521–530 of 670 posts
The main issue is podman support on Ubuntu. Ubuntu ships outdated podman versions that don't work out of the box. So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker. So now my script must work with old podman, recent podman and docker
> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML. We all use Kubernetes these days, so why even bother about this? I find that kubernetes yaml are a lot more complex than docker compose. And while I do, no, not everybody uses kubernetes.
I disagree with you on that. Kubernetes YAML is on the same level of complexity as docker compose and sometimes even easier. But verbosity - yeah, kubernetes is absolutely super-verbose. Some 100-line docker-compose could easily end up as 20 yamls of 50 lines each. kubectl really needs some sugar to convert yamls from simple form to verbose and back.
> If your Docker Compose workflow is overly complex, just convert it to Kubernetes YAML. We all use Kubernetes these days, so why even bother about this? I find that kubernetes yaml are a lot more complex than docker compose. And while I do, no, not everybody uses kubernetes.
Having an LLM function as a translation layer from docker compose to k8s yaml works really well. On another note, podman can generate k8s yaml for you, which is a nice touch and easy way to transition.
Earlier quoted context omitted.
> Rootless networking is very slow I came across just how slow recently: - Container -> host: 0.398 Gbps vs. 42.2 Gbps - host -> container: 20.6 Gbps vs 47.4 Gbps Source: https://github.com/containerd/nerdctl/blob/main/docs/rootles...
The slow speed is for using slirp4netns, not containers in general.
The main issue is podman support on Ubuntu. Ubuntu ships outdated podman versions that don't work out of the box. So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker. So now my script must work with old podman, recent podman and docker
Docker is failing in that trap where they feel the need to try (and mostly fail so far) to add net-new value streams (e.g. mcp catalogue, a bunch of other stuff i immediately turned off that last time i installed it) rather than focus on the core value. It's not the case that they've maximised the utility of the core build / publish container nor the acquire / run container workflows and but they're prioritising fluf…
Sadly "docker" is just a synonym for "container" for most people, so the main issue is that most projects only ship a compose file. Hopefully they'll ship quadlet files too, some day.
Alternatively, a public repository for sharing quadlets for popular open source software would be great.
Earlier quoted context omitted.
OK, this seems like an absolutely valid use case. Big enterprise microservice architecture, I get it. If you have islands of dev teams, and a dedicated CI/CD dev ops team, then this makes more sense. But this puts you in a league with some pretty advanced deployment tools, like high level K8, Ansible, cloud orchestration work, and nobody thinks those tools are really that appropriate for the majority of devteams. Peo…
Having a reproducible dev environment is great when everyone’s laptop is different and may be running different OSes, libraries, runtimes, etc. Also docker has the network effect. If there was a good light weight tool that was better enough people would absolutely use it. But it doesn’t exist. In an ideal world it wouldn’t exist, but we don’t live there.
Docker and other containerization solved the “it works on my machine” issue
Earlier quoted context omitted.
One of the major use cases was multi-user HPC systems. Because they can be complicated, it’s not uncommon for bioinformatics data analysis programs to be distributed as containers. Large HPC clusters are multi-tennant by nature, so running these containers needs to be rootless. There are existing tools that fill this gap (Singularity/Apptainer). But, there is always friction when you have to use a specialized tool ve…
> Large HPC clusters are multi-tennant by nature, so running these containers needs to be rootless. I can't see how any kind of sensible security evaluation process would reach that conclusion. If you trust your users you don't need rootless, if you don't trust your users rootless containers aren't good enough. I suspect people do rootless because it seems easy and catches a few accidental mistakes rather than it bei…
These are almost always multi-tennant with differing levels of trust and experience between users. The data processed here can often have data access agreements or laws that limit who can see what data. You can’t have a poorly configured container exposing data, for example. So, the number of people who have root access is very limited. Normal users running workflows would all be required to run code rootless.