Updates
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.
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
.
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 |
Conclusion
There are many ways to update Bottlerocket, including:
- Running
apiclient
commands directly in the control container - The ECS updater
- Brupop, the EKS Console, and
eksctl
on Kubernetes - Applying SSM Command Documents to your nodes
It is also possible to lock your nodes to a specific release.