131–140 of 183 posts
Earlier quoted context omitted.
What were the headaches?
Not the poster, but I have to reboot at least one a day to clear up Docker networking/DNS gremlins. I thought moving to Linux from Mac would make Docker better due to the lower resource usage but I would guess the fact that it’s isolated in a VM in Mac is why I never had network issues there
Earlier quoted context omitted.
Is there any config to set up this way or do you literally just run podman on the socket and it just knows what to do?
podman replacing the docker socket https://www.redhat.com/sysadmin/podman-docker-compose
$ systemctl --user enable --now podman.socket
$ export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock
OCI compatible containers are the future, docker and podman both classify as such. https://opencontainers.org/ That being said, docker blows. Docker desktop blows more. Docker desktop on Windows blows the most. I always get stuck with a bind mount misbehaving, or some other issue that requires me to wipe the docker desktop data to fix it. Just use docker compose for simple stuff, and stay away from docker for Windows…
I see your "Docker blows on Windows" and raise you "Docker blows on M1." At least you have WSL, Apple couldn't give half a fuck (and nor could Docker). Colima has been a lifesaver, but having used WSL Docker in the past and Linux Docker recently (I now favor Podman), M1 Docker is a complete shitshow. I'm slowly infesting our codebase with Podman/Buildah/Skopeo (also because they do things Docker can't), and hopefully we'll get to the point of using podman machine.
Earlier quoted context omitted.
> The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror. What I never understood is why they didn’t just properly handle this with mirrors like any package manager does; why is this a problem for docker, but not for yum / apt / etc? I have to admit that these rate limits have accelerated my migration to alternatives like quay.io
By default container images are not signed (there is notary, but it's not commonly used - maybe notary V2 will change that - and I think the signature changes depending on the registry it's hosted on anyway?) which make it inconvenient to mirror. Now, why are we still producing new package formats without mandatory signatures (containers, npm, cargo, etc) is not really clear to me. I guess everyone must think "those…
I could not find answer for myself why Docker is any close to be dead and why Podman is the thing I should use instead of Docker immediately.
Q 1. Docker has some policy change and your company may need to pay for it - if you have > 250 persons/10 million revenue A 1: Indi/Solo devs out of scope. Enterprises probably fine with that anyways.
Q 2. Docker has limits for pulls from Docker hub!!!! You have 100 (200 with login) downloads/single IP for 6 hours interval. A 2: It was already mentioned, switching to Podman, while using Dockerhub doesn't magically helps. Moreover, practically I find it totally fine for Indi/Solo dev. For companies, who's amount of pulls can be higher - you want and have in place your local registry anyways to ensure Business Continuity and this doesn't bother you much.
Q 3. Running no background processes, running rootless is good because of ... A 3: On dev env (your local laptop, for example) you do not care much - your goal is ease of use. On production, running rootless rises question from me: * how you expect firewall (iptables) to be updated for port forwardings? * how you expect networks and bridges organized without root? * how you expect auto restart for container to happen on failure without supervising it? * some security advises and mitigation guides mention disabling user namespaces and was/is disabled by default in some distros https://news.ycombinator.com/item?id=28054823 - your security & system administration team may have such limits in place on production * those who care for intruder gets into container and can hijack system further use FireCracker or similar approach anyways [for production]
So what is left in "pros" for Podman, have I missed anything?
Earlier quoted context omitted.
> The rate limits were mostly in place to deny corporate CI users access to the Hub free of charge and force them to pay or deploy a mirror. What I never understood is why they didn’t just properly handle this with mirrors like any package manager does; why is this a problem for docker, but not for yum / apt / etc? I have to admit that these rate limits have accelerated my migration to alternatives like quay.io
They opposed to add support to private mirrors in the software, probably to retain their monopolistic position https://github.com/moby/moby/pull/34319
Earlier quoted context omitted.
It is at least a year or so old. But there have been quite a few bugs, and iirc it was only at v4 where incompatible bugs have been ironed out. Not that it wasn't usable previously, you'd just run into a few issues.
> Not that it wasn't usable previously, you'd just run into a few issues. I don't like that definition of "usable". Compose v2.0 compatibility became available only since last month which was very late. If podman isn't for technical benefit, is this all about political decision for RH to govern container ecosystem on their own instead of dealing with docker?
- `--rootfs` lets you start a container from a directory instead of an image
- You can configure alternate container storage locations, e.g. to share a common library of container images among multiple machines over NFS
- As previously mentioned, it has the k8s-like notion of "pods" which are multiple containers sharing namespaces with each other
- It will play nice with systemd, both inside and outside of containers, and can generate systemd services for containers
I think the last point is really why Podman exists in the first place; IIRC, Red Hat's developers made a valiant effort to get patches into Docker to improve its cooperation with systemd, but the folks working on Docker weren't interested. If Red Hat's patches to Docker had been upstreamed, Podman might not exist.
How did the intro get so many things wrong?! 1. Mirantis did not acquire Docker Inc., they only bought Docker Enterprise. See https://techcrunch.com/2019/11/13/mirantis-acquires-docker-e... and https://www.docker.com/blog/docker-enterprise-edition/ 2. k8s didn't remove dockershim for political reasons but because containerd was refactored out of Docker long time ago and k8s wanted to get rid of the extra layer. See h…
"Docker the company is having trouble monetizing their products...so I'm unsure about their future"
And, so the follow on of:
"Can I use compatible tools that don't depend on Docker, the company, as much?"
Makes some sense.
Earlier quoted context omitted.
That took a while... Although I don't see what benefit I get by going podman when docker works fine and I don't really care about theoretical rootless security enhancement.
Can I use Docker on my company projects, or can I use it for personal use only? I was under the impression that Docker doesn't allow professional use with the unpaid license, though I might have gotten it wrong.
> Podman currently only runs stably on Linux-based systems. Under Windows or MacOS it becomes a bit more demanding, although it is possible with detours. I think this is an area bearing improvement before most dev workflows can switch
Why do you need to run docker on Windows or Mac?