51–60 of 133 posts
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
>understand filesystem contexts and how to copy them from a good place I’m not really sure what this means (I have 0 knowledge on selinux)
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…
They invest in it because Docker is waaay out of spec with how things are done on Linux. Doing things that break the system, struggling with rootless for years, and who can miss the vendor lock-in? Podman is open and compliant and compliments k8s as well. It’s just nonsense the amount of effort developers have invested in Docker because it was first to market for easy containers.
That daemon is a subtle but incomensurate burden when adopting the least privilege principle.
In environments running multiple hosts which themselves run multiple containers, typically: k8s, it forces your hand in either giving in and grant docker (the daemon) root privilege if any one of your container needs root, or to exclude that container from running in that environment altogether (since it would fail to execute if the docker daemon is in rootless mode). Of course the most secure and wise option would be to refractor that container and whatever it's doing to run rootlesssly, but sometimes this is simply not a reasonable or even possible option in order migrate massive complex platform of hundreds of micro services with its own history and justified security exceptions.
K8s (and Openshift, which adopts a stronger security by default configuration set) provides control over which service accounts is granted such exception.
tl-dr: use podman/buildah rather than docker, use openshift rather than vanilla k8s.
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 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-…
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]
[--podman-stop-args args] [--podman-rm-args args]
[--podman-volume-args args] [--no-ansi] [--no-cleanup]
[--dry-run]
{help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill}
...
command:
{help,version,wait,systemd,pull,push,build,up,down,ps,run,exec,start,stop,restart,logs,config,port,pause,unpause,kill}
...
systemd create systemd unit file and register its compose stacks
When first installed type `sudo podman-compose systemd -a create-unit`
later you can add a compose stack by running `podman-compose systemd -a register`
then you can start/stop your stack with `systemctl --user start podman-compose@`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 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…
They originally tried to work together with docker to fix various issues (e.g. systemd compatibility for certain use case) which had popped up in the past but this turned out not very fruit full.
If you combine this that docker had and still has a uncanny amount of security issues(1) and docker like containers/images being very widely used by developers they had very little choice then to create their own implementation which is more in line with the values and approaches of RHEL.
(1): Like docker still not defaulting to rootless even through it can. For a hardened context both the the docker user group and the ways to run it without the group are security wise a no-go in many use-cases. Like docker initially doing way to little to make sure non privileged containers are at least somewhat sandboxed and taking forever to fix it even when it became known it's an issue. Like the way it interacts with firewalls and networks rules. Like the way it interacts with SELinux. Etc. In companies with dedicated Linux system administrators which care about security docker being banned is not that rare.
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 see no reason using Docker at least on Linux boxes. Not sure how Podman fares on macOS or Windows. I hope the majority doesn't end up with your point of view. Docker is not RedHat/IBM. If Docker goes away RedHat gets to continue to push their corporate agenda with a heavier hand. There are some advantages to Podman, but there are also some things that have not been executed well in RedHat's mission to replace all…
they tried to work with docker, it didn't work out, that is why we have podman
and given the headache "securely" using docker is I'm really happy that they did
One of the nice things about podman is that it's super easy to configure image caches. So instead of rewriting all my image references to use my local cache tool, I can just set a cache directive in podman and everything works transparently.
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…
They invest in it because Docker is waaay out of spec with how things are done on Linux. Doing things that break the system, struggling with rootless for years, and who can miss the vendor lock-in? Podman is open and compliant and compliments k8s as well. It’s just nonsense the amount of effort developers have invested in Docker because it was first to market for easy containers.
they just never bothered making it the default or officially supporting it
which in context with how they acted about other security problems int the past tells a lot about how serious the docker company takes security on linux