←back to thread

Red Hat to contribute container tech (Podman, bootc, ComposeFS...) to CNCF

(www.redhat.com)
272 points twelvenmonkeys | 7 comments | 14 Nov 24 17:59 UTC | HN request time: 0s | source | bottom
Show context
kuratkull ◴[14 Nov 24 19:28 UTC] No.42140145[source]▶
Podman actually works really well. Out-of-the-box virtually-no-configuration-needed rootless containers. It's also usable via docker-compose with a single env variable. (podman-compose wasn't up to par for us)

We've been using it for a couple of years running and managing hundreds of containers per server - no feeling of flakiness whatsoever. It's virtually zeroconf and even supports GPUs for those who need it. It's like docker but better, IMO.

Hope it gets a popularity boost from CNCF. Rooting for it.

replies(14): >>42140324 #>>42140486 #>>42140492 #>>42140544 #>>42140660 #>>42140768 #>>42141042 #>>42141174 #>>42141341 #>>42142569 #>>42142974 #>>42150237 #>>42151540 #>>42155624 #
bityard ◴[14 Nov 24 20:11 UTC] No.42140660[source]▶
> It's also usable via docker-compose

Is that "docker-compose" (with a dash) or "docker compose" (with a space)?

replies(2): >>42140940 #>>42151448 #
whilenot-dev ◴[14 Nov 24 20:38 UTC] No.42140940[source]▶
Both should do exacly the same, they are just installed differently. docker compose is installed as docker CLI plugin (Linux only), and docker-compose is installed as standalone binary.

See ref: https://docs.docker.com/compose/install/#scenario-two-instal...

replies(1): >>42141011 #
1. tristan957 ◴[14 Nov 24 20:44 UTC] No.42141011[source]▶
There are subtle differences between the two and not exactly the same.
replies(1): >>42141040 #
2. whilenot-dev ◴[14 Nov 24 20:47 UTC] No.42141040[source]▶
That would be news to me, as both are pointing to the exact same GitHub repository[0]. Can you name the differences?

[0]: https://github.com/docker/compose

replies(1): >>42142498 #
3. thangngoc89 ◴[14 Nov 24 23:41 UTC] No.42142498[source]▶
Previous docker-compose was a separate program, written in Python if I remember correctly, people usually preferred to them as v1. Later docker incorporated it into the docker binary itself as a subcommand so that’s v2
replies(1): >>42144443 #
4. whilenot-dev ◴[15 Nov 24 06:43 UTC] No.42144443{3}[source]▶
v2 is still a separate binary, it can just be installed in different ways (on Linux). If GGGP was referring to v1, then that's legacy software since 2+ years and they probably shouldn't use it.
replies(1): >>42144545 #
5. yjftsjthsd-h ◴[15 Nov 24 07:03 UTC] No.42144545{4}[source]▶
The one problem I previously hit was that the ansible integration used the Python version; I hope they've fixed it now but haven't looked lately.
replies(1): >>42144663 #
6. whilenot-dev ◴[15 Nov 24 07:30 UTC] No.42144663{5}[source]▶
Looks like v2 is available: https://galaxy.ansible.com/ui/repo/published/community/docke...
replies(1): >>42149507 #
7. yjftsjthsd-h ◴[15 Nov 24 18:26 UTC] No.42149507{6}[source]▶
On the I've hand: that's great news!

On the other:

> The Docker compose CLI plugin has no stable output format (see for example https://github.com/docker/compose/issues/10872 ), and for the main operations also no machine friendly output format. The module tries to accomodate this with various version-dependent behavior adjustments and with testing older and newer versions of the Docker compose CLI plugin. Currently the module is tested with multiple plugin versions between 2.18.1 and 2.23.3. The exact list of plugin versions will change over time. New releases of the Docker compose CLI plugin can break this module at any time.