Python: Cloud FunctionsでHit and Blowを動かす
PR

Python: Cloud FunctionsでHit and Blowを動かす

プログラミングソフトウェア
記事内に広告が含まれています。
スポンサーリンク

Pythonの勉強ということでゲームを作ってApp Engineで動かしましたが、せっかくなのでCloud Functionsでも動かしてみました。

スポンサーリンク
スポンサーリンク

Cloud Functionsとは

スケーラブルな従量課金制 Functions as a Service(FaaS)プロダクト

https://cloud.google.com/functions?hl=ja

とあります。サーバレスと呼ばれるものの1つですね。

第二世代と呼ばれる新しいものがでてきているようなので、使ってみます。

スポンサーリンク

Cloud Function向けにアプリを直す

チュートリアルを見て(試して)、どんなプログラムになるのか、どういったサービスを使うか調べます。

functions frameworkというものを使う必要があるようです。

ということで、使うように直したアプリがこちら。

FlaskだとデコレーターでHTTP Methodまで指定できましたが、そういうわけにはいかないようです。functions frameworkのお作法に従った関数を1つ用意して、その中でHTTP Methodを判定して呼び分けるようにしています。

requirements.txtは、Python での依存関係の指定  |  Google Cloud Functions に関するドキュメントを参考に修正しました。

スポンサーリンク

デプロイする

下記のコマンドでデプロイしました。

gcloud functions deploy hit-and-blow --gen2 --region=us-central1 --allow-unauthenticated --runtime=python310 --source=. --entry-point=hit_and_blow --trigger-http

hit-and-blowというFunction名にしました。第二世代を使うので、–gen2を付けています。
@functions_framework.http を付けた関数の名前はhit_and_blowなので、–entry-pointに指定しています。

管理画面を見てみると

Cloud Functions - 関数のリスト

デプロイできているようです。
アクセス先のURLはこの画面には表示されていませんが、hit-and-blow のリンクをクリックして表示される関数の詳細画面にあります。

一方、第二世代はCloud Runで動くと言うので、Cloud Runの画面を見てみましょう。

Cloud Runのアプリケーション一覧

Cloud Functionsで付けた名前と同じサービスがあります。その名前(hit-and-blow)をリンクして詳細を見てみます。

Cloud Runのhit-and-blow

右側に「Cloud Functions で使用」と出ていて、関連していることがわかります。

Artifact Registryも見てみます。

artifact registry

hit-and-blowの中に、コンテナイメージがあります。

gcloudコマンドでdeployすると、コンテナを作ってCloud Runにdeployまでしてくれています。お手軽ですね。

sessionを使うとsecret keyのエラーが出る

プログラムの話に戻りましょう。

開発はローカル(手元)のPCで行うことになるのが普通だと思います。
ローカルでcloud functions用に作られたプログラムを動かす方法は、公式サイトに書いてあります。

動かしてみたところ、

RuntimeError: The session is unavailable because no secret key was set.  Set the secret_key on the application to something unique and secret.

というエラーになりました。secret_keyをセットする必要があるとありますが、どうやって?

requirements.txtを見るとFlaskを使っているようなので、それっぽいものに設定してみました。

エラーは出なくなりましたが、これでいいのだろうか…。

Cloud Runを使おう

Cloud Functions第二世代はCloud Runで動いているというのが、管理コンソールからも見えています。Dockerに慣れているのであれば、Cloud Runを使う方が自由度があって良さそうです。Cloud Runで動かすための手数は多いですが、頻繁にdeployするのであればそれ用のscriptなり仕組みを用意するでしょう。「コンテナイメージの作成」までと「コンテナイメージのdeploy」とわけることで、コンテナイメージに対して動作テストや脆弱性診断の実施といった、プロダクション環境で求められる作業も挟み込みやすくなります。

「手軽に動かす」という面では、App Engine Standardがアプリの作りやすさやdeployのしやすさで一歩リードという感じでしょうか。ただ、ベンダーロックインになりますし、App EngineよりもCloud Run(というかKubernetes)推しな印象を受けることも多いので、悩ましいところです。

スポンサーリンク
ソフトウェア
スポンサーリンク
memoTech

コメント

タイトルとURLをコピーしました