20 ms·

Transitioning from Docker to Podman

466 points by indentit 6y ago

husamia 6y ago
Does it support GPU when installed on Windows 10 WSL1?
musicale 6y ago
I'm not familiar with Podman but I welcome any alternative to Docker.
rhatdan 6y ago
Hopefully most of you who have had issues with Podman have opened bug reports or issues. We are working to fix incompatibility bugs and getting out new releases all the time. As far as docker-compose support, in Podman 2.0 we have added APIV2. This is a socket activation REST API. This API has a compatibility mode that implements the "Docker API" meaning podman can be setup to listen on the docker.sock and launch containers. We also have the more advanced Podman API for support of concepts like Pods. The API should be able to work with docker-py based scripts and Compose. We are getting lots of community support in fixing up our inconsistencies. This is a fully open source project and we love to get contributions.
- freedomben 6y ago
  This is incredible news! My only reason for using docker still are images that have you mount in the docker.sock and they introspect on it (such as jwilder/nginx-proxy). The day I can move over completely will be a good day.
upnrunning2140 6y ago
I'm an enduser and I expect things to "just work". That seems to match a lot with Red Hat's Linux distros (i.e. RHEL): "Just use it, it's a defacto standard so most third party software is tested on it, don't worry about underlying components as Red Hat has made sane choices for you." That's the theory (and Red Hat's marketing). I wish I could just be using CentOS/RHEL and not worry about the choices Red Hat makes. But the shit is piling up (sorry for my harsh words, no offence intended). So, let's containerise something simple on top of the "centos" container image, let's say postfix. Oh, postfix on centos needs systemd for logging. But systemd in a container is a nightmare. You can get systemd to work in a container if the host system is using containerd and you pass certain special files from the host to the container. So just use Podman instead of Docker, right? Podman has functionality to make systemd in a container work. OK, I can run my container on my fat workstation (a Centos system with Podman). But is it still portable? Can I just run it in Github Actions, AWS ECS, a Windows machine with Docker Desktop? Nope. It's not portable. Let's put the systemd rant aside (I really like the systemd CLI UX, but the architecture (dbus, etc) seems to only serve one usecase properly (Desktop systems) and seems to be heavily wrong for the container usecase). Let's rant about the architectural choices Red Hat is making for containers. Before Red Hat started to get involved there was the open source, (now) cross-platform containerd that a lot of tools are building on top. It consumes the low level runtime runc and both provides an API for Kubernetes (CRI) and additional things. It is highly pluggable and therefore the "only container runtime you'll ever need". And it's purely community governed (CNCF). What is Red Hat doing? Are they building their container tools on top of containerd? Nope. They create their own low level container runtime (crun), their own mid level container runtime (cri-o). But cri-o only covers what's needed for Kubernetes. So to be able to build container images, etc (the "working with containers on a single machine" usecase) additional tools are needed (podman, buildah, skopeo) and they have to implement the missing functionality themselves. So Red Hat's Open Shift (Kubernetes distribution) builds on an entirely different stack than Podman. Fragmentation everywhere. Was that really necessary? Why should I care as an enduser? Well, I can inspect and debug all tools that use containerd the same way (i.e. using the "ctr" tool). I can relatively easily even write my own tools that use containerd (via it's grpc api) and can access the resources (containers, images, etc) that these tools are managing to solve my special custom needs. For the Red Hat stuff everything is different. I could work with cri-o using crictl and write custom tools using cri interface. For Podman I would need to use Podman's API. (Which has annoyingly entirely changed between v1 and v2). ok, enough rant (I could go on with how hard it is to get an up to date version of podman on a supported RHEL system even with app streams, that UBI images don't provide podman/buildah/skopeo, etc etc etc). Please don't mistake me: Podman, cri-o, crun, open shift are all amazing technologies. And it's great that they are mostly open source via upstream projects. But I wish this whole fragmentation hadn't happened. For me as an enduser it's nightmare.
- upnrunning2140 6y ago
  and yes, people have proven that it's possible to build something like podman or buildah on top of containerd / buildkit! No need to reinvent the wheel! https://github.com/rancher/k3c https://github.com/rancher/k3c https://github.com/genuinetools/img https://github.com/genuinetools/img
- freedomben 6y ago
  Disclaimer: I work for Red Hat, but I don't code or design any of the things you've mentioned here. Opinions are my own. I think I just gave you your first ever upvote on HN! Thanks for this post, it's great discussion. Regarding Postfix/systemd issues, you should take a look at ubi-init image. It has a minimal systemd in it to address problems like that[1][2]. Regarding crun, have you looked at the "Why another implementation" in the crun README.md by chance?[3] Or have you read the blog post about it that goes into a lot more detail?[4] I totally agree with the dislike toward fragmentation. I myself have been very critical of NIH and fragmentation when it happens. I do think there's an interesting case to be made for crun though. [1]: https://developers.redhat.com/products/rhel/ubi https://developers.redhat.com/products/rhel/ubi [2]: https://catalog.redhat.com/software/containers/ubi8/ubi-init/5c359b97d70cc534b3a378c8 https://catalog.redhat.com/software/containers/ubi8/ubi-init... [3]: https://github.com/containers/crun https://github.com/containers/crun [4]: https://www.redhat.com/sysadmin/introduction-crun https://www.redhat.com/sysadmin/introduction-crun
  - upnrunning2140 6y ago
    thanks for the response and the links! I will certainly have a look. (And again sorry for my rather harsh words - I have a lot of respect for all the hard work everyone at Red Hat is doing. I can only imagine that it's much harder to make technical decisions and build tools like Podman than it looks like. Thank you for not taking my rant as an offence! It's just my brutally raw user experience).
- rhatdan 6y ago
  containerd is a daemon, which actually came out after CRI-O. But anyways the hole idea is Podman and Buildah was to get away from using root running daemons to launch containers. The important thing about containers is that we launch we all follow the standards. Podman, Docker, CRI-O, Buildah, Containerd all use the same OCI based images available at container registries, and all launch them the same time via OCI Runtimes. These runtimes can be runc, crun, kata, krun, gVisor ... There is no fragmentation on OCI, which is important. Think of these as been web content, you have lots of choice on viewing and using web content, firefox, chrome, safari, IE, curl, linx, wget... All of these tools (Podman, Buildah, Skopeo, CRI-O) that can interact with the OCI content and all have different strengths. Please do not add FUD about systemd. None of the new container engines require systemd, they all can run and support all images at Docker.io. The new container engines support systemd better then Docker did, but they do NOT require it.
sdan 6y ago
> One of Podman’s greatest advantages is its complete CLI compatibility with Docker. In fact, when building Podman, Docker users can adapt without any significant changes. For example, you can use the alias command to create a docker alias for Podman: `alias docker=podman` Wow that's a great adoption hack; just alias another program as another
- xenocratus 6y ago
  Would that be covered by the same issue as Google v Oracle?
  - igneo676 6y ago
    Maybe, but it wouldn't matter if they're OSS to begin with
    - xenocratus 6y ago
      That's true, don't know why I didn't think of that to begin with, just saw them as "products" from two companies.
    - deleted 6y ago
      [deleted]
joncp 6y ago
I like the daemonless architecture a lot, but until there's a quick and painless way to install it on OSX and Windows developer machines, you're going to see very limited uptake.
- nickysielicki 6y ago
  I find it somewhat surprising that we haven't seen more adoption of the redhat docker (lowercase d) replacements after Docker (uppercase d) started pushing some of their monetization efforts. The conclusion that I have to reach is that there are more docker users on Macbooks than I realized.
- deleted 6y ago
  [deleted]
- GordonS 6y ago
  I was just thinking the same thing, and was going to ask if there was anything like Docker Desktop, something to make it simple to use on Windows/MacOS!
  - mikey_p 6y ago
    Before there was Docker Desktop on Mac there was Docker Machine. And of course there's a Podman Machine: https://developers.redhat.com/blog/2020/02/12/podman-for-macos-sort-of/ https://developers.redhat.com/blog/2020/02/12/podman-for-mac...
- laaman02 6y ago
  Maybe it doesn't count but podman works great on WSL2 as far as I can tell.
- throwaway894345 6y ago
  I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right direction.
gigatexal 6y ago
Any docker Podman corner cases that people have run into? I like the idea of rootless containers but I can do that ether easily by adding one line to my dockerfile or adding a user flag when I run a docker container. What other advantages am I getting?
- tick_tock_tick 6y ago
  This isn't about root inside the container but rather it doesn't need root on the host system.
- deleted 6y ago
  [deleted]
- pydry 6y ago
  No need to run a daemon. Security is better.
  - educar 6y ago
    If you lock down the docker user, is it a problem?
    - soraminazuki 6y ago
      The biggest issue lies not in the few lines in /etc/passwd or /etc/group, but rather the highly privileged process with a large attack surface that is the Docker daemon.
      - redis_mlc 6y ago
        Docker in production is the Dominion voting machine of the IT world. :)
- fisxoj 6y ago
  Generally, it's been pretty easy to transition for me, but I used to rely on things like the automatic nginx image that you need to mount the docker socket into so it can route traffic to containers when they come up. Since there's no daemon, there wasn't a way to do that. I think people are working on it, but I haven't tried recently. Work also uses a special docker RUN command that can use the host's ssh keyring to, eg. Install something from a private github repo. Doesn't seem to exist in podman.
x87678r 6y ago
I really struggled with podman, a bunch of containers (I cant remember which ones) didn't work, and build tools choked as well. At work we dont get root access so I thought it would be perfect but sysadmins couldn't figure out how to configure either so was bust there too.
- deleted 6y ago
  [deleted]
- aduffy 6y ago
  I've also personally struggled a lot with this at $WORK, but some of the new features in RHEL 7.8+ (specifically GA'ing of the fuse-overlayfs graph driver) have actually alleviated a ton of the issues I've seen previously. If you haven't tried that I'd certainly recommend it, YMMV
- siscia 6y ago
  I had the opposite experiences, everything worked out of the box.
- dnautics 6y ago
  I just installed my new $WORK docker-compose using podman and podman-compose, and it worked out of the box. To be fair, I failed at it one time before at previous job... So... Coin flip?
  - circularfoyers 6y ago
    I had a repeat of the same experience too recently. It was very satisfying having it work now.
lopatin 6y ago
I was just about to complain about another thing to learn. Then I saw you can do "$ alias docker=podman". Just want to acknowledge the importance of that work. Making things compatible is both boring and a pain, but it's a door opener for people like me who refuse to learn your new API because I know a decent one already.
- freedomben 6y ago
  Completely agree. One thing I want to point out though for anybody not familiar with the differences between podman and docker, for the most part alias docker=podman will "just work" except for these situations: 1. docker-compose. podman-compose attempts to cover this but I've heard it's not quite there yet 2. Mounting the docker socket into the container. Podman is daemonless which means that won't work. There is work going on right now to allow Podman to be driven in a similar way if needed, but I recently tried to set it up and hit a bug[1]. CRI-O brings a daemon, and it is used extensively in Kubernetes and OpenShift, but not so much outside of that. [1] https://github.com/containers/podman/issues/8323 https://github.com/containers/podman/issues/8323
  - hda111 6y ago
    It’s now possible to mount a docker compatible socket inside the container using podman.
    - freedomben 6y ago
      Can you provide more information on this? A blog post or some instructions? I'd like to read more.
- capelio 6y ago
  Unless you're optimizing for stagnation, this really is a terrible approach to reaping the benefits of innovation. If your prereq to trying something better is that it needs to mirror something that's "decent already," you'll spend most of your life stuck on the same plateau.
kitotik 6y ago
Daemonless and rootless are killer features. The lack of filesystem isolation and volume support are the last things keeping me from jumping ship.
- lifty 6y ago
  Rootless is coming to Docker as well since containerd switched to cgroups v2, which was a requirement for rootless
  - AkihiroSuda 6y ago
    Docker has been supporting rootless mode since 19.03
- AkihiroSuda 6y ago
  Podman already supports `podman volume create`, though it doesn't support volume plugins.
ranadeep 6y ago
At my company, we run our CI/CD (Jenkins) using the Docker-in-Docker paradigm to facilitate easy maintainability of the CI itself and allow us to run containerized builds. When we shifted to RHEL 8, we attempted to move this over to Podman and it went miserably (this was back in November 2019). The main reason being is that podman-in-podman doesn't work and had bugs (at least back in Nov 2019). Maybe it fixed now but this was our experience. We ended up doing quite a bit of analysis on podman only to conclude it's simply not there yet relative to docker (ecosystem and ergonomics). There are quite a few corner cases that docker quite simply supports out of the box beautifully that podman doesn't support or just has bugs. I like the what the project is trying to solve by being daemonless, but this is not as simple as a drop in replacement for docker that RedHat markets it as (alias docker=podman). We ended up sticking to docker professionally and personally, I am still using docker over podman. The ecosystem and ergonomics are just far too nice to give up over podman.
- ctalledo 6y ago
  If you are using Docker-in-Docker, you may want to checkout the new Sysbox runtime (find it on Github). It's a new type of runc that sits below Docker and creates rootless containers capable of running Docker, systemd, K8s, etc. All you have to do is "docker run --runtime=sysbox-runc" <some-image-with-docker> and you'll get a docker daemon that is fully isolated from the host. It's a great way of avoiding privileged containers or mounts to the host docker socket.
- choeger 6y ago
  Maybe you are just too far into docker. I noticed that a lot of default workflows (needlessly) depended on docker running with privileges. One big reason for that seem to be Mac users that only know docker from inside a VM. However, if you think about what you're really needing for CI you will easily see that docker-in-docker gains you nothing. You can as well use plain docker (or podman). The same holds for privileges. No CI operation should need privileges, if only for the reason that it should never alter the CI system itself. I encourage you to not take the standard workflows as a given and really think about what you need and I bet you either end up with a use case that can be covered by rootless podman or something that requires real VMs anyways.
Jonnax 6y ago
Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?
- choeger 6y ago
  It certainly is a gaping hole. But the machines that docker runs on in my experience have a 100% sudoers ratio, so the practical impact is limited.
  - yjftsjthsd-h 6y ago
    Do you mean in that adding a user to the docker group is effectively handing them root? Because if you don't do that, then running docker requires root/sudo, which means that it should be exactly as secure as anything else
- eeZah7Ux 6y ago
  > Is the Docker daemon actually a huge security hole? Yes. Also the containers on docker hub are a security dumpster fire.
- soraminazuki 6y ago
  It's a root daemon which can be made to run arbitrary commands by anyone using its interface, so yes it is a huge, huge security burden. You can't just brush that off as a superficial problem.
  - educar 6y ago
    Given that the most common case is running docker in server environments in VMs and the sysadmins are root, is this a real issue? Can you tell me an environment where a multi-tenant system runs docker?
    - soraminazuki 6y ago
      Yes, it[1] is[2] a[3] real[4] issue[5] which leads to privilege escalation bugs. It also doesn't help that most containers that Docker is responsible for managing is supposed to be unprivileged, and Docker itself is commonly used as a component for a multi-tenant container runtime. [1] https://www.cvedetails.com/cve/CVE-2019-15752/ https://www.cvedetails.com/cve/CVE-2019-15752/ [2] https://www.cvedetails.com/cve/CVE-2019-14271/ https://www.cvedetails.com/cve/CVE-2019-14271/ [3] https://www.cvedetails.com/cve/CVE-2019-5736/ https://www.cvedetails.com/cve/CVE-2019-5736/ [4] https://www.cvedetails.com/cve/CVE-2018-15664/ https://www.cvedetails.com/cve/CVE-2018-15664/ [5] https://www.cvedetails.com/cve/CVE-2018-15514/ https://www.cvedetails.com/cve/CVE-2018-15514/
Cu3PO42 6y ago
I love the idea of Podman being daemonless and (potentially) rootless. Regardless of the presence of security flaws in dockerd, the Podman architecture just feels cleaner. And the CLI compatibility is great. Until it isn't. At work we switched to Podman for a small deployment because Docker didn't yet work with cgroupsv2 and many hours were spent debugging Podman-specific issues. In the end switching to cgroupsv1 would have been significantly less work. Therefore claiming you can `alias docker=podman` is a bit disingenuous. You can, but only if you don't do anything Podman can't handle and what it can and cannot handle isn't immediately obvious. All that said, I wish the project the best and hope it reaches the maturity where this alias actually does work.
- babarock 6y ago
  Genuinely curious what issues you came across. Any chance you documented them somewhere?
  - Cu3PO42 6y ago
    I'm afraid I didn't and I cannot really recall, but many were related to networking. I think one was that I couldn't have two containers on the same network listen to the same port, another one was related to Podman not playing nice with nftables, but the specifics elude me. EDIT: Upon further reflection, I think Docker doesn't really work with nftables either, so that one isn't on Podman. It just so happened we made that switch at the same time. Regardless, there were other problems. I'll check to see if I can find any records of the problems later.
znpy 6y ago
Last time I tried podman it looked very cool being rootless and daemonless, except that since it's rootless I couldn't create the necessary network interfaces... making it pretty much worthless.
- fuzxi 6y ago
  So run it as root then? Am I missing something?
  - DangitBobby 6y ago
    If GP thinks the selling point of podman is that it doesn't have to run as root, but to actually do anything meaningful they have to run it as root after all, why would they use podman?
    - znpy 6y ago
      A rootless docker would greatly simplify some use cases... For example, no need to do docker in docker. Edit: apparently now net4slirp is recommended... Maybe I'll give it another try.
    - fuzxi 6y ago
      The other major benefit of podman is that it doesn't use a daemon.
      - speedgoose 6y ago
        Many people say that, but don't feel like it's very important. Having a deamon or not is a technical detail that most people do not care about in my opinion. And it has advantages too, like accessing Docker remotely or from another VM on the same host, or directly from the host which is nice for Docker on Mac or Windows.
        fuzxi 6y ago
        See replies here [1] for more information [1]: https://news.ycombinator.com/item?id=25165789 https://news.ycombinator.com/item?id=25165789
arianvanp 6y ago
I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background and do the process supervision. I found this very surprising. I still don't understand why they made that choice.
- freedomben 6y ago
  Looks like you may have double posted. Not complaining, just letting you know in case it was unintentional: https://news.ycombinator.com/item?id=25166141 https://news.ycombinator.com/item?id=25166141
arianvanp 6y ago
I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background. I found this very surprising. I still don't understand why they made that choice. At least they do play nice with the whole "systemd owns the Cgroups tree" story. A thing that was always a bit painful with docker. Fun note. Systemd-nspawn actually can run OCI containers directly as well these days. However I'm not sure if it's feature-complete
- candiddevmike 6y ago
  In an ideal world, systemd-nspawn would be the preferred CRI. That was basically the goal of rkt.
  - mongol 6y ago
    What happened?
- foresto 6y ago
  Perhaps that choice comes from wanting their target platform to be linux, rather than systemd?
downrightmike 6y ago
He literally says Ah pah shae, no its Apache, its been around forever. (x) Doubt
yobert 6y ago
We've tried this (podman 2.0.5) and have hit some really really annoying bugs: - Build layer cache doesn't seem to work. If I rebuild locally with podman, it correctly detects cache hits and the build is fast. On our Jenkins server (RHEL 8) with podman 2.0.5 it doesn't. It randomly doesn't cache hit, causing builds to take 20x longer than with docker CE. - Podman is insanely slow at building images in general. COPY emptyfolder/ /emptyfolder/ takes 2 seconds. We have dozens of things to COPY and it's stupid slow compared to docker CE. Buildah doesn't seem any better. - Systemd integration has bugs. If you use the default generated systemd unit file, it does not kill processes when exiting and leaves them dangling. Even after removing the strange KillMode=none it says to put in there, it still leaves processes dangling. Podman sometimes loses track of the container. It will list nothing in "podman ps" but the processes will still be running.
- viraptor 6y ago
  Are you trying to use cache-from? This is explicitly not supported: > --cache-from > Images to utilize as potential cache sources. Podman does not currently support caching so this is a NOOP.
  - yobert 6y ago
    Not using --cache-from, though I did try the various caching command line options to try to troubleshoot. Just a vanilla Dockerfile with a few RUN commands and COPY commands. It would hit cache until about the third layer, and then would cache break every time. On my local computer (Arch) podman is v2.1.1, which seems to have whatever bug I was hitting fixed. So I guess my complaint isn't about podman specifically-- It had bugs and they were fixed, and that's great. But I hate that RHEL 8 touts it as a docker replacement, and won't carry docker in their repositories, when the version they have in their production releases is so broken. We eventually sledgehammered docker CE's CentOS repo into our RHEL 8 jenkins server and now everything works perfectly. Running podman on the production webservers seems to work okay though-- apart from the process killing problems.
    - fatherlinnux 6y ago
justaguy88 6y ago
I'm finding podman great for my (not actually that complicated) docker use-cases
nimbius 6y ago
Podman, buildah, and skopeo are insanely awesome tools that let you transition an image from a public registry to your own private deployment in a jiffy. The article doesn't mention it but podman can also dump a pod configuration you can use in kubernetes and open shift/okd so if you're not a yaml wizard you can still get stuff running containerized.
nikisweeting 6y ago
Lack of a drop-in docker-compose replacement is what stopped me last time I tried podman. podman-compose looked decent but it lacked a bunch of basic features and didn't work smoothly last time I tried it.
qiqitori 6y ago
Assuming that it's Red Hat's fault that there is no el8 package for Docker, I think Red Hat is really shooting themselves in the foot by not supporting Docker in RHEL8. (You can still install the el7 version of Docker on el8 by performing an enable/disable/enable/disable/... module dance, but... why isn't there just an el8 version?)
- bonzini 6y ago
  Red Hat ships podman for RHEL8, that's what the article is about.
  - qiqitori 6y ago
    Yes, but not Docker. (Also Podman is developed by Red Hat.) I think they have rather high hopes there, and are more likely to just shoot themselves in the foot by being one of a small number of distros that don't have Docker. In fact, rebuilders of RHEL (e.g. Oracle Linux) should maybe consider explicitly supporting Docker. "We are 100% compatible with RHEL but additionally also support Docker" definitely makes for better marketing copy than just "We are 100% compatible with RHEL".
lifeisstillgood 6y ago
Is it feasible to use podman to deploy to AWS?
- zelly 6y ago
  Stick to OCI-compatible images and there should not be a problem
wooque 6y ago
Nope, it's still not there, simplest things work but as soon as you diverge to something more complex it fails. I tried using it as Docker replacement, but various tools that use docker (using dockerized pip in serverless framework) and complex docker-compose files (dockerized Magento) were broken.
anderspitman 6y ago
I always like to chime in and recommend people check out Singularity[0] containers if they haven't before. It's more common in academia because you can run containers without privileges which is nice in HPC environments. The containers themselves are simple immutable flat files that can be easily copied around, backed up, etc. There's also no system daemon. It's nice knowing everything you need for your container system exists in the containers themselves and a single singularity executable. No volumes, remembering to append --rm to avoid dangling containers, wondering where the actual images are stored, etc. Of course there are tradeoffs but I like them for certain use cases. [0]: https://sylabs.io/ https://sylabs.io/
no_wizard 6y ago
After reading this thread, I realize that the 4 GB (average) of my vagrant box images wasn't that bad in retrospect, and that loaded a fully baked OS with packages from apt and just required VirtualBox and its extension pack. (this was not an optimized setup, I was such a noob at the time, just trying to wrangle our developer tools) The only reason I moved to docker years ago was I wanted a tighter reproducible workflow (ie docker-compose up) for all other developers, turns out vagrant has (at some point in the last 5 years) solved this problem too, with packer (I didn't know about this 5 years ago for whatever reason) Makes me long for going back to that. At least once you built your base image, it was done and you could just make fast linked images from there. I bet with Alpine you could get a vagrant up in a few minutes tops, then it boots in seconds. Never liked Ruby as a config language, but doing complex things like setting up shared networks and folders was a breeze comparatively I felt. Never used vagrant in a production capacity though. Everywhere I ever worked always deployed to bare metal or essentially we bought our services (cloud functions, semi-managed containers etc)
- doliveira 6y ago
  Ditto. I for one would love to have Vagrantfiles-like Ruby scripts in Docker. Or even Typescript. So many setups would be achievable with simple ifs.
alfiedotwtf 6y ago
Meta: there seems to be two kind of comments here... 1) why the hell would you want Docker-in-Docker 2) I can’t live without Docker-in-Docker
- pensatoio 6y ago
  1) people who haven't used docker very much 2) people who are using docker to do literally everything
- InsaneOstrich 6y ago
  I think there's a disagreement about what Docker-in-Docker actually is. Some people think it's running a docker daemon inside a container, and others think it's accessing the host docker daemon from inside a container by mounting the docker socket as a volume
zelly 6y ago
It's compatible with cgroups v2 unlike the standard Docker. If you're using Fedora, you have to add a kernel parameter to Grub to use cgroups v1 instead. RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implement their own things in parallel (see: Canonical's AppArmor, LXC, OpenZFS), RedHat just goes with what Linux already has like SELinux/cgroups v2/btrfs, which I think is more likely to last and just feels better. If RedHat goes away, I'm fine since I'm ultimately only relying on Linux features. If Canonical goes away, then I'd have to switch to a different stack. That's probably why government, enterprises, Amazon, etc. still prefer RedHat.
- dahfizz 6y ago
  Anecdotally, I've worked with developers at Redhat and Canonical, and the Redhat developers had passion. They really believed in open source and the linux community. In comparison Canonical seemed like Just Another Software Company to me.
  - gitweb 6y ago
    My experience has consistently been the opposite.
    - waheoo 6y ago
      This sounds anecdotal to me.
      - rat9988 6y ago
        As anecdotal as the person he is replying to.
        waheoo 6y ago
        I mean, yeah, thats what I said right?
yalogin 6y ago
Where can I find documentation about the security benefits claimed for podman?
- op00to 6y ago
  Look for blog posts by Dan Walsh.
jimmaswell 6y ago
Sometimes I feel grateful having let all these ephemeral things things pass by without having needed to learn something that was going to stop being "in" so soon.
- speedgoose 6y ago
  Containers are going to be there for a while and while the engine running the containers is not always the same, the command line Docker client and the Dockerfile DSL seem to become the standard for Linux containers.
maurys 6y ago
I've used Podman, SystemD and Buildah. It's great to hack around with. SystemD is particular is very polarizing and I don't want to start a flamewar, but it helped me "get" init systems. Podman seems to have a better security model than Docker, so we were trying it out at work too. Redhat is clearly very invested in this. There was excellent documentation and good tooling around all this.
perlgeek 6y ago
Podman is amazing for CI and dev environments: * It doesn't require special privileges to run * It runs containers as the same UID as the calling user, so directories mounted into the container can't be polluted with files belonging to other UIDs, as Docker tends to do * It's easy to get it to only pull images from custom registries. With docker, this requires some fiddling (at least last I tried). The only thing missing is Debian packages in Debian Stable (currently available in Bullseye aka testing).
strzibny 6y ago
I am still thinking whether to include Docker or Podman in my book[0]? Since I am leaning towards RH tech (like SELinux), I think I will go with Podman. I think it's the future on Fedora-based systems. [0] https://deploymentfromscratch.com/ https://deploymentfromscratch.com/
IceWreck 6y ago
For anyone not using Podman just because lack of docker compose like functionality, there are multiple alternatives. * Podman's official stance is to use Kubernetes YAML. The provide tools to generate this as well as convert docker-compose to kubeyaml * podman-compose is not official, but it works well. you have to note that its not 100% compatible with dc but a lot of dc files run out of the box without modifications * ansible with podman * i personally use the podman cli with makefiles to get docker-compose like functionality * also, podman v2 supports a docker comptaible rest api so its possible that docker-compose can be modified to support podman in the future
- torvald 6y ago
  I pray for a Hashicorp Nomad driver as well!
  - torvald 6y ago
    Hi, it exists <https://www.nomadproject.io/docs/drivers/podman https://www.nomadproject.io/docs/drivers/podman>! This has gone right passed me.
- 8fingerlouie 6y ago
  podman-compose works really well IMO. For my stacks, the only thing i can't get working is routing a specific container through a host defined network (not a container). I'm certain podman can do it, i just haven't had the time to "fiddle" with it. With docker (compose) i just define an ipam network (external) matching the host adapters network, and connect the containers to that network, and the spice begins to flow.
stephankoelle 6y ago
Podman is really a nice piece of software, we are using it successfully on debinan 10.
pjmlp 6y ago
And so it starts, the journey to something else. Thanks Docker.
edwintorok 6y ago
If you are running podman rootless it will use the fuse-overlayfs driver which comes with various limitations and is much slower than Docker: * you are limited to 1024 FDs for your entire container. So running make -j40 usually ends up with various errors due to running out of file descriptors. You can of course raise the limit for your own user, but this may not be trivial on a shared system. * getting podman to obey a raised user FD limit is non-trivial on CentOS 8. podman is not well supported on CentOS, you need latest Fedora if you want the various bugs/limitations fixed. * fuse-overlayfs is a single process for the entire container and quickly becomes the bottleneck for any IO intensive operation (e.g. don't try running AFL inside podman, it'll be way too slow and peg the CPU at 99% running fuse-overlayfs). Fuse shouldn't be necessary though if I could just give it access to the files that my user has access to (of course you'd loose the snapshotting/committing ability), perhaps using -v would improve performance? Using docker on CentOS 7 was a lot easier (and faster) than using podman on CentOS 8.
mleonhard 6y ago
Does Podman let you get the real SHA-256 digest of the image, pull it to a machine, and then launch the image only if it matches the specified SHA-256 digest? The podman 'create' command docs [1] do not list a '--digest' argument. I found no example of specifying the digest as part of the image name. Docker does not support this. You can get an image file and calculate the SHA-256 digest of it. But Docker does not let you say "start a container using this particular SHA-256". That's because the SHA-256 that docker uses internally is just a hash of dockerd's internal metadata about the image. That metadata is different on every machine. I felt extremely disappointed when I discovered this. And I lost a lot of respect for the Docker developers. If you want to deploy based on image hash with Docker, you must add your own verification step before creating each container instance. Terraform's docker plugin does not perform this step. And the local dockerd will not check the SHA-256 on reboot. If you just follow Docker's "best practices" and use the provided tools, all of these sources will needlessly have root on everything you deploy: - Your docker image repository - Any machines with credentials to push to your docker image repository (CI system, engineer machines, anyone with access to engineer machine backups) - Anyone with permission to push any public image that you use. The way most CI systems are configured, all jobs get the same credentials. So this includes your build and test jobs. That fancy linter Docker image you're using? Anyone who can push to its Dockerhub account can replace the image version you selected with one that roots all of your systems. - Dockerhub itself Why would RedHat switch to a Docker replacement without this crucial security feature? Am I missing some important point that makes all of this ok? [1] http://docs.podman.io/en/latest/markdown/podman-create.1.html http://docs.podman.io/en/latest/markdown/podman-create.1.htm...

466 points by indentit 6y ago

husamia 6y ago

Does it support GPU when installed on Windows 10 WSL1?

musicale 6y ago

I'm not familiar with Podman but I welcome any alternative to Docker.

rhatdan 6y ago

Hopefully most of you who have had issues with Podman have opened bug reports or issues. We are working to fix incompatibility bugs and getting out new releases all the time. As far as docker-compose support, in Podman 2.0 we have added APIV2. This is a socket activation REST API. This API has a compatibility mode that implements the "Docker API" meaning podman can be setup to listen on the docker.sock and launch containers. We also have the more advanced Podman API for support of concepts like Pods. The API should be able to work with docker-py based scripts and Compose. We are getting lots of community support in fixing up our inconsistencies. This is a fully open source project and we love to get contributions.

freedomben 6y ago
This is incredible news! My only reason for using docker still are images that have you mount in the docker.sock and they introspect on it (such as jwilder/nginx-proxy). The day I can move over completely will be a good day.

upnrunning2140 6y ago

I'm an enduser and I expect things to "just work". That seems to match a lot with Red Hat's Linux distros (i.e. RHEL): "Just use it, it's a defacto standard so most third party software is tested on it, don't worry about underlying components as Red Hat has made sane choices for you." That's the theory (and Red Hat's marketing). I wish I could just be using CentOS/RHEL and not worry about the choices Red Hat makes. But the shit is piling up (sorry for my harsh words, no offence intended). So, let's containerise something simple on top of the "centos" container image, let's say postfix. Oh, postfix on centos needs systemd for logging. But systemd in a container is a nightmare. You can get systemd to work in a container if the host system is using containerd and you pass certain special files from the host to the container. So just use Podman instead of Docker, right? Podman has functionality to make systemd in a container work. OK, I can run my container on my fat workstation (a Centos system with Podman). But is it still portable? Can I just run it in Github Actions, AWS ECS, a Windows machine with Docker Desktop? Nope. It's not portable. Let's put the systemd rant aside (I really like the systemd CLI UX, but the architecture (dbus, etc) seems to only serve one usecase properly (Desktop systems) and seems to be heavily wrong for the container usecase). Let's rant about the architectural choices Red Hat is making for containers. Before Red Hat started to get involved there was the open source, (now) cross-platform containerd that a lot of tools are building on top. It consumes the low level runtime runc and both provides an API for Kubernetes (CRI) and additional things. It is highly pluggable and therefore the "only container runtime you'll ever need". And it's purely community governed (CNCF). What is Red Hat doing? Are they building their container tools on top of containerd? Nope. They create their own low level container runtime (crun), their own mid level container runtime (cri-o). But cri-o only covers what's needed for Kubernetes. So to be able to build container images, etc (the "working with containers on a single machine" usecase) additional tools are needed (podman, buildah, skopeo) and they have to implement the missing functionality themselves. So Red Hat's Open Shift (Kubernetes distribution) builds on an entirely different stack than Podman. Fragmentation everywhere. Was that really necessary? Why should I care as an enduser? Well, I can inspect and debug all tools that use containerd the same way (i.e. using the "ctr" tool). I can relatively easily even write my own tools that use containerd (via it's grpc api) and can access the resources (containers, images, etc) that these tools are managing to solve my special custom needs. For the Red Hat stuff everything is different. I could work with cri-o using crictl and write custom tools using cri interface. For Podman I would need to use Podman's API. (Which has annoyingly entirely changed between v1 and v2). ok, enough rant (I could go on with how hard it is to get an up to date version of podman on a supported RHEL system even with app streams, that UBI images don't provide podman/buildah/skopeo, etc etc etc). Please don't mistake me: Podman, cri-o, crun, open shift are all amazing technologies. And it's great that they are mostly open source via upstream projects. But I wish this whole fragmentation hadn't happened. For me as an enduser it's nightmare.

upnrunning2140 6y ago
and yes, people have proven that it's possible to build something like podman or buildah on top of containerd / buildkit! No need to reinvent the wheel! https://github.com/rancher/k3c https://github.com/rancher/k3c https://github.com/genuinetools/img https://github.com/genuinetools/img
freedomben 6y ago
Disclaimer: I work for Red Hat, but I don't code or design any of the things you've mentioned here. Opinions are my own. I think I just gave you your first ever upvote on HN! Thanks for this post, it's great discussion. Regarding Postfix/systemd issues, you should take a look at ubi-init image. It has a minimal systemd in it to address problems like that[1][2]. Regarding crun, have you looked at the "Why another implementation" in the crun README.md by chance?[3] Or have you read the blog post about it that goes into a lot more detail?[4] I totally agree with the dislike toward fragmentation. I myself have been very critical of NIH and fragmentation when it happens. I do think there's an interesting case to be made for crun though. [1]: https://developers.redhat.com/products/rhel/ubi https://developers.redhat.com/products/rhel/ubi [2]: https://catalog.redhat.com/software/containers/ubi8/ubi-init/5c359b97d70cc534b3a378c8 https://catalog.redhat.com/software/containers/ubi8/ubi-init... [3]: https://github.com/containers/crun https://github.com/containers/crun [4]: https://www.redhat.com/sysadmin/introduction-crun https://www.redhat.com/sysadmin/introduction-crun
- upnrunning2140 6y ago
  thanks for the response and the links! I will certainly have a look. (And again sorry for my rather harsh words - I have a lot of respect for all the hard work everyone at Red Hat is doing. I can only imagine that it's much harder to make technical decisions and build tools like Podman than it looks like. Thank you for not taking my rant as an offence! It's just my brutally raw user experience).
rhatdan 6y ago
containerd is a daemon, which actually came out after CRI-O. But anyways the hole idea is Podman and Buildah was to get away from using root running daemons to launch containers. The important thing about containers is that we launch we all follow the standards. Podman, Docker, CRI-O, Buildah, Containerd all use the same OCI based images available at container registries, and all launch them the same time via OCI Runtimes. These runtimes can be runc, crun, kata, krun, gVisor ... There is no fragmentation on OCI, which is important. Think of these as been web content, you have lots of choice on viewing and using web content, firefox, chrome, safari, IE, curl, linx, wget... All of these tools (Podman, Buildah, Skopeo, CRI-O) that can interact with the OCI content and all have different strengths. Please do not add FUD about systemd. None of the new container engines require systemd, they all can run and support all images at Docker.io. The new container engines support systemd better then Docker did, but they do NOT require it.

sdan 6y ago

> One of Podman’s greatest advantages is its complete CLI compatibility with Docker. In fact, when building Podman, Docker users can adapt without any significant changes. For example, you can use the alias command to create a docker alias for Podman: `alias docker=podman` Wow that's a great adoption hack; just alias another program as another

xenocratus 6y ago
Would that be covered by the same issue as Google v Oracle?
- igneo676 6y ago
  Maybe, but it wouldn't matter if they're OSS to begin with
  - xenocratus 6y ago
    That's true, don't know why I didn't think of that to begin with, just saw them as "products" from two companies.
  - deleted 6y ago
    [deleted]

joncp 6y ago

I like the daemonless architecture a lot, but until there's a quick and painless way to install it on OSX and Windows developer machines, you're going to see very limited uptake.

nickysielicki 6y ago
I find it somewhat surprising that we haven't seen more adoption of the redhat docker (lowercase d) replacements after Docker (uppercase d) started pushing some of their monetization efforts. The conclusion that I have to reach is that there are more docker users on Macbooks than I realized.
deleted 6y ago
[deleted]
GordonS 6y ago
I was just thinking the same thing, and was going to ask if there was anything like Docker Desktop, something to make it simple to use on Windows/MacOS!
- mikey_p 6y ago
  Before there was Docker Desktop on Mac there was Docker Machine. And of course there's a Podman Machine: https://developers.redhat.com/blog/2020/02/12/podman-for-macos-sort-of/ https://developers.redhat.com/blog/2020/02/12/podman-for-mac...
laaman02 6y ago
Maybe it doesn't count but podman works great on WSL2 as far as I can tell.
throwaway894345 6y ago
I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right direction.

gigatexal 6y ago

Any docker Podman corner cases that people have run into? I like the idea of rootless containers but I can do that ether easily by adding one line to my dockerfile or adding a user flag when I run a docker container. What other advantages am I getting?

tick_tock_tick 6y ago
This isn't about root inside the container but rather it doesn't need root on the host system.
deleted 6y ago
[deleted]
pydry 6y ago
No need to run a daemon. Security is better.
- educar 6y ago
  If you lock down the docker user, is it a problem?
  - soraminazuki 6y ago
    The biggest issue lies not in the few lines in /etc/passwd or /etc/group, but rather the highly privileged process with a large attack surface that is the Docker daemon.
    - redis_mlc 6y ago
      Docker in production is the Dominion voting machine of the IT world. :)
fisxoj 6y ago
Generally, it's been pretty easy to transition for me, but I used to rely on things like the automatic nginx image that you need to mount the docker socket into so it can route traffic to containers when they come up. Since there's no daemon, there wasn't a way to do that. I think people are working on it, but I haven't tried recently. Work also uses a special docker RUN command that can use the host's ssh keyring to, eg. Install something from a private github repo. Doesn't seem to exist in podman.

x87678r 6y ago

I really struggled with podman, a bunch of containers (I cant remember which ones) didn't work, and build tools choked as well. At work we dont get root access so I thought it would be perfect but sysadmins couldn't figure out how to configure either so was bust there too.

deleted 6y ago
[deleted]
aduffy 6y ago
I've also personally struggled a lot with this at $WORK, but some of the new features in RHEL 7.8+ (specifically GA'ing of the fuse-overlayfs graph driver) have actually alleviated a ton of the issues I've seen previously. If you haven't tried that I'd certainly recommend it, YMMV
siscia 6y ago
I had the opposite experiences, everything worked out of the box.
dnautics 6y ago
I just installed my new $WORK docker-compose using podman and podman-compose, and it worked out of the box. To be fair, I failed at it one time before at previous job... So... Coin flip?
- circularfoyers 6y ago
  I had a repeat of the same experience too recently. It was very satisfying having it work now.

lopatin 6y ago

I was just about to complain about another thing to learn. Then I saw you can do "$ alias docker=podman". Just want to acknowledge the importance of that work. Making things compatible is both boring and a pain, but it's a door opener for people like me who refuse to learn your new API because I know a decent one already.

freedomben 6y ago
Completely agree. One thing I want to point out though for anybody not familiar with the differences between podman and docker, for the most part alias docker=podman will "just work" except for these situations: 1. docker-compose. podman-compose attempts to cover this but I've heard it's not quite there yet 2. Mounting the docker socket into the container. Podman is daemonless which means that won't work. There is work going on right now to allow Podman to be driven in a similar way if needed, but I recently tried to set it up and hit a bug[1]. CRI-O brings a daemon, and it is used extensively in Kubernetes and OpenShift, but not so much outside of that. [1] https://github.com/containers/podman/issues/8323 https://github.com/containers/podman/issues/8323
- hda111 6y ago
  It’s now possible to mount a docker compatible socket inside the container using podman.
  - freedomben 6y ago
    Can you provide more information on this? A blog post or some instructions? I'd like to read more.
capelio 6y ago
Unless you're optimizing for stagnation, this really is a terrible approach to reaping the benefits of innovation. If your prereq to trying something better is that it needs to mirror something that's "decent already," you'll spend most of your life stuck on the same plateau.

kitotik 6y ago

Daemonless and rootless are killer features. The lack of filesystem isolation and volume support are the last things keeping me from jumping ship.

lifty 6y ago
Rootless is coming to Docker as well since containerd switched to cgroups v2, which was a requirement for rootless
- AkihiroSuda 6y ago
  Docker has been supporting rootless mode since 19.03
AkihiroSuda 6y ago
Podman already supports `podman volume create`, though it doesn't support volume plugins.

ranadeep 6y ago

At my company, we run our CI/CD (Jenkins) using the Docker-in-Docker paradigm to facilitate easy maintainability of the CI itself and allow us to run containerized builds. When we shifted to RHEL 8, we attempted to move this over to Podman and it went miserably (this was back in November 2019). The main reason being is that podman-in-podman doesn't work and had bugs (at least back in Nov 2019). Maybe it fixed now but this was our experience. We ended up doing quite a bit of analysis on podman only to conclude it's simply not there yet relative to docker (ecosystem and ergonomics). There are quite a few corner cases that docker quite simply supports out of the box beautifully that podman doesn't support or just has bugs. I like the what the project is trying to solve by being daemonless, but this is not as simple as a drop in replacement for docker that RedHat markets it as (alias docker=podman). We ended up sticking to docker professionally and personally, I am still using docker over podman. The ecosystem and ergonomics are just far too nice to give up over podman.

ctalledo 6y ago
If you are using Docker-in-Docker, you may want to checkout the new Sysbox runtime (find it on Github). It's a new type of runc that sits below Docker and creates rootless containers capable of running Docker, systemd, K8s, etc. All you have to do is "docker run --runtime=sysbox-runc" <some-image-with-docker> and you'll get a docker daemon that is fully isolated from the host. It's a great way of avoiding privileged containers or mounts to the host docker socket.
choeger 6y ago
Maybe you are just too far into docker. I noticed that a lot of default workflows (needlessly) depended on docker running with privileges. One big reason for that seem to be Mac users that only know docker from inside a VM. However, if you think about what you're really needing for CI you will easily see that docker-in-docker gains you nothing. You can as well use plain docker (or podman). The same holds for privileges. No CI operation should need privileges, if only for the reason that it should never alter the CI system itself. I encourage you to not take the standard workflows as a given and really think about what you need and I bet you either end up with a use case that can be covered by rootless podman or something that requires real VMs anyways.

Jonnax 6y ago

Is the Docker daemon actually a huge security hole? I see people championing Podman because it's daemonless but is it actually beneficial or is it championed because it's Red Hat and a case of security check boxing?

choeger 6y ago
It certainly is a gaping hole. But the machines that docker runs on in my experience have a 100% sudoers ratio, so the practical impact is limited.
- yjftsjthsd-h 6y ago
  Do you mean in that adding a user to the docker group is effectively handing them root? Because if you don't do that, then running docker requires root/sudo, which means that it should be exactly as secure as anything else
eeZah7Ux 6y ago
> Is the Docker daemon actually a huge security hole? Yes. Also the containers on docker hub are a security dumpster fire.
soraminazuki 6y ago
It's a root daemon which can be made to run arbitrary commands by anyone using its interface, so yes it is a huge, huge security burden. You can't just brush that off as a superficial problem.
- educar 6y ago
  Given that the most common case is running docker in server environments in VMs and the sysadmins are root, is this a real issue? Can you tell me an environment where a multi-tenant system runs docker?
  - soraminazuki 6y ago
    Yes, it[1] is[2] a[3] real[4] issue[5] which leads to privilege escalation bugs. It also doesn't help that most containers that Docker is responsible for managing is supposed to be unprivileged, and Docker itself is commonly used as a component for a multi-tenant container runtime. [1] https://www.cvedetails.com/cve/CVE-2019-15752/ https://www.cvedetails.com/cve/CVE-2019-15752/ [2] https://www.cvedetails.com/cve/CVE-2019-14271/ https://www.cvedetails.com/cve/CVE-2019-14271/ [3] https://www.cvedetails.com/cve/CVE-2019-5736/ https://www.cvedetails.com/cve/CVE-2019-5736/ [4] https://www.cvedetails.com/cve/CVE-2018-15664/ https://www.cvedetails.com/cve/CVE-2018-15664/ [5] https://www.cvedetails.com/cve/CVE-2018-15514/ https://www.cvedetails.com/cve/CVE-2018-15514/

Cu3PO42 6y ago

I love the idea of Podman being daemonless and (potentially) rootless. Regardless of the presence of security flaws in dockerd, the Podman architecture just feels cleaner. And the CLI compatibility is great. Until it isn't. At work we switched to Podman for a small deployment because Docker didn't yet work with cgroupsv2 and many hours were spent debugging Podman-specific issues. In the end switching to cgroupsv1 would have been significantly less work. Therefore claiming you can `alias docker=podman` is a bit disingenuous. You can, but only if you don't do anything Podman can't handle and what it can and cannot handle isn't immediately obvious. All that said, I wish the project the best and hope it reaches the maturity where this alias actually does work.

babarock 6y ago
Genuinely curious what issues you came across. Any chance you documented them somewhere?
- Cu3PO42 6y ago
  I'm afraid I didn't and I cannot really recall, but many were related to networking. I think one was that I couldn't have two containers on the same network listen to the same port, another one was related to Podman not playing nice with nftables, but the specifics elude me. EDIT: Upon further reflection, I think Docker doesn't really work with nftables either, so that one isn't on Podman. It just so happened we made that switch at the same time. Regardless, there were other problems. I'll check to see if I can find any records of the problems later.

znpy 6y ago

Last time I tried podman it looked very cool being rootless and daemonless, except that since it's rootless I couldn't create the necessary network interfaces... making it pretty much worthless.

fuzxi 6y ago
So run it as root then? Am I missing something?
- DangitBobby 6y ago
  If GP thinks the selling point of podman is that it doesn't have to run as root, but to actually do anything meaningful they have to run it as root after all, why would they use podman?
  - znpy 6y ago
    A rootless docker would greatly simplify some use cases... For example, no need to do docker in docker. Edit: apparently now net4slirp is recommended... Maybe I'll give it another try.
  - fuzxi 6y ago
    The other major benefit of podman is that it doesn't use a daemon.
    - speedgoose 6y ago
      Many people say that, but don't feel like it's very important. Having a deamon or not is a technical detail that most people do not care about in my opinion. And it has advantages too, like accessing Docker remotely or from another VM on the same host, or directly from the host which is nice for Docker on Mac or Windows.
      - fuzxi 6y ago
        See replies here [1] for more information [1]: https://news.ycombinator.com/item?id=25165789 https://news.ycombinator.com/item?id=25165789

arianvanp 6y ago

freedomben 6y ago
Looks like you may have double posted. Not complaining, just letting you know in case it was unintentional: https://news.ycombinator.com/item?id=25166141 https://news.ycombinator.com/item?id=25166141

arianvanp 6y ago

I find the podman integrates with systemd well claims a bit dubious. Last time I checked both podman and CRI-O double fork and have reimplemented process supervision from scratch (through conmon) whilst they could get all those features for free if they didn't daemonize themselves and let systemd handle running things in the background. I found this very surprising. I still don't understand why they made that choice. At least they do play nice with the whole "systemd owns the Cgroups tree" story. A thing that was always a bit painful with docker. Fun note. Systemd-nspawn actually can run OCI containers directly as well these days. However I'm not sure if it's feature-complete

candiddevmike 6y ago
In an ideal world, systemd-nspawn would be the preferred CRI. That was basically the goal of rkt.
- mongol 6y ago
  What happened?
foresto 6y ago
Perhaps that choice comes from wanting their target platform to be linux, rather than systemd?

downrightmike 6y ago

He literally says Ah pah shae, no its Apache, its been around forever. (x) Doubt

yobert 6y ago

We've tried this (podman 2.0.5) and have hit some really really annoying bugs: - Build layer cache doesn't seem to work. If I rebuild locally with podman, it correctly detects cache hits and the build is fast. On our Jenkins server (RHEL 8) with podman 2.0.5 it doesn't. It randomly doesn't cache hit, causing builds to take 20x longer than with docker CE. - Podman is insanely slow at building images in general. COPY emptyfolder/ /emptyfolder/ takes 2 seconds. We have dozens of things to COPY and it's stupid slow compared to docker CE. Buildah doesn't seem any better. - Systemd integration has bugs. If you use the default generated systemd unit file, it does not kill processes when exiting and leaves them dangling. Even after removing the strange KillMode=none it says to put in there, it still leaves processes dangling. Podman sometimes loses track of the container. It will list nothing in "podman ps" but the processes will still be running.

viraptor 6y ago
Are you trying to use cache-from? This is explicitly not supported: > --cache-from > Images to utilize as potential cache sources. Podman does not currently support caching so this is a NOOP.
- yobert 6y ago
  Not using --cache-from, though I did try the various caching command line options to try to troubleshoot. Just a vanilla Dockerfile with a few RUN commands and COPY commands. It would hit cache until about the third layer, and then would cache break every time. On my local computer (Arch) podman is v2.1.1, which seems to have whatever bug I was hitting fixed. So I guess my complaint isn't about podman specifically-- It had bugs and they were fixed, and that's great. But I hate that RHEL 8 touts it as a docker replacement, and won't carry docker in their repositories, when the version they have in their production releases is so broken. We eventually sledgehammered docker CE's CentOS repo into our RHEL 8 jenkins server and now everything works perfectly. Running podman on the production webservers seems to work okay though-- apart from the process killing problems.
  - fatherlinnux 6y ago

justaguy88 6y ago

I'm finding podman great for my (not actually that complicated) docker use-cases

nimbius 6y ago

Podman, buildah, and skopeo are insanely awesome tools that let you transition an image from a public registry to your own private deployment in a jiffy. The article doesn't mention it but podman can also dump a pod configuration you can use in kubernetes and open shift/okd so if you're not a yaml wizard you can still get stuff running containerized.

nikisweeting 6y ago

Lack of a drop-in docker-compose replacement is what stopped me last time I tried podman. podman-compose looked decent but it lacked a bunch of basic features and didn't work smoothly last time I tried it.

qiqitori 6y ago

Assuming that it's Red Hat's fault that there is no el8 package for Docker, I think Red Hat is really shooting themselves in the foot by not supporting Docker in RHEL8. (You can still install the el7 version of Docker on el8 by performing an enable/disable/enable/disable/... module dance, but... why isn't there just an el8 version?)

bonzini 6y ago
Red Hat ships podman for RHEL8, that's what the article is about.
- qiqitori 6y ago
  Yes, but not Docker. (Also Podman is developed by Red Hat.) I think they have rather high hopes there, and are more likely to just shoot themselves in the foot by being one of a small number of distros that don't have Docker. In fact, rebuilders of RHEL (e.g. Oracle Linux) should maybe consider explicitly supporting Docker. "We are 100% compatible with RHEL but additionally also support Docker" definitely makes for better marketing copy than just "We are 100% compatible with RHEL".

lifeisstillgood 6y ago

Is it feasible to use podman to deploy to AWS?

zelly 6y ago
Stick to OCI-compatible images and there should not be a problem

wooque 6y ago

Nope, it's still not there, simplest things work but as soon as you diverge to something more complex it fails. I tried using it as Docker replacement, but various tools that use docker (using dockerized pip in serverless framework) and complex docker-compose files (dockerized Magento) were broken.

anderspitman 6y ago

I always like to chime in and recommend people check out Singularity[0] containers if they haven't before. It's more common in academia because you can run containers without privileges which is nice in HPC environments. The containers themselves are simple immutable flat files that can be easily copied around, backed up, etc. There's also no system daemon. It's nice knowing everything you need for your container system exists in the containers themselves and a single singularity executable. No volumes, remembering to append --rm to avoid dangling containers, wondering where the actual images are stored, etc. Of course there are tradeoffs but I like them for certain use cases. [0]: https://sylabs.io/ https://sylabs.io/

no_wizard 6y ago

After reading this thread, I realize that the 4 GB (average) of my vagrant box images wasn't that bad in retrospect, and that loaded a fully baked OS with packages from apt and just required VirtualBox and its extension pack. (this was not an optimized setup, I was such a noob at the time, just trying to wrangle our developer tools) The only reason I moved to docker years ago was I wanted a tighter reproducible workflow (ie docker-compose up) for all other developers, turns out vagrant has (at some point in the last 5 years) solved this problem too, with packer (I didn't know about this 5 years ago for whatever reason) Makes me long for going back to that. At least once you built your base image, it was done and you could just make fast linked images from there. I bet with Alpine you could get a vagrant up in a few minutes tops, then it boots in seconds. Never liked Ruby as a config language, but doing complex things like setting up shared networks and folders was a breeze comparatively I felt. Never used vagrant in a production capacity though. Everywhere I ever worked always deployed to bare metal or essentially we bought our services (cloud functions, semi-managed containers etc)

doliveira 6y ago
Ditto. I for one would love to have Vagrantfiles-like Ruby scripts in Docker. Or even Typescript. So many setups would be achievable with simple ifs.

alfiedotwtf 6y ago

Meta: there seems to be two kind of comments here... 1) why the hell would you want Docker-in-Docker 2) I can’t live without Docker-in-Docker

pensatoio 6y ago
1) people who haven't used docker very much 2) people who are using docker to do literally everything
InsaneOstrich 6y ago
I think there's a disagreement about what Docker-in-Docker actually is. Some people think it's running a docker daemon inside a container, and others think it's accessing the host docker daemon from inside a container by mounting the docker socket as a volume

zelly 6y ago

It's compatible with cgroups v2 unlike the standard Docker. If you're using Fedora, you have to add a kernel parameter to Grub to use cgroups v1 instead. RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implement their own things in parallel (see: Canonical's AppArmor, LXC, OpenZFS), RedHat just goes with what Linux already has like SELinux/cgroups v2/btrfs, which I think is more likely to last and just feels better. If RedHat goes away, I'm fine since I'm ultimately only relying on Linux features. If Canonical goes away, then I'd have to switch to a different stack. That's probably why government, enterprises, Amazon, etc. still prefer RedHat.

dahfizz 6y ago
Anecdotally, I've worked with developers at Redhat and Canonical, and the Redhat developers had passion. They really believed in open source and the linux community. In comparison Canonical seemed like Just Another Software Company to me.
- gitweb 6y ago
  My experience has consistently been the opposite.
  - waheoo 6y ago
    This sounds anecdotal to me.
    - rat9988 6y ago
      As anecdotal as the person he is replying to.
      - waheoo 6y ago
        I mean, yeah, thats what I said right?

yalogin 6y ago

Where can I find documentation about the security benefits claimed for podman?

op00to 6y ago
Look for blog posts by Dan Walsh.

jimmaswell 6y ago

Sometimes I feel grateful having let all these ephemeral things things pass by without having needed to learn something that was going to stop being "in" so soon.

speedgoose 6y ago
Containers are going to be there for a while and while the engine running the containers is not always the same, the command line Docker client and the Dockerfile DSL seem to become the standard for Linux containers.

maurys 6y ago

I've used Podman, SystemD and Buildah. It's great to hack around with. SystemD is particular is very polarizing and I don't want to start a flamewar, but it helped me "get" init systems. Podman seems to have a better security model than Docker, so we were trying it out at work too. Redhat is clearly very invested in this. There was excellent documentation and good tooling around all this.

perlgeek 6y ago

Podman is amazing for CI and dev environments: * It doesn't require special privileges to run * It runs containers as the same UID as the calling user, so directories mounted into the container can't be polluted with files belonging to other UIDs, as Docker tends to do * It's easy to get it to only pull images from custom registries. With docker, this requires some fiddling (at least last I tried). The only thing missing is Debian packages in Debian Stable (currently available in Bullseye aka testing).

strzibny 6y ago

I am still thinking whether to include Docker or Podman in my book[0]? Since I am leaning towards RH tech (like SELinux), I think I will go with Podman. I think it's the future on Fedora-based systems. [0] https://deploymentfromscratch.com/ https://deploymentfromscratch.com/

IceWreck 6y ago

For anyone not using Podman just because lack of docker compose like functionality, there are multiple alternatives. * Podman's official stance is to use Kubernetes YAML. The provide tools to generate this as well as convert docker-compose to kubeyaml * podman-compose is not official, but it works well. you have to note that its not 100% compatible with dc but a lot of dc files run out of the box without modifications * ansible with podman * i personally use the podman cli with makefiles to get docker-compose like functionality * also, podman v2 supports a docker comptaible rest api so its possible that docker-compose can be modified to support podman in the future

torvald 6y ago
I pray for a Hashicorp Nomad driver as well!
- torvald 6y ago
  Hi, it exists <https://www.nomadproject.io/docs/drivers/podman https://www.nomadproject.io/docs/drivers/podman>! This has gone right passed me.
8fingerlouie 6y ago
podman-compose works really well IMO. For my stacks, the only thing i can't get working is routing a specific container through a host defined network (not a container). I'm certain podman can do it, i just haven't had the time to "fiddle" with it. With docker (compose) i just define an ipam network (external) matching the host adapters network, and connect the containers to that network, and the spice begins to flow.

stephankoelle 6y ago

Podman is really a nice piece of software, we are using it successfully on debinan 10.

pjmlp 6y ago

And so it starts, the journey to something else. Thanks Docker.

edwintorok 6y ago

If you are running podman rootless it will use the fuse-overlayfs driver which comes with various limitations and is much slower than Docker: * you are limited to 1024 FDs for your entire container. So running make -j40 usually ends up with various errors due to running out of file descriptors. You can of course raise the limit for your own user, but this may not be trivial on a shared system. * getting podman to obey a raised user FD limit is non-trivial on CentOS 8. podman is not well supported on CentOS, you need latest Fedora if you want the various bugs/limitations fixed. * fuse-overlayfs is a single process for the entire container and quickly becomes the bottleneck for any IO intensive operation (e.g. don't try running AFL inside podman, it'll be way too slow and peg the CPU at 99% running fuse-overlayfs). Fuse shouldn't be necessary though if I could just give it access to the files that my user has access to (of course you'd loose the snapshotting/committing ability), perhaps using -v would improve performance? Using docker on CentOS 7 was a lot easier (and faster) than using podman on CentOS 8.

mleonhard 6y ago

Does Podman let you get the real SHA-256 digest of the image, pull it to a machine, and then launch the image only if it matches the specified SHA-256 digest? The podman 'create' command docs [1] do not list a '--digest' argument. I found no example of specifying the digest as part of the image name. Docker does not support this. You can get an image file and calculate the SHA-256 digest of it. But Docker does not let you say "start a container using this particular SHA-256". That's because the SHA-256 that docker uses internally is just a hash of dockerd's internal metadata about the image. That metadata is different on every machine. I felt extremely disappointed when I discovered this. And I lost a lot of respect for the Docker developers. If you want to deploy based on image hash with Docker, you must add your own verification step before creating each container instance. Terraform's docker plugin does not perform this step. And the local dockerd will not check the SHA-256 on reboot. If you just follow Docker's "best practices" and use the provided tools, all of these sources will needlessly have root on everything you deploy: - Your docker image repository - Any machines with credentials to push to your docker image repository (CI system, engineer machines, anyone with access to engineer machine backups) - Anyone with permission to push any public image that you use. The way most CI systems are configured, all jobs get the same credentials. So this includes your build and test jobs. That fancy linter Docker image you're using? Anyone who can push to its Dockerhub account can replace the image version you selected with one that roots all of your systems. - Dockerhub itself Why would RedHat switch to a Docker replacement without this crucial security feature? Am I missing some important point that makes all of this ok? [1] http://docs.podman.io/en/latest/markdown/podman-create.1.html http://docs.podman.io/en/latest/markdown/podman-create.1.htm...