With the Red Hat now focused CentOS Stream and the upcoming CentOS 7 EOL, many companies are considering whether they're ready to plan a CentOS Stream migration 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 for a CentOS Stream migration.
Editor's Note: This blog was originally published on February 25, 2021 and was updated on April 11, 2024.
Back to topIs Your System Ready for a CentOS Stream Migration?
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 migration checklist. Note that most of these principles also extend to other rolling operating systems, such as OpenSUSE Tumbleweed.
Back to topNeed More Time on CentOS?
With long-term support from OpenLogic, you can stay on your current version of CentOS for five years beyond end-of-life. We also can provide technical support and migration guidance. Click the button below to learn more.
CentOS Stream Migration Checklist
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.
| Servers Are Not "Patched in Place" | |
| Dependencies Are Held in Local Repositories | |
| Testing and Scanning of the Image Is Fully Automated | |
| Build Behavior Is Visible | |
| Full Monitoring and KPI Gathering Is in Place |
Checklist Item #1: Servers Are Not “Patched in Place”
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.
Checklist Item #2: Dependencies Are Held in Local Repositories
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.
Checklist Item #3: Testing and Scanning of the Image Is Fully Automated
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.
Checklist Item #4: Build Behavior Is Visible
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.
Checklist Item #5: Full Monitoring and KPI Gathering Is in Place
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.
Back to topFinal Thoughts
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.
Get SLA-Backed Support for CentOS Stream
OpenLogic can help your company find success while taking advantage of all the latest and greatest Enterprise Linux features in CentOS Stream. Talk to an expert today to get started!
Additional Resources
- Blog - CentOS Stream 10 Preview
- Blog - AlmaLinux vs. Rocky Linux: Exploring the Key Differences
- Blog - What's New in Rocky Linux 9
- Blog - What's Next for CentOS Stream
- On-Demand Webinar - Discussing the Future for CentOS
- Blog - Choosing the Right Linux Distribution
- White Paper - Decision Maker's Guide to Enterprise Linux