ローカルやterminalなどで作成しcmdでレジストリに入れるが、~/unco で下記作成
Dockerfile
.dockerignore
main.py
コンテナイメージにパッケージ化しContainer Registry にアップロード
gcloud auth application-default login
gcloud run deploy (対話型でデプロイまでできるが、SAはデフォルトになる)
gcloud builds submit --tag gcr.io/bangboo-run/unco (ビルドのみ、手動でコンソールでSAを指定しデプロイする)
コンソールでデプロイ(trigger/permission)-新ver更新のときTagを付けなおす?
設定allow all traficとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerでブラウザアクセス駄目
設定allow all traficとAllow unauthenticated invocations、権限allUsersにCloud Run Invokerではブラウザでも上手行く
設定allow all traficとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
IAMが要るのでターミナルから
curl https://unco-zp2aehj5rq-an.a.run.app/ ではIAM要求の場合は駄目
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ で上手行く
設定allow internal trafic onlyとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき
IAMが要るのでターミナルから
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ でも駄目
インターナルでIAMを使うにはどする?(vpcかvpc scかpubsubかEventarcだけ?terminalやschdulerは駄目?
→IAMを使うようにすればallow all traficでいいのでは、allusersにinvokerを付与しなければいいし
→怖ければVMを立ててそこからキック)
runのデフォルトのSAは別のrunでも同じSA実行として使い回されるので、別途作成したものを指定したい
デプロイをコンソールで実行するとサービスアカウントを指定できる(runのPermissonでそのSAにinvokerを付ける)
ブラウザ+IAMをrunで使うにはIAP
global ip、ドメイン、DNS、証明書、設定allow all traficとrequire auth(IAM)、権限各メールidにinvoker
LBはバックエンドにserverless network end groupを選べばいい
python requirements.txtでは google-cloud-bigqueryはインスコできるがsdkは無理
main.pyに from google.cloud import bigquery
Dockerfileでイメージでgoogle-cloud-sdkが入ればPythonのsubprocessでgcloud cmdが打てる
Dockerのベースイメージを FROM google/cloud-sdk:latest にして
RUN apt-get update && apt-get install -y \
python3-pip
RUN pip install --no-chache-dir -r requirements.txt
Cloud API client library for pythonを使うにはrequirements.txtに
google-api-python-client
Dockerfileの動作はCloud buildのhistoryで見れる
RUN which gcloud
RUN echo $PATH
RUN who
Cloud runのpython動作はloggingで見る
OSの実行ユーザとコンテナ内のユーザを合わせないとファイル読み込み等ができない
permission deniedになる
Cloud runのそれぞれのユーザが誰なのか分からない(上記でわかるが)
Dockerfileに RUN chmod -R 777 /app と入れてしまう
===
runとscheduler/pubsubの連携は eventarc triggerの設定が必要そう
設定したrunのサービスのトリガー項目に
google.cloud.scheduler.v1.CloudScheduler.Run.Jobを設定(スケジューラなら)
色んなAPI有効が必要
クイックスタート: Pub/Sub メッセージを使用してイベントを受信する(Google Cloud CLI) | Eventarc■Scheduler
get で https://run-service-name-.kuso.run.app
0 7 * * 1 毎週月曜の6時
Auth headerに add OIDC token
runのサービスにinvokerを付けたSAを指定
5回リトライ/最大リトライ0sで制限なし/バックオフ最小180s最大1h/期間倍5回
http経由ならデフォルトのサービスアカウントにCloud service agentロールが必要
===
■Run jobs
runはジョブならFlask不要
Procfile作成
web: python3 main.py
pipしたいものは requirements.txtに書く
google-cloud-bigquery
main.py作成
コードを書く from google.cloud import bigquery
gcloud auth application-default login
run job実行とコンテナのプロジェクトを合わすなら
gcloud config set project bangboo-runs
下記は通常不要なようだ
gcloud auth configure-docker
Buildpackを使用してコンテナをビルド
Cloud buildデフォルトサービスアカウントにGCSバケット権限必要 123456@cloudbuild.gserviceaccount.com
gcloud builds submit --pack image=gcr.io/bangboo-runs/run_data_to_bq
bangboo-runsのコンテナレジストリにrun_data_to_bqができている
Cloud runでジョブを作成
gcloud beta run jobs create job-run-data-to-bq \
--image gcr.io/bangboo-runs/run_data_to_bq \
--task 1 \
--set-env-vars SLEEP_MS=10000 \
--set-env-vars FAIL_RATE=0.5 \
--max-retries 0 \
--region asia-northeast1
(gcloud beta run jobs create --helpで見るとenv-varのハンドルは何もないのでコードでエラースローする必要がありそう、そこでスリープとか使ってエラーを吐くと、リトライはしてくれそう。taskを複数にすると同時に何個も動く)
ローカルでテスト
docker run --rm -e FAIL_RATE=0.9 -e SLEEP_MS=1000 gcr.io/bangboo-runs/run_data_to_bq
Cloud runでジョブを実行
gcloud beta run jobs execute job-run-data-to-bq
============
■Flask
from flask import Flask #モジュール読み込み
app = Flask(__name__) #Webアプリ作成
@app.route("/") #エンドポイント設定(ルーティング)
def index():
if __name__ == '__main__': #Webアプリ起動
app.run(debug=True)
============
■functions
コンソールでコード書いてもデプロイエラーになると入力分が消える糞
テキストで書いてコンソールにペーストしてやった
functionsもhttpで初めに実行される関数はFlaskのflask.Requestオブジェクトを受取る
requirementsは必要?import文を本体に書いていれば良さそう
標準ライブラリ以外はrequirementでインスコでは?
pprint.pprintでエラー、requirementの場合バージョンも必要そう
一時ファイルは/tmpというDIRであるがメモリーに保持される
テストでJSONを書く場合はキッチリ書く(文字はダブルクォート等)
{
"test" : "aaa"
}
functions invoker等のIAMはプロジェクトレベルではなく各functionsに対しての設定が必要そう
functionsのデプロイ時にinternal trafic や allow all trafic等の変更ができる
functions で gcloud cmdが打てない、SDKがないから
逆にgcloud cmdはダメだが、requirementでライブラリはpipインスコ自由では?
topicという入れ物
メッセージがpublish投入される(コンソールでも作れるのでinternal traficのトリガーにできる)
subscriptionでTopicのデータ取得状況を管理
subscriptionからsubscribeでメッセージの取得
メッセージは重複する仕様
Topicにメッセージを入れると勝手に紐づけられたアプリが動く
フィルターがあり条件を設定をできるがTopicを沢山作ればいいのでは
サブスクのpullはメールボックスみたいな入るだけ
functionsのpubsubで作った指定のTopicにメッセージが入れば動く
サブスクのpushも送信メールボックスみたいで送る
functionsのhttpで作ったエンドポイントに送られる
pullは謎に上手く行かなくなる?pushの方が安定かも