■21/12/2 12:16AM
B=AIDMA R MAT SURE
フォッグの消費者行動モデル B=MAT
行動Behavior = 動機Motivation（やりたい:利） × 実行能力Ability（簡単そう） × きっかけTrigger（背中押し）
https://note.com/akira_miyazaki/n/nb32211b94102
お気にのAIDMA
[Click for image]
他にも亜種が
AISAS / AISCEAS / AIDA / AIDCA / AIDCAS / AMTUL / SIPS / AISA / ARCAS / AIDEES / SAIDCAS
AIDMAと外的動機づけ(褒美Reward)と内的動機づけ(Fogg)とで人は動いている
B=AIDMA R MAT
@2020-01-16
================
■行動経済学の使い方
人の意思決定の癖
１）プロスペクト理論：確実性が高いものが好まれる、損失は嫌いで回避される
２）現在バイアス：今この時点の自分は可愛い、時間が必要な効用の期待は割り引かれる
３）社会的選好：互恵性があり自分だけが得することも損することも避ける
４）ヒューリスティックス：直感的意思決定、人はサンクコストに耐えられない、極端も無理で平均的なものを選択しがち
人は合理的な意思決定はせず(馬鹿だから期待値が最大の所でなく)予測可能な所にずれる
→医者は患者が正しい判断をしてくれるよう口説きたい（ナッジで合理的意思決定に誘導したい）
パチンコ/競馬/宝くじ/保険は胴元が儲かるように設計されている
→他人に合理的に判断させないようにして、その分を利益として分捕りたい（スラッジ）
●「確実でコレを逃すと損をします、貴方は正しく貴方の所有物の価値は高いですが、コレは利己的ではなく、どう見てもこの選択が正しく見える」あるいは「コレは損するので避けて」というフレーミングを使う
●期待値でビジネスを計算し、ズラした分を利益として分捕る
●アンカリング(時間の単位や金額の単位、労働量の単位等の単位が人の意識の中にある)で参照点を上げ下げし利益を最大化する
●何もしなければ人は現状維持で、先延ばしするので利益をもたらしてくれるよう働きかけ続ける
●互恵性で貴方が施せば相手も少し返してくれる、これを続けることで関係性を築き、長期で利益を確保する
●間接税みたいな間接徴収にして幾ら払っているか分かりにくくする、メンテ費が掛かる等
使い方
1) 意思決定のプロセスを図式化2) バイアスを推測（能動的、受動的自動的、情報ソースetc)3) ナッジ候補を考える4) ナッジ候補上位をテスト実行5) 効果測定6) 全体に適用する
Comment (0)
■21/6/9 12:01AM
k8s
全て想像ですが
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース
ケツが扱う最小単位がPodで1つの機能を持つ（Podは1つ以上のコンテナを含む）
ReplicaSetは複数のPodを組み合わせてアプリを実現する（Podの数の管理機能）
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う（Podのデプロイ管理機能）
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する（Podへのアクセス管理機能）
クラスターはServiceが複数動く環境、少なくとも1つのMaster(node)と複数のNodeから構成され
Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う
（非マネージドなら単一障害点にならないようマルチMaster3台が一般的）
cluster > namespace > node x workload (pod, <複数pod:deployment, job, statefulset>, <全てのnodeにpod:deamonset>)
namespaceは論理的な分離、node poolは物理ノード・スケーリング管理
■ケツリソース一覧
Node：Kubernetes クラスタで実行するコンテナを配置するためのサーバNamespace：Kubernetes クラスタ内で作る仮想的なクラスタPod：コンテナ集合体の単位で、コンテナを実行する方法を定義するReplicaSet：同じ仕様のPodを複数生成・管理するDeployment：Replica Setの世代管理をするService：Podの集合にアクセスするための経路を定義するIngress：Service を Kubernetes クラスタの外に公開するConfigMap：情報を定義し、Podに供給するPersistentVolume：Podが利用するストレージのサイズや種別を定義するPersistentVolumeClaim：PersistentVolumeを動的に確保するStorageClass：PersistentVolumeが確保するストレージの種類を定義するStatefulSet：同じ仕様で一意性のあるPodを複数生成・管理するJob：常駐目的ではない複数のPodを作成し、正常終了することを保証するCronjob：cron記法でスケジューリングして実行されるJobSecret：認証情報等の機密データを定義するRole：Namespace 内で操作可能な Kubernetes リソースのルールを定義するRoleBinding：Role と Kubernetes リソースを利用するユーザーを紐づけるClusterRole：Cluster 全体で操作可能な Kubernetes リソースのルールを定義するCluster RoleBinding：ClusterRole と Kubernetes リソースを利用するユーザーを紐づけるService Account：Podに Kubernetes リソースを操作させる際に利用するユーザー
流れ Dockerfile(設定)とアプリをdocker build/pushし DockerレジストリにDockerイメージを作成 GKEにデプロイ(deploymentファイル.yml/serviceファイル.ymlをkubectrl create/apply：manifest) レプリケーションコントローラ:Pod数、オートスケールをdeployment fileで設定 サービス定義：ノードのproxyデーモンが複数Podに負荷分散 ノードがクラスタ内のPod同士に振分けるクラスタIP LBが振分ける外部IPを設定K8s クラスタリング（複数サーバを束ねる） コールドスタンバイ、ホットスタンバイ（フェイルオーバ） オーケストレーション…NW、Storage、スケジュール、IP、ルーティング、負荷分散、監視、デプロイ（ローリングアップデート） 構成 マスターサーバ（コントロールプレーン）←kubectrl
etcd（DB:kvs形式のconfig=マニフェスト、デプロイメントとサービス等を記述） レジストリサーバ（コンテナレジストリ：GCSに保存）
↓ ワーカーノード＞Pod＞コンテナ(webサーバ)、コンテナ(ログ収集)、仮想NIC ワーカーノード、ワーカーノード…GKE コンソールで設定＋kubectrl コンソール：GCE、ストレージ、タスクキュー、BQ、cloudSQL、cloudDataStore、cloudソースレポジトリ、StackDriverLogging、StackDriverMonitoring、StackDriverTrace、CloudPlatform、BigTable、Pub/Sub、サービスコントロール、サービス管理
※コンソールだけでkubectrl無しでイケそう
クラスタ作成＞ワークロードでコンテナデプロイ、あるいは直接デプロイで簡易でイケる
クラスタ作成をすると一般公開で承認NW、あるいは限定公開、はたまたIP範囲とか詳細を決められる
■流れ
GKEでクラスタを作成
Kubectrlをインスコ
KubectlでPodを立ち上げ＞Deploymentができる、複数Podの起動も Kubectlでサービス公開設定
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp)
サービスアカウント作成
ネームスペース、kubeサービスアカウント作成
Yamlで機能を宣言しKubectlでデプロイ
Pod(論理ホスト/インスタンスみたいな) 一意のIPが自動的に割り当てられる、Pod間はIPで通信 Pod内のコンテナはlocalhost:ポートで互いに通信、コンテナ間で共有するストレージ Podを直接作成は非推奨 CPU/メモリの最小と最大を設定
k8sのsecretリソース(≒SA key)はPw/Oauthトークン/SSH key等を含むオブジェクト(base64エンコード生) 使う方法3種類：コンテナにマウント、コンテナの環境変数、Pod生成時にケツがpull どこに置くか、どう暗号化するか、gitに置かない等の考慮が必要
別途記載がある
/// BANGBOO BLOG /// - GCP part2
/// BANGBOO BLOG /// - GKE
＝＝＝＝＝＝＝＝＝
時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えば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とは？仕組みと構造をわかりやすく解説 - カゴヤのサーバー研究室 (kagoya.jp)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
[Click for image]
これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)
GKEクラスタをコンソールで作成
NATを作成
Cloud shellを起動
k8s用の認証情報を取得$ gcloud container clusters get-credentials <standard-cluster-1> --zone asia-northeast1-ak8sオブジェクトを表示$ kubectl get allnginx dockerイメージを起動$ kubectl run <handson> --image=nginx --port 80LBを作成しトラフィックを流す設定$ kubectl expose deploy <handson> --port=80 --target-port=80 --type=LoadBalancerサービスを表示（LBを見る）$ kubectl get serviceレプリカセットを表示$ kubectl get replicasetポッドを表示$ kubectl get podポッドを削除$ kubectl delete pod <handson-86f796b8b7-m68sr>nginxコンテナ3台を立てる$ kubectl run <handson-2> --image=nginx:1.14 --replicas=3ポッドの詳細情報を表示$ kubectl describe pod <handson-2-85dfb7fd88-wr58c>デプロイメントを表示$ kubectl get deploymentdockerイメージのバージョン変更$ kubectl set image deployment <handson-3> <handson-3>=nginx:1.15デプロイメントのレプリカセットの履歴を表示$ kubectl rollout history deployment <handson-3>$ kubectl rollout history deployment <handson-3> --revision=1デプロイメントのロールバック（nginx:1.14に戻す）$ kubectl rollout undo deployment <handson-3>デプロイメントを削除$ kubectl delete deploy/<handson-2>サービスを削除$ kubectl delete service <handson>
マニフェストを作成（デプロイメントとサービス）vi manifest.yaml apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: run: handson-4 name: handson-4 spec: selector: matchLabels: run: handson-4 template: metadata: labels: run: handson-4 spec: containers: - image: nginx name: handson-4 ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: labels: run: handson-4 name: handson-4 spec: ports: - port: 80 targetPort: 80 selector: run: handson-4 type: LoadBalancerマニフェストを適応（nginxとLBが作成される）$ kubectl apply -f manifest.yamlマニフェストで定義したオブジェクトを削除$ kubectl delete -f manifest.yaml
Dockerfileの作成$ vi Dockerfile FROM google/cloud-sdk:latest COPY . /app RUN make app CMD python /app/app.pyDockerビルド$ docker build -t myapp .ビルドしたコンテナを起動$ docker run -p 3000:3000 myapphttp://localhost:3000 へアクセスして確認コンテナにタグ付け$ docker tag myapp asia.gcr.io/${prjid}/myappGCRの認証$ gcloud auth configure-dockerリポジトリへPush$ docker push asia.gcr.io/${prjid}/myappデプロイ$ kubectl run myapp --image=asia.gcr.io/${prjid}/myapp$ kubectl expose deploy myapp --port=80 --target-port=3000 --type=LoadBalancerポッドを増やす$ kubectl scale deployment myapp --replicas=3確認$ kubectl get all -l run=myapp
クラスタを削除$ gcloud beta container clusters delete standard-cluster-1 --zone "asia-northeast1-a" Dockerイメージの削除$ gcloud container images list --repository asia.gcr.io/${prjid}Dockerイメージの削除$ gcloud container images delete asia.gcr.io/${prjid}/<myapp>
GKEのクラスターでConnect＞クレデンシャルcmdが分かるgcloud contaier clusters get-credentials <clustername> --zone asia-northeast1-b --project unco そのコマンドを承認済みNWの環境で実行するkubectl get pods -n <namespace> | grep xxx Podを特定したい、オプションnでネームスペース、-n無しだと現行のNS、--all-namespacesで全NSkubectl exec -it <podname> -n <namespace> -- /bin/bash これでPodに入れるので python xxx.py とかコマンド可能
さらにアクセスが必要ならkubectl config get-contexts コンテキスト一覧（クラスタ、ユーザ、ネームスペースを組み合わせたもの）を表示kubectl config use-context <コンテキスト名> コンテキスト切り替えkubectl port-forward service/<srv> 8080:80
ポートフォワード先を設定別ターミナルを立ち上げcurl "http://localhost:8080/api/v1/namespaces/<namespace>/pods/<pod>"
curl --silent 127.0.0.1:8080 | head -n 10
Kubernetes API RESTのサブリソースサブリソースとは通常のリソースの HTTP パスに追加でサフィックスを付与した特別な HTTP パスService proxy: /api/v1/namespaces/<namespace>/services/<scheme>:<service>:<port>/proxy/Pod のログを取得する: /api/v1/namespaces/<namespace>/pods/<pod>/logsPod のポートを転送する: /api/v1/namespaces/<namespace>/pods/<pod>/portforwardPod で任意のコマンドを実行する: /api/v1/namespaces/<namespace>/pods/<pod>/exe
コンテナ起動時• ステートレスな状態を維持する• スケールアウト可能なアーキテクチャにする• 設定は外部から注入できるようにする• ログは標準出力に構造化ログで出力する• いつでも容易に停止できるようにする• SIGTERM シグナルをハンドリングする• コンテナ上には単一プロセスのみ起動する• ヘルスチェック用のエンドポイントを用意する• アプリケーションの状態を可観測にする• 起動時にアプリをダウンロードしない
=========================
ASM（anhtos service mesh) サービスメッシュでマイクロサービス間で適切な通信する マネージドな管理？監視/デプロイ/イングレスセキュリティ？コントロールプレーン？
DBやミドルウェアは外して別途管理が良いらしいAnthos Service Mesh を導入、移行、そして使いこなしてみよう全体の雰囲気GKEクラスタへのAnthos Service Meshの導入 (zenn.dev)サイドカープロキシ ASMがGKE本体に蜜結合することなくプロキシとして全てのトラフィックを傍受できる 周辺的なタスクをこなすという意味合いかAnthos Service Mesh を使用してサイドカー プロキシを挿入する | Google Cloud
=========================
●DAGを使う
Kubernetes ネイティブなワークフローエンジン Argo Workflows | 豆蔵デベロッパーサイト (mamezou-tech.com)
Argo公式マニフェストが長すぎる？argo-helmでやるか
argo-helm/charts/argo-workflows at main · argoproj/argo-helm · GitHub
Quick Start - Argo Workflows - The workflow engine for Kubernetes (argoproj.github.io)
gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい
Comment (0)
■21/5/22 12:00AM
GCP Hands Off
データの種類でアーキテクチャを決める？ コンテナはオーバヘッドが少なくVM/GCEに比べ軽量高速、スケールアップ/ダウンに優れているGCS
IAPを使うと画像アクセスにも認証が使えそう＞LBのバックエンドではIAPが使えない
GCEにGCSマウントするとGCEのIAPとしてイケる、gcsfuseのOSSでLinux上のドライブになる
CensOS6.8にgcsfuseをインストールしてGCSをマウント - Qiita
GCS Fuseを使ってみる - Qiita
リテンションで保護期間を設定したり、ライフサイクルで削除時期を設定したり
世代管理ができたり
■制約が重要そうでまとめて記載したい IAPとCDNの両立はできない
LBのbackendにgcsを設定したときはIAPが使えない
GKEのingressのLBに他のアプリのバックエンドを同居できない（GKEが上書き自動更新するから、ドメイン別になる）
IAPでGCEにOSログインする場合はAPI有効やIAPの設定、OSlogin系の権限が必要（Owner付与が楽）
ネットにでるのがapt updateのみでもNAT/Routerが要る
■VPCネットワーク
default VPCネットワークを削除（セキュリティが緩いため）vpcネットワーク作成 サブネットIPレンジ 10.27.0.0/16-192.168.27.0/24 等で private google accessはオンでいいのか?on FWはひとまずなしで、だが大体ポートは22,80,443,8080?別途firewallで下記を設定（ちなみにリクエスト側を許可すればよく、レスポンス側は自動）bangboo-fw-allow-iap-ssh IAPからのSSHを許可 35.235.240.0/20 tcp:22 レンジはマニュアル https://cloud.google.com/iap/docs/using-tcp-forwarding#create-firewall-rulebangboo-fw-allow-lb GFE(Google Front End)からのHTTPを許可 35.191.0.0/16,130.211.0.0/22 tcp:qll レンジはマニュアル https://cloud.google.com/load-balancing/docs/health-checks#fw-ruleCloud NAT(Router)を設定https://cloud-ace.jp/column/detail260/https://www.topgate.co.jp/google-cloud-network-security
■ハンズオン(GAE:php+FW+IAP)→GAEよりCloud runが良いIAPはGAEが簡単そう（アクセスするのにGoogleの認証プロンプトを出す）
自前DNSにTXTレコードを設定>確認>IPが表示されAレコードやCnameも登録でき、SSL証明書も使えるようだ
しかし無くてもgoogle提供のドメインが使え不要 DNS(TXTレコード)による所有権の確認 - Google Search Consoleの使い方 (howtonote.jp)
WinローカルにGCP SDKインスコし下記にapp.yamlとindex.phpを置いてcmd→ gcloud app deploy
C:\Users\おまはんのユッザー名\AppData\Local\Google\Cloud SDK\php
IAPを有効にしIAM secured userの権限とIAMでGAE viewer権限付与で@gmail.comユーザ等は見れる
外部ドメインを使うときはIdentityPlatform設定が必要そう
止めるにはinstanceを削除する(再度アクセスでinstanceが自動作成される)、IngressをInternal onlyにすると一応止まるか、楽だ
■ハンズオン(Marketplace: GCE+FW->Wordpress)
デフォルト：エフェメラル＋インターネット公開なし(LB/IAP/NAT/Armor付けてから公開しようかと)
VMインスタンス ネットワークタグwordpress-1-deployment
FW：wordpress-allow-external ターゲットタグwordpress-1-deployment、ソース0.0.0.0/0 tcp0-65535スナップショットのラベルはKVSで app : wordpress とか env : testとか
DBはステートフルMIG-永続ボリュームにできる？
■ハンズオン(GCE+nginx+FW+LB+IAP+Cloud NAT+Cloud armor)
●cloud shell terminalgcloud compute instances list インスタンス一覧●コンソールデフォルトVPC NWを削除 > VPC NW作成 > サブネットIPレンジ 10.27.0.0/16-192.168.27.0/24等でGCE VMを作成(Instance scheduleで起動-停止時間が入れられる、テンプレやグループに使えない？)
インスタンスを作って設定しスナップショットからOSイメージを作り量産すればいいが
instance template作成してinstance group作成してもいい。IGが中々できないならIGを開きエラーメッセージを見ること
OSはubuntu、API access scopeには"Allow full access to all Cloud APis"で 外部からアクセスさせずLB経由だけにしたい→外部IPがephemeralで止められない→作成時にnetwork>external ipをnoneで作成すること→
外へでれなくなるのでgcloudコマンドが通らない→CloudNAT(Router)も設定
インスタンステンプレートのメタデータ 起動スクリプトをファイル化できる キーstartup-script or shutdown-script、値にパス キーstartup-script-url or shutdown-script-url、値にGCSのURL
OSLoginをIAPにしてVM上の独自ID管理PW管理不要に
便利機能「OS Login」を使ってIAMでインスタンスへのSSH接続制限をする | apps-gcp.com
キーenable-oslogin、値にTRUE、IAMで権限（compute OSLogin/IAP tunnel/gce系）、IAP API有効
権限もIAMで管理されるのでLINUX上の755等も不要なようだ（computeinstanceAdmin.v1を付けとく） MIGとLBと同じヘルスチェックを使うことは非推奨 LBはより短い低い閾値にせよSSHの項目からview gcloud commandで好きなSSHターミナルからアクセスできるcmd出る gcloud beta compute ssh --zone "asia-northeaset1-b" "instance-3" --tunnel -through-iap --project "bangboo-sandbox"●SSHターミナルgcloud init インスコsudo apt-get install nginx Webサーバインスコ、ブラウザで内部IPでアクセスしたかったが不可だったsudo service nginx stop 止める、動かすのは sudo service nginx startps プロセス見るcurl http://10.117.0.19 nginxが動いているか確認cat /var/log/nginx/access.log ログ確認
●nginx
/etc/nginxにあるconf系が設定ファイル
sites-enabled/default だけがあり cat default しdocument rootは/var/www/htmlと判明
ここへ移動 cd /var/www/html
sudo cp index.nginx-debian.html index.html コピー
sudo nano index.html で編集
設定変更後は sudo service nginx restart●コンソール
GCEスナップショット作成→OSイメージ作成→テンプレ作成→Healthcheck作成→MIG設定
OSイメージはオンプレから作ったものとかHashi corpのPackerで作るとかも
FW作成
gceに外部IPがあればアクセス試す
fw-bangboo-http-ingress-allow ingress - "all instances" - 0.0.0.0/0 デフォルトで許可＋ingressが必要
httpsはIPではダメ、ドメイン/証明書が要るか知らんがhttpでは外部IPあればアクセスできる
GCPのIPを自前のDNSのAレコードに設定しとけば、、
ウェブとメールを別々のサーバで運営したい？・・・それ、ゾーン設定で出来ます！ | さくらのナレッジ (sakura.ad.jp)
ドメイン所有はDNSにTXTレコード設定ができるようだが、、、
ウェブマスター セントラル (google.com)
使うときfw-bangboo-all-ingress-allow ingress - "all instances" - 192.168.1.255/32 に設定？
外部IP(普通LBとなるか）への制御はCloud armorのでdeny allowしてFWではあんまり考慮しない
armor-bangboo-all-ingress-deny ingress - "all instances" - 0.0.0.0/0 で設定完了まで止めとくLB作成 VMインスタンスグループ（子インスタンス）作成（上で作ってなければ） インスタンステンプレート作成 LBヘルスチェック(閾値)が要る httpLBだと内部か外部か選択できる
httpLBならIPレンジが要る＞VPC networkで同resionで使われていないものを設定 例10.55.20.0/22なら10.55.23.255まで使われているので10.55.25から使うとか NW計算 ネットワーク計算ツール・CIDR計算ツール | Softel labs
VPCのサブネット設定は拡大できるが縮小ができない→小さめにしておきたいが、k8sはIP沢山使うので大きめ
プライベートサービスコネクト(VPC間を繋ぐ)を使うと疎結合でつなげられるが
backendはhttpで、healthcheckはtcp80とproxy無し
IAP作成
外部 HTTPS ロードバランサの設定 | Identity-Aware Proxy | Google Cloud IAP(https)を見るとFWで開けてくれの指定がある
fw-bangboo-lb-gce-allow Source IP range:072.72.1.19/22, 69.11.8.0/16 tcp:80
IAPを見るとLBを設定するとFWはLBに対するものだけになるので不要との指示がある fw-bangboo-http-ingress-allow 0.0.0.0/0（削除） 下記はインスタンス作成時の許可設定分で不要 default-allow-internal 69.11.0.0/9（削除） default-allow-http 0.0.0.0/0（削除）
これも不要？default-allow-http 0.0.0.0/0 tcp:443（削除）default-allow-icmp 0.0.0.0/0（削除）
default-allow-rdp 0.0.0.0/0 tcp:3389（削除）default-allow-ssh 0.0.0.0/0 tcp:22（削除）
IAP(ssh/tcp)を見るとFWで開けてくれの指定があるが開けるとhttpsに穴ができると出るし止め
fw-bangboo-lb-iap-tcp-allow Source IP range:072.72.2.0/20 tcp:all（sshターミナルを使う時だけFW開ける、通常priority9000）
IAPをONだけでは駄目で、FWで調整してGCEに直接アクセスじゃなくLBでやっとIAPが動くみたい IAPの設定でhttp://IPでアクセスするとhttps://に転送されたのだが(IAPがない場合は下記設定をするようだ)
HTTP(S) 負荷分散用の HTTP から HTTPS へのリダイレクトの設定 | Google Cloud事前にgce.bangoo.com -> 117.072.19.255 (LBのIPはephemeralをstaticに変更)を自前のDNSに設定
（DNSのTTLを前日に3600から300に変更しておいたり、DNS反映期間があったり） LBのフロントエンドでマネージド証明書を設定（ssl-policyを緩めで設定したが必要？） オレオレ証明書は？ LBフロントエンドはhttpsでもバックエンドはhttpで
IAP-secured web app userロールを@gmail.comユーザに付与
IAPとCDNの両立はできない
LBのbackendにgcsを設定したときはIAPが使えない→ネット公開にしてVPN SCで制御？(元々ネットに面しているが権限がないだけ)、GCEにGCSをマウント？
FW調整
0.0.0.0/0 all deny priority2000>LB関連 tcp80 allow 1000/IAP関連 tcp allow 1000>（使用拠点のソースIP allow 500)
使用拠点のIPはLBを使うならArmorで設定すればFWへの設定不要
GCEの外部IPを止める：インスタンステンプレート作成時に外部IPnoneで設定(StaticIPを買って削除でもnoneにできなさそう)
必要なもの以外を止める：0-442, 444-65535で443のみ許可は駄目か？
Connectivity testでテストがIPアドレス等でできる（設定変更から実際の反映に時間が掛かるものがあるような気が）
apache benchでスケールするかテスト Apache Bench を使って初めてのベンチマークテスト - Qiita
sudo apt install apache2 abはapachに含まれるのでどれかのVMにインスコ
ab -n 1000 -c 100 https://gcp.bangboo.com/ でインスタンスが増えることが確認できる
Cloud armor設定
DDoS等を防ぐのでOnでいいのでは、adaptive protectionで優先度低いdeny設定
外部IPのdeny allowはこれでやる(web app firewallなのでな)、log4J対策等もここで弾く
一時止めるときは0.0.0.0/0 bad gateway等分かり易いエラーで止めるのが良いかも
IAPが前、Cloud armorが後ろ、そしてLBとか
Access context manager設定（+VPC service control）
Organizationの設定が必要(≒Cloud identityでドメイン必要？)IPアドレスやOS等でアクセスを制限できるCloudSQL APIライブラリからCloud SQL API、Cloud SQL Admin APIを有効に 平文通信→暗号化CloudSQL proxyバイナリをVMインスコ、ディレクトリ切る proxyとアプリ設定を合わせる、proxyサービス起動
SQL用にsvac作成 lemp-gce-sql-01@ ログインユーザをこのsvacにowner設定 ロール付与 Cloud SQL Client、Compute Engine Service Agent、Compute Instance Admin (v1)、Compute Viewer このsvacをGCEインスタンスのデフォルトsvacに設定 ユーザやdatabeseを作成、charaset: uft8mb4, collation: utf8mb4_bin
GCEでSQL proxyの設定（SSH開く）
gcloud auth list ログインユーザがsvacか確認 mkdir $HOME/download cd $HOME/download wget https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 sudo mv cloud_sql_proxy.linux.amd64 /usr/local/bin/cloud_sql_proxy 変名 sudo chmod +x cloud_sql_proxy 実行権限設定 sudo mkdir /cloudsqlproxy ソケットになるディレクトリ作成 sudo chmod 777 /cloudsqlproxy パーミッション設定
sudo /usr/local/bin/cloud_sql_proxy -dir=/cloudsqlproxy -instances=bangboo-sql:asia-northeast1:mysql-01 ↑Readyになってからコマンドが返るのに何分か掛かる
もう一つSSHを開くと下記コマンドが通る
mysql -u root -p -S /cloudsqlproxy/bangboo-sql:asia-northeast1:mysql-01
mysql> connect test; mysql> show tables; mysql> create table test.test (id int, name varchar(10));
mysql> insert into test (id, name) values (1, 'baka'); mysql> select * from test; SQL proxyサービス化 Cloud SQL Proxy (TCP Socket)を systemd で起動させる - Qiita
sudo vi /etc/systemd/system/cloud_sql_proxy.service
===== [Unit]Description = Cloud SQL Proxy DaemonAfter = network.target [Service]ExecStart = /usr/local/bin/cloud_sql_proxy -dir=/cloudsqlproxy -instances=bangboo-sql:asia-northeast1:mysql-01ExecStop = /bin/kill ${MAINPID}ExecReload = /bin/kill -HUP ${MAINPID}Restart = alwaysType = simpleLimitNOFILE=65536 [Install]WantedBy = multi-user.target=====
sudo systemctl start cloud_sql_proxy 起動だが自動設定してリブートだけでいい sudo systemctl enable cloud_sql_proxy サービス自動起動 sudo reboot now Authenticating as: Ubuntu (ubuntu)でPWを求められる場合 sudo su - でrootに切り替えてからcmd sudo su とかしてる人はだいたいおっさん (zenn.dev) systemctl list-units --type=service サービスの一覧確認 systemctl list-units --all --type=service 全サービスの一覧確認 service サービス名 status service サービス名 start service サービス名 stop
IAMでDB認証するにはフラグ cloudsqql_iam_authentication 面倒なだけか？
Cloud SQL IAM データベース認証 | Cloud SQL for PostgreSQL | Google Cloud
IAM データベース認証用に新規または既存のインスタンスを構成する | Cloud SQL for MySQL | Google Cloud
IAM データベース認証を使用してログインする | Cloud SQL for MySQL | Google CloudFW/ArmorでIngress全止め or VMインスタンス停止、LB停止
■GCE MIGローリング更新GCP のローリング更新が恐ろしく便利で簡単でおしっこ漏らしそう - 強まっていこう (hateblo.jp)
MIG 内の VM に新しい構成を適用する | Compute Engine ドキュメント | Google CloudMIG で VM 構成の更新を自動的に適用する | Compute Engine ドキュメント | Google Clouddev-stg環境でinstance templateを作ってprodでテンプレ置き置き換える感じ？
シングルVMでstg > OSイメージ > テンプレ化 > prod用MIGローリングアップデート設定 MIGは徐々に更新をいい塩梅で行う必要があるためローリング更新する ロールバックはテンプレートを元に戻す設定をする、コミットは新しいテンプレートを設定するだけ カナリアは2nd テンプレート追加項目でターゲットサイズで3台とか10%とか設定するだけ
ローリング更新（Update VMS）
インスタンスグループを開いてUpdate VMSに進む a)Proactiveは最大サージ(一時追加のインスタンス数)、とオフライン上限を指定 b)日和見Opportunisticはオートスケールの増減時に新インスタンステンプレートに切替る（どうでもいいパッチ等） サージ：追加台数、オフライン：停止台数、 オフライン台数を大きくすると一気に反映できる それに合わせて見積もりサージを大きくする（料金は掛かる）
最大サージを 1、オフライン上限を 1 とすると、新しい VM が 1 ずつ発起動して、古い VM が 1 台ずつ落とされて行きます。 最大サージを 3、オフライン上限を 2とすると、新しい VM が 3 発起動して、古い VM が 2 台落とされ、1台落とされる。
インスタンスの再起動/置換（Restart/Replace VMS） インスタンスグループを開いてRestart/Replace VMSに進むとローリングでインスタンスの再起動と置換ができる
a)再起動：オフライン上限のみを指定して VM のテンプレートを切り替え b)置換：最大サージを指定することができるようになるだけ
■インスタンススケジュール元来のサービスアカウントにcompute.instanceAdmin.v1が必要（コンソールでの設定時にエラーが出るので参考にして権限付与）VMは一つのインスタンススケジュールにしか所属できないため、テスト後に本番スケジュールに入れなおす等の考慮が必要インスタンススケジュールを削除するには、所属のVMを外す必要がある最大15分遅れる場合がある。起動時間もその上加算する必要があるかも
■MonitoringVMにOpsエージェント入れるOps エージェントの概要 | Cloud Logging | Google Cloudエージェント ポリシーの管理 | オペレーション スイート | Google CloudOps エージェントの構成 | Cloud Logging | Google CloudGCPのVMインスタンスにOps Agent入れてログモニタリング - Qiita
個々の VM に Ops エージェントをインストールする | オペレーション スイート | Google Cloud
→VMを起動していたらコンソールで実施可能（CloudShellに誘導される）なのでコレでいい
Loggingエージェントを捨ててOpsエージェントに乗り換える
他の方法の例：
@terminalでgcloud components update これ時間掛かるし不要ではhttps://cloud.google.com/stackdriver/docs/set-permissions.sh?hl=ja をダウンロードterminalにアップロードし実行 bash set-permissions.sh --project=bangboo-omeインスタンス ラベルで設定する GCEにラベルenv=test,app=omeを設定gcloud beta compute instances \ ops-agents policies create ops-agents-policy-safe-rollout \ --agent-rules="type=logging,version=current-major,package-state=installed,enable-autoupgrade=true;type=metrics,version=current-major,package-state=installed,enable-autoupgrade=true" \ --os-types=short-name=centos,version=7 \ --group-labels=env=test,app=ome \ --project=bangboo-ome起動しているVMにOS Config エージェントがインストールされているかを確認gcloud compute ssh instance-1 \ --project bangboo-ome \ -- sudo systemctl status google-osconfig-agent下記が返るEnter passphrase for key '/home/sute3/.ssh/google_compute_engine': google-osconfig-agent.service - Google OSConfig Agent Loaded: loaded (/lib/systemd/system/google-osconfig-agent.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2022-04-11 18:34:26 UTC; 8min ago Main PID: 1279 (google_osconfig) Tasks: 11 (limit: 1116) CGroup: /system.slice/google-osconfig-agent.service └─1279 /usr/bin/google_osconfig_agentNumpyが要る場合は下記でインスコsudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-noseダッシュボード作成アラート作成
複数の Cloud プロジェクトの指標を表示する | Cloud Monitoring | Google Cloud
エージェントのログのモニタリングはNW構成に関わらず集約できる（GCP環境に置かれておりGCP設定のみでOKだから）Yaml設定を新規で作ればオーバーライドされるOps エージェントの構成 | Cloud Logging | Google Cloudsudo vim /etc/google-cloud-ops-agent/config.yaml------------------logging: receivers: laravel_log: type: files include_paths: - /var/www/html/laravel/storage/logs/*.log
service: pipelines: custom_pipeline: receivers: [laravel_log]-----------------# 反映sudo service google-cloud-ops-agent restart
↑
sute16 asia-northeast1-b 2021/7/24(91日で33000yen-10/20位まで)
sute3 asia-northeast1-b 2022/2/20(91日で34500yen-5/20位まで)Instance groupはどう止める？＞LB削除＞LBのバックエンド削除＞Instance group削除
LBはinstance groupがいる、IAPはGCEの場合はLBにSSL証明書要る（ドメインもGlobalIPも要る）
DNSのAレコードを登録しLB設定すれば証明書入る
毎回検証終了時につぶして、立てるのが面倒そうだな→FWでdeny allしとく
【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita
Oauth同意画面のサポートメールはログインしているユーザのものか、そいつがオーナになっているGoogle workspaceのメールグループを設定することができる（gcpのロールとしてwnerかoauthconfig.editorも要る）
nginx+PHP appサーバ＋BigQuery+BigTable＋CloudSQL(MySQL)+GCS+α？ [PHP]BigQueryのデータを取得する | yyuuiikk blog
$ composer require google/cloud でインスコ<?phprequire 'vendor/autoload.php';use Google\Cloud\BigQuery\BigQueryClient;$keyfile = './credential.json'; //svacのkey$bigquery = new BigQueryClient([ 'keyFile' => json_decode(file_get_contents($keyfile), true),]);$dataset = $bigquery->dataset('dataset-name');$table = $dataset->table('table-name');$queryJobConfig = $bigquery->query( "SELECT * FROM `project-id.data-set-name.table-name` LIMIT 100");$queryResults = $bigquery->runQuery($queryJobConfig);foreach ($queryResults as $row) { print_r($row);}
Google Cloud Storage にPHPを使ってファイルをアップロードする | カバの樹 (kabanoki.net)
$composer require google/cloud-storage でインスコ<?phprequire __DIR__ . '/vendor/autoload.php';use Google\Cloud\Storage\StorageClient;$projectId = 'bangboo-prj';$auth_key = './iam/credential.json';$bucket_name = 'gcs-bangboo';$path = 'img.png';$storage = new StorageClient([ 'projectId' => $projectId, 'keyFile' => json_decode(file_get_contents($auth_key, TRUE), true)]);$bucket = $storage->bucket($bucket_name);$options = [ 'name' => $path];$object = $bucket->upload( fopen("{$path}", 'r'), $options);
<img src="https://storage.googleapis.com/gcs-bangboo/img.png">SSLに対応したNGINXリバースプロキシを構築する手順 - Qiita
nginxは静的コンテンツを高速に配信するように設計されている。 また、 リバースプロキシ の機能を持つため、背後にWebアプリケーションサーバを配置して動的なコンテンツを配信したり、ソフトウェア ロードバランサやHTTPキャッシュとしても使うこともできる。GCPにセキュアな踏み台サーバーを作成する. GCPのIdentity-Aware… | by Taiga Murakami | google-cloud-jp | Medium
Googleにバックドアを開けてしまっては危険、、、ということはない
End
Comment (0)
Navi: < 9 | 10 | 11 | 12 >
-Home
-Column [128]
-Europe [9]
-Gadget [77]
-Web [133]
-Bike [4]
@/// BANGBOO BLOG ///
