I ditched Docker for Podman

> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML. We all use Kubernetes these days, so why even bother about this?

I find that kubernetes yaml are a lot more complex than docker compose. And while I do, no, not everybody uses kubernetes.

Having an LLM function as a translation layer from docker compose to k8s yaml works really well.

On another note, podman can generate k8s yaml for you, which is a nice touch and easy way to transition.

Use an LLM is not a solution. It's effectively telling you to switch your brain off and hope nothing goes wrong in the future. In reality things do go wrong and any conversation should be done with a good understanding of the system involved.

When things go wrong, you just ask the LLM about that too. It's 2025.

/s

I don't know how to create a compose file, but I do know how to create a k8s yaml. Therefore, compose is more "complex" for me.

While I agree with this concept, I don't think it is applicable here. Docker compose files and k8s yaml are basically just two different syntaxes, saying the same thing. Translating from one syntax to another is one of the best use cases for an LLM in my opinion. Like anything else you should read it and understand it after the machine has done the busy work.

I bet there’s already a conversion library for it. Translating from one syntax to another _reliably_ should be done with a dedicated library. That being said, I don’t disagree that using an LLM can be helpful to generate code to do the same.

You don’t need an LLM for this. Use `kubectl` to create a simple pod/service/deployment/ingress/etc, run `kubectl get -o yaml > foo.yaml` to bring it back to your machine in yaml format, then edit the `foo.yaml` file in your favorite editor, adding the things you need for your service, and removing the things you don’t, or things that are automatically generated.

As others have said, depending on an LLM for this is a disaster because you don’t engage your brain with the manifest, so you aren’t immediately or at least subconsciously aware of what is in that manifest, for good or for ill. This is how bad manifest configurations can drift into codebases and are persisted with cargo-cult coding.

[edit: edit]

This is a conflation of "Simple" and "Easy" (rather, "complex" and "hard"). 'Simple vs Complex' is more or less objective, 'Easy vs Hard' is subjective, and changes based on the person.

And of course, Easy =/= Simple, nor the other way around.

This assumes everyone who wants to run containers via podman has kubectl and a running cluster to create resources in which is a strange assumption.

I'm a CKA and use docker compose exclusively in my homelab. It's simpler.

> You don't need an LLM for this

I guess that depends on how many you need to do

BTW, I'm talking about docker/compose files. kubectl doesn't have a conversion there. When converting from podman, it's super simple.

Docker would be wise to release their own similar tool.

compose syntax isn't that complex, nor would it take advtange of many k8s features out of the box, but it's a good start for a small team looking to start to transition platforms

(Have been running k8s clusters for 5+ years)

> Translating from one syntax to another is one of the best use cases for an LLM in my opinion.

Have a look at https://kompose.io/ as well.

"Using an IDE is not a solution" same arguments, same counter arguments. An abstraction being leaky does not mean it's useless. You will always need to drop down a layer occasionally, but there's value in not having to live on the lower layer all the time.

I disagree with you on that. Kubernetes YAML is on the same level of complexity as docker compose and sometimes even easier.

But verbosity - yeah, kubernetes is absolutely super-verbose. Some 100-line docker-compose could easily end up as 20 yamls of 50 lines each. kubectl really needs some sugar to convert yamls from simple form to verbose and back.

Both (K8s and Compose) are well defined schemas, hence the conversation is mere mapping via search & replace. Bunch of `sed` statements could do that, LLM is an overkill for the job.

Meanwhile, kompose.io exists, which is exactly what it does (but with Go templates as far as I can tell)

Why would docker should create such tool in the first place? It's the job of the target/destination to provide compatibility layer. In this case, Kubernetes already does with kompose.io tool.

kompose: https://kubernetes.io/docs/tasks/configure-pod-container/tra...

Also, technically docker-compose was the first orchestration tool compared to Kubernetes. Expecting former to provide a translation layer for the latter is rather unorthodox. It is usually the latter tool provides certain compatibility features for former tools...

Why would docker?

Because it's not very useful by itself for running production infra, but it's great for helping to develop it.

Otherwise you're going to see more and more move to podman (and podman desktop) / OCI containers over time, as corps won't have to pay the docker tax and will get better integration with their existing k8s platform.

The difference being that when your IDE makes a mistake you can understand and debug it, and maybe even patch it to fix it (or failing that at least understand what triggers it and work around it).

We have about 30 services running in 4 environments, including dev. I desperately want a better kustomize that removes most of the boilerplate and adds linting (like, every process should have a ram limit, but no cpu limit). I estimate about 75% of the lines of YAML are redundant.

For toy projects, sure. For production, the probability that the LLM would sneak in some subtle typo is just too high.

Have you thought about using jsonnet? It has a good library for k8s (https://jsonnet-libs.github.io/k8s-libsonnet/). I like how I don’t need to worry about white spaces and how I can use functions to reduce boilerplate. For an example environment: https://github.com/ThatFave/homelab

Is that intended to be a good example? There's still tons of duplication between the environments.

Kustomize eliminates the vast majority of the duplication (i.e. a unique fact about the cluster being expressed in more than one place), it's just the boilerplate that's annoying.

Not a good one, no. I am currently in the process of rewriting this, so that I eliminate duplicate code. The language has the potential, I am still in the process of learning. I also dislike boilerplate, but I think my example is still better than pure yaml.

> Kubernetes YAML is on the same level of complexity as docker compose

> Some 100-line docker-compose could easily end up as 20 yamls of 50 lines each.

Yeah, nothin to add here.

Docker is useful and running in production. (well, it was the only, before containerd got separated entirely and it was usable directly from K8s about when it was 1.16)

What you say is absolutely correct. If Docker keeps creating compatibility layers for it's competitors, it makes everyone to switch to a competitor. In this case, the competitor is Kubernetes as it's running in production for much larger scale (enterprise workloads) compared to Podman et. al.

Hence, it's the job of Podman, Kubernetes, et. al. to write their compatibility layer to provide a value-add for their customers.