SoylentNews is people
SoylentNews
from the you-have-only-3-months-to-migrate-off dept.
Red Hat is set to fling a flaming arrow at Red Hat CoreOS Container Linux*, the software firm said as it laid out the details of the end of life timeline for the distro it acquired in January 2018.
[...] Users who want something similar outside the context of OpenShift are directed to Fedora CoreOS, the community version, which is "the official successor to CoreOS Container Linux," according to the end of life announcement. That said, Red Hat has admitted: "Fedora CoreOS cannot currently replace Container Linux for all use cases."
[...] The team said: "We've found that the incremental, exploratory, forward-looking development required for Fedora CoreOS — which is also a cornerstone of the Fedora Project as a whole — is difficult to reconcile with the iron-clad stability guarantee that ideally exists when automatically updating systems."
Red Hat noted there is a fork of CoreOS Container Linux called Flatcar Linux which may be more suitable for users who do not want to jump into OpenShift. Flatcar Linux is supported by a Berlin company called Kinvolk.
The end of life timeline for CoreOS Container Linux is aggressive, Red Hat said. May 26 is the last date for updates including security patches. From September 1st, "published resources related to CoreOS Container Linux will be deleted or made read-only. OS downloads will be removed, CoreUpdate servers will be shut down, and OS images will be removed from AWS, Azure, and Google Compute Engine. GitHub repositories, including the issue tracker, will become read-only." The reason for deleting OS images is to discourage continued use after end of support.
(Score: 2) by DannyB on Wednesday February 19 2020, @03:15PM
Has anyone tried Rancher OS instead of Core OS?
I have dabbled and experimented a bit with Docker, Kubernetes, and thus a bit of Rancher OS. Haven't tried Core OS.
Since Apache Tomcat can be run in a clustered mode, I have considered that, if there ever were such a need, I could run multiple Tomcats across multiple machines in a cluster. (Even without the need for greater scale, this could also provide a hot failover redundancy.) While a couple or several Tomcats could be managed by simply setting up several VMs, I thought the idea of Docker packaging and playing with Kubernetes might be interesting. Then, on a suitably equipped Kubernetes cluster, you have the potential to not only scale up to a handful of instances, but to dozens or hundreds. Not that I have such a need.
I've got more than the scale I need right now by just throwing bigger hardware at it.
If I ever had to cluster the Tomcat servers, then I probably might need a clustered SQL database as well. If my app grows to where this is needed, I'll be delighted.
The lower I set my standards the more accomplishments I have.