5 ms·

Does anyone have resources or advice for someone interested in podman as a replacement for docker-compose? There is a lot I like about podman but my previous ex

Does anyone have resources or advice for someone interested in podman as a replacement for docker-compose? There is a lot I like about podman but my previous exposure to kubernetes felt extremely complicated for my use cases. Most of the time my docker-compose projects only need to run on one or two machines without much horizontal scaling or fault tolerance and portability/ease of spin-up are more important than high 9s edge cases. If that's my use case should I just stick with docker-compose, or does podman simplify kubernetes config enough that its worth considering the switch? I'd like the flexibility of being able to deploy to a k8s cluster if the cost is cheap in terms of mental overhead and how easy it is for another developer to pick up and run with.

unethical_ban 3y ago
https://developers.redhat.com/e-books/podman-action https://developers.redhat.com/e-books/podman-action
worldsayshi 3y ago
I'm not sure how podman fits into this thought but I feel what's needed to make kubernetes as easy to use as docker-compose is a bunch of sane defaults for things that you mostly don't want to care about for smaller projects. And then maybe an option to easily "eject" the configuration when the project grows. There has to be some attempt at this right?
- vbezhenar 3y ago
  Can you clarify what's hard about using kubernetes for smaller projects and what do you want to omit?
  - jasonjayr 3y ago
    helm + go-templating in YAML is pure madness. I've found k8s more manageable with straight manifests, or tooling to generate the manifests from some other source. I do need to give jsonnet a hard look, as I hear it's less crazy than yaml+templates
    - vbezhenar 3y ago
      You definitely don't have to use helm and go-templating for small projects. I never used it (other than from the user side to install 3-rd party software). Just ordinary yamls is absolutely fine. Kustomize might be useful for configmaps and secrets, but that's a small layer of complexity. What I want to try to generate yamls is to write typescript code. Emitting JSON is natural in typescript. Adding types for schema compliance is doable. And then you've got full typescript power on top of it to remove any kind of duplication.
      - jasonjayr 3y ago
        I agree with that approach, and it's one I want to try as well. I'm an old Perl guy, but the transition to being a JS/TS native to use modern interfaces + toolings has proven a pretty straightforward path, especially with nodejs systems side for scripts and what not. The 'declarative' nature of YAML + configuration for defining infrastructure is definitely a good thing, but the tooling for producing those declarations are in a very rough state. I think a "TS => YAML => git => deploy" workflow for deployments could make using K8S a breeze, especially if there is a sensible library in TS that could provide the base classes for manifests, that could be subclassed or wrapped with defaults + definitions for the local environment
        mksybr 3y ago
        Sounds like cdk8s+ https://cdk8s.io/docs/latest/plus/ https://cdk8s.io/docs/latest/plus/
        jasonjayr 3y ago
        Thanks for that pointer, that does look excellent
    - tao_at_garden 3y ago
      There's a number of solutions. One is to use a maintained Helm Library Chart that exposes all the values most could ever want like The Helmet [1]. The other is to move over to something like Timoni that is analogous to Helm but with better templating [2]. [1] https://github.com/companyinfo/helm-charts/tree/main/charts/helmet https://github.com/companyinfo/helm-charts/tree/main/charts/... [2] https://timoni.sh/comparison/ https://timoni.sh/comparison/
  - worldsayshi 3y ago
    Perhaps I'm biased by working on mostly big projects. I haven't tried a very small project recently so I might be on thin ice. The thing that I would expect would be a bit complicated in a small project is networking rules, load balancing, mounting directory from host. That kind of thing.
    - vbezhenar 3y ago
      Kubernetes networking requires installing CNI plugin. Something simple like flannel will work fine and does not require any configuration. That's the only required addon for kubernetes, I think. With docker you'll probably bind container port to the host. With kubernetes you can create Service of type NodePort and it's exactly the same. Load balancing: I'm not really sure what do you mean, what do you use for docker load balancing? Just expose your kubernetes host to the Internet and that's about it. Or hide it behind separate reverse proxy, if you want. Mounting directory from the host is supported with kubernetes, no problems here. Use hostPath volume in the pod spec.
      - ofrzeta 3y ago
        Besides CNI networking potentially encompasses Services, Endpoints/Slices, Load Balancers, Ingresses and most recently the Gateway API. I'd say that's quite a bit complex.
        vbezhenar 3y ago
        Kubernetes allows you to make complex networking, which is especially useful for cluster setups involving multiple nodes. But if you're comparing kubernetes with docker, docker does not have load balancers, ingresses, so you can just skip it, if you feel that it's too much of complexity. They're not mandatory.
  - dboreham 3y ago
    k8s is a kit of (very useful) parts imho. The abstractions it presents are not human-usable. It needs some layer that adapts concepts that make intuitive sense to a human to its internal model. e.g. Vercel. You can make a tool for example that will deploy compose files onto a k8s cluster, and that thing will be totally useable by someone who already understands k8s. But give them raw k8s and they will spend a month scratching their head.
    - zinclozenge 3y ago
      Are you talking about pods/deployments/etc or lower level abstractions like informers and things like that?
    - vbezhenar 3y ago
      Abstractions are absolutely human-usable. My only issue is overly verbose yamls, but some people might even find it a good thing.
  - enragedcacti 3y ago
    It's been a while but iirc my primary issues weren't about configuring a small project, it was the effort of setting up and administering a k8s cluster that was the problem. With docker-compose you realize you need a persistent volume and go "volumes: ..." and you're good. With your own k8s cluster you go, "okay I need a persistentVolumeClaim to a PersistentVolume with a particular StorageClass that my cluster needs to offer". Then you go learn the "Right Way" to set up a StorageClass and 2 hours later you finally have a persistent volume. Repeat every time you try to do something that would be one line in a docker-compose file. If you have easy access to an administered k8s cluster then kubernetes becomes way more approachable. What would be ideal for me is an offering that presents itself as a batteries included k8s cluster running on your local machine. That way I could make pod definitions and run them without having to understand k8s internals while gaining the option of deploying on a real cluster in the future.
    - vbezhenar 3y ago
      Setting up kubernetes is easy with kubeadm. There are other distros like k3s, but I don't have personal experience with them. For storage, just use hostpath volume and that's about it. You don't need to deal with PersistentVolumes at all. I never used named docker volumes, honestly, and I don't understand why they're useful, I always prefer to explicitly specify disk location, so I can back it up, etc. PersistentVolumes are useful, when you have separate storage system and full-fledged multi-node cluster, but for simple setup, there's nothing wrong with hostpath volume, IMO. Just don't forget about backups.
- lancetipton 3y ago
  I would recommend https://www.devspace.sh https://www.devspace.sh I use for just about everything. It also works well as a good gateway into the kubernetes world when coming from docker compose.
- mieubrisse 3y ago
  We're trying to do this at Kurtosis! (https://github.com/kurtosis-tech/kurtosis https://github.com/kurtosis-tech/kurtosis) The idea is to write your environment in Starlark (a minimal Python subset) and we'll handle running it on Docker or Kubernetes for you. We started with "reduce Kubernetes complexity" so we don't yet have the full Kubernetes ejection seat, but we're slowly marching towards it - feedback welcome!
R0flcopt3r 3y ago
podman can't replace docker-compose. it can only replace docker. if you install podman-docker any docker command you run will be translated to a podman command. I think that should work when you run docker-compose as well.
- pydry 3y ago
  It's not quite enough. You also have to run a server too - docker-compose won't run without a docker service running. podman-compose will and it behaves more or less the same way but it's quite a neglected piece of software - lots of bugs, lots of open PRs. A lot of people talk about quadlets or k8s as alternatives but I don't think these are generally good substitutes for compose.
  - _cenw 3y ago
    If your distro is relatively recent, enable podman.socket (available as system and user unit) and things should just work as they do with docker. You may have to set CONTAINER_HOST though, and the new Docker CLI has the concept of contexts where you need to point the CLI at the right socket, but confusingly using docker as a library does not automatically add contexts as functionality, so Tools like flyctl (from fly.io) and melange (chainguard's APK builder) may still need CONTAINER_HOST anyway...
    - pydry 3y ago
      at some point it's easier to just use docker
      - _cenw 3y ago
        other tools prefering to use CONTAINER_HOST instead of docker contexts happens without podman too, because docker didn't build contexts into their go client library and it's instead all in the docker CLI.
    - CoolCold 3y ago
      can you please clarify, from technical perspective > enable podman.socket (available as system and user unit) Won't it make podman be daemon then if it'd be activated by socket? Won't such a daemon be run as root then to be able to handle creation of networks/ports forwardings/multiple-users?
zamaterian 3y ago
This article describes using podman with a pod containing multiple containers. https://www.redhat.com/sysadmin/compose-podman-pods https://www.redhat.com/sysadmin/compose-podman-pods
boudin 3y ago
You can actually use podman as a backend for docker-compose If you install docker-compose, podman and enable the podman service, it does work quite well. If you also install podman-docker you basically can run: `docker-compose`, `docker compose` or `podman compose`, all three will leverage podman in the backend. I use it with podman rootless and I'm quite happy with it.
- arcanemachiner 3y ago
  I wasn't able to get podman + docker compose working after they upgraded docker-compose from Python to Go. Does everything work for you with the newest versions?
  - boudin 3y ago
    All good now, it was an issue for a bit indeed. The only thing not compatible that I know off is buildkit so you have to make sure it's disabled, they do seem to plan to implement buildkit APIs but it's not done yet
- papichulo2023 3y ago
  Is docker-compose python version still supported? I thought they moved everything to docker and rewrote in Go.
  - boudin 3y ago
    Not sure if the python version is still supported, i'm using the v2 (go based)
raphinou 3y ago
Genuine question: I'm curious to know why you deploy with docker-compose and not Docker swarm (eg like described at https://dockerswarm.rocks/ https://dockerswarm.rocks/ ). I'm deploying the same kind of apps, and ended up with Swarm which seems to fit perfectly. I also found Kubernetes much too complex for my use case. Curious to know why we ended up with different outcomes. Btw, I also use Compose, but for local runs (of other apps).
- dboreham 3y ago
  Nobody uses Swarm. Everyone understands compose, all projects ship with compose files.
  - lbhdc 3y ago
    Do they? I have never actually seen that. Do you have examples?
  - jve 3y ago
    Swarm reuses docker compose files... By looking at HN activity on docker swarm, I can see many good comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=docker%20swarm&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
  - raphinou 3y ago
    Docker Swarm uses compose files too. Swarm is still used and maintained, though I agree it is much smaller than k8s. But that's not a reason to dismiss it I think. I went for it because it's so easy to use that if I need to migrate off of it, I would not loose a lot of investment in it anyway.
- enragedcacti 3y ago
  I'm sure swarm would work for what I need and rationally its probably worth using, but I only trust docker as far as I could throw them and if I needed to really deploy I would probably just suck it up and figure out k8s.
luoc 3y ago
My podman installations (Mac, Fedora) both ship the compose subcommand which works as expected. See https://podman-desktop.io/docs/compose https://podman-desktop.io/docs/compose

unethical_ban 3y ago

https://developers.redhat.com/e-books/podman-action https://developers.redhat.com/e-books/podman-action

worldsayshi 3y ago

I'm not sure how podman fits into this thought but I feel what's needed to make kubernetes as easy to use as docker-compose is a bunch of sane defaults for things that you mostly don't want to care about for smaller projects. And then maybe an option to easily "eject" the configuration when the project grows. There has to be some attempt at this right?

vbezhenar 3y ago
Can you clarify what's hard about using kubernetes for smaller projects and what do you want to omit?
- jasonjayr 3y ago
  helm + go-templating in YAML is pure madness. I've found k8s more manageable with straight manifests, or tooling to generate the manifests from some other source. I do need to give jsonnet a hard look, as I hear it's less crazy than yaml+templates
  - vbezhenar 3y ago
    You definitely don't have to use helm and go-templating for small projects. I never used it (other than from the user side to install 3-rd party software). Just ordinary yamls is absolutely fine. Kustomize might be useful for configmaps and secrets, but that's a small layer of complexity. What I want to try to generate yamls is to write typescript code. Emitting JSON is natural in typescript. Adding types for schema compliance is doable. And then you've got full typescript power on top of it to remove any kind of duplication.
    - jasonjayr 3y ago
      I agree with that approach, and it's one I want to try as well. I'm an old Perl guy, but the transition to being a JS/TS native to use modern interfaces + toolings has proven a pretty straightforward path, especially with nodejs systems side for scripts and what not. The 'declarative' nature of YAML + configuration for defining infrastructure is definitely a good thing, but the tooling for producing those declarations are in a very rough state. I think a "TS => YAML => git => deploy" workflow for deployments could make using K8S a breeze, especially if there is a sensible library in TS that could provide the base classes for manifests, that could be subclassed or wrapped with defaults + definitions for the local environment
      - mksybr 3y ago
        Sounds like cdk8s+ https://cdk8s.io/docs/latest/plus/ https://cdk8s.io/docs/latest/plus/
        jasonjayr 3y ago
        Thanks for that pointer, that does look excellent
  - tao_at_garden 3y ago
    There's a number of solutions. One is to use a maintained Helm Library Chart that exposes all the values most could ever want like The Helmet [1]. The other is to move over to something like Timoni that is analogous to Helm but with better templating [2]. [1] https://github.com/companyinfo/helm-charts/tree/main/charts/helmet https://github.com/companyinfo/helm-charts/tree/main/charts/... [2] https://timoni.sh/comparison/ https://timoni.sh/comparison/
- worldsayshi 3y ago
  Perhaps I'm biased by working on mostly big projects. I haven't tried a very small project recently so I might be on thin ice. The thing that I would expect would be a bit complicated in a small project is networking rules, load balancing, mounting directory from host. That kind of thing.
  - vbezhenar 3y ago
    Kubernetes networking requires installing CNI plugin. Something simple like flannel will work fine and does not require any configuration. That's the only required addon for kubernetes, I think. With docker you'll probably bind container port to the host. With kubernetes you can create Service of type NodePort and it's exactly the same. Load balancing: I'm not really sure what do you mean, what do you use for docker load balancing? Just expose your kubernetes host to the Internet and that's about it. Or hide it behind separate reverse proxy, if you want. Mounting directory from the host is supported with kubernetes, no problems here. Use hostPath volume in the pod spec.
    - ofrzeta 3y ago
      Besides CNI networking potentially encompasses Services, Endpoints/Slices, Load Balancers, Ingresses and most recently the Gateway API. I'd say that's quite a bit complex.
      - vbezhenar 3y ago
        Kubernetes allows you to make complex networking, which is especially useful for cluster setups involving multiple nodes. But if you're comparing kubernetes with docker, docker does not have load balancers, ingresses, so you can just skip it, if you feel that it's too much of complexity. They're not mandatory.
- dboreham 3y ago
  k8s is a kit of (very useful) parts imho. The abstractions it presents are not human-usable. It needs some layer that adapts concepts that make intuitive sense to a human to its internal model. e.g. Vercel. You can make a tool for example that will deploy compose files onto a k8s cluster, and that thing will be totally useable by someone who already understands k8s. But give them raw k8s and they will spend a month scratching their head.
  - zinclozenge 3y ago
    Are you talking about pods/deployments/etc or lower level abstractions like informers and things like that?
  - vbezhenar 3y ago
    Abstractions are absolutely human-usable. My only issue is overly verbose yamls, but some people might even find it a good thing.
- enragedcacti 3y ago
  It's been a while but iirc my primary issues weren't about configuring a small project, it was the effort of setting up and administering a k8s cluster that was the problem. With docker-compose you realize you need a persistent volume and go "volumes: ..." and you're good. With your own k8s cluster you go, "okay I need a persistentVolumeClaim to a PersistentVolume with a particular StorageClass that my cluster needs to offer". Then you go learn the "Right Way" to set up a StorageClass and 2 hours later you finally have a persistent volume. Repeat every time you try to do something that would be one line in a docker-compose file. If you have easy access to an administered k8s cluster then kubernetes becomes way more approachable. What would be ideal for me is an offering that presents itself as a batteries included k8s cluster running on your local machine. That way I could make pod definitions and run them without having to understand k8s internals while gaining the option of deploying on a real cluster in the future.
  - vbezhenar 3y ago
    Setting up kubernetes is easy with kubeadm. There are other distros like k3s, but I don't have personal experience with them. For storage, just use hostpath volume and that's about it. You don't need to deal with PersistentVolumes at all. I never used named docker volumes, honestly, and I don't understand why they're useful, I always prefer to explicitly specify disk location, so I can back it up, etc. PersistentVolumes are useful, when you have separate storage system and full-fledged multi-node cluster, but for simple setup, there's nothing wrong with hostpath volume, IMO. Just don't forget about backups.
lancetipton 3y ago
I would recommend https://www.devspace.sh https://www.devspace.sh I use for just about everything. It also works well as a good gateway into the kubernetes world when coming from docker compose.
mieubrisse 3y ago
We're trying to do this at Kurtosis! (https://github.com/kurtosis-tech/kurtosis https://github.com/kurtosis-tech/kurtosis) The idea is to write your environment in Starlark (a minimal Python subset) and we'll handle running it on Docker or Kubernetes for you. We started with "reduce Kubernetes complexity" so we don't yet have the full Kubernetes ejection seat, but we're slowly marching towards it - feedback welcome!

R0flcopt3r 3y ago

podman can't replace docker-compose. it can only replace docker. if you install podman-docker any docker command you run will be translated to a podman command. I think that should work when you run docker-compose as well.

pydry 3y ago
It's not quite enough. You also have to run a server too - docker-compose won't run without a docker service running. podman-compose will and it behaves more or less the same way but it's quite a neglected piece of software - lots of bugs, lots of open PRs. A lot of people talk about quadlets or k8s as alternatives but I don't think these are generally good substitutes for compose.
- _cenw 3y ago
  If your distro is relatively recent, enable podman.socket (available as system and user unit) and things should just work as they do with docker. You may have to set CONTAINER_HOST though, and the new Docker CLI has the concept of contexts where you need to point the CLI at the right socket, but confusingly using docker as a library does not automatically add contexts as functionality, so Tools like flyctl (from fly.io) and melange (chainguard's APK builder) may still need CONTAINER_HOST anyway...
  - pydry 3y ago
    at some point it's easier to just use docker
    - _cenw 3y ago
      other tools prefering to use CONTAINER_HOST instead of docker contexts happens without podman too, because docker didn't build contexts into their go client library and it's instead all in the docker CLI.
  - CoolCold 3y ago
    can you please clarify, from technical perspective > enable podman.socket (available as system and user unit) Won't it make podman be daemon then if it'd be activated by socket? Won't such a daemon be run as root then to be able to handle creation of networks/ports forwardings/multiple-users?

zamaterian 3y ago

This article describes using podman with a pod containing multiple containers. https://www.redhat.com/sysadmin/compose-podman-pods https://www.redhat.com/sysadmin/compose-podman-pods

boudin 3y ago

You can actually use podman as a backend for docker-compose If you install docker-compose, podman and enable the podman service, it does work quite well. If you also install podman-docker you basically can run: `docker-compose`, `docker compose` or `podman compose`, all three will leverage podman in the backend. I use it with podman rootless and I'm quite happy with it.

arcanemachiner 3y ago
I wasn't able to get podman + docker compose working after they upgraded docker-compose from Python to Go. Does everything work for you with the newest versions?
- boudin 3y ago
  All good now, it was an issue for a bit indeed. The only thing not compatible that I know off is buildkit so you have to make sure it's disabled, they do seem to plan to implement buildkit APIs but it's not done yet
papichulo2023 3y ago
Is docker-compose python version still supported? I thought they moved everything to docker and rewrote in Go.
- boudin 3y ago
  Not sure if the python version is still supported, i'm using the v2 (go based)

raphinou 3y ago

Genuine question: I'm curious to know why you deploy with docker-compose and not Docker swarm (eg like described at https://dockerswarm.rocks/ https://dockerswarm.rocks/ ). I'm deploying the same kind of apps, and ended up with Swarm which seems to fit perfectly. I also found Kubernetes much too complex for my use case. Curious to know why we ended up with different outcomes. Btw, I also use Compose, but for local runs (of other apps).

dboreham 3y ago
Nobody uses Swarm. Everyone understands compose, all projects ship with compose files.
- lbhdc 3y ago
  Do they? I have never actually seen that. Do you have examples?
- jve 3y ago
  Swarm reuses docker compose files... By looking at HN activity on docker swarm, I can see many good comments: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=docker%20swarm&sort=byDate&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
- raphinou 3y ago
  Docker Swarm uses compose files too. Swarm is still used and maintained, though I agree it is much smaller than k8s. But that's not a reason to dismiss it I think. I went for it because it's so easy to use that if I need to migrate off of it, I would not loose a lot of investment in it anyway.
enragedcacti 3y ago
I'm sure swarm would work for what I need and rationally its probably worth using, but I only trust docker as far as I could throw them and if I needed to really deploy I would probably just suck it up and figure out k8s.

luoc 3y ago

My podman installations (Mac, Fedora) both ship the compose subcommand which works as expected. See https://podman-desktop.io/docs/compose https://podman-desktop.io/docs/compose