Getting started with Kompose
We have written about Kompose earlier here , when it was as young as 0.1.0. This blog post will showcase where Kompose stands now.
Kompose is a tool that converts a Docker Compose file to Kubernetes or OpenShift artifacts. Kompose was originally started as an onboarding tool for Kubernetes users by Skippbox (now part of Bitnami). It went on to receive early contributions from both Google and Red Hat.
Kompose has graduated from the Kubernetes Incubator, we reached the epic milestone of 1.0.0, and so it’s now officially part of the Kubernetes Community Project.
Let’s see what Kompose is all about! Here’s a standard example that the Kubernetes community uses consisting of a web interface (Go) as well as a cluster of databases (Redis).
Let’s use an official Kompose example!
version: "2" services: redis-master: image: grc.io/google_containers/redis:e2e ports: -"6379" redis-slave: image: gcr.io/google_samples/gb-redisslave:v1 ports: - "6379" environment: - GET_HOSTS_FROM=dns frontend: image: gcr.io/google-samples/gb-frontend:v4 ports: - 80:80 environment: -GET_HOSTS_FROM=dns labels: kompose.service.type:LoadBalancer
Features of Kompose:
The following sections discuss the various features of Kompose:
Deploying Kubernetes Artifacts Directly
The following example demonstrates how you can run ‘kompose up’ to deploy an application to a kubernetes cluster. This example will use either *minishift* or *minikube* to test it locally.
$ kompose up
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need a different kind of resource, use ‘kompose convert’ and ‘kubectl create – f commands instead.
INFO Deploying application in "default" namespace INFO Successfully created Service: frontend INFO Successfully created Service: redis-master INFO Successfully created Service: redis-slave INFO Successfully created Deployment: frontend INFO Successfully created Deployment: redis-master INFO Successfully created Deployment: redis-slave Your application has been deployed to Kubernetes. You can run 'kubetcl get deployment, svc, pods, pvc' for details.
Generating Kubernetes Artifacts
If you want to simply generate artifacts than deploying immediately, you can run ‘kompose convert’ as follows:
$ kompose convert INFO Kubernetes file "frontend-service.yaml" created INFO Kubernetes file "redis-master-service.yaml" created
You can deploy this later, when required, using:
$ kubectl create -f frontend-service.yaml, redis-master-service.yaml, redis-slave-service.yaml, frontend-deployment.yaml, redis-master-deployment.yaml, redis-slave-deployment.yaml service "frontend" created service "redis-master" created
Deploying/Generating OpenShift artifacts
OpenShift is another distribution of Kubernetes and it is one of the supported providers of Kompose. You can deploy the artifacts on OpenShift by providing the command line argument ‘–provider’:
$ kompose up --provider openshift
You can generate artifacts using:
$ kompose convert --provider openshift
Store output artifacts to a specific location
In case, you need to store output artifacts to some location, use the command line argument ‘-o’ as shown below.
$ kompose convert -o out/ INFO Kubernetes file "out/frontend-service.yaml" created INFO Kubernetes file "out/redis-master-service.yaml" created
You can specify the number of replicas by using the command line argument ‘–replicas’.
$ kompose convert --replicas=4
Delete deployed manifests
You can delete instanced artifacts like service, deployments etc. as follows:
$ Kompose down INFO Deleting application id=n "default" namespace INFO Successfully deleted Service: frontend INFO Successfully deleted Service: redis-master INFO Successfully deleted Service: redis-alive INFO Successfully deleted Deployment: frontend INFO Successfully deleted Deployment: redis-master INFO Successfully deleted ployment: redis-slave
As of now, not all the Docker Compose keys can be mapped to Kubernetes artifacts. Hence, for service type and ingress, we have defined two types of Kompose specific labels as follows:
'kompose.service.expose' defines if service needs to be made accessible from outside of a cluster labels: Kompose.service.expose: true Kompose.service.expose: "example.com" 'kompose.service.type' defines types of services to be created labels: Kompse.service.type: nodeport # or clusterip or loadbalancer
The following sections discuss the support provided by Kompose 1.0.0 for Docker build and push as well as for Docker Compose Version 3.
Some Docker Compose files contain the ‘build’ key, which means that the Dockerfile file is in the code repository. When you do, ‘docker-compose build’ or ‘docker-compose up’, it is supposed to build the Docker image.
Earlier, the `build` supported only the OpenShift provider and ignored the Kubernetes provider. In the 1.0.0 release, Kompose supports building container images for both Kubernetes and OpenShift providers.
For example, in case our Docker compose file is: version: "3" services: foo: build: "./build" image" docker.io/foo/bar
It would simply generate artifacts as follows (default value of ‘–build’ flag is none):
$ kompose convert INFO file "foo-service.yaml" created INFO file "foo-deployment.yaml created
Whereas in the case of OpenShift provider, buildconfig gets generated using the following command:
$ kompose convert --provider=openshift --build build-config INFO Buildconfig using firstname.lastname@example.org:surajnarwade/Kompose.git::master as a source. INFO file "foo-service.yaml" created INFO file "foo-deploymentconfig.yaml" created INFO file "foo-imagestream.yaml" created INFO file "foo-buildconfig.yaml" created
When you run ‘kompose up’, the local building of images takes place and is pushed to the respective docker registry for which credentials are stored in the ‘~/.docker/config.json’ file in the user’s home directory. (‘–build’ flag is set to local)
You can deploy it as follows:
$ kompose up INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar' INFO Building image 'docker.io/foo/bar' from directory 'build' INFO Image 'docker.io./foo/bar' from directory 'build' built successfully INFO Pushing image 'foo/bar:latest' to registry 'docker.io' INFO Attempting authentication credentials 'https://index.docker.io/v1/ INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io' INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need a different kind of resources, use the 'kompose convert' and 'kubectl create -f' commands instead. INFO Deploying application in "default" namespace INFO Successfully created Service: foo INFO Successfully created Deployment: foo Your application has been deployed to Kubernetes. You can run 'kubectl get deployment, svc, pods, pvc' for details.
In case you already have the required images, you need to disable building and pushing of the images using the ‘–build’parameter:
$ kompose up --build none
Docker Compose Version 3 support:
As of 1.0.0, we provide support to Docker Compose Version 3.
Here is a demonstration using our default example.(https://github.com/kubernetes/kompose/blob/master/examples/docker-compose-counter-v3.yaml)
version: "3" services: web: image: tuna/docker-counter23 ports: - "5000:5000" deploy: restart_policy: condition: any labels: kompose.service.type: Nodeport redis: image: redis:3.0 deploy: replicas: 1 ports: - "6379"
Here’s the other stuff we’ve added including bug fixes and new keys such as ‘replicas’, ‘restart_policy’, etc.
Previously, we have to mention ‘replicas’ using ‘–replicas’ flag, but now with Docker Compose version 3 support, we can mention replicas in Docker Compose file itself.
Give it a try 🙂
Download this Kubernetes cheat sheet for automating deployment, scaling and operations of application containers across clusters of hosts, providing container-centric infrastructure.