What is Bottlerocket?
Bottlerocket is a new Linux-based open source OS that is purpose-built to run containers. With Bottlerocket, you can improve the availability of your containerized deployments and reduce operational costs by automating updates to your container infrastructure. Bottlerocket includes only the essential software to run containers, which improves resource usage, reduces security attack surface, and lowers management overhead. It also integrates with container orchestrators (such as Amazon EKS and Amazon ECS) to further reduce management and operational overhead while updating container hosts in a cluster.
What are the benefits of using Bottlerocket?
a) Higher uptime with lower operational cost and lower management complexity: By including only the components needed to run containers, Bottlerocket has a lower resource footprint, boot times, and security attack surface compared to general-purpose OSes. A smaller footprint helps reduce costs because of decreased usage of storage, compute, and networking resources. The use of container primitives (instead of package managers) to run software lowers management overhead.
b) Improved security from automatic OS updates: Updates to Bottlerocket are applied as a single unit which can be rolled back if necessary which removes the risk of “botched” updates that can leave the system in an unusable state. Update failures are common with general-purpose OSes because of unrecoverable failures during package-by-package updates. In Bottlerocket, security updates can be automatically applied as soon as they are available in a minimally disruptive manner and be rolled back if failures occur.
c) Open source and universal availability: An open development model enables customers, partners, and all interested parties to make code and design changes to Bottlerocket.
d) Premium Support: The use of AWS-provided builds of Bottlerocket on Amazon EC2 is covered under the same AWS support plans that also cover AWS services such as Amazon EC2, Amazon EKS, Amazon ECR, etc.
How is Bottlerocket different from Amazon Linux?
Amazon Linux is a general-purpose OS to run a wide range of applications that are packaged with the RPM Package Manager or containers. Amazon Linux is optimized to provide the ability to configure each instance as necessary for its workload using traditional tools such as yum, ssh, tcpdump, netconf, etc. Bottlerocket, on the other hand, is purpose-built for running containers and allows you to manage a large number of container hosts identically with automation. Specifically, Bottlerocket differs from Amazon Linux in the following ways:
- Bottlerocket does not have a package manager and software can only be run as containers. Updates to Bottlerocket are applied and can be rolled back in a single atomic step, which reduces update errors.
- The primary mechanism to manage Bottlerocket hosts is with a container orchestrator like Amazon EKS. Unlike Amazon Linux, logging into individual Bottlerocket instances is intended to be an infrequent operation for advanced debugging and troubleshooting.
Will the EKS and ECS optimized AMIs based on Amazon Linux 2 continue to be supported?
The current EKS-optimized AMIs that are based on Amazon Linux will be supported and continue to receive security updates. See EKS optimized Amazon Linux 2 AMI and ECS optmized AMI for details on support lifetimes.
What are the core components of Bottlerocket?
The primary components of Bottlerocket include:
- Minimal OS that includes the Linux kernel, system software, and containerd as the container runtime.
- Atomic update mechanism to apply and rollback OS updates in a single step.
- Integrations with container orchestrators such as Amazon EKS to manage and orchestrate updates.
- “Admin container” that can be optionally run for advanced troubleshooting and debugging.
How can I apply updates to Bottlerocket?
Bottlerocket updates are automatically downloaded from pre-configured AWS repositories when they become available. A reboot of Bottlerocket is needed to apply updates and can be either manually initiated or managed by the orchestrator such as Amazon EKS. You need to select the appropriate mechanism to handle reboots based on the tolerance of your applications to reboots and your operational needs. If your application is stateless and resilient to reboots, reboots can be performed immediately after updates are downloaded. If you are running stateful traditional workloads (e.g., databases, long-running line-of-business apps, etc.) in containers which not resilient to reboots, you will need to ensure that state is preserved before reboots.
Bottlerocket reboots can be managed by orchestrators such as Amazon EKS by draining and restarting containers across hosts to enable rolling updates in a cluster to reduce disruption. Updates to Bottlerocket can also be safely rolled back in case of failures occur via supported orchestrators or with manual action.
What are the steps to deploy and operate Bottlerocket using Kubernetes?
You can deploy and service Bottlerocket using the following steps:
Step 1: You can deploy Bottlerocket the same way as any other OS in a virtual machine. On AWS, you can deploy Bottlerocket to EC2 instances from the console, API, CLI. You need to provide configuration details via user data for each Bottlerocket instance to enroll into an Amazon EKS cluster.
Step 2: To operate Bottlerocket with your orchestrator, you will need to deploy an integration component to your cluster. The integration component enables the orchestrator to initiate reboots, rollback updates, and replace containers in a minimally disruptive manner for rolling upgrades.
See Bottlerocket documentation, for steps to deploy and use the “Bottlerocket update operator” on Amazon EKS clusters.
Can I use Bottlerocket without using a container orchestrator?
Yes, you can run Bottlerocket as a standalone OS without an orchestrator on your laptop or server for development and test use cases. You can use utilities in the “admin container” to administer and update Bottlerocket.
Which compute platforms and EC2 instance types does Bottlerocket support?
Bottlerocket builds from AWS are supported on an HVM and EC2 Bare Metal instance families with the exception of the P, G, F, and INF instance types. Bottlerocket needs at least 1vCPU and 512MB of RAM. Bottlerocket does not support PV instance types.
How can I get started with using Bottlerocket on AWS?
AWS provides an Amazon Machine Image (AMI) for Bottlerocket that you can use to run on supported EC2 instance types from the AWS console, CLI, and SDK. AWS will provide Bottlerocket builds that come pre-configured for use with EKS and ECS. You can use EKS to update and manage the OS with minimal disruptions without having to log-in to each OS instance. The Bottlerocket operator for Kubernetes enables you to perform OS management operations such as activities such as initiating reboots and rollback of updates with minimal disruptions.
How do I run software on Bottlerocket?
You can run your containerized applications including third-party ISV software on a running Bottlerocket instance using your container orchestrator. You can also use include your software and startup scripts into Bottlerocket during image customization. Refer to Bottlerocket documentation for details.
What is the pricing for Bottlerocket?
AWS-provided builds of Bottlerocket are available at no cost on all supported platforms. Standard Amazon EC2 apply for running Amazon EC2 instances.
Do you have a public roadmap?
How are Bottlerocket releases versioned?
AWS-provided builds of Bottlerocket builds follow a “major.minor.patch” semantic versioning scheme. Minor versions of Bottlerocket will be released multiple times in the year with changes such as support for new EC2 platforms, support for new orchestrator agents, and refreshes to open source components. The version scheme will indicate whether the updates contain breaking changes.
What kind of support does AWS provide for Bottlerocket?
AWS provided builds of Bottlerocket will receive security updates, bug fixes, and are covered under AWS support plans. The period of support for a given build will depend on the version of the container orchestrator being used. Bottlerocket builds will be deprecated when the corresponding orchestrator version is deprecated. For example, we no longer support aws-k8s-1.15, which is the Bottlerocket build for Kubernetes 1.15. This is in-line with Kubernetes 1.15 no longer receiving support upstream. We recommend customers replace aws-k8s-1.15 nodes with a more recent build as supported by your cluster.
In addition, community support for Bottlerocket is available on GitHub where you can post questions, feature requests, and report bugs. Details on releases and fixes to CVEs will be posted in the Bottlerocket changelog.
What kinds of updates are available for Bottlerocket?
AWS provides pre-tested updates for Bottlerocket that are applied in a single step. These updates can also be rolled back in a single step to a known good state. As a result, “botched” updates that can leave the system unusable because of inconsistent states that need manual repair do not occur with Bottlerocket. With single-step atomic updates, there is lower complexity, which reduces update failures.
How can I apply updates to Bottlerocket?
Updates to AWS-provided builds of Bottlerocket are automatically downloaded from pre-configured AWS repositories when they become available. A reboot of Bottlerocket is needed to apply updates and can be either manually initiated or managed by the orchestrator such as Amazon EKS. You need to select the appropriate mechanism to handle reboots based on the tolerance of your applications to reboots and your operational needs. If your application is stateless and resilient to reboots, reboots can be performed immediately after updates are downloaded. If you are running stateful traditional workloads (e.g., databases, long-running line-of-business apps, etc.) in containers which not resilient to reboots, you will need to ensure that state is preserved before reboots.
Bottlerocket reboots can be managed by orchestrators such as Amazon EKS that drain and restart containers across hosts to enable rolling updates in a cluster to reduce disruption. By default, Bottlerocket will auto-update to the latest secure version upon boot. Updates to Bottlerocket can also be safely rolled back in case of failures occur via supported orchestrators or with manual action.
How does Bottlerocket help ensure that updates are minimally disruptive?
The integrations with orchestrators such as Amazon EKS helps make updates to Bottlerocket minimally disruptive. During the update process, the orchestrator drains containers on hosts being updated and places them on other vacant hosts in the cluster. The orchestrator also rolls back to hosts to the previous version of Bottlerocket if updates fail.
Compatibility and migration
What container images can I run in containers on Bottlerocket?
Bottlerocket can run all container images that meet the OCI Image Format specification and Docker images.
Can I move my containers running on Amazon Linux 2 to Bottlerocket?
Yes, you can move your containers across Amazon Linux 2 and Bottlerocket without modifications.
When should I not use Bottlerocket?
If your operational workflows to run containers involves installing software on the host OS with yum, directly ssh-ing into instances, customizing each instance individually, or run third-party ISV software that is not containerized (e.g., agents for logging and monitoring), Amazon Linux 2 may be a better fit. Bottlerocket is optimized to run and manage large containerized deployments and does not easily allow many of these activities.
Troubleshooting and security
How do I debug issues with Bottlerocket?
You can run an “admin container” using Bottlerocket's API (invoked via user data or AWS Systems Manager) and then log in with SSH for advanced debugging and troubleshooting with elevated privilages. AWS provides the admin container that allows you to install and use debugging tools like sosreport, traceroute, strace, tcpdump. The act of logging into an individual Bottlerocket instance is intended to be an infrequent operation for advanced debugging and troubleshooting.
What is the admin container?
An admin container is an Amazon Linux contianer image contains utilities for troubleshooting and debugging Bottlerocket and runs with elevated privileges. The running of the tools container can be initiated via user data or Bottlerocket APIs.
What container isolation and security features does Bottlerocket provide?
Bottlerocket enables automatic security updates and reduces exposure to security attacks by including only the essential software to host containers. Bottlerocket uses containers control groups (cgroups) and kernel namespaces for isolation between containers. It also comes with Security-Enhanced Linux (SELinux) in enforcing mode and seccomp. eBPF in the kernel reduces the need for kernel modules for many low-level system operations by providing a low-overhead tracing framework for tracing I/O, file-system operations, CPU usage, intrusion detection, and troubleshooting. Bottlerocket uses with device-mapper-verity (dm-verity), a Linux kernel feature which provides integrity checking to help prevent rootkits that can hold onto root privileges.
Open source and trademarks
What is the Open Source License for Bottlerocket?
Bottlerocket code is licensed under Apache 2.0 OR MIT. Amazon wrote its Bottlerocket in Rust, so we’ve chosen a license that fits into that community easily. Underlying third party code, like the Linux kernel, remains subject to its original license.
How can I view and contribute source code changes to Bottlerocket?
Bottlerocket is released as an open source project hosted on GitHub. Design documents, code, build tools, tests, and documentation will be hosted on GitHub. We will use the GitHub’s bug and feature tracking systems for project management. You can view and contribute to Bottlerocket source code using standard GitHub workflows.
How can I produce custom builds of Bottlerocket that include my own changes?
You can fork the GitHub repository, make your changes and follow our building guide.
Can I create and redistribute my own builds of Bottlerocket?
Yes. If you build Bottlerocket from unmodified source and redistribute the results, you may use “Bottlerocket” only if it is clear in both the name of your distribution and the content associated with it that your distribution is your build of Amazon’s Bottlerocket and not the official build, and you must identify the commit from which it is built, including the commit date.
How can I use the Bottlerocket Trademarks to refer to my own version of Amazon’s Bottlerocket that I’ve adapted for a different container orchestrator?
If you modify Amazon’s Bottlerocket to work with a different container orchestrator, you may use “Bottlerocket Remix” to refer to your version in accordance with the policy guidelines. If you have the rights to use the trademarks of that container orchestrator in this manner, you may append the name of that container orchestrator to “Bottlerocket Remix”.
What OS changes do I need to make to a modified version of Bottlerocket to comply with this policy?
You must modify the os-release file to either use your “Bottlerocket Remix” name or to remove the Bottlerocket Trademarks. This can be done by modifying both packages/release/release.spec and tools/rpm2img. Names of the system root (/x86_64-bottlerocket-linux-gnu/sys-root), partition labels, directory paths, and service file descriptions do not need to be changed to comply with this policy.