あそびはここで終わりにしようぜ～

Big Table

でっかいテーブル、読み書き低レイテンシー、RDBは負荷高いときにレプ数位でスケールが難しいがBTはするので正規化せずに単一テーブルにしておく感じ

row keyが主役

データを追加するのに3パターンある(行追加、列追加、セル追加)

　行に複数カラムファミリーにカラムが幾つか入れられるのでKVSだが結局Where句みたいに使う?

　　行キー「企業ID#日付」,COLUMN FAMILY「STOCK PRICE」,COLUMN「HI PRICE」「LO PRICE」に対してJSONデータを入れておく等 

　　時間はバージョン管理として持っている

　複雑な条件は無理でデータを事前整理して入れておき、JSONカラムを使ったりで一行にまとめスキャンを一発で済ます等で高スループットのみ

　　Google検索のようにキーワードを入れると、検索結果が数多く一瞬で返る等

　　複雑な条件はDataprocを使うらしい

Big table構成

インスタンスの中に一つ以上のクラスタ(ゾーン別に設定しレプリケーション)> 各クラスタには1つ以上の同数のノード 

　クラスタに table > 複数Column family > 複数Column > セル

bigtable_app_profilesで転送クラスタ先の設定する(単一行トランザクション設定を含む)

　－マルチクラスタ(自動フェイルオーバ、単一行transaction不可でレプリケーションによる不整合あり) 

　－シングルクラスタ(手動フェイルオーバ、一行transaction) 

デフォルトをマルチにして、通常のクラスタ転送をシングル、問題があるときだけアプリで判定しマルチに行く

スキーマ:

　テーブル

　行キー(row key)

　カラムファミリー(カページコレクションポリシーを含む)

　カラム

更新したデータはタイムスタンプによりセル内で保存される

　解消するにはガベージコレクション

　　期限切れ値、バージョン数で設定する

仕様：

KVS、行指向の行単位でスキャン

各テーブルのインデックス (行キー)は1つのみで一意である必要がある

行は、行キーの辞書順に並べ替えられます。

列は、列ファミリー別にグループ化され、列ファミリー内で辞書順に並べ替えられます

列ファミリーは特定の順序では保存されません

集計列ファミリーには集計セルが含まれます

行レベルでアトミック (複数行だと知らんという意)

　アトミック性:トランザクション整合性がある（一部の操作だけ実行した状態とならずに）
特定の行にread/writeが集中するより分散が良い

Bigtable のテーブルはスバース、空白行での消費はない

gcloud components update

gcloud components install cbt

(-/cbtrcに以下記載すれば-projectと-instance はデフォルト値で省略できる)

cd ~

echo project unco > ~/.cbtrc

echo instance = chinco >> ~/.cbtrc

cbt -project unco listinstances

cbt -instance chinco listclusters

cbt -project unco -instance chinco ls | grep kuso-t

　テーブル名取得

cht -project unco -instance chinco ls kuso-table

　カラムファミリやポリシー等取得

cbt -project unco -instance chinco deletefamily kuso-table shikko-family

cbt -project unco -instance chinco deletetable kuso-table

　テーブルを消せばカラムファミリも削除になる

■pubsub

Publisher app → |GCPの壁| Topic(Schema) → Subscription 1や2 |GCPの壁| → Subscriber app
　サブスクライバーappにPull/PushさせるPull/Pushのサブスクリプションをトピックに紐づける設定をしておく

【図解付き】Cloud Pub/Subに概要や使い方についてわかりやすく解説 - KIYONO Engineer Blog (kiyono-co.jp)

アプリで簡単にPubsubにパブリッシュや、サブスクもできるので、アプリ間の連携にPubsubが使える

　• 非同期処理(画像処理とか重めのもの

　• IDの種類 (message id, subscription id, topic id, ack id, project idあたりがアプリでは使われるっぽい

　　※ack idはpull時のみでPushのときはhttpステータスコードが200でackとなる

トピック（メッセージのパブリッシュ先）
　• スキーマ/外部アクセス許可/リテンション/GCS/バックアップの設定がある (Push/Pullの設定はない)

　• パブリッシュ側のベストプラクティス (JWT) 

　　Pub/Sub トピックにパブリッシュするためのベスト プラクティス  |  Pub/Sub ドキュメント  |  Google Cloud

サブスクライバのPushとPull (PushはEndpointが必要、デフォルトはpull)

　GCP - Pub/Sub サービス概要 #GoogleCloud - Qiita

　• at-least-once (少なくとも1回) 配信を提供します

　• 同じ順序指定キーを持ち、同じリージョンに存在している場合は、メッセージの順序指定を有効にできます

　• サブスクライバーが31日間未使用、またはサブスクリプションが未更新の場合、サブスクリプションは期限切れ

　• メッセージ数が多いとpull向き サブスクリプション タイプを選択する  |  Pub/Sub ドキュメント  |  Google Cloud

pushはhttpsが必要?

　push サブスクリプションを作成する  |  Pub/Sub ドキュメント  |  Google Cloud

　• push エンドポイントのサーバーには、認証局が署名した有効な SSL証明書が必要でhttps

　• Cloud run でEvent Arcを設定するとサブスクが自動作成されrunのデフォルトhttpsのURLが使われるが、これはPullよりPushで安定した

　• CronバッチならPullで安定するのでは?大量リクエストはPull向きとある(Pullは失敗処理込みの話かも知れん)

トピックのリテンション:デフォルトなし、最小値:10分、最大値:31日

サブスクのリテンション:デフォルト値:7日、最小值:10分、最大値:7日

　サブスクリプション プロパティ  |  Pub/Sub ドキュメント  |  Google Cloud

pubsub ack期限(Ack Deadline)
　•デフォルト60秒> 設定10分>ack延長で最大1時間まで伸ばせると思われる

　リース管理で確認時間を延長する  |  Pub/Sub ドキュメント  |  Google Cloud

　•exactly onceを設定しなければ期限の延長は保証されない

　•ack期限を過ぎる、あるいはNackを返す場合、メッセージは再配送される

　•ack応答期限の延長は99パーセンタイル(上位1%の値よりも小さい値のうち最大の値)で

　modifyAckDeadlineを返し、延長してもMaxExtension (ack期限を延長 する最大値) 60minまで?
　　modifyAckDeadlineリクエストを定期的に発行すればよいらしい

メッセージの再試行を強制するには
　•nack リクエストを送信

　•高レベルのクライアント ライブラリを使用していない場合は、ackDeadlineSeconds を0に設定して modifyAckDeadline リクエストを送信する

exactly once
1 回限りの配信  |  Pub/Sub ドキュメント  |  Google Cloud

　•pullなら設定できる。他には、Cloud Dataflowを組み合わせる(プログラムコードでDataflowを使う感じかり、あるいはmessageについているunique idを利用して、KVS を用いたステート管理をして自前で重複を排除する

　•再配信は、メッセージに対してクライアントによる否定確認応答が行われた場合、または確認応答期限が切れる前にクライアントが確認応答期限を延長しな かった場合のいずれかか原因で発生することがある。

pubsubはトピックにPublishされたメッセージをDataflowに引き継げる

　•Apache Beamのウィンドウ処理とセッション分析とコネクタのエコシスエムがある

　•メッセージ重複の削除ができる

　•pubsub>dataflow>BQやGCS: この流れでログ等をストーリミングで入れ込める

BQサブスクリプション (PubSubはBigQuery Storage Write API を使用してデータを BigQueryテーブルに送信、GCSサブスクもある)

　Langganan BigQuery  |  Dokumentasi Pub/Sub  |  Google Cloud

　BigQuery サブスクリプションの作成  |  Pub/Sub ドキュメント  |  Google Cloud

サブスクライバーApp側のコードでのフロー制御によりちょっと待てよのトラフィック急増対応

　フロー制御を使用して一時的な急増を処理する  |  Pub/Sub ドキュメント  |  Google Cloud

デッドレタートピック (配信試行回数が見れる)やエラーでの再配信

　メッセージ エラーの処理  |  Pub/Sub ドキュメント  |  Google Cloud

　 • Pub/Subサブスクリプションにデッドレタートピックを設定しておくと、一定の回数再送信が失敗したメッセージの宛先がデッドレタートピックに変更され貯められる

メッセージのフィルタ、同時実行制御により多いメッセージに対応

　サブスクリプションからのメッセージをフィルタする  |  Pub/Sub ドキュメント  |  Google Cloud

Pubsubをローカルでエミュレートする

　エミュレータを使用したローカルでのアプリのテスト  |  Pub/Sub ドキュメント  |  Google Cloud

pubsubのスナップショットやリテンション

トピックにリテンションを設定しスナップショット作成> 過去のサブスクしたメッセは見えなさそう

サブスクにリテンションを設定しスナップショット作成> 過去のAckしたメッセは見えなさそう

スナップショットでどう使うのか?

　cloud pubsubで配信済みのメッセージを再送する #PubSub - Qiita

　キューがたまっているときに撮るものと思われる。またシーク時間のポイントを設定する意味がある

　スナップショットとシークを使いこなして特定期間の再実行を行う機能

　　スナップショットで再実行する

　　シークは指定時間か最後のスナップショット以降のサブスク再実行(実際pushでrunが再実行された)

Pubsubにどんなメッセージが入ってきているか確認する方法

　pull形式ならAckしなければpullボタンで拾い見れる (トピックでパブリッシュしてサブスクでPull し見る)

　トラブルシュートはログを見るかデッドレタートピックかGCSバックアップを見る?

デッドレターキュー(ドロップしたものの確認と救済?)

　サブスクでDLQのONしデッドレタートピックを設定し転送する>GCSにもバックアップできる

　DLTでメッセージ(実行済みOR未実行)の再生

データ形式:スキーマを使うか、スキーマなしならdataで取得できる

　トピックのスキーマを作成する  |  Pub/Sub ドキュメント  |  Google Cloud

　Cloud Pub/Subの概要とPythonでの実践 - case-kの備忘録

from google cloud import pubsub_v1

from avro.io import DatumReader, BinaryDecoder

from avro schema import Parse

project_id="your-project-id"

subscription id="your-subscription-id"

subscriber pubsub_v1.SubscriberClient()

subscription_path = subscriber.subscription_path(project_id, subscription_id)

avro_schema = Parse("""

{

"type": "record",

"name": "Avro".

"fields": [

{

"name": "ProductName",

"type": "string",

"default":""

},

{

"name": "SKU",

"type": "int",

"default": 0

}

}

def callback(message):

subscriber.subscribe(subscription_path, callback=callback)

def callback(message):

helm create <チャート名>

templates/ マニフェスト (テンプレート)

env/ 自分で作成するが環境毎に異なる値の入る変数を記述

┣dev.yaml

┣prd.yaml

values.yaml 繰り返す値等 (dev/prd.yamlが優先され上書きされる) 

helm upgrade-install <release名> <Helmチャートの圧縮ファイル名>

●●helmテンプレートの文法 (.ファイル名.親.子で表す、.はルートオブジェクト、Valuesはvaluesオブジェクト、$変数:=値、ymlインデントはスペース2つ)

●templates/deployment.yaml

{{ $env := Values.environment }}

{{ $serviceAccountName := Values.serviceAccountName }}

image: {{ .Values.deployment.image }}:{{.Values deployment.imageTag }} //nginx:latest

serviceAccountName: {{ $serviceAccountName }}-{{ $env }} //sample-sa-dev

↑

●values.yaml

deployment:

  image: nginx

  imageTag: latest

serviceAccountName: sample-sa

●env/dev.yaml

environment: dev
※values.yaml よりdev/prd.yamlが優先され上書きされ.Valueで使う

●●helmテンプレートのループ (range～end)

●templates/es.yaml

spec:

  nodeSets:

  ((- range .Values.es.nodeSets }}

  name: {{ .name }}

  config:

    node.attr.zone: {{ .zone }}

  {{- end }}

↑

●values yami

es:

  nodeSets:

  - name: node-a

    zone: asia-northeast1-a

  - name, node-b

    zone: asia-northeast1-b

●●helmテンプレートのIF (if-end)

●templates/ingress.yaml

((- if .Values.ingress.enabled -))

apiVension: networking k8s.io/v1

kind: Ingress

{(- end }}

●env/prd.yaml

ingress:

  enabled: true

●env/dev.yaml

ingress:

  enabled: false

●●helmテンプレートの複数値 (toYaml、nindentは関数)

●templates/ingress.yaml

metadata:

  annotations:

    {{- toYaml .Values.ingress.annotations | nindent 4 }}

●values.yaml

ingress:

  annotations:

    kubernetes.io/ingress.global-static-ip-name: sample-ip-name

    kubernetes.io/ingress.class: "gce-internal"

●●その他

中括弧内側の前後にダッシュ {{--}} をつけることができ、前に付けた場合は前の半角スペースを、 後ろにつけた場合は改行コードを取り除く

hoge:

  {{- $piyo := "aaa" -}}

  "fuga"

/* */で囲まれた部分はコメント構文

{{-/* a comment */ -}}
.Releaseでリリースの情報を使用できる
{{ .ReleaseName }}とか{{ .ReleaseNamespace }}

●●_helpers.tpl
Helmの_helpers.tplを使える人になりたい #kubernetes - Qiita

helm create [チャート名]で自動でtemplates ディレクトリに_helpers.tplが作成されるが、 partialsやhelpersと呼ばれる共通のコードブロック (defineアクションで定義されtemplateアクションで呼び出される)や、ヘルパー関数などが定義される。

_アンスコ始まりのファイルは、他のテンプレートファイル内のどこからでも利用できるという共通部品。 これは内部にマニフェストがないものとみなされる。

種類としては、values.yamlが差し替え可能な変数、ローカル変数が定義したTemplateファイル内でのみ使える変数、_helpers.tplはチャート内で自由に使える変数

●templates/_helpers.tpl

{{- define "deployment" -}}

apiVersion: apps/v1

kind: Deployment

metadata:

  labels:

    app: {{.name }}

    name: {{ .name }}-deployment

spec:

  replicas: {{ .replicas }}

  selector:

    matchLabels:

      app: {{ .name }}

  template:

    metadata:

      labels:

        app: {{.name}}

    spec:

      containers:

      - image: {{ .image }}

        name: {{ .name }}

{{- end -}}

●values.yaml

nginx:

  replicas: "1"

  name: nginx

  image: docker.io/nginx:1.25.1

httpd:

  replicas: "3"

  name: httpd

  image: docker.io/httpd:2.4.57

●deployment-nginx.yami

{{ include "deployment" .Values.nginx }}
※{{ include "deployment" 引数 }}で関数を呼ぶ

●●英語サイトだともっと情報がある
Helm | Built-in Objects
.Filesなどのビルトインオブジェクトがあったりと、、、

モダンか何か知らんが、豚玉かイカ玉で十分じゃ

＝＝＝＝＝＝＝＝＝＝＝
kubectlチートシート | Kubernetes

フォルダに .py と requirements.txt と .dockerignore と Dockerfile を入れてアップロードしている

gcloud builds submit --tag asia-northeast2-docker.pkg.dev/bangboo-prj/xxx/image001

helloworld@bangboo-prj.iam.gserviceaccount.com 作成

アクセス元のIPを確認するCloud run作成

　ドメインないと無理なのでLBとIAPをあきらめ生成されるURLで十分

　Cloud runでアクセス元IPを表示するヤツ

　runのallUsersのinvokerを削除したらアクセス不可になった（この方法で管理する）

curl http://ifconfig.me/ で十分だったが

GKE
k8sの内部NWは通常別途いるがGKEは速い奴が動作
GKEはクラスタ内部のDNSでサービス名で名前解決できる
サービスのIPとポートは環境変数で参照可
kubectlを使うには、gcloud container cluters get-credentials　を打つ必要がある

GKE設定

-クラスタ:側の設定（IP範囲とかセキュリティとか？）

　一般/限定公開:外部IPを使うか使わないか

　コントロール プレーン承認済みネットワーク：CPにアクセスできるセキュリティ範囲

-ワークロード:マニフェストで設定

一般か限定公開か？コントロールプレーンが外部IPか？CPがグローバルアクセス可か？承認NWか？

　一般公開で承認NWが良いのでは？簡単だし、

　限定公開で使うには＞CPに外部IPで承認NWでいいのでは？

　　NW:default subnet:default

　　外部IPでアクセス許可

　　CP アドレスの範囲 192.168.1.0/28とか172.16.0.0/28(サブネット重複しない奴)

　　コントロール プレーン承認済みネットワーク home (169.99.99.0/24ではなくGCPのIPぽい)

　　限定公開ならnatが要る

　CPの VPCのIP範囲は、クラスタの VPC 内のサブネットと重複不可。CPとクラスタは VPC ピアリングを使用してプライベートで通信します

　グローバルアクセスは別リージョンからという意味っぽい、cloud shellからのkubectlのためONが良い

デフォルト設定なら作成したサブネットのIP範囲でなくクラスタが作られない

　面倒ならdefault-defaultで良いかも

ARにあるコンテナからGKEをデプロイが簡単にできる

Cloud Source Repositories　でソース管理gitが下記のようにできる

　gcloud source repos clone bangboo-registry --project=bangboo-prj

　cd bangboo-registry

　git push -u origin master

run使用中のコンテナがGKE上では上手くいかない runのコンテナは8080のようだ

　Dockerfileとmain.py上ではポートは何でもよい仕様だが、runで自動的に8080割り当てるようだ

　　それが駄目でありGKEは環境変数でPORT 8080を指定

　　CrashLoopBackOff問題がでる

　　https://www.scsk.jp/sp/sysdig/blog/container_security/content_7.html

デプロイ公開でポート80　ターゲットポート8080に（クラスタを作成後、ワークロードでデプロイする）

developmentのspec: containers: ports: - containerPort: 8080　を入れる？

　yamlでなく、コンソールで設定時に入れると良い

$ kubectl get all

NAME                      TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE

service/flask-1-service   LoadBalancer   10.48.4.134   34.97.169.72   80:32147/TCP   20m

us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

　これは簡単に上手く行く、環境変数PORT8080不要

　クイックスタート: アプリを GKE クラスタにデプロイする  |  Google Kubernetes Engine (GKE)  |  Google Cloud

ワークロードでyamlの spec: replicas: 0を保存するとアクセスを止められる

コンフィグマップ：構成ファイル、コマンドライン引数、環境変数、ポート番号を別途持っていてPodにバインドする(マニフェストに書くと抜き出され見れる)

シークレット：Base64の値？(マニフェストに書くと抜き出され見れる）甘いのでsecret mgrを使う方が良い？

　config map/secretはマニフェストで編集する必要がある（見れるだけと思われる）

エディタで見てみる：yamlとかステータスが見れる

■LBに静的IPを振る

ArmorでIP制限

１）サービスから対象を選択しingressを作成することでLBを追加しArmorも設定可能

２）デフォルトLBに付けるにはkubectl要りそう、backendconfig.yamlはどこに置く

　Cloud ArmorでGKE IngressへのアクセスをIPで制御する #GoogleCloud - Qiita

サービス画面のkubectrlから

# backend-config.yaml　を作り　kubectl apply -f backend-config.yaml

apiVersion: cloud.google.com/v1

kind: BackendConfig

metadata:

  namespace: default

  name: hello-backend-config

spec:

  securityPolicy:

    name: "bangboo-armor"

serviceのyamlに下記を追加

metadata:

  annotations:

    cloud.google.com/backend-config: '{"ports": {"8080":"hello-backend-config"}}'

↑これでは不足する 

どこで設定状態を見るか？

ingress作成してLBとArmorつけて、デフォルトLBを削除してみる？

GKEの外部からのアクセスを制限するには？

　限定公開＋コントロールプレーンは承認済み等でアクセスしKubectlする

　ArmorでIP制限＋アダプティブ設定（ArmorはLBが要る）
GKEでNodePort TypeのServiceに対してインターネットアクセス許可する - IK.AM

限定公開クラスタ＋踏み台サーバにIAPで入りKubectl（承認済みNWでの制御はIPのみなので危ういらしい）
GKE(Google Kubernetes Engine) Autopilotの限定公開クラスタにIAPを利用してアクセスする | Tech-Tech (nddhq.co.jp)
【GKE/Terraform】外部ネットワークからの全てのアクセスを制限した限定公開クラスタを作成し、踏み台サーバーからkubectlする (zenn.dev)
コントロールプレーンとPod間で自動FWされない場合もありFirewall要チェック

GKEでPythonをCron定期実行させたい

ArgoでDAGを実行させたい

　https://zenn.dev/ring_belle/articles/2c4bbe4365b544

ArgoでGKEのCICD（Argoは別ホストでGithubにアクセスし、GKEを操る）

　https://www.asobou.co.jp/blog/web/argo-cd

サービスアカウント
Workload Identity Federation for GKEの新しい設定方法を解説 - G-gen Tech Blog
３）Workload Identity Federationをつかう

●メモ
忙しいときはスケールアウトするが、落ち着き始めるとスケールinし、必要なPodも落とされてしまう

safe-to-evict　をymlのannotationで明示して特定Podはスケールinしない等にしておく

annotations:

  cluster-autoscaler.kubernetes.io/safe-to-evict:"false"

クラスタのオートスケーラー イベントの表示  |  Google Kubernetes Engine (GKE)  |  Google Cloud

■Workloads リソース

Pod：Workloadsリソースの最小単位

ReplicaSet：Podのレプリカを作成し、指定した数のPodを維持し続けるリソースです。

Deployment：ローリングアップデートやロールバックなどを実現するリソースです。

DaemonSet(ReplicaSet亜種)：各ノードにPodを一つずつ配置するリソースです。

StatefulSet(ReplicaSet亜種)：ステートフルなPodを作成できるリソースです。

Job：Podを利用して、指定回数のみ処理を実行させるリソースです。(使い捨てPod)

CronJob：Jobを管理するリソースです。

Config connector：GKEでGCPリソースを調節してくれるアドオン。Podの増加減少にあたり必要なアカウントや権限やPubSub等々を自動作成や管理する。マニフェストのymlにcnrmのAPIを記載したりする（Config connector resource nameの略）

Config Connectorを試してみる (zenn.dev)

■GKE関連の運用

GKEクラスタ認証ローテーション

30日以内になると自動ローテーションするが危険なので手動が由

GKEはマイクロサービスのエンドポイントでのサービス提供かgcloud api利用が前提といえるのでこれでOK

1) ローテ開始 (CPのIPとクレデンシャル)

2) ノード再作成

3) APIクライアントを更新 (クレデンシャル再取得)

4) ローテ完了 (元IPと旧クレデンシャルの停止)

クラスタ認証情報をローテーションする  |  Google Kubernetes Engine (GKE)  |  Google Cloud

GKEクラスタ認証ローテーションの考慮

Google Kubernetes Engine のクラスタ認証情報をローテーションするまでに考えたこと - DMM inside

セキュアなGKEクラスタ

それなりにセキュアなGKEクラスタを構築する #GoogleCloud - Qiita

コントロールプレーンの自動アップグレード＆IPローテーション＆ノードブールの自動アップグレードで死ぬ

GKEシングルクラスタ構成で障害発生してサービス停止しちゃったのでマルチクラスタ構成にした話 (zenn.dev)

　CPの更新後はクレデンを取得しなおす必要がある、ArgoでCICDを組んでいるとクラスタに認証入りなおす必要がある
　ノードが入れ替わりに時間が掛かり、時間差で問題がでることがあるので注意

●共有 VPC
　同組織のプロジェクトのホストプロジェクト(親)のVPCをサービスプロジェクト(子)に共有

●VPC ネットワーク ピアリング
　異なる組織間の接続（双方のVPCでコネクションを作成する、内部IPで通信する、サブネットは重複しないこと、2ホップ制限で1:1＝3つ以上の場合は古メッシュでコネクション作成要）、k8sサービスとPod ipをVPCピアリング経由する利用法もある

●ハイブリッド サブネット

　Cloud VPN/Interconnect等が必要、オンプレルータとCloud RouterをBGPでつなぐ、オンプレとGCPをつなぐ
●内部範囲
　VPCで使うIPをCIDRで定義しIP範囲の使用方法を事前に決定しておく、IPが勝手に使われたりしない等ができる

●限定公開の Google アクセス（Private Google Access）
　外部IPを持たないGCE等はデフォルトのインターネットゲートウェイ0.0.0.0を経由してGoogle APIにアクセスする、VPC＞Routesで見れる
●オンプレミス ホスト用の限定公開の Google アクセス

　CloudVPNやInterconnectを経由してオンプレから内部IPを利用してGoogleAPIにアクセス、GCP側ではCloudDNSで特定のドメインのAレコードを入れる、選択したドメインのIPアドレス範囲を静的カスタムルートでVPC内のプライベートIPからルーティングできるように設定する、オンプレにはCloudRouterからドメインのIPアドレス範囲をBGPでルーティング広報する、VPNやInterconnectがないと0.0.0.0でGoogleAPIにアクセスするがこれだとRFC1918に準拠しない199.33.153.4/30などのIPを使う必要がありルーティングが複雑化したり、オンプレを通る場合があり通信は慎重に設計をすること

●Private Service Connect

　「限定公開の Google アクセス」の発展版、オンプレをNATでVPCに接続、内部IPでGoogleAPIにアクセスできる、PSCエンドポイントを介して内部IPで公開できる、NATされ内部IPの公開先での重複OK

●プライベート サービス アクセス
　VPCペアリングを併用してサービスプロデューサをVPCに接続し内部IPで次のようなサービスに内部IPでアクセスできるようにする（Cloud VPNまたはInterconnectを付け足せばオンプレからも可）、Cloud SQL/AlloyDB for posgre/Memorystore for Redis/Memcached/Cloud build/Apigee等の限られたもの

●サーバーレス VPC アクセス
　サーバレスからVPC内リソースにアクセスするためのコネクタ（通常は外部IP通信になるがコレだと内部IPでVPCにルーティングされる、/28のサブネットを指定）、例えば既存のcloud runサービスを編集しても付けられず初期構築時のみ設定できる

●外部 IP アドレスを持つ VM から API にアクセスする
IPv6をVMに設定し限定公開DNSゾーン設定をすればトラフィックはGCP内にとどまりインターネットを通りません

●CDN Interconnect
　Cloud CDNもあるが他社のCDNに接続する、Akamai/Cloud flare/fastly等々

●Network Connectivity Center 
　ハブとなりCloudVPN/InterconnectをメッシュしGCP/オンプレ含め通信させる、Googleのバックボーンでユーザ企業の拠点間を接続できる

●ダイレクト ピアリング
　GoogleのエッジNWに直接ピアリング接続を確立し高スループット化、Google workspaceやGoogleAPI用だが普通は使わずInterconnectを使う

●キャリア ピアリング
　ダイレクトピアリングの高度な運用が自社対応できない等でサービスプロバイダ経由でGoogle workspaceなどのGoogleアプリに品質よくアクセスする

Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog

＝＝＝＝＝＝＝＝＝＝＝＝＝
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - (フリル)

機械学習：

　マシーンラーニング、ML。マッシーンがLearnしデータの背景にあるルールやパターンを発見する。

モデル：

　機械学習における入力データに対して結果(出力)を導き出す仕組み。モデルは入力されたデータを解析し、評価/判定を行った結果を出力として返す。つまり、機械学習は「入カ＞モデル＞出力」から成る。

学習データ

　モデルをつくるために学習させるデータ

適用データ

　モデルに対して予測を適用させるデータ

教師あり

　学習データに対して正解ラベルを付けて学習する方法

　　例)過去にDMを送付した結果(目的変数)を用いて学習させる

教師ありは、回帰と分類の2つに分けられます。

　回帰(予测)

　　連続する数値を予測するもので、売上、重量、温度などを算出する

　分類(識別)

　　データがどのクラスに属するかを予測するもので、販売商品が売れる見込み/売れない見込みなどに分類

　　DMにおいては分類モデル(買う・買わないの識別)を使用

目的変数

　結果側の変数

　例)ある特定のカテゴリやブランドをその顧客が注文する

　　●確率(購入する・しない)

　　　ー学習データにターゲットフラグ (購入あり=1、購入無し=0)を立てる

　　　ー適用後に出てくる結果は0～1 (0%～100%) の範囲

　　●金額

説明変数(特微量とも呼ぶ) 

　原因側のデータ

　目的変数を予測するために使用する顧客の様々な情報、大きく分けて2種類

　　●顧客属性

　　　ー法人/個人事業主など事業形態、登録住所の郵便番号、業種コードなど

　　●購買履歴

　　　ー購買 いつ、何を、どのくらい購入したか等の情報

　　　ー各商品カテゴリ毎の購入金額 etc.

質的変数

　数値で推し測ることができ、数字の大小に意味をもつデータ

　　(例)売上、購入回数、従業員数、DM送付回数

單的変数

　単に分類や種類を区別するためだけのデータ

　　(例)都道府県、茎種コード、購入有無

統計手法

　重回帰分析:

　　説明変数xが目的変数yの値を変化させます。そのため、説明変数から、目的変数の値を予測可能です。

　ロジスティック回帰

　　yが1になる確率を判別します。いくつかの要因(説明変数)から「2値の結果(目的変数)」が起こる確率を説明・予測

　　　2値の結果とは合格/不合格、採用/不採用など、答えが2つしかない場合を指し

線形回帰（エクセル）
　slope関数：回帰直線の傾きを取得
　inercept関数：回帰直線の切片を取得
　forecast関数：単回帰分析からの推測値を取得
+++++++++++++

■プロジェクト削除時のサービスアカウント

=========================
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

Dockerボリューム共有ともいう

■ボリュームマウントの確認や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 .

■Appコンテナ（PHP)

■アプリ
/// 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の作り方を考え直したらすごく効率が上がった。 (zenn.dev)

■ビルドでイメージを作成
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 container 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 等で実際の名前を確認して操作する

■コンテナ デバッグ
３部: デバッグノウハウ ( 番外編 )｜実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 (zenn.dev)

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
基本は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
　nohup python main.py &
　ログアウトしてもバックグラウンド ジョブを継続する方法 (codereading.com)

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 でコマンドのフルパスを表示