TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Docker is dead? Podman – an alternative tool?

272 点作者 F_J_H将近 3 年前

29 条评论

smarx007将近 3 年前
How did the intro get so many things wrong?!<p>1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See <a href="https:&#x2F;&#x2F;techcrunch.com&#x2F;2019&#x2F;11&#x2F;13&#x2F;mirantis-acquires-docker-enterprise&#x2F;" rel="nofollow">https:&#x2F;&#x2F;techcrunch.com&#x2F;2019&#x2F;11&#x2F;13&#x2F;mirantis-acquires-docker-e...</a> and <a href="https:&#x2F;&#x2F;www.docker.com&#x2F;blog&#x2F;docker-enterprise-edition&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.docker.com&#x2F;blog&#x2F;docker-enterprise-edition&#x2F;</a><p>2. k8s didn&#x27;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 <a href="https:&#x2F;&#x2F;kubernetes.io&#x2F;blog&#x2F;2022&#x2F;01&#x2F;07&#x2F;kubernetes-is-moving-on-from-dockershim&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kubernetes.io&#x2F;blog&#x2F;2022&#x2F;01&#x2F;07&#x2F;kubernetes-is-moving-o...</a><p>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&#x2F;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.<p>4. RedHat offers not only packages in RHEL but also support and it makes sense they will offer packaging <i>and support</i> only for podman (a RH project) going forward. This does not concern us who don&#x27;t pay for RH support.<p>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.
评论 #31619503 未加载
评论 #31749972 未加载
评论 #31619086 未加载
评论 #31620667 未加载
评论 #31619339 未加载
qbasic_forever将近 3 年前
Rootless podman is my first choice for using containers now, it works fantastically well in my experience. It&#x27;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&#x27;s so much easier and better than the root privileged daemon.<p>I really wish rootless podman&#x2F;docker was the default install now. It&#x27;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 &quot;run this install script and you&#x27;re done&quot;.
评论 #31618237 未加载
评论 #31618693 未加载
评论 #31617503 未加载
评论 #31619347 未加载
评论 #31618578 未加载
评论 #31617814 未加载
评论 #31631780 未加载
jordemort将近 3 年前
Why not both?<p>Since Podman 4.1 came out with full Compose 2.x compatibility, I&#x27;m running Podman on Docker&#x27;s socket, but using Docker&#x27;s CLI to talk to it, so that I can use the buildx and compose CLI plugins. It works great, Docker&#x27;s CLI doesn&#x27;t seem to have any clue that it&#x27;s talking to not-Docker. I even have VSCode&#x27;s Docker extension and Remote Containers working this way.
评论 #31618311 未加载
评论 #31616774 未加载
评论 #31620061 未加载
评论 #31616950 未加载
评论 #31617126 未加载
Havoc将近 3 年前
Think it is rapidly moving towards being more of a data carrier&#x2F;format rather than being dead per se.<p>Half the time you&#x27;re jamming it into some cloud service anyway where you have no idea what GCP&#x2F;fly&#x2F;aws is using under the hood to actually run it.<p>Meaning this discussion is more relevant to the self-hosted context. In which case I&#x27;d say containerization isn&#x27;t really security. So in my mind that residual risk of the daemon being root is inconsequential. (Or if not use a VM).
评论 #31618188 未加载
评论 #31616858 未加载
评论 #31616860 未加载
评论 #31618750 未加载
lapser将近 3 年前
This article misses quite a bit.<p>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.<p>Podman also is currently working on &quot;podman machine&quot;, which can spin up a Linux VM to run Podman on macOS and Windows. I think it&#x27;s still in beta or something, but it seems to be working already.<p>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.<p>[0] <a href="https:&#x2F;&#x2F;podman-desktop.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;podman-desktop.io&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;iongion.github.io&#x2F;podman-desktop-companion&#x2F;" rel="nofollow">https:&#x2F;&#x2F;iongion.github.io&#x2F;podman-desktop-companion&#x2F;</a>
评论 #31625218 未加载
jdoss将近 3 年前
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 <a href="https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;nomad-driver-podman" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hashicorp&#x2F;nomad-driver-podman</a><p>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.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;forem&#x2F;selfhost" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;forem&#x2F;selfhost</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;jdoss&#x2F;ppngx" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jdoss&#x2F;ppngx</a><p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;jdoss&#x2F;25f9dac0a616e524f8794a89b7989e9f" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;jdoss&#x2F;25f9dac0a616e524f8794a89b7989e...</a><p><a href="https:&#x2F;&#x2F;gist.github.com&#x2F;jdoss&#x2F;ad87375b776178e9031685b71dbe37cf" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;jdoss&#x2F;ad87375b776178e9031685b71dbe37...</a>
评论 #31619386 未加载
iknownothow将近 3 年前
It&#x27;s okay to stick with Docker if it works for us right? There&#x27;s nothing fundamentally wrong with it right?<p>At the moment Podman is just more work for us because I and other devs don&#x27;t have years of of experience and intuitions about Podman like we have with Docker. I&#x27;d rather just focus on business problems rather than another migration.
评论 #31617914 未加载
评论 #31619155 未加载
评论 #31620072 未加载
tragictrash将近 3 年前
OCI compatible containers are the future, docker and podman both classify as such.<p><a href="https:&#x2F;&#x2F;opencontainers.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;opencontainers.org&#x2F;</a><p>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.
评论 #31617933 未加载
评论 #31617724 未加载
评论 #31620140 未加载
usr1106将近 3 年前
This article is from a Windows perspective.<p>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.
pid-1将近 3 年前
Docker for Desktop went from being complete garbage to a really nice product.<p>I think Docker folks are heavily focused on providing great local development experiences, which is a niche few other products are covering.
评论 #31616935 未加载
评论 #31618316 未加载
bobobob420将近 3 年前
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
评论 #31616351 未加载
hiroshui将近 3 年前
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!<p>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.<p>We are trying to get all wrong information - based on your discussion - right and summarize them in the refactored article!<p>What can we take away from this? - More research next time is necessary and we need to challenge our article.<p>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.
评论 #31904838 未加载
bdcravens将近 3 年前
&gt; 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.<p>I think this is an area bearing improvement before most dev workflows can switch
评论 #31619396 未加载
pelorat将近 3 年前
I just use LXC, it&#x27;s never failed me and has none of the hype.
评论 #31618824 未加载
评论 #31618706 未加载
评论 #31618629 未加载
mati365将近 3 年前
Have you ever used podman-compose? It&#x27;s amount of bugs and missing features is bigger than actual features count.
评论 #31617455 未加载
colordrops将近 3 年前
NixOS recently switched the default from docker to podman for containers. I don&#x27;t know if it&#x27;s Nix&#x27;s configuration, or a problem with Podman itself, but it&#x27;s unusable. The systemd service often hangs, creating networks errors out, the pod concept doesn&#x27;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&#x27;t the list of images global to the machine? Perhaps I just don&#x27;t get it yet.
评论 #31617384 未加载
评论 #31617453 未加载
评论 #31617514 未加载
TheAceOfHearts将近 3 年前
People complaint about framework or library churn in the JS world, but other ecosystems have the same issue. For people who aren&#x27;t following this ecosystem closely, I just want something that works and gets out of the way with a minimal learning curve.<p>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.
评论 #31621413 未加载
studmuffin650将近 3 年前
Lack of mention of podman machine seems like big miss when talking about podman as an alternative to Docker.
评论 #31615818 未加载
KronisLV将近 3 年前
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.<p>Why?<p>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 &quot;off the happy path&quot; (not everyone has the resources to try and figure out Podman compatibility oddness)<p>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<p>Docker Swarm - most projects out there do not need Kubernetes; personally, i&#x27;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&#x27;t want to mess around with a Kubernetes ingress and somehow feeding certificates into it, you can instead just run your own Apache&#x2F;Nginx&#x2F;Caddy instance and manage it like a regular container with host ports 80&#x2F;443 (setting up which might be a bit more difficult with Kubernetes, because by default you get access to ports upwards of 30000)<p>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<p>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&#x2F;Compose&#x2F;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&#x2F;containerd&#x2F;Kubernetes.<p>I&#x27;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&#x2F;Oracle Linux) in the 20.X releases i think, though personally i&#x27;m more inclined towards using the second-latest Ubuntu LTS because there&#x27;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&#x27;ll just use something like <a href="https:&#x2F;&#x2F;kompose.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kompose.io&#x2F;</a> to migrate over from the Compose format to Kubernetes.<p>Of course, none of that excuses you from having to learn Kubernetes, because that&#x27;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&#x27;t need anything more.<p>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&#x27;t the interest to get more resources and even if there was, then there&#x27;d also be thoughts along the lines of &quot;why should we give this one project that many resources?&quot; expressed. I&#x27;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.<p>I recently went to Europe DevDays 2022 (<a href="https:&#x2F;&#x2F;devdays.lt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;devdays.lt&#x2F;</a>) and DevOps Pro Europe 2022 (<a href="https:&#x2F;&#x2F;devopspro.lt&#x2F;" rel="nofollow">https:&#x2F;&#x2F;devopspro.lt&#x2F;</a>) and one of the arguments expressed was along the lines of: &quot;You should never host your own clusters, if you can. Just pay one of the big three platforms out there (AWS&#x2F;GCP&#x2F;Azure) to do it for you.&quot; 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.<p>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&#x2F;k0s&#x2F;RKE and tools like Lens&#x2F;k9s&#x2F;Portainer&#x2F;Rancher.
评论 #31622097 未加载
throwawei369将近 3 年前
This would all be true if podman wasn&#x27;t a gimped version of docker.
评论 #31617404 未加载
flerp将近 3 年前
Clickbait title ahoy
nanna将近 3 年前
Wouldn&#x27;t this be a good time to adopt guix (or nix) for a next generation upgrade on Docker?
评论 #31620005 未加载
CoolCold将近 3 年前
Article itself and the idea in general seems controversial at best for me.<p>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.<p>Q 1. Docker has some policy change and your company may need to pay for it - if you have &gt; 250 persons&#x2F;10 million revenue A 1: Indi&#x2F;Solo devs out of scope. Enterprises probably fine with that anyways.<p>Q 2. Docker has limits for pulls from Docker hub!!!! You have 100 (200 with login) downloads&#x2F;single IP for 6 hours interval. A 2: It was already mentioned, switching to Podman, while using Dockerhub doesn&#x27;t magically helps. Moreover, practically I find it totally fine for Indi&#x2F;Solo dev. For companies, who&#x27;s amount of pulls can be higher - you want and have in place your local registry anyways to ensure Business Continuity and this doesn&#x27;t bother you much.<p>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&#x2F;is disabled by default in some distros <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28054823" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=28054823</a> - your security &amp; 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]<p>So what is left in &quot;pros&quot; for Podman, have I missed anything?
lolcat_cowsay将近 3 年前
BTW there&#x27;s no alternative to docker compose in podman, I&#x27;ve tried running my docker compose file with podman compose and it just failed outright. Currently I&#x27;m going to stick with Docker because of this alone.
lloydatkinson将近 3 年前
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 &#x2F;sys for the GPIO pins and for I2C etc. does podman have this too?
CottonMcKnight将近 3 年前
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&#x27;s dead, at least to me.
akagusu将近 3 年前
Docker is not dead, despite the attempts of Red Hat (and Google) to kill it.<p>The market changed and Docker changed to stay relevant. Just that.
lkxijlewlf将近 3 年前
So, is Podman to Docker what LXD is to LXC, then?
user3939382将近 3 年前
Does Podman work with ECR&#x2F;ECS etc the way Docker does?
评论 #31618860 未加载