Skip to content

Latest commit

 

History

History
88 lines (54 loc) · 2.47 KB

demo-3.md

File metadata and controls

88 lines (54 loc) · 2.47 KB

demo-3.md

3 - CoreOS Update-engine usage and management

CoreOS update philosophy

CoreOS believes the ability to easily and automatically update software is the most effective way to improve server security.

To do so, they have implemented the Omaha update protocol, defined by Google for the Chrome web browser on Windows. The features provided by this protocol are:

  • Atomicity
  • Coordination
  • Automatic rollback

The disturbing concepts are :

  • Updates are "pushed"
  • Updates are automatically installed

Official links from CoreOS:

Update components

A - Update-engine

Update-engine

The update-engine is the program in charge of:

  • Downloading the update
  • Installing the update
  • And asking for a reboot to apply the update

The Omaha protocol has a concept of "coordination" with "canary" servers, update window, ... but the update-engine is not in charge of it. This task is delegated to the locksmith utility tool.

B - Locksmith

Locksmith

locksmith is a reboot manager for the CoreOS update engine which uses etcd to ensure that only a subset of a cluster of machines are rebooting at any given time. locksmithd runs as a daemon on CoreOS machines and is responsible for controlling the reboot behaviour after updates.

Setp by step management

CoreOS "pushes" the updates... but,

  • How can I control which update is pushed to my clusters ?
  • How can I control when the updates are applied ?
  • How can I see and visualize the state of the nodes ?
A - CoreRoller introduction

demo-3A

B - CoreOS configuration

demo-3B

C - Update progress follow-up

demo-3C