[HN Gopher] End-of-Life Announcement for CoreOS Container Linux
___________________________________________________________________
End-of-Life Announcement for CoreOS Container Linux
Author : thebeardisred
Score : 120 points
Date : 2020-02-05 16:41 UTC (6 hours ago)
(HTM) web link (coreos.com)
(TXT) w3m dump (coreos.com)
| rubyn00bie wrote:
| What did CoreOS offer that say ClearLinux, or good ol' Debian do
| not?
|
| It seems like the only difference is you've gottta
| `packagemanger_xyz install` a couple packages...?
| vlowther wrote:
| well, good thing there is https://www.flatcar-linux.org/
| astrea wrote:
| > In fact, if CoreOS Container Linux disappeared tomorrow, it
| would have very little impact on the Flatcar Container Linux
| project.
|
| Well we will learn how true this is very shortly.
| blixtra wrote:
| Chris from Kinvolk here. Our Flatcar builds are already
| completely independent of CoreOS builds. This is quite
| exciting for us as we can finally start updating the included
| software versions. We've been doing this a while for the edge
| channel (https://www.flatcar-linux.org/releases/) and have
| been waiting to do that with the other channels.
| merb wrote:
| it would be cool if https://github.com/coreos/container-
| linux-update-operator would also be part of flatcar.
| bovermyer wrote:
| What about RancherOS? Is that a viable replacement?
| qwerty456127 wrote:
| Fedora CoreOS. Oh my. I din't even know Fedora Core is not the
| full name of the ordinary Fedora OS any more...
| fkistner wrote:
| Can someone recommend an immutable Linux distro, which offers
| auto-updates out-of-the-box and supports arm64 on RPi?
|
| 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.
| infinisil wrote:
| As choward already mentioned, I think NixOS is a very good
| choice: aarch64 is decently well supported with a bunch of
| people running NixOS on their Raspbys, and cross compilation
| support is really good too if needed. See
| https://nixos.wiki/wiki/NixOS_on_ARM/Raspberry_Pi for more
| info, or hop into #nixos and/or #nixos-aarch64 on Freenode for
| help
| choward wrote:
| I'm not sure exactly what you mean by "immutable" but you might
| find NixOS (https://nixos.org/) interesting. However, it might
| not be the best experience at the moment for the Raspberry Pi 4
| (https://github.com/NixOS/nixpkgs/issues/63720).
| zymhan wrote:
| Fedora CoreOS seems like it has some pretty significant
| restrictions
|
| > 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.
| wmf wrote:
| This is the Red Hat "stay in business" business model, not the
| CoreOS "make it up in volume" business model.
| kashyapc wrote:
| [I work at Red Hat, but not related to CoreOS.]
|
| 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...
| newnewpdro wrote:
| >> The rkt container runtime is not included.
|
| rkt is dead
| c0restraint wrote:
| It is? The GitHub project page does not indicate that:
| https://github.com/rkt/rkt/
| blixtra wrote:
| A former rkt dev here. rkt was archived by the CNCF with
| our blessings. Was just speaking to other rkt folks at
| FOSDEM about archiving the project on GH as well, which
| should happen shortly. We will also announce deprecation of
| rkt in Flatcar Container Linux very soon. rkt really
| changed the container runtime landscape for the best and
| we're happy to see that other projects improved because if
| it and that the space was able to consolidate a bit.
| thebeardisred wrote:
| It was donated to the CNCF years ago. As of today, it's the
| only "Archived" CNCF project:
|
| https://www.cncf.io/archived-projects/ (https://web.archive
| .org/web/20200205190817/https://www.cncf....)
| chipsa wrote:
| Last release was 2 years ago. It's either dead or feature
| complete and bug free.
| fcantournet wrote:
| It is 100% we're finishing our migration away from it right
| now. Never getting kubernetes support killed it.
| wmf wrote:
| It's really dead. rkt never got much adoption and now Red
| Hat is promoting Podman instead.
| stingraycharles wrote:
| But Podman is not the same thing at all.
|
| 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 ?
| plapetomain wrote:
| systemd nspawn
| pkulak wrote:
| Wow, I'd never heard of that. I've been using LXD for a
| while now and love it. From a quick glance at the docs,
| I'm not sure what benefits this has, apart from not
| requiring Snap. :D
| newnewpdro wrote:
| If you're on a systemd distro, one advantage is you
| already have systemd-nspawn. Although, on debian boxes,
| it's split out into the systemd-container package.
|
| 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.
| gigatexal wrote:
| Won't be long until we do systemd ls...
|
| I jest but systemd really is taking over a lot of
| functionality
| newnewpdro wrote:
| It's less worrying if you view systemd as a mono-repo
| containing a collection of related projects maintained in
| one place, one of which is PID 1 - which really should
| have been renamed to systemd-initd.
|
| 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.
| dane-pgp wrote:
| You say that the mono-repo contains a collection of
| "related" projects, but how many of those projects is it
| possible to install and use without installing and using
| at least one other project from the same repo?
|
| 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.
| cycloptic wrote:
| Systemd didn't take this over, nspawn is a pretty small
| wrapper around functionality that already existed. It
| turns out containers are not really that special compared
| to services, and most of the plumbing was already there
| in the service manager anyway.
| newnewpdro wrote:
| > nspawn is a pretty small wrapper around functionality
| that already existed. It turns out containers are not
| really that special compared to services, and most of the
| plumbing was already there in the service manager anyway.
|
| 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/4f923a19844
| 76de344...
| cycloptic wrote:
| >It's not like nspawn just calls into the service manager
| to get things done on its behalf via dbus or something
| like that.
|
| Yes, it literally does? https://github.com/systemd/system
| d/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.
| newnewpdro wrote:
| > Yes, it literally does? https://github.com/systemd/syst
| emd/blob/master/src/nspawn/ns...
|
| 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.
| CameronNemo wrote:
| systemd is a container runtime even without nspawn... you
| can control all of the namespaces and control groups via
| regular service units. Not sure if you can pivot_root
| too, but I would not be surprised.
| CameronNemo wrote:
| Void Linux, Gentoo, and Arch Linux package LXD without
| Snap. Perhaps other distros too.
| kitotik wrote:
| Seems it's at least trending towards dead. Hashicorp Nomad
| recently deprecated the rkt driver for lack of adoption.
| ollien wrote:
| I mean this makes sense, right? Fedora Silverblue exists. Or are
| they totally separate products?
| wwright wrote:
| Silverblue is an effort to bring this technology to the desktop
| AFAICT. Fedora Atomic Server uses some of the technology for
| server workloads, but maintains some traditional structure and
| architecture.
|
| CoreOS is intended to be a "new" architecture for servers if I
| am not mistaken. I may be :-)
| hosh wrote:
| CoreOS was built using Gentoo / ChromeOS / Chromium OS
| family. There is a minimum set of services to run containers.
| Rootfs is read-only. Updates are done atomically by updating
| the standby rootfs, and the swapped at boot.
|
| 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.
| bogomipz wrote:
| >"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)."
|
| I found this interesting. Does anyone have any insights how
| or why Google ended up choosing CoreoS for their GKE
| offering?
| robszumski wrote:
| (Former CoreOS/Red Hat)
|
| I am 99% sure that this offering is only similar in
| nature, not a fork or using any bits from Container Linux
| linuxdude314 wrote:
| Historically CoreOS was the first OS you could easily PXE
| boot and have a working container host without performing
| installation. This was supported not as a secondary
| thought, but specifically designed to make scale out
| easier.
|
| 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.
| bogomipz wrote:
| Thanks for the insight. I was wondering what the two
| patterns are exactly that you referred to here:
|
| >"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
| hosh wrote:
| Yeah. I didn't mean to imply Google chose CoreOS to work
| off of, just that the ideas are there.
| captn3m0 wrote:
| Didn't know GLE bade OS was based on CoreOS. Is this
| documented somewhere?
| hosh wrote:
| Sorry, I misspoke. I did not mean to imply that the
| Google containeros itself is a hard fork, but rather the
| ideas behind them lives on. I think those were based on
| ChromiumOS, but not CoreOS Container OS at least when I
| peeked into running GKE nodes.
|
| As I mentioned in the edit, it looks like FlatCar is a
| true successor fork.
| wmf wrote:
| Fedora Silverblue is for desktops, Fedora CoreOS is for
| servers, and RHEL CoreOS is for supported enterprise servers.
| captn3m0 wrote:
| Interesting that they are yanking AMIs on 1st Sep.
|
| > New CoreOS Container Linux machines will not be launchable in
| public clouds without prior preparation.
|
| Are people here moving to FlatCar or Fedore CoreOS?
| secure wrote:
| FlatCar. I'm using coreos-cloudinit for configuration, and that
| seems to be deprecated with no proper replacement.
| crad wrote:
| Yet another instance of RedHat buying something I used/liked and
| killing it off and offering a shitty alternative. And yet another
| reason I've tried to avoid giving RedHat money over the last 20+
| years.
| quasse wrote:
| I'm especially sad since I finished porting some of our Docker
| infrastructure to CoreOS _today_. I guess I missed the
| proverbial writing on the wall.
|
| Thank god Flatcar Linux looks to be a viable alternative and
| easy changeover.
___________________________________________________________________
(page generated 2020-02-05 23:00 UTC)