Using Move2Kube CLI

In this tutorial we will see how we can transform a set of sample applications to run on Kubernetes. We will use the Move2Kube CLI tool to generate the Kubernetes YAMLs, Dockerfiles, and build scripts for each application. We will then build the container images and deploy them to a cluster.


  1. Install the Move2Kube CLI tool.

  2. We will use language-platforms sample. The language-platforms directory has a combination of multiple applications in different languages (Java, Go, Python, Ruby, etc.) which need to be containerized and deployed to Kubernetes.

Using the CLI to perform a transformation

  1. Download the language platforms sample. Each directory contains a simple web application written in different languages.
$ curl | bash -s -- -d samples/language-platforms -r move2kube-demos

$ ls language-platforms
django		golang		java-gradle	java-gradle-war	java-maven	java-maven-war	nodejs		php		python		ruby		rust
  1. Run move2kube plan -s language-platforms to generate a plan file. The -s flag specifies a source directory as language-platforms because we want Move2Kube to analyze the source code inside the language-platforms directory and come up with a plan for transforming them to Kubernetes YAMLs.
$ move2kube plan -s language-platforms
INFO[0000] Configuration loading done   
INFO[0000] Planning Transformation - Base Directory
INFO[0000] [CloudFoundry] Planning transformation   
INFO[0000] [CloudFoundry] Done  
INFO[0000] [ComposeAnalyser] Planning transformation
INFO[0000] [ComposeAnalyser] Done   
INFO[0000] [DockerfileDetector] Planning transformation
INFO[0000] [DockerfileDetector] Done
INFO[0000] [Base Directory] Identified 0 named services and 0 to-be-named services
INFO[0000] Transformation planning - Base Directory done
Click to see the remaining output.
  1. Look at the plan file we generated in YAML format. Notice Move2Kube has detected all the different services, one for each web app.
$ ls
language-platforms	m2k.plan
$ cat m2k.plan
kind: Plan
  name: myproject
  sourceDir: language-platforms
Click to see the rest of the yaml.
  1. Run the transformation using move2kube transform to perform the transformation according to the generated plan. By default Move2Kube looks for a plan file in the current directory. If you want to specify the path to a different plan file you can do so using the -p flag.

During transformation Move2Kube will ask several questions to help guide the transformation process. For most questions we can go with the default answers. Some questions to watch out for are:

  • The container registry and namespace that you want 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 you are deploying to MiniKube then give localhost as the ingress host and leave the TLS secret blank.

For all other questions accept the default answers by pressing Enter for each.

$ move2kube transform
INFO[0000] Detected a plan file at path /Users/user/Desktop/tutorial/m2k.plan. Will transform using this plan.
? Select all transformer types that you are interested in:
[Services that don't support any of the transformer types you are interested in will be ignored.]
 ComposeGenerator, DockerfileDetector, Jboss, WinSLWebApp-Dockerfile, ZuulAnalyser, Buildconfig, Maven, Tekton, Tomcat, WarRouter, WinConsoleApp-Dockerfile,DotNetCore-Dockerfile, EarAnalyser, KubernetesVersionChanger, Nodejs-Dockerfile, Ruby-Dockerfile, WinWebApp-Dockerfile, CloudFoundry, ComposeAnalyser, DockerfileParser,   EarRouter, Gradle, ClusterSelector, Rust-Dockerfile, ContainerImagesPushScriptGenerator, ReadMeGenerator, WarAnalyser, Jar, Golang-Dockerfile, Knative, Kubernetes, Liberty,  PHP-Dockerfile, Parameterizer, Python-Dockerfile, DockerfileImageBuildScript
? Select all services that are needed:
[The services unselected here will be ignored.]
 golang, myproject-python, nodejs, rust, simplewebapp, myproject-django, myproject-java-gradle, myproject-java-gradle-war, myproject-java-maven-war, myproject-php, ruby
INFO[0009] Starting Plan Transformation
Click to see the remaining questions and output.

After the questions are finished wait a few minutes for it to finish processing. Once it’s done, we can see it has generated a directory called myproject. The name of the output directory is the same as the project name (by default myproject). The project name can be changed using the -n flag.

$ ls
language-platforms	m2k.plan		m2kconfig.yaml		m2kqacache.yaml		myproject
$ ls myproject/	deploy		scripts		source

The applications can now be deployed to Kubernetes using these generated artifacts.

Deploying the application to Kubernetes with the generated artifacts

  1. View the full structure of the output directory by executing the tree command.
$ cd myproject/
$ tree
$ cd myproject/
$ tree
├── deploy
│   ├── cicd
│   │   ├── tekton
│   │   │   ├── myproject-clone-build-push-pipeline.yaml
│   │   │   ├── myproject-clone-push-serviceaccount.yaml
│   │   │   ├── myproject-git-event-triggerbinding.yaml
│   │   │   ├── myproject-git-repo-eventlistener.yaml
│   │   │   ├── myproject-image-registry-secret.yaml
│   │   │   ├── myproject-ingress.yaml
│   │   │   ├── myproject-run-clone-build-push-triggertemplate.yaml
│   │   │   ├── myproject-tekton-triggers-admin-role.yaml
│   │   │   ├── myproject-tekton-triggers-admin-rolebinding.yaml
│   │   │   └── myproject-tekton-triggers-admin-serviceaccount.yaml
│   │   └── tekton-parameterized
Click to see the rest of the tree.

The CLI has created Kubernetes YAMLs which are stored inside the deploy/yamls directory. For each of the directories and the services identified, it has created the deployment artifacts, service artifacts, and the ingress as required. The scripts directory contains the scripts for building the images for the applications using Dockerfiles.

Many scripts like and are also present inside the directory. It has also created a simple deploy/compose/docker-compose.yaml to test the images locally. It has also created Tekton artifacts inside the deploy/cicd/tekton directory that are required if you want to use Tekton as your CI/CD pipeline.

The file guides on the next steps to be followed.

$ cat
Congratulations! Move2Kube has generated the necessary build artfiacts for moving all your application components to Kubernetes. Using the artifacts in this directory you can deploy your application in a kubernetes cluster.

Next Steps
To try locally use the scripts in the "./scripts" directory, to build, push and deploy.

For production usage use the CI/CD pipelines for deployment.
  1. Run the script.

Note: This step may take some time to complete.

$ cd scripts/
$ ./
[+] Building 2.2s (11/11) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 1.36kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for 2.0s
=> [1/6] FROM 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 19.68kB 0.0s
Click to see the remaining output.
  1. Login into a container registry from the terminal. Refer to the instructions for Quay and Docker Hub

  2. Push the container images to the registry specified during the transformation using the script.

$ ./
Using default tag: latest
The push refers to repository []
8558b30e6fa3: Pushed
c25982faebf0: Pushed
e262751a7e43: Layer already exists
5e6a0ab87a4b: Layer already exists
7b17276847a2: Layer already exists
558b534f4e1b: Layer already exists
3ba8c926eef9: Layer already exists
352ba846236b: Layer already exists
Click to see the remaining output.
  1. Deploy the applications using kubectl apply -f ./deploy/yamls.
$ cd ..
$ kubectl apply -f deploy/yamls
deployment.apps/golang created
service/golang created
deployment.apps/myproject-django created
service/myproject-django created created
deployment.apps/myproject-java-gradle created
service/myproject-java-gradle created
deployment.apps/myproject-java-gradle-war created
service/myproject-java-gradle-war created
deployment.apps/myproject-java-maven-war created
service/myproject-java-maven-war created
deployment.apps/myproject-php created
service/myproject-php created
deployment.apps/myproject-python created
service/myproject-python created
deployment.apps/nodejs created
service/nodejs created
deployment.apps/ruby created
service/ruby created
deployment.apps/rust created
service/rust created
deployment.apps/simplewebapp created
service/simplewebapp created

Now all our applications are accessible on the cluster.

  1. Get the ingress to see the URLs where the apps have been deployed to kubectl get ingress myproject -o yaml.

Note: If you deployed to Minikube, make sure to enable the ingress addon.

$ minikube addons enable ingress
💡  After the addon is enabled, please run "minikube tunnel" and your ingress resources would be available at ""
▪ Using image
▪ Using image
▪ Using image
🔎  Verifying ingress addon...
🌟  The 'ingress' addon is enabled
$ minikube addons enable ingress-dns
💡  After the addon is enabled, please run "minikube tunnel" and your ingress resources would be available at ""
▪ Using image
🌟  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.

The apps should be available at the URLs below:


You can have a very diverse source environment like the language-platforms sample, which has multiple apps in different languages, and in a very simple way you can containerize and deploy them to Kubernetes. If you don’t like working with the terminal there is a Move2Kube UI tool which has all the same features as the CLI.