decorative image for blog on a preparation checklist for using centos stream
April 11, 2024

CentOS Stream Migration Checklist

Operating Systems
Open Source

By

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.

Table of Contents

  1. Is Your System Ready for a CentOS Stream Migration?
  2. CentOS Stream Migration Checklist
  3. Final Thoughts

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 top

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

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

Explore CentOS LTS

Back to top

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.

 
CentOS Stream Migration Checklist
 

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 top

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

Not Ready for CentOS Stream?

Whether you are looking for extended support or exploring CentOS alternatives, 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

Additional Resources

Back to top
professional headshot of Justin Reock

Justin Reock

Field CTO / Chief Evangelist, Gradle Inc.

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.