URLの一部となるようなリソース名にはバージョン番号を付与する方針にしたというお話。
IaCでスクラップ＆ビルドを実施する時に考慮が必要。
例えば、KeyVaultのリソース名はURLの一部になるため、グローバルで一意な名前になっている必要がある。
このような制約のあるリソースの場合、一度生成するとそのリソース名はグローバルからアクセス可能なURLの一部としてDNSに登録されるので、仮にリソースを削除してもすぐには同じ名前のリソースを再作成できないし、IaCなどで自動的にリソースをスクラップ＆ビルドすることはできない。
DNSキャッシュの影響を避けるために同名リソースを作成しようとすると数日間はエラーとなる。
これの対策として、今回はバージョン番号を明示的に設定することでこれに対応した。
1. 一意性を持たせるための命名規則のオプション
1-1. タイムスタンプ
utcNow()関数を用いて、yyyyMMddHHmmssなどのフォーマットで生成した文字列をリソース名に付与する。
Bicepテンプレートでデプロイを実行すると、毎回utcNowで実行時の日時が取得されるため、毎回異なるリソース名になる。
IaCを実行する上で、毎回スクラップ＆ビルドするのであれば問題無いが、既存リソースに対する更新を行いたい場合でも毎回異なった名前のリソースが作成されるので、これはNGとした。
1-2. ユニーク値
uniqueString()関数を用いて、例えばResourceGroup.idを元に生成したランダムな文字列をリソース名に付与する。
この方法も毎回異なるリソース名になり、タイムスタンプと同様、既存リソースに対する更新を行いたい場合でも毎回異なる名前のリソースが作成されるので、これもNGとした。
1-3. バージョン
Bicepテンプレート内に、パラメータとしてバージョン情報を指定する。たとえば、”001”など。
明示的に自分でバージョン情報を変更しない限り、同じリソース名でデプロイ処理が実行されるので、リソースが無ければ新規に作成され、既存の場合は更新処理が実行される。
これはOKなので、今後はこの方式で名前を生成する。
1-4. リソース名の文字数の制約
タイムスタンプやユニーク値を用いたリソース名のもう一つの留意すべきことは、リソース名が長くなるため、リソース名の文字数制約に抵触する可能性が高くなる。
リソース名に以下のような要素が複数含まれる場合は要注意
- システム名やアプリケーション名
- リージョン
- リソースタイプ
- 環境名
各リソース名に関する制約は以下に定義されている。
以下、MSがリソース名に対するガイドを出しているが、なにも考えずに単純にこれをマルっと踏襲していると、後で文字数超過することになるので工夫が必要。
以下、リソースタイプについてのガイドがある。これは有用なので、今後はできるだけ踏襲するようにする。