背景
ちょっとした処理を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みたいな定期実行する方法
こんな感じの設定でいける