=========================
2016-01-03
■XSS対策、CSRF対策、脆弱性チェック
情報処理推進機構にチェックリスト有
https://www.ipa.go.jp/security/vuln/websecurity.html

XSS対策
　フォーム送信後の確認画面ではHTMLエスケープ等でサニタイズされた内容の結果を表示
　DBへのクエリについてはプレースホルダやエスケープ等でSQLインジェクションを防ぐ
　target="_blank"はXSSになるので危ない、rel="noopener noreferrer"を付ける
　　https://b.hatena.ne.jp/entry/s/webtan.impress.co.jp/e/2020/03/13/35510
　　https://laboradian.com/test-window-opener/
CSRF対策
　前ページでhidden値を入れる
他
　クッキーに具体的なものは入れない、CookieにHttpOnly属性、HTTPS通信ではsecure属性
　エラーメッセージを表示しない
　不要なファイルは削除

　XMLの外部実態参照は禁止、サーバ上でコードが実行される
　　→libxml_disable_entity_loader(true)で止める、xmlをアップロードさせない/使用しない、JSON使う
　PDFからHTTPリクエストが発行される
　　→PDFをアップロードさせない

------

//SQLインジェクション対策
\ " ' を\エスケープ
$sql = "UPDATE users SET name='.mysql_real_escape_string($name).'WHERE id='.mysql_real_escape_string ($id).'";

//クロスサイトスクリプティング対策
表示時には<>&"をメタ文字へ変換
echo htmlspecialchars($_GET['username'], ENT_QUOTES);
$ent = htmlentities($ent, ENT_QUOTES, "UTF-8"); //100個の文字を変換

//クロスサイトスクリプティング対策
別サイトからのポストを弾く
refferを送信しないリクエストもある（別サイトのリファラを弾き、nullもしくは適切ページからを許可する）
セッションIDで判断する

//DOS対策
2重ポスト
IPと日付で2重ポストを防ぐ（同IPのポストがx秒以内を弾く）

========

■JSONP
scriptタグを使用してクロスドメインなデータを取得する仕組みのことである。 HTMLのscriptタグ、JavaScript（関数）、JSONを組み合わせて実現される

GoogleAnalyticsのクッキーは1stパーティでサイト側がオーナでありGoogleがオーナーではない
　サイト側のJSでクッキーが作成されるようなっている
　クッキーが送信される相手はどこか？が重要でGoogleでなくサイト側に送信される
　アクセス履歴は別途データをGoogleに送信しており、クッキーはセッション管理に使用される

■SSO

どこでビルドしてもデプロイしてもImmutableインフラ（不変の）なので変更したい場合はDockerfileの方を変える

コンテナはOS上のDockerEngine上に配置する（コンテナは複数配置できる、Dockerfileさえあれば再現可）
DockerfileでなくてもDockerイメージでもいいが、Dockerは可搬性をもたらすのである

　なおVMはOSをもシミュレート
１部: はじめに｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
２部: Dockerfile の基礎｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
３部: Docker Compose｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)
　Dockerのチュートリアル - とほほのWWW入門 (tohoho-web.com)
　Dockerコマンド - とほほのWWW入門 (tohoho-web.com)
　　コンテナ設計方針をまとめてみた - Qiita
　　社内のDockerfileのベストプラクティスを公開します│FORCIA CUBE│フォルシア株式会社
　　Docker完全に理解した | IIJ Engineers Blog
　ボリュームマウント＝DockerEngine上にボリュームを作りコンテナにマウント(操作が面倒で仮使用や永続ファイル用)
　バインドマウント＝LinuxOS上のファイルやディレクトリをマウント(ファイル編集が多い場合)
　dockerfile(イメージを作る)、docker compose(yamlで一括でコンテナ/nw/volを作る)

docker container run --name コンテナ名003 -d -p 8083:80 イメージ名httpd

■仮想NW
コンテナ間をつなぐ（タグ名で紐づける感じ）
docker network create ネットワーク名net001
docker container run --name mysql001 -dit --net=net001 ～～～ イメージ名mysql
docker container run --name wordpress001 -dit --net=net001 -p 8085:80 -e WORDPRESS_DB_HOST=mysql001 ～～～ イメージ名wordpress

■停止
docker stop コンテナ名
docker rm コンテナ名
docker network rm ネットワーク名

■コピー　OS⇔コンテナ
docker cp コピー元 コピー先
例）docker cp /home/a.txt コンテナ名:/app/

■ボリュームのマウント
データをコンテナ内に置くとコンテナが消えるとデータも消えてしまう
永続化１）ボリュームマウント：DockerEngine上
永続化２）バインドマウント：OS上
永続化３）一時メモリマウント：（tmpfs）

■バインドマウント
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v /home/a:/usr/local/apache/htdocs イメージ名httpd　（OS側パス:コンテナ側パス、コンテナ側のパスをどこにすべきかはDockerイメージのドキュメントを見よ）
docker volume inspect vol001　（確認できる）
docker volume rm vol001

■ボリュームマウント
ちょい面倒らしいのでバインドマウントでいいのでは？
docker volume create ボリューム名vol001
docker run --name コンテナ名httpd001 -d -p 8080:80 -v ボリューム名vol001:/usr/local/apache/htdocs イメージ名httpd　（OS側パス:コンテナ側パス）

docker volume inspect vol001　（確認できる）
docker volume rm vol001

■ボリュームマウントの確認やOS側にバックアップ
アプリコンテナとは別のshellコンテナを用意してlsしたりtar.gz等する
Apacheコンテナ <-> vol001 <- Linuxコンテナ -> vol002バックアップ
マウントを2つ（DockerEngine上のマウント、OS上のマウント）
tar.gzコピーでDockerEngine上の指定フォルダにコピーするが其れはOS側にもマウントされている、最後のドットも要る
イメージは軽量Linuxのbusyboxを使用
docker run --rm -v vol001:/usr/local/apache/htdocs -v /home/b:/tmp busybox tar CXvf /tmp/bjk.tar.gz -C /usr/local/apache/htdocs .

■アプリ
/// BANGBOO BLOG /// - GCP script　下の方に記載あり

■Dockerfile
ビルドしてイメージを作成
FROM イメージ名
COPY コピー元パス コピー先パス
RUN Linuxのコマンド

ENTRYPOINT　イメージを実行するときのコマンド
CMD　コンテナ起動時に実行する規定のコマンドを指定
ONBUILD　ビルドが完了したときに任意の命令を実行する
EXPOSE　通信を想定するポートをイメージの利用者に伝える
VOLUME　永続データが保存される場所をイメージ利用者に伝える
ENV　環境変数を定義する

WORKDIR　RUN/CMD/ENTRYPOINT/ADD/COPYの際の作業ディレクトリ

SHELL　ビルド時のシェルを指定
LABEL　名前やバージョンや制作者情報等を設定
USER　RUN/CMD/ENTRYPOINT実行するユーザやグループを設定

ARG　docker buildする際に指定できる引数を宣言
STOPSIGNAL　docker stopの際にコンテナで実行しているプログラムに対して送信するシグナルを変更する
HEALTHCHECK　コンテナの死活確認をするヘルスチェックをカスタマイズする

社内のDockerfileのベストプラクティスを公開します│FORCIA CUBE│フォルシア株式会社
Dockerセキュリティベストプラクティス トップ20：究極ガイド

■ビルドでイメージを作成
Dockerfileや材料ファイルのあるフォルダパスを最後に指定、-tはタグでイメージ名
docker build -t img_httpd001 ./

■commitでコンテナからイメージを作成

コンテナにexecで幾つかインスコする操作をしてからイメージにする等ができる
docker commit httpd001 img_httpd001

■コンテナ/イメージはDockerEngine上から移動できない
saveするとファイル化され、できるようになる
docker save -o save_img_httpd001.tar img_httpd001
　ファイルからイメージとして取り込みたいときはdocker load
　ファイル化せずにパブリックならDocker hubへ登録してもよい、プライベートレジストリを作ってもよい
　　その中にそれぞれリポジトリを持つ > docker push レジストリ/リポジトリ名:バージョン

■コンテナに命令する
2つの方法がある
１）docker exec
２）docker run に引数を付ける→ソフトウェア(apache)が動いていない状態になり改めてdocker startが必要
docker exec -it コンテナ名httpd001 /bin/bash
　apt install mysql-server　など対話でコンテナにインスコできる
exit　抜ける

■Docker compose

docker runコマンドの集合体、コンテナ等作って消すだけ（k8sはコンテナ等を管理する）
以前はdocker-composeコマンドで別ツールだったが今は統合済み
フォルダに1つだけdocker-compose.yml
基本はdocker runを実行せずにdocker composeしたい
手順は、１）Docker run方法で一応の検討>２）docker-compose.ymlの記述>３）docker composeコマンドの実行

docker run~~に対するdocker-compose.ymlとdocker composeコマンド の対比
１）docker run --name cnt_wordpress001 -dit --net=net001 -v wordpress001vol2:/var/www/html -p 8080:80 -e WORDPRESS_DB_HOST=mysql001 -e WORDPRESS_DB_NAME=wpdb001 -e WORDPRESS_DB_USER=wpu001 -e WORDPRESS_DB_PASSWORD=my-secret-pw wordpress
↓

２） docker-compose.ymlの記述

/// restartの設定値（コンテナが停止した時にどうするか？）
no　＝何もしない
always　＝必ず再起動する
on-failure　＝プロセスが0以外のステータスで終了したときは再起動する
unless-stopped　＝停止していたときは再起動しないがそれ以外は再起動する
　Bashで終了ステータスよる条件分岐 | Codebase Blog
　※bashは前に実行されたコマンドの終了ステータスは「$?」で取得できるが慣習的にコマンドが正常終了した場合は0を返す

/// その他の定義項目

command　＝起動時の規定コマンドを上書きする

entrypoint　＝起動時のENTRYPOINTを上書きする

env_file　＝環境設定情報のファイルを読み込む
　他　container_name / dns / eternal_links / extra_hosts / logging / network_mode etc.

３）docker compose コマンド
　up=イメージDL、コンテナ/nw/volの作成・起動
　down=コンテナとnwの停止と削除、volとイメージは残る
　stop=削除せず停止のみ

docker compose -f /home/a/docker-compose.yml up -d
docker compose up -d --scale unco001=3　（コンテナ名はput-folder-name_unco001_1, put-folder-name_unco001_2, put-folder-name_unco001_3になる）
　-f　ファイルの場所（省略でカレントパス）
　-d　バックグラウンド実行
　--build　コンテナ開始前にビルド
　--no-build　イメージが見つからなくてもビルドしない
　-t　コンテナ停止のタイムアウト（デフォ10S）

docker compose -f /home/a/docker-compose.yml down

　--rmi {all | local}　破棄後にイメージも削除、localの時はimageにカスタムタグが無いイメージのみを削除
　-v　volumesに記載されているボリュームを削除、但しexternalの指定を除く
　--remove-orphans　定義ファイルで定義されていないコンテナを削除

docker compose -f /home/a/docker-compose.yml stop

　コンテナを停止

■Docker composeはコンテナ名を勝手につける
docker-compose.yml内は下記の通り、DockerEngine上のコンテナ名は変わるがdocker-compose.yml内のコンテナ名は変わず指定できる

services:
  unco001

～
  unco002

    depends_on:
      - unco001
    environment:
      WORDPRESS_DB_HOST: unco001
↓
DockerEngine上のコンテナ名は put-folder-name_unco001_1 となる
DockerEngine上で操作したいときは docker ps -a 等で実際の名前を確認して操作する

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
基本はLinuxの機能を使っている

namespaceで分離し

Level1 Ver4.0
■システムアーキテクチャ

周辺機器のon/offや起動ドライブ検索順序はBIOS/UEFI

/proc以下のファイルによりカーネルが認識しているデバイスを確認できる

/dev以下にはデバイスファイルがある

USBはホットプラグデバイス

lsusbでUSBデバイスの情報、lspciでpciデバイスの情報を確認できる

modprobeコマンドでデバイスドライバをロード

起動時にカーネルが出すメッセージはdmesgで表示

SysVinitのシステムでは/etc/inittabでデフォルトのランレベル設定

0：停止、1：シングルユーザモード、5：マルチユーザモードGUI、6：再起動

ランレベル移行はinitやtelinit

systemdのシステムはsystemctlでサービス管理

shutdownでシステム停止や再起動

■インスコとパッケージ管理

インスコにはルートパーティション/とスワップ領域が必要

中大規模では/varや/homeと/は別パーティションが良い

/varはログやメールデータ

/homeは各ユーザのホームディレクトリで肥大化しやすい

スワップ領域は物理メモリと同程度から2倍を確保

GRUBのインスコにはgrub-install

GRUB Legacyの設定ファイルは/boot/grub/menu.lst

GRUB 2の設定は/etc/default/grub、grub-mkconfigを実行すると設定ファイル/boot/grub/grub.cfgができる

共有ライブラリはld.soによってリンクされる

実行ファイルが必要とするライブラリはlddで確認

ld.soが参照する/etc/ld.so.cacheは/etc.ld.so.confを元にldconfigで作成

Debianパッケージ管理はdpkgやAPTツールで、apt-get、apt-cache、aptitudeがある

APT設定ファイルは/etc/apt/sources.list

RPMパッケージ管理はrpmやYUM

rpmでパッケージをインスコするには-i、アップグレードには-Uもしくは-F、アンインスコには-eオプション

rmp -qはパッケージ情報の参照

YUMレポジトリ設定は/etc/yum.repos.dディレクトリ以下のファイルで

■GNU

変数名=値　でシェル変数を設定

echo $変数名　で変数の中身を確認できる

unsetで変数を削除

exportでシェル変数を環境変数に

環境変数を一覧 env や printenv

環境変数とシェル変数を一覧 set

環境変数PATHでコマンドの検索パスを定義

複数コマンドを連続実行は;で区切る

直前のコマンドが成功したときのみ次コマンド実行 &&

失敗した時のみ実行は ||

'や"の囲みは文字列として、`の囲みはコマンドと解釈

"や`の囲みの中は変数展開されるが、'ではされない

historyでコマンド履歴表示

manでマニュアル参照、1:ユーザコマンド、5:ファイルfmt、8:システム管理cmd

属性を保持したままコピーは cp -p

移動先で上書きしたい場合は cp -f、あるいは mv -f

ディレクトリ作成で必要な親ディレクトリを作る場合は mkdir -p

サブディレクトリを含めて削除 rm -r

file でファイルの種別を確認できる

シェルでワイルドカードが使える

. 任意1文字

* 直前の文字の0回以上繰り返し

[] いずれか1文字

[a-c] aからcの範囲

[^ab] aとb以外

^ 行頭

$ 行末

\ エスケープ

+ 直前の文字の1回以上の繰り返し

? 直前の文字の0回もしくは1回の繰り返し

| 左右いずれかにマッチ

コマンドの出力を別コマンドの入力化やファイル格納するにはパイプやリダイレクト

tee 標準入力をファイルに格納し同時に標準出力に出す

ファイルの表示・連結は cat

バイナリファイルを8進数法事するには od

テキストファイルの先頭表示 head、末尾表示 tail、-nで行数

tail -f でファイル末尾を継続監視

テキストファイルの列の取り出しや連結 cut や join や paste

trは文字列を置換

uniqは重複する行を1行にまとめる

xargsで標準入力から受け取った文字を引数にし与えられたコマンドを実行

grepやsedで正規表現を使う

■ファイルとプロセスの管理

gzip, bzip2, xy　はファイル圧縮

unzip, bunzip2, xz(unxz)はファイル解凍

tar, cpio　はアーカイブ作成・展開

chown ファイルやディレクトリの所有者設定

chgrp　は所有グループ変更

chmod　ファイルやディレクトリのアクセス権変更

SUIDやSGID適用のプログラムは実行ユーザに関係なく所有者or所有グループの権限で実行スティッキービットを設定したディレクトリは自分が所有するファイル以外削除不可

アクセス権はファイルは666から、ディレクトリは777からumask値を引いた値

ln　でハードリンク、ln -s でシンボリックリンク作成

ps, pstree, pgrep でプロセス参照、top でシステム状況を一定間隔で表示

kill, killall, pkull でプロセス終了・再起動等

1:HUPハングアップ、2:INT割り込みctl+c、9:KILL強制終了、15:TERM終了デフォ、18:CONT再開、19:STOP一時停止

コマンドラインの最後に&でバックグラウンド実行

jobs でシステム上のジョブを確認

ログアウトでもプログラムを実行しつけるには nohup

free でメモリの利用状況を確認

uptime でシステムの平均負荷を確認

nice でプロセスの実行優先度を指定、変更には renice

ナイス値-20-19で実行優先度を指定

■デバイスとLinuxファイルシステム

fdisk, gdisk, parted でパーティション作成

mkfs でファイルシステムを作成

ext2, ext3, ext4ファイルシステムを作成するには mke2fs

mkswap でスワップ領域を作成

df でファイルシステムの利用状況を確認

du でファイルやディレクトリを含めたサイズを確認

fsck, e2fsck でファイルシステムの整合性チェックや修復

ext2, ext3, ext4ファイルシステムのパラメータ設定は tune2fs

mount でファイルシステムのマウント、解除は umount

継続利用や頻繁利用のファイルシステム情報は /etc/fstab に格納

ディスク利用容量の制限はディスククォータを使う、ハードリミット、ソフトリミット、猶予期間を設定できる

find, locate でファイル検索、locateはあらかじめ準備されたDBに基づいて検索

which, whereis でコマンドのフルパスを表示

Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming.
TDD is dead. Long live testing. (DHH)

I need to hire new techniques to help me solve many of my problems during programming: The pain will fade. Farewell TDD, old friend.
RIP TDD from Kent Beck

そもそもテスト駆動開発の最後のところに、自分で考えてやれって書いてんなぁ、やらんでもええしって。そらそーやろ、自分で考えさせろや、やらんと分からんやろやらせろや

＝＝＝＝＝＝＝＝＝＝＝＝＝＝
終了ーーーーとなりそうだが変な常識
両方でドリドリになる、まとめて行こう

Assertするだけ？、何か一部しかテストでけへんの？
　テストをコード化するのはいい
　テストファーストとテストドリブンとユニットテストは違うらしいで
　javascriptとかテストできんの？

ビジネスをソフトウェアでするだけ
　ソフトウェアを捏ねくりまわしたいのではない

他人が使うソフトウェアなら必要、自分も使うソフトウェアなら不要では
　自分でも使うくらい有用なものであるか
　品質をどこで担保するか、機能だけなのかUXなのか
　スーパープログラマには本質の部分にもっと時間を使って欲しい、死ぬ方が早い
　あんまり機能をリファクターする機会がないかも

＋＋＋＋＋＋＋＋＋＋
ソフトウェア開発

アプリケーションを超シンプルにするとリリース回数が多くなる（質とスピードを上げるにはリリース回数）
アプリの分散と並列も可、競争力はオリジナリティ、政治力か真理性か
原体験、初期衝動は、グラスルーツかグルーピーか

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

新しい（変化する）事は良いことみたいな感じでやってきたところもあるが、今時変化っつーたら怪しいわな。不要な変化を押し付けられたり、本当に変えるべきところを隠すために変化してたり。コンサバでええかもな

＝＝＝＝＝＝＝＝＝＝＝＝＝＝

リーダブルコードの要点整理と活用法をまとめた - Qiita
これはいいな
「良いコード」を書くために意識している17のTips まとめ (zenn.dev)
これも
すべての新米フロントエンドエンジニアに読んでほしい50の資料 - Qiita
知らん事結構ある、keep them simpleだが知っておかんとな、下とか
オリジン間リソース共有 (CORS) - HTTP | MDN (mozilla.org)
JSON Web Token（JWT）の紹介とYahoo! JAPANにおけるJWTの活用 - Yahoo! JAPAN Tech Blog
Overview - Chrome Developers

■RUN

httpリクエストでコンテナを呼び出す

Google Cloud Run を使うまで - Qiita

■ハンズオン(run)
クイックスタート: ビルドとデプロイ  |  Cloud Run のドキュメント  |  Google Cloud
クイックスタート: Cloud Run に Python サービスをデプロイする  |  Cloud Run のドキュメント  |  Google Cloud
基本はFlaskのhttp responseを返すコードである必要があるみたいだ
　Scheduler手動 > Pubsub > Eventarc > Cloud runのでキックで実行がいい

===

===■Run jobs
============

request.form.get('name', None) 第2引数にデフォルト値入れられるらしい

============
functionsのデプロイ時にinternal traffic や allow all trafic等の変更ができる
名前の変更や連携変更はfunctions再作成が必要で面倒

gcloud projects list --filter="bangboo OR fucu" --format=json

gcloud projects list --filter="bangboo OR fku" --format=json | grep -oP '(?<="name": ")[^"]*'

全て想像ですが
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース

ケツが扱う最小単位がPodで1つの機能を持つ（Podは1つ以上のコンテナを含む）
ReplicaSetは複数のPodを組み合わせてアプリを実現する（Podの数の管理機能）
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う（Podのデプロイ管理機能）
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する（Podへのアクセス管理機能）
クラスターはServiceが複数動く環境、1つのMasterと複数のNodeから構成され
　Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う


■流れ
　GKEでクラスタを作成
　Kubectrlをインスコ
　KubectlでPodを立ち上げ＞Deploymentができる、複数Podの起動も

　Kubectlでサービス公開設定
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp)

　サービスアカウント作成
　ネームスペース、kubeサービスアカウント作成
　サービスアカウントとKubeサービスアカウント紐づけ(gcloudとbubectlの両方)
　Yamlで機能を宣言しKubectlでデプロイ


＝＝＝＝＝＝＝＝＝
時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えばArgoワークフローでデプロイ/デリバリー/バッチスケジューラを動かす
　DAG：有向非巡回グラフのやつ
＝＝＝＝＝＝＝＝＝
helmを入れる(kubectrlを使うローカルに)とチャート記述でデプロイができる
　テンプレートがありマニュフェスト記述からkubectrlあたりのデプロイを省力化できる
＝＝＝＝＝＝＝＝＝
masterとworkerで構成され冗長化を考慮すると最低master3台、worker2台～のサーバ要るのでマージドが楽
コンテナにはストレージを置かず外部に持たせた方が良いかも（ステートレスでファイルを保持しない）
DBはK8s上でなくマネージドサービスを使いたい
＝＝＝＝＝＝＝＝＝
VMからOSを抜いてアプリを入れたものがコンテナ、ドッカ―がOS以下を手配
Dockerがコンテナを管理、k8sがそのDockerをオーケストレーション

複数台でまとめたクラスターで故障があっても切り替え可用性を保つ

　そのクラスターをnamespaceで分割し複数チームで利用することも可

稼働中にサーバ追加のスケールをしたりロールバックできる

podにIPを割り振ったり、DNS名を振ったり、負荷分散したり

自動デプロイでコンテナイメージをサーバ群へ展開する

Dockerのホスト管理、コンテナのスケジューリング、ローリングアップデート、死活監視、ログ管理等々

Externalname>LoadBalancer>NodePort>ClusterIP

マネージド以外ならk8s用にユーザ管理も必要

Dockerはアプリイメージという感じ、それらを束ね管理するのがケーツ

Kubernetesとは何かを図でわかりやすく解説！Pod、Na…｜Udemy メディア (benesse.co.jp)
ケツは3か月ごとにアップデートされ知識もアップデート必要だし、バージョンによって機能が変わり古いコードが動かないこともあり大変らしい

＝＝＝＝＝＝＝＝＝
↓実際のアプリがないとイメージ沸かん
クイックスタート: 言語に固有のアプリのデプロイ  |  Kubernetes Engine ドキュメント  |  Google Cloud
コンテナ化されたウェブ アプリケーションのデプロイ  |  Kubernetes Engine  |  Google Cloud
Cloud buildを使用してアプリをコンテナイメージにパッケージ化
GKEでクラスタを作成、コンテナイメージをクラスタにデプロイ
↓手始め？
GKEでnginxを外部アクセス可能にするまで - Qiita
Kubernetesでのコンポーネント間の通信をまとめる - Qiita
GCP におけるコンテナ入門 ~Kubernetes の何がすごい！？ | クラウドエース株式会社 (cloud-ace.jp)

GKE

これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)

■Cloud Loggingで調べる
ログ エクスプローラを使用したサンプルクエリ  |  Cloud Logging  |  Google Cloud
Logging のクエリ言語  |  Google Cloud

/// GCEのPyhon等のロギングを見る

/// コネクティッドシートでBQアクセスするスプシを調べるLoggingのクエリ

connected_sheets

bigquery.Jobs.create

bigquery.googleapis.com

docId

--データセット名

dataset ni_access_sarerudayo

--除外するにはマイナスを頭に付ける

-protoPayload.authenticationInfo.principal Email="washi@jyaroga.com"

■BQインフォメーションスキーマ information schemaで調べる

//// DOL:

SELECT * FROM prj.ds.INFORMATION SCHEMA.TABLES

/// 組織のジョブ:

SELECT DISTINCT 

creation_time,

information_schema.project_id,

user_email,

job_id,

cache_hit,

FROM

`region-us`.INFORMATION SCHEMA.JOBS BY ORGANIZATION AS Information schema,

UNNEST (referenced_tables) AS referenced_table

WHERE

--データコネクタからジョブ実行だと sheets_dataconnector が Prefix

job_id like "%sheets_%"

--参照先+

AND referenced table.project_id = "pri_xxx"

AND referenced table.dataset_Id = "ds_xxx"

AND referenced table.table_id LIKE "tbl_xxx%"

AND DATE (creation_time) BETWEEN "2022-06-01" AND "2023-01-30"

AND error_result IS NULL

/// プロジェクトのジョブ:

SELECT * FROM `pri_xxx.region-us.INFORMATION SCHEMA.JOBS`

,UNNEST (referenced_tables) AS referenced table

WHERE creation_time BETWEEN TIMESTAMP_SUB (CURRENT_TIMESTAMP(). INTERVAL 1 DAY)

AND referenced_table.dataset_id = 'ds_xxx'

--データコネクタからジョブを実行している場合 prefixにsheets_dataconnector、他にはscheduled_query等

AND job_id like "%sheets_%"

/// ラベル:

SELECT * FROM pri xxx.region-us. INFORMATION SCHEMA.JOBS

,UNNEST (referenced_tables) AS referenced_table

,UNNEST (labels) AS label

WHERE creation_time BETWEEN TIMESTAMP_SUB (CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()

AND referenced_table.dataset_id = 'ds xxx

--データコネクタからジョブを実行している場合 labels connected_sheetsが含まれる

AND label.value = 'connected_sheets'

/// ジョブBYユーザ

SELECT * FROM `pri_xxx-region-us.INFORMATION SCHEMA.JOBS_BY_USER`

,UNNEST (referenced_tables) AS referenced_table

,UNNEST (labels) AS label

WHERE creation_time BETWEEN TIMESTAMP_SUB (CURRENT_TIMESTAMP(). INTERVAL 1 DAY) AND CURRENT_TIMESTAMP()

AND referenced_table.dataset_id = 'ds_xxx'

AND label.value = 'connected_sheets'