
Show HN: Go from Docker-Compose to Kubernetes with a simple tool - twelvenmonkeys
http://kompose.io/index
======
codebeaker
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)

~~~
theptip
You can also add the `--export` flag to get kubectl to omit unique metadata
that would be ignored on import; keeps your exported files a bit tidier.

~~~
xkarga00
Export needs more work.

~~~
theptip
Go on?

------
lobster_johnson
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.

~~~
mst
Some people learn better by putting everything together from the ground up.

Some people learn better by starting with a working example and going from
there.

I suspect you and I are both in the first group, but for the second group,
this seems like a nice way to get started.

~~~
lobster_johnson
Of course. I personally prefer learning by copying from examples rather than
reasoning through reference documentation. But that doesn't mean you need a
tool to generate examples. All you need is a small list of "this is how Docker
Compose declares X, this is how K8s does it". Compose's surface area is much
smaller than K8s, so it doesn't require a lot of examples.

------
dewiz
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.

------
sebgoa
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.

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

~~~
algesten
Is there a reason to go from docker-compose to kubernetes?

~~~
linkmotif
Kubernetes is a more robust tool and has a great community around it. For
example
[https://github.com/kubernetes/charts](https://github.com/kubernetes/charts).
You can launch any of these applications in one line

[https://github.com/kubernetes/charts/tree/master/stable](https://github.com/kubernetes/charts/tree/master/stable)
[https://github.com/kubernetes/charts/tree/master/incubator](https://github.com/kubernetes/charts/tree/master/incubator)

and then very easily tweak them.

------
bglusman
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](https://github.com/stellaservice/ky)

------
Dangeranger
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.

------
exclusiv
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?

~~~
shykes
If you use the desktop editions of Docker (Docker for Mac or Docker for
Windows), it will handle permissions correctly when mounting.

Currently the server and cloud editions (Docker for Linux, Docker for AWS,
Docker for Azure) don't solve the permission problems for performance reasons.
But in production you typically don't want or need to mount source code
anyway.

If you want to copy instead of mounting, just use the COPY operation in your
Dockerfile. [https://docs.docker.com](https://docs.docker.com)

Whether you use Kubernetes or Swarmkit for deploying to production, that takes
place later in the workflow.

------
bdcravens
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)

------
madhorse
I red Go as Golang, that title made little sense

------
dollar
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.

~~~
jedberg
"The complexity and learning curve of vim will kill the project"

"The complexity and learning curve of Emacs will kill the project"

"The complexity and learning curve of LaTex will kill the project"

"The complexity and learning curve of Sendmail will kill the project" <\-- The
only one that's partially true and it took 35 years.

~~~
dollar
Expert tools are for experts, they can be hard to use as long as they are
really good at doing what they do. If you haven't noticed though, these modern
times are all about convenience. We even have delivery services for gasoline,
and there was already a gas station on every corner. If Docker (or someone
else) makes this stuff super easy, they are going to win.

~~~
jedberg
Sure, and MS Word is way easier to use than Vim or Emacs or LaTex, and has a
much bigger market share, but it didn't kill those projects.

Exchange is a lot easier to use than Sendmail, but didn't kill that one
either.

When you need power and flexibility, which is generally the case when your
project gets to any reasonable size, then you go with the pro tool with the
learning curve.

