デモのデプロイ

前提条件

Terraform は terraform/versions.tf に記載されたバージョン下限 — >= 1.8 — 以上。プロバイダー定義関数と、VIP を保護する check ブロックのために必要です。
xcsh プロバイダー。 バージョンは一切固定されていません。.terraform.lock.hcl は gitignore されており、制約は上限のない下限のみであるため、init のたびに最新の公開リリースが解決されます。これはプレリリースのプロジェクトとして意図的なものです。デモは、プロバイダーのリグレッションを隠す古いバージョンに留まるのではなく、そのリグレッションで失敗すべきです。
var.expected_xc_tenant のテナント向けの F5 XC API 資格情報。XCSH_API_TOKEN としてエクスポートします（または P12/PEM のペア）。エクスポートするのは資格情報のみで、 URL は決してエクスポートしないでください — 下記を参照。
リソースグループ、VNet、Route Server、VM を作成する権限を持つ Azure 資格情報。
アプリ層向けの 既存の F5 XC 名前空間。デプロイはそれを読み取るだけで、作成も破棄もしないため、無関係なデモを保持している名前空間がこのスタックの destroy 対象リストに含まれることはありません。

~/.terraformrc に xcsh 向けの dev_overrides ブロックが含まれている場合、ローカルのすべての Terraform コマンドはそのディレクトリのバイナリを使用し、バージョン制約とロックファイルの両方を無視します。数日前のビルドであっても、公開されているプロバイダーに対してはまったく有効な構成に対して Blocks of type "…" are not expected here で失敗するのに十分です。

デフォルトのパスからは外し、プロバイダーを開発しているときにのみ明示的に有効化してください。

mv ~/.terraformrc ~/.terraformrc.provider-dev
TF_CLI_CONFIG_FILE=~/.terraformrc.provider-dev terraform plan   # when you mean it

デフォルト値のない 2 つの値を指定する

その他のすべての変数には動作するデフォルト値があり、すべてのオブジェクト名は var.component から導出されます。2 つだけが意図的にデフォルトなしとされています。

cd terraform
cp terraform.tfvars.example terraform.tfvars

変数	デフォルトがない理由
`origin_ip`	どんなデフォルトも特定の 1 台のマシンを指します。古い値は、失敗する代わりに新しいデプロイのトラフィックを他人のホストへ送ってしまいます。
`lb_domain`	ロードバランサーは `Host` でマッチするため、これはすべてのリクエストが送信しなければならない値です。デプロイを実行する人に属する値です。

どちらも形式が検証されるため、タイプミスはデモではなくプランの段階で失敗します。

terraform.tfvars は gitignore されており、その状態を維持しなければなりません。サブスクリプション ID とエンジニアごとの値を含んでいるためです。

テナントは構成であり、シェルがエクスポートしている値ではありません

var.expected_xc_tenant がテナントを指定し、テナントが指定される場所はここだけです。 providers.tf はこれから xcsh プロバイダーの api_url を導出し、環境の XCSH_API_URL を意図的に上書きします。また terraform/main.tf の postcondition は、環境が別のテナントを指定している場合に plan を失敗させます。

状態を変更するものを実行せずに、どちらの値も読み取れます。

terraform output -raw xc_tenant       # what the deployment targets
terraform output -raw xc_env_tenant   # what your shell claims — diagnostic only

f5-sales-demo
f5-sales-demo

デモは 1 つのテナントで構築されました。その後、資格情報ファイルが別のテナントの XCSH_API_URL をエクスポートし始め、以降の apply がそのテナント向けのトークンを発行し、 CE VM がそちらに再登録され、元の登録は放棄されました。その間のすべてのプランはクリーンでした。構成のどこにもテナントについての意見がなかったからです（issue 696、 PR 697 で修正）。復旧には、誤ったテナントのスタックを破棄し、正しいテナントで再構築する必要がありました。

認識すべき症状は、それ自体では説明的でないため注意が必要です。別のテナント向けに発行されたトークンは、固定されたエンドポイントに対して素の 401 で失敗し、これは期限切れの資格情報とまったく同じように見えます。問題ないと思っている資格情報が 401 を返す場合は、別のトークンを発行する前に上記 2 つの出力を比較してください。

Apply

初期化します。 バックエンド構成はコミットされていません。自身のものを指定してください。
Terminal window
```
terraform init -backend-config=backend.hcl
```
最初の apply。 これにより Azure、CE サイト、登録トークンが構築され、CE が起動します。
Terminal window
```
terraform apply
```
CE が登録された後に再度 apply します。 これは省略できません。その理由は、自分で発見するものではなく以下に記載してあります。
Terminal window
```
terraform apply
```

その後、誰かに見せる前に正常性を証明するに進んでください。

登録承認は自動化されていますが、apply は依然として 2 段階です

登録承認にコンソールでの人手は不要になりました。xcsh_registration_approval リソースがそれを実行し、サイトモジュールがどの登録を承認するかを解決します。

それでもデプロイが一度の手放し apply になるわけではなく、その理由は、最初の実行を見て失敗したと結論づける前に理解しておく価値があります。

CE の登録オブジェクトの名前は r-<uuid> です。サイト名に由来する名前が付くことは決してないため、プラン時点で名前を予測できるものはありません。
登録は、VM が起動して vpm が登録を行った後にのみ存在します。
したがって 最初の apply では承認がまったく計画されません。CE が登録された後に再度 apply すると、承認が作成されます。

terraform/main.tf はこの順序をファイル冒頭に記載しており、それが正式版です。デプロイ手順は、それを実装するコードと共に存在します。

オペレーター SSH は構築時の決定事項です

デプロイは、ログインシェルが Site CLI であるアプライアンスの admin アカウントにオペレーターキーを書き込みます。これは cloud-init の write_files によって書き込まれ、初回起動時に一度だけ実行されます。

custom_data は置き換え専用であるため、稼働中の CE でこれを採用すると すべての CE VM が置き換えられます。これは構成変更ではなく、フリート全体の再構築です。 cloud-init テンプレート内の他のあらゆる変更についても同じことが言えます — コメントの追加でさえ同様です。custom_data はレンダリングされたファイルの base64encode だからです。

かつてはもっと悪い状況でした。置き換えられた CE は決して再登録できませんでした。破棄されたノードの登録が、コントロールプレーンの一意な (tenant, cluster_name, hostname) インデックスを保持し続けていたためです — そしてフリートがダウンしている間、terraform plan はずっと「No changes」と報告していました。復旧には 2 回の完全な再構築が必要でした。これは修正済みです（issue 674、 PR 693 でクローズ）。サイトオブジェクトのライフサイクルは CE VM インスタンスに結び付けられたため、VM を置き換えるとサイトも置き換えられ、サイトの削除は、置き換えノードが起動する前にその登録も一緒に削除します。

これを他の場所で採用する場合は、まず SSH のページを読んでください。

破棄する

terraform destroy

アプリの名前空間は残ります。読み取られるだけで管理されないため、destroy が無関係なデモを保持している名前空間を一緒に削除することはできません。リソースグループ内のそれ以外のすべては削除されます。