Posts

エラーの概要 Azure 409 Conflict エラーは、リソースの現在の状態と API リクエストが競合している場合に発生します。通常、同じ名前のリソースが既に存在する、リソースがプロビジョニング途中である、または削除処理中の状態で新しい操作を実行しようとしたときに返されます。このエラーは Azure Portal、Azure CLI、Azure PowerShell、REST API など複数のインターフェースで発生する可能性があります。 実際のエラーメッセージ例 Azure REST API レスポンス： { "error": { "code": "Conflict", "message": "The resource 'myStorageAccount' already exists in the resource group 'myResourceGroup'.", "status": "409" } } Azure CLI の出力： (Conflict) The storage account myStorageAccount already exists. Code: Conflict Message: The storage account myStorageAccount already exists. よくある原因と解決手順 原因1：同じ名前のリソースが既に存在する 同じ名前のリソース（ストレージアカウント、App Service、Cosmos DB など）が既に同じリソースグループ内に存在すると、新規作成時に 409 Conflict が発生します。Azure の多くのリソースはグローバルに一意な名前を要求するため、他のリソースグループや他のサブスクリプションの同名リソースも競合の原因となります。 Before（エラーが起きるコード）： az storage account create \ --name myStorageAccount \ --resource-group myResourceGroup \ --location eastus After（修正後）： ...

エラーの概要 429 Too Many Requests エラーは、Azure API がスロットリング制限に達したことを示す HTTP ステータスコードです。Azure では、各サブスクリプションと API に対して一定期間内のリクエスト数に上限を設定しており、この制限を超えたときに発生します。特に、自動化スクリプトやバッチ処理でループ内から大量のリクエストを送信する場合に頻繁に見られます。 実際のエラーメッセージ例 Azure REST API の直接呼び出しで見られる典型的なレスポンス： { "error": { "code": "SubscriptionThrottled", "message": "The subscription is throttled for the following operation: Microsoft.Compute/virtualMachines/write. Please try after 30 seconds." } } Azure SDK（Python）で発生した場合のコンソール出力： azure.core.exceptions.HttpResponseError: (429) Throttling error. Subscription has exceeded throttling limits for operation 'Microsoft.Storage/storageAccounts/write'. Retry after 60 seconds. よくある原因と解決手順 原因1：リクエストレートが上限を超えている Azure には、API ごと・操作ごと（例：仮想マシン作成、ストレージ読み書き）に一定秒あたりのリクエスト数制限があります。制限値はサブスクリプション、リージョン、リソースの種類によって異なり、ループ内で連続して API を呼び出すと瞬時に制限に達します。 Before（エラーが起きるコード）： from azure.identity import DefaultAzureCredential from azure.mgmt.compute import ComputeManagementClient credential = DefaultAzureCredential() client = ComputeManagementClient(credential, "<subscription_id>") # 50 台の VM を一気に作成しようとする for i in range(50): client.virtual_machines.begin_create_or_update( "<resource_group>", f"vm-{i}", vm_config ) After（修正後）： ...

Docker Composeとは、複数のDockerコンテナーを定義・実行・管理するためのオーケストレーション（統合管理）ツールです。YAMLファイルで複数サービスの設定を一元管理し、単一コマンドで環境全体を起動できます。開発環境から本番環境まで、コンテナーベースのアプリケーション構築を効率化します。 主な特徴・できること YAML形式での設定管理：docker-compose.ymlファイルに全サービスの定義を記載でき、バージョン管理が容易 マルチコンテナーの一括起動：docker compose upコマンド一つで複数コンテナーを同時に立ち上げ ネットワーク自動構築：サービス間の通信を自動設定し、コンテナー間でホスト名解決が可能 ボリューム管理：データの永続化やホストマシンとのファイル共有を簡単に設定 環境変数の管理：.envファイル等での変数定義により、環境ごとの設定切り替えが効率的 スケーリング機能：docker compose up --scale service=<数>コマンドで特定サービスのレプリケーション数を変更可能 ローカル開発環境の再現性：同じ設定ファイルで全開発者が統一環境を構築できる 料金プラン Docker Composeはオープンソースソフトウェアであり、完全無料で利用できます。商用・非商用を問わず制限なく使用可能です。 似たツールとの比較 ツール 用途 スケーラビリティ 学習曲線 本番運用 Docker Compose ローカル・小規模環境 低い 低い 非推奨 Kubernetes エンタープライズ規模 高い 高い 推奨 Docker Swarm 中規模分散環境 中程度 低い 対応可能 Nomad マルチクラウド運用 高い 中程度 対応可能 Docker Composeはシンプルさと学習コストの低さで優位ですが、本番運用やクラウドスケーリングが必要な場合はKubernetesの検討が必要になります。 こんな人・チームに向いている 開発エンジニア：ローカルマシンで複数サービスを同時に実行したい場合 スタートアップ・小規模チーム：導入コストを最小化し、素早く開発環境を構築したい QA・テストエンジニア：再現性の高いテスト環境を短時間で構築したい DevOpsエンジニア：CI/CDパイプライン（継続的インテグレーション・デリバリー）におけるローカル環境の統一化を推進したい マイクロサービス学習者：複数コンテナーの連携を学習したい初心者 Docker Composeの実務的な利点 Docker Composeは開発プロセスにおけるエラー原因の特定を効率化します。docker compose logsコマンドで全サービスのログを一元表示できるため、エラーの原因追跡が容易になり、デバッグ時間を大幅に削減できます。 同一の設定ファイルを共有することで、「この環境ではうまくいくが、別の環境では動作しない」といった環境依存のバグを防止できます。チーム開発では、全員が同一設定で作業でき、メンバー間の環境差分によるトラブルを排除できます。

エラーの概要 Azure への API リクエストやコマンド実行時に 401 Unauthorized エラーが返される場合、認証情報が無効であるか期限切れになっていることを示しています。このエラーが発生すると、Azure リソースへのアクセスが完全にブロックされ、デプロイやリソース管理の操作が実行できなくなります。Azure CLI、SDK、マネージド ID など複数の認証方式で発生する可能性があります。 実際のエラーメッセージ例 Azure CLI での出力例： $ az group list ERROR: The command failed with an unexpected status code: 401 (Unauthorized). The command failed with an error. (AuthenticationFailed) Authentication failed. The `Credentials` object was not initialized. Please call `Credentials.Initialize()` before making any requests. REST API レスポンス例： { "error": { "code": "AuthenticationFailed", "message": "Authentication failed. The user or application is not authorized to access the resource.", "details": [ { "code": "Unauthorized", "message": "The request requires authentication information." } ] } } よくある原因と解決手順 原因1：az login のセッションが期限切れになっている Azure CLI の認証セッションには有効期限があります。特に長時間セッションを保持していたり、PC のスリープ後に再度コマンドを実行したりする場合、自動的にセッションが無効化されることがあります。 ...

エラーの概要 Azure リソースへのアクセスが拒否されたことを示す HTTP 403 エラーです。このエラーは、ユーザーやアプリケーションが認証には成功（401 ではなく）したものの、対象リソースに対する操作権限がないことを意味します。Azure では RBAC（ロールベースアクセス制御）、Azure Policy、ネットワーク設定などの複数のレイヤーで権限チェックが行われるため、403 が頻繁に発生します。 実際のエラーメッセージ例 Azure Portal や Azure CLI を通じて 403 エラーが出力される場合、以下のような形式で表示されます。 { "error": { "code": "AuthorizationFailed", "message": "The client 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with object id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' over scope '/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Compute/virtualMachines/<vm-name>'." } } $ az vm create --resource-group <resource-group> --name <vm-name> ... (AuthorizationFailed) The client 'user@example.com' with object id '...' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/write' よくある原因と解決手順 原因 1：RBAC で必要なロールが割り当てられていない Azure RBAC により、ユーザーやサービスプリンシパルに対して明示的にロールを割り当てない限り、リソースへの操作は拒否されます。例えば、仮想マシンの作成には「仮想マシン共同作成者」や「共同作成者」ロールが必要です。サブスクリプションやリソースグループレベルでロールが割り当てられていなければ、その配下のすべてのリソース操作が 403 で拒否されます。 ...

エラーの概要 Azureの404エラーは、APIやポータルからアクセスしようとしたリソースが見つからないことを示すHTTPエラーです。このエラーが発生すると、指定したリソース名、リソースID、あるいはAPIエンドポイントが存在しないか、アクセス権限がない状態を意味します。Azure CLIやREST API、Azure Portalを通じてリソースを操作する際に頻繁に遭遇するエラーであり、原因の特定と対処には体系的なアプローチが必要です。 実際のエラーメッセージ例 Azure CLIの出力例： { "error": { "code": "ResourceNotFound", "message": "The Resource 'Microsoft.Compute/virtualMachines/<vm-name>' under resource group '<resource-group-name>' was not found." } } REST APIレスポンス例： { "code": "NotFound", "message": "The specified blob does not exist.", "details": [] } Azure CLI標準エラー出力例： The resource with id /subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Storage/storageAccounts/<account-name> does not exist. (Code: ResourceNotFound) よくある原因と解決手順 原因1：リソース名またはIDの綴りが間違っている Azureのリソース名やリソースIDに入力ミスがあると、404エラーが発生します。特にストレージアカウント名やVirtual Machine名は大文字小文字が区別され、ハイフンやアンダースコアが混在することで綴り間違いが起きやすくなります。また、REST APIで完全修飾リソースID（例：/subscriptions/.../resourceGroups/.../providers/...）を指定する場合、パス内のどこかに誤字があると該当リソースが見つかりません。 Before（エラーが起きるコード）： az vm show --resource-group myResourceGroup --name myVirtualMahine After（修正後）： az vm show --resource-group myResourceGroup --name myVirtualMachine Before（エラーが起きるコード）： curl -X GET \ https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorgeaccount/listKeys?api-version=2023-01-01 \ -H "Authorization: Bearer <access-token>" After（修正後）： ...

エラーの概要 Azure 400エラーは「Bad Request」を意味し、Azure APIへのリクエストに含まれるパラメータや値に誤りがある場合に発生します。これは認証エラーではなく、リクエストの内容そのものが仕様に違反していることを示す重要な信号です。Azure PortalやAzure CLI、REST APIを通じてリソースを作成・更新する際に頻繁に遭遇するエラーであり、適切な対応により確実に解決できます。 実際のエラーメッセージ例 Azure REST APIのレスポンス例： { "error": { "code": "BadRequest", "message": "The value of parameter 'vmName' is invalid.", "details": [ { "code": "InvalidParameterValue", "message": "The name 'my-vm-123456789-toolongname' is longer than the maximum allowed length of 15 characters." } ] } } Azure CLIの出力例： $ az vm create --resource-group myRG --name "invalid@vm#name" --image UbuntuLTS (BadRequest) The name 'invalid@vm#name' does not match the allowed pattern. よくある原因と解決手順 原因1：必須パラメータの不足または型の不正 リクエストに必須のパラメータが含まれていないか、指定した値がAPIが期待するデータ型と異なっている場合に発生します。例えば、リソースIDは文字列型で指定が必須であるのに対し、数値型で送信された場合などが該当します。Azure APIの仕様では厳密な型チェックが行われるため、JSONペイロードの構造確認は必須です。 Before（エラーが起きるコード）： import requests payload = { "properties": { "adminUsername": "azureuser", # adminPassword が不足している "osProfile": { "computerName": "myvm" } } } response = requests.put( "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2021-07-01", headers={"Authorization": f"Bearer {token}"}, json=payload ) After（修正後）： ...

エラーの概要 Docker Compose で 403 エラーが発生する場合、これはレジストリ（Docker Hub、プライベートレジストリなど）またはホストマシンのリソースに対して、実行ユーザーが十分なアクセス権限を持っていないことを示しています。プライベートイメージの pull、ボリュームマウント時のファイルアクセス、Docker ソケットへのアクセスなど、複数の場面で発生する可能性があります。 実際のエラーメッセージ例 Docker Hub などのレジストリからのプライベートイメージ pull 時： { "message": "Error response from daemon: pull access denied for myregistry/myimage, repository does not exist or may require 'docker login'", "error": "403 Forbidden" } ボリュームマウントのパーミッション不足時： ERROR: for <service-name> Cannot start service <service-name>: error while creating mount source path '/data/app': permission denied Docker ソケットへのアクセス権限不足時： ERROR: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock よくある原因と解決手順 原因1：プライベートイメージレジストリへの認証不足 Docker Compose でプライベートイメージを利用する場合、レジストリに対する認証情報が必要です。認証なしにプライベートイメージを pull しようとすると 403 エラーが発生します。 ...

エラーの概要 Docker Compose の 404 エラーは、docker-compose.yml（または compose.yml）で指定されたイメージ、サービス、ボリューム、またはネットワークがシステムに見つからないときに発生します。このエラーは、イメージのプル失敗、ビルドコンテキストの誤設定、または依存リソースの不足が原因となることがほとんどです。Docker Compose がコンテナーの起動や構築を試みた際に、参照先が存在しないことを検出すると、このエラーを出力して処理を中断します。 実際のエラーメッセージ例 Error response from daemon: pull access denied for <your-image-name>, repository does not exist or may require 'docker login' または、より明確な 404 表現として： { "message": "manifest not found", "status": 404 } ローカルでのビルド失敗時： ERROR: Service '<your-service-name>' failed to build : [Errno 2] No such file or directory: '<your-build-context-path>' よくある原因と解決手順 原因1：compose.yml 内で指定したイメージが存在しない、またはタグが間違っている Docker Compose がレジストリ（Docker Hub やプライベートレジストリー）からイメージをプルしようとしても、そのイメージが存在しない、あるいはタグが誤っていると 404 エラーが発生します。たとえば、タイポやバージョン番号の誤指定があると、プル対象が見つからなくなります。 Before（エラーが起きるコード）： version: '3.8' services: web: image: nginx:lattest # タイポ: lattest → latest ports: - "80:80" After（修正後）： ...

エラーの概要 Docker Compose の 409 エラーは、リクエストされたコンテナーやネットワーク、ボリュームの状態が現在の環境状態と競合していることを示します。このエラーは通常、既に存在するリソースの作成を試みたり、使用中のポート・ネットワークを重複させたりした場合に発生します。既存の状態を認識しないまま操作を進めようとすると、Docker Compose がこの競合を検出して実行を中止します。 実際のエラーメッセージ例 パターン1：コンテナー名の競合 Error response from daemon: Conflict. The container name "<container-name>" is already in use by container "<existing-container-id>". You have to remove (or rename) that container to be able to reuse that name. パターン2：ポート番号の競合 ERROR: for <service-name> Cannot start service <service-name>: driver failed programming external connectivity on endpoint <endpoint-name>: Bind for 0.0.0.0:<port> failed: port is already allocated パターン3：ネットワークまたはボリュームの競合 Error response from daemon: network with name <network-name> already exists よくある原因と解決手順 原因1：同じ名前のコンテナーがすでに起動または停止状態で残っている Docker Compose は docker-compose.yml で定義したサービス名とプロジェクト名の組み合わせでコンテナー名を生成します。以前に作成したコンテナーが停止状態で残っていたり、同じ構成を再度実行しようとしたりすると、同じ名前のコンテナーが存在することになり、409 エラーが発生します。 修正方法： # 既存のコンテナーと関連リソースを完全に削除 docker compose down -v # その後、新たに起動 docker compose up -d -v フラグでボリュームも削除されるため、データの永続化が必要な場合は事前にバックアップを取得してください。 原因2：同じポートを複数のサービスが使おうとしている docker-compose.yml で複数のサービスが同じホストポートをバインドしようとしている場合、またはホストシステムの別のプロセスがすでにそのポートを使用している場合に 409 エラーが発生します。 修正方法： version: '3.8' services: web1: image: nginx:latest ports: - "8080:80" web2: image: nginx:latest ports: - "8081:80" 各サービスに異なるホストポートを割り当てることで競合を解決します。既にポートが使用されている場合は、以下のコマンドでホストマシン上の使用中ポートを確認できます。 ...