Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I ditched Docker for Podman

codesmash.dev

Post reply on HN
Print view View original

611–620 of 670 posts

Re: I ditched Docker for Podman

#611

Post by figmert »

wyoung2 wrote: post #383
rsyring wrote: post #244

Earlier quoted context omitted.

Do you have a summary of those most common issues and their workarounds?

Broadly, the claim that Podman is a drop-in replacement for Docker is true only for the simple cases, but people have developed assorted dependencies on Docker implementation details. Examples: 1. People hear about how great rootless is with Podman but then expect to be able to switch directly from rootful Docker to rootless Podman without changing anything. The only way that could work is if there was no difference…

For #2, it will also use docker compose v2 if available. Docker compose v2 is still a standalone binary even in the case of installing Docker (it's a plugin). As long as you download the v2 binary, put it in the correct location, the podman compose subcommand will invoke it.

Re: I ditched Docker for Podman

#612

Post by rldjbpin »

my team switched to podman due to docker desktop licensing (and only using engine pain). personally it has been quite annoying to work with on windows with cuda.

the need to spin its own wsl instance (which takes a lot of disk space) and gpu workarounds are just not there yet.

others have mentioned about podman compose but the old docker-compose do work to be fair.

Re: I ditched Docker for Podman

#613

Post by [deleted] »

jnovacho wrote: post #153

> Privileged ports in rootless mode not working? Good! That's security working as intended. A reverse proxy setup is a better architecture anyway. So, how are you supposed to run the proxy inside the container? Traefik for example? Genuinely curious.

[deleted]

Re: I ditched Docker for Podman

#614

Post by cduzz »

lmm wrote: post #514
cduzz wrote: post #316

Earlier quoted context omitted.

It's pretty easy to run docker on macos -- colima[1] is just a brew command away... It runs qemu under the hood if you want to run x86 (or sparc or mips!) instead of arm on a newer mac. [1] https://formulae.brew.sh/formula/colima

> colima[1] is just a brew command away... Which would be great if it worked reliably, or had any documentation at all for when it breaks. But it doesn't and it doesn't.

First, I guess I'll just invoke Sturgeon's law[1] -- almost all software, especially if you don't really understand it, is crap, and probably the software you understand is also crap, you're just used to it. Good software is pretty tricky to make.

But second -- I use colima lots, on my home macs and my work macs, and it mostly just works. The profiles stuff is kinda annoying and I find myself accidentally running arm when I want x86, or other tedious config issues crop up. But it actually has been easier to live with than docker desktop where I'd run out of space and things would fall apart.

Docker on MacOS is broadly going work poorly relative to it on linux, just from having to run the docker stuff in a linux vm that's hiding somewhere behind the scenes.

If you find too much friction with any of these, probably it's easier to just run a linux vm on the mac and interact with docker in the 'native' environment. I've found UTM to be quite a bit easier to live with than virtualbox.

[1] https://en.wikipedia.org/wiki/Sturgeon%27s_law

Re: I ditched Docker for Podman

#615

Post by regularfry »

0cf8612b2e1e wrote: post #282
dec0dedab0de wrote: post #195

Earlier quoted context omitted.

It becomes a pain point when the IT team never heard of docker, all new licenses need to be approved by the legal department, and your manager is afraid to ask for any extra budget. Also, I don't want to have to troubleshoot why the docker daemon isn't running every time I need it

I have personally given up trying to get a $25 product purchased through official channels. The process can make everything painful.

It can be easier to spend £100K than £100.

Re: I ditched Docker for Podman

#616

Post by mdaniel »

Dunedan wrote: post #592
mdaniel wrote: post #251

Earlier quoted context omitted.

In fairness, Vagrant solves a slightly different problem than does containerization, so I doubt the need went away but rather folks realized no one cares very much about fresh VM, rather it's all about the application configs Also, fuck them: https://github.com/hashicorp/vagrant/blob/v2.4.9/LICENSE who the fuck are they expecting to pay for Vagrant, or that "AWS gonna steal our ... vagrant?"

I'm so angry about that license change, as it makes impossible to use Vagrant anymore. For example the version of Vagrant in Debian is stuck to the pre-license change commit and Debian doesn't publish Vagrant boxes for new releases anymore. I've yet to find a replacement, which works as seamlessly across different operating systems.

Yeah, I was actually participating in a soft-fork for a while but I think the project ran out of steam. My guess is that it's very hard to pay attention to something that you don't use every day, so they let it drift. But if you ever hear of someone starting up again, let me know

I'm aware that I, too, could be the someone but like I said it's hard to dedicate all the time and energy when the last time I used vagrant was years ago

I also just remembered that I haven't revisited the forks list to see if there's some meaningful activity https://github.com/hashicorp/vagrant/forks?include=active&pa...

Re: I ditched Docker for Podman

#617

Post by chuckadams »

goku12 wrote: post #339
1a527dd5 wrote: post #10

I really wish Docker didn't take over the industry like it has. In my experience not enough people know how to debug yet another layer of abstraction. Remove layers, keep things simple. That being said, it is here to stay. So any alternative tooling that forces Docker to get it's act together is welcome.

> ... how to debug yet another layer of abstraction. > Remove layers, keep things simple. Due to the first line above, I'm not sure if I'm reading the second line correctly. But I'm going to assume that you're referring to the OCI image layers. I feel your pain. But honestly, I don't think that image layers are such a bad idea. It's just that the best practices for those layers are not well defined and some of the ea…

Quite an informative reply, but I think GP is referring to layers of abstraction in general, which IMHO puts it in "old man yells at cloud" territory.

Re: I ditched Docker for Podman

#618

Post by sroerick »

kqr wrote: post #602
sroerick wrote: post #427

Earlier quoted context omitted.

The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend. We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'. While I've used Docker a lot since then, that remains the single easiest deployment I've ever had. I genuinely don't understand wh…

Docker in and of itself does not do you much good. Its strength comes from the massive amounts of generic tooling that is built around the container as the standard deployable unit. If you want to handle all your deployments the same way, you can basically only choose between Nix and containers. Unfortunately, containers are far more popular and have more tooling.

I think this is accurate. It just feels like a lot of "we use Docker because everybody uses Docker. That's just the way we do it.

But if you actually add up the time we spend using docker, I'm really not sure it saves that many cycles

Re: I ditched Docker for Podman

#619

Post by sroerick »

SkiFire13 wrote: post #597
rcv wrote: post #466

Earlier quoted context omitted.

> I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues. Sounds great if you're only running a single web server or whatever. My team builds a fairly complex system that's comprised of ~45 unique services. Those services are managed by different teams with slightly d…

> so there is basically a zero percent chance I'll come in in the morning and not be able to run the latest head of develop because someone else's dev machine is slightly different from mine. It seems you never had to deal with timezone-dependent tests.

What are timezone-dependent tests? Sounds like a bummer
Post reply on HN