[レポート] AWS のためのコンテナをビルドする #CON325 #reinvent

AWS re:Invent 2022

川崎照夫

2022.12.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

アノテーションテクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

AWS にコンテナをデプロイする際には、多くの選択肢があります。 AWS Lambda、Amazon ECS、または Amazon EKS を使用した Kubernetes のいずれでビルドする場合でも、プロセスはイメージのビルドから始まります。このセッションでは、コンテナを使用したビルドに関するガイダンスを 2 つの部分に分けます。まず、開発ツールの一般的な選択肢をいくつか見て、完全にオープンソースの開発環境を開始する最も簡単な方法を見つけてください。次に、開発パターンについて学び、AWS でのコンテナ開発に関する実践的なアドバイスを聞きます。

セッション動画

アジェンダ

コンテナとイメージ
オープンソースのコンテナ開発ツール
イメージのビルド、および配布とデプロイの計画

コンテナとイメージ

AWS 上のコンテナ

コンピューティングパラダイムとしてのコンテナ

大規模なマルチクラスター資産のオーケストレーションから、1 回限りの Web アプリケーションまで
多くのユースケースでの他の AWS サービスとの統合
ソフトウェアのライフサイクル全体を通して再現可能で一貫性があります

パッケージおよび流通用のコンテナ

バージョン管理された不変のアーティファクトに基づくすべてのインスタンス
すべてのコンポーネントと依存関係はビルド時に定義され、証明可能です
レジストリは基盤であり、両方がビルドされます
宛先とデプロイ元

コンテナは単純ですが、スケールは複雑です

コンテナを使い始めるのは非常に簡単ですが、複雑さが忍び寄る可能性があります
長期的な導入は、コンテナ化されたワークロードをデプロイするだけではありません
イメージビルドの標準、ソフトウェアの依存関係、および配布方法はすべて、大規模に重要です
デプロイするのにどれくらいかかりますか? どのくらいの頻度で？イメージのサイズとビルドにかかる時間は?.

Linux コンテナについて理解する

ワークロードを実行したり、パッケージ化を簡素化したりするために、コンテナで使用する AWS のサービスに関係なく、イメージから始めます
開発作業の一環としてこれらのイメージをビルドする場合は、優れたツールと、それらが解決する問題についてのコンテキストが必要です
そのコンテキストを設定するために、コンテナがどのように機能するか、およびさまざまな可動部分を処理するソフトウェアの簡単なツアーから始めます

コンテキスト用の Linux コンテナ

Linux コンテナは、実際には特定のものではありません
それらは、カーネル機能とユーザー空間ソフトウェアで構成される構造です
目標は、一見プライベートなコンピューティングでプロセスまたは一連のプロセスを開始することです
ソフトウェアの特定のバンドルからの環境
コンテナがバンドルから開始されるときはいつでも、コンテナは一貫している必要があります

名前空間

それ以外の場合はグローバルリソースの一見分離されたインスタンスを作成できます
コンテナでは、多数のリソースの名前空間を構成します
マウント、PID、ネットワーク、UTS、IPS、およびユーザーが例です
名前空間は、を作るものです
コンテナは孤立したシステムのようです

コントロールグループ (cgroup)

プロセスまたは一連のプロセスに制限と監視を提供します
CPU、メモリ、ネットワーク IO、およびディスク IO はすべて、cgroup によって制御できるリソースです
Linux をビルドするための 2 番目の主要コンポーネントには、次のものが含まれています

レスキューのためのツール

この時点で考えているかもしれませんが、スライドが数枚入っているだけで、心配する必要はもうありません
賛成です！だからこそ、ツールはとても重要です
コンテナは、多くの問題に対する優れたソリューションです
- 一貫性のある反復可能なランタイム環境
- 依存関係の管理、パッケージ化、および配布
- 一意の識別子によって配布に結び付けられた不変のデプロイアーティファクト
コンテナは非常に便利です。私たちのツールはコンテナを使いやすくするものです

どこから始めれば

コンテナの開発ツールのコンポーネントについて説明し、後でイメージをビルドするためのガイダンスを提供する際に、いくつかのコンテキストが必要になります
ボトムアップから始めて、ランタイムが必要です
コンテナランタイムは、カーネル機能とその他のコンポーネントソフトウェアを抽象化し、コンテナインスタンスの作成と実行をスムーズに処理します
ランタイムには、プロセスを実行するための環境が必要であり、移植可能なファイルシステムまたはイメージが必要になります

簡単な歴史、Open Containers Initiative

Open Containers Initiative は、コンテナイメージのフォーマットとランタイムの標準を設定するために作成されました
OCI ランタイムおよびイメージ仕様 v1.0 は、2017 年 7 月にリリースされました

コンテナの作成

OCI ランタイム仕様は、コンテナの構成、実行環境、およびライフサイクルを指定します
構成は構成ファイルで指定され、環境仕様によりコンテナの一貫性が保証されます
これらは標準ファイルにまとめられています
コンテナを作成できるシステムバンドル

リファレンス実装 runc

Docker のエンジニアによって実装されました
OCI ランタイム仕様のリファレンス実装として寄贈されました
準拠したバンドルが与えられると、コンテナが生まれます
ルートファイルシステムがすでに配置されている必要があります

コンテナイメージ

OCI Image Specification は、コンテナイメージのビルド、転送、および準備のためのツールを有効にします
イメージ・マニフェスト、イメージ・インデックス、一連のファイル・システム・レイヤーおよび構成で構成されるOCIイメージを指定します

イメージのビルド

Linux コンテナイメージは組み込みレイヤーです
各レイヤーは、スタック内の前のレイヤーに依存します
レイヤーは下から順にビルドされます
このセッションでは、Build Kit と Dockerfiles に焦点を当てます

イメージのビルド

BuildKit は成熟した機能豊富なイメージビルドシステムです
イメージレイヤーと構成をビルドする実際の作業を処理します
クライアントはビルドコンテキスト (通常はビルド環境内のパス) を渡します
ビルドコンテキストが読み込まれ、BuildKit が Dockerfile を反復処理します

Dockerfiles からビルドします

Dockerfile の各行は p
処理済み、上から下
命令を変更すると、イメージレイヤーがビルドされます。これは、最終イメージのボトムアップと見なされます
COPY などの rootfs を変更する命令や、パッケージをインストールする RUN コマンドを実行すると、新しいレイヤーが作成されます

イメージとは？

OCI イメージはマニフェストによって記述されます。マニフェストは、他のメタデータと共にダイジェストによってイメージレイヤーを指定します
Dockerfile からビルドされた (トップダウンで読み取られてビルドされた) レイヤーは、ボトムアップのイメージレイヤーを表します
イメージは事実上、下のレイヤーに依存する tarball のスタックです

イメージレイヤー

特定のレイヤーの変更のみが保存されます。その後、コンテナが作成されると、レイヤーが再ビルドされます
コンテナがローカルで作成されると、これらのレイヤーが再ビルドされます
レイヤーは不変であり、コンテンツのダイジェストによって識別されます
イメージは不変ですが、通常はコンテナ内のプロセスがファイルシステムに書き込めるようにする必要があります

不変のイメージ

新しいコンテナは、スタックの最上部にある読み取り/書き込みレイヤーから始まります
下位層は変更されず、ダイジェストによって識別されます
イメージマニフェストもダイジェストによって識別されます
イメージコンテンツは、特定のダイジェストによって常に説明できます

マルチプラットフォームイメージ

イメージは個別のアーティファクトです
特定の OS およびアーキテクチャのコンテンツ
コンテナは複数でサポートされています
システムとアーキテクチャ
マルチプラットフォームイメージには次のものが含まれます
マニフェストリスト、または OCI インデックス

マルチプラットフォームイメージ

これは、プラットフォームの注釈が付けられた他のマニフェストのインデックスです
クライアントは、オペレーティングシステムとアーキテクチャに適したイメージをプルするように実装されます

containerd ですべてを整理します

これで、コンテナを作成する方法と、コンテナを作成するためのイメージ、およびそれらのイメージを配布する方法が得られました
複数のコンテナインスタンスとそのイメージを管理し、合理的なシステムをビルドするための何かが必要です

containerd ですべてを整理します

containerd は Linux の標準コンテナスーパーバイザーであり、これも Docker のエンジニアによって開始され、寄付されました (今回は CNCF に寄付されました)
これは、コンテナを実行するシステムサービスとして実行され、コンテナインスタンスの作成と管理、イメージのプルなどを担当します
containerd は多くの開発ツールで使用されており、Kubernetes および AWS Fargate のデフォルトのランタイムです

レスキューのためのツール

何が抽象化されているかを理解するのは良いことなので、これは大雑把なツアーでした
お客様は、ツールではなく、ソフトウェアのビルドに集中したいと考えています
優れたツールは複雑さを抽象化し、シンプルなワークフローを可能にします

オープンソースのコンテナ開発ツール

コンテナ開発

セッションのこのセクションでは、コンテナ開発ツールについて説明します
具体的には、macOS などの非 Linux 環境向けの Linux コンテナツールについてお話したいと思います
私たちは、私たちが持っている要件を満たすオープンソースコンポーネントに焦点を当てます
また、それらを簡単に使用できる新しいオープンソースプロジェクトについて詳しく説明します

仮想マシン

ほとんどのコンテナ開発は Linux を対象としています
ほとんどの開発環境は macOS または Windows です
これまで見てきたように、Linux コンテナを実行して Linux イメージをビルドするには Linux が必要です
救助のための仮想化。最初はアドホックですが、その後はエンドツーエンドのソリューションです

エンドツーエンドのソリューション

Docker Desktop は、このニーズを満たす最初の製品であり、Hyperkit を使用する Docker の主力コンテナ開発製品です
Red Hat は、libpod ライブラリの一部として提供されるコマンドラインユーティリティである Podman と、QEMU を活用した Podman Desktop を今年初めに導入しました
Rancher Desktop は、Lima (QEMU を管理する) を活用して、nerdctl および Docker ベースのコンテナ管理でデスクトップ Kubernetes ソリューションを拡張しました
Colima は、Lima を使用して Linux VM で nerdctl または Docker を簡単に使用できるようにする、非常に人気のあるオープンソースプロジェクトです