Bottlerocket のよくある質問

AWS は、AWS コンソール、CLI、および SDK からサポートされている EC2 インスタンスタイプで実行するために使用できる Bottlerocket 用に Amazon マシンイメージ (AMI) を提供します。AWS は、ベアメタルの EKS、ECS、VMware、および EKS Anywhere で使用するために事前設定された Bottlerocket ビルドを提供します。オーケストレーターを使用すると、各 OS インスタンスにログインしなくても、中断を最小限に抑えながら OS を更新および管理できます。

オーケストレーターを通じて、Bottlerocket インスタンスでコンテナ化されたアプリケーションを起動できます。イメージのカスタマイズ中に、ソフトウェアと起動スクリプトを Bottlerocket に含めることもできます。詳細については、Bottlerocket のドキュメントをご覧ください。

次の手順を実行して、Bottlerocket をデプロイおよび保守できます。

• ステップ 1: 仮想マシンの他の OS と同じ方法で Bottlerocket をデプロイできます。AWS では、AWS マネジメントコンソールから、または API や AWS CLI を介して、Bottlerocket を EC2 インスタンスにデプロイできます。Amazon EKS クラスターに登録するには、各 Bottlerocket インスタンスのユーザーデータを介して設定の詳細を提供する必要があります。
• ステップ 2: オーケストレーターで Bottlerocket を運用するには、統合コンポーネントをクラスターにデプロイする必要があります。統合コンポーネントを使用すると、オーケストレーターは、ローリング更新の中断を最小限に抑えながら、再起動、更新のロールバック、およびコンテナの交換を開始できます。

Bottlerocket の更新は、利用可能になると、事前設定された AWS リポジトリから自動的にダウンロードされます。更新を適用するには Bottlerocket の再起動が必要であり、手動で開始するか、または Kubernetes などのオーケストレーターによって管理できます。再起動に対するアプリケーションの許容度と運用上のニーズに基づいて、再起動を処理するための適切なメカニズムを選択する必要があります。アプリケーションがステートレスで、かつ、再起動に対する回復力がある場合は、更新がダウンロードされた直後に再起動を実行できます。再起動に対する回復力のないコンテナでステートフルな従来のワークロード (データベース、長時間実行される基幹業務アプリケーションなど) を実行している場合は、再起動する前に確実にステートが保持されているようにする必要があります。

Bottlerocket の再起動は、オーケストレーターが、ホスト間でコンテナをドレインおよび再起動して、クラスター内のローリング更新を有効にし、中断を減らすことで管理できます。サポートされているオーケストレーターを介して、またはアクションの手動実行で、障害が発生した場合、Bottlerocket の更新を安全にロールバックすることもできます。Amazon EKS クラスターおよび Amazon ECS クラスターに「Bottlerocket update operator」をデプロイして使用するステップについては、Bottlerocket のドキュメントをご覧ください。

AWS が提供する Bottlerocket ビルドは、「major.minor.patch」セマンティックバージョニングスキームに従います。Bottlerocket のマイナーバージョンは、新しい EC2 プラットフォームのサポート、新しいオーケストレーターエージェントのサポート、オープンソースコンポーネントの更新などの変更を含み、年に複数回リリースされます。バージョンスキームは、更新に重大な変更が含まれているかどうかを示します。

バリアントは、さまざまな機能または統合特性をサポートする Bottlerocket のビルドです。AWS は、EC2、VMware、およびベアメタルで Kubernetes ワーカーノードをサポートする Bottlerocket バリアントを提供します。AWS は、EC2 の ECS 向けに Bottlerocket バリアントも提供しています。AWS が提供するすべてのバリアントのリストを表示できます。

はい。Bottlerocket には、Amazon Elastic Container Services (Amazon ECS) および EC2 の Kubernetes ワーカーノードで NVIDIA GPU ベースの Amazon EC2 インスタンスタイプをサポートするバリアントがあります。ECS および EKS でこれらのバリアントを使用する方法については、ブログ記事を確認してください。

Bottlerocket の機能リリース (マイナーバージョン、1.10.0、1.11.0など) は通常、6〜8 週間の間隔で行われます。バグや CVE の修正 (パッチバージョン、1.10.1、1.11.1) は必要に応じて行われ、リリースの頻度は問題の重大度によって異なります。Bottlerocket のすべてのリリースとそのタイムラインを示すCHANGELOGをご覧ください。

AWS が提供する Bottlerocket のビルドは、セキュリティアップデートとバグ修正を受け取り、AWS サポートプランの対象となります。特定のビルドのサポート期間は、使用されているコンテナオーケストレーターのバージョンによって異なります。対応するオーケストレーターのバージョンが非推奨になると、Bottlerocket ビルドは非推奨になります。例えば、Kubernetes 1.19 向けの Bottlerocket ビルドである aws-k8s-1.19 はサポートされなくなりました。これは、Kubernetes 1.19 がアップストリームでサポートを受けなくなったことを受けたものです。aws-k8s-1.19 ノードを、クラスターでサポートされている最新のビルドに置き換えることをお勧めします。さらに、Bottlerocket のコミュニティサポートは GitHub で利用でき、質問を投稿したり、機能をリクエストしたり、バグを報告したりできます。CVE のリリースと修正の詳細は、Bottlerocket の変更ログに掲載されます。

Amazon Linux に基づく現在の EKS 最適化 AMI は今後もサポートされ、引き続きセキュリティ更新プログラムを受信します。サポートの有効期間の詳細については、「EKS 最適化 Amazon Linux 2 AMI」および「ECS に最適化された AMI」をご覧ください。

AWS からの Bottlerocket ビルドは、F、G4ad、および INF インスタンスタイプを除いて、HVM および EC2 ベアメタルインスタンスファミリーでサポートされています。

はい。詳細については、こちらのブログ記事をご覧ください。

AWS は Bottlerocket のためにテスト済みの更新を提供します。これは単一のステップで適用されます。これらの更新は、単一のステップで既知の良好な状態にロールバックすることもできます。その結果、手動修復が必要な一貫性のない状態のためにシステムを使用できない状態にする可能性のある「失敗した」更新は、Bottlerocket では発生しません。単一のステップのアトミック更新を使用すると、複雑さが軽減され、更新の失敗が減少します。

AWS が提供する Bottlerocket のビルドの更新は、利用可能になると、事前設定された AWS リポジトリから自動的にダウンロードされます。更新を適用するには Bottlerocket の再起動が必要であり、手動で開始するか、または Kubernetes などのオーケストレーターによって管理できます。再起動に対するアプリケーションの許容度と運用上のニーズに基づいて、再起動を処理するための適切なメカニズムを選択する必要があります。アプリケーションがステートレスで、かつ、再起動に対する回復力がある場合は、更新がダウンロードされた直後に再起動を実行できます。再起動に対する回復力のないコンテナでステートフルな従来のワークロード (データベースまたは長時間実行される基幹業務アプリケーションなど) を実行している場合は、再起動する前に確実にステートが保持されているようにする必要があります。

Bottlerocket の再起動は、ホスト間でコンテナをドレインおよび再起動して、クラスター内のローリング更新を有効にし、中断を減らす Kubernetes などのオーケストレーターによって管理できます。デフォルトでは、Bottlerocket は起動時に最新の安全なバージョンに自動更新します。サポートされているオーケストレーターを介して、またはアクションの手動実行で、障害が発生した場合、Bottlerocket の更新を安全にロールバックすることもできます。

Kubernetes などのオーケストレーターとの統合は、Bottlerocket の更新の中断を最小限に抑えるのに役立ちます。更新プロセス中に、オーケストレーターは更新中のホスト上のコンテナをドレインし、クラスター内の他の空のホストに配置します。更新が失敗した場合、オーケストレーターはホストにロールバックして、以前のバージョンの Bottlerocket にロールバックします。

Bottlerocket は、OCI Image Format 仕様と Docker イメージを満たすすべてのコンテナイメージを実行できます。

はい。変更することなく、Amazon Linux 2 と Bottlerocket 間でコンテナを移動できます。

コンテナを実行する運用ワークフローに、yum を使用したホスト OS でのソフトウェアのインストール、インスタンスへの直接 SSH 接続、各インスタンスの個別カスタマイズ、またはコンテナ化されていないサードパーティーの ISV ソフトウェア (ログ記録やモニタリング用のエージェントなど) の実行が含まれる場合、Amazon Linux 2 の方が適している可能性があります。Bottlerocket は、大規模なコンテナ化されたデプロイを実行および管理するために最適化されており、これらのアクティビティの多くを簡単には許可しません。

Bottlerocket の API (ユーザーデータまたは AWS Systems Manager を介して呼び出されます) を使用して「管理コンテナ」を実行し、SSH でログインして、昇格された特権で高度なデバッグとトラブルシューティングを行うことができます。AWS は、sosreport、traceroute、strace、tcpdump などのデバッグツールをインストールおよび使用できるようにする管理コンテナを提供します。個々の Bottlerocket インスタンスにログインするという行為は、高度なデバッグとトラブルシューティングのための低頻度のオペレーションであることが想定されています。

管理コンテナは Amazon Linux コンテナイメージであり、Bottlerocket のトラブルシューティングとデバッグのためのユーティリティが含まれており、昇格された権限で実行されます。管理コンテナの使用方法の詳細をご覧ください。

Bottlerocket は、コンテナをホストするために不可欠なソフトウェアのみを含めることにより、自動セキュリティ更新を可能にし、セキュリティ攻撃への露出を減らします。Bottlerocket は、コンテナ間の分離のために、コンテナ制御グループ (cgroups) とカーネル名前空間を使用します。また、施行モードの Security-Enhanced Linux (SELinux) と seccomp が付属しています。カーネル内の eBPF は、I/O、ファイルシステムオペレーション、CPU 使用率、侵入検知、およびトラブルシューティングをトレースするための低オーバーヘッドのトレースフレームワークを提供することにより、多くの低レベルシステムオペレーションのためのカーネルモジュールの必要性を減らします。Bottlerocket は、device-mapper-verity (dm-verity) を使用します。これは、ルート特権を保持できるルートキットを防ぐのに役立つ整合性チェックを提供する Linux カーネル機能です。

Bottlerocket ノードからログを収集するには、複数のオプションがあります。例えば、CloudWatch Container Insights または Fluent Bit with OpenSearch を使用できます。

はい、Bottlerocket には CIS Benchmark があります。CIS Benchmark は Bottlerocket ユーザーがシンプルで効率的な方法で設定したり、あらゆるコンプライアンス違反を記録したりするのに役立つセキュリティ重視の構成設定のカタログです。Bottlerocket の CIS Benchmark には、レベル 1 とレベル 2 の両方の設定プロファイルが含まれており、CIS ウェブサイトからアクセスできます。

いいえ、Bottlerocket はまだ FIPS 認定を受けていません。Bottlerocket の FIPS 認定はロードマップにありますが、現時点では、いつ利用可能になるかはわかりません。

はい、Bottlerocket を使用して PCI コンプライアンスを達成できます。機能セットが最適化され、攻撃対象領域が縮小されることは、Bottlerocket インスタンスで PCI DSS 要件を満たすために必要な設定が少なくなることを意味します。Bottlerocket の CIS Benchmark は、ガイダンスを強化するための優れたリソースであり、PCI DSS 要件 2.2 に基づく安全な設定基準のためのお客様の要件をサポートします。お客様は、Fluent Bit を活用して、PCI DSS 要件 10.2 に基づくオペレーティングシステムレベルの監査ログ記録に関するお客様の要件をサポートすることもできます。AWS は、お客様が PCI DSS 要件 6.2 (v3.2.1 の場合) および要件 6.3.3 (v4.0 の場合) を満たすのをサポートするために、新しい (パッチが適用された) Bottlerocket インスタンスを定期的に発行します。

はい。Bottlerocket は、Amazon EC2 および Amazon EKS の両方で、規制対象のワークロードでの使用が許可された HIPAA 適格機能です。Amazon EKS に関する設定ガイダンスの追加情報については、このホワイトペーパーをご覧ください。

Amazon EKS で使用する場合の Bottlerocket の強化と検証に関するガイドをご覧ください。

はい。Amazon Inspector は、EC2 とコンテナのワークロードをスキャンして、ソフトウェアの脆弱性や意図しないネットワークの露出がないかを探す脆弱性管理サービスです。Amazon Inspector は、AWS System Manager (SSM) エージェントを利用して脆弱性をスキャンします。Bottlerocket ホストにおいて、SSM エージェントはコントロールホストコンテナ内で実行されるため、ホストで確実に有効にする必要があります。

Bottlerocket コードは、Apache 2.0 または MIT でライセンスされています。Amazon は Rust で Bottlerocket を作成したため、そのコミュニティに簡単に適合するライセンスを選択しました。Linux カーネルなどの基盤となるサードパーティーのコードは、引き続き元のライセンスの対象となります。

Bottlerocket は、GitHub でホストされているオープンソースプロジェクトとしてリリースされています。設計ドキュメント、コード、ビルドツール、テスト、およびドキュメントは GitHub でホストされます。プロジェクト管理には、GitHub のバグと機能の追跡システムを使用します。標準の GitHub ワークフローを使用して、Bottlerocket のソースコードを表示および貢献できます。

GitHub リポジトリをフォークし、変更を加えて、構築ガイドに従うことができます。

はい。変更されていないソースから Bottlerocket を構築してその結果を再配布する場合、ディストリビューションの名前とそれに関連付けられたコンテンツの両方で、ディストリビューションがお客様の Amazon の Bottlerocket のビルドであり、公式ビルドではないことが明らかな場合にのみ、「Bottlerocket」を使用でき、コミット日を含めて、ビルド元のコミットを明示する必要があります。

本ポリシーに従って Bottlerocket を使用するか、Bottlerocket の商標を削除するように os-release ファイルを変更する必要があります。これは、packages/release/release.spec と tools/rpm2img の両方を変更することで実行できます。このポリシーに準拠するために、システムルートの名前 (/x86_64-bottlerocket-linux-gnu/sys-root)、パーティションラベル、ディレクトリパス、およびサービスファイルの説明を変更する必要はありません。

Bottlerocket 商標の紛らわしい、誤解を招く使用、またはその他の誤用を発見した場合は、さらに調査できるよう、上記の通り trademarks@amazon.com までご連絡ください。