![11
Migration steps
Scenario #2 - known deployment
Source cluster
MyApplication
Kubernetes
objects
Kubernetes
objects
Kubernetes
objects
PV1
Internal Images
PV2
Destination cluster
MyApplication
Kubernetes
objects
Kubernetes
objects
Kubernetes
objects
PV1
Internal Images
PV2
Crane
State migration
>_
CODE
[>>>]
CI
[###]
CD
[yml]
MANIFEST
*
IMAGE
GIT](https://image.slidesharecdn.com/rehostingappsbetweenk8sclustersandautomatingdeploymentusingcrane-cncfwebinar-220217151730/85/Rehosting-apps-between-k8s-clusters-and-automating-deployment-using-crane-cncf-webinar-pptx-11-320.jpg)
![12
Migration Scenario #3
automated creation of pipeline
Source cluster
MyApplication
Kubernetes
objects
Kubernetes
objects
Kubernetes
objects
PV1
Internal Images
PV2
Destination cluster
MyApplication
Kubernetes
objects
Kubernetes
objects
Kubernetes
objects
PV1
Internal Images
PV2
[>>>]
CI
[###]
CD
*
IMAGE
Crane
State migration
Crane Image migration
>_
CODE
[yml]
MANIFEST
Crane reconstruct manifest
GIT
In this scenario, Crane would reconstruct manifests from the existing application and provide transform tools to help a developper quickly generate
non-environment specific automation. Those new manifests are pushed to GIT and a new pipeline gets generated to support this deployment. PVs and Images
can also optionally be migrated during the pipeline execution.
Crane creates a
new pipeline](https://image.slidesharecdn.com/rehostingappsbetweenk8sclustersandautomatingdeploymentusingcrane-cncfwebinar-220217151730/85/Rehosting-apps-between-k8s-clusters-and-automating-deployment-using-crane-cncf-webinar-pptx-12-320.jpg)
![% crane export ...
% crane transform …
% crane apply ...
% git add | commit | push
13
Reconstructing manifest
export, transform and push example
MyApplication
Kubernetes
objects
Kubernetes
objects
Kubernetes
objects
[###]
CD
[yml]
MANIFEST
GIT](https://image.slidesharecdn.com/rehostingappsbetweenk8sclustersandautomatingdeploymentusingcrane-cncfwebinar-220217151730/85/Rehosting-apps-between-k8s-clusters-and-automating-deployment-using-crane-cncf-webinar-pptx-13-320.jpg)
Rehosting apps between k8s clusters and automating deployment using crane cncf webinar.pptx
- 1. Marco Berube, Erik Nelson Rehosting Apps Between k8s Clusters And Automating Deployment Using Crane 1
- 2. 2 Accelerate your journey to Kubernetes with the Konveyor Community A community of people passionate about helping others modernize and migrate their applications to the hybrid cloud by building tools and best practices on how to break down monoliths, adopt containers, and embrace Kubernetes. www.konveyor.io
- 3. 3 Agenda ● What is Crane? ● Crane use-cases ● Introduction to Crane commands ● Demo
- 4. 4 Quick update on Crane Crane is a project in the Konveyor community to migrate applications from kubernetes to kubernetes/OpenShift. MTC 1.x is not Crane. MTC = OCP to OCP migration Crane doesn't have a downstream name yet. Expected release around ~spring 2022. Will come as command line power tools + OpenShift "easy" migration button.
- 5. 5 1. I would like developers to migrate their own applications between clusters (without admin permissions) 1. I would like to provision my application from pipeline, but migrate my application state (PVs, secrets, …) 1. I would like to use this migration opportunity to improve my current situation (leverage pipeline provisioning, transform my app to better use latest kubernetes features, etc.) 1. MTC 1.0 is very easy to use, but can be difficult to customize and troubleshoot. Lessons learned from MTC 1.x and most requested features
- 6. 6 Why a migration tool? Could you just re-provision your applications on a new cluster from pipeline? 1. My application can be re-provision from pipeline, but I want to migrate my application state. 1. I cannot re-provision my application from pipeline, but I'd like to take this migration opportunity to adopt some new best practices. 1. We don't have CI/CD automation for all our apps, some have just been provisioned manually for all kinds of reasons.
- 7. OpenShift cluster 7 Many customers only have a small fraction of their applications leveraging continuous delivery and automation. Some customers now have hundreds or even thousands of apps that have been manually deployed. In addition, some of the kubernetes manifest used to provisioned those apps had hard-coded values for a specific cluster, or expect specific environment conditions to run. For these reasons, those apps become "pets" and customers are afraid of any change that could impact them. Why migrating apps is hard for many customers? Automated deployment Manually deployed
- 8. OCP3 cluster 8 Current OCP3 to 4 migration scenarios Automated deployment Manually deployed OCP4 cluster Automated deployment Manually deployed Scenario 1 - Migration from pipeline (automated deployment) Scenario 2 - Migration toolkit (MTC/Crane) Scenario 2 requires a significant effort, but it works. MTC solves a short-term OCP4 upgrade problem by migrating applications as-is to OCP4 (backup/restore) and solve some environment transformation issues with scripts (like Migration hooks). That said, at the end of this migration, you have not improved your situation. Even with all this migration effort, you still have the same ratio of applications without automated deployments, locked into a brand new OCP4 cluster.
- 9. OCP3 cluster 9 Migrating manually deployed apps at scale to a continuous deployment model? Automated deployment Manually deployed OCP4 cluster Automated deployment Scenario 1 - Migration from pipeline (automated deployment) Scenario 3 - Automated creation of pipeline We know automated deployments is the right long term solution. But if you have hundreds or thousands of apps, going back to manually generate this automation would be unrealistic. We believe this has be simplified and automated when possible.
- 10. 10 Migration steps Scenario #1 - Simple migration from unknown deployment Source cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 Destination cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 Crane State migration Crane Image migration Crane reconstruct manifest and import
- 11. 11 Migration steps Scenario #2 - known deployment Source cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 Destination cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 Crane State migration >_ CODE [>>>] CI [###] CD [yml] MANIFEST * IMAGE GIT
- 12. 12 Migration Scenario #3 automated creation of pipeline Source cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 Destination cluster MyApplication Kubernetes objects Kubernetes objects Kubernetes objects PV1 Internal Images PV2 [>>>] CI [###] CD * IMAGE Crane State migration Crane Image migration >_ CODE [yml] MANIFEST Crane reconstruct manifest GIT In this scenario, Crane would reconstruct manifests from the existing application and provide transform tools to help a developper quickly generate non-environment specific automation. Those new manifests are pushed to GIT and a new pipeline gets generated to support this deployment. PVs and Images can also optionally be migrated during the pipeline execution. Crane creates a new pipeline
- 13. % crane export ... % crane transform … % crane apply ... % git add | commit | push 13 Reconstructing manifest export, transform and push example MyApplication Kubernetes objects Kubernetes objects Kubernetes objects [###] CD [yml] MANIFEST GIT
- 14. Migrating state direct migration example Source cluster PV1 PV2 Destination cluster PV1 PV2 % crane transfer-pvc ...
- 15. 15 Demo
- 16. Join the Konveyor Community www.konveyor.io