I was so excited by my success with Docker Stacks in my last blog post that I wanted to explore some additional options for migrating from Docker Compose to Kubernetes (k8s). I had come across the Kompose project earlier this year, and had made a mental note to revisit when I had exhausted what I wanted to do with Docker Compose.
Kompose, which has been around longer than Docker Stacks, is trying to solve the same problem, helping people migrate Docker Compose to k8s. Unlike Docker Stack, not only can you deploy directly to a k8s but you can also have it just generate the YML files for use in k8s, Openshift, and Helm.
I tore down my local demo environment and gave kompose a try. The command to deploy straight to your k8s instance is super simple, just run kompose up!
The first thing I learned is that Kompose respects the build directive, but also wants to tag and publish the containers to your docker repo.
Ok, so I had spend some time to get my .docker/config.json setup with some credentials to a private repo. I also noticed that kompose had presented my custom image names with 'library'. Had I been working with my Sonatype Nexus Repository, that would have worked, but I was pushing back to Docker Hub for now. After a few iterations, it all worked.
At this point, I was excited. It still helped me manage my custom images, though I felt it was too soon to publish them. It seemed like Docker Stack until I tried to hit my apps with a browser. When localhost wouldn't work, I looked around the dashboard.
No external endpoints! Ok, so not as seamless as Docker Stack. While everything is up and running, I can't hit any of it. On a more interesting note, kompose ignored my local volume mounts and create a persistent volume for both IQ and Nexus Repository, which would help me make that transition.
I quickly switched back to a Docker Stack so I could compare the YML files, in hopes of learning how to add those endpoints. When I ran kompose down I learned one more gotcha, it also removed my persistent volumes.
Even though these specs don't seem to work out-of-box, I feel they can be a good starting place as I continue my education into kubernetes. So I've run the kompose convert commands to generate the YML files for Kubernetes, Openshift, and Helm.
I'll add them to the git repo, where we can track the changes I'll need to make to make them more useful and better starting examples.
In a world of winning or learning, this was a learning experience. Still, I'm excited to have to roll up the sleeves a bit and work through the shortcomings of the conversion. I hope to learn from what Docker Stack has done and apply that to the converted to bring them up to par with Docker Stack, while also tackling the persistent volumes along the way.
Has anyone else made the leap from Compose to Kubernetes? How are your developers working locally and yet feeding that work into real environments? Is the local build dead, because it can all be done in the cloud now?
For now, Docker Compose is still the easiest way to manage a local environment with the least overhead and complexity. Getting to where I can seamlessly transition that work to my AWS or GCP instances is still my goal, and I'll try to continue chronicling my adventures along the way.
Curtis Yanko is a Sr Principal Architect at Sonatype and a DevOps coach/evangelist. Prior to coming to Sonatype Curtis started the DevOps Center of Enablement at a Fortune 100 insurance company and chaired a Open Source Governance Committee. When he isn’t working with customers and partners on how ...
Explore All Posts by Curtis YankoTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.