Zenn
Closed4

GCP関連の単なる備忘録

GCP
KUZU_TAROUKUZU_TAROU

Cloud functions第２世代の設定で苦戦したことのメモ

以下の2つが必要
1.Clound Functionsが（Cloud Schedulerにより内部的に使われる）Cloud Run起動元に関する権限の設定が必要リンク
2.Cloud SchedulerからCloud Functions第2世代をHTTPで呼び出す認証の設定が必要リンク

Cloud Run起動元権限の設定

リンク先に以下のような記載がある。

ターゲットが Google Cloud 内にある場合は、必要な IAM ロールをサービス アカウントに付与します。Google Cloud 内の各サービスには特定のロールが必要で、受信側のサービスは生成されたトークンを自動的に検証します。たとえば、Cloud Run と第 2 世代の Cloud Functions 関数では、Cloud Run Invoker ロールを追加する必要があります。

つまり、Cloud Schedulerを実行するプリンシプルに対して、Cloud Runの起動元権限というものを付与する必要がある。Cloud Schedulerを触っていると、？？？、となるポイントが、実行しているサービスアカウントがどこを見てもわからない。実は、デフォルトのサービスアカウントPROJECT_ID@appspot.gserviceaccount.comが実行しているらしいので、これに対してcloud run起動元権限を付与すれば良い。以下のコマンドを発行した。

gcloud functions add-iam-policy-binding ファンクション名 \
  --member='serviceAccount:プロジェクト名@appspot.gserviceaccount.com' \
  --role='roles/cloudfunctions.invoker'

これでもしPermission Deniedになるようであれば、上記リンク先に記載がありますが、Cloud Run側へのPermission設定も必要なのかも（どっちもやってしまったので、どちらが正確に必要なのか不明）。ちょっとドキュメントがわかりにくいですよね、結局第二世代のCloud Functionの場合は、上記のコマンドだけで良さそうな感じにも読み取れますが、どうなんでしょうか。

HTTP認証の設定

リンク先の認証を使用するスケジューラ ジョブを作成するに記載がある。これは、スケジュールの設定を行うところなのだが、よく見るとAuthヘッダーのところにHTTP認証の設定があり、ここでサービスアカウントを指定して設定が可能になっており、デフォルトサービスアカウントを使ってHTTP認証をODICベースでやれば良い。
なお、ODICなのかOathなのか、については、

[Auth ヘッダー] リストでトークンタイプを選択します。一般には OIDC が使用されます。ただし、*.googleapis.com でホストされている Google API は例外で、OAuth（アクセス）トークンが使用されます。

と記載がある。私が今やっているのが一般的なのか、*.googleapis.comでホストされているGoogle APIなのかがよくわからない。調べたところ、以下の通りのもよう。わかりにくいな。いずれにせよODICで良いのだ。

*.googleapis.com でホストされている Google の API（例: Google Cloud Storage, BigQuery など）へのアクセスには、OAuth トークン（具体的には OAuth 2.0 アクセス トークン）を使用します。これらの API は Google の内部リソースにアクセスするため、OAuth トークンが適切です。

KUZU_TAROUKUZU_TAROU

Google Cloud Functionsをローカルで開発、テスト、デプロイする

Macで発生するウザいエラー

以下の二つを参考にすると、本来最も簡単にローカルでCloudFunctionsの実行ができるはずだが、仮にデプロイして成功するコードだとしてもMac OSだとうまくいかないケースがある。これはMacのセキュリティに起因するものである。
https://cloud.google.com/functions/docs/deploy?hl=ja
https://dev.classmethod.jp/articles/try-function-framework/

俺たちのChatGPTちゃんによると以下の理由が考えられるとのこと。

  1. 環境変数の設定
    まず、問題が発生しているターミナルセッションで次の環境変数を設定します。これは fork() 呼び出し時の問題を回避するためのものです。
export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES

このコマンドを実行後、Python スクリプトを再実行してみてください。

んで、実際に上記を実行の上でCloud Functionsの関数をローカルデプロイしたところ、うまくいきました。

いやーーー、めんどくさw

KUZU_TAROUKUZU_TAROU

Pyenvの最も基本的な使い方のメモ

pyenvでインストールできるPythonのバージョン一覧を確認する

$ pyenv install --list

pyenvの環境にインストールされているPythonを確認する

$ pyenv versions

こんな感じで一覧が表示される。今の環境は*の部分が現在の環境になってる。

(py_virtual_env) user_name@user_name bin % pyenv versions
  system
  3.10.13
* 3.11.0 (set by /Users/user_name/.pyenv/version)
  3.12.0

pyenvインストール後、Pythonのバージョンを指定してインストールする。

$ pyenv install 3.7.3

PC起動後、特に何もしていない場合のバージョンは、以下のとおりglobalのキーワードで指定する。
これにより、現在のPythonの環境のバージョンが変化する。

$ pyenv global 3.5.1

所望ぼPythonのバージョンに切り替えた状態で、以下のコマンドで仮想環境を作成すると、そのバージョンで仮想環境が作られる。

$ mkdir 仮想環境名
$ cd 仮想環境名
$ python -m venv 仮想環境名

作成すると、仮想環境ディレクトリ配下に必要ファイルが作られる。
bin配下にactivateスクリプトが作成され、これを実行することで仮想環境が切り替えられるようになる。
具体的には、仮想環境を指定してPythonの実行環境を切り替えるには以下の通りコマンドを発行する。

source <仮想環境名>/bin/activate

これで所望の仮想環境に切り替わる。

仮想環境のpythonバージョン変更

バージョン変更は、globalのバージョン(通常利用されるPythonのバージョンのこと)を切り替えた後に、もう一度作成コマンドを--clearオプション付きで実行すると良い。

$ pyenv global 3.11 
$ pyenv versions
  system
  3.10.13
* 3.11.0 (set by /Users/kazuhisa.wada/.pyenv/version)
  3.12.0

$ pyenv global 3.11

python -m venv dataflow --clear

削除

ディレクトリ丸ごと、インストール先のディレクトリを削除すればOK

参考文献

1
2
3

KUZU_TAROUKUZU_TAROU

Pythonのパッケージ一括インストールとインストール済みパッケージ一覧関連(requirements.txt)

開発は主にPython仮想環境を切り替えて実行するが、Python仮想環境ごとにインストールされているパッケージはpip freezeにより出力できる。これを使うことでCloudFunctionsへのデプロイ時にそのまま使えるようになる。

$ pip freeze
agate==1.6.0
agate-dbf==0.2.0
agate-excel==0.2.1
agate-sql==0.5.2
...

パイプでrequirements.txtに出力すれば良い。
```py
$ pip freeze > requirements.tx

requirements.txtを使えば、一括でインストールも可能です。

$ pip install -r requirements.txt

参考文献１

このスクラップは1ヶ月前にクローズされました