コンテナ イメージをデプロイする
Cloud Run には、複数のデプロイ オプションがあります。どのデプロイ オプションを選択しても、Cloud Run のフルマネージドでスケーラビリティの高いインフラストラクチャで Cloud Run のサービス、ジョブまたはワーカープールとして実行されるコンテナ イメージが作成されます。
デプロイ可能なコンテナ イメージ
Cloud Run のコンテナ ランタイムの契約に準拠するコンテナ イメージは、Cloud Run のサービス、ジョブまたはワーカープールにデプロイできます。
ソースコードからデプロイする
利便性を考慮し、Cloud Run では 1 つのコマンドからソースコードをビルドしてデプロイできます。詳細については、ソースコードからサービスをデプロイするとソースコードからワーカープールをデプロイするをご覧ください。
ソースコードからデプロイすると、Cloud Build はコードを Artifact Registry に保存されているコンテナ イメージに変換します。Dockerfile を含むソースコード、またはサポートされている言語ランタイムのいずれかを使用するソースコードをデプロイできます。
関数
クラウド インフラストラクチャやサービスで発生したイベントに応答する単一目的のファンクションをデプロイできます。監視対象イベントが発生すると、Cloud Run によって関数がトリガーされます。
ファンクションのデプロイは特殊なタイプのソースコード デプロイで、ファンクション コードのみを提供する必要があります。Cloud Run functions は、さまざまなサポート対象のプログラミング言語を使用して作成できます。
関数をデプロイすると、Cloud Run サービスが作成されます。
git からの継続的ソースコード デプロイ
Cloud Run を使用すると、Git からの継続的デプロイを構成できます。ソースデプロイと同様に、Dockerfile を含むソース、またはサポートされている言語ランタイムのいずれかで記述されたソースコードをデプロイできます。
Git からの継続的デプロイは、Cloud Run サービスで利用できます。Cloud Build で Cloud Run ジョブ用に手動で構成できます。
Cloud Run サービス
サービスは Cloud Run のメインリソースの一つです。各サービスは特定の Google Cloud リージョンにあります。冗長性とフェイルオーバーを実現するため、Cloud Run はリージョン内の複数のゾーンにサービスを自動的に複製します。1 つの Google Cloud プロジェクトで、複数のリージョンの多くのサービスを実行できます。
各サービスは固有のエンドポイントを公開します。デフォルトでは、Cloud Run は受信リクエストを処理するために自動スケーリングを行います。必要に応じて、スケーリング動作を手動スケーリングに変更できます。サービスは、コンテナ、リポジトリ、ソースコードからデプロイできます。
次の図は、サービスの Cloud Run リソースモデルを示しています。
この図に示すのは、3 つの Cloud Run サービス（Service A、Service B、Service C）を含む Google Cloud プロジェクトです。各サービスには複数のリビジョンがあります。
Service A は複数のリクエストを受信しているため、Cloud Run は負荷を処理するために複数のインスタンスを起動しています。これらのインスタンスはそれぞれ、1 つのコンテナ（アプリケーションのコンテナ）のみを実行します。
Service B にリクエストがないため、アイドル状態になり、Cloud Run はアプリケーションのコピーを実行していません。
Service C にはリクエストがあり、複数のインスタンスを作成して負荷を処理するようにスケーリングされています。各インスタンスには複数のコンテナが含まれ、独立したセットとして機能します。各セットでは、Ingress コンテナのみがリクエストを受信しますが、他のコンテナがリクエストの処理を支援します。
Cloud Run サービスのリビジョン
サービスをデプロイするたびに、リビジョンが作成されます。リビジョンは、環境変数、メモリ上限、リクエストの同時実行の値などの構成の設定と、1 つ以上のコンテナ イメージで構成されます。
作成後にリビジョンを変更することはできません。たとえば、コンテナ イメージを新しいサービスにデプロイすると、Cloud Run によって最初のリビジョンが作成されます。その後、同じサービスに別のコンテナ イメージをデプロイすると、Cloud Run によって 2 番目のリビジョンが作成されます。その後で環境変数を設定すると、Cloud Run は 3 番目のリビジョンを作成します。時間が経つと古いリビジョンは Cloud Run によって削除されます。
Cloud Run は、リクエストを最新で正常な状態のリビジョンに自動的にルーティングします。
Cloud Run サービスのインスタンス
Cloud Run は、リクエストを受信する各サービス リビジョンを、受信したすべてのリクエストを処理するために必要なインスタンス数に自動的にスケールします。インスタンスは同時に多くのリクエストを受信できます。リクエストの同時実行の設定を使用すると、リビジョンの各インスタンスに同時に送信されるリクエストの最大数を設定できます。
Cloud Run ジョブ
各ジョブは特定の Google Cloud リージョンに配置され、1 つ以上のジョブタスクで構成されます。これらのタスクは、1 つ以上のコンテナを完了まで実行します。ジョブタスクは独立しており、特定のジョブ実行で並列に実行できます。
Cloud Run ジョブ実行
ジョブが実行されると、すべてのジョブタスクを開始するジョブ実行が作成されます。ジョブ実行を成功させるには、ジョブ実行のすべてのタスクが正常に完了する必要があります。タスクのタイムアウトを設定し、タスクが失敗した場合の再試行回数を指定できます。
いずれかのタスクで再試行の最大数を超えると、Cloud Run はそのタスクを「失敗」、ジョブを「失敗」とマークします。デフォルトでは、タスクは最大 100 件まで並行して実行されますが、データベースなどのバッキング リソースで必要な場合は最大値を小さくできます。
Cloud Run ジョブタスク
すべてのジョブ実行において多くのタスクが並行して実行され、各タスクは 1 つのインスタンスを実行します。Cloud Run は、maxRetries のジョブの構成に応じて、失敗したタスクを自動的に再実行しようとします。
Cloud Run ワーカープール
ワーカープールは、pull キューなどのリクエスト以外のワークロード用に特別に設計された Cloud Run リソースです。ワーカープールには次の機能がないことに注意してください。
- エンドポイントまたは URL がない
- デプロイされたコンテナは、ポートでリクエストをリッスンする必要がない
- 自動スケーリングがない
Cloud Run サービスと同様に、ワーカー プールをデプロイまたは更新すると、新しいリビジョンが作成されます。
ワーカープール インスタンスは、必要に応じて手動でスケールして、ワークロードに十分なインスタンスをスケールできます。ただし、必要に応じて独自のオートスケーラーを作成できます。たとえば、Kafka オートスケーラーは、Kafka メッセージキューから受信するワークロードのスケーリングを処理します。