こんにちは、虎の穴ラボの植竹です。主にFantiaを見てる人です。
虎の穴ラボ Advent Calendar 2021 - Qiita 13日目の記事です。
12日目は三井さんによる虎の穴ラボにおけるリモートワークの働き方でした。
今回は今年開催したとらラボカンファレンスや弊社主催のLTで発表したGCPのサーバーレス環境「CloudRun」に関する紹介を書いていきます。
目次
CloudRunとは
CloudRunはGCPが提供するコンテナ環境のオートスケールプラットフォームです。
Google Kubernetes Engine (GKE)と似たような環境ではあるのですが、 GKEのようにKubernetesの設定が必要なく設定項目も最小限なため、 かなり手軽に環境構築をすることができます。
CloudRun環境の作り方
環境作成の基本的な流れ
CloudRunの環境を作るにはDockerの環境が必要です。
こちらの公式ページのクイックスタートの説明も充実しているのですが、 改めて簡潔に説明していきたいと思います。
CloudRunはDockerコンテナを元にして作られるので、開発言語を問いません。
ローカル環境でDockerで作成されたアプリが動作すれば、そのまま動かすことが可能です。 順序としては
- Dockerイメージを作成
- イメージをGCPの『Container Registry』にプッシュする
- 『Container Registry』のイメージを元に『CloudRun』の環境を作成する
という流れになります。
※『Container Registry』はGCPが提供するDockerのリポジトリです
デプロイまでのコマンド実行
イメージ作成からリポジトリへのプッシュまでの流れを実際のコマンド実行をする場合、以下のようになります。
# gcloudコマンドでDockerを使うための認証(初回のみ) $ gcloud auth configure-docker # [local-image]にDockerイメージの名前を入れてビルドする $ docker build -t [local-image] . # Dockerイメージのプッシュ先のタグ付けを行う # [host-name]はレジストリのホスト名「asia.gcr.io」などContainer Registryの場所を示す # [project-name]はアップロードしたい自身で作成したGCPのプロジェクト名を入れる # [image-name]はアップロードするイメージの名前で[local-image]と同じでも可 $ docker tag [local-image] [host-name]/[project-name]/[image-name]:latest # そのまま指定したタグでイメージをリポジトリにプッシュする $ docker push [host-name]/[project-name]/[image-name]:latest
たった4コマンドでデプロイ前の準備は完了となり、Container Registryにイメージが登録されます。
その後、以下のコマンド実行でデプロイは完了となります。
# Container RegistryのイメージからCloudRunのデプロイをする # [cloudrun-env-name]は自身で作成するCloudRunの環境の名前が入ります # [region]には「asia-northeast1 」など作成する先のリージョンが入ります gcloud beta run deploy [cloudrun-env-name] \ --project [project-name] \ --region [region] \ --image [host-name]/[project-name]/[image-name] \ --allow-unauthenticated \ --timeout 10 \ --port 8080 \ --min-instances 1 \ --region asia-east1 \ --memory 512Mi \ --concurrency 10 \ --set-env-vars " \ ENV_DUMMY=1 "
このようなコマンドを実行するだけでデプロイ完了です。
様々なオプションの設定が必要なので長くなってますが、オプション指定しない場合は設定が変更されることはないので2回目以降はオプションなしでも問題ありません。
オプションの説明は以下に載っております。
アクセス先とポート
上記例ではオプションでportを「8080」に指定しています。
この場合ローカル上で
$ docker run -p 8080:8080 [イメージ名]
と起動した場合に8080ポートでそのまま「http://localhost:8080」でアプリが動作すればOKです。
CloudRunで作られたドメインにアクセスした場合、ローカルのDocker環境にて「http://localhost:8080」へアクセスしたときと同様の動きになります。
環境変数の設定
CloudRunでは環境変数の設定も簡単に行なえます。
GCPのGUI画面上ではこのように環境変数を複数設定することが可能です。
また、デプロイコマンド上でも設定が可能で、
--set-env-vars " \ ENV_DUMMY=1 "
の部分が環境変数の設定部分にあたります。
set-env-varsの中に設定された環境変数を複数設定することができます。
また、一度設定された環境変数は明示的に削除しない限り次のデプロイ時にも自動的に引き継いでくれます。
アプリのドメインについて
CloudRunで特徴的なのは、ドメインの設定も自動的に行われることです。
このようにデプロイすると、アクセス出来るドメインURLを自動的に発行してくれます。
SSL証明書もGCPが内部で管理してくれるので更新費用などもかからず、非常に便利です。
ロードバランサーと連携させて独自ドメインの設定も可能なのですが、特にこだわりがなければこのまま使っても問題ないでしょう。
セキュリティについて
CloudRunは基本的にHTTPサーバーとしての使い方を想定していますが、セキュリティを考慮してのアクセス制限も可能です。
さきほど示したデプロイコマンドでは
--allow-unauthenticated
というオプションがついてますが、これはアクセス認証をせずにネットワークに公開するという設定です。
「--no-allow-unauthenticated」というオプションにするとCloud IAMで認証したアクセスのみに制限されるので、外部に見せないAPIなどを使う場合はこちらを利用するのが良いでしょう。
また、CloudRunはロードバランサーとの連携ができるため、CloudArmorを使ったアクセス制限やセキュリティ対策も行えます。
これらを用いれば、セキュリティを担保した中規模以上のサービス構築も十分に可能となるでしょう。
バッチサーバーとしての使い方
基本はリクエストを受けて動作するコンテナ環境ですが、定期バッチや非同期処理にも対応できるような想定で作られています。
CloudRun単体では不可能ですが、CloudSchedulerやCloudTaskを使った手法が公式で紹介されており、CloudRunをベースにしたサービス構築ができるようにGCPは整備していると思われます。
欲を言えばCloudRunだけでこのような非同期系の処理ができると理想ですが、
今後のアップデートで期待して良い部分かもしれません。
料金
気になるお値段ですが、オートスケールがかなり柔軟に働き、かなり安価で動いてくれます。
かかる費用は「CPUの稼働時間」「リクエスト数」「メモリの稼働時間」で最も高くなるのは「CPUの稼働時間」です。
料金表はこちらに記載しているのですが、 毎月の無料分がかなり幅広く、部分的に使う場合はその範囲内で収まるのではないかと思います。
まとめ
CloudRunは非常に安価、かつ手軽にサーバーレス環境が作れるので、 GCP使ったことない人にもこれを機に使ってみることをオススメしたい機能です。
定期的にアップデートもされているので、最速でサービス構築する場合の手段としては更に有力な環境となるのではないでしょうか。
P.S.
採用情報
■募集職種
yumenosora.co.jp
カジュアル面談も随時開催中です
■お申し込みはこちら!
news.toranoana.jp
■ToraLab.fmスタートしました!
メンバーによるPodcastを配信中!
是非スキマ時間に聞いて頂けると嬉しいです。
anchor.fm
■Twitterもフォローしてくださいね!
ツイッターでも随時情報発信をしています
twitter.com