背景

ちょっとした処理をGCEのf1-microインスタンスでdockerを使って定期実行していたのですが、なぜか昨年11月頃から動作が重くなり処理が完了できなくなりました。そもそもspec不足だろうとは思ったので、最近知ったCloud RunならRubyのまま移行できるのではないか、と考えました。

Cloud Runではボリュームに相当する機能が使えないので、ファイルに保存していたデータを別の方法で保存する必要が発生しました。試行錯誤の結果、今回はFirestoreに保存するのが良さそうという結論になったので、この記事を書いています。

サンプル

Ruby2.6なのは、現時点ではRuby2.7でgrpcのgemがbundleできないからです。あと数日で出来そうな気配はあります。

要点

Cloud Runは、処理の内容が何であっても、HTTPリクエストを受け取って実行する仕組みです。なので、既存の処理を、リクエストが来たら実行するwebアプリケーションに書き換える必要があります。

Cloud Runは、同じプロジェクトであれば、設定を全く行わずに、Firestoreにアクセスできるようになっています。

動かしかた

１つ１つのプロセスは各サービスの基本的なものなので、公式ドキュメントやGoogleなどで調べられると思います。

Firestoreのデータ

GCPの同じプロジェクトでFirebaseを動くようにして、Firestoreも動くようにして、以下のようにデータを入れます。

コンテナのビルド

gcloud builds submit . --project=your-awesome-project --config=cloudbuild.yaml

プロジェクト名は置き換えましょう。

サービスの設定

サービスが設定されたら自動的に最初のデプロイが行われるので、すぐ実行できるようになります。

実行

Firestoreのデータを引っ張ってこれていることがわかります。

ここまででCloud Runを動かす話は終わりです。ついでに開発時に手元で動作させる方法について書きます。

手元での動かしかた

サービスアカウントの鍵を発行

発行時にJSONを手元にダウンロードして保存します。

鍵の配置

レポジトリの下にdataディレクトリを作って鍵ファイルを置いて、

# Replace file name
GOOGLE_APPLICATION_CREDENTIALS=/data/your-awesome-project-deadbeef1234.json

鍵ファイルの名前に書き換えて、.envとして保存します。この環境変数はFirestore用のgemが読み取ります。

起動

docker-compose up

で、 http://localhost:8080 にアクセスして、{:foo=>"bar", :hoge=>"piyo"}と表示されればOKです。

TIPS

• STDOUT.sync = trueを入れておかないと処理のログが出ないかも

cronみたいな定期実行する方法

こんな感じの設定でいける