フォッグの消費者行動モデル B=MAT
行動Behavior = 動機Motivation（やりたい:利） × 実行能力Ability（簡単そう） × きっかけTrigger（背中押し）
https://note.com/akira_miyazaki/n/nb32211b94102お気にのAIDMA
他にも亜種が
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) 全体に適用する
全て想像ですが
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース
ケツが扱う最小単位がPodで1つの機能を持つ（Podは1つ以上のコンテナを含む）
ReplicaSetは複数のPodを組み合わせてアプリを実現する（Podの数の管理機能）
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う（Podのデプロイ管理機能）
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する（Podへのアクセス管理機能）
クラスターはServiceが複数動く環境、1つのMasterと複数のNodeから構成され
Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う
流れ
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、サービスコントロール、サービス管理
■流れ
GKEでクラスタを作成
Kubectrlをインスコ
KubectlでPodを立ち上げ＞Deploymentができる、複数Podの起動も
Kubectlでサービス公開設定
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp) サービスアカウント作成
ネームスペース、kubeサービスアカウント作成
サービスアカウントとKubeサービスアカウント紐づけ(gcloudとbubectlの両方)
Yamlで機能を宣言しKubectlでデプロイ
Pod(論理ホスト/インスタンスみたいな)
一意のIPが自動的に割り当てられる
Pod内のコンテナはlocalhostで互いに通信、コンテナ間で共有するストレージ
Podを直接作成は非推奨
CPU/メモリの最小と最大を設定
Workload identityでServiceAccountとケツのサービスアカウントを紐づけ認証
k8sのsecretはPw/Oauthトークン/SSH key等を含むオブジェクト(base64エンコード生)
使う方法3種類：コンテナにマウント、コンテナの環境変数、Pod生成時にケツがpull
どこに置くか、どう暗号化するか、gitに置かない等の考慮が必要
＝＝＝＝＝＝＝＝＝
時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えば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 CloudCloud buildを使用してアプリをコンテナイメージにパッケージ化
GKEでクラスタを作成、コンテナイメージをクラスタにデプロイ
↓手始め？
GKEでnginxを外部アクセス可能にするまで - QiitaKubernetesでのコンポーネント間の通信をまとめる - QiitaGCP におけるコンテナ入門 ~Kubernetes の何がすごい！？ | クラウドエース株式会社 (cloud-ace.jp)GKE
これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)k8s用の認証情報を取得
$ gcloud container clusters get-credentials <standard-cluster-1> --zone asia-northeast1-a
k8sオブジェクトを表示
$ kubectl get all
nginx dockerイメージを起動
$ kubectl run <handson> --image=nginx --port 80
LBを作成しトラフィックを流す設定
$ 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 deployment
dockerイメージのバージョン変更
$ 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.py
Dockerビルド
$ docker build -t myapp .
ビルドしたコンテナを起動
$ docker run -p 3000:3000 myapp
http://localhost:3000 へアクセスして確認
コンテナにタグ付け
$ docker tag myapp asia.gcr.io/${prjid}/myapp
GCRの認証
$ 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>
■Cloud Loggingで調べる
ログ エクスプローラを使用したサンプルクエリ | Cloud Logging | Google CloudLogging のクエリ言語 | Google Cloudとりあえず何かを出して、クリックして不要な要素をHideしていくといい
/// 誰が権限を変更したか
protoPayload.request.policy.bindings.role="organizations/123456/roles/unco"
protoPayload.methodName="SetlamPolicy"
--操作者
--protoPayload.authenticationInfo.principalEmail="kuso@dayo.com"
/// GCEのPyhon等のロギングを見る
resource.labels.instance_id="12234567898"
severity=WARNING
/// IAPのアクセスログ
監査ログからidentity-で探しログを有効化する（似たような名前があるので注意）
下記でLog exploreで検索するが、大体のアクセス時刻からリソースを類推して右クリックで絞る
logName="project/prjxxxxxx/logs/cloudaudit.googleapis.com%2Fdata_access"
resource.type="gce_backend_service"
/// BQの利用先
protoPayload.resourceName="projects/prjxxxxxxxx/datasets/dsxxxxxxxxx/tables/tblxxxxx
/// Scheduled queryの利用状況
resource.type="bigquery_dts_config"
/// コネクティッドシートでBQアクセスするスプシを調べるLoggingのクエリ
connected_sheets
bigquery.Jobs.create
bigquery.googleapis.com
docId
--データセット名
dataset ni_access_sarerudayo
--除外するにはマイナスを頭に付ける
-protoPayload.authenticationInfo.principal Email="washi@jyaroga.com"
■組織のログを一つのプロジェクトにまとめておく
組織のLog routerで全Syncを設定しておく
■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'
データの種類でアーキテクチャを決める？
コンテナはオーバヘッドが少なくVM/GCEに比べ軽量高速、スケールアップ/ダウンに優れている
■制約が重要そうでまとめて記載したい
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-rule
bangboo-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-rule
Cloud 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 terminal
gcloud 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、値にパス
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 start
ps プロセス見る
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
使うとき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から使うとか
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が動くみたい
事前に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 Daemon
After = network.target
[Service]
ExecStart = /usr/local/bin/cloud_sql_proxy -dir=/cloudsqlproxy -instances=bangboo-sql:asia-northeast1:mysql-01
ExecStop = /bin/kill ${MAINPID}
ExecReload = /bin/kill -HUP ${MAINPID}
Restart = always
Type = simple
LimitNOFILE=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を求められる場合
systemctl list-units --type=service サービスの一覧確認
systemctl list-units --all --type=service 全サービスの一覧確認
service サービス名 status
service サービス名 start
FW/ArmorでIngress全止め or VMインスタンス停止、LB停止
■GCE MIGローリング更新
dev-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分遅れる場合がある。起動時間もその上加算する必要があるかも
■Monitoring
VMにOpsエージェント入れる
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_agent
Numpyが要る場合は下記でインスコ
sudo apt-get install python-numpy python-scipy python-matplotlib ipython ipython-notebook python-pandas python-sympy python-nose
ダッシュボード作成
Yaml設定を新規で作ればオーバーライドされる
sudo 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位まで)
nginx+PHP appサーバ＋BigQuery+BigTable＋CloudSQL(MySQL)+GCS+α？
[PHP]BigQueryのデータを取得する | yyuuiikk blog$ composer require google/cloud でインスコ
<?php
require '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 でインスコ
<?php
require __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">
nginxは静的コンテンツを高速に配信するように設計されている。 また、 リバースプロキシ の機能を持つため、背後にWebアプリケーションサーバを配置して動的なコンテンツを配信したり、ソフトウェア ロードバランサやHTTPキャッシュとしても使うこともできる。
■GCP(Google Cloud Platform)
https://console.developers.google.com/
GCPを活用するスキルを問われる「Associate Cloud Engineer」
インフラストラクチャの知識を問われる「Professional Cloud Architect」
データと機械学習の知識を問われる「Professional Data Engineer」
マシーンラーニング：教師ありをベースにパターンを線形として認識し相似のパターンを見つける
ディープラーニング：人間が把握できる次元のデータ構造ではない多次元でパターンを見つける
線形検索みたいなもんか
■GCP
https://techblog.gmo-ap.jp/category/gcp/https://tech.zeals.co.jp/entry/2019/01/08/094054https://techblog.gmo-ap.jp/category/tensorflow/情報源
Solution Design Pattern (gc-solution-design-pattern.jp)google-cloud-jp – Mediumサポートを付けるとGoogleに聞き放題になったりする
サポートのケースは組織レベルでみると全プロジェクトのケースが見れる
3か月間300 ドル分だけ無料
https://console.cloud.google.com無料枠
GCE:プリエンプティブル以外の1つの以下のe2-micro VMインスタンスと30GB/月の標準永続ディスク
オレゴン: us-west1
アイオワ: us-central1
サウスカロライナ: us-east1
GCS: 5GB/月のRegional Storage（米国リージョンのみ）
無料だとBigQueryのDML(insert)ができないらしい
予算とアラートを1円で設定（通知チャネルにSMSとメール設定）
月額のプロダクトを日割レポートで見ると2月の日割りは高く見え、3月は安く見える
為替の影響は月初から適応されるので円安だと高いよ
辞めるときはプロジェクトをシャットダウン＆請求先アカウントの閉鎖
１）プロジェクトの閉鎖
Google Cloud Console ＞ IAMと管理 ＞ 設定 ＞ シャットダウン
２）請求先アカウントの閉鎖（原因不明だが下記画面が出るときと出ないときがった）
Google Cloud Console ＞ お支払い ＞ (左ナビ)アカウント管理 ＞ 請求先アカウントの閉鎖
※お支払い＞マイプロジェクト＞アクション＞無効や請求先変更ができる
セキュリティは使用GoogleアカウントのSMSによる２段階認証、信用するデバイスの設定があるようだ
GKE, Cloud SQL, Dataflow等
【GCP入門編・第3回】難しくない！ Google Compute Engine (GCE) でのインスタンス起動方法！ | 株式会社トップゲート (topgate.co.jp)【GCP入門編・第12回】 BigQuery を使って気軽にビッグデータの解析を行ってみよう！ | 株式会社トップゲート (topgate.co.jp)【GCP入門編・第25回】 Cloud SQL for MySQL で Master-Slave 構成を組もう！ | 株式会社トップゲート (topgate.co.jp)【GCP入門編・第29回】Cloud Load Balancing で Web アプリケーションにロードバランサーを設定する | 株式会社トップゲート (topgate.co.jp)【初心者】GCP Identity-Aware Proxy (IAP), Access Context Managerを使ってみる (WEBサーバへのアクセス制限) - Qiita■IAM(Identity and Access Management)
https://cloud.google.com/iam/docs/overview?hl=ja
https://cloud.google.com/iam?hl=ja
IAMベストプラクティス https://cloud.google.com/iam/docs/using-iam-securely
操作方法 https://cloud.google.com/iam/docs/how-to?hl=ja
ロール https://cloud.google.com/iam/docs/understanding-roles?hl=ja
https://www.isoroot.jp/blog/1244/
https://medium.com/google-cloud-jp/gcp-iam-beginner-b2e1ef7ad9c2
//IAMの機能（RBAC認可：role based access control）
機械学習を使ったスマート アクセス制御の最適化
デバイスのセキュリティ、IP アドレス、リソースタイプ、日時などの属性に基づいて、リソースに対するきめ細かいアクセス制御ポリシー
権限の認可、解除、委任に関するすべての監査証跡の履歴
ユーザーとグループのプロビジョニングや管理、シングル サインオンの設定、2 要素認証プロセス（2FA）
//IAMポリシー
IDをGroup（●●部）にアサイン
Members(Group等)にRoles（●●役）をアサイン
MembersとはグループやドメインやID(Googleユーザアカウント、サービスアカウント)
Roles（●●役）にPermissions（権限）を付与
ロールは作成ができ●●世話役みたいな感じか
permissionsは権限で「resourcemanager.projects.get」等でロールに紐づける
個人や無料アカだと組織がない？→フォルダが作成できない？
組織がないとグループが作成できない→グループがないとIDにRoleを付与するしか
フォルダは組織ツリー状でリソース管理、組織改編が多いならプロジェクトフォルダでも
各フォルダに対してそれぞれメールグループを定型(folder-admin/dev/lead/member/parttime/etc)で持たせ
メールグループへのユーザ出し入れで権限の管理をするのが良さそう
IAMやServceAccountの一覧には出てこないが存在するIDがある、実際に権限を付与できるかで存在確認する(TFで作成の場合？)
ポリシーはMSのGPOみたいものも組み込みで存在する
サービスアカウントはAPI用、人が使うことは基本想定されていない(impersonate等できるが
ユーザが削除になっても権限やリソースは残る？30日位はdeleted:になって消えるのでは
プリンシパルには@gmail.comのGoogleアカウントやWorkspace契約のある組織ドメインのGWSアカウント等があり、独自ドメインでもGWS契約がない場合は@gmailのように登録しGoogleアカウントにして使用する
外部ドメインのユーザの場合はメールグループ単位でのロール付与が効かず個別アカウントで付与する必要がある？あるいは組織ポリシーを開けっ放し？
APIを有効化せんと何もできないが、するロール roles/serviceusage.serviceUsageAdmin
メールグループの権限関係の確認方法
仕組み：祖->親->子、上の権限は下も持つ
権限から確認する、所属から確認するの両面で確認
１）権限を持っている全ての子をリストアップ
２）所属しているメールグループの全ての親をリストアップ
//画面上部のプルダウンからプロジェクトを選択できない場合
（BQのデータセットにのみ権限がある等）
１）BQの左ペーンでデータセット名を検索し（すべてのプロジェクトを検索するため2回必要）スターを付けて代替とする
２）データセットレベル権限でもURLパラメータ付きだと選択ができる
http://console.cloud.googl.com/bigquery?project=bangboo-kuso-project
３）IAMの画面で何かしらresourcemanager.projects.listを含むロール、つまりBQ data viewerでOKだがプロジェクトレベルの権限を付与しておく（権限付与後にログインしなおしが必要）
※jobuserがないとBQコンソールでプルダウンできない訳ではない（jobuserなしでOK）
※グループメールの深い階層で付与されていても影響はしない
//リソース
階層：Organization > Folders > Project > Resource(Google Cloud services)
割り当て：日や分に対してのデータ量の上限等を設定
必要以上に権限を付与しない
組み込みロールが多い、改変してロールを作るか
権限はサービス名.リソース.動詞という命名規則
プロジェクト名はGCPグローバルで名前空間を共有しており、企業名等でprefixするのがいい
プロジェクト毎にメールグループを設け、権限はメールグループの参加で管理したい
//リージョンとゾーン
リージョン：データセンターの存在場所、ゾーンをいくつか持つ
ゾーン：障害ドメイン区画（単一障害点を避ける形で環境設計したい）
Google Cloud SDKをインストールすればコマンドラインが使える
BQは同一リージョンでないとJoinができない、ゾーンはマルチで良い
APAC: asia-east(台湾、香港)、asia-northeast(日本、韓国)、asia-south(インド)、asia-southeast(シンガポール、インドネシア)、australia-shoutheast(オーストラリア)
NA: northamerica-northeast(モントリオール、トロント)、us-central(アイオワ等)、us-east(バージニア等)、us-west(ネバダ等)
リージョンとゾーン | Compute Engine ドキュメント | Google Cloud//サブネット、Shared VPC
Shared VPCホストプロジェクトに対しサービスプロジェクトを設定しプロジェクト間を共有
サブネットは通常リージョン内？レガシーだと完全に仮想で自由なサブネット？
//Cloud Shell
Google Cloud Shell の 10 の知っておくと便利な Tips | Google Cloud Blogファイルのアップロードやダウンロードが可、コードエディタもありブラウザで完結
Webアプリのプレビューも可
f1-microのGCE一時インスタンスがプロジェクトをまたいだ永続ディスク5GBで起動されている
gcludやdocker,bash,sh,vim,nano,pip,git,mysql等がプリインスコされている
5GBあるのでインスコもできる sudo apt-get install gawk
Cloud Shell VM の Zoneを知る：curl metadata/computeMetadata/v1/instance/zone
Ctrl + b キーを押してから % キーを押すとtmux により ウィンドウが左と右のペインに分割
リスト一覧を出すgcloud cmd
gcloud projects list --filter='bangboo-' --format=json | grep -oP '(?<="name": ")[^"]*'
どのgcloud cmdにも使えるワイルドフラグ
--access-token-file, --account, --billing-project, --configuration, --flags-file, --flatten, --format, --help, --impersonate-service-account(人がcmdを打つ場合でも成りすませる、その人にprjレベルの権限が必要), --log-http(cmdでエラーがでるならコレを、詳細が出る), --project, --quiet, --trace-token, --user-output-enabled, --verbosity
各言語でのSDKを使ったプログラムを実行する際の認証を得るために使います
gcloud auth application-default login
ローカルで以下のようなGCP系CLIを実行する際の認証を得るために使います
gcloud config configurations list
gcloud config configurations create unko-profile
gcloud config set account unko@dot.com
gcloud config set project onara-project
gcloud config configurations activate unko-profile
gcloud auth login
■GCE
Marketplaceを使えばアプリを数クリックでデプロイできる
永続ディスク…NWストレージ、SSD永続ディスクも選択できる
ローカルSSD…高性能、永続ではなく一時的
非マネージドインスタンスグループ インスタンスをIGに紐づけるだけ
ステートレスMIG 自動スケーリング（Webフロントエンド等）
スケジュールでもスケーリングできる(cronや予測も)
ステートフルMIG 設定を保持可（DBやデータ保持必要なstatefulなアプリ等）
インスタンス名やIPやディスクやメタを維持する、部分的に外部化ステートレスにして自動化等も
ゾーンMIG＝シングルゾーン、リージョンMIG＝マルチゾーン(最大3ゾーン)
プリエンプティブは24時間までだが20%課金だけで安い
■マネージドクラウドDB各種
ホワイトペーパーPDF■Bigquery
/// BANGBOO BLOG /// - BigQuery/// BANGBOO BLOG /// - GCP ログ調査 Logging/Bigquery information schema■GCS
http(s)で公開可（そもそも公開しているがAllUsersやAllAuthenticatedUsersや各ユーザに権限がついていないだけ）
Nearline…月1アクセス等
Coldline…年1アクセス等長期アーカイブ
(standard以外は最低保存期間の縛りがあり早期削除でもお金が掛かる)
5GBまで無料、リージョンで値段が違う、保存/NW/取得/操作で課金
nearlineの保存は半額で取得と併せstandardと同じ金額になるが操作費高い
coldline/archive storageでも長期保存はせずできれば削除する、できないならポリシーでcold/archiveへ移動
最低保存期間の縛り(90/365)があり早期削除でも請求、その期間は置いておく
autoclassだとニア→コールド→アーカイブといい感じにしてくれるが1000ファイルにつき0.0025追加料金
※128kb以下は適応されずstdで追加料金もかからない
Autoclassが安全便利でファーストチョイス
ログ保存用途ならColdline/Archive設定＋OLMでの削除設定
※GCSの注意点
早期削除料金の発生がリスク
オブジェクトライフサイクルマネージメントOLMでストレージクラスの変更すること
早期削除料金は削除、置換、移動、クラス移動でかかるが、OLMのクラス移動ではかからない
手動で変更するとStd以外は早期削除料金で高額化の恐れ
ただしOLMは若返りの方向へのストレージクラス変更はできない（要手動）
OLMの変更はファイル単位で変わりバケット設定をみてもクラスが分からない
Std以外は保存のみの使用としたい、なぜなら、置換はファイル編集が該当するためファイルサーバとできないから
費用は保存費、オペレーション費、NW費、Std以外は取得費等からなり、費用は利用サイズの影響が大きく、通常は保存より利用の費用が高くなる
早期削除料金はStd以外で削除されたり更新がかかればファイル単位でかかる
早期削除料金は最低保存期間分がかかるがファイル作成日を元に計算されどのストレージであっても日数としてカウントされる（ファイルに対してライフタイムで一度では？）
■GCP Cloud asset inventory
5週間分の履歴が保管される
CAI exportにより任意のタイムスタンプでBQあるいはGCSに履歴情報を吐き出す
コマンドやライブラリでダンプが可能
gcloud CLIのgcould asset search-all-resourseコマンドにより設定
BQに吐き出し各種状況のチェックやポリシーのチェックに活用
権限の確認もコマンドでできる
gcloud asset analyze-iam-policy --organization=123456 --identity="user:fack@unko.com"
■Cloud logging
毎月取込50GBまで無料、取込0.5$/GB+保存0.01$/GB、2種類ありAuditLogで有効無効化
管理アクティビティログ 13ヵ月400日デフォ有効（_requiredログバケットは取込もデフォ期間保存も完全無料）
データアクセスログ デフォ無効（有効にしてもデフォ保存期間30日は無料、50GBを超える取込が有料）
※つまり50GBを超えた取込、あるいは保存期間を伸ばした分が有料
BQ streaming insert0.05$/GB+BQ保存(10G無料)0.02/GB=0.07$/GBでBQ化し保存が得
長期保存が必要なものだけエクスポート
集約エクスポート
ログ取集前にログシンク(取込費がかからない)
サンプル1%等で絞る等
400日の_requiredに入らないものが30日の_defaultに入る
Logルータのシンクでフィルタ、サンプリングしLogバケット/GCS/BQ/Pubsubに転送
requiredでなくdefaultに入る時にLogルータを設定しフィルタを掛ければ減る
自動でSAが作られるので作成や権限付与は不要
包含フィルタが空なら全ログ
クエリsample(insertId, 0.10)で10%のサンプル
Logバケットのdefault30日は変更できる
全ログをBigqueryに入れるには組織プロジェクトで転送を設定すればいい
クエリ：Loggingをクエリで見る、Logルータのシンクをフィルタ(サンプル)する
■Monitoring
ダッシュボードはサンプルから作ると楽
MQLで改変、クエリを実行するとエラーメッセが出るんで
fetch gae_instance::appengine.googleapis.com/flex/cpu/utilization | { top1, max(val()); bottom 1, min(val()) } | UNION
■APIキー
APIキーを発行することで、外部アプリから利用できるようになる。各種使えるが強力なためAPIを絞る等制限を入れた方がよい、アクセス元のIPアドレスやリファラーで縛る等も
API キーを使用して認証する | Google Cloud【要確認】Google Maps Platform APIキーの取得方法と注意点 | ワードプレステーマTCD (tcd-theme.com)■サービスアカウント
デフォルトでは上限100個
svacキーはPWと同じ、できるだけ発行せず慎重に管理、gitにUP厳禁
svac名や役割を広くしない、強すぎる権限は付与せず最小限の権限で
GCEデフォのsvacは使用しない(Editorを持つから)
サービスアカウントはサービスを有効化したときに動作用に自動作成されたり、別途手動でも作れる
所属のプロジェクトが削除されると：
サービスアカウントは削除できなくなり、権限が残るため権限は個別削除が必要になる
サービスアカウントの権限が残るが、他のプロジェクトで使用できる
一定期間が経つとサービスアカウントの権限も自動削除される
＞プロジェクト削除前にサービスアカウントの無効にするのが望ましい
IAMでsvacにロールを付与、IAM>svacでユーザにsvacに対する管理ロールを付与できる
組織ポリシーでsvacキーの使用を特定のプロジェクトに制限した方が良い
できればキーを作成せず他の方法を
workload identity(gke)、workload identity federation(serverless)
SAMLみたいなものでGKE、OpenID、AWS、Azure、ActiveDirectory、GoogleCloudAPIは対応している
一発使用ならimpersonateで成り済ませば一連のgcloud cmdは実行できる(下記参照)
SAキーの管理方法
キーの削除、あるいはIAMコンディションにより権限側の変更、あるいはVPCサービスコントロールで制限位しかない
有効期限の設定は無い、キーローテート機能もなくコマンドで自作するしか（削除と作成をするだけ）
キーローテートを要求するため、キーは各々で発行してもらう
手前でキーを発行した方が、キー削除や追跡ができるがローテートの手間がある、手前だと権限付与も少なくできるが、、
svacキーはRSA鍵ペア、秘密鍵でJWT署名なしトークンを作成（JWT=json web token）
GCP内ではキーが自動rotateされている
外部の場合は手動や仕組みでローテーションしたい
開発環境ではクライアントライブラリとgoogle application credentials環境変数を使い隠匿する
サービス アカウント キーを管理するためのベスト プラクティス | IAM のドキュメント | Google CloudGoogle Cloud SDKのインストールと認証の設定について - TASK NOTES (task-notes.com)概要 / アジェンダ - Infra OnAir (cloudonair.withgoogle.com)秘密鍵さえあれば成り済ませ追跡が困難で誰が利用したか等が分からないのでsvacキーは使いたくない
svacキーは10個作成できる
/// svacキー使用方法
サービスアカウントのキーを作成しローカルに保存
SSHでGCEのVMに内容をコピペしてキーファイルを作成
下記でSAとしてログイン
gcloud auth activate-service-account ketsu@un.com --key-file /home/ketsu/sakey.json
cloud shell terminalでもファイルをアップロードできるのでup後下記でOK
gcloud auth activate-service-account ketsu@un.com --key-file sakey.json
ログオン切替
終わるとき rm sakey.json
shellセッションごとに環境変数でkeyを設定する方法も
認証のスタートガイド | Google Cloud/// サービスアカウントキーを発行せずにサービスアカウント権限を使う
IAM and Resource Manager API を有効化
サービスアカウントに使いたいロールを付与(roles/accesscontextmanager.policyAdminとか)
自身にroles/iam.serviceAccountTokenCreatorを付与
叩くgcloud info --impersonate-service-account=chinko-compute@developer.gserviceaccount.com
※tfだとproviderにimpersonate_service_accountを追加する形
設定するにはこれらしい
gcloud config set auth/impersonate_service_account chinko-compute@developer.gserviceaccount.com
svacを指定するならこれでもいいがKeyがいる
gcloud auth activate-service-account chinko-compute@developer.gserviceaccount.com --key-file=/himitsu/dame_key.json --project=bangboo-kuso
ログインユーザ確認で要確認
gcloud auth list
gcloudコマンドのリファレンス
■セック
Google workspace googleアカウント(特定の経路:IP以外は無効）
組織ポリシー(GCP)
Google Cloud 組織ポリシー - Qiita serviceuser.services deny compute.googleapis.com デフォルトcomputeなし
compute.skipDefaultNetworkCreation enforced=true デフォルトcompute nwなし
compute.vmExternalIpAccess inherit_from_parent=true
iam.allowedPolicyMemberDomains inherit_from_parent=true 対象組織 外部ユーザ禁止
→allusers/allauthuserも影響する(このためGCSもallusersが設定できず公開にはならない)
iam.allowedPolicyMemberDomains inherit_from_parent=false 対象prj 外部ユーザ許可
storage.uniformBucketLevelAccess enforced=true GCSアクセス制御を均一
storage.publicAccessPrevention=true 公開しない(allusersも消える、逆にoffってもallusersも要る)
sql.restrictAutherizedNetwork enforced=true CloudSQLのネットワーク制限
compute.restrictLoadBalancerCreationForTypes allow=in:INTERNAL LBは内部だけ許可
compute.restrictLoadBalancerCreationForTypes allow=all=true 対象prj LB許可
compute.disableSerialortAccess enforced=true シリアルポートアクセスの制限
compute.disableSerialortAccess enforced=false 対象prj シリアルポートアクセスの許可
BeyondCorp Enterprise(VPNレス、なお下の各要素はこの為だけということではない)
┣ IAP
┣ IAM
┣ Access Context Manager(VPC Service Controls:IPとかメールドメインとか)
┗ Endpoint Verification(Chrome機能拡張)
Cloud armor(WAF)、FW
危険な設定はアラートを出したい：security command center、cloud asset inventoryをBQに出し定期スキャン
BigQueryの高額クエリはアラートを出したい
セキュアなBigQueryの運用方法 - Speaker Deck IAM condition: 20時以降はアクセスできない等時間やリソースで権限制御
VPC-ServiceControls: VPC+FWで制限を掛けられなかったIPやIDで制限を掛ける(クレデンシャル漏洩防御)
LBのバックエンドをGCSにするとIAPが使えない時も
TF)perimeterで境界を設定してaccess leveで超えれるものを定義
危険で user explicit dry run spec = trueでテストしながら falseで本番化
statusが本番用、specがドライラン用で一旦statusを消してテスト
restricted_services = storage.googleapis.com ならGCS
resource
access_level
https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/access_context_manager_service_perimeter
サブネット作成の際はセキュリティの観点からフローログを15分で取る
監査ログを有効に
ContainerResistryの脆弱性スキャンを有効に
ログ：データアクセス/ポリシー拒否は30日、管理アクティビティは400日
BQにバックアップしたい
SecurityCommandCenterで脆弱性を検知
■タグとラベル
組織ポリシーはタグでconditionを指定した上で設定できる
タグは権限管理のための機能
タグは事前に組織レベルでタグを作成する、その後にリソースに対しタグ付け
FWで使うのはネットワークタグで種類が違うと思われる
ラベルはリソース整理や課金整理のための機能
■ネットワーク
外部IP
External IP addressで取得、300円/月位、通常一つは自動で割り当てられる
PoP(Point of presence)
世界70か所でGCPとエッジ(ネット)接続
NWトポロジーで通信が可視化でき通信コストが分かる
詳細開くのは片側だけにすると使用帯域が表示される
■課金
BillingのBilling ExportからBigQueryにダンプができる
■サービスイン、導入、廃止
どういうステップかよくわからんが
GA(Generally available)
サービスに関する重要なお知らせ：MSA(Mandatory service announcement)
Deprecated
Decommission
■他
///gcloudをプロキシで使う環境設定とか
https://qiita.com/tora470/items/bc00bef8cba9f9acecc7
///Loadbalancer
IAPはhttp LB/GCE/AppEngineに
Internal LBにExternal IPは無理
ついでにIAP tunnel userの権限で踏み台が作れる＋OS Loginで認証強化
OS LoginはIAPの認証機能でSSH上でGCEインスタンスにログインできる代物
GCPがSSH keyとIAMをGCEに準備してくれる
ついでにリバースプロキシ（nginxとかで作る）
LBみたいなもんだがプロキシでキャッシュを返す
代理代表サーバとなりWEBサーバ界のFWみたいな役割もできる
///NoSQL
=not only sql、分散kvsだったりの非構造化データ、下記2つのみ提供
キーを指定してCRUD(追加、取得、更新、削除)
キーの範囲かキーの前方一致でのスキャン
///bigtable
高スループット低レイテンシー読み書き速く膨大なユーザや数千万件テラ以上で
gmail、GA、マップ等々で使われている
///cloud functions
サーバレスでRESTみたいな形でURLでサーバアプリを実行、Node.js/PHP/Python等のコードが直接コンソールに掛ける
curl https://REGION-PROJECT_ID.cloudfunctions.net/FUNCTION_NAME -H "Authorization: bearer $(gcloud auth print-identity-token)"
↑curlでいいなら、コンソールで[未認証の呼び出しを許可する] 設定 + allusersでも可
///Pub/Sub
パプリッシャーからサブスクライバーにメッセージ転送、順序設定可、大量データを1件ずつとか
publisher -> topic : メッセージ -> push型 subscriber
publisher -> topic : メッセージ -> pull型 subscriber
-> cloud functions/runに連携したり、cloud schedulerから連携をしたり
BQ テーブルにデータをエクスポートする Dataflow ジョブ
GCS でデータをテキスト ファイルまたは Avro ファイルにエクスポートするための Dataflow ジョブ
///シリアルコンソール接続
SSH接続できない！そんな時のシリアルコンソール | apps-gcp.com突然起動しなくなったWordPressサーバーをなんとか復旧した話 | (tipstock.net)///gcloud cmd
gcloud organization list GCP IDやGoogleWorkspace IDが分かる
///Recommender
API の使用 - 推奨事項 | Recommender のドキュメント | Google Cloud///Googleスプレッドシート+GAS＋BigQuery
GAS:マクロで記録してそれを使いまわす
GASでBQの制御は難しいかも、更新してもBQのデータが古いままだったりする（appscript.jsonに権限を追記しても）
シート経由せずにGASから直にファイルに書き出すとましかも（下記コード参照）
データを一時でも書込ならスプレッドシートの共有の編集権限とシート保護しない設定が必要と思われ（セキュリティがザルに）
呼び名
connected sheetでBQのデータをスプシに抽出する
federated queryはBQに外部ソース（スプシ等）をインポートする
スプシの保護（シートはコピーできザルなのでセキュリティ対策でなくデータ保護）
シートを保護する、非表示にする、編集する - パソコン - ドキュメント エディタ ヘルプ (google.com)スプシの閲覧共有だけでBQコネクテッドシートのプレビュー/抽出は可能だが、それをvlookup系で他のセルに移せない
組織でコネクテッド シートを使用する - Google Workspace 管理者 ヘルプ↓
■アプリ
公開資料 - App Modernization OnAir 〜 モダンなアプリケーション開発とは 〜 (cloudonair.withgoogle.com)cloud runの設定だけでCDCIできる（第10回
End
公式
https://www.terraform.io/docs/index.html
導入
https://www.terraform.io/guides/core-workflow.html
推奨方法
https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part1.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part2.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.1.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.2.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.3.html
https://www.terraform.io/docs/cloud/guides/recommended-practices/part3.4.html
チュートリアル
https://learn.hashicorp.com/collections/terraform/gcp-get-started
HCL
https://www.terraform.io/docs/language/index.html
CLI aka cmd（アルファベットリストから使う）
https://www.terraform.io/docs/cli/auth/index.html
GCP用リファレンス
https://registry.terraform.io/providers/hashicorp/google/latest/docs
お便強
https://qiita.com/minamijoyo/items/1f57c62bed781ab8f4d7
https://qiita.com/donko_/items/6289bb31fecfce2cda79
https://www.apps-gcp.com/infra-automation-01/
https://colsis.jp/blog/gcpterraform/
Infra as codeとしてインフラの構築や設定をコード化できる
特にクラウドだと構築の自動化や構成管理等でのレバレッジが強力
■段階
Terraformとは?基本知識とTerraformのメリット4つを紹介 | テックマガジン from FEnetインフラ必要なリソースをTerraform化>workspaceの活用>main.tfの共通部分をmodule化
moduleは構成に合わないようなリファクタリングが必要になった時にterraform state mv が必要になってとたんにつらい、moduleを細分化しすぎるとvariable と output が大量に必要になって書きづらい、moduleは再利用できる複数のリソースの単位（プログラミング言語でいうところの関数みたいなもの）で作るのがしっくり
リソースの差分を無視するlifecycleブロックを使う
resource "aws_autoscaling_group" "app_1" {
name = "app-asg-1"
lifecycle {
ignore_changes = ["load_balancers"]
create_before_destroy = true//新しいのを作ってから古いのを削除
}
}
外部ファイルを文字列として読み込む
resource "aws_iam_role" "ec2_role" {
name = "ec2-role"
assume_role_policy = "${file("./ec2_assume_role_policy.json")}"
}
1つのディレクトリで複数のStateを扱うWorkspaceという機能もあるのですが、
個人的には普通にディレクトリを分けて管理する方が楽
production/stagingが完全に同じリソース構成で、設定のパラメータの差分がちょっとだけあるという理想的な世界ではWorkspaceでも運用できるかもしれませんが、現実的にはstagingだけリリース前の検証用の一時的なリソースが立ってたりとか、完全に同じ構成にならないことも多いので、モジュールの読み込みの有無や一部の環境だけ存在するリソースなどの差分を吸収できる場所があったほうが都合がよい
モジュールが公式から提供されている
Browse Modules | Terraform RegistryTerraform の terraform.tfvars とは | 30歳未経験からのITエンジニア (se-from30.com)環境情報は外部ファイルが基本
prd/stg/dev環境はprd.tfvars, stg.tfvars, dev.tfvarsを用意
.tfvars 各環境の設定
aws_access_key = "XXXXXXXXXXXXXXXXXXXX"
aws_secret_key = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
aws_region = "eu-west-1"
main.tf
terraform {
required_version = "= 0.12.26"
}
provider "aws" {
version = "2.66.0"
access_key = var.aws_access_key
secret_key = var.aws_secret_key
region = var.aws_region
}
var.tf 空の受け皿
variable aws_access_key {}
variable aws_secret_key {}
variable aws_region {}
Terraform で変数を使う - Qiita実行時に-var-fileで値ファイルを指定して環境などを切り替えると良いかもしれない
terrafrom plan -var-file=dev.tfvars
terrafrom plan -var-file=prod.tfvars
変数ファイル指定がないときは変数でdefaultに入れておく、descriptionで変数の説明もかける
variable "foo" {
type = "string"
default = "default-var"
description = "Sample Variable"
}
変数ファイルを異なるバックエンド(フォルダ構成)で共有したいときはシンボリックリンクを貼る
ln -s ../common/shared_var.tf shared_var.tf
credentials等の秘匿したい変数を外部のファイルやコマンドライン引数から読み込む
variable "credentials_file" {} ＠var.tf 変数を定義し空にしておく
credentials = file(var.credentials_file) ＠main.tf ファイルを読むがファイル名は変数
terraform plan -var 'project=
' -var 'credentials_file=.json' ＠cmd プロジェクトとクレデンをコマンド時に指定
他にもvars.tfvars設定ファイル(行頭variableが不要)、TF_VAR_環境変数による指定-var-fileで変数ファイルを明示してcmd、ファイル名は.tfvars/.tfvars.json
-varで変数を明示してcmd
順序があり後の読込でオーバーライド
↓
HCLの変数は基本2種類のlocalとvariable
variableはグローバル変数、ファイル外やコマンドラインから使える
その他の変数参照方法としては（上から優先に適応）
コマンド引数 一時的に使用
変数ファイル terraform.tfvars git管理等で外部ファイルで？
環境変数 TF_VAR_ 実行ログに残らない鍵情報等
workspaceは使わない、moduleを限定的に使う
設定をコード化>Gitレポジトリに置く>設定内容、作業履歴の明確化、チームでの運用性向上
■特性
TFの影響を反映するのはterraform applyの時だけ、tfファイルとtfstateの差分を実際にリソース作成する
tfファイルで変更した場合、TFはリソースの再作成を行うので一度消えることになる（大体は単位が権限だったりで影響がないだけでplanで要注意）
terraform planはtfとtfstateと実体の差なので、実体があってもtfstateになければwill be createdでplan時は表示される
terraform importはtfファイルからtfstateへ記載だけを行う(実体からも情報を取得しtfstateに入れる)
カレントdirの全.tfファイルor.tf.jsonを評価するのでtfファイルの名は何でもいい
各リソースに対してTF化するかは選択ができるが、TFする場合はそのリソースに必要な全記載をTFファイルに行う
terraform import tfResourceID.yourResourceName gcpIdentifier のコマンド
terrafrom import google_bigquery_dataset.tf-1 bangboo-prj/test-dataset
tfResourceID(リソースIDというようタイプ：リソース種別)はTF指定のもの、yourResourceName (リソース名)は任意のもの
構成ファイル.tfはローカルのものが使われる、importするとtfstateに反映
GCP identifierはTF公式サイトの各サービスの一番下import項目を見ると指定内容が分かるのでGCPを見て拾ってくる
terraform state list TF化されているリソースを見る
terrarorm apply時にもtfstateは更新される（オプション-refresh=falseで無効可）
またapply時に-target=xxxでデプロイするリソースを特定できる(TFファイルだけでなくTFステートもターゲットになる)
resource "google_sql_database_instance" "instance" {
provider = google-beta
name = "my-database-instance"
}
resource "google_sql_database" "db" {
instance = google_sql_database_instance.instance.name
name = "db"
}
ToSetは値設定をするが順不同で重複を省く
resource "xxx" "aaa" {
for_each = toset(["foo", "bar", "bar"]) でbar, foo
name = each.key
}
for_each/eachのループ
locals {
sg = {
foo = "FOO"
bar = "BAR"
}
}
resource "xxx" "aaa" {
for_each = local.sg
name = each.key
description = each.value
}
mapをリストしたものをfor_each
locals {
images = [
{ name = "foo", image = "alpine" },
{ name = "bar", image = "debian" },
]
}
resource "docker_container" "this" {
for_each = { for i in local.images : i.name => i } # こう書くのが正しい
name = each.value.name
image = each.value.image
}
terraform importはリソース単位、更新はできず削除してから追加 terraform state rm google_bigquery_dataset.tf-1
実設定とimportの内容が違う場合は実設定の情報でtfstate化されるようだ(importは項目を入れ込む感じ？)
なので実環境に変更を加えるにはterrafrom apply、tfstate化もされtfファイル/tfstate/実設定の3者で同じになる
apply時にtfstateと実設定が違う場合、例えば既存設定がある場合は重複エラーになりapplyできず、importしtfstateと実設定を同じにしてから、tfファイルの内容をapplyすることが必要
for_eachで書いた.tfをterraform importする | DevelopersIO (classmethod.jp) ユーザ指定は user:aaa@xxx.com だったりメールグループなら group:aaa@xxx.com
■セットアップ
作業ディレクトリの作成(プロジェクトに対するローカルのフォルダ）
プロバイダを指定したtfファイルの作成(gcsにstateを置く設定が良い
provider "google" {
project = "bangboo-kuso"
}
terraform {
backend "gcs" {
bucket = "bangboo-kuso-terraform"
}
}
terraform init ローカルに対して初期化
プロジェクトレベルownerのサービスアカウントを持っておく
セットアップする際にtfsateのbackend保存場所のbucket部分をコメントアウト
bucketを作るterraformを実施しbucketを作成しつつlocalにtfstateファイルを作成
再度terraformをするとtfstateファイルがbucketにコピーされる
bucket部分のコメントアウトを外すと次回tfからはバケットにtfstate更新する
このときローカルtfstateの内容をバケットに写すか聞かれるが写す
（写さないと差分しかバケットに行かないのでimport等が必要になる）
■既存リソースのTF化のおおよその作業
リソースタイプと名前を定義したtfファイルを作成する(任意のリソース名、基本ユニーク、纏められるものは重複してもいい)
resource "google_cloudfunctions_function" "fuckin" { ... をtfファイルに記載
tfResourceID(リソースIDというようタイプ：リソース種別)とyourResourceName (リソース名) だけで
リソースタイプや個別パラメータは公式ドキュメントを参照しながら定義
https://registry.terraform.io/providers/hashicorp/google/latest/docs
(簡単)tfファイル内で１行目以外は空で、terraform planをするとエラーで必要なものが分かるので、それを埋める
planが通ると自動的に値をサーバから拾ってくる（importすればtfstate.tfに入っている or コピーしてTFに入れる）
planでダメならterraform state show tfResourceID.yourResourceName でstateを見てtfファイルにパラメータを定義していく
暫定に空でリソースをTFファイルに記載しterraform import、次にtfstateを調査する
terraform state list tfstateファイルにあるアセットを一覧
terraform import google_bigquery_table.xxx project/dataset/table インポート
terraform state show google_bigquery_table.xxx tfstateの該当部を表示
terraform state rm google_bigquery_table.xxx インポート取り消し
TF定義は複数の方法がある、最終GCP公式のRestAPIで確認するしか
terraform importする（公式ドキュメントの一番下にimportコマンドの指定がある）
terraform planして差分がなくなるまでtfファイルを修正する
import(tfstate)の修正は一度stateから削除する terraform state rm google_bigquery_dataset.tf-1
(既存リソースがあってもあくまでtfファイルとtfstateの差分なのでinitした状態でplanしてもup-to-dateと表示されるだけ)
tfstateファイルにおかしなものが無いか確認、keyとか含まれないか
■個別
リファレンスでoptionalとなっていてもtfファイルでは必要な場合もある
tfstateファイルからは必要ないとして自動的に削除されるが
スプシをBQでみれるFederatedQueryはテーブルだけ定義しimportしstate show調査
urlをTFファイルに記載する
シャーディング（日付別）テーブルは定義できないのでは
生成するクエリの方をTF化したい
Authorized viewはモジュールがあるがconflictがあり全消えする場合がありTF化にまだ向かない
google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。
Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。
google_bigquer_dataset_iam_policy と google_bigquery_iam_binding は Authoritative で権限追加でなく権限強制設定でコンソール付与分を引き剝がすので、使わない方が安全。
なお、Authorized view と Routines はTerraform化できない事が分かっている（2022/4時点）
ScheduledQuery は Terraform化できるが実行者の設定ができない（Terraform実行者がSQ実行者？誰？）
BQ関連ではデータセット定義、テーブル定義、ビュー定義、フェデレテッドクエリ定義、ScheduledQuery定義をTerraformで行い
BQ権限定義、AuthorizedView定義、Routines定義は行わない
BQ権限を定義するならデータセットレベルはgoogle_bigquery_dataset_access
プロジェクトレベルはgoogle_project_iam_memberで実施すると別なので安全らしい？
■TF公式ドキュメント
google_organization_iam_custom_role | Resources | hashicorp/google | Terraform Registrygoogle_organization_iam | Resources | hashicorp/google | Terraform Registryカスタムロールを設定して、組織レベルのIAMでそれを使いたい
TFのorg_iamページのArgument referenceのrole項目を見ると
Note that custom roles must be of the format organizations/{{org_id}}/roles/{{role_id}}
TFのorg_iam_custom_roleページのAttributes referenceのrole項目を見ると
id - an identifier for the resource with the format organizations/{{org_id}}/roles/{{role_id}}
で下記と分かる、使用側と被使用側のTFマニュアルを両方確認する
resource "google_organization_iam_custom_role" "my-custom-role" {
role_id = "myCustomRole"
org_id = "123456789"
title = "My Custom Role"
description = "A description"
permissions = ["iam.roles.list", "iam.roles.create", "iam.roles.delete"]
}
resource "google_organization_iam_member" "my-organization" {
org_id = "123456789"
role = google_organization_iam_custom_role.my-custom-role.id
#あるいは通常"roles/bigquery.dataEditor"のようにいれるがorganizations/0123456789/roles/chinkoといれる
member = "user:jane@example.com"
}
↑
resourceの2番目リソース名を定義しますが任意の名前を指定します
ここが同じ項目はユニーク制限がない場合は追加としてまとめられます
通常はユニークにしterraformで管理するリソース名(yourResourceName)を宣言します
※1番目のリソースタイプ内でユニークにするのが基本（全体でもユニークの方が分かり易い）
TFファイルに定義をしたい →定義したいリソースのArgument referenceの項目を設定
TFファイルに定義した内容を変数で使いたい →使いたいリソースのAttributes referenceを見る
terraform importしたい →インポしたいリソースのページ一番下のimportコマンドの指定を見る
■他に一般的なTF（既存がimportされると以下で変更をapplyして運用）
terraform -v 稼働確認
terraform fmt ファイルの記述フォーマットを整える
terraform validate ファイルの検証
terraform plan アクションを計画
terraform apply 最後に変更を適応
terraform show ステータスを確認、一覧
terraform destroy で簡単にインフラの吐き、initができないとき必要そう
■特定のリソースだけ適応したい
terraform plan -target="tfResourceID.yourResourceName"
terraform apply -target="tfResourceID.yourResourceName"
TFファイルだけでなくTFステートもターゲットに含まれる
これでTFファイルにコードがなくTFステートだけにあるものを指定して削除等もできる
■tfenvを使う場合
tfenv install 1.0.0
tfenv list
tfenv use 1.0.0
terraform init
terraform workspace list
terraform workspace select ore_space
main.tf作成し記載
terraform fmt tfファイルのフォーマット（書式は適当で書けばいい）
gcloud auth login ローカル操作のための認証
gcloud auth application-default login SDKを実行のための認証
API&Servicesでクレデンシャルは取得できそう、key=xxxx
既存のリソースを調査
terrafrom import google_storage_bucket.pri-bucket project-abc123/asia-northeast1/pri-bucket でimportとか
terraform refresh tfstateの最新化、どのタイミングで使う？
■既存のリソースを調査
terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123 とか
既存リソースimport
https://www.apps-gcp.com/terraformit-gcp/
ダメなら terraform state rm で不要分を削る
新環境用にtfファイルを準備
新環境で下記を実行
terraform init
terraform state push xxx.tfstate
terraform planで差分がないことを確認
■gcloud cmd
https://www.devsamurai.com/ja/gcp-terraform-101/
gcloud projects list 権限あるプロジェクトを表示
gcloud config set project [prjID] ワーキングプロジェクトの設定
gcloud services enable iam.googleapis.com サービスの有効化
gcloud iam service-accounts create terraform-serviceaccount \
--display-name "Account for Terraform" サービスアカウント作成
gcloud projects add-iam-policy-binding [PROJECT_ID]
--member serviceAccount:terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com --role roles/editor 権限付与
gcloud iam service-accounts keys create path_to_save/account.json
--iam-account terraform-serviceaccount@[PROJECT_ID].iam.gserviceaccount.com クレデン発行
■Linux terminal
tabで入力補完
↑↓で入力履歴呼び出し
^qはCtrl+qを押すという意味
半角/全角キー 日本語を切り替える（画面右上にもIMEがある、win+spaceの場合も）
ls -la ディレクトリ内を表示
ls -a 隠しファイルを含み表示
（GUI）ctl+h 隠しファイルを表示（メニューでもチェックで可）
pwd 現ワーク中のディレクトリを表示
cd ../ 上に上がる
mv beforeName.text afterName.txt ファイル名変更
rm -R ディレクトリ名 削除、ファイルはrm a.txt
ls -l > hoge.txt >結果を上書き
ls -l >> hoge.txt >>結果を追記
printenv 環境変数表示 printenv xで特定表示
grep aaa -rl ./ カレントディレクトリ以下からファイル内にaaaが含まれるファイルを検索
テキスト選択
Shift↑or↓ で行全体
home(+fn)で行頭、end(+fn)で行末移動
nano text.txt 作成あるいは開く、nano簡単かも、画面下コマンドでctrl+?すればいい
コマンドM-UはEsc+u
ctrl+k で１行削除
■viエディタ
sudo apt install vim
vi text.txt ファイル作成あるいは開く
viは2つ＋αのモード
┣コマンドモード
┃┗コロンモード（exモード:祖先のラインエディタ）
Escでコマンドへ抜ける
┗挿入 i （入力モード）
ファイル名を指定し保存 :w new_file_name.txt
強制保存のコマンド :w!
保存せず終了 :q 強制終了 :q!
:10 10行目に移動
:set number 行数を表示
:num 現在のカーソル位置行数を表示
$ カーソルを行末へ
G カーソルを最終行行頭へ
- 前行の行頭へ
Enter 次行の行頭へ
w カーソルを1語進める
b カーソルを1語戻す
Ctrl-d 1/2画面下へ(down)
Ctrl-u 1/2画面上へ(up)
Ctrl-f 1画面下へ(foward)
Ctrl-b 1画面上へ(back)
/文字列(Enter要) 文字列検索(スラッシュ)
┣n 次の検索文字列へ
┗N 前の検索文字列へ 保存して終了 :wq 保存して強制終了 :wq!
■環境変数は下記の順で探す、なので必要なら下位のものを上にコピー
~/.bash_profile
~/.bash_login
~/.profile
■SSHの設定
Linuxコマンド【 ssh-keygen 】認証用の鍵を生成 - Linux入門 - Webkaru$ ssh-keygen
パスフレーズは空でも設定上は問題ないが塩っ気が足らん気が
秘密鍵（id_rsa）と公開鍵（id_rsa.pub）が生成され、ホームディレクトリに作成される
/home/yourID/.ssh/id_rsa
/home/yourID/.ssh/id_rsa.pub.
公開鍵をSSHサーバや外部サービスに登録する等して使う、秘密鍵は明かさないこと
$ vi ~/.ssh/config
Host oketsu
HostName 1.XXX.XXX.XXX
User hoge
IdentityFile ~/.ssh/id_rsa.pub
LocalForward 5912 localhost:5902
ProxyCommand connect-proxy -H proxy.syanai.in:8022 %h %p
Host github.com
HostName ssh.github.com
Port 443
IdentityFile ~/.ssh/id_rsa.pub
ProxyCommand connect-proxy -H proxy.syanai.in:3128 %h %p
User githoge
$ chmod 600 .ssh/config
下記のように実行すると、ログイン/GITできます。
$ ssh oketsu
$ git clone githoge@github.com:kusogitry.git
＝＝＝＝＝＝＝＝＝＝＝＝＝
■VS code
マルチカーソル：ctrl+shift+↓
[Alt]+クリック | カーソルを追加 |
[Ctrl]+[Alt]+[↑]/[↓] | カーソルを上下に追加 |
[Ctrl]+[U] | カーソル操作を元に戻す |
[Shift]+[Alt]+[I] | カーソルを行末に追加 |
[Ctrl]+[L] | 行を選択 |
[Ctrl]+[Shift]+[L] | 選択中の文字列と同じものをすべて選択 |
[Ctrl]+[F2] | カーソル位置の単語と同じものををすべて選択 |
[Shift]+[Alt]+[→] | 選択範囲の拡大 |
[Shift]+[Alt]+[←] | 選択範囲の縮小 |
[Shift]+[Alt]+ドラッグ | 矩形選択 |
[Ctrl]+[Alt]+[Shift]+[カーソル] | 矩形選択 |
[Ctrl]+[Alt]+[Shift]+[PgUp]/[PgDn] | 矩形選択 ページ上下 |
VSCodeのマルチカーソル練習帳 - Qiitaマルチカーソルを使わないVSCodeはただのVSCodeだ！〜解説編〜 - memo_md (hateblo.jp)
