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)

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.

Export needs more work.

Go on?

Links are supposed to be legacy and docker seems to push people into using docker networks, but pragmatically there's something nice about links that make it really fit and simple for many simple use cases where full-blown networks and service discovery are just way overkill.

If you don't use networks then all services are on the default network and can refer to each other by service name, so even without complicated full-blown networks links are superfluous.

Very interesting, as we're looking into doing essentially exactly the same very soon. seems even more urgent with docker just having announced free/enterprise editions. Would be very interested in a blog post / some more detail about how it went down!

more generally, what were the biggest upsides / downsides from moving to k8s?!

Docker always had free and enterprise versions, they've just rebranded them.

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.

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.

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.

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 tool kompose helped me when I did my first POC on kubernetes since it allowed me to get up and running with something without having to study all the new abstractions and terminology in kubernetes, but pretty quickly I ended up going back over the generated yml files line by line and manually changing stuff. Overall still a helpful tool since many people use Compose in development but need to eventually migrate to kubernetes for production.

I'm really happy to hear that it helped you get started with Kubernetes. This was one of the reasons we started with the project.

(I'm one of the Kompose maintainers. ;-) )

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

Kubernetes is a more robust tool and has a great community around it. For example 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/incubator

and then very easily tweak them.

The typical use case is when a dev team uses docker compose while the ops team has chosen docker+kube. It creates an impedance mismatch which complicates the dev/ops handoff.

Since it's typically hard for the ops team to convince the dev team to abandon compose, the next best thing for is to translate formats each time the dev team wants to deploy. That is what kompose allows.

Note that Docker has a similar translator built-in, so ops teams can deploy compose to production directly without needing an external tool. But it doesn't support kubernetes, so it doesn't help ops teams who have adopted kube.

We've been using docker-compose for dev but still used eg Salt and hand written deploys for production. We basically used docker parity between dev machines, and are now taking it into production

agreed, it's surprisingly hard to get your head around initially. minikube helps me personally.

Started using minikube and kompose just yesterday. They're really nice tools. I'm stuck on the fact that minikube doesn't seem to use my vpn connection (fail when attempting to link to library dependencies over vpn).

You can install Docker for Mac, which supports VPN integration out of the box, then install kubernetes on top of that. I heard it works great.

https://docker.com/mac

Yes, I've been using Docker for Mac since beta and it does indeed work fine with VPN. It's when I'm using Docker inside minikube where it fails. I didn't realize installing k8 and using with Docker for Mac was straightforward, I'll give it a try. Btw, thx for such an incredible tool!

That sounds annoying. Could it be something with the configuration in your virtualization tool?

Could be, I'm using xhyve, but haven't messesd with any configuration myself.

I work on a team who wants to help make this easier. What are the concepts that you think are the most complex?

For me, it's mostly the number of concepts and the fact that they need to be known upfront. None of them are particularly difficult, but I've done ops for a bit and gone from manual sysadmin on bare metal to Puppet to Chef to Salt... then when we started playing with docker, there's the initial learning curve, then a slew of orchestration options to consider. I'm exhausted keeping up with devops tools.

What I want is a better way to learn hands-on or as I go. Not sure exactly what that looks like.

Nothing reminds you how little you actually know when you have to pick up docker/k8s for the first time, and realize that it's a long journey to understand every nuance you need to get things done.

I actually just wrote an article that talks about all these complexities, and how micro-PaaS (things like hyper.sh, dokku, and nanobox.io) address a lot of them.

https://hackernoon.com/what-is-micro-paas-and-why-its-the-fu...

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?

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

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

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.

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

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.

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.

Win the mass market I mean...

Ok, but have you ever tried to deploy docker compose on production. How did it scale for you?

You missed the point. Kompose will generate the Kubernetes config and it can even bring up your application using "kompose up" command. Have some faith and read more about it on kompose.io and use it

Quick correction, Docker 17.03 supports compose files out of the box, in swarm mode. Two commands to deploy and scale. https://docs.docker.com/engine/reference/commandline/stack_d...

This.

GP comment was downvoted into oblivion, but he had a point. Compose (at least, v3/v3.1) is a reasonably simple system, that can describe a fairly complex setup. Kubernetes has a lot of complexity to it. And the question "why do I need it, if there are simpler options?" is left unanswered.

Until you end up working around various shortcomings and then suddenly your yaml files are a mess and almost a framework in themselves.

The Kubernetes files really arent that complex