The
servers that run our applications, our businesses, all depend on the stability and underlying features offered by the installed operating system (or OS). As administrators, we have to plan ahead and think ahead about how our users will use the machines we monitor while ensuring those machines remain stable and online. There are numerous operating systems to choose from; however, one of the most popular, most stable and highly compatible operating systems is CentOS. A combination of great features, strong performance stability, and support from enterprise-centric institutions like Red Hat and Fedora have led CentOS to become a foundational operating system that administrators can count on.
Although extremely stable in both iterations, the switch from CentOS 6 to CentOS 7 sparked a number of changes that have polarized the community surrounding CentOS and put administrators in a position of having to determine which one is best for their projects and organization. The choice of the version you use for a given project depends on a number of factors that only you will know. However, there are some common concerns/points of interest that can help make your decision easier.
The
first aspect, and ultimately the most important to consider, is what need are you trying to satisfy? Knowing what the problem really is will provide a clear path to determining what the ultimate solution will be. Some of the example “needs” I’ve helped clients try to negotiate requirements for here at Liquid Web are:
- Use newer, more powerful hardware while supporting legacy applications
- Prepare a test and staging environment for a project to be developed
- Migrate client/system application data from end-of-life software to compatible software
All of the above requires examining the requirements of existing systems and considering what difficulties would be involved and how to overcome them. Some points
to consider: If you have legacy systems that you are trying to
- support or perhaps systems already using CentOS 6 that are simply trying to migrate to newer hardware, you will want to consider a test environment running CentOS 7 before migrating to it in a production environment. There are numerous changes to the underlying operating system, command syntax, and even package versions available. Encountering problems in production due to a change in the expected environment is an easily avoidable problem.
- Maintaining a consistent environment can dramatically reduce support overhead. Also: If your environment currently consists of CentOS 6-based hosts, you won’t have to worry about the educational aspect of training you or your staff on the differences/nuances that separate CentOS 6 from 7. If you have fully managed servers here at Liquid Web, you can rest easier as our support staff is comprised of Red Hat RHEL 6 and 7 certified system administrators (more on this below).
- If you have the opportunity to start a project with CentOS 6 or 7, you’ll want to think about the lifespan of that project. If it’s a short-term project, the benefits of being on an operating system you’re familiar with may be greater than an operating system that’s newer. If the project will be long-term compatible, you’ll want to consider the lifespan of the software packages and the support offered for the operating system.
If this is a new project, it is highly recommended to use CentOS 7 simply because of the continued support you will receive, which is my next topic of discussion:
Support Timeline
CentOS has a unique version scheme that they have adopted for their most recent operating system. It’s important to recognize the version you’re in, which version you need/want, and the benefits of any given version. If your project’s timeline sees the project lasting a decent amount of time, you’ll want to consider the need for updates/patches for your operating system. The benefits of using CentOS 6 vs CentOS 7 can depend entirely on how long you need to receive support.
The CentOS wiki
does an excellent job of breaking down the meaning of CentOS 7 version numbers (point #29); however, the basic way to remember versioning for CentOS 7 is: “two-digit two-digit month of the year and two digits”. So the following: CentOS-7-1406 is representative of the CentOS 7 build from June 2014. The main reason for the change is to provide a quick reference of when a version of CentOS 7 was released and allow you to understand if it will be supported. The ONLY supported images are the most recent image in the secondary branch. Liquid Web regularly updates our fully managed servers to ensure they are running the latest secondary branch, ensuring you receive the necessary updates/patches to stay protected.
The deadline for CentOS 6 to no longer receive updates is November 30, 2020. After this point in time, CentOS 6 will be declared “End of Life” and will receive no further updates (patches, security, etc.). Although this means that CentOS 6 will eventually suffer from issues that have not yet been discovered or will not be compatible with newer hardware, it does not mean that it cannot yet be used for a project and work smoothly. Liquid Web Support will also continue to provide assistance with CentOS 6-based servers and guide you on the best way to upgrade to CentOS 7 if you wish. This also gives you time to start testing CentOS 7 (perhaps with a virtual server that can be easily created/torn down) and figure out what changes you’ll need to make so that your app can run smoothly on the newer OS.
While you have time to decide whether CentOS 6 or 7 can be used, it’s best to look to the future of your hosting environment. CentOS 6 no longer receives updates creates a potential security risk, as malicious people will be able to exploit bugs/weaknesses that are discovered later without fear of those holes being patched. It takes time to migrate the infrastructure and those looking to take advantage of that fact will be probing their servers and applications to try to find those weaknesses that will not be corrected. However, the amount of time it takes to migrate depends on a number of factors, including the big changes and differences between CentOS 6 / CentOS 7. The next section discusses what many consider the biggest change:
SystemD
Undoubtedly, it was the introduction of SystemD that created the most controversy surrounding the release of CentOS 7. Although it was known for a while that it would filter from the upstream source (CentOS uses Red Hat as the upstream, which in turn uses the Fedora project as the upstream), it was a major change for people used to CentOS 6. This adoption of SystemD meant that applications and software had to be examined and tested to make sure they worked properly on CentOS 7 and that SystemD’s architecture was not causing problems. The design of SystemD was such that it should be backward compatible; That doesn’t mean every change is something that can be overlooked because it won’t cause problems. Elements to consider when choosing CentOS 7 for your project:
- Do you need to have complete control over
- your application need to interact with daemons and other services regularly
- Do you expect to be able to override operating system defaults with your own package options?
your system and registry? Does
?
Once this example of why SystemD can create problems: SystemD produced “targets”, which were similar to the “startup levels” of CentOS 6. Each “goal” sets out the services to be initiated and are designed around specific purposes. However, this is a great example of why testing to ensure your application works is key: targets are not startup runlevels, and customizations you may have made at a given runlevel may not work. This change in default behavior can have unintended consequences if your environment is not designed to handle those changes. Altering
defaults is a frequent theme in CentOS 7 and that brings me to my last topic:
Defaults have changed
The last topic to touch on is the default changes you’ll see between CentOS 6 and 7. Again, this all relates to what your app designed to handle. The following are some of the defaults changed from CentOS 6 to CentOS 7 that people will probably notice:
Default file system changes from
- EXT4 to XFS Default kernel
- 2.6 to 3.10
- Iptables to FirewallD Default
- management system changes from MySQL to MariaDB
changes from
Default firewall changes from
database
These options can be fixed, but you run the risk of creating a system that constantly tries to “fix” and correct so that it can handle the changes introduced. Evaluating whether you even need to worry about these changes is another component to determining whether CentOS 6 or 7 will make a difference in your project.
Conclusion
Although CentOS 7 has been out for a while and SystemD has been used for even longer in the upstream phase, there are bugs and issues that are being resolved. CentOS has been a mainstay in the hosting world for the solid stability it provides, and most of that carries over to CentOS 7. It is still thoroughly tested and has a large community surrounding the development. The future is with SystemD and the changes that are occurring, and if you need support or wait for updates, you will be forced to use CentOS 7. However, only you know what your project requires and what it depends on. Whether you’re familiar with CentOS 7, SystemD, and the process of migrating your data, Liquid Web is here to help.
If you’re interested in seeing some of the changes that CentOS 7 makes, check out the Knowledge Base for articles on CentOS 7 and common operations/tasks.