6 ms·

Does anyone have experience “migrating” from docker to podman on a somewhat large scale? I am starting a new job soon in a DevOps role where the devs use both p

Does anyone have experience “migrating” from docker to podman on a somewhat large scale? I am starting a new job soon in a DevOps role where the devs use both podman and docker and although the resulting images are the same, using two tools where one would suffice does not seem optimal. For context, it is a medium-sized (~40 devs) commodities trading company running some hundred applications in azure k8s but considering moving to on-prem k8s.

encryptluks2 4y ago
If you want to do a straight migration you can start the socket unit and expose it via the DOCKER_HOST environment variable and use the standard docker tooling or use podman-docker to make it seamless. As long as you make no other changes everything should just work. Where people frequently run into issues is when they want to utilize the rootless feature, and that definitely requires adjustments and work.
- robinhoodexe 4y ago
  Rootless is definitely one of the major selling points for using podman over docker, especially for local development.
  - Lutger 4y ago
    Isn't there support for rootless docker these days as well?
    - 5e92cb50239222b 4y ago
      I never used it, but have seen separate "rootless" images many times. Seems like you have to build a separate image for rootless Docker? podman runs regular images under an unprivileged user just fine.
      - plonk 4y ago
        You don't need a separate image. You can run a script to install a rootless systemd service that starts the Docker daemon. You just point the Docker client to that rootless daemon's socket and do things as before. You'll need some configuration if you want to expose system ports (below 1024).
- timost 4y ago
  Using DOCKER_HOST and the podman-docker package (Debian and Ubuntu) also makes it really easy to use docker-compose which is more mature and feature-complete than podman-compose.
- itsthejb 4y ago
  If you’re on regular docker and would like to go podman for rootless, you can take the middle step of migrating to rootless docker. Essential step, honestly - it’s significant work to get rootless working (but definitely worth it) Haven’t done so myself yet, but rootless docker to podman ought to be more or less a direct switch
- dbrgn 4y ago
  I agree, rootless was also the main blocker when I attempted my last migration in June. My goal was to run all my Docker containers as rootless Podman containers through systemd. The first service I ported was single-container, which made it easier. Still quite some work (like manually adjusting the podman-generated unit file, tracking down some weird-looking error messages, etc), but doable. Once you get to multi-container setups, I ran into even more issues (IIRC related to the linking of containers through a network, while staying rootless), so I gave up for the moment and started a Docker daemon for the rest of the services...
lmeyerov 4y ago
We got burned hard last year around GPUs (ai) and compose being not ready for enterprise settings for technical and redhat politics reasons, which are top use cases in the wild. Networking also looked problematic. We hadn't tried k8s for podman, which likely has its own issues. So defaulting to docker would be the less risky bet and relegate podman to opt-in by trailblazers. Podman core development is impressive, so frustrating to see the broader ecosystem issues.
koprulusector 4y ago
On-prem k8s is almost always a bad idea. Things like storage or traffic routing become uncertain/hacky at best or at worst just straight up don’t work. I’ve literally seen many on-prem k8s deployments where there was no support for persistent volume claims because of storage - whether the enterprise storage solution wasn’t supported by k8s or because there was no way to guarantee storage (HDDs being a capital expense and therefore purchased ahead of time). Examples of friction off the top of my head: * storage - who knows if there’s actually enough space to provision and attach a volume * exposing a service externally * load balancers managed by a different team (such as networking) and their process or tech environment not setup to support k8s * certificates need to be requested and signed by approved enterprise certificate authority * network security restrictions - lengthy process for firewall change requests or similar to expose a service externally (also related to point above on certificates) I’ve also seen silly deployments where k8s runs inside VMware virtual machines - why not just run k8s directly on hardware if on-prem? Virtual machines just add a ton of unnecessary and expensive overhead. Personally, my preferred way of doing k8s: 1. GKE (Google Kubernetes Engine) - the easiest and cheapest managed option 2. kops Hot take here but I personally think EKS is convoluted and complicated as hell. I’ve not used AKS but in the past I’ve seen limitations such as network configuration that became problematic - couldn’t route traffic properly because IP space overlapped with corporate IP ranges already used by VPN and/or existing vnets, though it’s been a couple years since I first saw this specific example.
- dilyevsky 4y ago
  1. Just pay the vendor. Diy csi is also an option 2. MetallB. Not sure how cert thing applies here… 3. vmware based vms are to manage underlying node image so that you dont have to mess with ipmi/ipxe that often. They can also make networking easier

encryptluks2 4y ago

If you want to do a straight migration you can start the socket unit and expose it via the DOCKER_HOST environment variable and use the standard docker tooling or use podman-docker to make it seamless. As long as you make no other changes everything should just work. Where people frequently run into issues is when they want to utilize the rootless feature, and that definitely requires adjustments and work.

robinhoodexe 4y ago
Rootless is definitely one of the major selling points for using podman over docker, especially for local development.
- Lutger 4y ago
  Isn't there support for rootless docker these days as well?
  - 5e92cb50239222b 4y ago
    I never used it, but have seen separate "rootless" images many times. Seems like you have to build a separate image for rootless Docker? podman runs regular images under an unprivileged user just fine.
    - plonk 4y ago
      You don't need a separate image. You can run a script to install a rootless systemd service that starts the Docker daemon. You just point the Docker client to that rootless daemon's socket and do things as before. You'll need some configuration if you want to expose system ports (below 1024).
timost 4y ago
Using DOCKER_HOST and the podman-docker package (Debian and Ubuntu) also makes it really easy to use docker-compose which is more mature and feature-complete than podman-compose.
itsthejb 4y ago
If you’re on regular docker and would like to go podman for rootless, you can take the middle step of migrating to rootless docker. Essential step, honestly - it’s significant work to get rootless working (but definitely worth it) Haven’t done so myself yet, but rootless docker to podman ought to be more or less a direct switch
dbrgn 4y ago
I agree, rootless was also the main blocker when I attempted my last migration in June. My goal was to run all my Docker containers as rootless Podman containers through systemd. The first service I ported was single-container, which made it easier. Still quite some work (like manually adjusting the podman-generated unit file, tracking down some weird-looking error messages, etc), but doable. Once you get to multi-container setups, I ran into even more issues (IIRC related to the linking of containers through a network, while staying rootless), so I gave up for the moment and started a Docker daemon for the rest of the services...

lmeyerov 4y ago

We got burned hard last year around GPUs (ai) and compose being not ready for enterprise settings for technical and redhat politics reasons, which are top use cases in the wild. Networking also looked problematic. We hadn't tried k8s for podman, which likely has its own issues. So defaulting to docker would be the less risky bet and relegate podman to opt-in by trailblazers. Podman core development is impressive, so frustrating to see the broader ecosystem issues.

koprulusector 4y ago

On-prem k8s is almost always a bad idea. Things like storage or traffic routing become uncertain/hacky at best or at worst just straight up don’t work. I’ve literally seen many on-prem k8s deployments where there was no support for persistent volume claims because of storage - whether the enterprise storage solution wasn’t supported by k8s or because there was no way to guarantee storage (HDDs being a capital expense and therefore purchased ahead of time). Examples of friction off the top of my head: * storage - who knows if there’s actually enough space to provision and attach a volume * exposing a service externally * load balancers managed by a different team (such as networking) and their process or tech environment not setup to support k8s * certificates need to be requested and signed by approved enterprise certificate authority * network security restrictions - lengthy process for firewall change requests or similar to expose a service externally (also related to point above on certificates) I’ve also seen silly deployments where k8s runs inside VMware virtual machines - why not just run k8s directly on hardware if on-prem? Virtual machines just add a ton of unnecessary and expensive overhead. Personally, my preferred way of doing k8s: 1. GKE (Google Kubernetes Engine) - the easiest and cheapest managed option 2. kops Hot take here but I personally think EKS is convoluted and complicated as hell. I’ve not used AKS but in the past I’ve seen limitations such as network configuration that became problematic - couldn’t route traffic properly because IP space overlapped with corporate IP ranges already used by VPN and/or existing vnets, though it’s been a couple years since I first saw this specific example.

dilyevsky 4y ago
1. Just pay the vendor. Diy csi is also an option 2. MetallB. Not sure how cert thing applies here… 3. vmware based vms are to manage underlying node image so that you dont have to mess with ipmi/ipxe that often. They can also make networking easier