3. Transform

Now run the transformation according to the plan file generated in the previous step. The transformation phase runs all of the transformers again, but this time the transformers will use the plan to generate the output files.

During this process, the transformers might run into situations where it requires some more information to generate the output. In order to get this information, it will ask the user some questions. The questions range from yes/no, to multiple choice, to string input and most will have a default answer.

Example: Some of the questions Move2Kube will ask is about the type of container registry where you want to push the images to. It also needs to know the registry namespace and any authentication necessary for pulling images from that registry.

If you want to skip the QA, use the --qa-skip flag to accept the default answers. However, a config file that contains all of the answers using the --config flag can be used instead of skipping.

After the transformation is finished, all the answers are written to a config file called m2kconfig.yaml which can be used for later transformations.

The transformation phase produces all the necessary output files including the Dockerfiles, build scripts for containerizing various services and Kubernetes deployment, and the service and ingress YAMLs necessary for deploying the application to a Kubernetes cluster.

Move2Kube also generates the CI/CD pipeline and parameterized versions of all the Kubernetes YAMLs (Helm chart, Kustomize YAMLs, Openshift templates, etc.) for various environments (dev, staging, prod, etc.).

Prerequisites

Perform the Plan step before this procedure.

Transforming using the CLI

  1. Run the transformation in the same directory as the plan file. This will detect the plan file and use it to find the source directory.
$ move2kube transform
Optional: Provide answers to questions using a config file...

If you want to avoid the question answers during transformation, you can use this config file

$ move2kube transform --config m2kconfig.yaml
  1. Answer all the questions as appropriate. For most questions accept the default answers. Some questions to watch out for are:
  • A spurious service called config-utils was detected by one of the transformers can be deselected when asked to select the services or by editing the plan file.
  • Move2Kube has detected the Maven profiles for each of the Java services. Select the dev-inmemorydb profile to deploy to MiniKube. There will be similar questions for the SpringBoot profiles.
  • The container registry and namespace to use. A container registry is where all the images are stored (Example: Quay, Docker Hub, etc.).
  • The ingress hostname and ingress TLS secret. If deploying to MiniKube, give localhost as the ingress host and leave the TLS secret blank.
  • Select ClusterIP to only expose the order customers inventory and gateway services inside the cluster. Choose Ingress and / as the path to expose the frontend service. This way only the frontend will be exposed outside the cluster through the ingress.
$ move2kube transform
INFO[0000] Detected a plan file at path /Users/user/Desktop/tutorial/m2k.plan. Will transform using this plan.
INFO[0000] Starting Plan Transformation 
? Select all transformer types that you are interested in:
ID: move2kube.transformers.types
Hints:
[Services that don't support any of the transformer types you are interested in will be ignored.]
 Buildconfig, CloudFoundry, ClusterSelector, ComposeAnalyser, ComposeGenerator, ContainerImagesPushScriptGenerator, DockerfileDetector, DockerfileImageBuildScript, DockerfileParser, DotNetCore-Dockerfile,EarAnalyser, EarRouter, Golang-Dockerfile, Gradle, Jar, Jboss, Knative, Kubernetes, KubernetesVersionChanger, Liberty, Maven, Nodejs-Dockerfile, PHP-Dockerfile, Parameterizer, Python-Dockerfile, ReadMeGenerator,Ruby-Dockerfile, Rust-Dockerfile, Tekton, Tomcat, WarAnalyser, WarRouter, WinConsoleApp-Dockerfile, WinSLWebApp-Dockerfile, WinWebApp-Dockerfile, ZuulAnalyser
? Select all services that are needed:
ID: move2kube.services.[].enable
Hints:
[The services unselected here will be ignored.]
 customers, frontend, gateway, inventory, orders
INFO[0005] Iteration 1  
INFO[0005] Iteration 2 - 5 artifacts to process 
INFO[0005] Transformer CloudFoundry processing 3 artifacts
INFO[0005] Transformer CloudFoundry Done
INFO[0005] Transformer Maven processing 2 artifacts
Click to see the remaining transform questions.

Transforming using the UI

Continue from the previous step in the UI.

  1. Scroll down from the Plan section to the Outputs section.
spec:
    sourceDir:sources
    services:
        config-utils:
            -transformerName: Maven
             paths:
                MavenPom:
                 -src/src/config-utils/pom.xml
                ServiceDirPath:
                 -src/src/config-utils
             configs:
                Maven:
                 mavenAppName: config-utils
                 artifactType: jar
            customers-tomcat:
             - transformerName: Maven
  1. Click the Start transformation button.

A form to ask the user questions to guide the transformation opens.

  1. Answer all the questions as appropriate. For most questions accept the default answers. Some questions to watch out for are:
  • A spurious service called config-utils was detected by one of the transformers can be deselected when asked to select the services or by editing the plan file.
  • Move2Kube has detected the Maven profiles for each of the Java services. Select the dev-inmemorydb profile to deploy to MiniKube. There will be similar questions for the SpringBoot profiles.
  • The container registry and namespace to use. A container registry is where all the images are stored (Example: Quay, Docker Hub, etc.).
  • The ingress hostname and ingress TLS secret. If deploying to MiniKube, give localhost as the ingress host and leave the TLS secret blank.
  • Select ClusterIP to only expose the order customers inventory and gateway services inside the cluster. Choose Ingress and / as the path to expose the frontend service. This way only the frontend will be exposed outside the cluster through the ingress.
  1. Click the Next button to continue going through the questions and then run the tranformation.

Move2Kube processes the transformation and the output appears.

  1. Click the output ID link to download.

Using the output generated by Move2Kube transform

For a sample output of what Move2Kube generates for this enterprise app, click here.

After the output has generated, run the scripts inside the scripts directory.

  1. Run the builddockerimages.sh script to build all the container images for each service using the Dockerfiles that were generated.
$ cd myproject/scripts/
$ ./builddockerimages.sh
  1. Run the pushimages.sh script to push them to the specified container registry.
$ ./pushimages.sh
  1. Because the prod-externaldb profile was selected, deploy the database using the YAMLs located here.
$ cd ..
$ curl https://move2kube.konveyor.io/scripts/download.sh | bash -s -- -d samples/enterprise-app/database -r move2kube-demos
$ minikube start --memory 8192 --cpus 2 # do this only if you are deploying to Minikube
$ kubectl apply -f database/
  1. Deploy the Kubernetes YAMLs that Move2Kube generated to the cluster
$ kubectl apply -f deploy/yamls

The application is now running on the cluster.

  1. Get the URL where the app has been deployed to, using kubectl get ingress myproject -o yaml

Note: If deployed to Minikube, enable the ingress addon and start minikube tunnel to access the ingress on localhost.

$ minikube addons enable ingress
💡  After the addon is enabled, please run "minikube tunnel" and the ingress resources would be available at "127.0.0.1"
▪ Using image k8s.gcr.io/ingress-nginx/controller:v1.0.4
▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
▪ Using image k8s.gcr.io/ingress-nginx/kube-webhook-certgen:v1.1.1
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled
$ minikube addons enable ingress-dns
💡  After the addon is enabled, please run "minikube tunnel" and the ingress resources would be available at "127.0.0.1"
▪ Using image gcr.io/k8s-minikube/minikube-ingress-dns:0.0.2
🌟  The 'ingress-dns' addon is enabled
$ minikube tunnel
❗  The service/ingress myproject requires privileged ports to be exposed: [80 443]
🔑  sudo permission will be asked for it.
🏃  Starting tunnel for service myproject.
Password:

The app is now available on http://localhost.

Optional: As part of the transformation, if Cloud Foundry runtime information is required, use the collect output in planning and transformation: Collect information from running apps.

Customizing the output

After inspecting the output that Move2Kube produced some changes might be necessary. For example:

  • Changing the base image used in the Dockerfiles.
  • Adding some annotations to the Ingress YAML.
  • Changing the output directory structure.
  • Changing which values are parameterized in the Helm chart.
  • Generating some new files, etc.

For all these user specific requirements and more, use customizations.

Source