121–130 of 278 posts
Earlier quoted context omitted.
What kinds of tasks require two levels of containers?
Your CI server running in a container that is itself executing Docker commands.
This way you don't need to grant "docker" group to the "ci" user and you avoid having your cluster compromised one commit away :)
Earlier quoted context omitted.
Openshift years ago at least (last time I looked) - SHUDDER! I couldn't believe it was what big business / enterprise was standardizing on as best in class. It looks like it's now Kube / Docker connected, but back then I think it did it's own thing? The cost in time / $ / config to maintain and operate at the time was not pretty (all this no doubt has changed a lot).
They gave you three pods for free until they moved to Openshift 3. I ran an entire startup five years using them without paying a single penny. A nice Heroku alternative. (Iot control server, so basically no load)
Earlier quoted context omitted.
Why do you say that docker-in-docker buys him nothing? It's not obvious at all and you go into no detail whatsoever to back up your opinion. In my experience, that is not true at all. Docker-in-docker allows me to deliver smaller images that can fit into a CI flow as language plugins instead of shipping a beastly 5G docker image with every possible language runtime I need to support for my CI tool.
It is because to build the image using docker requires the docker client to talk with a dockerd daemon, so one has to configure the client to access the dockerd which allow untrusted code to run as root in the host. Docker-in-docker is a workaround to make docker work in CI. Basically a security nightmare and bad design that podman doesn't have.
Earlier quoted context omitted.
It is because to build the image using docker requires the docker client to talk with a dockerd daemon, so one has to configure the client to access the dockerd which allow untrusted code to run as root in the host. Docker-in-docker is a workaround to make docker work in CI. Basically a security nightmare and bad design that podman doesn't have.
Kubernetes as a layer of indirection is another solution.
I don't think kubernetes is a solution for context of building an image (a rootfs tree into a .tar.gz file).
Unless you are using kaniko which extends the kubernetes api to add the capability of creating images, but that is handled by kaniko itself via the same api.
RedHat seems to be pushing a standard ecosystem for Linux: systemd, Wayland, SELinux, GNOME, and now maybe podman. I've been on Linux for a while; it's a welcome change from all the fragmentation I'm used to. Whereas others try to work around the kernel and implement their own things in parallel (see: Canonical's AppArmor, LXC, OpenZFS), RedHat just goes with what Linux already has like SELinux/cgroups v2/btrfs, which I think is more likely to last and just feels better. If RedHat goes away, I'm fine since I'm ultimately only relying on Linux features. If Canonical goes away, then I'd have to switch to a different stack. That's probably why government, enterprises, Amazon, etc. still prefer RedHat.
Is it feasible to use podman to deploy to AWS?
Earlier quoted context omitted.
Kubernetes as a layer of indirection is another solution.
Kubernetes is a consistent management api for linux (so then you don't need to interact with iptables, mount and all that "hard stuff"). I don't think kubernetes is a solution for context of building an image (a rootfs tree into a .tar.gz file). Unless you are using kaniko which extends the kubernetes api to add the capability of creating images, but that is handled by kaniko itself via the same api.
Earlier quoted context omitted.
Maybe you are just too far into docker. I noticed that a lot of default workflows (needlessly) depended on docker running with privileges. One big reason for that seem to be Mac users that only know docker from inside a VM. However, if you think about what you're really needing for CI you will easily see that docker-in-docker gains you nothing. You can as well use plain docker (or podman). The same holds for privileg…
Okay, I want to build a container image using gitlab CI, which runs builds in docker. How would you like me to build an image without using docker in docker, or buildah in docker?