
End-of-Life Announcement for CoreOS Container Linux - thebeardisred
https://coreos.com/os/eol/
======
zymhan
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
This is the Red Hat "stay in business" business model, not the CoreOS "make it
up in volume" business model.

~~~
mixmastamyk
How is breaking compat good for business?

------
crad
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
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.

~~~
dharmab
How did you miss the announcement back in July?
[https://fedoramagazine.org/introducing-fedora-
coreos/](https://fedoramagazine.org/introducing-fedora-coreos/)

------
vlowther
well, good thing there is [https://www.flatcar-
linux.org/](https://www.flatcar-linux.org/)

~~~
astrea
> 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
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/](https://www.flatcar-
linux.org/releases/)) and have been waiting to do that with the other
channels.

~~~
merb
it would be cool if [https://github.com/coreos/container-linux-update-
operator](https://github.com/coreos/container-linux-update-operator) would
also be part of flatcar.

------
captn3m0
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
FlatCar. I’m using coreos-cloudinit for configuration, and that seems to be
deprecated with no proper replacement.

------
qwerty456127
Fedora CoreOS. Oh my. I din't even know Fedora Core is not the full name of
the ordinary Fedora OS any more...

~~~
pepemon
12 years have passed. Glad that you woke up.

~~~
qwerty456127
I still don't feel like Fedora CoreOS is a good name choice for a new OS
distinct from what used to be named Fedora Core. Perhaps they could name it
after another kind of hat or something.

------
bovermyer
What about RancherOS? Is that a viable replacement?

~~~
ShakataGaNai
I'm surprised more people aren't mentioning RancherOS. It's a great "Docker
Only" OS, like many of the other options mentioned. It doesn't have the market
that CoreOS did, that's for sure, but still a great tool. It's tiny and being
actively updated.

Plus it's got good RPi support for all those serious Big Software Company
deployments /s

------
fkistner
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.

~~~
choward
I'm not sure exactly what you mean by "immutable" but you might find NixOS
([https://nixos.org/](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](https://github.com/NixOS/nixpkgs/issues/63720)).

------
ollien
I mean this makes sense, right? Fedora Silverblue exists. Or are they totally
separate products?

~~~
wwright
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
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
>"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?

~~~
linuxdude314
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
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

------
rubyn00bie
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...?

~~~
dharmab
My team at a Very Large Software Company runs CoreOS for two main reasons:

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.

~~~
m4rtink
I think kickstart is quite well documented, both upstream and in RHEL:

[https://pykickstart.readthedocs.io/en/latest/https://access....](https://pykickstart.readthedocs.io/en/latest/https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/7/html/installation_guide/sect-kickstart-syntax)

Any concrete examples of stuff the existing docs do not cover ?

~~~
dharmab
I've maintained both kickstart and ignition professionally. The documentation
and readability of Ignition is absolutely way better than kickstart.

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.

~~~
m4rtink
Ideally one uses mainly kickstart commands to configure the system during the
installation - then the installer (Anaconda) takes care for everything for
you. If you use custom scripts with kickstart, you are pretty much on your
own, like with any other custom script.

BTW, maybe open an RFE to include a helper script in the installation
environment for easy & robust file downloading ?

------
merb
stuff that is happening with CoreOS is a complete NIH show. it's really akward
what they are doing.

