15 ms·

Docker is dead? Podman – an alternative tool?

272 points by F_J_H 4y ago

lolcat_cowsay 4y ago
BTW there's no alternative to docker compose in podman, I've tried running my docker compose file with podman compose and it just failed outright. Currently I'm going to stick with Docker because of this alone.
pid-1 4y ago
Docker for Desktop went from being complete garbage to a really nice product. I think Docker folks are heavily focused on providing great local development experiences, which is a niche few other products are covering.
- teruakohatu 4y ago
  What exactly does Docker for Desktop do? All it seems to me is a slightly annoying non-free GUI application I need to use docker cli from Windows or Mac.
  - oogetyboogety 4y ago
    It has something like a minikube k8s distribution and introduces some compatibility layer for systems without *nix hyper v or wsl
  - kristjansson 4y ago
    Runs docker in a VM for you, abstracts that away, confuses the hell out of new and old developers alike.
    - tasuki 4y ago
      Wasn't the main selling point of docker "no more VMs"?
      - dilyevsky 4y ago
        This is for macs where no container api exists to this day
      - matyasrichter 4y ago
        That's true on Linux, where the container shares the host's kernel. On Windows, they need to create a Linux VM and run the Docker daemon inside it.
      - namaria 4y ago
        IMHO doing development work on any long lived environment (especially if also used for personal internet browsing) is a mistake. Embracing disposable VMs for everything has saved me so much time and headache - just scrap it and start anew. Then my personal compute space remains very simple and debris free.
        tasuki 4y ago
        > Embracing disposable VMs for everything has saved me so much time and headache Yes, but wasn't the main selling point of Docker "no more VMs"? It solves the same issues, without the drawbacks of running virtual machines.
    - KronisLV 4y ago
      > Runs docker in a VM for you It depends: - the Hyper-V backend uses a VM for running the actual containers, which is a bit annoying because it just sits there and eats your RAM whenever it's on (technically you could enable dynamic memory for the VM, but i think it used to break) - the WSL2 backend uses the whole fancy new system that Microsoft came up with to, idk, attempt to embrace and extend Linux or something; far less annoying than Hyper-V but also has somewhat different approaches to setting resource limits (e.g. if you only wnat to give it 4 GB of RAM or 4 CPU cores so something is left for the rest of your system and doesn't slow down when you run docker build) Honestly, Docker on *nix is a way better experience, but not everyone can run it for a variety of reasons (e.g. corporate policy or having the same PC for personal development and gaming).
      - LunaSea 4y ago
        And 2022 is still not the year of the Linux Desktop. Many tried and went back to OSX die to the rough corners of desktop Linux.
        KronisLV 4y ago
        It will probably never be the year of the Linux Desktop in the mainstream, despite many promising projects out there. But for personal usage, Linux is more than acceptable - if you can grokk all of its pain points, that is. Linus Tech Tips did a few videos on the topic recently, it was painful but understandable to watch. Personally, Ubuntu LTS (or equivalent boring long term support distro) or something with XFCE is solid and really usable, especially if you intend to do programming, where things are weird on Windows sometimes. Except for gaming. Proton still has a ways to go and Wine isn't optimal for that sort of stuff and neither Linux or OS X are worth supporting for many games/projects/software because they represent a small part of the total userbase. For example, in regards to games: https://store.steampowered.com/hwsurvey https://store.steampowered.com/hwsurvey Windows 96.68% OSX 2.20% Linux 1.12% Supporting any system that's not Windows for games would be like burning money. At that point, you might as well offer the game for free on those systems (if using an engine like Unity/Unreal/Godot, where builds are easy) but refuse bug reports on them, if you don't have the resources for that kind of support.
- papito 4y ago
  All you really need is "ctop", the "top" for Docker. You can view running and idle containers, start, stop, delete, view logs. https://github.com/bcicen/ctop https://github.com/bcicen/ctop
akagusu 4y ago
Docker is not dead, despite the attempts of Red Hat (and Google) to kill it. The market changed and Docker changed to stay relevant. Just that.
hiroshui 4y ago
Hello, its Maximilian from fme - the author of the linked article. I had vacation when this article blew up and now i am pretty overwhelmed of the discussion that started here! We are very happy that this discussion took place and that it sparked a nice and lively discussion about containers, Docker, Podman and all the other stuff between you and all the other professionals. We are also very grateful for all your criticism and corrections. The article is currently under review and we want to make sure to correct the previous mistakes in a transparent way. Seems like a few valid points were missed and some wrong assumptions were made. Nonetheless, I think the discussion that came out of this helped a lot of people get some useful insights into Docker, Podman, and containerization as a whole. We are trying to get all wrong information - based on your discussion - right and summarize them in the refactored article! What can we take away from this? - More research next time is necessary and we need to challenge our article. Again, thanks a lot for all your feedback! We appreciate it very much! There were a few new things that also I was able to learn in this process which is always nice.
- hiroshui 4y ago
  We just updated the article. Just to let you know :) Have a good one!
studmuffin650 4y ago
Lack of mention of podman machine seems like big miss when talking about podman as an alternative to Docker.
- ravenstine 4y ago
  Wouldn't Lima serve that role? https://github.com/lima-vm/lima https://github.com/lima-vm/lima If memory serves me right, it works with Podman.
  - Havoc 4y ago
    Lima is mentioned in the article.
    - ravenstine 4y ago
      It's mentioned as an alternative, but not as something that works tandem to Podman.
bobobob420 4y ago
docker is far far far far from dead. I frankly do not seeing it going away for a looong time because it is generally a great and well supported product. Theres lots of information on issues and fixes and tons of developers using in across many large corporations
- redisman 4y ago
  Agreed. It’s simple (compared to k8s) and covers most companies needs perfectly well
Havoc 4y ago
Think it is rapidly moving towards being more of a data carrier/format rather than being dead per se. Half the time you're jamming it into some cloud service anyway where you have no idea what GCP/fly/aws is using under the hood to actually run it. Meaning this discussion is more relevant to the self-hosted context. In which case I'd say containerization isn't really security. So in my mind that residual risk of the daemon being root is inconsequential. (Or if not use a VM).
- djbusby 4y ago
  I'm still in the VM all the things camp. Like, containers are neat but VMs have the same cheapness for me - that is deploy some VM per app. Like Docker per app. Many times these days I'm one VM for just one Docker package. (Can you tell VM is my favorite isolation method)
  - jolux 4y ago
    Fargate and Fly are actually both Firecracker VMs, not containers.
    - djbusby 4y ago
      Yea, super fast boot VMs are a game changer in the container vs VM game.
  - LunaSea 4y ago
    I don't think people mind using VMs rather than containers. The preference comes from the tool chain which is simpler for containers (even if you use Vagrant) and performance ( true or not, lots of people still have the sluggish VMs in mind.
    - tluyben2 4y ago
      > lots of people still have the sluggish VMs in mind. I did, until trying firecracker.
  - 4y ago
tragictrash 4y ago
OCI compatible containers are the future, docker and podman both classify as such. https://opencontainers.org/ https://opencontainers.org/ That being said, docker blows. Docker desktop blows more. Docker desktop on Windows blows the most. I always get stuck with a bind mount misbehaving, or some other issue that requires me to wipe the docker desktop data to fix it. Just use docker compose for simple stuff, and stay away from docker for Windows if possible.
- Grimburger 4y ago
  Given that docker modelled the OCI standard on their own software and expected everyone else to follow along, I think it would be nigh impossible for them to not be in compliance with the spec.
- Hamcha 4y ago
  On the Docker for Windows note, it's not podman but after I had trouble with their "forced upgrade unless enterprise" policy (which made me update to a broken version with a known issue they didn't solve for weeks) I switched to Rancher Desktop and never looked back. You get all the things (docker CLI, docker-compose, kubernetes via k3s) but it's FOSS and it doesn't feel like they're trying to shove a premium plan down your throat.
  - astrostl 4y ago
    Loving Rancher Desktop here too, and even w/o making use of k3s at all. Fantastic drop-in replacement for Docker Desktop w/o the garbage.
    - deskamess 4y ago
      Interesting/Great that Rancher Desktop uses WSL - not having to launch a Linux VM (albeit transparent) is nice. I still wish MS would have come up with something native.
- zamalek 4y ago
  > blows. Docker desktop blows more. Docker desktop on Windows blows the most. I see your "Docker blows on Windows" and raise you "Docker blows on M1." At least you have WSL, Apple couldn't give half a fuck (and nor could Docker). Colima has been a lifesaver, but having used WSL Docker in the past and Linux Docker recently (I now favor Podman), M1 Docker is a complete shitshow. I'm slowly infesting our codebase with Podman/Buildah/Skopeo (also because they do things Docker can't), and hopefully we'll get to the point of using podman machine.
jordemort 4y ago
Why not both? Since Podman 4.1 came out with full Compose 2.x compatibility, I'm running Podman on Docker's socket, but using Docker's CLI to talk to it, so that I can use the buildx and compose CLI plugins. It works great, Docker's CLI doesn't seem to have any clue that it's talking to not-Docker. I even have VSCode's Docker extension and Remote Containers working this way.
- deleted 4y ago
  [deleted]
- jcastro 4y ago
  Is there any config to set up this way or do you literally just run podman on the socket and it just knows what to do?
  - piyh 4y ago
    podman replacing the docker socket https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
    - cipherboy 4y ago
      As a fun fact, you can also run: $ systemctl --user enable --now podman.socket $ export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock and get a rootless, Docker-compatible socket. If you're running, e.g., a test suite written against the Go Moby APIs, this will execute the containers with Podman rather than with the system daemon.
  - pkulak 4y ago
    You can set it as systemd socket service, so it doesn’t even run until something tries to connect. That said, I don’t even bother with that. Podman can run K8s configs, and they are yaml too, only slightly more verbose than a compose file, if you strip everything out you don’t need. The CLI is nicer than compose too, with proper commands instead of tying up a terminal until a ctrl-c.
user3939382 4y ago
Does Podman work with ECR/ECS etc the way Docker does?
- lapser 4y ago
  Yes
throwawei369 4y ago
This would all be true if podman wasn't a gimped version of docker.
- encryptluks2 4y ago
  In my experience it is quite the opposite really, a more featureful solution with much more options and safer defaults.
  - bob778 4y ago
    From using podman in prod, it seems to be lots of features but not necessarily stable or well-rounded
    - lapser 4y ago
      Podman isn't supposed to be used in prod servers. It's for local development. It produces OCI compatible images (through Buildah), and you're supposed to use those with a proper container orchestration tool such as K8s, Nomad, Docker Swarm, or whatever else there is.
colordrops 4y ago
NixOS recently switched the default from docker to podman for containers. I don't know if it's Nix's configuration, or a problem with Podman itself, but it's unusable. The systemd service often hangs, creating networks errors out, the pod concept doesn't work great, requiring tearing down the whole group of containers to change port mappings, and it acts like a completely different system depending on the user running the container (though I suppose this last bit is supposedly a feature). Why isn't the list of images global to the machine? Perhaps I just don't get it yet.
- yjftsjthsd-h 4y ago
  > Why isn't the list of images global to the machine? Why would it be? Unless you jump through hoops, your music and photos aren't global to the machine; rootless containers just made containers fit in the traditional unix security model.
- mati365 4y ago
  It's also happening on Debian. Podman seems to be also losing quite often network firewall configuration after killing containers that were using cached images so you are not able to access internet from containers (logs say its libpodman bug)
- bob778 4y ago
  Podman always feel like software no one’s using in prod. There’s a lot of edge cases and bugs - particularly in the service control, user groups and ipv6 support
bdcravens 4y ago
> Podman currently only runs stably on Linux-based systems. Under Windows or MacOS it becomes a bit more demanding, although it is possible with detours. I think this is an area bearing improvement before most dev workflows can switch
- mekster 4y ago
  Why do you need to run docker on Windows or Mac?
  - ByteJockey 4y ago
    Local development, usually.
mati365 4y ago
Have you ever used podman-compose? It's amount of bugs and missing features is bigger than actual features count.
- jdoss 4y ago
  Podman 4.x is pretty great with docker-compose due to its API compat with Docker. Give it a shot.
  - okamiueru 4y ago
    This sort of makes the whole premise confusing to me. The way to use the alternative to the "dead" product is to use the dead product. This isn't a critique of your comment. Just, that I don't understand what's going on here. Maybe this whole issue is a non-Linux kind of thing? Test stuff out with wither docker compose, or minikube, and otherwise deploy to k8s has worked great for me.
qbasic_forever 4y ago
Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root privileged daemon. I really wish rootless podman/docker was the default install now. It's still kind of annoying to setup with reading a smattering of old docs and having to think about your distro setup, cgroups settings, etc. It really should just be a "run this install script and you're done".
- pkulak 4y ago
  The arch wiki is my go to every time I install Podman, and it’s a little easier every time. It’s down to like two steps now, with no file editing. We’ll get there.
- sureglymop 4y ago
  What about UID issues? I remember using it years ago and sometimes having permission issues in containers when mounting local files. How is that nowadays? I much prefer running this in a rootless manner also. What about docker compose? Is there an alternative for podman?
  - stingraycharles 4y ago
    There’s podman-compose which does what you want, but is a community maintained script. There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose. See: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
    - znpy 4y ago
      You can point the official docker-compose at podman now! I do that! It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs. It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me. EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project. Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?
usr1106 4y ago
This article is from a Windows perspective. On Linux podman is significantly different from docker: It uses user namespaces. So it is much more secure (assuming that security bugs related to Linux user namespaces, which have indeed been dicovered, are still much rarer than people running untrusted container images). However, with security comes incompatibility. If the image does tricky system interaction instead of just running user space code and some standard cases like opening a socket chances are that things will not work under podman without modification.
js4ever 4y ago
- matyasrichter 4y ago
  Ok.
- pjmlp 4y ago
  Then there is very little GNU/Linux left to use.
jdoss 4y ago
I only use Podman for my workloads these days. Docker was always a headache for me on Linux. Podman allows me to quickly do whatever I want with containers and I can use systemd or a simple bash script to easily create services on my workstation or in production with Nomad with https://github.com/hashicorp/nomad-driver-podman https://github.com/hashicorp/nomad-driver-podman I am super thankful for the team of developers that work on Podman. It has really come a long way since 2.0 and they are very responsive to issues in my experiences. If you are using Linux as your daily driver and you use Containers give Podman a try. Here are some examples of the things I have done with Podman. https://github.com/forem/selfhost https://github.com/forem/selfhost https://github.com/jdoss/ppngx https://github.com/jdoss/ppngx https://gist.github.com/jdoss/25f9dac0a616e524f8794a89b7989e9f https://gist.github.com/jdoss/25f9dac0a616e524f8794a89b7989e... https://gist.github.com/jdoss/ad87375b776178e9031685b71dbe37cf https://gist.github.com/jdoss/ad87375b776178e9031685b71dbe37...
- mekster 4y ago
  What were the headaches?
  - skrtskrt 4y ago
    Not the poster, but I have to reboot at least one a day to clear up Docker networking/DNS gremlins. I thought moving to Linux from Mac would make Docker better due to the lower resource usage but I would guess the fact that it’s isolated in a VM in Mac is why I never had network issues there
    - bavell 4y ago
      Strange, I work with docker containers nearly every day but usually only reboot once a month.
iknownothow 4y ago
It's okay to stick with Docker if it works for us right? There's nothing fundamentally wrong with it right? At the moment Podman is just more work for us because I and other devs don't have years of of experience and intuitions about Podman like we have with Docker. I'd rather just focus on business problems rather than another migration.
- raesene9 4y ago
  Yep Docker's fine (IMO ofc). If you're running on Linux hosts, then Docker engine is open source, free and works.
- jarek83 4y ago
  Similar feelings here. We use Docker without any issues beyond usual problems of a caliber that I guess any other tool would have. I see some new live in docker desktop and I also have flawless experience on M! Mac with it. I even ignored all recent hype to ditch Docker because it became more transparent tool to my workflow, I forgot I use it.
- zamalek 4y ago
  If you're using it commercially, you are licensed right?
KronisLV 4y ago
Personally, i still find Docker to be the easiest way to get containers up and running - everything from Dockerfiles, building images (caching aside), to running them with Docker Compose, Docker Swarm or even Kubernetes with Docker as the runtime. Why? Docker - one of the older and most popular runtimes for OCI, with all of the tooling you might possibly want; most of the problems are known and solutions are easy to find, vs venturing "off the happy path" (not everyone has the resources to try and figure out Podman compatibility oddness) Docker Compose - ubiquitous and perhaps the easiest way to launch a certain amount of containers on a host, be it a local development machine, or a remote server (in a single node deployment), none of the complexity of Kubernetes, no need for multiple docker run commands either Docker Swarm - most projects out there do not need Kubernetes; personally, i'm too poor to pay for a managed control plane or host my own for a cluster; K3s and k0s are promising alternatives, but Docker Swarm also uses the Compose specification which is far easier to work with and most of the times you can effortlessly setup a docker-compose.yml based stack, to run on multiple nodes, as needed; also, in contrast to Nomad, it comes out of the box, if you have Docker installed; also, when you don't want to mess around with a Kubernetes ingress and somehow feeding certificates into it, you can instead just run your own Apache/Nginx/Caddy instance and manage it like a regular container with host ports 80/443 (setting up which might be a bit more difficult with Kubernetes, because by default you get access to ports upwards of 30000) Kubernetes with Docker as the runtime - maybe with something like K3s, if you need relatively lightweight Kubernetes but also want to figure out what is going on with individual containers through the Docker CLI which is familiar and easy to work with, to dig down vs what something like containerd would let you do Long story short, choose whatever is the best suited solution for your own needs and projects. Just want things to work and be pretty simple, modern technologies, hyperscalability and ecosystem be damned? Docker/Compose/Swarm. Want something with a bit more security and possibly even for running untrusted containers, with lots of scalability and projects built around the technologies? Podman/containerd/Kubernetes. I've heard about Docker and Swarm being dead for years, yet it seems to work just fine. They even fixed the DNS weirdness on RPM distros (RHEL/Oracle Linux) in the 20.X releases i think, though personally i'm more inclined towards using the second-latest Ubuntu LTS because there's far less SELinux or other weirdness to be had (e.g. K3s clusters failing to initialize because of changes to cgroups). When it will actually die for real, i'll just use something like https://kompose.io/ https://kompose.io/ to migrate over from the Compose format to Kubernetes. Of course, none of that excuses you from having to learn Kubernetes, because that's what the industry has decided on. My approach is more akin to basing a new project on PHP 7 because you know that you don't need anything more. On a different note, your employers asking you to setup Kubernetes and to launch Nexus, PostgreSQL and whatever else on a single node that has 8 GB of RAM, as well as run a bunch of Java services on it can be challenging to say the least, especially when the cloud is not in the cards, there are no pre-existing clusters in the org, there isn't the interest to get more resources and even if there was, then there'd also be thoughts along the lines of "why should we give this one project that many resources?" expressed. I'm slightly exaggerating, but oftentimes it can be akin to choosing to run Apache Kafka when RabbitMQ would have sufficed - someone else making the choice for you, pushing you into sub-optimal conditions and making you suffer as a result. I recently went to Europe DevDays 2022 (https://devdays.lt/ https://devdays.lt/) and DevOps Pro Europe 2022 (https://devopspro.lt/ https://devopspro.lt/) and one of the arguments expressed was along the lines of: "You should never host your own clusters, if you can. Just pay one of the big three platforms out there (AWS/GCP/Azure) to do it for you." What a crazy time to be alive, where running the full stack can be problematic and enterprise solutions are getting more and more detached from what smaller deployments and homelabs would actually need. That said, Podman is getting closer and closer to full feature parity with Docker with every passing year and Kubernetes is also easier to run thanks to clusters like K3s/k0s/RKE and tools like Lens/k9s/Portainer/Rancher.
flerp 4y ago
Clickbait title ahoy
lapser 4y ago
This article misses quite a bit. Podman has a full Docker compatible API, so you just have to enable it, and then set the DOCKER_HOST to point to its socket. From there docker compose should work as if you had Docker. Podman also is currently working on "podman machine", which can spin up a Linux VM to run Podman on macOS and Windows. I think it's still in beta or something, but it seems to be working already. There is also things like Podman Desktop[0] and Podman Desktop Companion[1] which attempt to bring an experience similar to Docker Desktop to Podman. [0] https://podman-desktop.io/ https://podman-desktop.io/ [1] https://iongion.github.io/podman-desktop-companion/ https://iongion.github.io/podman-desktop-companion/
- lioeters 4y ago
  About "podman machine": > Podman also runs on Mac and Windows, where it provides a native podman CLI and embeds a guest Linux system to launch your containers. This guest is referred to as a Podman machine and is managed with the `podman machine` command. > ..On Mac, each Podman machine is backed by a QEMU based virtual machine. > ..On Windows, each Podman machine is backed by a virtualized Windows System for Linux (WSLv2) distribution. https://podman.io/getting-started/installation.html https://podman.io/getting-started/installation.html
nanna 4y ago
Wouldn't this be a good time to adopt guix (or nix) for a next generation upgrade on Docker?
- scroot 4y ago
  This is what I'm wondering. These are in some ways simpler systems as well, because containerization is "baked in"
pelorat 4y ago
I just use LXC, it's never failed me and has none of the hype.
- cpach 4y ago
  Can you run OCI containers there?
- hamilyon2 4y ago
  Lxc rocks. It is linux-only, though
  - pxeger1 4y ago
    Containers are a Linux-only feature. Docker Desktop just runs a Linux VM on Windows and macOS. (actually I think Windows Server has some container support now, but it's a totally different system)
- j4hdufd8 4y ago
  LXD is not production ready in my experience. Snap auto updates fucked up many times, for example.
  - EnigmaCurry 4y ago
    Use LXC on Proxmox rather than LXD, very stable.
smarx007 4y ago
How did the intro get so many things wrong?! 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See https://techcrunch.com/2019/11/13/mirantis-acquires-docker-enterprise/ https://techcrunch.com/2019/11/13/mirantis-acquires-docker-e... and https://www.docker.com/blog/docker-enterprise-edition/ https://www.docker.com/blog/docker-enterprise-edition/ 2. k8s didn't remove dockershim for political reasons but because containerd was refactored out of Docker long time ago and k8s wanted to get rid of the extra layer. See https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/ https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o... 3. Rate limits have nothing to do with the container runtime. Podman also has to get images from somewhere. And Cloudfront bills starting at $0.02/GB (assuming you pump 5PB+) have to be paid somehow. The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror. 4. RedHat offers not only packages in RHEL but also support and it makes sense they will offer packaging and support only for podman (a RH project) going forward. This does not concern us who don't pay for RH support. Having said that, Podman is a nice evolution of Docker. Though I am not sure how much I can trust the rest of the article given how the intro twisted so many facts.
- hiroshui 4y ago
  I wrote a comment for the general comment section, but wanted to respond to your comment as it contains valid criticism. 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise... >> You are right. That's a mistake. 2. k8s did'nt remove dockershim for political reason.. >> That is a valid point and the official story. Imho I think the acquisition was nevertheless something that played an accelerating role in this, since it happened relatively soon after the acquisition. Mirantis acquired Docker Enterprise in November 2019, and the end of Dockershim support was announced in 2020. I've heard that from a few other people as well. BUT this is just rumor, so you might be right. 3. Rate limits have nothing to do with the container runtime.. >> This is 100% true. Nevertheless, dockerhub is part of Docker and therefore a rate limit on the official Docker registry is something that has made our customers switch registry to other registry providers or implement their own container registry. Therefore, they are getting rid of this service, which is part of the Docker-only ecosystem, so its usage in enterprises is decreasing. 4. RedHat support switched to Podman as it is on of their products.. >> It only makes sense for RedHat to support Podman since it's from their own product forge. You are right about that. That said, there are a lot of companies using RH and paying for it, which automatically leads to a decrease in Docker usage vs Podman. Less use of Docker means more use of Podman. Last but not least, RedHat would not invent Podman if there was no need for an independent tool to Docker. Podman helps in some areas where Docker lacks features, such as support for pods, rootless mode, etc. Thanks for your criticism! It is appreciated and helps us to do better.
CoolCold 4y ago
Article itself and the idea in general seems controversial at best for me. I could not find answer for myself why Docker is any close to be dead and why Podman is the thing I should use instead of Docker immediately. Q 1. Docker has some policy change and your company may need to pay for it - if you have > 250 persons/10 million revenue A 1: Indi/Solo devs out of scope. Enterprises probably fine with that anyways. Q 2. Docker has limits for pulls from Docker hub!!!! You have 100 (200 with login) downloads/single IP for 6 hours interval. A 2: It was already mentioned, switching to Podman, while using Dockerhub doesn't magically helps. Moreover, practically I find it totally fine for Indi/Solo dev. For companies, who's amount of pulls can be higher - you want and have in place your local registry anyways to ensure Business Continuity and this doesn't bother you much. Q 3. Running no background processes, running rootless is good because of ... A 3: On dev env (your local laptop, for example) you do not care much - your goal is ease of use. On production, running rootless rises question from me: * how you expect firewall (iptables) to be updated for port forwardings? * how you expect networks and bridges organized without root? * how you expect auto restart for container to happen on failure without supervising it? * some security advises and mitigation guides mention disabling user namespaces and was/is disabled by default in some distros https://news.ycombinator.com/item?id=28054823 https://news.ycombinator.com/item?id=28054823 - your security & system administration team may have such limits in place on production * those who care for intruder gets into container and can hijack system further use FireCracker or similar approach anyways [for production] So what is left in "pros" for Podman, have I missed anything?
lloydatkinson 4y ago
How does podman work with giving native access to resources? Like on a raspberry pi with docker you need to tell docker it has the ability to access /sys for the GPIO pins and for I2C etc. does podman have this too?
TheAceOfHearts 4y ago
People complaint about framework or library churn in the JS world, but other ecosystems have the same issue. For people who aren't following this ecosystem closely, I just want something that works and gets out of the way with a minimal learning curve. Navigating fragmented ecosystems sure is a pain... I get that different tools serve different needs, but having to learn a bunch of different things just to figure out which one to use gets really exhausting. Especially when you have to do it for tools at every layer of your stack.
- olingern 4y ago
  JS is a punching bag because it’s a moving target that most everyone has to deal with at some point and pre-ES6 JS had quite a few warts. It’s a fine language now, especially with TypeScript helping to push things in the right direction. I left .NET land for this very reason. JS pales in comparison to .NET framework fatigue
CottonMcKnight 4y ago
The first thing that happens when visiting that site is a modal overlay that forces me to interact with it before I can do anything else, so that website is what's dead, at least to me.
lkxijlewlf 4y ago
So, is Podman to Docker what LXD is to LXC, then?

272 points by F_J_H 4y ago

BTW there's no alternative to docker compose in podman, I've tried running my docker compose file with podman compose and it just failed outright. Currently I'm going to stick with Docker because of this alone.

pid-1 4y ago

Docker for Desktop went from being complete garbage to a really nice product. I think Docker folks are heavily focused on providing great local development experiences, which is a niche few other products are covering.

teruakohatu 4y ago
What exactly does Docker for Desktop do? All it seems to me is a slightly annoying non-free GUI application I need to use docker cli from Windows or Mac.
- oogetyboogety 4y ago
  It has something like a minikube k8s distribution and introduces some compatibility layer for systems without *nix hyper v or wsl
- kristjansson 4y ago
  Runs docker in a VM for you, abstracts that away, confuses the hell out of new and old developers alike.
  - tasuki 4y ago
    Wasn't the main selling point of docker "no more VMs"?
    - dilyevsky 4y ago
      This is for macs where no container api exists to this day
    - matyasrichter 4y ago
      That's true on Linux, where the container shares the host's kernel. On Windows, they need to create a Linux VM and run the Docker daemon inside it.
    - namaria 4y ago
      IMHO doing development work on any long lived environment (especially if also used for personal internet browsing) is a mistake. Embracing disposable VMs for everything has saved me so much time and headache - just scrap it and start anew. Then my personal compute space remains very simple and debris free.
      - tasuki 4y ago
        > Embracing disposable VMs for everything has saved me so much time and headache Yes, but wasn't the main selling point of Docker "no more VMs"? It solves the same issues, without the drawbacks of running virtual machines.
  - KronisLV 4y ago
    > Runs docker in a VM for you It depends: - the Hyper-V backend uses a VM for running the actual containers, which is a bit annoying because it just sits there and eats your RAM whenever it's on (technically you could enable dynamic memory for the VM, but i think it used to break) - the WSL2 backend uses the whole fancy new system that Microsoft came up with to, idk, attempt to embrace and extend Linux or something; far less annoying than Hyper-V but also has somewhat different approaches to setting resource limits (e.g. if you only wnat to give it 4 GB of RAM or 4 CPU cores so something is left for the rest of your system and doesn't slow down when you run docker build) Honestly, Docker on *nix is a way better experience, but not everyone can run it for a variety of reasons (e.g. corporate policy or having the same PC for personal development and gaming).
    - LunaSea 4y ago
      And 2022 is still not the year of the Linux Desktop. Many tried and went back to OSX die to the rough corners of desktop Linux.
      - KronisLV 4y ago
        It will probably never be the year of the Linux Desktop in the mainstream, despite many promising projects out there. But for personal usage, Linux is more than acceptable - if you can grokk all of its pain points, that is. Linus Tech Tips did a few videos on the topic recently, it was painful but understandable to watch. Personally, Ubuntu LTS (or equivalent boring long term support distro) or something with XFCE is solid and really usable, especially if you intend to do programming, where things are weird on Windows sometimes. Except for gaming. Proton still has a ways to go and Wine isn't optimal for that sort of stuff and neither Linux or OS X are worth supporting for many games/projects/software because they represent a small part of the total userbase. For example, in regards to games: https://store.steampowered.com/hwsurvey https://store.steampowered.com/hwsurvey Windows 96.68% OSX 2.20% Linux 1.12% Supporting any system that's not Windows for games would be like burning money. At that point, you might as well offer the game for free on those systems (if using an engine like Unity/Unreal/Godot, where builds are easy) but refuse bug reports on them, if you don't have the resources for that kind of support.
papito 4y ago
All you really need is "ctop", the "top" for Docker. You can view running and idle containers, start, stop, delete, view logs. https://github.com/bcicen/ctop https://github.com/bcicen/ctop

akagusu 4y ago

Docker is not dead, despite the attempts of Red Hat (and Google) to kill it. The market changed and Docker changed to stay relevant. Just that.

hiroshui 4y ago

Hello, its Maximilian from fme - the author of the linked article. I had vacation when this article blew up and now i am pretty overwhelmed of the discussion that started here! We are very happy that this discussion took place and that it sparked a nice and lively discussion about containers, Docker, Podman and all the other stuff between you and all the other professionals. We are also very grateful for all your criticism and corrections. The article is currently under review and we want to make sure to correct the previous mistakes in a transparent way. Seems like a few valid points were missed and some wrong assumptions were made. Nonetheless, I think the discussion that came out of this helped a lot of people get some useful insights into Docker, Podman, and containerization as a whole. We are trying to get all wrong information - based on your discussion - right and summarize them in the refactored article! What can we take away from this? - More research next time is necessary and we need to challenge our article. Again, thanks a lot for all your feedback! We appreciate it very much! There were a few new things that also I was able to learn in this process which is always nice.

hiroshui 4y ago
We just updated the article. Just to let you know :) Have a good one!

studmuffin650 4y ago

Lack of mention of podman machine seems like big miss when talking about podman as an alternative to Docker.

ravenstine 4y ago
Wouldn't Lima serve that role? https://github.com/lima-vm/lima https://github.com/lima-vm/lima If memory serves me right, it works with Podman.
- Havoc 4y ago
  Lima is mentioned in the article.
  - ravenstine 4y ago
    It's mentioned as an alternative, but not as something that works tandem to Podman.

bobobob420 4y ago

docker is far far far far from dead. I frankly do not seeing it going away for a looong time because it is generally a great and well supported product. Theres lots of information on issues and fixes and tons of developers using in across many large corporations

redisman 4y ago
Agreed. It’s simple (compared to k8s) and covers most companies needs perfectly well

Havoc 4y ago

Think it is rapidly moving towards being more of a data carrier/format rather than being dead per se. Half the time you're jamming it into some cloud service anyway where you have no idea what GCP/fly/aws is using under the hood to actually run it. Meaning this discussion is more relevant to the self-hosted context. In which case I'd say containerization isn't really security. So in my mind that residual risk of the daemon being root is inconsequential. (Or if not use a VM).

djbusby 4y ago
I'm still in the VM all the things camp. Like, containers are neat but VMs have the same cheapness for me - that is deploy some VM per app. Like Docker per app. Many times these days I'm one VM for just one Docker package. (Can you tell VM is my favorite isolation method)
- jolux 4y ago
  Fargate and Fly are actually both Firecracker VMs, not containers.
  - djbusby 4y ago
    Yea, super fast boot VMs are a game changer in the container vs VM game.
- LunaSea 4y ago
  I don't think people mind using VMs rather than containers. The preference comes from the tool chain which is simpler for containers (even if you use Vagrant) and performance ( true or not, lots of people still have the sluggish VMs in mind.
  - tluyben2 4y ago
    > lots of people still have the sluggish VMs in mind. I did, until trying firecracker.
- 4y ago

tragictrash 4y ago

OCI compatible containers are the future, docker and podman both classify as such. https://opencontainers.org/ https://opencontainers.org/ That being said, docker blows. Docker desktop blows more. Docker desktop on Windows blows the most. I always get stuck with a bind mount misbehaving, or some other issue that requires me to wipe the docker desktop data to fix it. Just use docker compose for simple stuff, and stay away from docker for Windows if possible.

Grimburger 4y ago
Given that docker modelled the OCI standard on their own software and expected everyone else to follow along, I think it would be nigh impossible for them to not be in compliance with the spec.
Hamcha 4y ago
On the Docker for Windows note, it's not podman but after I had trouble with their "forced upgrade unless enterprise" policy (which made me update to a broken version with a known issue they didn't solve for weeks) I switched to Rancher Desktop and never looked back. You get all the things (docker CLI, docker-compose, kubernetes via k3s) but it's FOSS and it doesn't feel like they're trying to shove a premium plan down your throat.
- astrostl 4y ago
  Loving Rancher Desktop here too, and even w/o making use of k3s at all. Fantastic drop-in replacement for Docker Desktop w/o the garbage.
  - deskamess 4y ago
    Interesting/Great that Rancher Desktop uses WSL - not having to launch a Linux VM (albeit transparent) is nice. I still wish MS would have come up with something native.
zamalek 4y ago
> blows. Docker desktop blows more. Docker desktop on Windows blows the most. I see your "Docker blows on Windows" and raise you "Docker blows on M1." At least you have WSL, Apple couldn't give half a fuck (and nor could Docker). Colima has been a lifesaver, but having used WSL Docker in the past and Linux Docker recently (I now favor Podman), M1 Docker is a complete shitshow. I'm slowly infesting our codebase with Podman/Buildah/Skopeo (also because they do things Docker can't), and hopefully we'll get to the point of using podman machine.

jordemort 4y ago

Why not both? Since Podman 4.1 came out with full Compose 2.x compatibility, I'm running Podman on Docker's socket, but using Docker's CLI to talk to it, so that I can use the buildx and compose CLI plugins. It works great, Docker's CLI doesn't seem to have any clue that it's talking to not-Docker. I even have VSCode's Docker extension and Remote Containers working this way.

deleted 4y ago
[deleted]
jcastro 4y ago
Is there any config to set up this way or do you literally just run podman on the socket and it just knows what to do?
- piyh 4y ago
  podman replacing the docker socket https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
  - cipherboy 4y ago
    As a fun fact, you can also run: $ systemctl --user enable --now podman.socket $ export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock and get a rootless, Docker-compatible socket. If you're running, e.g., a test suite written against the Go Moby APIs, this will execute the containers with Podman rather than with the system daemon.
- pkulak 4y ago
  You can set it as systemd socket service, so it doesn’t even run until something tries to connect. That said, I don’t even bother with that. Podman can run K8s configs, and they are yaml too, only slightly more verbose than a compose file, if you strip everything out you don’t need. The CLI is nicer than compose too, with proper commands instead of tying up a terminal until a ctrl-c.

user3939382 4y ago

Does Podman work with ECR/ECS etc the way Docker does?

lapser 4y ago
Yes

throwawei369 4y ago

This would all be true if podman wasn't a gimped version of docker.

encryptluks2 4y ago
In my experience it is quite the opposite really, a more featureful solution with much more options and safer defaults.
- bob778 4y ago
  From using podman in prod, it seems to be lots of features but not necessarily stable or well-rounded
  - lapser 4y ago
    Podman isn't supposed to be used in prod servers. It's for local development. It produces OCI compatible images (through Buildah), and you're supposed to use those with a proper container orchestration tool such as K8s, Nomad, Docker Swarm, or whatever else there is.

colordrops 4y ago

NixOS recently switched the default from docker to podman for containers. I don't know if it's Nix's configuration, or a problem with Podman itself, but it's unusable. The systemd service often hangs, creating networks errors out, the pod concept doesn't work great, requiring tearing down the whole group of containers to change port mappings, and it acts like a completely different system depending on the user running the container (though I suppose this last bit is supposedly a feature). Why isn't the list of images global to the machine? Perhaps I just don't get it yet.

yjftsjthsd-h 4y ago
> Why isn't the list of images global to the machine? Why would it be? Unless you jump through hoops, your music and photos aren't global to the machine; rootless containers just made containers fit in the traditional unix security model.
mati365 4y ago
It's also happening on Debian. Podman seems to be also losing quite often network firewall configuration after killing containers that were using cached images so you are not able to access internet from containers (logs say its libpodman bug)
bob778 4y ago
Podman always feel like software no one’s using in prod. There’s a lot of edge cases and bugs - particularly in the service control, user groups and ipv6 support

bdcravens 4y ago

> Podman currently only runs stably on Linux-based systems. Under Windows or MacOS it becomes a bit more demanding, although it is possible with detours. I think this is an area bearing improvement before most dev workflows can switch

mekster 4y ago
Why do you need to run docker on Windows or Mac?
- ByteJockey 4y ago
  Local development, usually.

mati365 4y ago

Have you ever used podman-compose? It's amount of bugs and missing features is bigger than actual features count.

jdoss 4y ago
Podman 4.x is pretty great with docker-compose due to its API compat with Docker. Give it a shot.
- okamiueru 4y ago
  This sort of makes the whole premise confusing to me. The way to use the alternative to the "dead" product is to use the dead product. This isn't a critique of your comment. Just, that I don't understand what's going on here. Maybe this whole issue is a non-Linux kind of thing? Test stuff out with wither docker compose, or minikube, and otherwise deploy to k8s has worked great for me.

qbasic_forever 4y ago

Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It's so much nicer to have all my container related stuff like volumes, configs, the control socket, etc. in my home directory and standard user paths vs. scattered all over the system. Permission issues with bind mounts just totally disappear when you go rootless. It's so much easier and better than the root privileged daemon. I really wish rootless podman/docker was the default install now. It's still kind of annoying to setup with reading a smattering of old docs and having to think about your distro setup, cgroups settings, etc. It really should just be a "run this install script and you're done".

pkulak 4y ago
The arch wiki is my go to every time I install Podman, and it’s a little easier every time. It’s down to like two steps now, with no file editing. We’ll get there.
sureglymop 4y ago
What about UID issues? I remember using it years ago and sometimes having permission issues in containers when mounting local files. How is that nowadays? I much prefer running this in a rootless manner also. What about docker compose? Is there an alternative for podman?
- stingraycharles 4y ago
  There’s podman-compose which does what you want, but is a community maintained script. There’s also the ability for podman to run as a system service, and provide an OCI compatible container API. This then integrates seamlessly with the actual docker-compose. See: https://www.redhat.com/sysadmin/podman-docker-compose https://www.redhat.com/sysadmin/podman-docker-compose
  - znpy 4y ago
    You can point the official docker-compose at podman now! I do that! It's 99.999% compatible as the podman people basicaly reimplemented all the docker daemon APIs. It sometimes lags a bit behind, because sometime docker implements new stuff... But for usage with docker-compose it has worked flawlessly for me. EDIT: you can also export the podman unix socket via socat, i also tried it to run a rootless docker runtime in kubernetes (podman daemon running as a pod, to run docker builds in kubernetes) as an experiment. It works but i'd love to see a better integration with Gitlab runner project. Gitlab is supposedly getting podman support any time soon, in 15.1 IIRC ?

usr1106 4y ago

This article is from a Windows perspective. On Linux podman is significantly different from docker: It uses user namespaces. So it is much more secure (assuming that security bugs related to Linux user namespaces, which have indeed been dicovered, are still much rarer than people running untrusted container images). However, with security comes incompatibility. If the image does tricky system interaction instead of just running user space code and some standard cases like opening a socket chances are that things will not work under podman without modification.

js4ever 4y ago

matyasrichter 4y ago
Ok.
pjmlp 4y ago
Then there is very little GNU/Linux left to use.

jdoss 4y ago

I only use Podman for my workloads these days. Docker was always a headache for me on Linux. Podman allows me to quickly do whatever I want with containers and I can use systemd or a simple bash script to easily create services on my workstation or in production with Nomad with https://github.com/hashicorp/nomad-driver-podman https://github.com/hashicorp/nomad-driver-podman I am super thankful for the team of developers that work on Podman. It has really come a long way since 2.0 and they are very responsive to issues in my experiences. If you are using Linux as your daily driver and you use Containers give Podman a try. Here are some examples of the things I have done with Podman. https://github.com/forem/selfhost https://github.com/forem/selfhost https://github.com/jdoss/ppngx https://github.com/jdoss/ppngx https://gist.github.com/jdoss/25f9dac0a616e524f8794a89b7989e9f https://gist.github.com/jdoss/25f9dac0a616e524f8794a89b7989e... https://gist.github.com/jdoss/ad87375b776178e9031685b71dbe37cf https://gist.github.com/jdoss/ad87375b776178e9031685b71dbe37...

mekster 4y ago
What were the headaches?
- skrtskrt 4y ago
  Not the poster, but I have to reboot at least one a day to clear up Docker networking/DNS gremlins. I thought moving to Linux from Mac would make Docker better due to the lower resource usage but I would guess the fact that it’s isolated in a VM in Mac is why I never had network issues there
  - bavell 4y ago
    Strange, I work with docker containers nearly every day but usually only reboot once a month.

iknownothow 4y ago

It's okay to stick with Docker if it works for us right? There's nothing fundamentally wrong with it right? At the moment Podman is just more work for us because I and other devs don't have years of of experience and intuitions about Podman like we have with Docker. I'd rather just focus on business problems rather than another migration.

raesene9 4y ago
Yep Docker's fine (IMO ofc). If you're running on Linux hosts, then Docker engine is open source, free and works.
jarek83 4y ago
Similar feelings here. We use Docker without any issues beyond usual problems of a caliber that I guess any other tool would have. I see some new live in docker desktop and I also have flawless experience on M! Mac with it. I even ignored all recent hype to ditch Docker because it became more transparent tool to my workflow, I forgot I use it.
zamalek 4y ago
If you're using it commercially, you are licensed right?

KronisLV 4y ago

Personally, i still find Docker to be the easiest way to get containers up and running - everything from Dockerfiles, building images (caching aside), to running them with Docker Compose, Docker Swarm or even Kubernetes with Docker as the runtime. Why? Docker - one of the older and most popular runtimes for OCI, with all of the tooling you might possibly want; most of the problems are known and solutions are easy to find, vs venturing "off the happy path" (not everyone has the resources to try and figure out Podman compatibility oddness) Docker Compose - ubiquitous and perhaps the easiest way to launch a certain amount of containers on a host, be it a local development machine, or a remote server (in a single node deployment), none of the complexity of Kubernetes, no need for multiple docker run commands either Docker Swarm - most projects out there do not need Kubernetes; personally, i'm too poor to pay for a managed control plane or host my own for a cluster; K3s and k0s are promising alternatives, but Docker Swarm also uses the Compose specification which is far easier to work with and most of the times you can effortlessly setup a docker-compose.yml based stack, to run on multiple nodes, as needed; also, in contrast to Nomad, it comes out of the box, if you have Docker installed; also, when you don't want to mess around with a Kubernetes ingress and somehow feeding certificates into it, you can instead just run your own Apache/Nginx/Caddy instance and manage it like a regular container with host ports 80/443 (setting up which might be a bit more difficult with Kubernetes, because by default you get access to ports upwards of 30000) Kubernetes with Docker as the runtime - maybe with something like K3s, if you need relatively lightweight Kubernetes but also want to figure out what is going on with individual containers through the Docker CLI which is familiar and easy to work with, to dig down vs what something like containerd would let you do Long story short, choose whatever is the best suited solution for your own needs and projects. Just want things to work and be pretty simple, modern technologies, hyperscalability and ecosystem be damned? Docker/Compose/Swarm. Want something with a bit more security and possibly even for running untrusted containers, with lots of scalability and projects built around the technologies? Podman/containerd/Kubernetes. I've heard about Docker and Swarm being dead for years, yet it seems to work just fine. They even fixed the DNS weirdness on RPM distros (RHEL/Oracle Linux) in the 20.X releases i think, though personally i'm more inclined towards using the second-latest Ubuntu LTS because there's far less SELinux or other weirdness to be had (e.g. K3s clusters failing to initialize because of changes to cgroups). When it will actually die for real, i'll just use something like https://kompose.io/ https://kompose.io/ to migrate over from the Compose format to Kubernetes. Of course, none of that excuses you from having to learn Kubernetes, because that's what the industry has decided on. My approach is more akin to basing a new project on PHP 7 because you know that you don't need anything more. On a different note, your employers asking you to setup Kubernetes and to launch Nexus, PostgreSQL and whatever else on a single node that has 8 GB of RAM, as well as run a bunch of Java services on it can be challenging to say the least, especially when the cloud is not in the cards, there are no pre-existing clusters in the org, there isn't the interest to get more resources and even if there was, then there'd also be thoughts along the lines of "why should we give this one project that many resources?" expressed. I'm slightly exaggerating, but oftentimes it can be akin to choosing to run Apache Kafka when RabbitMQ would have sufficed - someone else making the choice for you, pushing you into sub-optimal conditions and making you suffer as a result. I recently went to Europe DevDays 2022 (https://devdays.lt/ https://devdays.lt/) and DevOps Pro Europe 2022 (https://devopspro.lt/ https://devopspro.lt/) and one of the arguments expressed was along the lines of: "You should never host your own clusters, if you can. Just pay one of the big three platforms out there (AWS/GCP/Azure) to do it for you." What a crazy time to be alive, where running the full stack can be problematic and enterprise solutions are getting more and more detached from what smaller deployments and homelabs would actually need. That said, Podman is getting closer and closer to full feature parity with Docker with every passing year and Kubernetes is also easier to run thanks to clusters like K3s/k0s/RKE and tools like Lens/k9s/Portainer/Rancher.

flerp 4y ago

Clickbait title ahoy

lapser 4y ago

This article misses quite a bit. Podman has a full Docker compatible API, so you just have to enable it, and then set the DOCKER_HOST to point to its socket. From there docker compose should work as if you had Docker. Podman also is currently working on "podman machine", which can spin up a Linux VM to run Podman on macOS and Windows. I think it's still in beta or something, but it seems to be working already. There is also things like Podman Desktop[0] and Podman Desktop Companion[1] which attempt to bring an experience similar to Docker Desktop to Podman. [0] https://podman-desktop.io/ https://podman-desktop.io/ [1] https://iongion.github.io/podman-desktop-companion/ https://iongion.github.io/podman-desktop-companion/

lioeters 4y ago
About "podman machine": > Podman also runs on Mac and Windows, where it provides a native podman CLI and embeds a guest Linux system to launch your containers. This guest is referred to as a Podman machine and is managed with the `podman machine` command. > ..On Mac, each Podman machine is backed by a QEMU based virtual machine. > ..On Windows, each Podman machine is backed by a virtualized Windows System for Linux (WSLv2) distribution. https://podman.io/getting-started/installation.html https://podman.io/getting-started/installation.html

nanna 4y ago

Wouldn't this be a good time to adopt guix (or nix) for a next generation upgrade on Docker?

scroot 4y ago
This is what I'm wondering. These are in some ways simpler systems as well, because containerization is "baked in"

pelorat 4y ago

I just use LXC, it's never failed me and has none of the hype.

cpach 4y ago
Can you run OCI containers there?
hamilyon2 4y ago
Lxc rocks. It is linux-only, though
- pxeger1 4y ago
  Containers are a Linux-only feature. Docker Desktop just runs a Linux VM on Windows and macOS. (actually I think Windows Server has some container support now, but it's a totally different system)
j4hdufd8 4y ago
LXD is not production ready in my experience. Snap auto updates fucked up many times, for example.
- EnigmaCurry 4y ago
  Use LXC on Proxmox rather than LXD, very stable.

smarx007 4y ago

How did the intro get so many things wrong?! 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See https://techcrunch.com/2019/11/13/mirantis-acquires-docker-enterprise/ https://techcrunch.com/2019/11/13/mirantis-acquires-docker-e... and https://www.docker.com/blog/docker-enterprise-edition/ https://www.docker.com/blog/docker-enterprise-edition/ 2. k8s didn't remove dockershim for political reasons but because containerd was refactored out of Docker long time ago and k8s wanted to get rid of the extra layer. See https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/ https://kubernetes.io/blog/2022/01/07/kubernetes-is-moving-o... 3. Rate limits have nothing to do with the container runtime. Podman also has to get images from somewhere. And Cloudfront bills starting at $0.02/GB (assuming you pump 5PB+) have to be paid somehow. The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror. 4. RedHat offers not only packages in RHEL but also support and it makes sense they will offer packaging and support only for podman (a RH project) going forward. This does not concern us who don't pay for RH support. Having said that, Podman is a nice evolution of Docker. Though I am not sure how much I can trust the rest of the article given how the intro twisted so many facts.

hiroshui 4y ago
I wrote a comment for the general comment section, but wanted to respond to your comment as it contains valid criticism. 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise... >> You are right. That's a mistake. 2. k8s did'nt remove dockershim for political reason.. >> That is a valid point and the official story. Imho I think the acquisition was nevertheless something that played an accelerating role in this, since it happened relatively soon after the acquisition. Mirantis acquired Docker Enterprise in November 2019, and the end of Dockershim support was announced in 2020. I've heard that from a few other people as well. BUT this is just rumor, so you might be right. 3. Rate limits have nothing to do with the container runtime.. >> This is 100% true. Nevertheless, dockerhub is part of Docker and therefore a rate limit on the official Docker registry is something that has made our customers switch registry to other registry providers or implement their own container registry. Therefore, they are getting rid of this service, which is part of the Docker-only ecosystem, so its usage in enterprises is decreasing. 4. RedHat support switched to Podman as it is on of their products.. >> It only makes sense for RedHat to support Podman since it's from their own product forge. You are right about that. That said, there are a lot of companies using RH and paying for it, which automatically leads to a decrease in Docker usage vs Podman. Less use of Docker means more use of Podman. Last but not least, RedHat would not invent Podman if there was no need for an independent tool to Docker. Podman helps in some areas where Docker lacks features, such as support for pods, rootless mode, etc. Thanks for your criticism! It is appreciated and helps us to do better.

CoolCold 4y ago

Article itself and the idea in general seems controversial at best for me. I could not find answer for myself why Docker is any close to be dead and why Podman is the thing I should use instead of Docker immediately. Q 1. Docker has some policy change and your company may need to pay for it - if you have > 250 persons/10 million revenue A 1: Indi/Solo devs out of scope. Enterprises probably fine with that anyways. Q 2. Docker has limits for pulls from Docker hub!!!! You have 100 (200 with login) downloads/single IP for 6 hours interval. A 2: It was already mentioned, switching to Podman, while using Dockerhub doesn't magically helps. Moreover, practically I find it totally fine for Indi/Solo dev. For companies, who's amount of pulls can be higher - you want and have in place your local registry anyways to ensure Business Continuity and this doesn't bother you much. Q 3. Running no background processes, running rootless is good because of ... A 3: On dev env (your local laptop, for example) you do not care much - your goal is ease of use. On production, running rootless rises question from me: * how you expect firewall (iptables) to be updated for port forwardings? * how you expect networks and bridges organized without root? * how you expect auto restart for container to happen on failure without supervising it? * some security advises and mitigation guides mention disabling user namespaces and was/is disabled by default in some distros https://news.ycombinator.com/item?id=28054823 https://news.ycombinator.com/item?id=28054823 - your security & system administration team may have such limits in place on production * those who care for intruder gets into container and can hijack system further use FireCracker or similar approach anyways [for production] So what is left in "pros" for Podman, have I missed anything?

lloydatkinson 4y ago

How does podman work with giving native access to resources? Like on a raspberry pi with docker you need to tell docker it has the ability to access /sys for the GPIO pins and for I2C etc. does podman have this too?

TheAceOfHearts 4y ago

People complaint about framework or library churn in the JS world, but other ecosystems have the same issue. For people who aren't following this ecosystem closely, I just want something that works and gets out of the way with a minimal learning curve. Navigating fragmented ecosystems sure is a pain... I get that different tools serve different needs, but having to learn a bunch of different things just to figure out which one to use gets really exhausting. Especially when you have to do it for tools at every layer of your stack.

olingern 4y ago
JS is a punching bag because it’s a moving target that most everyone has to deal with at some point and pre-ES6 JS had quite a few warts. It’s a fine language now, especially with TypeScript helping to push things in the right direction. I left .NET land for this very reason. JS pales in comparison to .NET framework fatigue

CottonMcKnight 4y ago

The first thing that happens when visiting that site is a modal overlay that forces me to interact with it before I can do anything else, so that website is what's dead, at least to me.

lkxijlewlf 4y ago

So, is Podman to Docker what LXD is to LXC, then?