Skip to main content

CoreOS Beta Release

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 it should be considered close to production-ready.

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 complete 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, thanks to 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 reboots extremely fast (1-2s), you can roll a large cluster in a matter of minutes.

Configuring locksmith

The easiest way to configure Locksmith is via Cloud-Config. The reboot-strategy option determines what action Locksmith takes after an update has been applied to the system. 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 software 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. Essentially, 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. In general, we expect beta to lag behind alpha by 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, 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 the removal of unused ones.

New coreos-user Mailing List

Primary discussion of CoreOS will move to the new coreos-user list, and we invite you to join us there for discussion and questions around using CoreOS. CoreOS development discussion will remain on the existing (https://groups.google.com/forum/#!forum/coreos-dev)dev-list list.

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