はじめに
クラウドインテグレーション部の髙橋です。
本記事は『コンテナ入門 前編：コンテナとは何者か？ コンテナの概要』の続きです。
クラウドにおけるコンテナ、コンテナを使用する各クラウドサービスについてざっくり説明していきます。
各クラウドのコンテナサービスやKubernetesサービスについてざっくり知りたい方はぜひ参考にしていただけたらと思います。
なぜコンテナ化するのか
前提として、コンテナ技術を利用することが目的ではないです。
コンテナ化をすることで、以下のようなメリットがあります。
- 高い可搬性
- 異なる環境へ直ぐにデプロイできるため、クラウドへの移行がしやすい
- より迅速なデプロイの実現
- 開発サイクルを高速化できる
これらによって、オンプレミスにあったものからクラウド化へ繋げやすくなります。
各クラウドのコンテナサービス
3大クラウド(AWS,Azure,Google Cloud)それぞれにコンテナサービスがあります。そちらについて紹介していきます。
Amazon Elastic Container Service
Dockerコンテナを管理するサービスです。Amazon ECSと省略されて呼ばれたりします。
特徴としては以下が挙げられます。
- シンプルだが、非常にパワフル
- スケーリングや機能などを犠牲にすることなく、非常にスムーズに利用可能
- アプリケーションの構築、導入にかかる時間を短縮できる
- 「EC2」と「Fargate」の2つの起動タイプ
- EC2タイプはカスタマイズ性に優れる
- Fargateタイプはインスタンス管理が不要
- 拡張性
- 水平スケーリング、垂直スケーリングが可能
AWS Fargate
Amazon ECSや後述するEKSで利用するコンテナ環境の運用自動化サービスです。
以下のような特徴があります。
- サーバーレス
- インスタンスのOSやDocker Agent、ミドルウェアなどの構築や設定操作の手間が省ける
- 実行時に必要なCPUやメモリの設定だけで構築できる
Azure Container Instances
サーバーレスでコンテナを実行するサービスです。ACIと呼ばれたりします。
以下のような特徴があります。
- 素早い起動が可能
- 数秒で起動し、稼働した秒単位で課金がされる
- コンテナオーケストレーションや自動スケーリング機能なし
- Azure Kubernetes Service (AKS)と連携させることでロードバランシングはできる
- 直接アクセスが可能
- コンテナ単位でPublic IP、DNSが提供される
Google Cloud Run
こちらもサーバレスのコンテナ実行環境です。
- フルマネージド
- インフラストラクチャの管理が不要
- アプリケーションの移行が簡単
- Knative が基盤
- アプリケーションの移植が可能
- 高速な自動スケーリングが可能
- 最小インスタンスを「0」にでき、アクセスが来たらインスタンスを起動することができる
- 起動時間を削減し、コストを下げられる
比較
以下は、マネージドサービスを比較した表です。（2024/3時点）
Google Cloud RunのCPUとメモリが高額になっていますが、毎月無料枠があります。
可用性は、AWS > Google Cloud > Azureの順で高く、AWSとAzureの年間停止時間にはおよそ８時間ほど差があります。
各クラウドのレジストリサービス
コンテナイメージを保存するレジストリサービスを紹介します。
Amazon Elastic Container Registry
AWSのコンテナレジストリであり、省略してECRと呼ぶことが多いです。
以下のような特徴があります。
- フルマネージド
- 運用・管理などが不要
- 高可用性と耐久性
- コンテナイメージはAmazon S3に保存
- セキュア
- コンテナイメージがHTTPS経由で転送
- 保管時にイメージが自動的に暗号化
- シンプルなワークフロー
- Amazon ECSとDocker CLIに統合されている
- 開発から本稼働までのワークフローを簡略化できる
Azure Container Registry
Azureのコンテナレジストリです。
以下のような特徴があります。
- フルマネージド
- 運用・管理などが不要
- セキュア
- コンテナイメージがHTTPS経由で転送
- 保管時はイメージが自動的に暗号化
- 統合セキュリティ
- Azure ADをネイティブにサポートする
Google Artifact Registry
Google Cloudの発展型レジストリです。
- フルマネージド
- 運用・管理などが不要
- セキュア
- コンテナイメージがHTTPS経由で転送
- 保管時はイメージが自動的に暗号化
- マルチコンテンツのレジストリ
- コンテナイメージ以外のもの(言語・OSパッケージ)を管理できる
比較
以下は料金の比較です。（2024/3時点）
Azureのみ料金システムが特殊で、サービスを利用すると別途レジストリ料金が発生します。
その分、最も安いプラン(Basic)では10GBのストレージが付属するので、超過しなければストレージ料金はかかりません。
Kubernetesとは
各クラウドのサービスを紹介する前に、Kubernetesがどのようなサービスなのか紹介します。
Kubernetesは、Googleが2014年頃公開したコンテナオーケストレーションツール(コンテナを管理するツール)です。
「クバネティス」「クーベネティス」「K8s」などの呼び方があります。
Kubernetesを使うことで以下を実現でき、より効率的にコンテナ管理を実施できます。
- 負荷分散
- アクセスの振り分けを行う
- コンテナ間通信
- コンテナ間のネットワークを管理する
- 自動スケーリング
- コンテナの負荷からノードの増減を行う
- 複数ホストでのコンテナ管理
- 下の図のように、複数のホストマシンに跨ったコンテナ管理が可能
- コンテナ監視
- 障害発生などを検知する
各クラウドのKubernetesサービス
各クラウドが提供するKubernetesサービスについて紹介していきます。
Amazon Elastic Kubernetes Service
KubernetesをAWS上で簡単に実行できるようにした、マネージドサービスです。EKSと略されます。
以下のような特徴があります。
- 高可用性
- 複数のAZ（アベイラビリティーゾーン）でKubernetes管理インフラを実行
- 問題が発生した場合は、問題が発生したノードを自動的に検出、置換
- マネージドインフラ
- Kubernetes管理インフラの自動アップグレード
- 「EC2」と「Fargate」タイプを選択可能
Azure Kubernetes Service
Azure上で Kubernetesクラスタの構築・管理を行うサービスです。AKSと略されます。
以下のような特徴があります。
- 運用効率の向上
- 監視・スケーリング・クラスタの作成などの自動化
- 運用管理のオーバーヘッドを大幅に削減
- 優れた拡張性
- Kubernetes を使用して、コンテナの計算能力を数秒で柔軟に増減できる
- 認証基盤連携
- Azure ADとの優れた連携が可能
Google Kubernetes Engine
Kubernetesをベースとしたコンテナ マネージドサービスです。GKEと略されます。
- 頻繁な自動アップデート
- KubernetesはGoogleが開発
- 早い段階でアップデートに対応
- 運用負荷の軽減
- GKE Autopilotを利用することでノードの管理（作成・更新・削除・バージョン管理等）が不要
- コミュニティの充実
- イベントやミートアップの定期開催
比較
それぞれのサービスを比較すると以下の表のようになります。（2024/3時点）
Azure Kubernetes Serviceでは、開発・テスト用クラスタが無料で利用できます。
各サービスのデモ
コンテナサービスのデモとして、Amazon Elastic Container ServiceとAzure Container Instances、
KubernetesのデモとしてGoogle Kubernetes Engineを使ってWebサーバーを立てていきます。
Amazon Elastic Container Service
このような構成で作成します。
ECS on Fargateでコンテナを立てます。ALBも作成し、二つのサブネットにあるコンテナにアクセスを振り分ける形にします。
まずはタスク定義から作成していきます。タスク定義とは、コンテナグループ管理のための要件定義のようなものです。タスク定義では、コンテナのCPUやメモリのサイズ、コンテナイメージなどの選択をします。
AWSコンソールに入り、ECSコンソール > タスク定義 > 新しいタスク定義の作成を選択します。
任意のタスク定義ファミリー名を入力し、インフラストラクチャの要件からAWS Fargateを選択します。
次に、コンテナイメージとポートの定義です。任意のコンテナ名とコンテナイメージを選びます。今回はNginxにします。ポートは、後ほどブラウザで確認するので80番とします。作成ボタンを押して作成します。
残りはデフォルトのままで、作成ボタンを押します。
次にクラスタを作成します。クラスタとは、タスクや後述する「サービス」の論理グループのことで、タスクやサービスを実行する基盤となるものです。
任意のクラスタ名を指定します。デフォルトでは名前空間もクラスタ名と同名になります。
インフラストラクチャはAWS Fargate(サーバーレス)を選択します。
その他はデフォルトのままで、作成します。
クラスタが完成したら、サービスの作成をします。
サービスとは、タスク定義を基に作成されるリソース群のことで、タスクの管理を行うものです。作成ボタンを押します。
コンピューティングオプションから起動タイプ、起動タイプからFARGATEを選択します。
デプロイ設定では、サービスを選択します。
ちなみにタスクを選択した場合は、サービスを使わずにタスクを立てることができます。
ファミリー名は、先ほどタスク定義で作成したものを選択します。任意のサービス名をつけます。
ネットワーキングの設定から、VPCとサブネット、セキュリティグループを選択します。ブラウザからアクセスできるように80ポートでインバウンドを設定しておきます。
ロードバランサーの作成もここで行います。Applicaton Load Balancerを選択し、コンテナは先ほど作成したものを選択します。 任意のロードバランサー名もつけます。
ターゲットグループもここで作成します。任意のターゲットグループをつけます。
ここまで設定ができたら、他はデフォルトで作成します。
2,3分後に作成が完了するので、ALBのDNSからアクセスしてみます。
ブラウザにDNSを入力すると、Nginxのデフォルトページが表示されました！これにて、AWSのデモを完了とします。
Azure Container Instances
Azure Container Instancesでは以下のような構成で作っていきます。
リソースグループ(仮想マシンやストレージなどのAzureリソースをグループ化したもの)を作成し、そこにAzure Container Instancesでコンテナを作成していきます。
まず、Azureコンソールに入り、リソースグループを選択します。
作成を選択します。
任意のリソースグループ名を入力します。
作成前に検証を行ってくれます。問題ないのでこのまま作成します。
続いて、Azure Container Instancesでコンテナを作成します。
リソースグループは先ほど作成したものを指定します。コンテナ名は任意のものを入力します。Availability Zonesの追加で可用性を高めることはできますが、今回はNoneのままいきます。
クイックスタートイメージ(Azureが用意しているイメージ)をイメージとして指定します。今回は簡単なWEBページを表示するものを利用します。
ネットワークの設定をします。ブラウザからアクセスしたいので、パブリックを選択します。
DNS名ラベルは任意のものを書きます。 DNS名ラベルは、コンテナに割り当てられるサブドメインのことです。
Azureではリソース作成時に、問題なく作成できるか検証を行ってくれます。検証に成功したので、作成します。
デプロイが完了しました。
コンテナにIPとFQDNが割り当てられています。これらから直接コンテナにアクセスできます。
FQDNをブラウザに入力した結果、ページが表示されました！
Google Kubernetes Engine
Google Cloudのデモは以下のような構成で作成します。
GKEクラスタ、クラスタ内のPod(Kubernetesでデプロイできる最小のオブジェクト)、ロードバランサーを作成します。ロードバランサーから簡単なWebページにアクセスできるものとなっています。
構築の流れとしては、以下のように進めていきます。
- Google Artifact Registryにコンテナイメージを保存
- GKEクラスタの作成
- ワークロード(クラスタ内を管理するリソース)の作成
参考チュートリアル:アプリを GKE クラスタにデプロイする
まず、Google CloudのコンソールからCloud Shellを選択します。
Google Artifact Registryにコンテナイメージを保存
プロジェクトIDとリージョンの変数を作成しておきます。
export PROJECT_ID=(プロジェクトID)
export REGION=asia-northeast1
Google Artifact Registryのリポジトリを作成します。
gcloud artifacts repositories create hello-repo \
--repository-format=docker \
--location=asia-northeast1 \
--description="Docker repository"
今回使うサンプルのDockerfileをインストールします。
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
Dockerfileの階層に移動します。
cd kubernetes-engine-samples/quickstarts/hello-app
ビルドしていきます。
docker build -t ${REGION}-docker.pkg.dev/${PROJECT_ID}/hello-repo/hello-app:v1 .
Google Artifact Registryを有効化しておきます。
gcloud services enable artifactregistry.googleapis.com
作成したイメージをGoogle Artifact Registryにプッシュします。
docker push ${REGION}-docker.pkg.dev/${PROJECT_ID}/hello-repo/hello-app:v1
Google Artifact Registryの画面でプッシュしたイメージが確認できます。
GKEクラスタの作成
ここからはGoogle Cloud コンソールで操作していきます。GKEクラスタを作成からクラスタを作成していきます。任意のクラスタ名とイメージを保存したリージョンを選択します。
クラスタ内のPodアドレス範囲なども設定できますが、今回はデフォルトで作成します。
ワークロードの作成
ワークロード>デプロイからワークロードを作成していきます。
コンテナのイメージから既存のコンテナイメージを選択し、Google Artifact Registryにプッシュしたイメージを選択します。
Deployment名からワークロードの名前をつけます。
クラスタは先ほど作成したものを使います。
構成YAMLでは、今回の行った操作をYAML形式で定義されています。
このYAMLファイルから同じワークロードをデプロイすることができます。
ブラウザからアクセスしたいので、8080ポートをターゲットとしておきます。
また、サービスタイプでロードバランサを選択します。これでロードバランサーの作成も自動で行ってくれます。
ここまでできたら、作成します。
作成が完了したら、Podを確認します。マネージドPodが3つできていますが、この中でコンテナが起動しています。
では、ロードバランサーのエンドポイントからブラウザでアクセスしてみます。
ページが問題なく表示されました。
まとめ
前後編を通して、仮想化、コンテナ、クラウドサービスについて紹介してきました。 今後、さらに仮想化やコンテナの利用が活発化していくと考えられるので、本記事で紹介したことが少しでも参考になればと思います。
