Azure Dev Spaces のトラブルシューティングAzure Dev Spaces troubleshooting


Azure Dev Spaces は廃止の予定であり、2023 年 10 月 31 日に終了します。Azure Dev Spaces is being retired and will stop working on October 31, 2023. Bridge to Kubernetes への移行を検討してください。Consider migrating to Bridge to Kubernetes.

このガイドでは、Azure Dev Spaces 使用時の一般的な問題についての情報を示します。This guide contains information about common problems you may have when using Azure Dev Spaces.

Azure Dev Spaces の使用時に問題が発生した場合は、Azure Dev Spaces GitHub リポジトリに問題を作成します。If you have a problem when using Azure Dev Spaces, create an issue in the Azure Dev Spaces GitHub repository.

開始する前にBefore you begin

問題のトラブルシューティングをより効果的に行うには、レビュー用のより詳細なログを作成することが役に立つ可能性があります。To troubleshoot problems more effectively, it may help to create more detailed logs for review.

Visual Studio の場合、MS_VS_AZUREDEVSPACES_TOOLS_LOGGING_ENABLED 環境変数を 1 に設定します。For Visual Studio, set the MS_VS_AZUREDEVSPACES_TOOLS_LOGGING_ENABLED environment variable to 1. 環境変数を有効にするために Visual Studio を再起動してください。Be sure to restart Visual Studio for the environment variable to take effect. 有効になると、詳細なログが %TEMP%\Microsoft.VisualStudio.Azure.DevSpaces.Tools ディレクトリに書き込まれます。Once enabled, detailed logs are written to your %TEMP%\Microsoft.VisualStudio.Azure.DevSpaces.Tools directory.

CLI では、--verbose スイッチを使用してコマンド実行中に詳細な情報を出力できます。In the CLI, you can output more information during command execution by using the --verbose switch. %TEMP%\Azure Dev Spacesでより詳しいログを参照することもできます。You can also browse more detailed logs in %TEMP%\Azure Dev Spaces. Mac では、ターミナル ウィンドウから echo $TMPDIR を実行することで、TEMP ディレクトリを見つけることができます。On a Mac, the TEMP directory can be found by running echo $TMPDIR from a terminal window. Linux コンピューターでは、通常、TEMP ディレクトリは /tmp です。On a Linux computer, the TEMP directory is usually /tmp. また、Azure CLI 構成ファイルでログ記録が有効になっていることを確認します。In addition, verify that logging is enabled in your Azure CLI configuration file.

Azure Dev Spaces は、単一のインスタンス (ポッド) のデバッグでもきわめて効果的に機能します。Azure Dev Spaces also works best when debugging a single instance, or pod. azds.yaml ファイルには、Kubernetes がサービスに対して実行するポッドの数を示す設定である replicaCount が含まれています。The azds.yaml file contains a setting, replicaCount, that indicates the number of pods that Kubernetes runs for your service. replicaCount を変更して特定のサービスに対して複数のポッドを実行するようにアプリを設定すると、デバッガは (アルファベット順にリストされている場合) 最初のポッドに接続されます。If you change the replicaCount to configure your application to run multiple pods for a given service, the debugger attaches to the first pod, when listed alphabetically. 元のポッドがリサイクルされた場合、デバッガは別のポッドに接続されます。これにより、予期しない動作が発生する可能性があります。The debugger attaches to a different pod when the original pod recycles, possibly resulting in unexpected behavior.

Azure Dev Spaces を有効にするときに発生する一般的な問題Common issues when enabling Azure Dev Spaces

エラー "Azure Dev Spaces コントローラーを作成できませんでした"Error "Failed to create Azure Dev Spaces controller"

コントローラーの作成で問題が発生した場合に、このようなエラーが表示されることがあります。You might see this error when something goes wrong with the creation of the controller. これが一時的なエラーの場合は、コントローラーを削除して再作成することで修正されます。If it's a transient error, delete and recreate the controller to fix it.

コントローラーの削除を試みることもできます。You can also try deleting the controller:

azds remove -g <resource group name> -n <cluster name>

コントローラーを削除するには、Azure Dev Spaces CLI を使用します。Use the Azure Dev Spaces CLI to delete a controller. Visual Studio からコントローラーを削除することはできません。It's not possible to delete a controller from Visual Studio. また、Azure Cloud Shell に Azure Dev Spaces CLI をインストールすることもできないため、Azure Cloud Shell からコントローラーを削除することはできません。You also can't install the Azure Dev Spaces CLI in the Azure Cloud Shell so you can't delete a controller from the Azure Cloud Shell.

Azure Dev Spaces CLI がインストールされていない場合は、まず次のコマンドを使用してインストールしてからコントローラーを削除できます。If you don't have the Azure Dev Spaces CLI installed, you can first install it using the following command then delete your controller:

az aks use-dev-spaces -g <resource group name> -n <cluster name>

コントローラー名の文字数が原因でコントローラーの作成に失敗するController create failing because of controller name length

Azure Dev Spaces コントローラー名の文字数は 31 文字までです。An Azure Dev Spaces controller's name can't be longer than 31 characters. AKS クラスターの Dev Spaces を有効にするとき、またはコントローラーを作成するときに、コントローラー名が 31 文字を超えているとエラーが発生します。If your controller's name exceeds 31 characters when you enable Dev Spaces on an AKS cluster or create a controller, you'll receive an error. 次に例を示します。For example:

Failed to create a Dev Spaces controller for cluster 'a-controller-name-that-is-way-too-long-aks-east-us': Azure Dev Spaces Controller name 'a-controller-name-that-is-way-too-long-aks-east-us' is invalid. Constraint(s) violated: Azure Dev Spaces Controller names can only be at most 31 characters long*

この問題を解決するには、別の名前でコントローラーを作成します。To fix this issue, create a controller with an alternate name. 次に例を示します。For example:

azds controller create --name my-controller --target-name MyAKS --resource-group MyResourceGroup

AKS クラスターに Windows ノード プールが追加されていると、Dev Spaces を有効にすることができませんEnabling Dev Spaces failing when Windows node pools are added to an AKS cluster

現在のところ、Azure Dev Spaces は Linux のポッドとノードのみで実行するものです。Currently, Azure Dev Spaces is intended to run on Linux pods and nodes only. Windows ノード プールのある AKS クラスターがある場合は、Azure Dev Spaces ポッドが Linux ノードでのみスケジュールされていることを確認する必要があります。When you have an AKS cluster with a Windows node pool, you must ensure that Azure Dev Spaces pods are only scheduled on Linux nodes. Azure Dev Spaces ポッドが Windows ノードで実行されるようにスケジュールされている場合、そのポッドは開始されず、Dev Spaces の有効化は失敗します。If an Azure Dev Spaces pod is scheduled to run on a Windows node, that pod won't start and enabling Dev Spaces will fail.

この問題を解決するには、AKS クラスターにテイントを追加して、Linux ポッドが Windows ノードで実行されるようにスケジュールされていないことを確認します。To fix this issue, add a taint to your AKS cluster to ensure Linux pods aren't scheduled to run on a Windows node.

エラー "クラスター上で準備完了状態のテイントされていない Linux ノードが見つかりませんでした。Error "Found no untainted Linux nodes in Ready state on the cluster. "azds" 名前空間にポッドをデプロイするには、準備完了状態でテイントされていない Linux ノードが少なくとも 1 つ必要です。"There needs to be at least one untainted Linux node in Ready state to deploy pods in 'azds' namespace."

ポッドをスケジュールする 準備完了 状態のテイントされていないノードが見つからなかったため、Azure Dev Spaces で AKS クラスターにコントローラーを作成できませんでした。Azure Dev Spaces couldn't create a controller on your AKS cluster because it couldn't find an untainted node in a Ready state to schedule pods on. Azure Dev Spaces では、容認を指定せずにポッドをスケジュールするための、少なくとも 1 つの 準備完了 状態の Linux ノードが必要です。Azure Dev Spaces requires at least one Linux node in a Ready state that allows for scheduling pods without specifying tolerations.

この問題を解決するには、少なくとも 1 つの Linux ノードで容認を指定せずに確実にポッドをスケジュールできるように、AKS クラスターでテイント構成を更新します。To fix this issue, update your taint configuration on your AKS cluster to ensure at least one Linux node allows for scheduling pods without specifying tolerations. また、容認を指定せずポッドをスケジュールできる少なくとも 1 つの Linux ノードが、準備完了 状態であることも確認します。Also, ensure that at least one Linux node that allows scheduling pods without specifying tolerations is in the Ready state. ノードが 準備完了 状態に達するのに時間がかかっている場合は、ノードの再起動を試みることができます。If your node is taking a long time to reach the Ready state, you can try restarting your node.

az aks use-dev-spaces の実行時のエラー "Azure Dev Spaces CLI not installed properly (Azure Dev Spaces CLI が正しくインストールされていません)"Error "Azure Dev Spaces CLI not installed properly" when running az aks use-dev-spaces

Azure Dev Spaces CLI に対する更新により、そのインストール パスが変更されました。An update to the Azure Dev Spaces CLI changed its installation path. 2.0.63 より前のバージョンの Azure CLI を使用している場合は、このエラーが表示されることがあります。If you're using a version of the Azure CLI earlier than 2.0.63, you may see this error. Azure CLI のバージョンを表示するには、az --version を使用します。To display your version of the Azure CLI, use az --version.

az --version
azure-cli                         2.0.60 *

2.0.63 の前のバージョンの Azure CLI で az aks use-dev-spaces を実行している場合は、エラー メッセージに関係なくインストールは成功します。Despite the error message when running az aks use-dev-spaces with a version of the Azure CLI before 2.0.63, the installation does succeed. 引き続き問題なく azds を使用できます。You can continue to use azds without any issues.

この問題を解決するには、Azure CLI のインストールを 2.0.63 以降に更新します。To fix this issue, update your installation of the Azure CLI to 2.0.63 or later. この更新により、az aks use-dev-spaces の実行中に受け取るエラー メッセージが解決されます。This update will resolve the error message you receive when running az aks use-dev-spaces. また、引き続き現在のバージョンの Azure CLI と Azure Dev Spaces CLI を使用することもできます。Alternatively, you can continue to use your current version of the Azure CLI and the Azure Dev Spaces CLI.

エラー"Unable to reach kube-apiserver (kube-apiserver に到達できません)"Error "Unable to reach kube-apiserver"

Azure Dev Spaces が AKS クラスターの API サーバーに接続できない場合に、このエラーが表示されることがあります。You might see this error when Azure Dev Spaces is unable to connect to your AKS cluster's API server.

AKS クラスターの API サーバーへのアクセスがロック ダウンされている場合、または AKS クラスターに対して API サーバーの許可された IP アドレス範囲が有効になっている場合は、ご利用のリージョンに基づいて追加の範囲を許可するために、クラスターを作成または更新する必要もあります。If access to your AKS cluster API server is locked down or if you have API server authorized IP address ranges enabled for your AKS cluster, you must also create or update your cluster to allow additional ranges based on your region

kubectl コマンドを実行して、API サーバーが使用可能であることを確認してください。Ensure that the API server is available by running kubectl commands. API サーバーが使用できない場合は、AKS サポートに連絡し、API サーバーが動作しているときにもう一度試してください。If the API server is unavailable, please contact AKS support and try again when the API server is working.

Azure Dev Spaces のプロジェクトを準備するときに発生する一般的な問題Common issues when preparing your project for Azure Dev Spaces

警告 "Dockerfile could not be generated due to unsupported language(サポートされていない言語が原因で Dockerfile を生成できませんでした)"Warning "Dockerfile could not be generated due to unsupported language"

Azure Dev Spaces では、C# と Node.js がネイティブでサポートされます。Azure Dev Spaces provides native support for C# and Node.js. これらのいずれかの言語で記述されたコードが含まれているディレクトリで azds prep を実行すると、Azure Dev Spaces によって適切な Dockerfile が自動的に作成されます。When you run azds prep in a directory with code written in one of these languages, Azure Dev Spaces automatically creates an appropriate Dockerfile for you.

その他の言語で記述されたコードを Azure Dev Spaces で使用できますが、azds up の初回の実行前に、Dockerfile を手動で作成しておく必要があります。You can still use Azure Dev Spaces with code written in other languages, but you need to manually create the Dockerfile before running azds up for the first time.

Azure Dev Spaces でネイティブにサポートされる言語でアプリケーションが記述されていない場合、コードが実行されるコンテナー イメージをビルドするために適切な Dockerfile を設定する必要があります。If your application is written in a language that Azure Dev Spaces doesn't natively support, you need to provide an appropriate Dockerfile to build a container image running your code. Docker では、Dockerfile の記述に関するベスト プラクティスの一覧Dockerfile リファレンスを提供しています。これはご自身のニーズに合った Dockerfile を記述するために役立ちます。Docker provides a list of best practices for writing Dockerfiles and a Dockerfile reference that can help you write a Dockerfile that suits your needs.

適切な Dockerfile を用意できたら、azds up を実行して、Azure Dev Spaces でアプリケーションを実行します。Once you have an appropriate Dockerfile in place, you run azds up to run your application in Azure Dev Spaces.

Azure Dev Spaces でサービスを開始または停止するときに発生する一般的な問題Common issues when starting or stopping services with Azure Dev Spaces

エラー "構成ファイルが見つかりません:"Error "Config file not found:"

azds up を実行しているときに、このエラーが表示されることがあります。When running azds up, you may see this error. azds upazds prep はどちらも、Dev Spaces で実行するプロジェクトのルート ディレクトリから実行する必要があります。Both azds up and azds prep must be run from the root directory of the project you want to run in your dev space.

この問題を解決するには、次の手順に従います。To fix this issue:

  1. サービス コードが含まれているルート フォルダーにカレント ディレクトリを変更します。Change your current directory to the root folder containing your service code.
  2. azds.yaml ファイルがコード フォルダーにない場合、azds prep を実行して Docker、Kubernetes、および Azure Dev Spaces アセットを生成します。If you don't have a azds.yaml file in the code folder, run azds prep to generate Docker, Kubernetes, and Azure Dev Spaces assets.

AKS 仮想ノードの "Waiting for container image build... (コンテナー イメージがビルドされるのを待っています...)" 手順でタイムアウトが発生するTimeout at "Waiting for container image build..." step with AKS virtual nodes

このタイムアウトは、Dev Spaces を使用して、AKS 仮想ノード上で実行するように構成されているサービスを実行しようとした場合に発生します。This timeout occurs when you attempt to use Dev Spaces to run a service that is configured to run on an AKS virtual node. Dev Spaces では、現在、仮想ノード上でのサービスのビルドもデバッグもサポートされていません。Dev Spaces doesn't currently support building or debugging services on virtual nodes.

azds up--verbose スイッチを指定して実行するか、Visual Studio で詳細ログを有効にした場合、次の詳細が表示されます。If you run azds up with the --verbose switch, or enable verbose logging in Visual Studio, you see additional detail:

azds up --verbose

Installed chart in 2s
Waiting for container image build...
pods/mywebapi-76cf5f69bb-lgprv: Scheduled: Successfully assigned default/mywebapi-76cf5f69bb-lgprv to virtual-node-aci-linux
Streaming build container logs for service 'mywebapi' failed with: Timed out after 601.3037572 seconds trying to start build logs streaming operation. 10m 1s
Container image build failed

上のコマンドは、サービスのポッドが、仮想ノードである virtual-node-aci-linux に割り当てられたことを示しています。The above command shows that the service's pod was assigned to virtual-node-aci-linux, which is a virtual node.

この問題を解決するには、サービス用の Helm チャートで、仮想ノード上でのサービスの実行を許可する nodeSelector 値と tolerations 値を削除して、チャートを更新します。To fix this issue, update the Helm chart for the service to remove any nodeSelector or tolerations values that allow the service to run on a virtual node. 通常、これらの値は、チャートの values.yaml ファイルに定義されます。These values are typically defined in the chart's values.yaml file.

Dev Spaces を介してビルドまたはデバッグするサービスを VM ノード上で実行したい場合は、仮想ノード機能が有効な AKS クラスターを引き続き使用できます。You can still use an AKS cluster that has the virtual nodes feature enabled, if the service you wish to build or debug via Dev Spaces runs on a VM node. VM ノード上で Dev Spaces を使用してサービスを実行するのが既定の構成です。Running a service with Dev Spaces on a VM node is the default configuration.

Dev Spaces 起動時の "Error: could not find a ready tiller pod" (エラー: 準備のできた Tiller ポッドが見つかりませんでした)Error "could not find a ready tiller pod" when launching Dev Spaces

このエラーは、クラスターで実行されている Tiller ポッドに Helm クライアントが通信できなくなった場合に発生します。This error occurs if the Helm client can no longer talk to the Tiller pod running in the cluster.

この問題を解決するには、クラスター内のエージェント ノードを再起動します。To fix this issue, restart the agent nodes in your cluster.

エラー: "リリース azds-<identifier>-<spacename>-<servicename> が失敗しました: サービス '<servicename>' は既に存在します" または "<servicename> に対するプル アクセスが拒否されました。リポジトリが存在しないか、"docker login" が必要な場合があります"Error "release azds-<identifier>-<spacename>-<servicename> failed: services '<servicename>' already exists" or "Pull access denied for <servicename>, repository does not exist or may require 'docker login'"

これらのエラーは、ダイレクト Helm コマンド (helm installhelm upgradehelm delete など) と、Dev Spaces コマンド (azds upazds down など) を同じ開発スペース内に混在させて実行した場合に、発生することがあります。These errors can occur if you mix running direct Helm commands (such as helm install, helm upgrade, or helm delete) with Dev Spaces commands (such as azds up and azds down) inside the same dev space. 原因は、Dev Spaces に独自の Tiller インスタンスがあり、これが、同じ開発スペースで実行されているご自身の Tiller インスタンスと競合していることです。They occur because Dev Spaces has its own Tiller instance, which conflicts with your own Tiller instance running in the same dev space.

Helm コマンドと Dev Spaces コマンドは両方とも同じ AKS クラスターに対して使用しても問題ありませんが、それぞれの Dev Spaces 対応名前空間で、いずれかが使用されていなければなりません。It's fine to use both Helm commands and Dev Spaces commands against the same AKS cluster, but each Dev Spaces-enabled namespace should use either one or the other.

たとえば、Helm コマンドを使用して、親開発スペースでご自身のアプリケーション全体を実行するとします。For example, suppose you use a Helm command to run your entire application in a parent dev space. その親から離れた場所に子開発スペースを作成し、Dev Spaces を使って子開発スペース内で個別のサービスを実行した後、そのサービスをまとめてテストできます。You can create child dev spaces off that parent, use Dev Spaces to run individual services inside the child dev spaces, and test the services together. ご自身の変更をチェックインする準備ができたら、Helm コマンドを使用して、更新されたコードを親開発スペースにデプロイします。When you're ready to check in your changes, use a Helm command to deploy the updated code to the parent dev space. 更新されたサービスを親開発スペースで実行するときに azds up は使用しないでください。これは、Helm を使用して最初にサービスで実行されたサービスと競合するためです。Don't use azds up to run the updated service in the parent dev space, because it will conflict with the service initially run using Helm.

既存の Dockerfile がコンテナーのビルドに使用されないExisting Dockerfile not used to build a container

プロジェクト内の特定の Dockerfile を指示するように Azure Dev Spaces を構成できます。Azure Dev Spaces can be configured to point to a specific Dockerfile in your project. Azure Dev Spaces で、コンテナーをビルドするために想定した Dockerfile が使用されていないと思われる場合は、どの Dockerfile ファイルを使用するかを Azure Dev Spaces に明示的に通知する必要があります。If it appears Azure Dev Spaces isn't using the Dockerfile you expect to build your containers, you might need to explicitly tell Azure Dev Spaces which Dockerfile to use.

この問題を解決するには、Azure Dev Spaces によってプロジェクト内に生成された azds.yaml ファイルを開きます。To fix this issue, open the azds.yaml file that Azure Dev Spaces generated in your project. configurations: develop: build: dockerfile を更新して、使用する Dockerfile を指示します。Update configurations: develop: build: dockerfile to point to the Dockerfile you want to use. 次に例を示します。For example:

      dockerfile: Dockerfile.develop

プライベート レジストリから Docker イメージを使用しようとすると、"unauthorized: authentication required" (未承認: 認証が必要) というエラーが発生するError "unauthorized: authentication required" when trying to use a Docker image from a private registry

認証を必要とするプライベート レジストリから Docker イメージを使用しています。You're using a Docker image from a private registry that requires authentication.

この問題を解決するには、imagePullSecrets を使用して、このプライベート レジストリからイメージを認証およびプルすることを Dev Spaces に許可することができます。To fix this issue, you can allow Dev Spaces to authenticate and pull images from this private registry using imagePullSecrets. imagePullSecrets を使用するには、イメージを使用する名前空間に Kubernetes シークレットを作成します。To use imagePullSecrets, create a Kubernetes secret in the namespace where you're using the image. 次に、azds.yaml で imagePullSecret としてシークレットを指定します。Then provide the secret as an imagePullSecret in azds.yaml.

azds.yaml で imagePullSecrets を指定する例を次に示します。Below is an example of a specifying imagePullSecrets in azds.yaml.

kind: helm-release
apiVersion: 1.1
  context: $BUILD_CONTEXT$
  dockerfile: Dockerfile
  chart: $CHART_DIR$
    # Optional, specify an array of imagePullSecrets. These secrets must be manually created in the namespace.
    # This will override the imagePullSecrets array in values.yaml file.
    # If the dockerfile specifies any private registry, the imagePullSecret for the registry must be added here.
    # ref:
    # This uses credentials from secret "myRegistryKeySecretName".
      - name: myRegistryKeySecretName


azds.yaml で imagePullSecrets を設定すると、values.yaml で指定された imagePullSecrets はオーバーライドされます。Setting imagePullSecrets in azds.yaml will override imagePullSecrets specified in the values.yaml.

エラー "サービスを開始できません。"Error "Service cannot be started."

サービス コードを起動できない場合、このエラーが表示されることがあります。You might see this error when your service code fails to start. 通常、原因はユーザー コードです。The cause is often in user code. より詳しい診断情報を入手するには、サービスを開始するときに、詳細なログを有効にします。To get more diagnostic information, enable more detailed logging when starting your service.

詳細なログを有効にするには、コマンド ラインから --verbose を使用します。From the command line, use the --verbose to enable more detailed logging. --output を使用して出力形式を指定することもできます。You can also specify an output format using --output. 次に例を示します。For example:

azds up --verbose --output json

Visual Studio で次の操作を行います。In Visual Studio:

  1. [ツール] > [オプション] を開き、 [プロジェクトとソリューション] で、 [ビルドおよび実行] を選択します。Open Tools > Options and under Projects and Solutions, choose Build and Run.

  2. [MSBuild プロジェクト ビルドの出力の詳細] の設定を [詳細] または [診断] に変更します。Change the settings for MSBuild project build output verbosity to Detailed or Diagnostic.

    ツール オプション ダイアログのスクリーンショット

コントローラーの再作成後のサービスの再実行Rerunning a service after controller re-creation

このクラスターに関連付けられた Azure Dev Spaces を削除してから再作成した後、サービスを再実行しようとすると、"Service cannot be started (サービスを開始できません) " エラーが発生します。You receive a Service cannot be started error when attempting to rerun a service after you have removed and then recreated the Azure Dev Spaces controller associated with this cluster. このような状況では、詳細出力に次のテキストが含まれます。In this situation, the verbose output contains the following text:

Installing Helm chart...
Release "azds-33d46b-default-webapp1" does not exist. Installing it now.
Error: release azds-33d46b-default-webapp1 failed: services "webapp1" already exists
Helm install failed with exit code '1': Release "azds-33d46b-default-webapp1" does not exist. Installing it now.
Error: release azds-33d46b-default-webapp1 failed: services "webapp1" already exists

このエラーは、Dev Spaces コントローラーを削除しても、そのコントローラーによって以前にインストールされたサービスが削除されないという理由で発生します。This error occurs because removing the Dev Spaces controller doesn't remove services previously installed by that controller. コントローラーを再作成してから、新しいコントローラーを使用してサービスを実行しようとしても、古いサービスがまだ残っているため失敗します。Recreating the controller and then attempting to run the services using the new controller fails because the old services are still in place.

この問題に対処するには、kubectl delete コマンドを使用して古いサービスをクラスターから手動で削除した後、Dev Spaces を再実行して新しいサービスをインストールします。To address this problem, use the kubectl delete command to manually remove the old services from your cluster, then rerun Dev Spaces to install the new services.

エラー "サービスを開始できません。"Error "Service cannot be started." (マルチステージの Dockerfile の使用時)when using multi-stage Dockerfiles

マルチステージの Dockerfile を使用すると、"Service cannot be started (サービスを開始できません) " エラーが発生します。You receive a Service cannot be started error when using a multi-stage Dockerfile. このような状況では、詳細出力に次のテキストが含まれます。In this situation, the verbose output contains the following text:

$ azds up -v
Using dev space 'default' with target 'AksClusterName'
Synchronizing files...6s
Installing Helm chart...2s
Waiting for container image build...10s
Building container image...
Step 1/12 : FROM [imagename:tag] AS base
Error parsing reference: "[imagename:tag] AS base" is not a valid repository/tag: invalid reference format
Failed to build container image.
Service cannot be started.

このエラーが発生するのは、Azure Dev Spaces が現在マルチステージ ビルドをサポートしていないためです。This error occurs because Azure Dev Spaces does not currently support multi-stage builds. マルチステージ ビルドを回避するには、Dockerfile を書き直します。To avoid multi-stage builds, rewrite your Dockerfile.

開発マシンに接続するときに、ネットワーク トラフィックが AKS クラスターに転送されないNetwork traffic is not forwarded to your AKS cluster when connecting your development machine

Azure Dev Spaces を使用して AKS クラスターを開発マシンに接続すると、開発マシンと AKS クラスターの間でネットワーク トラフィックが転送されないという問題が発生する可能性があります。When using Azure Dev Spaces to connect your AKS cluster to your development machine, you may encounter an issue where network traffic is not forwarded between your development machine and your AKS cluster.

開発マシンを AKS クラスターに接続すると、Azure Dev Spaces は開発マシンの hosts ファイルを変更することによって、お使いの AKS クラスターと開発マシンの間でネットワーク トラフィックを転送します。When connecting your development machine to your AKS cluster, Azure Dev Spaces forwards network traffic between your AKS cluster and your development machine by modifying your development machine's hosts file. Azure Dev Spaces は、ホスト名として置き換える Kubernetes サービスのアドレスを使用して、hosts にエントリを作成します。Azure Dev Spaces creates an entry in the hosts with the address of the Kubernetes service you are replacing as a host name. このエントリは、開発マシンと AKS クラスターの間でネットワーク トラフィックを転送するために、ポート フォワーディングと共に使用されます。This entry is used with port forwarding to direct network traffic between your development machine and the AKS cluster. 開発マシン上のサービスが、置き換える Kubernetes サービスのポートと競合する場合、Azure Dev Spaces は Kubernetes サービスのネットワーク トラフィックを転送できません。If a service on your development machine conflicts with the port of the Kubernetes service you are replacing, Azure Dev Spaces cannot forward network traffic for the Kubernetes service. たとえば、Windows BranchCache サービスは通常 にバインドされます。これにより、すべてのローカル IP でポート 80 の競合が発生します。For example, the Windows BranchCache service is usually bound to, which conflicts will cause a conflict for port 80 on all local IPs.

この問題を解決するには、置き換えようとしている Kubernetes サービスのポートと競合する、あらゆるサービスやプロセスを停止する必要があります。To fix this issue, you need to stop any services or processes that conflict with port of the Kubernetes service you are trying to replace. netstat などのツールを使用して、開発マシン上のどのサービスまたはプロセスが競合しているかを調べることができます。You can use tools, such as netstat, to inspect what services or processes on your development machine are in conflict.

たとえば、Windows BranchCache サービスを停止および無効にするには、次のようにします。For example, to stop and disable the Windows BranchCache service:

  • コマンド プロンプトで services.msc を実行します。Run services.msc from the command prompt.
  • [BranchCache] を右クリックし、 [プロパティ] を選択します。Right click on BranchCache and select Properties.
  • [停止] をクリックします。Click Stop.
  • 必要に応じて、 [スタートアップの種類][無効] に設定して無効にすることができます。Optionally, you can disable it by setting Startup type to Disabled.
  • [OK] をクリックします。Click OK.

エラー "割り当てられた状態で pod:azds/azds-webhook-deployment-<id>の AzureAssignedIdentity が見つかりませんでした"Error "no AzureAssignedIdentity found for pod:azds/azds-webhook-deployment-<id> in assigned state"

マネージド ID および ポッド マネージ ID がインストールされている AKS クラスターで、Azure Dev Spaces を使用してサービスを実行すると、"グラフのインストール" ステップ後にプロセスが応答しなくなることがあります。When running a service with Azure Dev Spaces on an AKS cluster with a managed identity and pod managed identities installed, the process may stop responding after the chart install step. azds 名前空間で azds-injector-webhook を調べると、このエラーが表示されることがあります。If you inspect the azds-injector-webhook in the azds name space, you may see this error.

Azure Dev Spaces がクラスターで実行するサービスは、クラスターのマネージド ID を利用して、クラスター外の Azure Dev Spaces バックエンド サービスと通信します。The services Azure Dev Spaces runs on your cluster utilize the cluster's managed identity to talk to the Azure Dev Spaces backend services outside the cluster. ポッド マネージド ID がインストールされている場合、ネットワーク ルールはクラスターのノードで構成され、マネージド ID 資格情報の呼び出しはすべて、クラスターにインストールされた Node Managed Identity (NMI) デーモンセットにリダイレクトされます。When the pod managed identity is installed, networking rules are configured on your cluster's nodes to redirect all calls for managed identity credentials to a Node Managed Identity (NMI) DaemonSet installed on the cluster. この NMI デーモンセットは呼び出し元のポッドを識別し、要求されたマネージド ID にアクセスできるようポッドに適切なラベルが付けられていることを確認します。This NMI DaemonSet identifies the calling pod and ensures that pod has been labeled appropriately to access the requested managed identity. Azure Dev Spaces は、クラスターにポッド マネージド ID がインストールされているかどうか検出できず、Azure Dev Spaces サービスがクラスターのマネージド ID にアクセスするために必要な構成を実行できません。Azure Dev Spaces can't detect if a cluster has pod managed identity installed and can't perform the necessary configuration to allow Azure Dev Spaces services to access the cluster's managed identity. Azure Dev Spaces サービスはクラスターのマネージド ID にアクセスするように構成されていないため、NMI デーモンセットではマネージド ID の Azure AD トークンを取得できず、Azure Dev Spaces バックエンド サービスと通信できません。Since the Azure Dev Spaces services haven't been configured to access the cluster's managed identity, the NMI DaemonSet will not allow them to obtain an Azure AD token for the managed identity and fail to communicate with Azure Dev Spaces backend services.

この問題を修正するには、azds-injector-webhookAzurePodIdentityException を適用し、Azure Dev Spaces でインストルメント化されたポッドを更新してマネージド ID にアクセスできるようにします。To fix this issue, apply an AzurePodIdentityException for the azds-injector-webhook and update pods instrumented by Azure Dev Spaces to access the managed identity.

webhookException.yaml という名前のファイルを作成し、以下の YAML 定義をコピーします。Create a file named webhookException.yaml and copy the following YAML definition:

apiVersion: ""
kind: AzurePodIdentityException
  name: azds-infrastructure-exception
  namespace: azds
  PodLabels: "true"

上記のファイルによって、azds-injector-webhookAzurePodIdentityException オブジェクトが作成されます。The above file creates a AzurePodIdentityException object for the azds-injector-webhook. このオブジェクトをデプロイするには、kubectl を使用します。To deploy this object, use kubectl:

kubectl apply -f webhookException.yaml

マネージド ID にアクセスするために Azure Dev Spaces によってインストルメント化されたポッドを更新するには、以下の YAML 定義で 名前空間 を更新し、kubectl を使用して各開発領域に適用します。To update pods instrumented by Azure Dev Spaces to access the managed identity, update the namespace in the below YAML definition and use kubectl to apply it for each dev space.

apiVersion: ""
kind: AzurePodIdentityException
  name: azds-infrastructure-exception
  namespace: myNamespace
  PodLabels: "true"

また、AzureIdentity および AzureIdentityBinding オブジェクトを作成し、Azure Dev Spaces によってインストルメント化されたスペースで実行中のワークロードのポッド ラベルを更新して、AKS クラスターによって作成されたマネージド ID にアクセスできるようにすることもできます。Alternatively, you can create AzureIdentity and AzureIdentityBinding objects and update the pod labels for workloads running in spaces instrumented by Azure Dev Spaces to access the managed identity created by the AKS cluster.

マネージド ID の詳細を一覧表示するには、AKS クラスターで以下のコマンドを実行してください。To list the details of the managed identity, run the following command for your AKS cluster:

az aks show -g <resourcegroup> -n <cluster> -o json --query "{clientId: identityProfile.kubeletidentity.clientId, resourceId: identityProfile.kubeletidentity.resourceId}"

上記のコマンドはマネージド ID の clientIdresourceId を出力します。The above command outputs the clientId and resourceId for the managed identity. 次に例を示します。For example:

  "clientId": "<clientId>",
  "resourceId": "/subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>"

AzureIdentity オブジェクトを作成するには、clusteridentity.yaml という名前のファイルを作成し、前のコマンドで得たマネージド ID の詳細で更新された以下の YAML 定義を使用します。To create an AzureIdentity object, create a file named clusteridentity.yaml and use the following YAML definition updated with the details of your managed identity from the previous command:

apiVersion: ""
kind: AzureIdentity
  name: my-cluster-mi
  type: 0
  ResourceID: /subscriptions/<subid>/resourcegroups/<resourcegroup>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<name>
  ClientID: <clientId>

AzureIdentityBinding オブジェクトを作成するには、clusteridentitybinding.yaml という名前のファイルを作成し、以下の YAML 定義を使用します。To create an AzureIdentityBinding object, create a file named clusteridentitybinding.yaml and use the following YAML definition:

apiVersion: ""
kind: AzureIdentityBinding
  name: my-cluster-mi-binding
  AzureIdentity: my-cluster-mi
  Selector: my-label-value

AzureIdentity および AzureIdentityBinding オブジェクトをデプロイするには、kubectl を使用します。To deploy the AzureIdentity and AzureIdentityBinding objects, use kubectl:

kubectl apply -f clusteridentity.yaml
kubectl apply -f clusteridentitybinding.yaml

AzureIdentity および AzureIdentityBinding オブジェクトのデプロイ後、aadpodidbinding: my-label-value ラベルを持つワークロードはクラスターのマネージド ID にアクセスできるようになります。After you deploy the AzureIdentity and AzureIdentityBinding objects, any workload with the aadpodidbinding: my-label-value label can access the cluster's managed identity. このラベルを追加し、開発領域で実行中のワークロードをすべて再度デプロイします。Add this label and redeploy all workloads running in any dev space. 次に例を示します。For example:

apiVersion: apps/v1
kind: Deployment
  name: sample
  replicas: 1
        app: sample
        aadpodidbinding: my-label-value

エラー "Azure Dev Spaces コントローラー ' ABC ' は 'Failed' 状態であるため、この接続の詳細を取得できません。Error "Cannot get connection details for Azure Dev Spaces Controller 'ABC' because it is in the 'Failed' state. コントローラーで何らかの問題が発生した可能性があります。"Something wrong might have happened with your controller."

この問題を解決するには、Azure Dev Spaces コントローラーをクラスターから削除してから再インストールすることを試してください。To resolve this issue, try deleting the Azure Dev Spaces controller from the cluster and reinstalling it:

azds remove -g <resource group name> -n <cluster name>
azds controller create --name <cluster name> -g <resource group name> -tn <cluster name>

また、Azure Dev Spaces は廃止される予定なので、Bridge to Kubernetes への移行を検討してください。これによりエクスペリエンスが向上します。Also, as Azure Dev Spaces is being retired, please consider migrating to Bridge to Kubernetes which provides a better experience.

Visual Studio と Visual Studio Code を Azure Dev Spaces で使用するときに発生する一般的な問題Common issues using Visual Studio and Visual Studio Code with Azure Dev Spaces

エラー "必要なツールと構成が見つからない"Error "Required tools and configurations are missing"

このエラーは、VS Code を起動するときに発生する場合があります。"[[Azure Dev Spaces] Required tools and configurations to build and debug '[project name]' are missing.]([Azure Dev Spaces] '[プロジェクト名]' をビルドして出バックするために必要なツールと構成がありません。)"This error might occur when launching VS Code: "[Azure Dev Spaces] Required tools and configurations to build and debug '[project name]' are missing." エラーは、VS Code に示されるように、azds.exe が PATH 環境変数に無いことを意味します。The error means that azds.exe is not in the PATH environment variable, as seen in VS Code.

PATH 環境変数が正しく設定されているコマンド プロンプトから VS Code を起動してみてください。Try launching VS Code from a command prompt where the PATH environment variable is set properly.

エラー "Required tools to build and debug 'projectname' are out of date." ('projectname' をビルドおよびデバッグするために必要なツールの期限が切れています。)Error "Required tools to build and debug 'projectname' are out of date."

このエラーは、Azure Dev Spaces 用の VS Code 拡張機能のバージョンは新しいが、Azure Dev Spaces CLI のバージョンが古い場合に、Visual Studio Code に表示されます。You see this error in Visual Studio Code if you have a newer version of the VS Code extension for Azure Dev Spaces, but an older version of the Azure Dev Spaces CLI.

最新バージョンの Azure Dev Spaces CLI をダウンロードしてインストールしてみてください。Try downloading and installing the latest version of the Azure Dev Spaces CLI:

エラー:"Failed to find debugger extension for type:coreclr (type:coreclr のデバッガー拡張機能が見つかりませんでした)"Error: "Failed to find debugger extension for type:coreclr"

Visual Studio Code デバッガーを実行しているときに、このエラーが表示されることがあります。You may see this error when running the Visual Studio Code debugger. C# 用の VS Code 拡張機能が開発マシンにインストールされていない可能性があります。You might not have the VS Code extension for C# installed on your development machine. C# 拡張機能には、.NET Core (CoreCLR) 用のデバッグ サポートが含まれています。The C# extension includes debugging support for .NET Core (CoreCLR).

この問題を解決するには、C# 用 VS Code 拡張機能をインストールします。To fix this issue, install the VS Code extension for C#.

エラー "Configured debug type 'coreclr' is not supported (構成されているデバッグの種類 'coreclr' はサポートされていません)"Error "Configured debug type 'coreclr' is not supported"

Visual Studio Code デバッガーを実行しているときに、このエラーが表示されることがあります。You may see this error when running the Visual Studio Code debugger. Azure Dev Spaces 用の VS Code 拡張機能が開発マシンにインストールされていない可能性があります。You might not have the VS Code extension for Azure Dev Spaces installed on your development machine.

この問題を解決するには、Azure Dev Spaces 用の VS Code 拡張機能をインストールします。To fix this issue, install the VS Code extension for Azure Dev Spaces.

エラー "Invalid 'cwd' value '/src'.Error "Invalid 'cwd' value '/src'. The system cannot find the file specified." ('cwd' の値 '/src' が無効です。指定されたファイルがシステムに見つかりません。)The system cannot find the file specified." または "launch: program '/src/[path to project binary]' does not exist" (launch: program '/src/[プロジェクト バイナリのパス]' が存在しません)or "launch: program '/src/[path to project binary]' does not exist"

Visual Studio Code デバッガーを実行しているときに、このエラーが表示されることがあります。You may see this error when running the Visual Studio Code debugger. 既定では、VS Code 拡張機能はコンテナー上のプロジェクト用の作業ディレクトリとして src を使用します。By default, the VS Code extension uses src as the working directory for the project on the container. Dockerfile を更新して別の作業ディレクトリを指定した場合、このエラーが表示されることがあります。If you've updated your Dockerfile to specify a different working directory, you may see this error.

この問題を解決するには、プロジェクト フォルダーの .vscode サブディレクトリ下の launch.json ファイルを更新します。To fix this issue, update the launch.json file under the .vscode subdirectory of your project folder. プロジェクトの Dockerfile で定義されている WORKDIR と同じディレクトリを指すように、configurations->cwd ディレクティブを変更します。Change the configurations->cwd directive to point to the same directory as the WORKDIR defined in your project's Dockerfile. configurations->program ディレクティブも更新することが必要な場合もあります。You may also need to update the configurations->program directive as well.

エラー "The pipe program 'azds' exited unexpectedly with code 126. (パイプ プログラム 'azds' が、コード 126 により予期せず終了しました。)"Error "The pipe program 'azds' exited unexpectedly with code 126."

Visual Studio Code デバッガーを実行しているときに、このエラーが表示されることがあります。You may see this error when running the Visual Studio Code debugger.

この問題を解決するには、Visual Studio Code を閉じて、もう一度開きます。To fix this issue, close and reopen Visual Studio Code. デバッガーを再起動してください。Restart the debugger.

Node.js アプリケーションにデバッグを接続するとエラー "Internal watch failed: watch ENOSPC" が発生するError "Internal watch failed: watch ENOSPC" when attaching debugging to a Node.js application

デバッガーで接続しようとしている Node.js アプリケーションでポッドを実行しているノードが fs.inotify.max_user_watches 値を超えるとこのエラーが発生します。This error occurs when the node running the pod with the Node.js application you're trying to attach to with a debugger has exceeded the fs.inotify.max_user_watches value. 場合によっては、fs.inotify.max_user_watches の既定値が小さすぎて、デバッガーのポッドへの直接の接続を処理できない可能性がありますIn some cases, the default value of fs.inotify.max_user_watches may be too small to handle attaching a debugger directly to a pod.

この問題の一時的な対処法として、クラスター内の各ノード上で fs.inotify.max_user_watches の値を増やし、そのノードを再起動して変更を有効にしてください。A temporary workaround for this issue is to increase the value of fs.inotify.max_user_watches on each node in the cluster and restart that node for the changes to take effect.

その他の一般的な問題Other common issues

エラー "azds" が、内部または外部コマンド、操作可能プログラム、またはバッチ ファイルとして認識されませんError "azds" is not recognized as an internal or external command, operable program, or batch file

azds.exe がインストールされていないか、正しく構成されていない場合に、このエラーが発生することがあります。This error can happen if azds.exe is not installed or configured correctly.

この問題を解決するには、次の手順に従います。To fix this issue:

  1. %ProgramFiles%/Microsoft SDKs\Azure\Azure Dev Spaces CLI で azds.exe を探してください。Check the location %ProgramFiles%/Microsoft SDKs\Azure\Azure Dev Spaces CLI for azds.exe. 見つかった場合は、その場所を PATH 環境変数に追加します。If it's there, add that location to the PATH environment variable.

  2. azds.exe がインストールされていない場合は、次のコマンドを実行します。If azds.exe isn't installed, run the following command:

    az aks use-dev-spaces -n <cluster-name> -g <resource-group>

承認エラー "Microsoft.DevSpaces/register/action"Authorization error "Microsoft.DevSpaces/register/action"

Azure Dev Spaces を管理するには、お使いの Azure サブスクリプション内に "所有者" または "共同作成者" アクセス権が必要です。You need Owner or Contributor access in your Azure subscription to manage Azure Dev Spaces. Dev Spaces を管理しようとしたが、関連付けられている Azure サブスクリプションに "所有者" アクセス権も "共同作成者" アクセス権もない場合、承認エラーが表示されることがあります。If you're trying to manage Dev Spaces and you don't have Owner or Contributor access to the associated Azure subscription, you may see an authorization error. 次に例を示します。For example:

The client '<User email/Id>' with object id '<Guid>' does not have authorization to perform action 'Microsoft.DevSpaces/register/action' over scope '/subscriptions/<Subscription Id>'.

この問題を解決するには、Azure サブスクリプションの 所有者 または 共同作成者 のアクセス権を持つアカウントを使用して、Microsoft.DevSpaces 名前空間を手動で登録します。To fix this issue, using an account with Owner or Contributor access to the Azure subscription, manually register the Microsoft.DevSpaces namespace:

az provider register --namespace Microsoft.DevSpaces

新しいポッドが開始しないNew pods aren't starting

Kubernetes の初期化子は、クラスター内の cluster-admin ロールに対する Kubernetes RBAC 権限の変更により、新しいポッドに PodSpec を適用できません。The Kubernetes initializer can't apply the PodSpec for new pods due to Kubernetes RBAC permission changes to the cluster-admin role in the cluster. ポッドに関連付けられているサービス アカウントが存在しないなど、新しいポッドに無効な PodSpec が含まれている可能性もあります。The new pod may also have an invalid PodSpec, for example the service account associated with the pod no longer exists. 初期化子の問題により [保留中] の状態になっているポッドを確認するには、kubectl get pods コマンドを使用します。To see the pods that are in a Pending state due to the initializer issue, use the kubectl get pods command:

kubectl get pods --all-namespaces --include-uninitialized

この問題は、クラスター内の すべての名前空間 (Azure Dev Spaces が無効な名前空間を含む) のポッドに影響を与える可能性があります。This issue can impact pods in all namespaces in the cluster including namespaces where Azure Dev Spaces is not enabled.

この問題を解決するには、Dev Spaces CLI を最新バージョンに更新して、Azure Dev Spaces コントローラーから azds InitializerConfiguration を削除します。To fix this issue, update the Dev Spaces CLI to the latest version and then delete the azds InitializerConfiguration from the Azure Dev Spaces controller:

az aks get-credentials --resource-group <resource group name> --name <cluster name>
kubectl delete InitializerConfiguration azds

Azure Dev Spaces コントローラーから azds InitializerConfiguration を削除したら、kubectl delete を使用して [保留中] 状態のポッドをすべて削除します。Once you have removed the azds InitializerConfiguration from the Azure Dev Spaces controller, use kubectl delete to remove any pods in a Pending state. 保留中のポッドをすべて削除したら、ポッドを再デプロイします。After all pending pods have been removed, redeploy your pods.

再デプロイ後も新しいポッドが [保留中] 状態のままになっている場合は、kubectl delete を使用して [保留中] 状態のポッドをすべて削除してください。If new pods are still stuck in a Pending state after a redeployment, use kubectl delete to remove any pods in a Pending state. 保留中のポッドをすべて削除したら、コントローラーをクラスターから削除して再インストールします。After all pending pods have been removed, delete the controller from the cluster and reinstall it:

azds remove -g <resource group name> -n <cluster name>
azds controller create --name <cluster name> -g <resource group name> -tn <cluster name>

コントローラーを再インストールしたら、ポッドを再デプロイします。After your controller is reinstalled, redeploy your pods.

Dev Spaces コントローラーと API を呼び出すための Azure RBAC 権限が正しくないIncorrect Azure RBAC permissions for calling Dev Spaces controller and APIs

Azure Dev Spaces コントローラーにアクセスするユーザーは、AKS クラスター上の管理者用の kubeconfig を読み取るためのアクセス権を持っている必要があります。The user accessing the Azure Dev Spaces controller must have access to read the admin kubeconfig on the AKS cluster. たとえば、この権限は、組み込みの Azure Kubernetes Service クラスター管理者ロールで利用できます。For example, this permission is available in the built-in Azure Kubernetes Service Cluster Admin Role. また、Azure Dev Spaces コントローラーにアクセスするユーザーには、コントローラーの "共同作成者" または "所有者" の Azure ロールも設定されている必要があります。The user accessing the Azure Dev Spaces controller must also have the Contributor or Owner Azure role for the controller. AKS クラスターに対するユーザーの権限の更新に関する詳細は、こちらで確認できます。More details on updating a user's permissions for an AKS cluster are available here.

コントローラーに対するユーザーの Azure ロールを更新するには、次のことを行います。To update the user's Azure role for the controller:

  1. Azure Portal ( ) にサインインします。Sign in to the Azure portal at
  2. コントローラーを含むリソース グループに移動します。これは通常、お使いの AKS クラスターと同じです。Navigate to the Resource Group containing the controller, which is usually the same as your AKS cluster.
  3. [非表示の型の表示] チェック ボックスをオンにします。Enable the Show hidden types checkbox.
  4. コントローラーをクリックします。Click on the controller.
  5. [アクセス制御] (IAM) ウィンドウを開きます。Open the Access Control (IAM) pane.
  6. [ロールの割り当て] タブをクリックします。Click on the Role Assignments tab.
  7. [追加] をクリックして、 [ロールの割り当ての追加] をクリックします。Click Add then Add role assignment.
    • [ロール] で、 [共同作成者] または [所有者] を選択します。For Role, select either Contributor or Owner.
    • [アクセスの割り当て先][Azure AD のユーザー、グループ、サービス プリンシパル] を選択します。For Assign access to, select Azure AD user, group, or service principal.
    • [選択] で、権限を付与するユーザーを検索します。For Select, search for the user you want to give permissions.
  8. [保存] をクリックします。Click Save.

Dev Spaces サービスに関連付けられたパブリック URL で DNS の名前解決が失敗します。DNS name resolution fails for a public URL associated with a Dev Spaces service

azds prep コマンドで --enable-ingress スイッチを指定するか、Visual Studio で Publicly Accessible チェック ボックスをオンにすることで、サービスのパブリック URL エンドポイントを構成できます。You can configure a public URL endpoint for your service by specifying the --enable-ingress switch to the azds prep command, or by selecting the Publicly Accessible checkbox in Visual Studio. Dev Spaces でサービスを実行すると、パブリック DNS 名が自動的に登録されます。The public DNS name is automatically registered when you run your service in Dev Spaces. この DNS 名が登録されていない場合は、パブリック URL に接続するときに、Web ブラウザーに "Page cannot be displayed (ページを表示できません) " または "Site cannot be reached (サイトに到達できません) " エラーが表示されます。If this DNS name is not registered, you see a Page cannot be displayed or Site cannot be reached error in your web browser when connecting to the public URL.

この問題を解決するには、次の手順に従います。To fix this issue:

  • お使いの Dev Spaces サービスに関連付けられたすべての URL の状態をチェックします。Check the status of all URLs associated with your Dev Spaces services:

    azds list-uris
  • URL が "保留中" の状態にある場合、まだ Dev Spaces が DNS の登録が完了するのを待っている状態です。If a URL is in the Pending state, Dev Spaces is still waiting for DNS registration to complete. 登録が完了するまでに数分かかることがあります。Sometimes, it takes a few minutes for registration to complete. また、Dev Spaces は各サービスの localhost トンネルを開き、これを DNS の登録を待っている間に使用できます。Dev Spaces also opens a localhost tunnel for each service, which you can use while waiting on DNS registration.

  • URL の "保留中" 状態が 5 分を超える場合、パブリック エンドポイントを作成する外部 DNS ポッド、またはパブリック エンドポイントを取得する nginx イングレス コントローラー ポッドに問題がある可能性があります。If a URL stays in the Pending state for more than 5 minutes, it may indicate a problem with the external DNS pod that creates the public endpoint or the nginx ingress controller pod that acquires the public endpoint. 次のコマンドを使用して、それらのポッドを削除し、AKS で自動的に再作成してください。Use the following commands to delete these pods and allow AKS to automatically recreate them:

    kubectl delete pod -n kube-system -l app=addon-http-application-routing-external-dns
    kubectl delete pod -n kube-system -l app=addon-http-application-routing-nginx-ingress

エラー "upstream connect error or disconnect/reset before headers (ヘッダーの前にアップストリームの接続エラーあるいは切断またはリセットが発生しました)"Error "upstream connect error or disconnect/reset before headers"

このエラーは、サービスへのアクセスを試みたときに発生する場合があります。You may see this error when trying to access your service. たとえば、ブラウザーでサービスの URL にアクセスしたときです。For example, when you go to the service's URL in a browser. このエラーは、コンテナーのポートが使用できないことを意味します。This error means the container port isn't available. その理由としては次のことが考えられます。This can for the follow reasons:

  • コンテナーがまだビルドとデプロイの処理中です。The container is still in the process of being built and deployed. azds up を実行またはデバッガーを起動した後、コンテナーが正常にデプロイされる前にコンテナーにアクセスしようとした場合、この問題が発生する可能性があります。This issue can arise if you run azds up or start the debugger, and then try to access the container before it has successfully deployed.
  • Dockerfile、Helm チャート、およびポートを開くサーバー コード間でポート構成が整合していません。Port configuration is not consistent across your Dockerfile, Helm Chart, and any server code that opens up a port.

この問題を解決するには、次の手順に従います。To fix this issue:

  1. コンテナーがビルド/デプロイ処理中の場合、2 ~ 3 秒待ってからサービスへのアクセスを再試行できます。If the container is in the process of being built/deployed, you can wait 2-3 seconds and try accessing the service again.
  2. 次の資産のポート構成を確認します。Check your port configuration in following assets:
    • Helm チャート: azds prep コマンドでの values.yaml scaffolded 内に service.portdeployment.containerPort によって指定されています。Helm chart: Specified by the service.port and deployment.containerPort in values.yaml scaffolded by azds prep command.
    • Node.js などのアプリケーション コードで開かれているポートがあります: var server = app.listen(80, function () {...}Any ports being opened up in application code, for example in Node.js: var server = app.listen(80, function () {...}

型または名前空間名 "MyLibrary" が見つかりませんでしたThe type or namespace name "MyLibrary" couldn't be found

ご使用のライブラリ プロジェクトが見つかりません。A library project you're using can't be found. Dev Spaces では、ビルド コンテキストが既定でプロジェクトまたはサービス レベルになっています。With Dev Spaces, the build context is at the project/service level by default.

この問題を解決するには、次の手順に従います。To fix this issue:

  1. azds.yaml ファイルを変更して、ビルド コンテキストをソリューション レベルに設定します。Modify the azds.yaml file to set the build context to the solution level.
  2. Dockerfile および Dockerfile.develop ファイルを変更して、新しいビルド コンテキストからの相対位置でプロジェクト (.csproj など) ファイルを正しく参照します。Modify the Dockerfile and Dockerfile.develop files to refer to the project files, for example .csproj, correctly relative to the new build context.
  3. .sln ファイルと同じディレクトリに .dockerignore を追加します。Add a .dockerignore in the same directory as the .sln file.
  4. 必要に応じて追加のエントリで .dockerignore を更新します。Update the .dockerignore with additional entries as needed.

こちらに例があります。You can find an example at here.

開発スペースでポッドの水平オートスケール機能が動作しないHorizontal pod autoscaling not working in a dev space

開発スペースでサービスを実行すると、そのサービスのポッドがインストルメンテーション用の追加のコンテナーと共に挿入されます。また、ポッド内のすべてのコンテナーでは、ポッドの水平オートスケール機能に対してリソース制限と要求を設定する必要があります。When you run a service in a dev space, that service's pod is injected with additional containers for instrumentation and all the containers in a pod need to have resource limits and requests set for Horizontal Pod Autoscaling.

この問題を解決するには、挿入された Dev Spaces コンテナーにリソースの要求と制限を適用します。To fix this issue, apply a resource request and limit to the injected Dev Spaces containers. ポッド仕様に 注釈を追加することで、挿入されたコンテナー (devspaces-proxy) にリソースの要求と制限を適用できます。この値は、プロキシのコンテナー仕様の resources セクションを表す JSON オブジェクトに設定する必要があります。Resource requests and limits can be applied for the injected container (devspaces-proxy) by adding the annotation to your pod spec. The value should be set to a JSON object representing the resources section of the container spec for the proxy.

ポッド仕様に適用される proxy-resources 注釈の例を次に示します。Below is an example of a proxy-resources annotation that is to be applied to your pod spec. "{\"Limits\": {\"cpu\": \"300m\",\"memory\": \"400Mi\"},\"Requests\": {\"cpu\": \"150m\",\"memory\": \"200Mi\"}}"

ポッドが実行されている既存の名前空間で Azure Dev Spaces を有効にするEnable Azure Dev Spaces on an existing namespace with running pods

既存の AKS クラスターとポッドが実行されている名前空間で Azure Dev Spaces を有効にしたい場合があります。You may have an existing AKS cluster and namespace with running pods where you want to enable Azure Dev Spaces.

AKS クラスター内の既存の名前空間で Azure Dev Spaces を有効にするには、use-dev-spaces を実行し、kubectl を使用して、その名前空間内のすべてのポッドを再起動します。To enable Azure Dev Spaces on an existing namespace in an AKS cluster, run use-dev-spaces and use kubectl to restart all pods in that namespace.

az aks get-credentials --resource-group MyResourceGroup --name MyAKS
az aks use-dev-spaces -g MyResourceGroup -n MyAKS --space my-namespace --yes
kubectl -n my-namespace delete pod --all

ポッドの再起動後、Azure Dev Spaces で既存の名前空間を使用できるようになります。After your pods have restarted, you can begin using your existing namespace with Azure Dev Spaces.

クラスター ノードのエグレス トラフィックが制限されている AKS クラスターで Azure Dev Spaces を有効にするEnable Azure Dev Spaces on AKS cluster with restricted egress traffic for cluster nodes

クラスターノードからのエグレス トラフィックが制限されている AKS クラスターで Azure Dev Spaces を有効にするには、次の FQDN を許可する必要があります。To enable Azure Dev Spaces on an AKS cluster for which the egress traffic from cluster nodes is restricted, you will have to allow following FQDNs:

FQDNFQDN PortPort 用途Use HTTPS: 443HTTPS:443 Linux Alpine とその他の Azure Dev Spaces イメージをプルしますTo pull linux alpine and other Azure Dev Spaces images HTTP:443HTTP:443 helm/tiller イメージをプルしますTo pull helm/tiller images HTTP:443HTTP:443 helm/tiller イメージをプルしますTo pull helm/tiller images

上のすべての FQDN と Azure Dev Spaces インフラストラクチャ サービスとの間のネットワーク トラフィックを許可するようにファイアウォールまたはセキュリティ構成を更新してください。Update your firewall or security configuration to allow network traffic to and from the all of the above FQDNs and Azure Dev Spaces infrastructure services.

エラー "Could not find the cluster <cluster> in subscription <subscriptionId>" (サブスクリプション subscriptionId にクラスター cluster が見つかりませんでした)Error "Could not find the cluster <cluster> in subscription <subscriptionId>"

kubeconfig ファイルが、Azure Dev Spaces クライアント側ツールで使用しようとしているものとは異なるクラスターまたはサブスクリプションを対象としている場合に、このエラーが表示されることがあります。You may see this error if your kubeconfig file is targeting a different cluster or subscription than you are trying to use with the Azure Dev Spaces client side tooling. Azure Dev Spaces クライアント側ツールは、kubectl の動作をレプリケートし、1 つ以上の kubeconfig ファイルを使用して、クラスターを選択して通信します。The Azure Dev Spaces client side tooling replicates the behavior of kubectl, which uses one or more kubeconfig files to select and communicate with the cluster.

この問題を解決するには、次の手順に従います。To fix this issue:

  • az aks use-dev-spaces -g <resource group name> -n <cluster name> を使用して、現在のコンテキストを更新します。Use az aks use-dev-spaces -g <resource group name> -n <cluster name> to update the current context. このコマンドによって、AKS クラスターで Azure Dev Spaces も有効になります (まだ有効になっていない場合)。This command also enables Azure Dev Spaces on your AKS cluster if is not already enabled. または、kubectl config use-context <cluster name> を使用して現在のコンテキストを更新することもできます。Alternatively, you can use kubectl config use-context <cluster name> to update the current context.
  • az account show を使用して、対象となっている現在の Azure サブスクリプションを表示し、これが正しいことを確認します。Use az account show to show the current Azure subscription you are targeting and verify this is correct. az account set を使用して、対象とするサブスクリプションを変更できます。You can change the subscription you are targeting using az account set.

AKS 証明書のローテーション後に Dev Spaces を使用するエラーError using Dev Spaces after rotating AKS certificates

AKS クラスターで証明書をローテーションした後に、azds space listazds up などの特定の操作が失敗します。After rotating the certificates in your AKS cluster, certain operations, such as azds space list and azds up will fail. また、クラスター上で証明書をローテーションした後に、Azure Dev Spaces コントローラー上で証明書を更新する必要があります。You also need to refresh the certificates on your Azure Dev Spaces controller after rotating the certificates on your cluster.

この問題を解決するには、az aks get-credentials を使用して kubeconfig に更新された証明書がある状態を確保してから、azds controller refresh-credentials コマンドを実行します。To fix this issue, ensure your kubeconfig has the updated certificates using az aks get-credentials then run the azds controller refresh-credentials command. 次に例を示します。For example:

az aks get-credentials -g <resource group name> -n <cluster name>
azds controller refresh-credentials -g <resource group name> -n <cluster name>