ステージングと本番

ステージングと本番を 1 つの設定で動かします。リソースと読み手は同じで、プロジェクトは別、読むのも別のサービスアカウントです。環境ごとのファイルには違うところだけを書くので、ステージングに足したリソースを本番で忘れることがなく、本番の違いは 1 つのファイルを見れば分かります。

すべてのキーの説明は設定のリファレンスにあります。

1. 設定を分ける

今あるファイルから始めます（今の形のもの。古い形なら、先に migrate してください）。両方の環境で共通のものは tegata.yaml に残し、違うものを環境ごとのファイルに移します。

tegata.yaml           stores (without the project), identities (with []), providers, resources, environments
envs/staging.yaml     the project, the members, provider and resource settings that differ
envs/production.yaml  the same for production, and confirm: true
tegata.lock           shared: every environment uses the same providers

tegata.yaml

stores:
  main:
    gcp: { location: asia-northeast1 }
identities:
  app: []
environments:
  staging: envs/staging.yaml
  production: envs/production.yaml
resources:
  session_key:
    provider: random
    stores:
      main:
        - { name: SESSION_KEY, readers: [app] }

envs/production.yaml

confirm: true
stores: { main: { gcp: { project: myapp-prod } } }
identities: { app: [serviceAccount:app@myapp-prod.iam.gserviceaccount.com] }

ふつう違うもの：プロジェクト、サービスアカウント、ほかのサービスの上の名前（Cloudflare のトークンの名前、Cloud SQL のインスタンス、Tunnel）、Terraform のディレクトリ（パスは tegata.yaml からの相対のまま）、届け先。違うべきでなく、違えることもできないもの：どのリソースがあるか、誰が何を読むか。

2. 何も変わらないことを確かめる

apply する前に、各環境を、置き換えるもとのファイルと比べます。tegata env は、環境の、まとめたあとの設定を出します。

tegata env staging > /tmp/staging.yaml
tegata -f staging.old.yaml migrate > /tmp/staging.old.yaml   # the old file, in the same normalized form
tegata -f /tmp/staging.yaml migrate | diff /tmp/staging.old.yaml -
tegata check                          # every environment, and that they share no project or member
tegata -e staging apply --dry-run     # nothing to make

各環境の最初の apply で、そのシークレットに tegata-env=<name> のラベルが付きます。ほかは何も変わりません。

3. 一度に 1 つの環境で作業する

tegata -e staging rotate session_key
export TEGATA_ENV=staging             # or for a whole shell
tegata status

本番は confirm: true なので、何かを変える前に聞きます。

$ tegata -e production rotate session_key
production: make a new generation of session_key
Type the environment name to continue: production

CI では --yes を渡し、代わりにジョブを守ってください。たとえば、レビューの要る GitHub の環境を使います。

4. 本番の認証情報を、ステージングのシェルに置かない

プロバイダーの認証情報は、環境ごとに別の環境変数から取れます。

envs/production.yaml

providers:
  cloudflare:
    credentials:
      api_token: { env: TEGATA_CLOUDFLARE_TOKEN_PROD }

こうすれば、ステージングのために export したトークンを、うっかり本番で使うことがありません。