End-of-Life Announcement for CoreOS Container Linux
coreos.com
coreos.com
> It does not yet include native support for Azure, DigitalOcean, GCE, Vagrant, or the Container Linux community-supported platforms.
> The rkt container runtime is not included.
> Fedora CoreOS provides best-effort stability, and may occasionally include regressions or breaking changes for some use cases or workloads.
rkt is dead
Oh well. I always liked rkt, mostly as a sane alternative to Docker’s client/server and security model. What’s the best alternative nowadays ?
Another advantage is it's somewhat integrated into the rest of systemd, having hooks into systemd-machined and the machinectl tooling, and an out-of-box instance unit file for systemd-nspawn@ where the instance name maps to the machine name. Meaning you can trivially start a container w/`systemctl start systemd-nspawn@that-contained-webservice` having nothing more than something useful in /var/lib/machines/that-contained-webservice/, or enable it to start at boot like any other systemd service i.e. `systemctl enable systemd-nspawn@that-contained-webservice`.
BTW, rkt was basically just a wrapper around systemd-nspawn, though the pluggable stages supported alternative containment mechanisms. The nspawn stage1 is what was originally shipped from the beginning.
I jest but systemd really is taking over a lot of functionality
The fact that Debian is able to isolate the nspawn-related bits into systemd-container without breaking everything speaks to the modular arrangement. Though the project may be a mono-repo under the systemd umbrella, it's not a monolithic beast antithetical to unix tradition as many like to claim.
It's odd how *bsd people don't get all up in arms about their core system pieces being in one repo, but the linux world loses their minds when sprawling messes get a little more consolidated even though it's for the better.
It's possible to have a system with "ls" and without "grep", and vice versa, at least in principle. More importantly, it's possible to replace "ls" with a competing implementation, without having to change "grep". The systemd ecosystem is not structured in a way that lets alternatives be explored.
Nearly all of them. Have you actually tried to do this? The only thing I can think of off the top of my head that won't really work separately is journald.
See: https://github.com/elogind/elogind https://github.com/gentoo/eudev
So yes, systemd is a mono-repo containing a bunch of loosely-coupled projects, but they are still coupled too tightly to sanely distribute and use separately without a fork.
That's not true, forking becomes necessary when what you actually want is a different implementation fulfilling the same dbus interface.
If you just wanted intact systemd-logind and none of the rest, you could fairly trivially build systemd from source and package just logind and libsystemd and get on with your life. Maybe you'd have to carry some patches to inhibit some things like cgroups meddling in the systemd way, but that's no different than what say Debian does for practically every upstream tarball it packages.
Those projects have in a very real sense forked the components for the purposes of modifying their implementations in ways too substantial for some small packaging-time patches to cover.
I'd argue that it actually speaks to the modularity and organization of systemd's code that forking was a more attractive option for these folks than starting over with just the dbus interface in hand.
The difference is the utilities you mention interoperate at the level of bare UNIX pipes and execv/argv. Systemd components are largely integrated via dbus (UNIX domain sockets), as they're mostly services, daemons, which users don't generally interact with via execv/argv.
You're comparing apples and oranges here, and I'd like to note that GNU has already consolidated a lot of those CLI utilities into monorepos and I expect more consolidation like that to happen in the future as it's a natural evolution as the system stabilizes and active developers move on to other projects.
I think your argument would be more valid if systemd weren't establishing stable dbus interfaces, and instead were inventing all sorts of snowflake, constantly changing interfaces, but that simply isn't the case.
We already have examples of systemd components being forked and used independent of the project, to fulfill some of those interfaces without bringing in the entirety of systemd. [0] [1] I have mixed feelings about those efforts, but it at least demonstrates an ability to relatively trivially break off pieces you like and leave out the stuff you don't.
This didn't _used_ to be the case, but then I just looked it up, and… Yay, it actually is now! † I just want to say thanks (to the whole systemd team) for that!
† https://systemd.io/PORTABILITY_AND_STABILITY/ — the last time I checked was when the freedesktop.org page was still current, so it had been a while.
That's more than a little misleading. It's not like nspawn just calls into the service manager to get things done on its behalf via dbus or something like that.
If that were the case, rkt would only have worked on systemd hosts, since it used nspawn to setup its containers.
While it's true nspawn shares a bunch of code in common with the service manager, being in the same repository, it's a substantial program on its own and can function entirely independent of the service manager.
There was a time when nspawn actively required running on a systemd-booted host, but it was completely unnecessary and that check was removed while rkt was being developed. [0]
It's not some thin little ergonomic wrapper around existing service manager facilities.
[0] https://github.com/systemd/systemd/commit/4f923a1984476de344...
Yes, it literally does? https://github.com/systemd/systemd/blob/master/src/nspawn/ns...
Additionally there is a lot of shared functionality in libsystemd. Take a look at the rest of the code in nspawn and see how little it actually accomplishes.
No, it literally doesn't. That's just registration with the service manager, and it's optional. Basically it's to make the service manager aware of nspawn's actions, when it's on a systemd host.
I already pointed out they share a lot of code. The service manager process doesn't do squat on behalf of nspawn.
- containerd was pun out of the Docker engine to address community criticism. Pretty much every reason for creating rkt in the first place, has been addressed by containerd.
- lxd is very similar to containerd, but evolved out of the lxc userland tool.
There is also Podman and Cri-o, but I would not recommend those.
Unlike containerd and lxd, they were not created to solve an actual user problem, but to advance the interests of some vendors to the detriment of others.
Where can I read more about that?
https://github.com/pascomnet/nomad-driver-podman is a WIP Podman driver. We're discussing creating our own containerd-based driver, but there's no plans yet.
https://www.cncf.io/archived-projects/ (https://web.archive.org/web/20200205190817/https://www.cncf....)
A small nit-pick: Not having Vagrant is not a "significant restriction".
FWIW, there is the robust and well-documented virt-builder[1] tool that plays well with KVM, Xen and other stacks. (Related documentation here[2] -- replace "f27" with the latest Fedora release.)
[1] http://libguestfs.org/virt-builder.1.html
[2] https://developer.fedoraproject.org/tools/virt-builder/about...
Thank god Flatcar Linux looks to be a viable alternative and easy changeover.
Well we will learn how true this is very shortly.
> New CoreOS Container Linux machines will not be launchable in public clouds without prior preparation.
Are people here moving to FlatCar or Fedore CoreOS?
Plus it's got good RPi support for all those serious Big Software Company deployments /s
Have been searching for something like this for a while for a personal project, but unfortunately neither Flatcar nor Fedora CoreOS seem to support arm64, RancherOS does not to seem to offer fully automatic updates.
It's slimmer and more tuned for AArch64 and SBC type systems.
CoreOS is intended to be a “new” architecture for servers if I am not mistaken. I may be :-)
There is no package manager. You bring everything else with images and containers. If tools are not found on the distro, you have to get them yourself by starting up an image that contains those tools.
The build system that builds a new release is Gentoo. All the packages that are there gets updated, though the final release does not contain emerge or anything that actually can compile or build anything.
After CoreOS got bought out by Redhat, they started porting over those ideas using the Fedora build system (so Redhat packages, yum, etc).
I think the CoreOS Container OS will live on inside GCP as the customized container os as the default distro used on GKE (managed Kubernetes).
Edit: I see someone mention FlatCar. Neat. I guess that is more of a successor project than the one used in GKE.
I found this interesting. Does anyone have any insights how or why Google ended up choosing CoreoS for their GKE offering?
I am 99% sure that this offering is only similar in nature, not a fork or using any bits from Container Linux
A lot of these concepts and benefits apply when you consider cloud images as opposed to PXE boot images. With CoreOS, there was little difference in configuration with these two patters, if the infrastructure had the same topology you could essentially use the same config (VM or Baremetal).
Google Ventures also invested money in CoreOS at one point.
>"With CoreOS, there was little difference in configuration with these two patters, if the infrastructure had the same topology you could essentially use the same config (VM or Baremetal)"
Also are re "cloud images" VMs then, similar to AMIs in AWS?
Cheers
https://cloud.google.com/container-optimized-os/docs/concept...
As I mentioned in the edit, it looks like FlatCar is a true successor fork.
It seems like the only difference is you've gottta `packagemanger_xyz install` a couple packages...?
Another interesting Linux distro that uses virtualization rather merely containers to isolate system components for security is Qubes OS.
Really, I think any new Linux distros should:
1. be developed as an immutable whole
2. run most system and user-added services in containers
3. have package collections like nix or habitat that don't have dependency hells
4. make service and configuration management easy
5. not reinvent the wheel without specific goals and niche/s to occupy that are better than what came before
6. do damn good jobs of smoothing package rough edges, upstreaming patches and rapidly releasing security fixes (including ksplice/kpatch)
7. least surprise everywhere
8. think carefully about whether to go systemd or s6/runit/daemontools
9. manage logs better, preferably without local text files, streamed across a distributed system that scales like flume or kafka
1. Reduced attack surface due to a very slim OS with no package manager.
2. CoreOS Ignition, a killer app OS provisioning/customization tool. No weird barely-documented kickstart scripts, and no long build and upload times for OS images. We can make changes/customizations to our OS and have them deployed in a cloud within literally minutes. We consider this a competitive advantage.
https://pykickstart.readthedocs.io/en/latest/https://access....
Any concrete examples of stuff the existing docs do not cover ?
A simple example would be downloading a binary file and checking it's hash during boot, with retries if the connection is flaky. Three lines of declarative state in Ignition vs complex scripting in kickstart.
BTW, maybe open an RFE to include a helper script in the installation environment for easy & robust file downloading ?