:
Skip Navigation
Resources Blog Nexus Reference Platform: Kompose, OpenShift and Helm

Nexus Reference Platform: Kompose, OpenShift and Helm

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 essentially the same problem, help 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. This seems awesome, right?

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 does respect the build directive, but it also wants to tag and publish the containers to your docker repo.

kompose1

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 prepended my custom image names with 'library', had I been working with my Nexus Repository, that would have worked but I was pushing back to dockerhub for now. After a few iterations, it all worked.

kompose2

At this point, I was pretty excited, it still helped me manage my custom images, though I felt it was too soon to be publishing them. It seemed that it had worked just like Docker Stack until I tried to hit my apps with a browser. When localhost wouldn't work I went and looked around the dashboard.

kompose3

No external endpoints! Ok, so not quite 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 NXRM which would help me make that transition.

I was able to quickly switch back to a Docker Stack so I could compare the YML files with the hopes of learning how to add those endpoints.When I ran kompose down I learned one more gotcha, it also removed my persistent volumes! Oh well, easy come, easy go ;-)

Even though these specs don't seem to work out-of-box I do feel like they can be a good starting place as I continue my education into kubernetes. So I've gone ahead and run the kompose convert commands to generated the YML files for Kubernetes, Openshift, and Helm.

kompose4

I'll go ahead and add them to the git repo where we can track the changes I'll need to make in order 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'm hoping I can 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 just be done in the cloud now?

For now, Docker Compose is still the easiest way for me 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 chronicle my adventures along the way.

Picture of Curtis Yanko

Written by Curtis Yanko

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 to build security and governance into modern CI/CD pipelines he can be found raising service dogs or out playing ultimate frisbee during his lunch hour. Curtis is currently working on building strategic technical partnerships to help solve for the rugged devops tool chain.