We believe that frequent, reliable updates are critical to good security. Unfortunately, existing configuration management tools often encounter inconsistent state from machine to machine within a large cluster. This adds an enormous amount of complexity to running an update on large production deployments.
CoreOS minimizes the complexity of an update by compartmentalizing each entity that normally needs to be updated: the operating system, application code, and simple configuration values.
CoreOS updates are consistent because they rely on active-passive root partition scheme. We update the entire OS as a single unit, instead of package by package.
By deploying and running your code in containers, each application is fixed with all of its dependencies. This eliminates dependency conflicts, extensive test cases and many annoyances. Containers can be shipped from dev → test → production and will be bit for bit identical in either environment.
Container isolation means you can update each application independently of each other with ease. Even the most poorly coded application can't harm another running on the same machine.
Read more about docker + CoreOSDistributed platforms contain hundreds of configuration values. Every cache setting, database address, firewall rule and rate-limit needs to be stored somewhere. Traditionally you update these values via Chef or Puppet. The problem is, you can't audit the state of hundreds of machines before you execute your single config change. What if you triggered a library upgrade on a machine that was missed on the last run?
CoreOS provides distributed configuration with etcd to solve this problem. A single config value can be changed atomically, and only applications that listening for that change will be affected. Each application can decide how to react to a value changing, and that logic can be updated independently of other applications.
Read more about etcd + CoreOSUpgrading CoreOS is a bit different than the usual Linux distros. Instead of updating a single package at a time, CoreOS downloads an entirely new root filesystem and installs it to the passive partition. After the next reboot, CoreOS will be running the latest version.
The dual-partition scheme has many benefits over an in-place upgrade:
kexec can skip the bootloader process, decreasing reboot time further.
Our update system is based on Google's open-source project, Omaha, that powers updates for the Chrome browser, Chrome OS, Google Earth and more. It features advanced population control and grouping functionality that takes the guesswork out of a rolling upgrade throughout the fleet.
Initially your system is booted into the root A partition and CoreOS begins talking to the update service to find out about new updates. If there is an update available it is downloaded and installed to root B. To ensure we don’t disrupt your application we rate limit the disk and network I/O this process is allowed to use with Linux cgroups.
Using this dual-root scheme is an improvement on the existing workflow of yum or apt-get. Often when upgrading using these tools you can find that the package manager will kick daemons to get them using new libraries or move configuration files around. With CoreOS, a system update is an atomic operation that can be rolled back.
On CoreOS, the root partition you are running against isn’t modified and your server is never in an unstable or partially upgraded state. To finish off the upgrade, reboot the machine and in a few seconds you will start running on root B with a freshly updated system.