Live data from Hacker News

Exploring Podman: A More Secure Docker Alternative

betterstack.com

101–110 of 133 posts

Re: Exploring Podman: A More Secure Docker Alternative

#101
post #91

Earlier quoted context omitted.

I know it's a hard sell, but the 30 minutes to an hour to understand filesystem contexts and how to copy them from a good place isn't a lot It's likely to little gain. I know why people don't, but it is very accessible to those open to it The more one adheres to the FHS, the easier SELinux is

I have been doing Linux sysadmin for 20 years and I just stopped trying to understand SELinux. It looks and feels like an abomination borne out of some IBM or other antediluvian corporate UNIX system for programmers wearing suit and tie. Terrible documentation, terrible mental model, terrible CLI UX, terrible error messages. I run Fedora and SELinux is working well enough, but it's a piece of machinery I can't wait t…

I totally get it. I exert next to zero effort to keep it around for my systems!

For systems that shouldn't do much more than exactly what is prescribed, it's acceptable, is what I'm after... I guess.

I can't do justice to the source, but there's a concept about our programs/creations reflecting us.

Like a peer hints - SELinux reflects an agency like the NSA, draconian. Good and bad

Re: Exploring Podman: A More Secure Docker Alternative

#102
post #54

Earlier quoted context omitted.

I already was defining my infrastructure with docker-compose.yml files, and found out that podman-compose has a poorly documented feature that generates systemd units. It doesn't use the now-deprecated podman feature, it writes the unit files itself, and I find the process much smoother than the podman feature anyway. To enable the feature: $ podman-compose systemd -a create-unit To register a systemd unit: $ podman-…

Its documented. If you just type `podman-compose` in the command line you get... usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args] [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podma…

That’s… not documentation. That’s a CLI helpfile. It’s better than nothing but also what is completely broken with the “move fast and break things” mindset.

Re: Exploring Podman: A More Secure Docker Alternative

#103
post #91

Earlier quoted context omitted.

I have been doing Linux sysadmin for 20 years and I just stopped trying to understand SELinux. It looks and feels like an abomination borne out of some IBM or other antediluvian corporate UNIX system for programmers wearing suit and tie. Terrible documentation, terrible mental model, terrible CLI UX, terrible error messages. I run Fedora and SELinux is working well enough, but it's a piece of machinery I can't wait t…

It was originaly developed by the NSA, so it's even worse than corpos wearing suit and tie, it came from spooks.

Probably intentionally complex for just that reason. Easy to leave a misconfiguration.

Re: Exploring Podman: A More Secure Docker Alternative

#104
post #102
post #54

Earlier quoted context omitted.

Its documented. If you just type `podman-compose` in the command line you get... usage: podman-compose [-h] [-v] [--in-pod in_pod] [--pod-args pod_args] [--env-file env_file] [-f file] [-p PROJECT_NAME] [--podman-path PODMAN_PATH] [--podman-args args] [--podman-pull-args args] [--podman-push-args args] [--podman-build-args args] [--podman-inspect-args args] [--podman-run-args args] [--podman-start-args args] [--podma…

That’s… not documentation. That’s a CLI helpfile. It’s better than nothing but also what is completely broken with the “move fast and break things” mindset.

it's documentation enough to not call it an undocumented feature.

the concern with truly undocumented functionality is that it's not included intentionally: either it's a bug or an experimental feature that could be removed or changed with no notice. a poorly-documented feature, on the other hand, will probably at least get a deprecation notice before it disappears

Re: Exploring Podman: A More Secure Docker Alternative

#105
post #102

Earlier quoted context omitted.

That’s… not documentation. That’s a CLI helpfile. It’s better than nothing but also what is completely broken with the “move fast and break things” mindset.

it's documentation enough to not call it an undocumented feature. the concern with truly undocumented functionality is that it's not included intentionally: either it's a bug or an experimental feature that could be removed or changed with no notice. a poorly-documented feature, on the other hand, will probably at least get a deprecation notice before it disappears

> it's documentation enough to not call it an undocumented feature.

Which is why I didn't call it that, I called it poorly documented.

Re: Exploring Podman: A More Secure Docker Alternative

#106

I still don't really understand why Red Hat invests into creating a Docker alternative, but I really like it. Podman does pretty much everything Docker does, but it has more features (e.g. pods) or the way Podman does it tends to be better (e.g. daemonless container spawning process). The main issue to a common developer would be Docker compose I suppose, which if you use simple compose files, there's actually a podm…

I use Podman on Windows. Docker on Windows has been an endless stream of annoyances and frustration for me, starting from the fact everything points you to install an aggressively user-unfriendly GUI that starts up heavyweight processes on boot, nags you to sign up for a cloud account for some reason, and then nags you again that you shouldn't be using this so-called open source product for work anyway. Installing "just the command line" docker as an unsupported alternative is unnecessarily complicated, and last time I tried most WSL VMs didn't even support it out of the box anyway.

Enter Podman, you just winget install podman and it gets out of your way. When you need to run a container, you start up the Podman VM. When you don't, your system behaves exactly as it always did before. If you need to run something in a compose file, podman-compose is there. Maybe it can't handle esoteric configs, but it's worked for my use cases. The only thing Podman doesn't do is integrate with VS Code properly, but honestly the struggle of getting Docker to behave itself on Windows is far more annoying to me than missing some keyboard shortcuts in VS Code, so for me it's not a problem.

I would (and do) recommend Podman as the default solution for containers on Windows. The only reason I can see to use Docker is if your company is paying for it, or if you have a complicated compose setup, in which case it might be worth moving to Kubernetes anyway.

Re: Exploring Podman: A More Secure Docker Alternative

#107
post #82

Earlier quoted context omitted.

I've had issues as recently as this week with podman on an m1 laptop - the container would start but after a short time would freeze completely and couldn't even be killed - only solution i found was to restart my laptop. Eventually, I gave up and went back to using docker.

Same, I tried it on Thursday, I would recommend people on M1 Macs to stay well clear of podman for now.

Yep, there's a thread with hundreds of people on M1,2,3 macs having issues, it bit some people at work on newer macs. If you installed it a while ago, it's fine, but if you installed recently, it's buggered. The solution was to install podman-desktop which was somehow packaged such that it's not getting the bug (podman machine start hangs forever).

Re: Exploring Podman: A More Secure Docker Alternative

#108
post #49

I had some issues with podman working on my m1 mac about 1-2 yrs ago. I’ll give it a shot again. Looks like it has matured very fast.

I’ve been using it for years on M1 Macs without issue. I wrote up some notes:

https://gist.github.com/acdha/9be1c3521af4f18d9f86264a889581...

Re: Exploring Podman: A More Secure Docker Alternative

#109
post #97
post #6

Podman was good when it supported systemd unit files, so I could auto start and auto update containers, even entire pods with systemd. Then they removed that in favor of Quadlet. Now in order to do a single container I can do a unit file, but for a pod, I need to use a Kubernetes cluster definition. Plus, unlike Docker their containers bow to SELinux definitions, so I have repeatedly struggled with containers unable…

I recently migrated over to NixOS which treats systemd as the source of truth for everything, including containers. I found this model extremely intuitive, but it was difficult to apply this to Docker Compose without a lot of manual migration. So I ended up writing a tool that handles this for you — it converts your Compose files into a NixOS config that can be interpreted and managed natively. https://github.com/aks…

This is a cool idea. Two questions:

Arion can wrap docker-compose and run as a project or part of a nixos config. Did you come across Arion before creating this, and have you compared them?

I had a brief look through your examples and it doesn’t look like compose2nix implements docker-compose’s network per compose file. Is this something you want to add?

Re: Exploring Podman: A More Secure Docker Alternative

#110
post #31

I still don't really understand why Red Hat invests into creating a Docker alternative, but I really like it. Podman does pretty much everything Docker does, but it has more features (e.g. pods) or the way Podman does it tends to be better (e.g. daemonless container spawning process). The main issue to a common developer would be Docker compose I suppose, which if you use simple compose files, there's actually a podm…

I use Podman on Mac OS. I've found the experience better than Docker for the most part, especially when it comes to supporting older versions of Mac OS. The only major downside of Podman on Mac OS is that you cant use the host network in a container, but people will rarely want to use the host network in a container anyway. This is something to keep in mind if you want to experiment with network things in a container…

I'm a podman beginner, trying to install ollama-webui(1) using Podman on M2 MBA.

I started up Podman Desktop, and did a terminal command "docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v ollama-webui:/app/backend/data --name ollama-webui --restart always ghcr.io/ollama-webui/ollama-webui:main" based on Github's instructions, but it gave a error message something about "host".

the exact error message was ""Error": "failed to create new hosts file: unable to replace \"host-gateway\" of host entry \"host.docker.internal:host-gateway\": host containers internal IP address is empty""

Do you know what is the problem and how do I overcome this?

If I run the above command using Docker Desktop, it runs and installs Ollama-WebUI just fine.

Thank you.

(1) https://github.com/ollama-webui/ollama-webui ("Installing with Docker")

Post reply on HN