CoreOS Beta Release

May 9, 2014 · By Alex Polvi

After 150 releases and 9 months in alpha, we are excited to announce the first CoreOS Beta. Starting today, we will be releasing both alpha and beta versions of CoreOS. The beta means you can expect CoreOS itself to not change in any significant way and is close to production readiness.

The beta includes a new feature, Locksmith, giving you control over the CoreOS update process, as well as a variety of bug fixes and feature enhancements.

Locksmith

Locksmith gives you full control over when CoreOS is rebooted after an update is applied. The most advanced feature is the ability to acquire a distributed lock using etcd, before a reboot is applied. This means that you can guarantee, using the consensus algorithms in etcd, that only one machine at a time will be upgraded via reboot. This is critical for rolling an update to all your machines, without taking down the cluster. If you use fleet for deploying services, this also means that your processes will be seamlessly migrated around the cluster as the update is performed. Since CoreOS reboot extremely fast (1-2s), you can roll a large cluster in a matter of minutes.

Configuring locksmith

The easiest way to use Locksmith is via Cloud-Config. The following strategies are supported:

  • reboot: Reboot immediately after an update is applied.
  • etcd-lock: Reboot after first taking a distributed lock in etcd, this guarantees that only one host will reboot concurrently and that the cluster will remain available during the update.
  • best-effort - If etcd is running, "etcd-lock", otherwise simply "reboot". (default)
  • off - Do not reboot after updates are applied.

Example cloud-config.yml:

#cloud-config
coreos:
  update:
    reboot-strategy: etcd-lock

Full Locksmith Documentation

View the full Locksmith docs for more information.

How Updates Work on CoreOS

CoreOS uses update channels similar to client sofware applications, like the Chrome browser. Updates are first shipped to our alpha channel, then if testing is successful, the update is promoted, bit for bit, to the beta channel. Effectively, every alpha is a release candidate for a beta, and every beta is a release candidate for a stable release.

As an example of this in action, the alpha channel will soon be updated to Docker 0.11. Docker 0.10 is still on the beta channel, but will be promoted to 0.11 once our alpha testing has been completed. We expect beta to lag behind alpha approximately one week. If you want the latest features, use the alpha. If you want stability and feature completeness, use the beta.

Switching Channels

If you're getting closer to running CoreOS in production (and some of you already are), you're probably wondering how to switch your alpha channel machines over to the beta channel. It's really easy and we've got a quick Switching Release Channels guide for you. As you're booting new machines, be sure to base them off your desired channel from the beginning.

Roadmap to Stable

Today's beta release gets us much closer to a stable, and production ready version of CoreOS. The primary work before the stable release is focused on stability of fleet and etcd. Do not expect any major new features, more likely removing unused ones.

New coreos-user Mailing List

Primary discussion of CoreOS will move to coreos-user. CoreOS development discussion will still be on coreos-dev.

Finally, thank you to the incredible community that has grown with CoreOS. We're are committed to making CoreOS the best platform of its kind, and coudl not do it without the help from all of our alpha testers.