3 ms·

Due to security concerns of enabling user namespaces[1], I don't run rootless podman containers any more, and my current podman use on my workstation is to run

Due to security concerns of enabling user namespaces[1], I don't run rootless podman containers any more, and my current podman use on my workstation is to run rootful podman containers inside a VM (KVM with virt-manager, actually running Proxmox, which does nested virtualization for podman VM[2].), and configures those containers as systemd services with ansible. I'd really rather just use docker-compose (or a 100% UI clone like podman-compose), but for me the whole point of using podman was to limit the API attack vector, and using the single process model, so introducing the docker API into podman isn't really what I wanted either. (podman-compose doesn't need the API but theres other reasons I haven't used that.) I think though, you can't really replace docker with podman (without docker API) in a general sense. You just have to treat it as its own container platform. It will work for certain docker containers you've tested reliably, but if you regularly test out random container stuff you will run into problems on a daily basis. But you can use podman for new container development (because you're the one implementing it and avoiding the problems) that will also be compatible with docker. Configuring Traefik on podman has been painful[3] because it relies upon docker labels for configuration discovery (you can still write a static config file without discovery, but gets tedious), and now that there is docker API support it works, maybe no one cares to have a true dockerless podman Traefik provider, but I think that would be neat, and can probably be written with the new providers plugins[4] [1] https://news.ycombinator.com/item?id=28393949 https://news.ycombinator.com/item?id=28393949 [2] https://blog.rymcg.tech/tags/proxmox https://blog.rymcg.tech/tags/proxmox [3] https://github.com/traefik/traefik/issues/5730 https://github.com/traefik/traefik/issues/5730 [4] https://github.com/traefik/pluginproviderdemo https://github.com/traefik/pluginproviderdemo

KronisLV 5y ago
> ...and my current podman use on my workstation is to run rootful podman containers inside a VM... This makes me feel that perhaps we're slowly moving in the direction of a full circle, to how Docker Toolbox worked inside of VirtualBox, at least on Windows: https://docs.docker.com/toolbox/ https://docs.docker.com/toolbox/ Here's an example of someone's experience with setting it up: https://medium.com/@peorth/using-docker-with-virtualbox-and-windows-10-b351e7a34adc https://medium.com/@peorth/using-docker-with-virtualbox-and-... The industry seems to be slowly advancing, with Podman, Docker with HyperV and now with WSL2 integration, all just to solve the hard permission and runtime problem, whereas the actual OCI standard and the tooling that Docker provides for getting things up and running (environment variables, resource limits, exposing ports etc., with a few warts here and there) was sufficient from the beginning for the most part. > I think though, you can't really replace docker with podman (without docker API) in a general sense. With this, i agree, but perhaps i've ended up with a different set of conclusions. Docker and the tools like it are good for deploying applications in a mostly reproducible way and essentially solving the dependency management issue in a sub-optimal yet passable way. Because of all of the tools solving this problem and it oftentimes being a chief concern for it being chosen, all else becomes secondary, short of pressing issues like exploits and such. To that end, Docker inside of a VM, with separate VMs for separate apps and separate clusters for separate environments seems like the least painful option - decent security, somewhat limited attack surface, not relying on just one technology to be secure (even Podman has its exploits), but with the wide support that Docker has. For example, you could have your project, which has a few front end containers, a few various services for the back end and a few databases, also in containers. You could essentially have 1 VM per environment with all of those running (development, testing, accept testing) in the less important deployments, but have as many VMs and servers as you need for the important ones (staging, production). Then, have separate container clusters (with something like Docker Swarm) for your development environments and the production ones and you should be good. Sometimes the path of least resistance isn't all that bad. At least until Podman is stable enough to be a daily driver, be it in 5 years, 10 years or never.
- EnigmaCurry 5y ago
  yea, I've mostly come to the same conclusion, podman is a hobby, I can see its potential, so I actively track it, but I I mostly do stuff with vanilla docker and docker-compose, for single one-off installs, and k8s for bigger distributed stuff, either in a VM locally, or on a DigitalOcean dropet(s). I've been collecting my compose files [1] [1] https://github.com/EnigmaCurry/d.rymcg.tech https://github.com/EnigmaCurry/d.rymcg.tech

KronisLV 5y ago

> ...and my current podman use on my workstation is to run rootful podman containers inside a VM... This makes me feel that perhaps we're slowly moving in the direction of a full circle, to how Docker Toolbox worked inside of VirtualBox, at least on Windows: https://docs.docker.com/toolbox/ https://docs.docker.com/toolbox/ Here's an example of someone's experience with setting it up: https://medium.com/@peorth/using-docker-with-virtualbox-and-windows-10-b351e7a34adc https://medium.com/@peorth/using-docker-with-virtualbox-and-... The industry seems to be slowly advancing, with Podman, Docker with HyperV and now with WSL2 integration, all just to solve the hard permission and runtime problem, whereas the actual OCI standard and the tooling that Docker provides for getting things up and running (environment variables, resource limits, exposing ports etc., with a few warts here and there) was sufficient from the beginning for the most part. > I think though, you can't really replace docker with podman (without docker API) in a general sense. With this, i agree, but perhaps i've ended up with a different set of conclusions. Docker and the tools like it are good for deploying applications in a mostly reproducible way and essentially solving the dependency management issue in a sub-optimal yet passable way. Because of all of the tools solving this problem and it oftentimes being a chief concern for it being chosen, all else becomes secondary, short of pressing issues like exploits and such. To that end, Docker inside of a VM, with separate VMs for separate apps and separate clusters for separate environments seems like the least painful option - decent security, somewhat limited attack surface, not relying on just one technology to be secure (even Podman has its exploits), but with the wide support that Docker has. For example, you could have your project, which has a few front end containers, a few various services for the back end and a few databases, also in containers. You could essentially have 1 VM per environment with all of those running (development, testing, accept testing) in the less important deployments, but have as many VMs and servers as you need for the important ones (staging, production). Then, have separate container clusters (with something like Docker Swarm) for your development environments and the production ones and you should be good. Sometimes the path of least resistance isn't all that bad. At least until Podman is stable enough to be a daily driver, be it in 5 years, 10 years or never.

EnigmaCurry 5y ago
yea, I've mostly come to the same conclusion, podman is a hobby, I can see its potential, so I actively track it, but I I mostly do stuff with vanilla docker and docker-compose, for single one-off installs, and k8s for bigger distributed stuff, either in a VM locally, or on a DigitalOcean dropet(s). I've been collecting my compose files [1] [1] https://github.com/EnigmaCurry/d.rymcg.tech https://github.com/EnigmaCurry/d.rymcg.tech