※GCPアカウントの作成、プロジェクト作成、課金有効化、Cloud SDKのインストールなどは完了している前提で進める
シリーズ構成
【Cloud Runでサクッとサービスをデプロイ】Part1:導入
【Cloud Runでサクッとサービスをデプロイ】Part2:アプリケーションの手動デプロイ
【Cloud Runでサクッとサービスをデプロイ】Part3:CI/CDパイプライン構築
【Cloud Runでサクッとサービスをデプロイ】Part4:DB(Cloud Sql)と接続
概要
Google Cloud RunはHTTPリクエストに応じてステートレスなDockerコンテナをサーバレス環境で実行できるサービス(Pub/Sub イベント経由でも可)
イメージ図
最終的なゴールは以下の図の通り
.png?w=7071&h=3412)
特徴
サーバーレス
インフラストラクチャ管理が一切不要
マネージドサービス
インスタンスの CPU 使用率に基づいて自動スケーリング
カスタムドメイン
簡単に設定可能
DBとの連携
任意のCloud SQLインスタンスに簡単に接続可能
コンテナイメージの保存場所
Cloud Runを用いたデプロイに使用するイメージはContainer/Artifact Registryに保存される
デプロイの方法
Cloud Runでは、コンテナベースでアプリケーションをデプロイするが、Go,Java,Python,Node.js,.Netに関してはDockerfileを用意しなくても使用しているプログラム言語から解釈してデプロイすることが可能。もちろん、オリジナルのDockerfile用意してそれを元にコンテナをビルドすることも可能。
デプロイの頻度
単発 or 継続的なデプロイを選択できる。前者の場合はCLIや GCPコンソール上で、後者の場合はGithubなどのソース管理サービスとCloud Buildを使用してCI/CDパイプラインを構築する。Cloud Buildによる継続的デプロイを使用すると、ソースリポジトリに対する変更をトリガーにRegistryへコンテナイメージが自動的にpushされ、Cloud Run にデプロイされる
サービス
Cloud Runを用いてデプロイされたアプリケーションは、サービスという単位で管理され、固有のエンドポイントを公開する(デプロイ後にurlが発行される)。同一プロジェクトのサービス名は、リージョン内でユニークである必要があるので注意
料金
使用したリソース(100 ミリ秒単位で実行した時間)に対して課金される。
リクエストの処理中にのみ CPU を割り当てる としている場合、基本的にはリクエストを処理してる間しか課金は発生しない。ただし、最小インスタンス数を指定した場合はリクエストを処理していなくてもアイドル状態(リクエストを処理していない待機中の場合)で起動していることになるので、コストが発生する(=最小インスタンスではないアイドル状態のインスタンスは課金されない)
ちなみに1台アイドル状態にしておくと、1ヶ月に1000円弱ほどかかるらしい
デプロイを試す
これが最もシンプルで簡単な方法。サンプルのコンテナを手動でデプロイする
サービス作成
GCPコンソールからCloud Runを開きサービスを作成をクリック

サンプルコンテナでテストをクリックする

自動でサービス名やイメージのurl(us-docker.pkg.dev/cloudrun/container/hello)などがセットされるので、続けてリージョンを選択する

CPUの割り当てと料金はリクエストの処理中のみ(常にを選択すると、リクエストが無い時間帯でも料金計算の対象となるので注意)、自動スケーリングは0:1、Ingressの制御はすベて、認証は未認証の呼び出しを許可を選択しておく。
ちなみに、Ingressで内部と指定すればCloud Load Balancingと組み合わせることでアプリケーションへのアクセスに対してIP制限をかけたりすることができる。また、認証を必要とし、Cloud IAMを使用することで承認済みユーザーだけがアクセス可能といったアクセス制御も可能

他にもコンテナやネットワーク、セキュリティについて細かく設定できるがオプションなので特に指定しない。なお、Cloud Run はブロジェクトのVPC に属しないため、VPC 上のリソースにアクセスする場合や、外部への通信を VPC 経由に変更したい場合は別途コネクタが必要となる(App Engine、Cloud Functions などのサーバーレス環境からの場合と同様。任意のネットワークに対して)
作成ボタンをクリックし数秒待つと、サービスがデプロイされ、アプリケーションのurlが生成される。

最後にurlをクリックし、goで作成されたサービスが開きこのようなウェルカムページが表示されていればOK

クリーンアップ
不要になったサービスはサービス一覧の削除ボタンから削除可能

まとめ
いかがでしたでしょうか。本記事では、【Cloud Runでサクッとサービスをデプロイ】シリーズのPart1として、Cloud Runやシリーズのゴール、アーキテクチャ図、特徴や課金ルール、サンプルのコンテナをデプロイする方法など導入の説明を行いました。