Bottlerocket is designed to be updated in an image-based fashion.
This means that updates are applied by downloading an image of the entire operating system to a different partition on disk, then switching to using that partition when the system is rebooted.
This is done instead of a series of individual package updates on the current operating system partition.
This is a departure from the traditional package-based Linux update model such as
yum, which are what you would find in Ubuntu or Amazon Linux.
Ways To Update
The update method you choose depends on the Bottlerocket variant you are using and your environment.
The ways to update Bottlerocket can be classified into two main categories: in-place updates and node replacement. In-place updates are updates that are applied to the same node (no infrastructure reprovisioning), while node replacement is when you replace an existing node with a new node that is running the updated version of Bottlerocket.
At its core, an in-place update is a call to the Bottlerocket API server using
apiclient command can be run from the control container.
There are also orchestrated systems that perform the
apiclient calls for you: the ECS updater for ECS, Brupop for Kubernetes, and SSM Command Documents for both.
The following table shows whether a given update method is an in-place update or a node replacement.
|SSM command documents
There are many ways to update Bottlerocket, including:
apiclientcommands directly in the control container
- The ECS updater
- Brupop, the EKS Console, and
- Applying SSM Command Documents to your nodes
It is also possible to lock your nodes to a specific release.