Show HN: Go from Docker-Compose to Kubernetes with a simple tool

I used this to get an idea how K8s looked when I wanted to migrate ~500 lines of docker compose YAML config to k8s.

The result was sufficiently confusing that we threw it away, but it was helpful to get an idea what we were looking at, and why. We rebuilt the stack from hand, using all the files from the kompose tool as a guide/reference.

Later we found that kubectl can dump yaml, I found `kubectl .... -o=yaml[ ...]` to be super helpful, for any command you run from the tutorial or elsewhere, it'll generate you the equivalent YAML which you can commit/apply at your leisure.

I'm glad the tool existed, but idiomatic stuff in docker-compose is unidomatic in k8s (namely secret handling is completely different) which is a hurdle, and the "links" concept as used in docker-compose is essentially absent from k8s for our purposes (and, replaced wth much, much better and granular dns services and "expose"s)

While I appreciate the effort, as a Kubernetes user I can't really recommend this tool.

As a migration tool, it might save some time building your YAML files, but the differences between Compose and Kubernetes are large enough (secret management, for example) that the mapping will be incomplete. But more importantly, the tool itself doesn't lead to a great understanding of Kubernetes itself. In my opinion, the better approach is to learn Kubernetes, then put together your YAML files piece by piece until it all works. Learn by doing.

And it's not useful as a general-purpose tool that abstracts Kubernetes; you need all of the stuff you put in the YAML files. The only way to abstract it is to move one layer up, into a PaaS.

I think it would make more sense to do the opposite, generate Docker compose + files starting from a Kubernetes configuration. k8s features is a superset of Docker Compose, for instance networking, importing files, managing secrets is imho easier and superior in k8s. With docker-compose and Mesos often one has to find workarounds, change the topology, install additional pieces (e.g. service discovery) etc.

To be honest, I don't see a reason to use docker-compose anymore, because minikube gives the full Kubernetes experience locally. It might take a bit to learn k8s, but it's definitely worth it.

"docker-compose up" is perhaps still easier to start with, but as soon as you start working, rather than playing with demos, you hit limitations and want more.

I was part of the team that started kompose. The main idea was to help developers who had adopted docker-compose moved to Kubernetes. We understand that this is not a perfect match and there will always be semantic mismatch. Personally, I don't expect folks to use this for production. But, if you started down the road of docker-compose and want an easy way to generate Kubernetes manifests then kompose does the trick. This will get you on the way, and you will start learning Kubernetes primitives.

Hoping this helps with the Kubernetes learning curve. We've just started migrating and keeping track of the terminology has been tough.

This looks neat! I'd mirror what codebreaker said and probably in the long term you want to use something like helm.sh to manage your kubernetes yaml, but this may help get started. Also possibly useful for getting started (especially if coming from Heroku or using Foreman with a Procfile) is a gem I built, more or less in anger, out of inability to get a supporting partner to agree to using helm but not wanting to have duplication across deployment files and across environments, so while I don't necessarily reccomend as a long term tool, if you can't or don't want to initially use helm, ky[0] may be a useful stepping stone/bridge solution to avoid a ton of seperate manually maintained, unDRY deployment files with similar or identical env vars and small differences for web vs worker deployments etc.

[0]: https://github.com/stellaservice/ky

This looks really well put together and easy to understand. A lot of the people I've worked with understand Docker-Compose well. The Compose model seems to stick well in the mind.

One of the nice side effects of this tool will be mapping existing Compose knowledge into the Kubernetes config model. It's like a mini translator.

I have a feeling that this will make a big difference in the usage of MiniKube.

I'm still pretty new to docker and docker-compose. I've setup a few dev environments but how do you all deal with your app code? Do you mount it or do you copy it. I'm having permission problems with mounting. If you copy what's the workflow like and does kubernetes help at all with any of this?

One of the nice things about AWS ECS is that the command line lets you create services via compose files (usually with some small modifications)

I red Go as Golang, that title made little sense

Now you can take a really simple Docker compose file and make it complicated with Kubernetes, happy day! Seriously, the complexity and learning curve of Kubernetes will eventually kill the project.