Try our new open source stack builder and get a free, customized report >> Get Started
With the CentOS community shifting its focus to CentOS Stream, and CentOS 8 now reaching EOL at the end of 2021, many companies are considering if they're ready to take the plunge on CentOS Stream, or if they need to seek out another option.
In this blog, we discuss CentOS Stream and its benefits, as well as provide a checklist that companies can use to assess their readiness to migrate to CentOS Stream.
Some organizations who rely on CentOS will be able to embrace Stream and take full advantage of early delivery of features, fixes, and vulnerability patches that it offers. Others, however, may see this change in release cadence as too disruptive to their infrastructure and operations.
That difference really comes down to how prepared an organization’s deployment processes are to accept a rolling operating system. That’s easy to say, but what does that mean, tactically? To answer that question, we’ve assembled a CentOS Stream pre-flight checklist. Note that most of these principles also extend to other rolling operating systems, such as OpenSUSE Tumbleweed.
Using CentOS 8?We are currently offering a free, one-hour consultation for CentOS 8 users to discuss your current infrastructure and the best path forward for your company.Schedule Your Free Consultation
We are currently offering a free, one-hour consultation for CentOS 8 users to discuss your current infrastructure and the best path forward for your company.
Schedule Your Free Consultation
Parts of this checklist will look a lot like a continuous integration checklist, but make no mistake, feedback from continuous delivery is essential as well. If all of this just really sounds like an assessment of an organization’s DevOps maturity, that observation isn’t too far off the mark. The community decision to focus on a rolling release operating system absolutely reflects a community who wishes to transform their product into one that not only conforms, but truly thrives on modern DevOps practices. Their continuing commitment to semantic versioning, and their promise to only build towards the next dot-release of RHEL will ensure that other shops which have developed similar practices can continue to use CentOS reliably.
A new release means releasing both the app and the dependencies, including the operating system, all as a single unit. That unit is typically in a VM, cloud image, or container. The build process is “from scratch,” pulling down a base operating system, laying down the application, and fully configuring the environment all happens during a release. This, and any other modifications to the base image are made in a fully automated way as part of the build procedure. Generally, this build is scheduled as part of an accepted developer commit or pull request, or some other accepted change to the code base. This ensures that rolling dependency updates to the operating system are considered as part of every new build and are included in downstream testing actions.
Anything necessary to support the build is held in a local artifact repository, and versions can be semantically controlled. This could include code dependency artifacts held in technologies such as Artifactory or Sonatype Nexus, but also refers to things like base Docker images or “golden” VMs or cloud images. Operating System dependencies are included as well, and preferably tracked and managed through enterprise package management solutions such as Spacewalk. This will allow for strict control over updates that come rolling from upstream dependency repositories.
Once the image has been built, as described in our first bullet, all necessary tests are run against the image. Since the image includes the full environment, this testing would include all infrastructure scans such as vulnerability scans, static code analysis, and fuzzing, along with whatever prescribed staging, unit, and other tests are needed. These tests kick off after the build phase above, and are fully automated.
Feedback is given to the build teams immediately, ideally directly to the developer who is responsible for making the change. Any failures in any state of the build are clearly communicated to the developer, and the testing environment is destroyed upon those failures. New testing environments will be spun up upon completion of the build phase as described above. Successful builds are communicated as well, with stakeholders made aware of the newly available build, and any CD pipelines are alerted to the build’s presence and react accordingly.
For non-interactive workloads, this means gathering metrics about the state of the workload, and any kind of exception. The business must be able to quickly, preferably automatically, spot trends and differences that might denote unexpected behavior as the result of a change, and alert teams or engage other healing mechanisms. This will ensure that any undesirable behavior introduced by a rolling dependency upgrade is caught quickly and isn’t impacting to users. For interactive production workloads, techniques such as canary testing should be implemented to automatically roll back changes when unexpected impacts to user experience are introduced.
Businesses who can conform to the practices above will find that the transition to CentOS Stream has very little impact to their business continuity. In fact, these businesses will now benefit from automatically taking security fixes ahead of RHEL customers in most cases, and have access to the newest functionality and optimization. As the world around us becomes more digitally driven, this kind of velocity is essential to keeping pace with the expectations of consumers, and the capabilities of the competition.
Whether you are ready to take the plunge on CentOS Stream, you are looking for extended support, or you are looking for a CentOS alternative, OpenLogic can help your company find success. Talk to an expert today to learn more about what we can do for your team.
TALK TO AN EXPERT
Have questions about the future for CentOS? This webinar answers many of the questions we have received from our clients.
Chief Evangelist - OSS & API Management, Perforce Software
Justin has over 20 years of experience working in various software roles. He is an outspoken free software evangelist, delivering enterprise solutions, technical leadership, and community education on databases, architectures, and integration projects.