[Azure] はじめてのAzureで躓いたところ
はじめまして
どうも、Markです。
ITエンジニア1年目で、DevOps関連の技術を中心に学習中です。
Azureは投稿日の前日に初めて触りました。クラウドは、AWSしか触ったことがないのですが、Azureの案件に空きがあるから入らないかと勧誘を受けたので、キャッチアップの為に始めました。
とりあえず、習うより慣れろ精神で、Udemyのハンズオンを見ながら進めていました。
Udemy受講中に躓いた
Udemyの講座はこちらです。
こちらの講座は
Azure × Terraform × GithubActions
というCI/CD中心の構成でDevOpsエンジニアを目指す私にぴったりだったので選びました。
わからないこと所は、Microsoft公式のトレーニングをかいつまみながら進めていました。
その中で躓いた箇所をいかにまとめていきます。
1. プロバイダー?なにそれ...
最初の躓きはプロバイダーです。
Azure Container Registryをデプロイするために、terraform applyをした際に以下のようなエラーが出ました。
│ Error: creating Registry (Subscription: "xxxxxxxxxxxx"
│ Resource Group Name: "xxxxxxxxxxxx-rg"
│ Registry Name: "xxxxxxxxxxxxacr"): performing Create: unexpected status 409 (409 Conflict) with error: MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.ContainerRegistry'. See https://aka.ms/rps-not-found for how to register subscriptions.
│
│ with azurerm_container_registry.acr,
│ on acr.tf line 1, in resource "azurerm_container_registry" "acr":
│ 1: resource "azurerm_container_registry" "acr" {
│
サブスクリプションは名前空間 'Microsoft.ContainerRegistry' を使用するように登録されていません。
google 翻訳
Microsoft.ContainerRegistry ? なんじゃそれ
調べてみると公式に以下のように書かれていました。
Azure リソース プロバイダーは、特定の Azure サービスの機能をサポートする REST 操作のセットです。 たとえば、Azure Key Vault サービスは、Microsoft.KeyVault という名前のリソース プロバイダーで構成されます。 リソース プロバイダーでは、コンテナー、シークレット、キー、証明書を操作するための REST 操作が定義されます。
リソース プロバイダーでは、アカウントにデプロイできる Azure リソースが定義されます。 リソースの種類を表す名前は、{resource-provider}/{resource-type} のような形式になります。 キー コンテナーのリソースの種類は Microsoft.KeyVault/vaults です。
Microsoft公式 Azure リソース プロバイダーと種類
なるほど、REST APIによる操作はリソースプロバイダを経由して行われるから、サービスごとに登録しとけと言うことか。
ChatGPTによる要約を追記しときます。
Azure の REST API 操作はすべて Azure Resource Manager (ARM) を経由します。そして ARM は「どの操作をどのサービスにルーティングするか」を リソースプロバイダー を通じて判断します。
流れを簡単に書くと
-
クライアントが ARM に対して REST API リクエストを送る
例:PUT https://management.azure.com/subscriptions/{subId}/resourceGroups/myrg/providers/Microsoft.Storage/storageAccounts/mystorage?api-version=2023-01-01 -
ARM は URI の中の
providers/Microsoft.Storageを見て「このリクエストは Storage リソースプロバイダーに処理させる」と判断する。 -
リソースプロバイダーがそのリソースタイプ(例:
storageAccounts)に対応する操作(作成・更新など)を実行する。
補足
-
ARM =統一窓口
すべてのリソース管理リクエスト(作成、更新、削除、取得)は ARM を通る。 -
リソースプロバイダー = ARM の背後で実際に処理を担当するサービス
例:Microsoft.Computeは VM 作成や削除、Microsoft.Networkは VNet や NIC の操作。 -
ただし「サービスによっては管理面とデータプレーンが分かれる」ケースもある。
- 管理面(例: VM の作成/削除)は必ず ARM+リソースプロバイダー経由。
- データプレーン(例: 実際に VM に SSH 接続、Blob Storage へデータ PUT)はリソースプロバイダーを経由せず、そのサービスエンドポイントに直接アクセス。
👉 まとめると:
リソースの作成・変更・削除などの管理操作はすべて ARM 経由でリソースプロバイダーが担当します。ただし、利用者が直接サービスを使うデータ操作(例: Blob のアップロード)は対象サービスのエンドポイントに直接アクセスする仕組みです。
Azure CLIでリソースプロバイダを登録をして、起き上がる(解決する)ことができました。
# リソースプロバイダの登録
# サブスクリプションを明示(必要なら)
az account set --subscription "<SUBSCRIPTION_ID>"
# ACR の RP を登録
az provider register --namespace Microsoft.ContainerRegistry
# 登録状態を確認(Registered になればOK)
az provider show --namespace Microsoft.ContainerRegistry --query registrationState -o tsv
2. クオータ制限???
次の躓きは、クオータ制限です。
AWSを使用している中では出なかった概念で、そんなものがあるのかと驚きました。
Azure App Service Planをデプロイした際に出ました。
Error: creating App Service Plan (Subscription: "xxxxxxxxxxxx" │ Resource Group Name: "xxxxxxxxxxxx-rg" │ Server Farm Name: "xxxxxxxxxxxx-asp"): performing CreateOrUpdate: unexpected status 401 (401 Unauthorized) with response: {"Code":"Unauthorized","Message":"Operation cannot be completed without additional quota. \r\nAdditional
.....略
"メッセージ": "追加のクォータがないと操作を完了できません。
google 翻訳
クオータとはなんぞや。
多くの Azure サービスにはクォータがあり、これは Azure サブスクリプションに割り当てられたリソースの数です。 各クォータは、作成できる仮想マシンの数、同時に使用できるストレージ アカウントの数、使用できるネットワーク リソースの数、特定のサービスに対する API 呼び出しの数など、特定のカウント可能なリソースを表します。
クォータの概念は、不正確なリソース デプロイや誤った消費から顧客を保護するために設計されています。 Azure では、詐欺的または不適切な消費や予期しない需要によるリスクを最小限に抑えることができます。 クォータは、サブスクリプションのスコープで設定され、適用されます。
クォータの概要
フーンなるほど、サブスクリプションごとの利用制限か。
で、何のクォータが足りなかったかというと、App Service Planの実行基盤で指定したSKU(B1)でした。
ChatGPTに聞くと、クオータを確認してくださいと言われ、CLIで以下のコマンドを打って確認したところ、確かに0でした。
SUB="<SUBSCRIPTION_ID>"
REGION="japaneast"
az rest \
--method get \
--url "https://management.azure.com/subscriptions/$SUB/providers/Microsoft.Web/locations/$REGION/usages?api-version=2024-11-01" \
--query "value[].{name:name.localizedValue, current:currentValue, limit:limit, unit:unit}" \
-o table
そこで、リージョンをeastasiaにして再度確認すると、B1のクォータ制限が40となっていたので、Japn EastからEast Asiaに変更してエラーは解消されました。
おわりに
AzureはAWSより複雑ですが、嫌いではないですねー。
Discussion