はじめに

こんにちは、AI・IoTサービス開発部の岩丸です。気づけばもうすぐ4月になり入社から丸1年経とうとしています。月日の流れは早いですね。2年目も自分らしく頑張って参ります。

前回はAndroidのJetpack Composeに関する記事を執筆しました。もしお時間ある方は合わせてご覧ください。

tech-blog.optim.co.jp

今回はGCPのCloud Runを遊んでみたいと思います。せっかくなのでCloud Runで使用するイメージのビルドはCloud Build、イメージの保存先にはArtifact Registryをそれぞれ利用してCIOps環境を合わせて構築してみます。

実験したこと

簡単なHello Worldアプリを作成し、Cloud Runの実験を行いました
Cloud Build用のビルド構成ファイルを用意し、Cloud Runへの継続的デプロイ環境を構築しました

Cloud Run とは

Cloud RunはGCPが提供するサーバーレスサービスの1つです。Cloud Run 公式ドキュメントには以下のように説明されています。

Cloud Run はマネージドコンピューティングプラットフォームで、リクエストまたはイベント経由で呼び出し可能なコンテナを実行できます。Cloud Run はサーバーレスです。インフラストラクチャ管理が一切不要なため、最も重要な作業であるアプリケーションの構築に集中できます。

Cloud Runは様々なコンテナイメージに対応しているためコンテナで動く言語であれば大体利用することができます。そのため、Cloud Functionsの利用出来る言語の幅が広がったサービスという風に捉えることもできます。

AWSの似たようなサービスとしてはApp Runnerが挙げられます。App Runnerの詳細は以下で解説しているため、お時間ある方はこちらも合わせてご覧ください。

tech-blog.optim.co.jp

Cloud Build とは

Cloud BuildはGCPが提供するビルド実行サービスです。AWSではAWS CodeBuildが類似サービスにあたります。ビルド実行用のトリガーとして、GitHubやPub/Subトリガーも用意されており様々なサービスと連携することが可能なビルドサービスです。

cloud.google.com

Cloud Build + Cloud Runの実験

今回は以下のステップを実現するCIOps環境を構築してみます。今回は公式のPythonサンプル(Flask API)をCloud Runで動かします。 Cloud Run関連の記事ではContainer Registryにpushしているケースが多いですが、公式が推奨しているのはArtifact Resigtryのため今回はこちらを採用しています。

GitHubのpushをトリガーにしてCloud Buildを実行する
Cloud BuildでビルドしたイメージはArtifact Registryへpushする
Cloud Runへのデプロイを行う

アーキテクチャ図は以下の通りです。最近話題になったGoogle Cloud Architecture DiagrammingToolで作図を行っています。

STEP1: GitHubのリポジトリを作成し、GitHubトリガーを設定する

まずはGitHubでテスト用のリポジトリを作成し、Pythonサンプルを追加します。Pythonサンプルは公式のものを利用します。

次に以下を参照しながらGitHubトリガーの設定を行います。今回は以下のような設定を行いました。

トリガー名：hello-world
イベント：ブランチにpushする
対象ブランチ： main

cloud.google.com

STEP2: Cloud Buildのビルド構成ファイルを作成する

Cloud Buildでビルドを開始するためにはビルド構成ファイルを作成する必要があります。AWS CodeBuildのbuildspec.ymlに該当するものです。 Cloud Buildではcloudbuild.yamlという構成ファイルになります。

cloud.google.com

cloudbuild.yaml

こちらはCloud Runへのデプロイ#継続的デプロイ、Cloud Build を使用した Python の開発をベースに構成ファイルを作成しています。

steps:
  # Docker Build
  - name: "gcr.io/cloud-builders/docker"
    args: ["build", "-t", "${_IMAGE_NAME}", "."]
  # Docker push to Artifact Registry
  - name: "gcr.io/cloud-builders/docker"
    args: ["push", "${_IMAGE_NAME}"]
  # Deploy to Cloud Run
  - name: "gcr.io/google.com/cloudsdktool/cloud-sdk:slim"
    entrypoint: gcloud
    args:
      [
        "run",
        "deploy",
        "${_BASE_NAME}",
        "--image",
        "${_IMAGE_NAME}",
        "--region",
        "us-central1",
        "--platform",
        "managed",
        "--allow-unauthenticated",
      ]

# デフォルトは10分。今回は30分にしてみる
timeout: "1800s"

# ユーザー定義変数
substitutions:
  _SERVICE_NAME: "hello-world"
  _IMAGE_NAME: "us-central1-docker.pkg.dev/${PROJECT_ID}/${TRIGGER_NAME}/${_BASE_NAME}:${SHORT_SHA}"

images:
  - "${_IMAGE_NAME}"

cloudbuild.yamlではPROJECT_IDやTRIGGER_NAMEなどのデフォルトの置換変数だけではなくsubstitutionsとしてユーザ定義変数を設定することが可能です(参照：Cloud Build#変数値の置換)。

今回は_SERVICE_NAME、_IMAGE_NAMEをそれぞれ定義しました。

# ユーザー定義変数
substitutions:
  _SERVICE_NAME: "hello-world"
  _IMAGE_NAME: "us-central1-docker.pkg.dev/${PROJECT_ID}/${TRIGGER_NAME}/${_BASE_NAME}:${SHORT_SHA}"

STEP3: Cloud Buildを実行し、Cloud Runの接続確認を行う

STEP1、STEP2で実行準備が整いました。実際に動かしてみましょう。

STEP1で準備したリポジトリに対してpushを行い、Google Cloud ConsoleでCloud Buildのページを開きます。しばらくするとビルドが完了すると思うので、今度はCloud Runのページを開きます。

Cloud Run側で発行された割り当て済みURLにアクセスし、Hello Worldの文字が表示されたら実験は成功です(よくあるハロワ表示ですね)。

おわりに

今回はGCPのCloud Run、Cloud BuildでCIOpsの実験をして遊んでみました。AWS CodeBuildとビルド構成ファイルの書き方が異なっている部分はありましたが、CIOps環境を構築することが出来ました。

今回の実験ではTerraformを利用していませんが連携するGCPサービスが増えれば増えるほどIaCの実力を発揮します。公式ドキュメントにはTerraform + Cloud Buildのドキュメントが用意されていますので、機会があればこちらも実験してみたいと思います。

OPTiMではGCPに限らずAWS、Azureに挑戦したいエンジニアを随時募集しております。少しでもご興味のある方はこちらをどうぞご覧ください。

OPTiM TECH BLOG

【GCP】GCPで始めるCloud Run + Cloud Build CIOps環境構築

はじめに

目次

実験したこと

Cloud Run とは

Cloud Build とは

Cloud Build + Cloud Runの実験

STEP1: GitHubのリポジトリを作成し、GitHubトリガーを設定する

STEP2: Cloud Buildのビルド構成ファイルを作成する

cloudbuild.yaml

STEP3: Cloud Buildを実行し、Cloud Runの接続確認を行う

おわりに