Bottlerocket、1 年間のあゆみ

この記事は Bottlerocket, A Year in the Life を翻訳したものです。

先日、Amazon Elastic Kubernetes Service (Amazon EKS) がマネージド型ノードグループでの Bottlerocket のサポートを開始したことを受け、この機会に Bottlerocket とその機能について改めてお話したいと思います。私は以前、商用の UNIX OS に携わる多くのエンジニアの一人でした。その数年前、Linux が有力な選択肢として確立され、その後の市場においてかなりの部分を占めるようになりました。お客様が徐々に Linux に移行していく中、「OS はまだ重要ですか？」という質問を聞くようになりました。私たちの答えはいつも「Yes」でした。私たちは情熱的にそう信じていましたし、今でもそう思っています。

今日、私たちはアプリケーションの新しいプロセスモデルとしてコンテナを採用し、コンテナを管理、実行を抽象化したオーケストレーションに依存しています。開発者がオペレーティングシステムの深い階層にこだわる必要はないと言ってもいいでしょう。コンテナのオーケストレーションレイヤーが新しいオペレーティングシステムになったと言えるかもしれません (まあ、本当はそうではありませんが)。Kubernetes のようなオーケストレーションソリューションは、一般的な構成ではノードにワークロードをスケジューリングします。これらノードはオペレーティングシステムを実行するコンピュータです。同じコンピュートモデルで、抽象化された別のレイヤーに過ぎません。

AWS では、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) のコンピュートリソースに AWS Fargate を使用することで、ノードを意識せずに済むという選択肢があります。これは基盤側を気にせず、先に進むための圧倒的に早い方法です。しかし、独立した静的なコンピュートリソースを必要とする場合もあるでしょう。その場合、誰かがノードと実行するソフトウェアを気にかける必要があります。

このような状況では「私達はまだ OS のことを気にする必要がありますか？」という別の質問があるかと思います。それに対して私達は「No」と言いたいです。

Bottlerocket とは何か？

Bottlerocket は、コンテナをホスティングするために特別に設計された、フリーでオープンソースの Linux ベースのオペレーティングシステムです。一般的な Linux ディストリビューションでもコンテナを動作させることは可能ですが、これらはあらゆる種類のワークロードに一般的に使用できるように設計されています。つまり、より多くの種類のワークロードに対応し、サポートするための可動部品が増え、様々な設定に対応可能なデフォルトのセキュリティ体制を備えています。

Bottlerocket は主な役割として、コンテナのホスティングにフォーカスし、特化することに注力しています。その目標に向けて非常に堅牢な設計となっています。プロジェクト憲章には、Amazon で大規模な本番サービスを何年にもわたって運営してきた経験から得た教訓に基づく、明確な方針が定められています。Bottlerocket には、コンテナを安全かつ確実に実行するために必要なソフトウェアコンポーネントしか含まれていません。ホスト上で稼働する部品やプロセスが少ないため、一般的な汎用ホストオペレーティングシステムに比べて管理の手間が省け、攻撃対象も小さくなります。

セキュリティとメンテナンス性は、Bottlerocket の第一級の設計原則です。Bottlerocket は読み取り専用のルートファイルシステムに配置されており、ホストの設定変更をしたとしても一時的なものです。設定の変更は、シェルとスーパーユーザー権限でリモートからログインするのではなく、コントロールコンテナを介して行うか、API を介して実行する理想的な変更が行えます。Bottlerocket のセキュリティ面についてもう少し詳しく知りたい方は、最近の記事をご覧ください。

Bottlerocket のアップデートは、従来のモジュラーパッケージベースのアプローチではなく、事前に準備した新しいパーティションに一括で切り替えることで、高速かつ弾力性のあるものとなっています。Amazon ECS、Amazon EKS、Amazon EKS Anywhere、またはセルフマネージドの Kubernetes クラスターのノードのホスト OS として使用する場合は、アップデート作業を自動化するオプションもあります。これらのすべての側面は、コンテナワークロードのホスト OS をより安全で管理しやすくし、結果として OS についての心配事が少なくなります (全く無くなるというわけではありません)。

これらの機能はすべて、オペレーティングシステムの設計に対してのクラウドネイティブなアプローチを反映しています。Bottlerocket は、昨年 (2020 年) の夏に v1.0.0 で正式にローンチしました。この記事では、この 1 年で OS に導入された主な機能と、プロジェクトの変更点を紹介したいと思います。また、AWS パートナーが提供するソリューションについてもご紹介します。

1 年間の歩み

1 年以上前にバージョン 1.0 が発表されて以来、Bottlerocket プロジェクトでは多くの変更が行われてきました。大規模な機能から、小さくてもインパクトのあるユーザビリティの改善、便利で精選されたバリアントまで、全体的に、Bottlerocket OS は便利なカスタマイズと拡張機能を備え、作業と管理がより簡単になりました。また、このプロジェクトにはコミュニティが形成され、多くの AWS パートナーがこの Bottlerocket OS を利用したソリューションを開発しています。

多くのプロジェクトと同様に、リリースノートは各バージョンにどのような具体的な変更が加えられたかを知るための参考資料となります。

Bottlerocket のバージョンとバリアント

具体的な Bottlerocket の機能をご紹介する前に、バージョンとバリアントの仕組みについてご説明します。Bottlerocket の目標は、必要なものだけをインストールして実行することで、可能な限り小さなフットプリントでオペレーティングシステムを展開することです。ここで Amazon ECS と Amazon EKS について考えてみましょう。クラスターノードはわずかに異なるソフトウェアを必要とします。

ホストイメージに両方のオーケストレーションオプションをサポートするコンポーネントを含めることもできますが、それでは Bottlerocket の設計目標に反することになります。そのため、Bottlerocket ではバリアントを使用して、必要なコンポーネントのみを含む各環境専用の精選されたイメージを提供しています。この設計により、将来的にはさまざまなクラウド環境やコンテナオーケストレーターのサポートが可能になります。

Amazon ECS とバージョニングされた Kubernetes のリリースには、それぞれバリアントが存在します。Kubernetes のバリアントは特定のバージョンの Kubernetes をサポートするように構築されています。これらのバリアントは、Amazon EKS のワーカーノード、EKS Anywhere、またはセルフマネージド型 Kubernetes クラスターで使用できます。最近、VMware をサポートするバリアントがプレビュー版としてリリースされました。このバリアントには、Kubernetes のワーカーノードを VMware ゲストとして実行するために必要なパッケージが含まれています (EKS Anywhere でもサポートされています)。

Bottlerocket OS 自体にもバージョンがあります。これは、ある時点でのプロジェクトの要素が特定のイメージに組み込まれていることを示すものです。Bottlerocket OS は、特定のバリアント (基本的にはコンテンツのリストです) と特定のアーキテクチャ用に、特定のバージョンで構築されます。これらの様々な属性は、例えば bottlerocket-aws-k8s-1.21-x86_64-1.2.0-dafe3b16.img のように、インストール可能なイメージの特徴を定義します。

OS のアップデート

Bottlerocket のアップデートは、イメージベースのアトミックな操作です。アップデートが開始されると、システムが正常に動作している裏で、最新の Bottlerocket イメージが TUF リポジトリからホスト上の非アクティブなパーティションにダウンロードされます。ダウンロードが完了すると、システム (特に Signpost ユーティリティ) はアップデート用のパーティションをアクティブにし、以前のアクティブなパーティションを非アクティブにします。

その後、システムを再起動して新しいバージョンに移行します。ブートプロセス中に障害が発生した場合は、アクティブと非アクティブのパーティションを交換して再起動することで、システムを簡単に前のバージョンにロールバックすることができます。このようなイメージベースのアプローチは、十分に検証されたメカニズムであり、OS のアップデートをより信頼性の高いものにしています。

API の観点から見ると、アップデートのプロセスは次のようになります。

上記のアクションを実行する低レベルの API コマンドが存在しますが、Bottlerocket の apiclient はアップデートのワークフローを理解し、これらの呼び出しを自動化します。

以下の apiclient コマンドを使用して、OS をアップグレードすることができます。

apiclient update check: インストールされているバリアントに新しいバージョンがあるかどうかを確認します。
apiclient update apply: 更新プログラムをダウンロードし、ステージされていることを確認します。
apiclient reboot: アップデートを有効にして、システムを再起動します。

これらのコマンドを組み合わせて SSM ドキュメントを作成し、ノードに対して実行することができます。また、Kubernetes の Bottlerocket Update Operator や Amazon ECS の Bottlerocket ECS Updater を使ってアップデート作業の自動化をすることもできます(訳注: Bottlerocket ECS Updater に Deep Diveする)。Update Operator の両バージョンは、ワークロードを安全に排出し、クラスター内のノードを 1 つずつ更新して運用上の影響を最小限に抑えます。

AWS Auth と TLS の併用

Kubernetes において、kubelet は Kubernetes API と通信を行うノードエージェントです。この通信チャンネルは、プライベートで信頼性が高く、干渉を受けないものでなければなりません。これは TLS を使うことで実現されますが、これには問題があります。TLS クライアント証明書をどうやってワーカーノードに取得させるのでしょうか？Kubernetes は証明書の署名 API を提供しており、kubelet はこれを使ってクラスターのコントロールプレーンに証明書を要求します。Amazon EKS において、Bottlerocket は aws-iam-authenticator を使用して API サーバーを認証するためのトークンを生成し、CSR を署名 API に提出します。リクエストが認証されると、署名 API は自動的にリクエストを承認し、ノードがクラスターへの参加に使用する証明書を返します。その後、ノードは TLS を使用して API と通信します。

しかし、Bottlerocket をセルフマネージド型の Kubernetes クラスターや、IAM 認証が選択できない AWS 外のクラスター (セルフマネージド型、または EKS Anywhere を使用）で使用したい場合もあるでしょう。このような状況では、Bottlerocket API を使用して、settings.kubernetes.authentication-mode を aws から tls に変更することができます。これにより Bottlerocket は、AWS 認証の代わりにブートストラップトークンを使用するようになります。

この変更を行う際には、settings.kubernetes.bootstrap-token 変数に値を指定する必要があることに注意してください。ブートストラップトークンについてはこちらをご覧ください。

HTTPS proxy 設定

一部の環境では、ウェブトラフィックをプロキシ経由でルーティングする必要があります。Bottlerocket を使えば、updog (TUF のクライアント)、metricdog (ホストのヘルス情報を送信)、Docker、containerd、Amazon ECS エージェント、kubelet など、サーバー上で実行されるさまざまなサービスに対して、ネットワークプロキシを設定することが可能です。

プロキシを設定するには、settings.network.http-proxy にプロキシサーバーの URL とポートを指定するだけです (例: http://192.168.1.192:3128 )。また、settings.network.no-proxy の設定を使用して、プロキシの対象からホストのリストを除外することもできます。Kubernetes バリアントでは、API サーバーや他の Kubernetes サフィックスを自動的に no-proxy リストに追加します (例: クラスタードメイン)。

カスタム CA 証明書

Bottlerocket には、デフォルトで Mozilla CA の証明書ストアが搭載されていますが、独自のものをインストールすることもできます。これにより証明書のバンドルを管理し、OS API のコンテキスト内でその信頼状態を管理することができます。

以下の API 設定は、Bottlerocket で自己署名証明書を追加するためのものです。

settings.pki.<bundle-name>.data: 1 つまたは複数の証明書を、Base64 エンコードされた PEM フォーマットのバンドルとして含めます。
settings.pki.<bundle-name>.trusted: バンドル内の証明書を信頼するかどうかを示す Boolean 値で、デフォルトは false です。

この設定は、API コールで直接渡すことも、ユーザーデータに追加することもできます。例えば、ユーザーデータに以下のように設定します。

[settings.pki.my-trusted-bundle]
data="-----BEGIN.."
trusted=true
[settings.pki.untrusted-bundle]
data="-----BEGIN.."
trusted=false

もしくは、API クライアント経由で実行する場合は以下のようになります。

apiclient set \
  pki.my-trusted-bundle.data="-----BEGIN" \
  pki.my-trusted-bundle.trusted=true \
  pki.dont-trust-these.data="-----BEGIN" \
  pki.untrusted-bundle.trusted=false

ブートストラップコンテナ

ブートストラップコンテナでは、システムの起動時にタスクを処理するコンテナを実行することができます。ブートストラップコンテナは、コントロールコンテナや管理コンテナのように継続的に稼働するものではありません。ブートストラップコンテナは、他のサービスが開始される前にホストを “bootstrap” するために使用できるコンテナで、Bottlerocket のコンテナベースのカスタマイズ設計によって、ノードの設定変更を行います。

ブートストラップコンテナを設定する際には、以下を指定します。

使用したいコンテナイメージ
コンテナがいつ実行されるかの設定 (off, once, or always)
コンテナが “essential “であるかどうか。例えば、ブートストラップコンテナが失敗した場合、ブートストラッププロセスを停止します
(オプション) ブートストラップコンテナに設定データを提供するユーザーデータ

ブートストラップコンテナは、Docker、Amazon ECS エージェント、kubelet のようなサービスが開始される前に実行され、systemd の configured.target ユニットがアクティブになった後に実行されます。複数のブートストラップコンテナを設定することができますが、実行される順序はコントロールできません。

ブートストラップコンテナは、さまざまな目的で使用できます。例えば、エフェメラルストレージのパーティション作成やフォーマット、実行可能な Pod の最大数の計算や設定、Kubernetes の追加ラベルの設定などに使用できます。可能性が広がりますね！

ホストコンテナとは異なり、ブートストラップコンテナは superpowered コンテナとして実行することはできません。しかし、Linux の CAP_SYS_ADMIN 機能で動作し、ホスト上で表示されるファイル、ディレクトリ、マウントを作成することができます。

これを具体的に説明するために、エフェメラルディスクのパーティション作成とフォーマットを行うブートストラップコンテナを作成する方法を見てみましょう。

まず、ブートストラップコンテナのコンテナイメージ用の Dockerfile です。

FROM alpine
RUN apk add e2fsprogs bash parted
ADD setup-ephemeral-disks ./
RUN chmod +x ./setup-ephemeral-disks
ENTRYPOINT ["sh", "setup-ephemeral-disks"]

setup-ephemeral-disks は、以下の内容を含むスクリプトです。

#!/usr/bin/env bash
set -ex

# 管理したいディスクの名前
DISK=/.bottlerocket/rootfs/dev/nvme2n1
# すでにディスクにパーティションが作成され、フォーマットされているかどうかを確認するためのファイル
PARTITIONS_CREATED=/.bottlerocket/bootstrap-containers/current/created
# このマウントポイントからのマウントは、マウントの名前空間を越えて伝播します
BASE_MOUNT_POINT=/.bottlerocket/rootfs/mnt

# ディスクがパーティション化されていない場合は、パーティションを作成してフォーマットします
if [ ! -f $PARTITIONS_CREATED ]; then
parted -s $DISK mklabel gpt 1>/dev/null
parted -s $DISK mkpart primary ext4 0% 50% 1>/dev/null
parted -s $DISK mkpart primary ext4 50% 100% 1>/dev/null
mkfs.ext4 -F ${DISK}p1
mkfs.ext4 -F ${DISK}p2
# ディスクの分割・フォーマット後にファイルを作成します
touch $PARTITIONS_CREATED
fi

# ターゲットとなるマウントポイントが存在することを確認します
mkdir -p $BASE_MOUNT_POINT/part1
mkdir -p $BASE_MOUNT_POINT/part2

# パーティションを常にマウントさせる
mount ${DISK}p1 $BASE_MOUNT_POINT/part1
mount ${DISK}p2 $BASE_MOUNT_POINT/part2

このコンテナイメージが構築され、レジストリにプッシュされた状態で、Bottlerocket API を介して apiclient set コマンドを使用し、コンテナイメージを指定してブートストラップコンテナを設定することができます。

apiclient set \
  bootstrap-containers.bootstrap.source=<your image's URI> \
  bootstrap-containers.bootstrap.mode=always \
  bootstrap-containers.bootstrap.essential=false

ブートストラップコンテナは、eksctl create nodegroup コマンドでノードグループを作成する際にも指定できます。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: <cluster_name>
  region: <aws_region>

nodeGroups:
  - name: <group_name>
    instanceType: m5ad.4xlarge
    desiredCapacity: 1
    amiFamily: Bottlerocket
    privateNetworking: true
    bottlerocket:
      enableAdminContainer: true
      settings:
        motd: "Bottlerocket rocks!"
        bootstrap-containers: 
          bootstrap: 
            source: "<image_uri>"
            mode: "always"
            essential: false
    ssh:
      # SSH アクセスの有効化 (管理コンテナ経由)
      allow: true
      publicKeyName: <key_name>

ブートストラップコンテナが機能したことを確認するために、コントロールコンテナに接続して lsblk を実行します。インスタンスには、nvme2n1 と nvme3n1 という 2 つの新しいデバイスがあります。nvme2n1 が part1 と part2 の 2 つのパーティションに分割されていることがわかります。

[ec2-user@ip-192-168-156-26 ~]$ lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0          7:0    0   280K  1 loop /.bottlerocket/rootfs/x86_64-bottlerocket
loop1          7:1    0  11.6M  1 loop /.bottlerocket/rootfs/var/lib/kernel-deve
nvme0n1      259:0    0     2G  0 disk
├─nvme0n1p1  259:3    0     4M  0 part
├─nvme0n1p2  259:4    0    40M  0 part /.bottlerocket/rootfs/boot
├─nvme0n1p3  259:5    0   920M  0 part
├─nvme0n1p4  259:6    0    10M  0 part
├─nvme0n1p5  259:7    0    30M  0 part
├─nvme0n1p6  259:8    0    40M  0 part
├─nvme0n1p7  259:9    0   920M  0 part
├─nvme0n1p8  259:10   0    10M  0 part
├─nvme0n1p9  259:11   0    30M  0 part
└─nvme0n1p10 259:12   0    42M  0 part /.bottlerocket/rootfs/var/lib/bottlerocke
nvme2n1      259:1    0 279.4G  0 disk
├─nvme2n1p1  259:15   0 139.7G  0 part /.bottlerocket/rootfs/mnt/part1
└─nvme2n1p2  259:16   0 139.7G  0 part /.bottlerocket/rootfs/mnt/part2
nvme1n1      259:2    0    80G  0 disk
└─nvme1n1p1  259:14   0    80G  0 part /.bottlerocket/rootfs/local
nvme3n1      259:13   0 279.4G  0 disk

Static Pod

Static Pod は、クラスターノード上で Kubernetes API 管理外の Pod を実行する方法です。ノード上で Static Pod を実行すると、kubelet は Pod の健全性を監視する責任を負い、失敗した場合は Pod を再起動します。また kubelet は、各 Static Pod に対して API サーバー上に “shadow” Pod を作成しようとします。これにより、Static Pod は API サーバーから見えるようになりますが、API を通して管理することはできません。

通常、Static Pod は、kubelet に渡される --pod-manifest-path フラグで指定されたディレクトリに Pod マニフェストをコピーすることで作成されます。また、Web サーバーから取得するオプションもあります。Bottlerocket API では、Pod マニフェストのパスを構成できるだけでなく、次の例のようにマニフェストを渡すこともできます。

[settings.kubernetes.static-pods.my-pod]
manifest = "<BASE64 encoded pod manifest>"
enabled = true

kmod-kit

Bottlerocket はこの機能により、イメージに out-of-tree のカーネルモジュールを構築することができます。ここでポイントとなるところはブートストラップイメージと同様、ノードにログインしてソフトウェアをインストールすることなく、カスタマイズのユースケースを解決することです。kmod-kit を利用して、イメージにカーネルモジュールを構築することができます。

Bottlerocket の out-of-tree のカーネルモジュールをビルドするには、使用しているバリアントの kmod キットを使用します。以下は、この機能を使って Falco ドライバーをビルドし、それをロードするスクリプトを作成した例です。

まず、Dockerfile で falco をマルチステージビルドし、デプロイ可能なイメージにバンドルします。

FROM rust AS tuftool
RUN cargo install tuftool
FROM fedora:33 AS builder
WORKDIR /tmp
COPY --from=tuftool /usr/local/cargo/bin/tuftool /usr/local/bin/tuftool
# Install dependencies and download sources
RUN \ulimit -n 1024; dnf -y install \bc bzip2 cmake3 curl diffutils dwarves elfutils-devel \
  findutils gcc gcc-c++ git kmod make tar ncurses-devel \
  patch xz && \git clone https://github.com/falcosecurity/falco.git
# Download root.json to fetch artifacts from tuf repo
RUN curl -O "https://cache.bottlerocket.aws/root.json" && \echo "90393204232a1ad6b0a45528b1f7df1a3e37493b1e05b1c149f081849a292c8dafb4ea5f7ee17bcc664e35f66e37e4cfa4aae9de7a2a28aa31ae6ac3d9bea4d5  root.json" | sha512sum -c
FROM builder AS driver
ARG VARIANT="<VARIANT>"
ARG ARCH="<ARCH>"
ARG VERSION="<VERSION>"
ARG KIT="${VARIANT}-${ARCH}-kmod-kit-v${VERSION}"
ARG KERNELDIR="/tmp/${KIT}/kernel-devel"
ARG CROSS_COMPILE="${ARCH}-bottlerocket-linux-musl-"
ARG INSTALL_MOD_STRIP=1
RUN tuftool download . --root ./root.json \
      --target-name $KIT.tar.xz \
      --metadata-url "https://updates.bottlerocket.aws/2020-07-07/$VARIANT/$ARCH/" \
      --targets-url "https://updates.bottlerocket.aws/targets/"
RUN tar xf ${KIT}.tar.xz
RUN \export PATH="/tmp/${KIT}/toolchain/usr/bin:${PATH}" && \mkdir -p falco/build && \cd falco/build && \
  cmake3 -DUSE_BUNDLED_DEPS=ON .. && \make driver -j# Validate the kernel module was compiledRUN test -f /tmp/falco/build/driver/falco.ko
ADD ./load-driver /usr/bin/load-driver
ENTRYPOINT ["load-driver"]

以下は、load-driver のスクリプトです。

#! /bin/bash -x

insmod /tmp/falco/build/driver/falco.ko
sleep infinity &
trap "echo 'Caught signal'; { kill $!; exit 0; }" HUP INT QUIT PIPE TERM
trap - EXIT
while true; do wait $! || continue; done
exit 0

コンテナイメージがビルドされ、レジストリにプッシュされると、Kubernetes クラスターにデプロイすることができます。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: falco
spec:
  serviceName: falco
  replicas: 1
  selector:
    matchLabels:
      app: falco
  template:
    metadata:
      labels:
        app: falco
    spec:
      containers:
        - name: falco
          image: <image>
          securityContext:
            privileged: true

コンテナが実行されると、falco モジュールが存在し、ロードされていることがわかります。

[I] ~/P/b/k/falco> kubectl exec falco-0 -- lsmod | grep falco
falco                 647168  0

コンテナからカーネルモジュールをロードするには、Bottlerocket API で kernel.lockdown が none に設定されていることを確認する必要があることに注意してください。

out-of-tree カーネルモジュールの構築についての詳細は、Building out-of-tree kernel modules を参照してください。

AWS パートナーのソリューション

お客様のワークロードで Bottlerocket を活用していただく上で、AWS パートナーのサポートは重要な役割を担っています。AWS は、お客様の課題から逆算して、共通の要件を満たすソリューションを見出すことに注力してきました。これには、モニタリングとロギング、管理と DevOps、セキュリティにまたがるソリューションが含まれます。お客様が現在使用しているツールと同じような活用方法で、Bottlerocket のノードを一貫した体験で管理できるようにしたいと考えています。

昨年に引き続き、Bottlerocket の AWS パートナーサポートが拡大しています。これには以下のソリューションのサポートが含まれます。

Crowdstrike 社は、同社の Falcon platform が認定されました。Falcon により、お客様は Bottlerocket ベースのホストでエンドポイント管理ソリューションを活用することができます。
PaloAlto 社は、同社の Prisma Cloud ソリューションが認定されました。Prisma Cloud により、お客様は Bottlerocket ベースのホスト上で実行されているコンテナワークロードの監視と保護、および Bottlerocket ホストの監視とファイアウォールを行うことができます。
Codefresh 社は、同社の Codefresh Runners ソリューションが認定されました。Codefresh Runners は、Bottlerocket ノードを使用してビルド環境を迅速かつ安全に拡張する機能を提供します。
Granulate 社は、Granulate Agent ソリューションが認定されました。Granulate は、Bottlerocket OS 上で稼働するコンテナ環境を最適化することで、パフォーマンスの向上とコストの削減を実現します。
JFrog 社は、同社の JFrog Platform が認定されました。JFrog は Bottlerocket ベースのホスト上で動作します。
NetApp 社は、同社の Spot Ocean ソリューションが認定されました。Spot Ocean では、Bottlerocket OS を実行しているインスタンス上で Spot コントローラを起動、管理、実行することができ、Spot Ocean のコスト最適化機能も利用できます。

Bottlerocket の次の展望は？

Bottlerocket プロジェクトは継続しており、今後数ヶ月で新たな機能や統合が予定されています。プロジェクトリポジトリでフォローしたり、AWS Containers Roadmap で issue や新機能について議論したりすることができます。最近リリースされたのは、Amazon EKS マネージド型ノードグループにおける Bottlerocket のネイティブサポートです。GPU のサポートと AWS GovCloud (US) Regions での利用は近日中に開始される予定です。

Bottlerocket をすぐに使用したい方は、公開されている Amazon ECS や Amazon EKS 用の AMI を使用したクイックスタートガイドをチェックしてください。VMware 環境であれば、Kubernetes 用に公開された OVA を使用するガイドをチェックしてください。ビルドのカスタマイズ機能の一部を確認したい場合は、独自の AMI を構築することもできます。

今回のクイックツアーでは、Bottlerocket を利用することで、クラスターノードで稼働しているオペレーティングシステムでの心配事が軽減されることを実感していただけるよう、十分なコンテキストとユースケースをご紹介しました。アイデア、ご要望、issue があれば、プロジェクトとそのロードマップ、またはコンテナのロードマップのリポジトリをご覧ください。

翻訳はソリューションアーキテクト加治が担当しました。原文はこちらです。

Amazon Web Services ブログ