Azureリソースの名前付けルールについて

はじめに

Azureリソース(仮想マシンだったり、SQL DBだったり、リソースグループだったり)の名称を決めるのって、皆さんどうしていますか?

個人的な検証だったり、ワンショットで利用する環境であれば基本的に好きに付ければ良いと思いますが、チームで作業したりお客に納品する環境であれば、それなりに明確なルールを基に命名するのが良いですね。

リソース名とリソースID

Azureの各リソースは基本的にはリネームできません。

一度リソースを作成すると、個々のリソースには「リソースID」がAzure内でグローバルに一意となる文字列が確定します。

リソースIDは以下のルールで「/」区切りで決定します。

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}
subscriptions固定
{subscriptionId}AzureサブスクリプションID(GUID 形式)
resourceGroups固定
{resourceGroupName}リソースグループ名
providers固定
{resourceProviderNamespace}リソース プロバイダー名
{resourceType}リソース プロバイダーの名前空間を含むリソースの種類
{resourceName}リソース名

リソースプロバイダー名とリソースの種類の一覧は以下のサイトにあります。

Azure サービスのリソース プロバイダー

例えばサブスクリプションID「AAAAAAAA-BBBB-CCC-DDDD-EEEEEEEEEEEE」、リソースグループ「test-rg」にある仮想ネットワーク「test-vnet」を示すリソースIDは以下になります。

/subscriptions/AAAAAAAA-BBBB-CCC-DDDD-EEEEEEEEEEEE/resourceGroups/test-rg/providers/Microsoft.Network/virtualNetworks/test-vnet

この仮想ネットワーク内の更にサブネット「default」に対するリソースIDは「/subnets/default」が追加されて以下になります。

/subscriptions/AAAAAAAA-BBBB-CCC-DDDD-EEEEEEEEEEEE/resourceGroups/test-rg/providers/Microsoft.Network/virtualNetworks/test-vnet/subnets/default

このリソースIDは他のリソース内のプロパティ値としても利用されているため、容易に変更ができません。
(リソース名を変更して、リソースIDが変わるとそのIDに紐付いているすべてのリソースに影響がでるため)

無論、Microsoftもこの件については色々と考えており、リソースを別のサブスクリプションやリソースグループに移動するための方法を案内しています。

リソースを新しいリソース グループまたはサブスクリプションに移動する

今回はリソース移動やリソースIDの詳細についての記事ではないため、これ以上の事は別の機会に説明しようと思いますが、

Azureリソース名はちゃんと決めたほうが良い

ということがわかって頂けたかと思います。

リソース名の命名に関する制限事項(一部)

先のリソースIDがかぶらなければ、比較的自由な名前がつけられます。なんと、リソース名には日本語も指定可能です。

  • サブスクリプションIDが異なっていれば同名がつけられる
  • リソースグループが異なっていれば同名がつけられる
  • リソースプロバイダ(リソースの種類)が異なっていれば同名がつけられる

ということです。

同じリソースグループ内に、「hogehoe」という仮想ネットワークとNSG、Load Balancerが作れたりします。

最悪ですね。人にお見せできない以前に、自分でも間違って他のリソースを選んでしまったり、削除したりしてしまいそうです。

とまあ、基本的にはリソース名の命名はフリーダムなのですが、それでも一部のリソースはAzureグローバルでユニーク(重複しない)な名前をつける必要があるものもあります。

色々あって、全ては紹介出来ないのですが、例えばストレージアカウントがその代表例です。

以下のサイトにあるように、ストレージアカウント名は3~24文字で小文字と数字のみが使用可能で、スコープ(どの範囲でユニークにするか)は「グローバル」となっています。

Microsoft.Storage

設計段階(Azureにデプロイする前)に、「今回のプロジェクトは特別なサーバだからストレージアカウント名は special にしよう」といっても、その名前が実際に取得可能かはデプロイ時点でしかわかりません。

他のリソースにも命名に関する制限事項があったりするので、上記のURLから他の利用予定のリソース種類に関する命名則を事前に確認しておくと良いと思います。

じゃあ、どんな名前がいいのか?

個人的には、そのプロジェクトが個人利用、社内利用であれば、内部で合意が取れている名称で良いと思っています。

お客さんに納めるのであれば、お客さん側で既に利用しているAzureリソースの命名ルールに合わせればよいかと。

個人的には以下のルールをなんとなくですが決めてリソースを作成していました。

  • リソースグループ名
    恒久的なもの:projectname-rg
    一時的なもの:20210414-tmpname-rg
  • リソース名
    以下のサフィックスを追加
    仮想ネットワーク:-vnet
    ネットワークセキュリティグループ:-nsg
    ロードバランサ:-lb

仮想マシンが複数ある場合にはサフィックスに「01」「02」とか付ける感じ。

公式なベストプラクティスはないのか?

あります。実は数年前までは私が普段付与していた命名即に近いかたちで紹介されていたのですが、最近気づいたのですが2020/12に大幅に更新されていました。

名前付け規則を定義する

これによると、リソースグループは以下の形式になります。

rg-<app or service name>-<subscription type>-<###>

specialプロジェクトの開発環境であれば、「rg-special-dev-001」となります。

末尾の数字はAzureリソースを資産管理する場合に管理番号として「001」を付与しましょうということですが、必須ではなく別に「rg-special-dev」でも良さそうです。(もともと「こうしなさい」という資料ではないですが)

仮想ネットワークと中のサブネットは以下の形式になります。

vnet-<subscription type>-<region>-<###>
snet-<subscription>-<region>-<###>

東日本にある仮想ネットワークのサブネットをリソースIDで表現すると

/subscriptions/AAAAAAAA-BBBB-CCC-DDDD-EEEEEEEEEEEE/resourceGroups/rg-special-dev/providers/Microsoft.Network/virtualNetworks/vnet-dev-japaneast/subnets/snet-default-japaneast

になるのかな?と思います(サブネットにはリージョンは不要だと思いますが)

多分ですが、2020/12に公開されているこの命名則を使うと、環境ごと(開発環境、本番環境など)、リージョンごとに同じ用途のAzureリソースがあっても、名称が重複せずに視覚的にも簡易に識別できる利点があると思われます。

このすべてを合わせる必要はないと思いますが、以下の省略形のプレフィックス一覧は良いと思うので、私もこれからは合わせていこうかなと思います(サフィックスとして使うかもしれませんが)

Azure リソースの種類に推奨される省略形

おわりに

最近Azureドキュメントのアップデートで気づいたこととして本記事をエントリしました。

命名に悩んだ場合の参考になればと思います。