Hacker News Reader

Comment by oplav | Hacker News Reader

I've been exploring 2 alternatives (podman and colima) to replace my normal docker workflow, which is just building and running containers locally, sometimes with docker-compose. I started with podman but had issues with 2 main pieces of my workflow: docker-compose (or podman-compose) and shared volumes (with `run -v`). Switched over to colima and those worked out of the box for me ("brew install docker; brew install docker-compose; brew install colima; colima start; docker run ...")

View on HN

podman: https://podman.io/ colima: https://github.com/abiosoft/colima

Podman works with docker-compose 1.x only and needs some finagling to work. I have this wrapper script as podman-compose

    #!/bin/bash
    
    set -e
    
    tmpdir=$(mktemp -d)
    port=$(podman system connection ls | grep -Eo 'localhost:\d+' | head -1 | cut -d: -f2)
    [[ -n $port ]] || exit 1
    ssh -fnNT -L"$tmpdir/podman.sock":/run/user/1000/podman/podman.sock -i ~/.ssh/podman-machine-default ssh://core@localhost:"$port" -o StreamLocalBindUnlink=yes
    export DOCKER_HOST="unix:///$tmpdir/podman.sock"
    docker-compose "$@"
    rm -r "$tmpdir"

Afaik podman-compose doesn't support "docker compose run" to do one-off stuff in a new container? Is there some alternative?

I do it all the time now, have the entire dev flow dockerized. So I run tests, lints, fixers, migration etc all through docker compose.

To be clear: this isn’t the actual podman-compose project, just a wrapper to make docker-compose work with podman-machine. That said, I just tried to do a run and it didn’t work. It’s not part of my workflow though so I haven’t encountered it before and thus haven’t really looked into it.

> Afaik podman-compose doesn't support "docker compose run" to do one-off stuff in a new container? Is there some alternative?

Minikube, no sarcasm. I'm also going to use Minikube.

This is exactly why I ditched Podman.

I really wanted to use it badly, but lacking an alternative to Docker Compose or compatibility with it in 2022 is unacceptable. Yes, there is technically a way you can orchestrate containers through configuration, and I don't remember what it was called, but I found it both difficult to use and learn. It's crazy to me that people wanted to develop an alternative to Docker... without a way to just configure and network containers with YAML or JSON.

There are use-cases that Podman can be used for that don’t involve Compose (yes, even with orchestration). Likewise there are a lot of features Podman and family have that Docker does not. Historically rootless is the big one; Docker sort of has that now but it’s still not daemon-less.

What problems did you have running Docker-compose with podman? I am running both on a server without any problem. Fedora-like distros have a package podman-docker that make docker-compose work without workarounds.

Is this a short term issue or is nobody working on docker-compose 3.x compatibility?

I assume you meant 2.x; Compose 2.x is only ~4 months old. I believe the intention of the Podman team is to abandon their podman-compose and work on compatibility with docker-compose 2.x going forward.

The version of the file format is different to the version of the CLI tool. Compose (the file format) 3.x was introduced with Compose (the tool) version 1.10 in 2017: https://github.com/docker/compose/releases/tag/1.10.0

Oh. I was only talking about the program and the interface it uses with the underlying runtime. Compose 2.x expects the underlying tool to have a different API.

For the life of me, I could not make podman working to replace Docker. I keep getting various errors.

I just made the switch to colima. Thanks for mentioning it!

I just switched to Colima and found it worked perfectly out of the box, according to the documentation. Once I had brought up a new machine with `colima start --cpu 2 --memory 8 --disk 10 --with-kubernetes`, `docker compose` worked perfectly and I could see the colima-backed kubernetes cluster available to control via `kubectl config get-contexts`.

+1 to Colima. Works seamlessly. Made the switch not too long ago.

What drew you to switch up your workflow?

I am on a m1 macbook air and I've been using Docker + Docker Desktop without much issue, and my use-case is a little simpler than yours (only running single containers at a time).

I'm genuinely curious to learn more about what these tools (Colima, podman) help enable. If I'm missing out on a performance boost, I'd definitely check them out.

I suspect it was the docker licensing changes. We're largely switching to Colima at my work too.

https://news.ycombinator.com/item?id=28369570

In case you missed it the license terms for Docker Desktop have changed and require companies with ~250 employees to start paying for it: https://www.docker.com/blog/updating-product-subscriptions/

And in those larger companies, just paying for the "coffee a month" may not be an option, since they insist all licenses are company owned and it's less effort to change my docker VM wrapper than get shit past my company's purchasing department in a reasonable amount of time.

Exactly, I think this is really going to backfire for the bean counters that took over Docker. It should either be free or $100k+ agreements for extremely large companies. They're way underestimating the inertia and pain with trying to nickle-and-dime small and medium business users.

It doesn’t help that the compulsory “Business” edition is burdened with the anti-feature of Docker Registry but that SSO is still “on the roadmap.”

There’s no way we would have gotten the product through IT Security Management on time, much less through purchasing. Docker appears to have fallen down a bit on their market research - they forgot that their real customer for the Business subscriptions weren’t the developers at large companies, but their software purchasing processes.

gotcha. i was aware, but doesn't apply to my current circumstance.

is that the motivator for most, then?

It was the motivator for me. But having gone through the effort to evaluate alternatives, I’m happy where I ended up (lima). It’s free and open source, and easier to install and configure via scripts than Docker Desktop. The goal for our team is to make getting new developers set up as simple as possible (ideally just a single command), but prior to now the instructions to install and configure Docker Desktop were always an asterisk in the prerequisites section.

I switched because of licensing changes and because I find the docker desktop UI to be laggy, frequently updating with no discernible benefit to me, and superfluous -- I would rather interact with my containers via the CLI, but had to use the desktop app to start the daemon.

Reply on news.ycombinator.com