CoreOS: Control the Container Craziness

If you have been following the Linux container space lately you know that it is a fast paced place with frequent updates. Docker being the largest of the technologies at play is taking the DevOps world by storm making every ones life easier, or does it. Docker is a wonderful technology that is revolutionizing the way we deploy and run applications. However, if you plan to go to production with Docker you have to choose a strategy that will make it stable and secure. Docker will run on just about any modern Linux OS, but if you just go out and install it you could be in for lots of work. This is where I think CoreOS comes in. CoreOS is a lightweight OS with the sole purpose to run Linux containers. I didn’t just say Docker containers because there is a competing technology called Rocket being worked on by the CoreOS folks, but that is a topic for a different time.

Docker is the biggest of the two and very frequently updated. Sometimes as frequent as every two weeks. This means that it has a lot of potential to break things especially since you could have 50-100 applications running on the same host in some situations. With this in mind, imagine what havoc a serious issue at the docker level could cause. One of the things I love about CoreOS is that it has a slick update system and bundles docker updates into the OS so you don’t have to worry so much about making sure critical packages are updated. The CoreOS folks are very focused on quality and do large amounts of testing to ensure that the OS and all of it’s components are stable. This shows when compared to Ubuntu. For example, back around Docker version 1.7.1 there was a pretty serious bug that caused containers to fail to start because they couldn’t find the docker network bridge. This was ultimately caused by a kernel change, but it caused big problems on most OSs Docker ran on. When I first starting playing with CoreOS it was running Docker 1.7.1 and we were worried that this bug would be present, but after using it for a short period of time I realized that this bug just didn’t exist on CoreOS. Come to find out this was because the issue had been caught in CoreOS’s alpha and beta testing. This allowed them to fix the issue before it made it to production systems. A bug that was a crippling issue on other systems was a non issue that allowed you to take advantage of the new features right away instead of waiting for Docker fix the issue. This is why CoreOS is my choice of OS to run linux containers. They have proven again and again that they take stability and security very seriously which makes life in Production much easier as you can have confidence that when you reboot for an upgrade you’ll come back up with a stable system, and if something does go wrong during an upgrade you don’t have a useless server as it will just boot back into the previous system version since it use an A/B partition update system which downloads the whole OS to a second partition then reboots to switch to it allowing it to updates that happen very quickly with minimal downtime since applications can easily be transferred to other hosts before the reboot.

While there are many options out there for OSs to run Linux containers, I choose CoreOS due to its minimalist, stable, and secure platform. If you want stability I suggest you take a look at it as well.

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *