241–250 of 278 posts
Earlier quoted context omitted.
AFAIU you can't switch to a shell runner unless you self host gitlab runner.
That is exactly my point. Gitlab uses docker runners because it is much simpler for them. But why should you be constrained by what's simpler for gitlab?
Earlier quoted context omitted.
We have our LTSS -> Long term support at SUSE. Just in case you're a big government that wants to throw us lots of money.
Off-topic, but what’s you experience working at Suse? I know a former employee, and what he told me sounded hellish.
Earlier quoted context omitted.
Any build script can do serious damage to the environment it runs in. Before docker, you'd have to create a new VM from time to time because the build agent had rotted away or died in an altercation with a bad build. Docker in Docker in CI is like a lock on a door. It keeps honest people from being naughty, and is fairly efficient about it. I don't think the question is "should I run CI in docker in docker," it's who…
You do know that spinning up a new VM only takes a few seconds? With projects like https://firecracker-microvm.github.io/ , the difference between launching a new Docker container or a new VM is negligible. This works great if you own or rent the hardware, but most cloud providers don't allow nested virtualization.
Although there are tools to convert docker images to vm images. I expect if I were running community CI infrastructure, getting really familiar with those would be high on my priority list.
Earlier quoted context omitted.
Any build script can do serious damage to the environment it runs in. Before docker, you'd have to create a new VM from time to time because the build agent had rotted away or died in an altercation with a bad build. Docker in Docker in CI is like a lock on a door. It keeps honest people from being naughty, and is fairly efficient about it. I don't think the question is "should I run CI in docker in docker," it's who…
The other option that works really well in a single user environment is to bind to the runner's Docker daemon. That way builds run as siblings of the runner's daemon rather than as children via docker-in-docker. The huge issue with that is security which is why it's only really practical for a single user or a small group of trusted users. A secondary issue is that (I think) builds can't run simultaneously because th…
You could separate those into two builds, but the reason they are together is so people think about deployment, and in case any structural changes to the code need to coincide with deployment changes. For instance, breaking changes in APIs. I need a new version of tool/library and I need to change how I call it.
Earlier quoted context omitted.
btrfs is depreciated in redhat distribution
If you want to use btrfs on RHEL8, you still can: go to https://elrepo.org/ and install elrepo-release, then install kernel-ml from their -kernel repo and btrfs-progs from their -testing repo.
So if you want to use Btrfs, you might as well use it on something besides RHEL.
Earlier quoted context omitted.
If you want to use btrfs on RHEL8, you still can: go to https://elrepo.org/ and install elrepo-release, then install kernel-ml from their -kernel repo and btrfs-progs from their -testing repo.
... at which point you lose the support you're paying for from Red Hat, thus defeating the purpose of using RHEL in the first place. So if you want to use Btrfs, you might as well use it on something besides RHEL.
Earlier quoted context omitted.
What kinds of tasks require two levels of containers?
Ansible Molecule tests depend strictly on Docker: https://molecule.readthedocs.io/en/latest/ Also if your application is shipped as orchestrated containers (like docker-compose), or as multiple containers in a 'pod' (e.g. sidecars), you may want the ability to run containers from containers as part of CI.
A while ago, I, unfortunately, decided to add "proper tests" to all of my Ansible roles and decided to use Molecule (2.22, at the time, IIRC). As I don't use Docker, I was using "lightweight VMs" I had created (w/ Packer, converted into Vagrant boxes) with VirtualBox for all of this testing.
I spent I don't know how many hours across several days learning the "toolchain", getting everything setup and working properly, adding full test coverage, and so on. Not long afterwards, they released Molecule 3.0 which required using Docker. :/
Earlier quoted context omitted.
I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right dir…
> I actually like the idea of Docker as a better systemd (or rather, the interface is better). No bespoke file format, programmable API, no need to google for the right journalctl switches, and then of course the advantages of containers and images over processes and system packages. I’m not suggesting everything should be a container nor that docker is the ideal implementation, but it certainly points in the right d…
I don't know, systemctl is always a pain to interact with. The Docker CLI is pretty intuitive--you have different resources and different verbs for interacting with those resources. This includes logs. No need to use a separate (and confusing) tool nor dig through man pages. I'm of the philosophy that it's better for a tool to be intuitive than obscure-but-has-manpages.
> Anyhow, aren't systemd units ini files? The journalctl ships with man pages though.
I guess I meant that INI isn't a standard file format--different parsers behave differently, and structured data is often coded in strings in some bespoke format.
> Aren't containers just processes with namespaces and cgroups?
My mind isn't made up that containers are the ideal process unit, but I do like some things about them (and the container ecosystem more generally). That they come with their dependencies bundled is pretty nice, but I think the toolchain needs to improve to mitigate security concerns and so on. Something like Nix would be helpful, but Nix also has its own problems. Again, it's directionally correct. In any case, users don't need to be managing their own namespaces and cgroups.
Earlier quoted context omitted.
What kinds of tasks require two levels of containers?
“kind” is a example in my day to day, how do I run an ephemeral kube cluster in ci to deploy and test my app against without dind/kind? I want N clusters running on 1 host to support many CI jobs. https://github.com/kubernetes-sigs/kind https://github.com/bsycorp/kind
Earlier quoted context omitted.
> If you are in the business of charging complex prices per bits over the network, then docker seems to be quite a good investment and making it as popular as possible is a good strategy to print money. /s True, that. To be fair, at least it allows me to avoid lots of the brokenness of Python packaging.
Is always good to report packaging bugs so then people can fix them, do you have examples of python packages that can be improved?
tl;dr pip silently breaks my environments, mostly connected to upgrading numpy and other scientific/data science libraries.