run：言語自由、リクエストタイム60分

functions：リクエスト9分、関数をデプロイ
  gke auto pilot mode：制限がなくなる

ローカルや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と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 traffic onlyとrequire auth(IAM)、権限allAuthenticatedUsersにCloud Run Invokerのとき

　　ターミナルはinternal trafficでないから

　　curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" https://unco-zp2aehj5rq-an.a.run.app/ でも駄目

インターナルでIAMを使うにはどうする？(同セグメントvpcからcurl bearer、vpc scかpubsubかEventarcだけ、terminalやschdulerは駄目）

　→IAMを使うならallow all traficでいいのでは、allusersにinvokerを付与しなければいいし
　→怖ければ同セグメントにVMを立ててそこからキック、あるいはScheduler手動 > Pubsub > Eventarc > Cloud runがいい

ブラウザ+IAMをrunで使うにはIAP
　global ip、ドメイン、DNS、証明書、設定allow all traficとrequire auth(IAM)、権限各メールidにinvoker

LBはバックエンドにserverless network end groupを選べばいい

/// IAP

dockerfileに記載

FROM google/cloud-sdk:latest
　PythonモジュールでなくOS側にインストールする必要がありコンテナ化のDockerfileに記載できる
　/// BANGBOO BLOG /// - k8s にDocker記載がある

　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

OSの実行ユーザとコンテナ内のユーザを合わせないとファイル読み込み等ができない

　permission deniedになる

　Cloud runのそれぞれのユーザが誰なのか分からない（上記でわかるが）

　Dockerfileに RUN chmod -R 777 /app と入れてしまう

Cloud Run のトリガーを作成する  |  Eventarc  |  Google Cloud
runとscheduler/pubsubの連携は eventarc triggerの設定が良さそう
これはAudit logに既定のものが記載されると発火されるというもの

　設定したrunのサービスのトリガー項目に

　　google.cloud.scheduler.v1.CloudScheduler.Run.Jobを設定（スケジューラ手動実行ならこれでも連携する）
　　google.cloud.pubsub.topic.v1.messagePublishedを設定 (Pubsub経由のEventArcなら）
　色んなAPI有効が必要　クイックスタート: Pub/Sub メッセージを使用してイベントを受信する（Google Cloud CLI）  |  Eventarc
Schedulerとの連携に使う場合、手動実行でAudit logに記載され動くが、cron定期実行ならAudit logがなく動作しない事が分かった
　internal trafficなら Scheduler > Pubsub > Eventarc > Cloud run

■Scheduler

runはジョブならFlask不要で簡易。だがEventarc-Schedule連携がまだGAでなくできないので単発手動実行用。

Procfile作成

web: python3 main.py

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
Flaskへようこそ — Flask Documentation (2.0.x) (msiz07-flask-docs-ja.readthedocs.io)
とほほのFlask入門 - とほほのWWW入門 (tohoho-web.com)
Flaskの基礎 - 闘うITエンジニアの覚え書き (magata.net)

from flask import Flask #モジュール読み込み

app = Flask(__name__) #Webアプリ作成

@app.route("/", methods=["GET","POST"]) #エンドポイント設定(ルーティング)

def index():

if __name__ == '__main__': #Webアプリ起動

  app.run(debug=True)

■functions

コンソールでコード書いてもデプロイエラーになると入力分が消える糞
　テキストで書いてコンソールにペーストしてやった
　開発環境はローカルにすべきだろうな
　【Python】Cloud Functions ローカル環境で開発 デプロイ | のい太ろぐ (noitalog.tokyo)
　Cloud Functionsのローカル開発環境にFunction Frameworkを使用する (rhythm-corp.com)

functionsもhttpで初めに実行される関数はFlaskのflask.Requestオブジェクトを受取る
　PubsubトリガーとかEventarcトリガーもあるようだ
　　pubsubトリガーならinetrnal traffic onlyでOKだが、httpsはall traffic必要

requirementsは必要？標準ライブラリならimport文を本体に書いていれば良い

　pprint.pprintでエラー、requirementsの場合PyPIで調べてバージョンも書こう

一時ファイルは/tmpというDIRであるがメモリーに保持される

テストでJSONを書く場合はキッチリ書く（文字はダブルクォート等）

{

"test" : "aaa"

}

functions invoker等のIAMはプロジェクトレベルではなく各functionsに対しての設定が必要そう

functions では gcloud cmdが打てない、SDKがないから

　クライアントライブラリでは？ > 非力そう、、cloud runならSDKでDockerしgcloud cmd打てる
　Cloud クライアント ライブラリ  |  Cloud APIs  |  Google Cloud

ENTRY_POINT 実行される関数、GCP_PROJECT 現在のGCPプロジェクトIDとか

■pubsub
GCP - Pub/Sub サービス概要 - Qiita

topicという入れ物

　メッセージがpublish投入される（コンソールでも作れるのでinternal trafficのトリガーにできる）

　subscriptionでTopicのデータ取得状況を管理

　subscriptionからsubscribeでメッセージの取得

メッセージは重複する仕様

　Topicにメッセージを入れると勝手に紐づけられたアプリが動く

　　フィルターがあり条件を設定をできるがTopicを沢山作ればいいのでは

　サブスクのpullはメールボックスみたいな入るだけ

　　functionsのpubsubで作った指定のTopicにメッセージが入れば動く

　サブスクのpushも送信メールボックスみたいで送る

　　functionsのhttpで作ったエンドポイントに送られる
　pullは謎に上手く行かなくなる？pushの方が安定かも

　　でもトラフィックの種類でpullならinternal traffic OK

　　　pubsub pull -> functions：pull なら internal traficでもOK

　　　pubsub push -> functions：push は http なので internal traficダメ

　functionsのデプロイ時にinternal traffic や all等の変更もできる

例えばRunのTriggerでEventarcをPubsubで設定すれば指定のTopicに勝手にサブスクを作ってくれる