/// BANGBOO BLOG ///

January 17, 2022

Panty gore-tex / Never stop fucking

防水、防風、透湿の機能。擦りとかには弱そうでバイクには勿体ないか
圧力が掛かると水が浸み込むので意味ないかと思い込んでいたが、北風の寒さを打消し、ムレがないので汗をかきにくく寒い日の活動にメチャいい
infiniumは軽くて柔らかいが防水性がない
proはgore-texよりも透湿性が約30％アップ
普通30とか70デニールとかだがマンジャケは150デニール、糸の太さらしいが密度も上がる？マンジャケは裏生地もありトータル厚いがgore-texだけの厚さの違いは全然分からん
150DやProの方や、シャカシャカしている方が強いと思われるが、強度は張付ける生地側によるところが大きいのか触らなよく分からん→触って好みを買うしか
日本やアジアンサイズでMの場合は、並行輸入は要注意でワンサイズでかいのでS
futurelightは柔らかい、多分軽くて透湿性が優れてそうだが、シャカシャカのgore-texのパンティのゴワツキが好み、27年目の鎮魂

ITやinternetを上手く使えば戦争なんか起こるはずがない、そうならなかった　あぱー

Posted by funa : 02:23 AM | Gadget | Comment (0) | Trackback (0)

December 25, 2021

リンク踏合組合

シンプルで軽量！新しいCSSリセット「The New CSS Reset」を作成したElad Shechterにインタビュー | コリス (coliss.com)
【2021年版】おすすめのリセットCSSまとめ！基本と使い方の解説も | Web Design Trends (webdesign-trends.net)
【2021年版】リセットCSSのガイドライン｜基礎から使い方を徹底解説 - WEBCAMP MEDIA (web-camp.io)

新しい日本語フォントがたくさんリリースされてる！ 2021年、日本語の新作フリーフォントのまとめ | コリス (coliss.com)
2022年用、日本語のフリーフォント573種類のまとめ -商用サイトだけでなく紙や同人誌などの利用も明記 | コリス (coliss.com)

BigQueryにおけるポリシータグを用いた秘密情報管理とデータ連携の仕組み - ZOZO TECH BLOG
【新機能】Google Cloud 純正の構成図ツール Architecture Diagramming Tool が発表されました | DevelopersIO (classmethod.jp)
[B! 技術] とりあえずWebサービス作る時の私の技術選定ポイント (hatena.ne.jp)

----------------

LiveとPushを使用した音楽制作 | Ableton
ABLETON LIVE 特集｜サウンドハウス (soundhouse.co.jp)
製品情報：APC40：AKAI professsional (akai-pro.jp)

音楽制作に弾みをつけてくれる無料オンラインツール１０選 | LANDR Blog
signal - Online MIDI Editor

最近こういう奴多いよな、なんか命令とか受けとんのか、カミカゼけ

Posted by funa : 05:46 PM | Web | Comment (0) | Trackback (0)

December 2, 2021

B=AIDMA R MAT SURE

フォッグの消費者行動モデル　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) 全体に適用する

Posted by funa : 12:16 AM | Column | Comment (0) | Trackback (0)

June 9, 2021

k8s

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

ケツが扱う最小単位が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とは？仕組みと構造をわかりやすく解説 - カゴヤのサーバー研究室 (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

これはいいかも
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

spec:

selector:

matchLabels:

run: handson-4

template:

metadata:

labels:

run: handson-4

spec:

containers:

- image: nginx

ports:

- containerPort: 80

---

apiVersion: v1

kind: Service

metadata:

labels:

run: 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>

Posted by funa : 12:01 AM | Web | Comment (0) | Trackback (0)

May 22, 2021

GCP ログ調査 Logging/Bigquery information schema

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

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

resource.labels.instance_id="12234567898"

severity=WARNING

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

connected_sheets

bigquery.Jobs.create

bigquery.googleapis.com

docId

--データセット名

dataset ni_access_sarerudayo

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

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

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

BigQuery INFORMATION_SCHEMA の概要 | Google Cloud

//// 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'

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)

May 21, 2021

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-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、値にパス

　　　キー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有効

　　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

●コンソール
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 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を求められる場合

　　　　sudo su - でrootに切り替えてからcmd　sudo su とかしてる人はだいたいおっさん (zenn.dev)

　　systemctl list-units --type=service　サービスの一覧確認

　　systemctl list-units --all --type=service　全サービスの一覧確認

　　service サービス名 status

　　service サービス名 start

FW/ArmorでIngress全止め or VMインスタンス停止、LB停止

■GCE MIGローリング更新

GCP のローリング更新が恐ろしく便利で簡単でおしっこ漏らしそう - 強まっていこう (hateblo.jp)
MIG 内の VM に新しい構成を適用する | Compute Engine ドキュメント | Google Cloud

MIG で VM 構成の更新を自動的に適用する | Compute Engine ドキュメント | Google Cloud

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エージェント入れる

Ops エージェントの概要 | Cloud Logging | Google Cloud

エージェントポリシーの管理 | オペレーションスイート | Google Cloud

Ops エージェントの構成 | Cloud Logging | Google Cloud

GCPの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_agent

Numpyが要る場合は下記でインスコ

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 Cloud

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位まで)

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 でインスコ

<?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">

SSLに対応したNGINXリバースプロキシを構築する手順 - Qiita

　nginxは静的コンテンツを高速に配信するように設計されている。また、リバースプロキシの機能を持つため、背後にWebアプリケーションサーバを配置して動的なコンテンツを配信したり、ソフトウェアロードバランサやHTTPキャッシュとしても使うこともできる。

GCPにセキュアな踏み台サーバーを作成する. GCPのIdentity-Aware… | by Taiga Murakami | google-cloud-jp | Medium
　Googleにバックドアを開けてしまっては危険、、、ということはない

End

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)

May 20, 2021

GCP

■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/094054
https://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

無料枠

Google Cloud の無料プログラム

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による２段階認証、信用するデバイスの設定があるようだ

GCP ハンズオンセミナー Google_Cloud_GCPHandson_infra1122.pdf (cloudplatformonline.com)

　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アカウントにして使用する

外部ドメインのユーザの場合はメールグループ単位でのロール付与が効かず個別アカウントで付与する必要がある？あるいは組織ポリシーを開けっ放し？

メールグループの権限関係の確認方法
　仕組み：祖->親->子、上の権限は下も持つ

　権限から確認する、所属から確認するの両面で確認

　１）権限を持っている全ての子をリストアップ

　２）所属しているメールグループの全ての親をリストアップ

//リソース
階層：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 tasks list | Google Cloud CLI Documentation

どの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

ログイン

gcloud auth application-default login

デフォルト以外のプロファイルを使う

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

gcloud でプロジェクトの切り替え設定 - Qiita

■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以外は最低保存期間の縛りがあり早期削除でもお金が掛かる)

　Multi-regional 99.95%、Regional 99.9%の可用性
料金 | Cloud Storage | Google Cloud

　　5GBまで無料、リージョンで値段が違う、保存/NW/取得/操作で課金

　　nearlineの保存は半額で取得と併せstandardと同じ金額になるが操作費高い

　　　月1未満ならnearline

　　coldline/archive storageは年1程度とされているが使うと結構お金が掛かる

　　　長期保存はせずできれば削除する、できないならポリシーでcold/archiveへ移動

　　　　最低保存期間の縛り(90/365)があり早期削除でも請求、その期間は置いておく

■GCP Cloud asset inventory

　5週間分の履歴が保管される

　CAI exportにより任意のタイムスタンプでBQあるいはGCSに履歴情報を吐き出す

　gcloud CLIのgcould asset search-all-resourseコマンドにより設定
　　BQに吐き出し各種状況のチェックやポリシーのチェックに活用
PythonのライブラリでBQにダンプできる

■Cloud logging

Cloud Audit Logging 活用のベストプラクティス | Google Cloud Blog

Stackdriver Loggingのログを失う前にエクスポートしておく方法（前編） | apps-gcp.com

Stackdriver Loggingのログを失う前にエクスポートしておく方法（後編） | apps-gcp.com

Google Cloudの監査ログを理解する&長期間保存方法 - NRIネットコム Design and Tech Blog (nri-net.com)
Cloud Loggingの利用方法 | apps-gcp.com
料金 | オペレーションスイート | Google Cloud

　毎月取込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%等で絞る等

Google Cloud のログ設定 Cloud Logging の概要と一部設定など - Qiita

Cloud Logging の基本的な使い方 - Qoosky

クイックスタート: gcloud CLI を使用したログエントリの書き込みとクエリ | Cloud Logging | Google Cloud

400日の_requiredに入らないものが30日の_defaultに入る

Logルータのシンクでフィルタ、サンプリングしLogバケット/GCS/BQ/Pubsubに転送

　requiredでなくdefaultに入る時にLogルータを設定しフィルタを掛ければ減る
　自動でSAが作られるので作成や権限付与は不要

　　包含フィルタが空なら全ログ

　　クエリsample(insertId, 0.10)で10%のサンプル

Logバケットのdefault30日は変更できる

ログエクスプローラを使用したサンプルクエリ | Cloud Logging | Google Cloud
Logging のクエリ言語 | Google Cloud
　/// BANGBOO BLOG /// - GCP ログ調査 Logging/Bigquery information schema

クエリ：Loggingをクエリで見る、Logルータのシンクをフィルタ(サンプル)する

■Monitoring
ダッシュボードはサンプルから作ると楽

MQLで改変、クエリを実行するとエラーメッセが出るんで

fetch gae_instance::appengine.googleapis.com/flex/cpu/utilization | { top1, max(val()); bottom 1, min(val()) } | UNION

Google Cloud metrics | Cloud Monitoring

■APIキー
APIキーを発行することで、外部アプリから利用できるようになる。各種使えるが強力なためAPIを絞る等制限を入れた方がよい、アクセス元のIPアドレスやリファラーで縛る等も
API キーを使用して認証する | Google Cloud
【要確認】Google Maps Platform APIキーの取得方法と注意点 | ワードプレステーマTCD (tcd-theme.com)

■サービスアカウント

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 Cloud
Google 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

/// サービスアカウントキーを発行せずにサービスアカウント権限を使う

サービスアカウントに直接成り代わって gcloud コマンドを実行する - Qiita
サービスアカウントの権限借用の管理 | IAM のドキュメント | Google Cloud

gceにデフォルトsvacが設定されていれば誰で入ってもauthはsvac？パスはユーザだが

任意のコマンドに--impersonate-service-account=ワイルドフラグを付けるだけ

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コマンドのリファレンス

　gcloud auth activate-service-account | Google Cloud CLI Documentation

■セック

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

GCPでセキュリティガードレールを作るための方法と推しテク - Speaker Deck

　サブネット作成の際はセキュリティの観点からフローログを15分で取る

　監査ログを有効に

　ContainerResistryの脆弱性スキャンを有効に

　ログ：データアクセス/ポリシー拒否は30日、管理アクティビティは400日

　　BQにバックアップしたい

　SecurityCommandCenterで脆弱性を検知

Cloud Audit Logging 活用のベストプラクティス | Google Cloud Blog
　集約エクスポートシンクにより監査ログをBQに貯めたい

■タグとラベル

組織ポリシーはタグでconditionを指定した上で設定できる

タグは権限管理のための機能

タグは事前に組織レベルでタグを作成する、その後にリソースに対しタグ付け

FWで使うのはネットワークタグで種類が違うと思われる

ラベルはリソース整理や課金整理のための機能

タグとラベルの違いについて (Tags / Labels) - G-gen Tech Blog

■ネットワーク

外部IP

　External IP addressで取得、300円/月位、通常一つは自動で割り当てられる

PoP(Point of presence)

　世界70か所でGCPとエッジ(ネット)接続

NWトポロジーで通信が可視化でき通信コストが分かる

Network Topology – Network Intelligence – Google Cloud Platform

　詳細開くのは片側だけにすると使用帯域が表示される

■課金
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等のコードが直接コンソールに掛ける

　ブラウザでcloud functionsにアクセスしたら下記が出た
Error: Forbidden Your client does not have permission to get URL/kuso-ketsu from this server
呼び出しの認証 | Google Cloud Functions に関するドキュメント

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 管理者ヘルプ
↓

他のブックにすればいいかも
編集共有した別ブックに入力データ（日付やメール）を持たせBQフェデレテッドクエリでBQに準備
閲覧共有した別ブックは参照用にBQコネクテッドシートがある形

■シートを経由しないBQを操作するGAS

const request = {

query: "select * from asoko",

useLegacySql: false

};

let rows = [['c1','c2']]

const result = BigQuery.jobs.query(request, 'kuso-prj');

for(let i=0; i < result.rows.length; i++){

let resultRow = result.rows[1];

let c1 = resultRow.f[0].v;

let c2 = resultRow.f[1].v;

let row = [];

row.push(c1, c2);

rows.push(row);

}

const spreadsheet = SpreadsheetApp.create("file", rows.length, 2);

const range = spreadsheet.getRange("A:B");

range.setValues(rows);

Browser.msgBox("A file is created"+spreadsheet.getUrl(), Browser.Buttons.OK);

GASのGCPプロジェクトは通常はデフォルトがベスト
　GASはOauthのためだけにGCPのプロジェクトを使う

Google Cloud Platform Projects | Apps Script | Google Developers

デフォルトプロジェクトから切り替えると戻せない、利点も少しだけ（サイト参照）

appscript.jsonにoauthのスコープを追加しないと十分に機能しない
　GAS で OAuth のスコープが足りなくてやったこと (zenn.dev)
　GoogleAPIのOAuth2.0スコープ | Google Identity Platform | Google Developers
※エラーの場合
　BQの場合はBQコンソールでクエリ単体で実行しテスト
　loggingを見るともう少し情報がある
　スプシ等への共有設定とBQの閲覧ロール等が要る、ビューならその先の小孫～最後までのロールまで要る
　oauth自体でこけるとクッキー消去すれば待たずに再確認ができる？
Google Apps Script試行錯誤 Blog: デフォルトのGCPプロジェクトを標準のGCPプロジェクトに切り替えたい (pre-practice.net)
Google Apps ScriptのログをGoogle Cloud Platformで確認する方法 – hidetoshl.com

GASでAdminDirectoryを使う
　gas > サービス > AdminDirectory APIをOn
　gcp該当prj > APIダッシュボード > ライブラリ > Admin SDKを有効
　等でg workspaceのユーザ情報が取れるらしい
　　Google Apps Script試行錯誤 Blog: AdminDirectoryでUsers.listを取得したい (pre-practice.net)
　　GASでAdmin SDKを利用する（Directory編）その１ - Qiita

メールグループは任意にg workspace管理画面で削除が可能

GCP上はDeleted groupとなり1か月程度で削除される（IAMの状態は見れるが使えない）

■アプリ
公開資料 - App Modernization OnAir 〜モダンなアプリケーション開発とは〜 (cloudonair.withgoogle.com)
cloud runの設定だけでCDCIできる（第10回

End

Posted by funa : 09:00 PM | Web | Comment (0) | Trackback (0)

May 2, 2021

Terrafirma

公式

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/

TerraformでGCP環境を構築してみる | GMOアドパートナーズグループ TECH BLOG byGMO (gmo-ap.jp)

https://colsis.jp/blog/gcpterraform/

Infra as codeとしてインフラの構築や設定をコード化できる

特にクラウドだと構築の自動化や構成管理等でのレバレッジが強力

■段階
Terraformとは?基本知識とTerraformのメリット4つを紹介 | テックマガジン from FEnetインフラ
必要なリソースをTerraform化>workspaceの活用>main.tfの共通部分をmodule化

Terraform運用事例書きました - pixiv inside

moduleは構成に合わないようなリファクタリングが必要になった時にterraform state mv が必要になってとたんにつらい、moduleを細分化しすぎるとvariable と output が大量に必要になって書きづらい、moduleは再利用できる複数のリソースの単位（プログラミング言語でいうところの関数みたいなもの）で作るのがしっくり

Terraform職人入門: 日々の運用で学んだ知見を淡々とまとめる - Qiita

リソースの差分を無視する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だけリリース前の検証用の一時的なリソースが立ってたりとか、完全に同じ構成にならないことも多いので、モジュールの読み込みの有無や一部の環境だけ存在するリソースなどの差分を吸収できる場所があったほうが都合がよい

Terraform職人再入門2020 - Qiita
モジュールが公式から提供されている
Browse Modules | Terraform Registry

Terraform の 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

TerraformでGCPのリソースの作成と変数から値を読み込む - y-zumiの日記 (hatenablog.com)

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_環境変数による指定

Input Variables - Configuration Language - Terraform by HashiCorp

-var-fileで変数ファイルを明示してcmd、ファイル名は.tfvars/.tfvars.json

-varで変数を明示してcmd

順序があり後の読込でオーバーライド

Terraformのベストなプラクティスってなんだろうか | フューチャー技術ブログ (future-architect.github.io)
Workspace派、module派、ディレクトリ分離派

↓

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でデプロイするリソースを特定できる

Syntax - Configuration Language - Terraform by HashiCorp　コメントは#が基本、//や/**/も使える
Terraform v0.12で変わるHCLの記述について - Qiita　localsや変数、リストやマップ等
Terraform職人再入門2020 - Qiita　yamldecodeやjsonencode等
Terraformの基本 - Foreverly (hatenablog.com)

変数

　variable(input var)はcmd実行時に変数を上書きできるが、localsはできない

　outputはapply時にterminalで値が確認できる、moduleから値を取得する

google_bigquery_connection | Resources | hashicorp/google | Terraform Registry
ドット繋ぎで値を扱える

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

Terraformのfor_eachにmapのlistを渡してループしたい - Qiita

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で行い

権限定義、AuthorizedView定義、Routines定義は行わない

　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のcount
数を指定してその個数のリソースを作る。なのだが

　enable_lien = true　モジュール側/変数側でこう設定し

　count = var.enable_lien ? 1 : 0　リソース側で3項演算子を使えばIFのように使える
　　※for loopのようなインクリのcount"+="でなく"="の1発実行なので3項演算子でIFになる

■エラー
bigquery access denied：

gcloud auth login --enable-gdrive-access

gcloud auth application-default login --scopes="https://www.googleapis.com/auth/drive","https://www.googleapis.com/auth/cloud-platform"

BigQueryでGoogleドライブデータへのクエリでエラーが出るときの対処 (zenn.dev)

排他処理でロックが残る：

他の作業者がいなければ、terraform apply -lock=false で一時的に無視をして続行
エラーIDに対して terraform force-unlock id_num963103164

Terraform で state のロックを解除する方法、ロックを手動で行う方法 | ゲンゾウ用ポストイット (genzouw.com)
TerraformでState Lockエラーが発生したら | DevelopersIO (classmethod.jp)

■tfenvを使う場合

cd my-repo

get clone https://bitbucket/bangboo-prj.git

cd bangboo-prj

tfenv use 0.14.7

　terraform workspace list

　terraform workspace select default　デフォルト

　　terraform workspace new prod　prodという名で作成なら

main.tf作成し記載

　terraform fmt　tfファイルのフォーマット（書式は適当で書けばいい）

　　gcloud auth list　認証確認

　　gcloud auth application-default login　クレデンシャルが必要なら

　　　API&Servicesでクレデンシャルは取得できそう、key=xxxx

terraform init

既存のリソースを調査

terrafrom import google_storage_bucket.pri-bucket project-abc123/asia-northeast1/pri-bucket　でimportとか

　terraform refresh　tfstateの最新化、どのタイミングで使う？

■既存のリソースを調査

Terraform と gcloud CLI を使用した完璧な Google Cloud インフラストラクチャの構築 | Google Cloud Blog
gcloud beta resource-config bulk-export --help
gcloud beta resource-config bulk-export --project=kuso12345 --resource-format=terraform --path=/path/to/dir/
　対応を見ると数が少ないgcloud beta resource-config list-resource-types --format=json --project=kuso12345

terraformer import google list --projects=xxxx-123　で対象のリソース確認

terraformer import google --resources=instances,forwardingRules --regions=us-west1 --projects=xxxx-123　とか

既存リソースimport

https://www.apps-gcp.com/terraformit-gcp/

https://qiita.com/uu4k/items/48d3ecfefe57dba1d7e1

■Terraform applyで意図しない権限削除で障害が発生する
Terraform x GCP で、IAM権限を全削除してしまった - Qiita

resource "google_project_iam_policy" "unko" {

project = "my-project"

role = "roles/noguso"

members = [

"serviceAccount:${google_service_account.baka.email}"

]

}

google_project_iam_policy：書き換えるので他は無くなる（他を消したいときに使う）

google_project_iam_binding：付与、Authritativeだが他は現状維持？
google_project_iam_member：付与、Non-authoritativeで安全、まとめ難いか

　※_iam_policyと_iam_bindingとt_iam_memberは一緒に使えない

　※_iam_bindingと_iam_memberは一緒に使える

google_bigquery_dataset_iam_binding：（承認済みビューの権限はなくなる＞google_bigquery_dataset_accessを使え）

google_bigquery_dataset_iam_member：roleとmemberを1対1でresourceを作りまくる、Non-authoritative
　※_iam_policyや_bindingはまとめ易そうだが権限消しそう

google_bigquery_dataset_iam_memberでもAuthorized viewをはがしてしまう。

Authorized viewを使っている個所は google_bigquery_dataset_access あるいは google_bigquery_dataset の access フィールドを使う。

Terraform で GCP のサービスアカウントを管理する - Eng (なりたい) (hatenablog.com)
Terraform で GCP IAM 設定どれ使うのがいいのか - pokutuna (scrapbox.io)
google_project_iam | Resources | hashicorp/google | Terraform Registry
Authoritative: TFに明示していないものをApply時に削除しますという意、TFの権威
Non-authoritative: TFは権威を示さず、TFに明示していないものは現状維持ですという意

■勝手に公開
terraform vpc auto_create_subnetworks = falseにせなサブネットを公開して作りよる

■Applyの依存関係はdepends_on(プロジェクト作成の前に権限を付与しようとしてエラー等の順序)
[Terraform]Module間の値の受け渡しについて | DevelopersIO (classmethod.jp)
　これより先にあれをTFしてくれという記述

■データセット
google_bigquery_dataset | Resources | hashicorp/google | Terraform Registry
スキーマ取得: bq show --schema --format=prettyjson bangboo-prj:test-dataset.tbl001
ビューはコンソール＞BQ＞該当ビュー＞detailからコピー

■組織ポリシー
google_organization_policy | Resources | hashicorp/google | Terraform Registry
制約について | Resource Manager のドキュメント | Google Cloud

■parallelismで早くなるかもしれない
あなたのterraform planを手軽に高速化する（かもしれない）魔法の言葉 - Qiita

シェル変数を設定、確認cmdは printenv

export TF_CLI_ARGS_plan="--parallelism=50"

export TF_CLI_ARGS_apply="$TF_CLI_ARGS_plan"

■テスト
TF Apply後には検証をしっかりしたい、最低Apply後にPlanを再実行したい、テストスクリプト的にチェックしたい
適応されていないことや、TF定義とtfstateと実設定の差分が想定と違うことがある感じがするからだ
moduleを含めて条件的な書き方だと、適応の順序の関係で適応が抜け2回以上TF applyしないといけなかったり

■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　クレデン発行

　export GOOGLE_CLOUD_KEYFILE_JSON=path_to/account.json　クレデン設定
↑サービスアカウントで認証　環境変数にファイルパスを渡す
　gcloud auth application-default login　だと個人

　これにクレデンシャルファイルのパスを渡すとサービスアカウントでgcloudコマンド打てるはず

Terraformで複数リージョンをまたいだリソース制御する (mosuke.tech)
Terraform workspaceを利用して環境毎のリソース名の変更を行う (mosuke.tech)

End

Posted by funa : 10:14 PM | Web | Comment (0) | Trackback (0)

April 2, 2021

Linux cmd

■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モード:祖先のラインエディタ）

　┗入力モード
　https://docs.oracle.com/cd/E19253-01/816-3946/editorvi-5/index.html
　viのコロンモードコロンモードのコマンドは、このw、q、q!、x、$5... - Yahoo!知恵袋

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!

コマンド集　viコマンド集 (ritsumei.ac.jp)

カーソル移動　viでのカーソル移動方法を一通りまとめました (eng-entrance.com)

検索　【初心者向け】viでの文字列の検索方法を一通り (eng-entrance.com)

＝＝＝＝＝＝＝＝＝＝＝＝＝
■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)

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)

March 9, 2021

Treachery

:||

2021/4/25に気づいた、ハニーちゃんおめでとうとありがとう、エピソードは今度どこかで

Posted by funa : 11:39 PM | Column | Comment (0) | Trackback (0)

Navi: < 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 >

@funa1000 からのツイート

For mobile click here
For smart phone click here

#1	Web
#2	Hiace 200
#3	Gadget
#4	The beginning of CSSレイアウト
#5	Column
#6	Web font test
#7	Ora Ora Ora Ora Ora
#8	Wifi cam
#9	みたらし団子
#10	Arcade Controller
#11	G Suite
#12	PC SPEC 2012.8
#13	Javascript
#14	REMIX DTM DAW - Acid
#15	RSS Radio
#16	Optimost
#17	通話SIM
#18	Attachment
#19	Summer time blues
#20	Enigma
#21	Git
#22	Warning!! Page Expired.
#23	Speaker
#24	Darwinian Theory Of Evolution
#25	AV首相
#26	htaccess mod_rewite
#27	/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28	竹書房
#29	F☆ck CSS
#30	Automobile Inspection
#31	No ID
#32	Win7 / Win10 Insco
#33	Speaker
#34	Arcade Controller
#35	Agile
#36	G Suite
#37	Personal Information Privacy Act
#38	Europe
#39	Warning!! Page Expired.
#40	GoogleMap Moblile
#41	CSS Selectors
#42	MySQL　DB　Database
#43	Ant
#44	☆od damnit
#45	Teeth Teeth
#46	Itinerary with a eurail pass
#47	PHP Developer
#48	Affiliate
#49	/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50	/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51	/// BANGBOO BLOG /// On 2020-03-01
#52	/// BANGBOO BLOG /// On 2020-04-01
#53	Windows env tips
#54	恐慌からの脱出方法
#55	MARUTAI
#56	A Rainbow Between Clouds‏
#57	ER
#58	PDF in cellphone with microSD
#59	DJ
#60	ICOCA
#61	Departures
#62	Update your home page
#63	CSS Grid
#64	恐慌からの脱出方法
#65	ハチロクカフェ
#66	/// BANGBOO BLOG /// On 2016-03-31
#67	/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68	/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69	/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70	/// BANGBOO BLOG /// On 2020-01-21
#71	Bike
#72	Where Hiphop lives!!
#73	The team that always wins
#74	Tora Tora Tora
#75	Blog Ping
#76	無料ストレージ
#77	jQuery - write less, do more.
#78	Adobe Premire6.0 (Guru R.I.P.)
#79	PC SPEC 2007.7
#80	Google Sitemap
#81	Information privacy & antispam law
#82	Wifi security camera with solar panel & small battery
#83	Hope get back to normal
#84	Vice versa
#85	ハイエースのメンテ
#86	Camoufla
#87	α7Ⅱ
#88	Jack up Hiace
#89	Fucking tire
#90	Big D
#91	4 Pole Plug
#92	5-year-old shit
#93	Emancipation Proclamation
#94	Windows env tips
#95	Meritocracy
#96	Focus zone
#97	Raspberry Pi
#98	Mind Control
#99	Interview
#100	Branding Excellent

Column [124]
Europe [9]
Gadget [74]
Web [120]
Bike [3]

GMT(Greenwich Mean Time) on Mar 15
HSTS/CORS/CSPOAuth/OpenID/SAML/XSS/CSRF/JSOP/SSO/SSL on Feb 11
竹書房 plotted on Jan 22
Overtone on Sep 02
Docker on Jul 24

< March 2023 >
Sun	Mon	Tue	Wed	Thi	Fri	Sat
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31