モジュール 1: Amazon ECS、ECR、AWS Fargate を理解する
学習モジュール
概要
このモジュールでは、Amazon ECS、AWS Fargate 上の Amazon ECS、Amazon ECR についてご紹介します。Linux と Windows で実行されるコンテナ向けのクラスター、コンテナとイメージ、タスクとタスク定義、サービス、起動タイプについて説明します。最後に、これらすべての要素をまとめて、.NET アプリケーション向けに Amazon ECS または AWS Fargate 上の Amazon ECS を使用して最適なコンテナソリューションを実現するためのシナリオとパスについて見ていきます。
所要時間
30 分
Amazon ECS のご紹介
Amazon ECS は、クラウドでコンテナベースのアプリケーションを実行するために使用されるサービスです。拡張性が高く高速なコンテナ管理が可能で、他の AWS のサービスと統合することで、セキュリティ、コンテナオーケストレーション、継続的インテグレーションとデプロイ、サービス検出、モニタリングとオブザーバビリティを実現できます。
コンテナは、仮想マシンイメージから仮想マシンを起動する方法と同じ様に、コンテナイメージを使用して起動します。Amazon ECS は、Amazon Elastic Container Registry (Amazon ECR) または Docker Hub にデプロイされたコンテナイメージからコンテナをデプロイして実行します。
Amazon ECS はタスク定義を使用して、アプリケーションを構成するコンテナを定義します。タスク定義は、アプリケーションのコンテナの実行方法を指定します。実行して完了時に停止する個別のタスクを定義して使用することも、タスクをサービス内で実行するように定義することもできます。サービスは、指定された数のタスクを同時に継続的に実行および維持するため、ウェブアプリケーションなどの長時間実行されるアプリケーションに適しています。
必要に応じて、コンテナをホストするインフラストラクチャを設定して管理したり、AWS Fargate 上の Amazon ECS を使用してサーバーレスアプローチを活用したりできます。これにより、AWS がコンテナインフラストラクチャを管理し、ユーザーはアプリケーションに集中できます。Amazon ECS には、起動タイプと呼ばれるコンテナを実行するモデルが 2 つあります。
EC2 起動タイプ
EC2 起動タイプは、クラスターに設定された 1 つ以上の Amazon Elastic Compute Cloud (EC2) インスタンスでコンテナを実行するために使用します。EC2 起動タイプを使用すると、コンテナをホストするインフラストラクチャの設定と管理を完全に制御できます。
インフラストラクチャを管理する必要がある場合、またはアプリケーションで常に高い CPU コアとメモリの使用量を必要とする場合、料金を最適化する必要がある場合、または永続的なストレージが必要な場合は、コンテナには EC2 起動タイプを選択してください。
Fargate 起動タイプ
Fargate 起動タイプは、コンテナを実行するためのサーバーレスの従量制料金オプションです。サーバーレスでは、実行中のコンテナをホストするためにインスタンスのクラスターを設定および管理する方法を理解する必要がある EC2 起動タイプとは異なり、コンテナインスタンスをホストするためのインフラストラクチャを設定する必要がありません。
Amazon ECS のリソース
起動タイプを使用してコンテナインフラストラクチャの管理方法を制御する以外にも、Amazon ECS を操作する際はいくつかのタイプのリソースを使用します。
クラスター
クラスターは、特定のリージョンにあるコンピューティングリソースの論理的なグループです。クラスターは、アプリケーションとアプリケーションコンポーネントをホストする実行中のコンテナインスタンスを保存し、同じ基盤となるインフラストラクチャを使用しないようにそれらを分離するのに役立ちます。これにより、アプリケーションをホストしているインフラストラクチャの特定の項目に障害が発生した場合の可用性が向上します。再起動する必要があるのは、影響を受けたクラスターだけです。
Amazon ECS を使用するか、AWS Fargate 上の Amazon ECS を使用するかに関係なく、クラスターを操作することになります。異なるのは、期待される管理のレベルです。クラスターの作成時に EC2 起動タイプを指定した場合、それらのクラスターの設定と管理はお客様の責任となります。ただし、Fargate 起動タイプを使用する場合、それらを管理するのは Fargate の責任です。
コンテナ
コンテナは、コンテナ内のアプリケーションまたはアプリケーションコンポーネントの実行に必要なコード、ランタイム、ツール、およびシステムライブラリをすべて保存します。コンテナインスタンスを起動してアプリケーションをホストすると、クラスターに関連付けられたコンピューティングインフラストラクチャで実行されます。
コンテナを起動するには、コンテナイメージと呼ばれる読み取り専用テンプレートが使用されます。イメージを使用してコンテナを実行する前に、コンテナイメージを Amazon Elastic Container Registry (Amazon ECR) や Docker Hub などのレジストリにデプロイする必要があります。
コンテナイメージは、Dockerfile と呼ばれるリソースを使用して定義します。Dockerfile は、イメージに含めたいすべてのコンポーネントとリソースの詳細が記載されたテキストファイルです。Amazon ECS は、他の場所で .NET アプリケーションのコンテナイメージを定義するときに使用したのと同じ Dockerfile を、変更することなく使用します。docker build コマンドを使用すると、Dockerfile で定義されているコマンドと設定を、レジストリにプッシュしたり、Docker でローカルに実行したりできるコンテナイメージに変換できます。AWS から入手できるコンテナツール (モジュール 2 で詳述) は、多くの場合、イメージのビルドとプッシュを代行してくれます。
タスク定義
タスク定義は、アプリケーションを構成するコンテナを記述するために使用する JSON 形式のテキストファイルです。1 つのタスク定義で最大 10 個のコンテナを記述できます。
タスク定義は、アプリケーションとオペレーティングシステムのパラメータを指定するアプリケーション環境のブループリントと考えることができます。例としては、どのネットワークポートを開いておくべきか、アタッチする必要があるデータボリュームなどのリソースがあります。
Amazon ECS は、アプリケーションを 1 つのタスク定義に制限しません。実際、アプリケーションの一部を構成するコンポーネントの関連コンテナを 1 つのタスク定義にまとめ、複数のタスク定義を使用してアプリケーション全体を記述することをお勧めします。これにより、アプリケーションを構成するさまざまな論理コンポーネントを個別に拡張できます。
Web UI フロントエンド層、API 層、中間層、データベースコンポーネント層で構成される一般的な n 層ウェブアプリケーションを考えてみましょう。以下のイメージは、これらのコンポーネント層をさまざまなタスク定義にグループ化する方法を示しています。これにより、例えば、使用量が急増した場合、ウェブ UI 層を他のコンポーネントとは別個に、水平方向にスケーリングでき、またその逆も可能です。1 つのタスク定義ですべての層を定義した場合、使用量が増加していない層を含め、アプリケーション全体が負荷に応じてスケーリングされ、スケールアウトにかかる時間が長くなり (アプリケーションが大きい場合)、財務コストが増加する可能性があります。
以下に、タスク定義の例を示します。Fargate 起動タイプの Linux コンテナを使用してウェブサーバーをセットアップします。
{
"containerDefinitions": [
{
"command": [
"/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' > /usr/local/apache2/htdocs/index.html && httpd-foreground\""
],
"entryPoint": [
"sh",
"-c"
],
"essential": true,
"image": "httpd:2.4",
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group" : "/ecs/fargate-task-definition",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"name": "sample-fargate-app",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp"
}
]
}
],
"cpu": "256",
"executionRoleArn": "arn:aws:iam::012345678910:role/ecsTaskExecutionRole",
"family": "fargate-task-definition",
"memory": "512",
"networkMode": "awsvpc",
"runtimePlatform": {
"operatingSystemFamily": "LINUX"
},
"requiresCompatibilities": [
"FARGATE"
]
}タスク
Amazon ECS がタスク定義をインスタンス化すると、クラスター内で実行されるタスクが 1 つ以上作成されます。タスクは実行中のコンテナインスタンスです。他の環境設定に加えて、タスク定義はクラスターで実行されるタスクの数またはコンテナインスタンスの数を指定します。
タスクをスタンドアロンで実行するように設定して、タスクの完了時にコンテナを停止させることも、タスクをサービスとして継続的に実行することもできます。サービスの一部として実行すると、Amazon ECS は指定された数のタスクを同時に実行し、障害が発生したコンテナを自動的に交換します。
継続的に実行する必要のないアプリケーションコードには、スタンドアロンタスクを使用します。コードはタスク内で 1 回実行されてから終了し、コンテナインスタンスが終了します。例としては、一部のデータのバッチ処理があります。
スケジュールされたタスク
オペレーターが介入してタスクを手動で開始することなしに定期的に実行する必要があるアプリケーションコードには、スケジュールされたタスクを使用します。シナリオの例としては、ログの検査、バックアップ操作、または定期的な抽出、変換、ロード (ETL) ジョブを実行するコードがあります。
サービス
Amazon ECS は、クラスター内の各コンテナインスタンスでエージェントを実行します。このエージェントを自分でインストールしたり、メンテナンスしたりする必要はありません。エージェントは、実行中のタスクとコンテナインスタンスの使用状況に関する情報を報告し、Amazon ECS が失敗または停止したタスクを検出できるようにします。このような場合、Amazon ECS は失敗したタスクを新しいインスタンスに置き換えて、サービスで指定された数のタスクを維持します。ユーザーが自分で監視してアクションを実行する必要はありません。
継続的に実行する必要があるアプリケーションコードにはサービスを使用します。例としては、ウェブサイトのフロントエンドや Web API があります。
アプリケーションデータを永続化する
実行中のコンテナインスタンスには、データを保存できる書き込み可能なレイヤーがあります。ただし、書き込み可能なレイヤーは一時的なものであり、ユーザーアクションによってコンテナインスタンスが終了したとき、またはインスタンスが異常になり、Amazon ECS がそれを置き換えたことを理由に、破棄されます。このため、書き込み可能なレイヤーは、データベース内のデータなどの長期間のデータ保存には適していません。さらに、書き込み可能なレイヤーのデータには、個々のコンテナインスタンスで実行されるコードによってのみアクセスできるため、複数のコンテナインスタンスにまたがるアプリケーションで共有する必要があるデータには適していません。
アプリケーションデータをコンテナインスタンスの存続期間よりも長い期間保存したり、複数のコンテナインスタンス間で共有したりできるように、AWS はいくつかのストレージサービスを用意しています。これらのストレージサービスは、データストレージをコンピューティングインスタンスから切り離します。コンピューティングインスタンスから切り離されたストレージを使用すると、アプリケーションデータがアプリケーションが実行されているコンテナインスタンスよりも長く存続し、データを複数のインスタンスで共有できるようになります。
コンテナ化された .NET アプリケーションで使用できるストレージサービスは、アプリケーションが Linux コンテナと Windows コンテナのどちらで実行されているかによって異なります。
Linux コンテナ向けの永続ストレージオプション
Linux コンテナは現在、Amazon ECS または AWS Fargate 上の Amazon ECS で実行されている場合、.NET アプリケーション向けの最も幅広いストレージサービスをサポートしています。ストレージサービスの選択は、アプリケーションがデータへの共有同時アクセスを必要とするかどうかによって異なります。
Amazon Elastic Block Store (Amazon EBS)
Amazon Elastic Block Store (Amazon EBS) は、ブロックレベルのストレージボリュームを提供するストレージサービスです。EBS ボリュームは、通常のドライブデバイスと同じようにアクセスできる Linux コンテナにマウント可能なストレージをアプリケーションに提供します。Amazon EBS は、アベイラビリティーゾーン内の EBS ボリューム中のデータを自動的に複製するため、ストレージボリュームに障害が発生した場合でもアプリケーションの信頼性を向上させる信頼性の高いストレージソリューションとなります。
EBS ボリュームは動的にサイズ変更可能で、暗号化をサポートし、コピーを作成するためのスナップショットもサポートしています。必要に応じて、ボリュームをコンテナから切り離して、別のコンテナに再度アタッチできます。アプリケーションのパフォーマンスと料金の要件に合わせて、Amazon EBS ではさまざまなボリュームタイプが用意されています。
EBS ボリュームはリージョンの特定のアベイラビリティーゾーンに作成されます。その後、ボリュームは、同じゾーンで実行されているタスク定義の設定を使用してコンテナインスタンスにマウントできます。別のアベイラビリティーゾーンの同じデータにアクセスするには、ボリュームのスナップショットを作成し、そのスナップショットを使用して同じリージョンまたは別のリージョンの別の場所に新しいボリュームを作成します。1 つのスナップショットで、アベイラビリティーゾーンとリージョンにまたがる多数のボリュームを作成できます。これは、高可用性を必要とするアプリケーションで使用される読み取り専用のアプリケーションデータで、さまざまなアベイラビリティーゾーンとリージョンにまたがる複数のコンテナインスタンスにデプロイされている場合に検討すべきアプローチです。
Amazon EBS は、アプリケーションが水平方向にスケーリングされる (つまり、複数のコンテナインスタンスで実行される) ため、同時に共有されないデータへの高速で低レイテンシーのアクセスを必要とするアプリケーションにとって、検討すべき優れたストレージソリューションです。例としては、1 つのコンテナインスタンスからアクセスする一般的なファイルシステムやデータベースがあります。
Amazon EBS はボリュームへの同時アクセスをサポートしていません。アプリケーションが複数のコンテナにマウントされた 1 つのファイルシステムを共有する必要があるアプリケーションでは、Amazon Elastic File Service、または Amazon FSx から入手できるいずれかのファイルシステムを検討してください。
Amazon Elastic File System (Amazon EFS)
Amazon EFS は、ネットワークファイルシステム (NFS) を使用してアクセスするスケーラブルなファイルシステムサービスを提供するため、ストレージを管理する必要はありません。Amazon EFS で管理されるファイルシステムは、読み取り/書き込みの一貫性とファイルロックにより、複数の Linux ベースのコンテナインスタンスに同時にアタッチできます。これにより、スケールアウトされたアプリケーションをホストする複数のコンテナ間でドライブ上のデータを共有し、読み取り/書き込みアクセスが可能になります。Amazon EFS ストレージも動的で、アプリケーションストレージのニーズの変化に応じて自動的に容量を拡張 (および縮小) します。
料金はアプリケーションが消費したストレージに対してのみ発生します。デフォルトでは、Amazon EFS で作成されたファイルシステムのデータは、耐障害性と耐久性を持たせるために、リージョン内の複数のアベイラビリティーゾーンに保存されます。Amazon EFS では、このモードを標準ストレージクラスと呼んでいます。アプリケーションがフルサイズのマルチ AZ ストレージを必要としない場合は、代わりに 1 ゾーンストレージクラスを使用するとコストを節約できます。 標準 – 低頻度アクセスと 1 ゾーン – 低頻度アクセスのストレージクラスは、アプリケーションが非定期的にアクセスするデータをホストするためにも使用でき、コストをさらに節約できます。
Amazon EFS ファイルシステムは、ウェブアプリケーション、コンテンツ管理システム、ユーザーのホームフォルダ、一般的なファイルサーバーなど、幅広いアプリケーションに適しています。ファイルシステムは、認証、承認、暗号化をサポートしています。アクセス制御は標準の POSIX 許可を使用します。
以下のタスク定義スニペットの例は、タスクに EFS ファイルシステムをマウントする方法を示しています。
"containerDefinitions":[
{
"mountPoints": [
{
"containerPath": "/opt/my-app",
"sourceVolume": "Shared-EFS-Volume"
}
}
]
...
"volumes": [
{
"efsVolumeConfiguration": {
"fileSystemId": "fs-1234",
"transitEncryption": "DISABLED",
"rootDirectory": ""
},
"name": "Shared-EFS-Volume"
}
]
Amazon FSx for Lustre
Lustre は、機械学習、ハイパフォーマンスコンピューティング (HPC)、動画処理、財務モデリングのパフォーマンスニーズに対応するために設計されたオープンソースのファイルシステムです。これらのソリューションに対応する .NET アプリケーションや、ミリ秒未満のレイテンシーを必要とするその他のシナリオでは、Amazon FSx for Lustre は Linux コンテナ向けに永続ストレージレイヤーを提供できます。
注: 執筆時点では、AWS Fargate で実行されているタスクは FSx for Lustre ファイルシステムをサポートしていません。
FSx for Lustre で作成されたファイルシステムは POSIX に準拠しています。つまり、Linux 上で動作する .NET アプリケーションで既に使用しているのと同じ、使い慣れたファイルアクセス制御を引き続き使用できるということです。FSx for Lustre でホストされているファイルシステムは、読み取り/書き込みの一貫性とファイルロック機能も備えています。
アプリケーションのニーズに応じて、さまざまなワークロード要件に最適化されたソリッドステート (SSD) ストレージとハードドライブ (HDD) ストレージを選択できます。SSD ストレージは、レイテンシーの影響を受けやすく、通常はランダムにアクセスする小規模なファイル操作が発生する、IOPS を多用するアプリケーションに適しています。HDD ストレージタイプは、一般的に大規模でシーケンシャルなファイル操作を伴う高スループット要件のアプリケーションに適しています。HDD ストレージでは、読み取り専用 SSD キャッシュを HDD ストレージの 20% まで追加することもできます。これにより、ミリ秒未満のレイテンシーと IOPS の向上が可能になり、頻繁にアクセスされるファイルのパフォーマンスが向上します。
FSx for Lustre のファイルシステムは、完全な読み取り/書き込みアクセス権で Amazon S3 バケットにリンクすることもできます。これにより、.NET アプリケーションは S3 バケット内のオブジェクトを、あたかも既にファイルシステムに存在しているかのように処理できるようになります。これは、S3 に既にある大規模なクラウドベースのデータセットのデータを処理するように構築されたアプリケーションにとって、データにアクセスして更新する前にそのデータをファイルシステムにコピーする必要がないオプションです。
lustre-client パッケージを使用して Docker コンテナ内のコマンドを使って Lustre ファイルシステムをマウントすることもできます。これにより、コンテナ内でファイルシステムを動的にマウントできます。
Windows コンテナの永続ストレージオプション
.NET および .NET Framework アプリケーションを実行する Windows コンテナでは、Amazon FSx for Windows File Server が提供するファイルストレージを使用して、タスクで実行されている 1 つ以上のコンテナ間でデータの永続化とデータの共有を行えます。
Amazon FSx for Windows File Server
FSx for Windows File Server は、SMB 経由で標準の Windows ファイル共有を介してアクセスできる実際の Windows ファイルサーバーインスタンスを使用して、アプリケーションデータを保存および提供します。標準の Windows ファイル共有では、シャドウコピー、ユーザークォータ、アクセスコントロールリスト (ACL) を使用したエンドユーザーファイルの復元など、Windows File Server 管理者が既に使い慣れている機能や管理ツールを使用できます。SMB では、Linux コンテナから FSx for Windows File Server 共有に接続することもできます。
FSx for Windows File Server のファイルシステムは、データの重複排除と圧縮を使用するアプリケーションのストレージコストを削減するのに役立ちます。その他の機能には、データ暗号化、監査可能なファイルアクセス、スケジュールされた自動バックアップなどがあります。ファイルシステム共有へのアクセスは、オンプレミスの Microsoft Active Directory (AD) または AWS の Managed AD との統合により制御できます。
FSx for Windows File Server は、オンプレミスの Windows ベースのファイルサーバーをクラウドに移行して、コンテナ化された. NET/.NET Framework アプリケーションと連携させるのに適しています。また、ハイブリッドクラウドやオンプレミスのデータストア (Amazon FSx File Gateway を使用) にアクセスする必要がある .NET および .NET Framework アプリケーションでの使用にも適しています。SQL Serverを使用するアプリケーションでは、FSx for Windows File Serverを使用すると、SQL Server Enterpriseライセンスを必要とせずにこれらのデータベースワークロードを実行できます。
以下のタスク定義スニペットの例は、FSx for Windows File Server で作成されたファイルシステムをタスクにマウントする方法を示しています。
{
"containerDefinitions": [
{
"entryPoint": [
"powershell",
"-Command"
],
"portMappings": [],
"command": [...' -Force"],
"cpu": 512,
"memory": 256,
"image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
"essential": false,
"name": "container1",
"mountPoints": [
{
"sourceVolume": "fsx-windows-dir",
"containerPath": "C:\\fsx-windows-dir",
"readOnly": false
}
]
},
...
],
"family": "fsx-windows",
"executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole",
"volumes": [
{
"name": "fsx-windows-vol",
"fsxWindowsFileServerVolumeConfiguration": {
"fileSystemId": "fs-0eeb5730b2EXAMPLE",
"authorizationConfig": {
"domain": "example.com",
"credentialsParameter": "arn:arn-1234"
},
"rootDirectory": "share"
}
}
]
}その他の永続ストレージオプション
AWS では、ECS のタスクに必要な永続ストレージを処理するための特殊なファイルシステムサービスを他にもいくつか提供しています。このコースでは、これらのファイルシステムとサービスについては説明しませんが、代わりに以下の製品詳細をご覧ください。
- Amazon FSX for OpenZFS は、OpenZFS ファイルシステムを使用してフルマネージド型のファイルストレージを提供します。OpenZFS は、高性能ストレージと、インスタントデータスナップショット、暗号化、クローニングなどの機能を必要とするワークロード向けのオープンソースファイルシステムです。OpenZFS ストレージには NFS を使用してアクセスでき、.NET アプリケーションコンテナで使用するために Linux ファイルサーバーをクラウドに簡単に移行できます。
- Amazon FSx for NetApp ONTAP は、データアクセスと管理機能を提供するもう 1 つのフルマネージド型ファイルストレージサービスです。アプリケーションは、NFS、SMB、および iSCSI プロトコルを使用して NetApp ONTAP ファイルシステムにアクセスします。
AWS Fargate のご紹介
クラウドインフラストラクチャのプロビジョニングと管理に対するサーバーレスアプローチは、多くのデベロッパーや組織にとって魅力的です。サーバーレスでは、アプリケーションをホストするため、インフラストラクチャリソースの差別化されていないプロビジョニングと管理を AWS が処理します。これにより、デベロッパーはアプリケーションに集中できます。アプリケーションの実行とスケーリングに必要なものを指定します。その方法については、AWS が責任を負います。
AWS Fargate は、クラウドでコンテナをホストするサーバーレスアプローチです。Amazon ECS 向けの Fargate または Amazon EKS ベースのアプリケーションを選択すると、コンテナベースのアプリケーションをホストするために Amazon EC2 インスタンスのサーバーまたはクラスターを管理する必要がなくなります。Fargate は、必要に応じてコンテナインフラストラクチャのプロビジョニング、設定、スケールアップとスケールダウンを行います。
デベロッパーとして、Dockerfile を使用してコンテナイメージのビルドを定義し、そのビルドされたイメージを Amazon ECR または Docker Hub にデプロイすることに関心をお持ちのことでしょう。アプリケーションのランタイムインフラストラクチャでは、オペレーティングシステム、CPU とメモリ、ネットワーク、および IAM ポリシーを指定するだけです。その後、Fargate はそれらの要件を満たすコンテナインフラストラクチャをプロビジョニングし、スケーリングします。Fargate は、.NET および .NET Framework アプリケーションをサービス、タスク、およびスケジュールされたタスクとして実行することをサポートしています。
AWS Fargate で Amazon ECS を利用したい .NET デベロッパーは、Windows Server 環境または Linux 環境を選択できます。.NET Framework アプリケーションは Windows Server コンテナを使用する必要があります。ただし、.NET で構築されたアプリケーションでは、Windows Server 環境と Linux 環境のどちらかを選択できます。
注: Windows Server コンテナと Linux コンテナを混在させて使用するアプリケーションでは、異なる環境ごとに個別のタスクが必要です。
AWS Fargate の Linux コンテナ上の .NET
.NET ベースのアプリケーション (.NET 6 以上) は、Fargate がプロビジョニングおよび管理するコンテナインフラストラクチャを使用できます。Fargate は、X86_64 または ARM64 のどちらのアーキテクチャでも利用できる Amazon Linux 2 を使用しています。タスク定義は必要なアーキテクチャを指定します。
注: Fargate では、古い .NET Core 3.1 および .NET 5 ベースのアプリケーションを実行することもできます。ただし、これらのバージョンはいずれも Microsoft からのサポートが終了しているか、間もなくサポートされなくなります。.NET 5 は長期サポート (LTS) リリースではなかったため、現在はサポート対象外です。これを書いている時点で、.NET Core 3.1 はメンテナンスサポート段階にあります。つまり、サポート終了からセキュリティ問題のパッチを受け取るだけの期間が 6 か月もないことになります。
AWS Fargate の Windows コンテナ上の .NET
Fargate 上の Windows コンテナは、.NET フレームワークと .NET アプリケーションの両方を実行できます。Fargate は現在、アプリケーション向けの Windows Server の 2 つのバージョン (Windows Server 2019 Full と Windows Server 2019 Core) をサポートしています。どのバージョンを使用しても、AWS がユーザーのために Windows オペレーティングシステムのライセンスを管理します。
注: Windows Server のすべての機能、および一部の AWS 機能は、AWS Fargate 上の Windows コンテナでは使用できないことにご注意ください。機能の制限と考慮事項に関する最新情報については、サービスドキュメントを参照してください。サポートされていない機能の例を以下に示します。
- グループマネージドサービスアカウント (gMSA)。
- Amazon FSx ファイルシステム (FSx for Windows File Server 以外)。
- 設定可能な一時ストレージ。
- Amazon Elastic File Store (Amazon EFS) ボリューム。
- イメージボリューム。
- App Mesh サービスとタスクのプロキシ統合。
Amazon ECS と AWS Fargate 上の Amazon ECS のどちらを選択するか
以下を使用して、.NET アプリケーションをホストするのに Amazon ECS を選択するのか、AWS Fargate 上の Amazon ECS を選択するのかをご判断ください。
- タスクをホストするためにクラスターやその他のインフラストラクチャをプロビジョニング、管理、スケーリングしたい場合、またはこのインフラストラクチャを自己管理する必要がある場合は、Amazon ECS をお選びください。
- コンテナ化されたアプリケーションをサポートするインフラストラクチャのプロビジョニング、管理、スケーリングを AWS に任せたい場合は、AWS Fargate をお選びください。AWS Fargate は、.NET フレームワークや .NET アプリケーション向けの Windows コンテナ、または .NET アプリケーション向けの Linux コンテナをサポートしています。
- Amazon FSx for Windows File Server を使用してコンテナに追加の永続ストレージボリュームを提供する .NET アプリケーションの場合は、Amazon ECS をお選びください。AWS Fargate は、執筆時点ではこのストレージオプションをサポートしていません。
コンテナイメージと Amazon Elastic Container Registry (Amazon ECR)
Amazon ECR は、Docker およびオープンコンテナイニシアチブ (OCI) コンテナイメージ向けの安全でスケーラブルなフルマネージド型コンテナレジストリです。その機能により、Amazon ECS を使用しているか、AWS Fargate 上で Amazon ECS を使用しているかにかかわらず、コンテナイメージの保存、管理、デプロイが簡単になります。フルマネージドサービスである Amazon ECR は、レジストリのサポートに必要なインフラストラクチャの提供、管理、スケーリングを行います。
注: Amazon ECS と AWS Fargate を使用している場合は、Docker Hub を使用してコンテナイメージを保存することもできます。
Amazon ECR は、各 AWS リージョンのすべてのアカウントにデフォルトのプライベートレジストリを提供します。レジストリは、コンテナイメージを保存する 1 つ以上のプライベートリポジトリを管理するために使用します。イメージをリポジトリにプッシュまたはリポジトリからプルする前に、クライアントは認証トークンを取得する必要があります。認証トークンは、次にレジストリへのアクセスを認証するために使用されます。イメージがリポジトリにプッシュされると、Amazon ECR はオプション機能として自動脆弱性スキャンを行います。リポジトリは、AWS Key Management Service (KMS) による暗号化もサポートしており、AWS が提供するキーを使用するか、カスタムのユーザーマネージドキーを使用するかを選択できます。
アクセスを制御するために、Amazon ECR は AWS IAM と統合されています。きめ細かなリソースベースのアクセス許可により、コンテナイメージとリポジトリにアクセスできるユーザー (または対象) を制御できます。Amazon ECR が提供する管理ポリシーを使用して、さまざまなレベルのアクセス制御を行うこともできます。
レジストリごとの設定を使用すると、リポジトリはリージョンや他のアカウント間で複製できます。追加のイメージライフサイクルポリシーも設定できます。例えば、リポジトリ内の未使用のイメージをクリーンアップするライフサイクルポリシーを設定 (およびテスト) できます。
Amazon ECR では、パブリックレジストリとプライベートレジストリの両方を使用できます。他のパブリックレジストリからプルされたコンテナイメージ用のプルスルーキャッシュも利用できます。プルスルーキャッシュは、ビルドやデプロイを上流のレジストリやリポジトリで停止させないようにします。また、開発チームが依存関係のコンプライアンス監査を受けるのにも役立ちます。
Amazon ECR のパブリックレジストリとプライベートレジストリ、それらに含まれるリポジトリ、プルスルーキャッシュリポジトリの詳細については、以下の機能をご確認ください。
プライベートレジストリとリポジトリ
AWS は各アカウントに各 AWS リージョンに 1 つのプライベートレジストリを提供し、各レジストリには 0 個以上のリポジトリを含めることができます (イメージを保存するには少なくとも 1 つのリポジトリが必要です)。アカウント内のリージョン別のレジストリには、https://aws_account_id.dkr.ecr.region.amazonaws.com 形式の URL (例えば、https://123456789012.dkr.ecr.us-west-2.amazonaws.com) を使用してアクセスできます。
プライベートレジストリ内のリポジトリには、Docker とオープンコンテナ規格 (OCI) 両方のイメージとアーティファクトが保存されます。イメージとアーティファクトに必要な数だけリポジトリを使用できます。例えば、あるリポジトリを使用して開発段階のイメージを保存し、別のリポジトリをテスト段階のイメージ用に保存し、さらに別のリポジトリを使用して実稼働ステージにリリースされたイメージを保存できます。
リポジトリイメージ内のイメージ名は一意である必要がありますが、Amazon ECR リポジトリは名前空間もサポートしています。これにより、さまざまなイメージを識別するイメージ名を、1 つのリポジトリでさまざまな環境ステージやチームで再利用できます。
アカウントには、デフォルトでプライベートレジストリのリポジトリへの読み取りおよび書き込みアクセス権があります。ただし、IAM プリンシパル、およびそれらのプリンシパルのスコープ内で実行されるツールには、Amazon ECR の API を利用したり、Docker CLI などのツールを使用してリポジトリに対してプル/プッシュコマンドを発行したりするための許可が必要です。このコースのモジュール 2 で詳しく説明されているツールの多くは、ユーザーに代わってこの認証プロセスを処理します。
プライベートリポジトリは、AWS マネジメントコンソールの Amazon ECR ダッシュボード、AWS Toolkit for Visual Studio の AWS Explorer ビュー、またはコマンドラインで AWS CLI または AWS Tools for PowerShell を使用して作成できます。以下のスクリーンショットは、Visual Studio 内からプライベートリポジトリを作成している様子を示しています。これを行うには、AWS Explorer ビューの Amazon Elastic Container Service エントリを展開し、リポジトリエントリのコンテキストメニューから [Create repository] (リポジトリを作成) を選択します。
AWS Toolkit for Visual Studio は、ECR パブリックレジストリでの作業や、プライベートレジストリ内の新しいリポジトリの自動スキャンやリポジトリ暗号化などの機能の有効化をサポートしていません。これらの機能が必要な場合は、AWS マネジメントコンソール、または AWS CLI や AWS Tools for PowerShell などのコマンドラインツールを使用してリポジトリを作成します。
パブリックレジストリとリポジトリ
Amazon ECR のパブリックレジストリとリポジトリは、公開したイメージを誰でもプルできます。各アカウントには、複数のパブリックリポジトリを含むことができるパブリックレジストリが用意されています。プライベートリポジトリと同様に、パブリックリポジトリには Docker とオープンコンテナ規格 (OCI) のイメージとアーティファクトが保存されます。
パブリックレジストリのリポジトリは、Amazon ECR Public Gallery に一覧表示されています。これにより、コミュニティは公開イメージを見つけてプルすることができます。パブリックレジストリを所有する AWS アカウントには、そのレジストリに含まれるリポジトリへの完全な読み取り/書き込みアクセス権があります。リポジトリにアクセスする IAM プリンシパルは、トークンで提供される許可を取得し、そのトークンを使用してイメージをプッシュするための認証を行う必要があります (プライベートリポジトリと同様)。ただし、認証の有無にかかわらず、誰でもパブリックリポジトリからイメージをプルすることは可能です。
ギャラリー内のリポジトリには、https://gallery.ecr.aws/registry_alias/repository_name という形式の URL を使用してアクセスします。registry_alias は、最初のパブリックリポジトリが作成されたときに作成されたもので、変更可能です。パブリックリポジトリからイメージをプルするための URI の形式は、public.ecr.aws/registry_alias/repository_name: image_tag です。
パブリックリポジトリにイメージをプッシュするには、パブリックレジストリへの許可と認証が必要です。許可はトークンで提供され、レジストリへの認証時に提示する必要があります。イメージは、事前認証の有無にかかわらず、パブリックリポジトリからプルできます。
プルスルーキャッシュリポジトリ
プルスルーキャッシュは、上流のパブリックレジストリのキャッシュイメージを Amazon ECR のプライベートレジストリにキャッシュします。現在、Amazon ECR は Amazon ECR Public と Quay を上流のレジストリとしてサポートしています。Amazon ECR は上流に新しいイメージバージョンがないかチェックし、新しいバージョンが利用可能であれば 24 時間に 1 回キャッシュを更新します。プルスルーキャッシュは、上流のレジストリに影響するシステム停止やその他の問題からビルドやデプロイプロセスを切り離すのに役立ちます。
キャッシュリポジトリは、設定された上流のレジストリからイメージを初めてプルしたときに自動的に作成されます。イメージプルは AWS IP アドレスを使用し、上流のレジストリに設定されているプルレートクォータの影響を受けません。キャッシュリポジトリへのイメージプルは、ルールを使用して設定されます。プライベートレジストリには、最大 10 個のプルスルーキャッシュルールを設定できます。
以下のイメージは、2 つのルールの例を示しています。1 つは Amazon ECR パブリックからイメージをキャッシュするルールで、もう 1 つは Quay のイメージをキャッシュするルールです。この設定では、Amazon ECR Public から初めてイメージをプルしたときに、上流のリポジトリの名前を使用して ecr-public 名前空間にリポジトリが自動的に作成されます。Quay からプルされたイメージについても同様です。
AWS Toolkit for Visual Studio は、ECR パブリックレジストリでの作業や、プライベートレジストリ内の新しいリポジトリの自動スキャンやリポジトリ暗号化などの機能の有効化をサポートしていません。これらの機能が必要な場合は、AWS マネジメントコンソール、または AWS CLI や AWS Tools for PowerShell などのコマンドラインツールを使用してリポジトリを作成します。
上流のレジストリからプルスルーキャッシュにプルされたイメージは、レプリケーションや自動脆弱性スキャンなど、プライベートリポジトリで利用できる追加の Amazon ECR 機能をサポートします。
イメージをプッシュしプルする
アカウントには、デフォルトでプライベートレジストリとパブリックレジストリのリポジトリへの読み取りおよび書き込みアクセス権があります。ただし、それらのアカウント内の IAM プリンシパル、およびその IAM プリンシパルのスコープ内で実行されるツールには、プッシュ/プルコマンドと Amazon ECR の API を使用する許可が必要です。許可は認証トークンとして提供され、Amazon ECR のプライベートレジストリまたはパブリックレジストリへのアクセスを認証するときに提示する必要があります。
注: IAM プリンシパルには、プライベートリポジトリにイメージをプッシュ/プルしたり、パブリックリポジトリにイメージをプッシュしたりする許可が必要ですが、アカウントのパブリックレジストリにあるパブリックリポジトリから誰でも認証なしでイメージをプルできます。これを非認証プルと呼びます。
コマンドラインでリポジトリアクセスを承認する
このコースのモジュール 2 で説明した AWS ツールの多くは、ユーザーに代わってトークンを取得し、それを使用してプライベートレジストリで認証しますが、CI/CD パイプラインからレジストリにアクセスする場合など、必要に応じて同じ手順を自ら実行することもできます。または、Amazon ECR 認証情報ヘルパーユーティリティを GitHub から入手できます。詳細については、「Amazon ECR Docker 認証情報ヘルパー」を参照してください (このコースでは、ヘルパーユーティリティの使用については詳しく説明しません)。
AWS CLI と AWS Tools for PowerShell には、認証トークンを簡単に取得するためのコマンドが含まれています。認証トークンはそれを Docker Client などのツールで使用して、イメージをプッシュしたりプルしたりします。どちらのコマンドもサービスからの出力を処理し、必要なトークンを出力します。コマンドラインの使用が適していないシナリオやカスタムツールには、Amazon ECR API コールの GetAuthorizationToken を使用できます。
注: 認証トークンの許可は、それをリクエストした IAM プリンシパルに与えられた許可を超えることはありません。トークンは 12 時間有効です。
AWS CLI を使用して Amazon ECR レジストリで Docker を認証するには、次のように、get-login-password コマンドを使用して出力を docker login にパイプし、ユーザー名として AWS を指定し、レジストリの URL を指定します。
aws ecr get-login-password --region region | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
AWS Tools for PowerShell を使用して Docker クライアントを認証するには、Get-ECRLoginCommand (AWS.Tools.ECR モジュール、またはレガシーの AWSPowerShell と AWSPowerShell.NetCore モジュールで利用可能) を使用します。次のように、出力オブジェクトの Password プロパティを docker login コマンドにパイプし、ユーザー名として AWS を指定し、レジストリの URL を指定します。
(Get-ECRLoginCommand -Region region).Password | docker login --username AWS --password-stdin aws_account_id.dkr.ecr.region.amazonaws.com
Docker クライアントが認証されると、イメージをレジストリ内のリポジトリにプッシュしたり、リポジトリからプルしたりすることができます。異なるリージョンのレジストリには個別の認証トークンが必要であることに注意してください。
イメージをプッシュする
プライベートリポジトリとパブリックリポジトリの両方にイメージをプッシュするには、IAM 許可が必要です。ベストプラクティスとして、IAM プリンシパルの許可のスコープを特定のリポジトリに絞り込むことを検討してください。以下のポリシー例は、特定のリポジトリを対象として、イメージをプッシュするためにプリンシパルが必要とする Amazon ECR API オペレーション (「アクション」) を示しています。リポジトリを指定すると、Amazon リソースネーム (ARN) を使用してリポジトリを識別します。複数のリポジトリを (配列要素で) 指定したり、ワイルドカード (*) を使用してスコープをすべてのリポジトリに広げたりできることに留意してください。
以下のポリシーを使用するには、111122223333 を AWS アカウント ID に、リージョンをリポジトリが存在するリージョンに置き換え、リポジトリ名を設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:CompleteLayerUpload",
"ecr:GetAuthorizationToken",
"ecr:UploadLayerPart",
"ecr:InitiateLayerUpload",
"ecr:BatchCheckLayerAvailability",
"ecr:PutImage"
],
"Resource":
"arn:aws:ecr:region:111122223333:repository/repository-name"
}
]
}上記と同様の IAM ポリシーを設定し、レジストリに対して認証したら、Docker CLI またはその他のツールを使用してイメージをプッシュできます。イメージをリポジトリにプッシュする前に、レジストリ、リポジトリ、およびオプションのイメージタグ名でタグ付けする必要があります (イメージタグ名を省略すると、最新のものとみなされます)。次の例は、Amazon ECR にプッシュする前にローカルイメージにタグを付けるタグ形式とコマンドを示しています。
111122223333 はお使いの AWS アカウント ID に、リージョンはリポジトリを含むリージョンの識別子 (us-east-1、us-west-2 など) に、リポジトリ名はリポジトリの実際の名前に置き換えてください。
docker tag ab12345ef 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
最後に、次のようにイメージをプッシュします。
docker push 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
イメージをプルする
イメージは、イメージがプッシュされたときに使用されたものと同じタグ付け形式を使用して識別し、プルされます。
docker pull 111122223333.dkr.ecr.region.amazonaws.com/repository-name:tag
プライベートレジストリのリポジトリでは、イメージをプルする前に、前述のようにレジストリでクライアントを認証する必要があります。パブリックレジストリでは、認証の有無にかかわらずイメージをプルできます。
知識のチェック
これで、Amazon ECS と AWS Fargate 入門であるモジュール 1 を完了しました。以下のテストでは、これまでに学んだことを確認できます。
問題 1: Amazon Elastic Container Registry とは?
a.コンテナイメージを保存するためのレジストリ
b.実行中のコンテナのレジストリ
c.実行中のタスクのレジストリ
d.コンテナにマップされたストレージボリュームのレジストリ
問題 2: Amazon ECS で実行されている Windows と Linux コンテナの永続ストレージオプションは同じでしょうか?
a.正
b.誤
問題 3: ECS に関連して、クラスターとは?
a.実行中のコンテナのインスタンス
b.実行されるコンテナの定義
c.アプリケーションの構成の定義
d.コンピューティングリソースの論理グループ
正解: 1-a、2-b、3-d
まとめ
このモジュールでは、最初にコンテナについて学習しました。コンテナが仮想マシンとどのように異なるか、Docker Linux コンテナとWindows コンテナとの違いなどです。軽量で、標準化されており、持ち運びが簡単で、シームレスに移動でき、より速く出荷でき、費用を節約できます。AWS のコンテナは安全で信頼性が高く、さまざまなコンテナサービスによってサポートされており、AWS と緊密に統合されています。
次に、サーバーレステクノロジについて学びました。サーバーレステクノロジを使用すると、サーバーについて考えることなくアプリケーションを構築できます。利点としては、運用上のオーバーヘッドの排除、自動スケーリング、コストの削減、他の AWS サービスとの組み込み統合によるアプリケーションのより簡単な構築などがあります。ユースケースは、ウェブアプリケーション、データ処理、バッチ処理、イベント取り込みです。
コンテナ用の AWS コンピューティングサービスと、コンピューティングサービスの選択方法について学びました。AWS App Runner は、コンテナをホストするためのフルマネージドサービスであり、サーバーレスでもあることを学びました。