81–90 of 98 posts
Earlier quoted context omitted.
What do you mean by that? You use Docker Compose to distribute to production? Into what?
Here is netbox's compose file: https://github.com/netbox-community/netbox-docker/blob/relea... -- there is no way I am going to spend the time to translate that into whatever k8s wants. If it isn't broken don't fix it.
I tried Podman on 2 MacBook Pros: my personal one (Intel) and my work one (M1) and it basically doesn’t work well at all. Podman Desktop simply doesn’t work, on first run it loops forever on initializing stuff (I guess it tries to create the Podman machine but fails? No idea because it doesn’t say what’s wrong, nor where to look). So I tried Podman bare without Podman desktop and it’s not a lot better, the machine st…
These types of papercuts (see other comments on how podman-compose and any sort of custom networking have issues, too) are why I have mostly avoided Podman so far. I find myself just using Docker rootless on Linux workstations and the Docker Engine on servers. On MacOS, I use Colima and it has worked well for me. > I loved the idea of rootless but it doesn't work on Mac One clarification I think is worth making in ca…
Maybe I’m using the wrong term, but when installing Docker, you need root access, and not for Podman. Maybe I’m wrong but I don’t think it’s possible to install Docker if you’re not root on the machine?
Earlier quoted context omitted.
> Why not have 1 daemon, rather than 1 daemon per container? Having a daemon per container has this little advantage that if something manages to bring down one of the daemons, it won't bring down the whole shebang.
Also side-channel attacks. E.g. if one user downloads a container, and then for another user it is already in the cache, this gives the other user information about the first user.
Earlier quoted context omitted.
Also side-channel attacks. E.g. if one user downloads a container, and then for another user it is already in the cache, this gives the other user information about the first user.
Isn't this pointless, since if the other user has access to docker, they basically have root access to the machine?
Earlier quoted context omitted.
Isn't this pointless, since if the other user has access to docker, they basically have root access to the machine?
I don't think users need to have root access to use Docker.
Earlier quoted context omitted.
What do you mean by that? You use Docker Compose to distribute to production? Into what?
Here is netbox's compose file: https://github.com/netbox-community/netbox-docker/blob/relea... -- there is no way I am going to spend the time to translate that into whatever k8s wants. If it isn't broken don't fix it.
at best, you can deploy that app to a Docker Swarm. Docker Swarm is not reasonably comparable to K8s.
there are tools (and colleagues ! :) ) to transform docker compose files to K8s manifests.
Earlier quoted context omitted.
Here is netbox's compose file: https://github.com/netbox-community/netbox-docker/blob/relea... -- there is no way I am going to spend the time to translate that into whatever k8s wants. If it isn't broken don't fix it.
You could use Kompose https://kompose.io , just sayin :)
That's a pretty strong option!
Earlier quoted context omitted.
You think all programmers are HN-level passionate? Most of my colleagues don't know what a ssh public key is used for.
OK fair enough (and I was being deliberately provocative so deserve any criticism I get). You're of course right that there's a huge diversity of programmers (in terms of experience, background, and extent to which they give a shit even if they're experienced and had access to the most helpful family background and best education a wealthy developed country can provide). But don't you kind of think that we should sti…
What problem does Docker's daemon actually solve? To me it always felt over-engineered.
Problems having a daemon solves: 1. You need a watchdog process anyways to handle stdout/stderr processing (to not block those pipes), namespace setup and teardown, etc. Why not have 1 daemon, rather than 1 daemon per container? 2. You need root to setup networking and various security controls (seccomp etc). Having a daemon lets an unprivileged user delegate to a privileged daemon. This was especially important in t…
Earlier quoted context omitted.
These types of papercuts (see other comments on how podman-compose and any sort of custom networking have issues, too) are why I have mostly avoided Podman so far. I find myself just using Docker rootless on Linux workstations and the Docker Engine on servers. On MacOS, I use Colima and it has worked well for me. > I loved the idea of rootless but it doesn't work on Mac One clarification I think is worth making in ca…
Thanks for the clarification! Maybe I’m using the wrong term, but when installing Docker, you need root access, and not for Podman. Maybe I’m wrong but I don’t think it’s possible to install Docker if you’re not root on the machine?
This link breaks down what permissions are used on MacOS.
> Maybe I’m using the wrong term
Typically, the meaningful piece with "rootless" Docker is that the daemon is not running as root.
When the Docker daemon is running as root on a Linux server, for example, anyone who can access the daemon (i.e. anyone in the "docker" group) has enough access to the system can do catastrophic damage with the access they have. For example, the docker daemon can mount any file on the host's filesystem (i.e. "-v /etc/shadow:/tmp/shadow"). With Docker running as root, anyone with access to the Docker daemon has the power to do almost anything to the system.
With rootless Docker, that issue is mitigated heavily because the Docker context is restricted to an unprivileged user context.
> but when installing Docker, you need root access, and not for Podman
According to Podman Desktop's docs, it asks for admin permission when installing on MacOS: https://podman-desktop.io/docs/Installation/macos-install
That being said, I don't personally see any security value added or removed by an installer process needing to elevate privileges. That's a one-time thing and likely should require admin privileges.