Release Channels

Release Versions

Container-Optimized OS versions are represented as 3-tuples of integers; for example, 10895.52.0. New Container-Optimized OS versions are lexicographically greater than older versions. For example, version 10895.10.0 is newer than 10895.9.0. These version numbers do not have much meaning beyond understanding which images are newer than other images.

Release versions are visible as the suffix of a Container-Optimized OS image name. As an example, the image cos-beta-69-10895-52-0 has the version 10895.52.0.

Release Milestones

Container-Optimized OS images are released on release milestones; example release milestones are 60, 61, and 62. A milestone is a sequence of images going through the stages of our development cycle; see Release Channels for more information about our development cycle. Release milestones are analogous to major software versions.

The milestone of an image is typically visible in a Container-Optimized OS image name. As an example, the image cos-beta-69-10895-52-0 is part of milestone 69.

Release Channels

Container-Optimized OS release channels are stages of stability that each milestone goes through over the course of its development. Each milestone goes through three release channels:

dev Channel

A milestone on the dev channel undergoes active feature development. Images are regularly released on a dev milestone. New releases on a dev milestone include the latest features from the Container-Optimized OS team. There is usually only one milestone on the dev channel at a time. A milestone on the dev channel is promoted to the beta channel after approximately six weeks.

beta Channel

A milestone on the beta channel is feature complete. New releases on a beta milestone typically only include bug fixes. There is usually only one milestone on the beta channel at a time. A milestone on the beta channel is promoted to the stable channel after approximately six weeks.

stable Channel

Milestones on the stable channel are well-tested and expected to be high quality. New releases on stable milestones are rare and include critical bug fixes and security updates. There are usually multiple milestones on the stable channel at a time. A milestone on the stable channel is eventually deprecated, at which point new releases are no longer made on the milestone. Refer to the Support Policy to learn more about the support window for each milestone.

Container-Optimized OS users can use images from any of the release channels. The rule of thumb for choosing a release channel is:

  • For testing and prototyping, select the latest image from the dev or beta channels.
  • For production deployments, select an image from the stable channel.

How do I take advantage of release channels?

Release channels give Container-Optimized OS users visibility into the development of a Container-Optimized OS milestone. It is strongly recommended that users set up tiered testing along with their production environment to utilize the release channels. For example, a light-weight "nightly" test environment can pick up the latest releases on the dev channel to test new features as well as to catch any potential breakage as early as possible, and a more involved "staging" or "canary" test environment that mimics the production environment can pick up latest releases on the beta channel. This kind of setup will minimize surprises when switching the production environment to a newer milestone on the stable channel.

Auto Updates

Container-Optimized OS uses an active-passive root partition scheme. The OS image is updated in its entirety, including the kernel, as opposed to package-by-package updates like on traditional Linux distributions. The image ships with the auto-update feature enabled; this means that a default Container-Optimized OS instance always downloads a newer OS version on the same channel and installs it on the passive partition soon after it's released. Note that the update does not take effect until the instance is rebooted, and the auto-updater does not force reboot when an update is installed. After an updated version has been installed, the instance must be rebooted before it can update to a newer version.

Users can check the status of auto-update using the following command on a running instance:

sudo update_engine_client --status

Users can trigger an auto-update using the following command on a running instance:

sudo update_engine_client --update

Disable auto-updates by setting the cos-update-strategy metadata when creating a new instance:

gcloud compute instances create ... --metadata cos-update-strategy=update_disabled

Or use add-metadata on an existing instance:

gcloud compute instances add-metadata ... --metadata cos-update-strategy=update_disabled
Was this page helpful? Let us know how we did:

Send feedback about...

Container-Optimized OS