Cloud Run と Buildpacks で簡単にコンテナ使えるよ！
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 15 日目の記事です。
こんにちわ！Google Cloud の Kazuu (かずー) です。昨年も Cloud Run の記事を書きました。今年も Cloud Run でいきます！
本記事は、Kubernetes は Too much 、Dockerfile を書きたくない方々 に贈ります。
Kubernetes の学習 & 運用コスト
Kubernetes はインフラを抽象化する便利なツールとして語られることが多いですが、人によってその抽象度について不十分と感じる方もいるのではないでしょうか。マニフェストによる宣言型の API や Deployment のようなコンテナの配置からレプリカ数、ローリングアップデートまで包含した API リソースはエンジニアの生産性を上げる強力な機能ではあるものの、アプリケーションをホストして公開する、そして運用していくという一連のワークフロー全体を考えると、気にすることは他にもたくさんあると思います。GCP のマネージド Kubernetes である Google Kubernetes Engine (a.k.a GKE) を利用した場合でも、例えば外部公開用の IP アドレス、SSL/TLS 証明書を準備したり等々、やることが結構あってインフラ要素が滲み出ちゃってますね。インフラよりの人(私とか)だと、これでも十分に Kubernetes の恩恵に預かれると思いますが、普段アプリケーションの開発を中心に行っている人やインフラのバックグランドが少ない人からすると、これを自分たちで運用していくって結構面倒ですよね。Kubernetes は多機能なのでそれを１から学んで修めるところのコストも大きいです。最近だと YAML エンジニアという言葉を聞きますが、深淵なる Infrastructure as Code の世界にどっぷり浸かってしまうケースも。。なるべくインフラのことは気にせず生きたいという人は世の中少なくないと思います。
コンテナイメージを作る手間
一般的にコンテナイメージを作成する際にはDockerfileにコンテナイメージの作成手順を記述し、docker build コマンドを使ってコンテナイメージを作成します。Dockerfileは他の人が読んだときに当該コンテナが何をやっているものなのか分かる尊いものである反面、ベースイメージの選択や各種依存性のインストールから、コンテナイメージのレイヤ構造を理解してオーバーヘッドの少ないコンテナイメージを作成するためのお作法まで、開発者はDockerfileを書くための諸々を習熟する必要があります。それって結構面倒だしコード書くことに集中したい人って多いのではないでしょうか。
前置きが長くなりましたが、ここからは上記 2 つの課題を解決するのにぴったりの以下 2 つのサービスを紹介します。
Cloud Run
Cloud Run はコンテナをサーバーレスに使えるサービスで以下のような特徴があります。
- 用意したコンテナイメージをデプロイすると外部公開用の URL から SSL/TLS 証明書まで自動的に設定され、即時公開可能
- リクエスト数と負荷状況に応じて自動的にオートスケール
- コンテナなのでランタイムやライブラリの制約がない
- オープンソースの Knative 互換
Cloud Run で特筆すべきはそのシンプルさです。Kubernetes と比較しても非常に簡単にコンテナを利用出来ることが分かると思います。
ここから Cloud Run の細かい話をしたいところですが、本記事の趣旨とズレてしまうので、Cloud Run のその他詳細についてはこちらの資料をご確認ください。
Google Cloud Buildpacks
Google Cloud Builds packs （以降 Buildpacks) は Dockerfile 無しでコンテナイメージを作成するビルドツールです。オープンソースの Buildpacks v3 に準拠しており、Cloud Run や GKE 上で動かすコンテナイメージを作成するのに最適化されています。サポートする言語は Go、Java、Node.js、Python、.NET です。細かい使い方などは後述しますが、仕組みとしては以下のような動きをします。
言語毎に buildpack が用意されており、それぞれ detect/build 関数が実装されています。 detect でどの言語かチェック 、 NG なら次の言語の buildpack へ、OK なら build へという流れです。
上の図を見て分かる通り、コンテナのベースイメージとしては Ubuntu 18.04 のマネージド ベースイメージを利用しています。マネージド ベースイメージは Google によって常に最新のセキュリティパッチが反映されており、定期的に脆弱性スキャンニングを受けた安全なイメージとなっています。
Buildpacks の詳細は弊社の同僚の Matt の動画（英語）もおすすめです。是非ご視聴ください。
Cloud Run と Buildpacks を試してみる
各サービスの説明はここまでにして、実際に Cloud Run と Buildpacks を使ってみましょう。ここでは OSX の環境で試してみます。GCP のコマンドラインツール Cloud SDK (gcloud) をはじめて使う方はこちらを参考にインストールしてみてください。
1.環境準備とコンテナイメージのビルド
2~3 行目
Buildpacks は pack という CLI ツールを使って利用します。また、この後 Cloud Run 上にコンテナをデプロイしてオートスケールも試してみたいので、負荷ツールの Hey も入れておきます。
14 行目
pack コマンドで builder オプションの後に gcr.io/buildpacks/builder:v1 を指定していますが、こちらが Google Cloud Buildpacks のビルダーになっています。その後の gcr.io/k8s-day/sample-python:v1 は今回作成するコンテナイメージの名前とタグです。お使いの環境に合わせて適宜変更してください。フォーマットは gcr.io/<GCPのプロジェクト ID>/<コンテナイメージの名前>:<タグ> です。
23 行目
コンテナイメージを作成した後、イメージレジストリと呼ばれる場所にコンテナイメージを Push して保管します。今回は Google Container Registry (a.k.a GCR) を利用します。
2. Cloud Run へのデプロイと負荷試験
2 行目
Cloud Run へ先程作成したコンテナイメージをデプロイします。image オプションで gcr.io/k8s-day/sample-python:v1 指定します。allow-unauthenticated オプションは認証なしでアクセス出来るサービスを作ることを意味しています。最後の sample-python は今回作成するサービス名です。実際このコマンドを実行すると十数秒程度でコンテナイメージのデプロイと外部公開までが完了します。コマンドのアウトプットの最後に生成された URL が出てきますので、そちらにアクセスしてみてください。
8 行目と 11 行目
Cloud Run の特徴のひとつあるオートスケールが行われるか負荷試験を行い確認してみます。またCloud Runではデフォルトでモニタリングやロギングの仕組みが備わっており、わざわざ別のモニタリングサービスのセットアップを行わなくてもコンテナイメージをデプロイ完了した時点からモニタリングやロギングが開始されます。メトリクスデータを GCP のコンソールで確認するため、ある程度負荷を掛ける必要があります。11 行目のコマンドで 5 ~ 10 分程度負荷を継続して掛けてみてください。(課金が発生するのでご利用は計画的に！) コマンドを終了するときは CTRL + Z です。
5 ~ 10 分後、GCP のコンソールを確認してみましょう。
左側のナビゲーションメニューから Cloud Run > サービス名を選択すれば以下のような素敵な画面が！
ご覧の通り、リクエスト数やレイテンシー、CPU 時間などがグラフで確認出来ます。またアクセスログなども確認することが可能です。コマンド 1 つでデプロイして外部公開してここまで出来ちゃうのって凄くないですか？(興奮気味)
3.トラフィック スプリットを試す
せっかくなので Cloud Run の素晴らしさを更に体験してみましょう。Cloud Run には Update traffic 機能があり、所謂トラフィック スプリットを行うことが可能です。例えば古い Version A に 50% 、新しい Version B に 50% のリクエスト トラフィックを転送する等々が簡単に可能です。
2 行目
新しい Version のアプリケーション (コンテナ) を作るため、メッセージ内容を変更しコードを更新します。
5 行目
更新したコードで新しい Version のコンテナイメージを作成します。
14 行目
新しい Version のコンテナイメージを Cloud Run にデプロイします。no-traffic オプションでデプロイした新しいバージョンにトラフィックが流れないようにします。tag オプションで分かりやすいようにタグを付けておきます。今回は green というタグを付けておきます。
20 行目
services update-traffic コマンドで green に 50% のリクエストトラフィックを転送するよう設定します。
以上のように 少ない手数で簡単にトラフィック スプリットを試すことが出来ました。この機能を使えば Blue / Green Deployment や Canary Release などが比較的簡単に行なえますよね！
まとめ
如何でしたでしょうか？本記事のポイントは以下の通りです。
- Cloud Run は Kubernetes と比較して簡単に コンテナをホストできるサーバーレス サービス、コマンド一発で 外部公開やモニタリング、ロギングまで設定可能。
- Buildpacks で Dockerfile を用意しなくても簡単にコンテナイメージをビルド可能。
ということで、Cloud Run と Buildpacks を使えば、未だコンテナに詳しくない方でも簡単にコンテナイメージをビルドし、外部公開まで行えます。まずは Cloud Run でコンテナをはじめて頂き、システムの規模が大きくなってきたら GKE に移行する展開も美しくて良いですね！本記事を読んで頂きコンテナや GCP をはじめる方が増えるととても嬉しいです。
明日 16 日目は、yuyaono san の「Google Cloud の視覚認識 AI のいま」です。お楽しみに！
