HCP Terraform の workspace を GitHub のリポジトリにつなぎ、VCS-driven workflow にする。PR を出すと plan だけの run が始まって結果が PR に表示され、main にマージすると run が始まって auto-apply で apply まで進む。つないだあとはローカルの terraform apply が断られることも確かめる。
HCP Terraform の workspace に置いていた AWS のアクセスキーを消し、Dynamic provider credentials に置き換える。AWS の IAM に ID プロバイダーとロールを作り、workspace に環境変数を 2 つ置くと、run のたびに一時的な認証情報が発行される。plan と apply で、run が誰として AWS を操作するかが IAM ユーザーからロールに変わるところまで確かめる。
HCP Terraform の workspace の変数に AWS のアクセスキーを sensitive な Environment variable として置き、Terraform variable でバケット名とタグを渡して S3 バケットを作る。run の中で 2 種類の変数がどう使われるかを、plan のエラーと成功、画面で値を変えた run で確かめる。
ローカルの terraform コマンドから HCP Terraform の workspace を作り、plan と apply を run として実行する。run がどこで動き、承認待ちでどう止まり、state がどこに残るかを、ターミナルの出力と画面で確かめる。
HCP Terraform は、Terraform の plan と apply を HashiCorp のクラウドで実行し、state と認証情報もそこに置くサービス。HCP Terraform とは何か、何ができるか、どういう仕組みで動くかを、公式ドキュメントをもとに整理する。
Tilt で、Go で書いた API と一緒に PostgreSQL を kind のクラスタで動かす。resource_deps で DB の Pod が Ready になるのを待ってから初期データを入れ、そのあと API を起動する。初期データの投入は local_resource で行い、trigger mode を manual にして管理画面のボタンで入れ直す。tilt down で DB も含めて削除されることを確認する。
Tilt の Live Update を使い、Go で書いた API のソースの変更を、image を作り直さずに kind のクラスタで動いているコンテナへ反映する。ローカルの開発環境で go build した実行ファイルを sync でコンテナにコピーし、restart_process 拡張でプログラムを起動し直す。保存のあとも Pod の名前・RESTARTS・image のタグが変わらないことを確認する。
Tilt を使い、自作の API を kind のクラスタで動かす。Tiltfile に docker_build・k8s_yaml・k8s_resource の 3 行を書いて tilt up を実行し、ソースを 1 行変えて保存するだけで image の作成から Pod の入れ替えまでが自動で行われることを確認する。開発用と判定できないクラスタでは Tilt が止まることも、kubeconfig の名前だけを変えて確かめる。
Tilt は、ローカルの開発環境で動き、アプリのソースを保存するたびに image の作成・Kubernetes への反映・port-forward を自動でやり直すツール。Tilt とは何か、何ができるか、どういう仕組みで動くかを、公式ドキュメントをもとに整理する。
同じアプリを dev と prod の 2 つの環境に入れる。Kustomize の base と overlay で共通の YAML と環境ごとの差分を分け、Argo CD の Application を環境ごとに作る。sops で暗号化した Secret を Kustomize と同じディレクトリに置けない理由と、その回避のしかたも整理する。