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

Podman: A Daemonless Container Engine

podman.io

Post reply on HN
Print view View original

231–240 of 250 posts

Re: Podman: A Daemonless Container Engine

#231

Post by mekster »

yobert wrote: post #109

I've been trying to use podman in production and it is not working very well. I'm excited for this technology but it is not ready. - podman layer caching during builds do not work. When we switched back to docker-ce, builds went from 45 minutes to 3 minutes with no changes to our Dockerfile - fuse-overlayfs sits at 100% CPU all day, every day on our production servers - podman loses track of containers. Sometimes the…

What are you exactly excited about?

It's just minor difference to me except it doesn't work well.

Not sure what the laziness was about from RedHat on podman development.

Re: Podman: A Daemonless Container Engine

#232

Post by mekster »

archi42 wrote: post #106
eeZah7Ux wrote: post #96

Earlier quoted context omitted.

> we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?

With root it's easy to mess up the system badly ("I'll just fix that small error") and/or let all systems slowly diverge. And if something fails on my workstation, it will fail on many others as well and needs a coordinated solution. Also, giving every dev root is a security liability, especially when there is absolutely no work reason that requires us to become root. So only a few "core IT" people have root access.…

It's only because your environment is fragile running stuff on metal instead of in a virtual environment.

Why not just give everyone an isolated space on a server with stuff like systemd-nspawn and let people do whatever they want including using docker inside and if they've screwed up, that's 1 lesson for them and redeploy his environment from a daily backup of the entire space or from a base image quickly.

Re: Podman: A Daemonless Container Engine

#233

Post by mekster »

kohlerm wrote: post #107
eeZah7Ux wrote: post #96

Earlier quoted context omitted.

> we devs don't have root on our workstations What's the justification for this... while at the same time allowing the use of containers?

In big companies there isn't always a good justification for a restriction ;-)

With no courage to voice a concern, it's your problem to be strangled by such limitations or there's actually a valid concern that you're not aware of.

Re: Podman: A Daemonless Container Engine

#235

Post by mekster »

8fingerlouie wrote: post #115
superbcarrot wrote: post #108

Can anyone explain what daemonless means in this case and what the advantages are? (I don't work in this space and my knowledge ends with knowing what a container is.)

IIRC, docker by default runs a daemon as root, which spawns all your containers. It is possible to run it rootless as well ( https://docs.docker.com/engine/security/rootless/ ), though you’d need a separate daemon for each user you’d want to run containers as. Podman doesn’t have that. It spawns containers without the help of a controlling daemon, and can spawn containers both as root and rootless. Rootless is of cou…

So, it's only about a tiny security concern but it got much bigger usability problems and what's worse RedHat is forcing people to use podman since RHEL 8 when it's not even ready.

Re: Podman: A Daemonless Container Engine

#236

Post by eptcyka »

CivBase wrote: post #127
tshtf wrote: post #124

Earlier quoted context omitted.

Oh, I agree it is a tradeoff. But the parent said "you can learn to miss every time". Can anyone point me to a C language project where the developers consistently miss every time?

Are you saying that every project written in C has suffered from a memory leak issue at some point? Most C/C++ code I've personally written doesn't even use the heap. I work on avionics and we use C/C++ now and then. We have a ton of rules regarding memory management (pretty much everything stays on the stack) and I can't recall anything I've ever been involved with suffering from a memory leak.

Don't need a leak for C code to be vulnerable, in fact not using the heap helps - just one missing bounds check on user input and you can write to the stack. OTOH, W^X should catch those.

Re: Podman: A Daemonless Container Engine

#237

Post by eptcyka »

CivBase wrote: post #225
Cyph0n wrote: post #206

Earlier quoted context omitted.

If basically everything stays on the stack, you’ll have a much lower chance of seeing a memory leak, by definition.

Exactly. Using C/C++ doesn't have to mean using the heap.

Using the heap has nothing to do with the code being safe or unsafe.

Re: Podman: A Daemonless Container Engine

#238

Post by dirkt »

geerlingguy wrote: post #19

What's the status on ease of running on Mac? I know last time I seriously considered testing it out in my workflow, it was kind of crazy that I had to have a separate machine (VM or real) just to run container images... I see in the docs [1]: "Podman is a tool for running Linux containers. You can do this from a MacOS desktop as long as you have access to a linux box either running inside of a VM on the host, or avai…

> it was kind of crazy that I had to have a separate machine (VM or real) just to run container images...

Containers use Linux namespaces to decouple from the main OS. MacOS doesn't support those, so no matter what you do, you can't run them directly on MacOS. That's why you need a VM, and you need the WSL Windows subsystem for Linux on Windows.

BSD has jails, but they don't have the same functionality. In particular, I sorely miss the network namespace that Linux has on MacOS.

Re: Podman: A Daemonless Container Engine

#239

Post by eptcyka »

zapita wrote: post #159
kbenson wrote: post #152

Earlier quoted context omitted.

That could be, but if Frazelle did actually walk around with a button saying “I will not merge patches for systemd” I think it's simpler and safer to assume Red Hat decided that relying on Docker was risky given how important it was to their future products and the apparent animus on display from the Docker maintainer. If I carpool with someone and they like to go around and loudly proclaim "I refuse to listen to any…

It’s no secret that there were tensions betwen Docker and Red Hat that culminated around 2016, when Red Hat’s desire to capitalize on the success of containers ran into Docker’s own ambitions to compete with Red Hat. Those tensions were eventually resolved (or at least diminished) by Red Hat shifting gears to Kubernetes as their “next Linux”. The drama you’re talking about is from that period - 2015-16. But “crun” wa…

I'll gladly use crio, crun and podman instead of the docker alternatives.

Re: Podman: A Daemonless Container Engine

#240

Post by nednar »

yobert wrote: post #179
nednar wrote: post #150

Earlier quoted context omitted.

What are the Github issue IDs for these 4 problems?

I agree with the sentiment that I should go find them. But I also agree with the sentiment that if RHEL 8 is going to make it hard to install docker and promote podman instead as a drop-in replacement, it's a bit frustrating.

> I agree with the sentiment that I should go find them.

I can sympathize with feeling overwhelmed when searching for similar Issues in a bug database, as I was in a similar situation in the past.

What happend was this: I went to the central starting point of the repo's database (e.g., https://github.com/containers/podman/issues), removed the filters like `is:open` from the search bar, and entered one or two keywords that for me sounded similar to the problem I faced.

As I didn't find any Issues that seemed similar, I just created a new one. Of course, I was worried about creating a possible duplicate, but I figured that it would still be a valuable contribution by adding more keywords (with the maintainers linking my duplicate to the ticket where the problem gets resolved) for others to search for. And last but not least, I thought this would also add additional debugging information for the developers, as well as an indication of the community-wide impact of the problem for the release management team.

In the end, I was quite happy I went this way, because I didn't just make a small impact on a project that would be useful for me, but it also enabled me to connect to the amazing people that build the tools I use on a daily basis.

I hope that you can also find a way that gives you some happiness in dealing with your situation, yobert.

Post reply on HN