Cloud Run でマルチコンテナが利用可能になったのでマニフェストサンプルを添えて機能を紹介
はじめに
こんにちは。クラウドエース株式会社で SRE をしている間瀬です。
Zenn でのブログ投稿は初めてとなりますが、よろしくお願いします。
本記事にてご紹介する内容は、2023/5/16に Public Preview となった Google Cloud のサービスとなる Cloud Run のマルチコンテナデプロイについてです。
Cloud Runについて
既にご存知の方も多いと思いますが、Cloud Run というサービスについて簡単に触れさせていただきます。
Cloud Run は Google Cloud が提供する Knative ベースのコンテナ実行環境サービスです。
利用者が Kubernetes や VM マシンといったインフラストラクチャを管理しないサーバレスな形態でコンテナアプリケーションを運用することができます。
弊社でも多くの導入実績があり、中小規模のアプリケーションから大規模まで幅広いユースケースで採用されています。
私自身は Kubernetes のファンで Kubernetes クラスタを使った開発や本番運用もしてきましたが、Cloud Run を利用すると Kubernetes と比べて設計するポイントが少ないのにも関わらず、スケーラビリティに優れており、開発容易性、拡張性の高さに驚かされました。
また、課金については CPU ,メモリ、リクエスト数に応じた従量課金となっており、スモールスタートもしやすい方式となっています。
マルチコンテナについて
マルチコンテナは一つのインスタンスに対して複数のコンテナをデプロイすることで、１つのインスタンス内で実行されるアプリケーションの処理を複数のコンテナで担うことができます。
アプリケーションの処理を複数のコンテナに分離することで、コンテナのメリットである可搬性や分離性を活かしたアーキテクチャを実現することができます。
メリットをもう少し具体的に説明すると、例えばアプリケーション処理の中核を担うビジネスロジックを個別のコンテナとして実装して、ビジネスロジック間で横断的な関心事となる認証/認可やストレージへのファイル転送、インタフェースの変換といった処理を個別のコンテナとして実装することによる処理の共通化や各共通処理をそれぞれ異なる言語で実装できるようなメリットがあります。
マルチコンテナの実行環境としては多くのケースでは Kubernetes を利用する必要があり、マルチコンテナを前提としたプロダクトの例としては Istio のようなサービスメッシュが挙げられます。
Cloud Runでのマルチコンテナデプロイ
Cloud Run でのマルチコンテナデプロイ方法について簡単に検証したので紹介したいと思います。
Cloud Run をデプロイする際には Google Cloud コンソール、gcloud コマンドといった複数の方法がありますが、マルチコンテナをデプロイする場合は YAML ファイルを作成して gcloud コマンドを実行する必要があります。
YAMLの記載例は以下の通りです。
Cloud Run のエンドポイントとして公開できるポート(ingressポート)は1つだけになるため、エンドポイントでリクエストを受け付けるコンテナに対して ports を設定するようにしてください。
ingress ポートを指定しなかったコンテナは localhost:port にてアクセスが可能です。
- cloud-run.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: demo-sidecar-app
labels:
cloud.googleapis.com/location: asia-northeast1
annotations:
run.googleapis.com/launch-stage: BETA
spec:
template:
metadata:
annotations:
run.googleapis.com/execution-environment: gen2
spec:
containerConcurrency: 80
timeoutSeconds: 30
containers:
- image: asia-northeast1-docker.pkg.dev/${YOUR_PROJECT_ID}/${YOUR_ARTIFACT_REGISTRY}/demo-sidecar-app:v0.0.1 #containerA
ports: #ingressポート
containerPort: 8080
resources:
limits:
cpu: 1000m
memory: 256Mi
- image: asia-northeast1-docker.pkg.dev/${YOUR_PROJECT_ID}/${YOUR_ARTIFACT_REGISTRY}/demo-sidecar-app:v0.0.1 #containerB
resources:
limits:
cpu: 1000m
memory: 256Mi
traffic:
- percent: 100
latestRevision: true
上記ファイル作成後、以下のコマンドを実行することで Cloud Run のサービスとしてデプロイすることが可能です。
※ gcloud の初期化ができていなければ gcloud init コマンドからアカウント認証を行なってください。
※ YAML ファイルを修正して再デプロイする際も同じコマンドを使用してください。
gcloud run services replace cloud-run.yaml --project=${YOUR_PROJECT_ID}
デプロイ成功時には以下のようなコマンド結果が表示されます。
Applying new configuration to Cloud Run service [demo-sidecar-app] in project [xxxxxxxxxxxx] region [asia-northeast1]
✓ Deploying... Done.
✓ Creating Revision...
✓ Routing traffic...
Done.
New configuration has been applied to service [demo-sidecar-app].
Google Cloud コンソールより Cloud Run のコンソール画面に記載されているURLよりアクセスが可能です。
curl コマンドやブラウザよりアクセスができるかと思います。
上記で掲載している YAML ファイルやサンプルアプリケーションは以下の GitHub リポジトリより取得できます。
その他Cloud Runが提供するマルチコンテナ関連機能
コンテナの開始順序の制御
マルチコンテナをデプロイする場合、コンテナ間で依存関係が発生するケースがあります。
例えば、DBへ接続するためのプロキシコンテナとこれ以外の DB を利用した業務処理を担うコンテナが存在する場合において業務処理を担うコンテナアプリケーションの起動時において DB との接続処理が実装されている場合、本コンテナ起動時にはプロキシコンテナが起動していて DB と接続できる状態である必要があります。
このようなケースで本機能を利用することでコンテナの開始順序を制御することが可能です。
本機能を利用するには以下のように YAML ファイル上にアノテーションとして依存関係を定義します。
また、 Cloud Run ではコンテナ別にヘルスチェックとなるプローブを設定することで、依存先のコンテナに対してヘルスチェックが有効になってから次のコンテナを起動させることが可能です。
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: demo-sidecar-app
labels:
cloud.googleapis.com/location: asia-northeast1
annotations:
run.googleapis.com/launch-stage: BETA
spec:
template:
metadata:
annotations:
run.googleapis.com/execution-environment: gen2
run.googleapis.com/container-dependencies: "{proxy-app:[backend-app]}" # コンテナの依存関係をコンテナ名で定義 backend起動してからproxy-appを起動する。
spec:
containerConcurrency: 80
timeoutSeconds: 30
containers:
- image: APPLICATION_IMAGE
name: proxy-app # コンテナ名
startupProbe: # ヘルスチェック
httpGet:
path: /
port: 8080
ports:
containerPort: 8080
- image: DB_PROXY_IMAGE
name: backend-app # コンテナ名
startupProbe: # ヘルスチェック
httpGet:
path: /backend
port: 8090
まとめ
繰返しにはなりますが、今回紹介した機能は記事執筆時点では Public Preview になります。
これまでマルチコンテナアーキテクチャを採用するケースでは Cloud Run の利用を見送る必要がありましたが、本機能によって選択できるケースが増えるかと思いますので利用してみてください。
Discussion