2023年は「Cloud Run を触って覚える」をテーマとした一人アドベントカレンダーを一人で開催しており、Cloud Run のさまざまな機能や、Cloud Run でよく使う構成などを実際の使い方と一緒にご紹介しています。
5日目は Cloud Run サービスのデプロイのよくあるパターンについてご紹介します。
Cloud Run の概要は技術評論社さまのブログ「gihyo.jp」に寄稿した記事で解説していますのでこちらもぜひご覧ください。
Cloud Run サービスのデプロイの基本的な流れと構成要素
別な記事でデプロイの基本的な流れと構成要素について解説しました。これらの要素が前提となるので、まだご覧になっていない場合はこちらの記事を読んでから読み進めてください。
構成要素としては次のようになります。
- ソースコード リポジトリ (Git リポジトリ)
- ビルド環境
- コンテナ レジストリ
Cloud Run サービスのデプロイのパターン 3 選
Cloud Run サービスのデプロイのパターンをいくつかご紹介します。
コマンド1発でデプロイするパターン - gcloud run deploy
gcloud コマンドでデプロイする、非常にクイックにデプロイできる方法です。
$ gcloud run deploy
このコマンドだけでソースコードを Zip ファイルに圧縮して Cloud Storage バケットにアップロード、Cloud Build の環境構築も自動的に作られます。Cloud Build 内では Zip ファイルをダウンロードして Artifact Registry に Push、Cloud Run サービスへのデプロイを実行します。
また通常のコンテナ アプリケーションをデプロイする場合は Dockerfile を必要としますが、Dockerfile を用意していない場合でもデプロイが可能です。Buildpack というツールが自動的にソースコードから使用されているプログラミング言語を検出し、安全なベースイメージからコンテナ イメージをビルドします。
gcloud run deploy コマンドはオプションが指定されていない場合はどのような Cloud Run サービスを作るか対話形式で設定でき、Cloud Run サービスも予め作成していない場合でも作成とデプロイが同時に行えます。設定できるオプションは、次のドキュメントで確認してください。
Google Cloud で CI/CD するパターン
CI/CD 環境を Google Cloud で構築するパターンです。
ソースコード リポジトリはスタンダードな Git リポジトリのホスティングサービスである GitHub を使い、CI/CD 環境はサーバーレス CI/CD プラットフォームである Cloud Build を使います。Cloud Build ではコンテナ イメージをビルドし、コンテナ レジストリのサービスの Artifact Registry に Push します。Cloud Build の次のステップとして Cloud Run サービスへのデプロイコマンドを実行します。Cloud Run サービスは Artifact Registry に置かれているコンテナ イメージをダウンロードし、必要に応じてコンテナ インスタンスを起動します。
また、この派生としてソースコード リポジトリに Cloud Source Repositories を採用するパターンもあります。この構成にすることで、Google Cloud 内で全て完結させることができます。
ソースコードの保管する環境と参照する環境を狭めたい (なるべくサービス間でアップロード・ダウンロードさせたくない) 場合や、などに取られるパターンです。しかし Cloud Souce Repositories の機能はシンプルなソースコード管理のみになるため、例えば GitHub で課題管理の機能 (Issue や Project) を使っている場合は Cloud Source Repositories 単体では実現が難しい面もあります。
GitHub フル活用パターン
ソースコード リポジトリのホスティングや CI/CD サービスを提供している GitHub にできるかぎり寄せたパターンです。CI/CD のためのサービスである GitHub Actions を使うと、Cloud Build と同様にコンテナ イメージのビルドやコンテナ レジストリへの Push、Cloud Run のデプロイの実行などが行えます。
ソースコードの保管場所 (ソースコード リポジトリ) と CI/CD で使うサービスが社内標準で決められている企業は比較的多いと思います。そのような場合は ソースコード リポジトリと CI/CD までは社内標準を使い、コンテナ レジストリと Cloud Run サービスは Google Cloud に寄せるなどといった分け方がおすすめです。
このような分け方は、例えば GitHub ではなく GitLab を採用したい場合なども同様になります。
デプロイ構成を拡張する
上記の構成に加え、Google Cloud ではデプロイ時に役立つ便利なサービスを提供しています。それらのサービスを併用することで、デプロイ構成を拡張していくことができます。
ここでは、そのサービスの概要とデプロイ時に役立つポイントを紹介します。
Cloud Deploy
Cloud Deploy はデプロイ パイプラインを管理・実施することができるサービスです。
Cloud Run サービスをプロダクション環境で運用することを考えた場合、複数の環境 (例 : 開発環境 / ステージング環境 / 本番環境) を用意し、それらに対してデプロイすることになると思います。Cloud Deploy ではこのような複数の環境に対するコンテナ アプリケーションのデプロイのパイプラインを一括で管理することができます。
Cloud Workstations
Cloud Workstations は開発環境をクラウド化するためのサービスです。
開発環境をクラウド上にコンテナ インスタンスとして起動し、ブラウザから IDE (例えば VS Code の OSS 版である Code OSS) を開いてアプリケーション開発を行うことができます。ブラウザのみならず VS Code や IntelliJ IDEA などの IDE からのリモート接続もサポートしているので、ビルドやテストの実行のみに Cloud Workstations を使用することもできます。
立ち上がるコンテナは Dockerfile で定義できるので、開発チーム内で必ずインストールしているソフトウェアなどを共通化することができます。新しい開発メンバーが参加する場合もコンテナ インスタンスを立ち上げるだけで環境が準備できるので、オンボーディングを迅速に行うことができます。
Software Delivery Shield
Software Delivery Shield はアプリケーションを開発やビルド、テスト、デプロイといった一連のパイプラインに対してのセキュリティ体制を強化するためのソリューションです。
今回ご紹介したような構成要素に対して、脆弱性を診断したり SLSA によるセキュリティ体制の成熟度を評価するような機能を拡張することができます。
アプリケーション開発において高度なセキュリティ要件が求められる場合に、非常に有用です。
まとめ
Cloud Run サービスをデプロイする上でのいくつかのパターンをご紹介しました。
本番環境を想定すると CI/CD が組める構成がスタンダードですが、クイックに試したい場合や使用するサービスを最小限に留めたい場合などには gcloud run deploy のようにシンプルに1発デプロイする方法も非常に便利です。
Discussion