Should I be using CoreOS for my containers?
Generally I've been using either Ubuntu or Alpine as bases.
Also it looks to be Red Hat based? Is there a Debian equivalent?
Generally I've been using either Ubuntu or Alpine as bases.
Also it looks to be Red Hat based? Is there a Debian equivalent?
So that's quite interesting. Because on the host I generally run Ubuntu 18.04. Because I know how it works and can ensure it's secured and up to date.
Same with someone with familiarity with Redhat/Centos etc.
But installing a whole different OS?
Like I get it on niche Linux distros where people like packaging their desktop environments whilst pulling in Debian packages for everything else, for example.
But what's the advantage here?
First is minimalism - it's designed to run containers.
Next is automatic, atomic updates - layers that comprise the entire OS are "pulled" and updated when the host boots, similar to how updates work with containers. Because updates are atomic, they can also be rolled back.
I think there is also built-in support for rolling updates across a fleet of host machines.
I find CoreOS a very interesting proposition, but because it's so different from other distros, there is going to be a learning curve.
CoreOS Container Linux is not. But changes are not persistent over redeployment. That's nice for quick testing and development, but of course fatal should you do it in a production system. And of course not ideal for security.
Disclaimer: Edited for false claims. Hope, it's correct now...
Btrfs will support cryptographically secure hash algorithms (sha256 and blake2) starting with kernel 5.5. I wonder if this is a suitable compromise over dm-verity, which can't be updated, and more conventional file system options? When I consider various use cases, Btrfs always results in EIO rather than propagating bad data to user space; compress=zstd:1 reduces writes, saves storage space, and can improve performance of slower storage.
There's also two interesting read-only options: read-only snapshots and read-only volume (via the seed flag), root can't write to either. Root would need to unset the flag first. A read-only seed can support writes via a volatile 2nd device, e.g. /dev/zram device, reboot and you get a reset. Or persistence via a partition. Either way a reset also resets filesystem state.
I can eat a lot of shakeup in my own data center or cloud but a shipped box makes that a lot more problematic.
I personally find CoreOS very confusing. None of the advantages you mentioned are a problem nowadays, for personal computing. I haven't heard of Debian, Ubuntu, or RHEL update that would bork the system in a long while. All of these distros are more than capable of running containers...
And, for corporate use? You'd use Debian + Kubernetes to take care of your needs, wouldn't you?
As I said, I'm left here scratching my head, thinking up usecases for this system.
Fedora CoreOS is designed to have the smallest possible attack surface out of all operating systems currently capable of hosting containers.
Unlike Ubuntu, Debian, and CentOS, Fedora CoreOS doesn't contain packages that aren't required for hosting containers, and is automatically kept up-do-date without any manual interventions.
Just like Chromium OS on PCs, Fedora CoreOS on servers eliminates the need for "dist-upgrade", and thus reduces risks and increases reliability.
CoreOS is designed for these workloads. For example, with OpenShift 4 (Red Hat enterprise Kubernetes) the masters run on RHCoreOS and the worker nodes have the option of running on RHEL or RHCOS. You can end up having your entire Kube platform running entirely on CoreOS, either bare-metal or virtualized.
Fedora CoreOS is big as OCP uses RHCOS. OKD (the community version) needed its own platform and FCOS is that platform.