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 apt
or yum
, which are what you would find in Ubuntu or Amazon Linux.
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
.
The 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.
In-Place Updates | Node Replacement |
---|---|
apiclient commands | EKS Console |
ECS updater | eksctl |
Brupop | |
SSM command documents |
There are many ways to update Bottlerocket, including:
apiclient
commands directly in the control containereksctl
on KubernetesIt is also possible to lock your nodes to a specific release.