Azure Dev Spaces のしくみと構成方法How Azure Dev Spaces works and is configured

Kubernetes アプリケーションの開発には課題が生じる可能性があります。Developing a Kubernetes application can be challenging. Docker と Kubernetes の構成ファイルが必要です。You need Docker and Kubernetes configuration files. アプリケーションをローカルでテストし、その他の依存サービスとやり取りする方法を理解する必要があります。You need to figure out how to test your application locally and interact with other dependent services. 開発者のチームを採用して、開発とテストを複数のサービスで同時に処理しなければならない場合があります。You might need to handle developing and testing on multiple services at once and with a team of developers.

Azure Dev Spaces を使用すると、Kubernetes アプリケーションを Azure Kubernetes Service (AKS) で直接開発、デプロイ、およびデバッグできます。Azure Dev Spaces helps you develop, deploy, and debug Kubernetes applications directly in Azure Kubernetes Service (AKS). また、Azure Dev Spaces を使用して開発スペースをチームで共有することもできます。Azure Dev Spaces also allows a team to share a dev space. 開発スペースをチームで共有すると、個々のチーム メンバーが単独で開発を行うことができます。クラスター内の依存関係やその他のアプリケーションのレプリケートまたはモックアップは必要ありません。Sharing a dev space across a team allows individual team members to develop in isolation without having to replicate or mock up dependencies or other applications in the cluster.

Azure Dev Spaces では、AKS で Kubernetes アプリケーションをデプロイ、実行、およびデバッグするための構成ファイルを作成して使用します。Azure Dev Spaces creates and uses a configuration file for deploying, running, and debugging your Kubernetes applications in AKS. この構成ファイルはアプリケーションのコードと共に存在し、バージョン コントロール システムに追加することができます。This configuration file resides with your application's code and can be added to your version control system.

この記事では、Azure Dev Spaces の使用を開始するためのプロセスおよび Azure Dev Spaces 構成ファイルでのそれらのプロセスの構成方法について説明します。This article describes the processes that power Azure Dev Spaces and how those processes are configured in the Azure Dev Spaces configuration file. Azure Dev Spaces を迅速に実行して実際に確認するために、次に示すいずれかのクイック スタートを実行してください。To get Azure Dev Spaces running quickly and see it in practice, complete one of the quickstarts:

Azure Dev Spaces のしくみHow Azure Dev Spaces works

Azure Dev Spaces では 2 つの異なるコンポーネント (コントローラーとクライアント側ツール) をユーザーが操作します。Azure Dev Spaces has two distinct components that you interact with: the controller and the client-side tooling.

Azure Dev Spaces のコンポーネント

コントローラーでは次のアクションが実行されます。The controller performs the following actions:

  • 開発スペースの作成と選択を管理する。Manages dev space creation and selection.
  • アプリケーションの Helm チャートをインストールし、Kubernetes オブジェクトを作成する。Installs your application's Helm chart and creates Kubernetes objects.
  • アプリケーションのコンテナー イメージをビルドする。Builds your application's container image.
  • アプリケーションを AKS にデプロイする。Deploys your application to AKS.
  • インクリメンタル ビルドを行い、ソース コードが変更されたら再起動する。Does incremental builds and restarts when your source code changes.
  • ログと HTTP トレースを管理する。Manages logs and HTTP traces.
  • stdout と stderr をクライアント側ツールに転送する。Forwards stdout and stderr to the client-side tooling.
  • 親開発スペースから派生した子開発スペースの作成をチーム メンバーに許可する。Allows team members to create child dev spaces derived from a parent dev space.
  • スペース内および親スペースと子スペースにまたがるアプリケーションのルーティングを構成する。Configures routing for applications within a space as well as across parent and child spaces.

コントローラーは AKS の外部に存在します。The controller resides outside AKS. これは、クライアント側ツールと AKS クラスター間の動作と通信を管理します。It drives the behavior and communication between the client-side tooling and the AKS cluster. クラスターで Azure Dev Spaces を使用するための準備を行う際に、Azure CLI を使用してコントローラーを有効にします。The controller is enabled using the Azure CLI when you prepare your cluster to use Azure Dev Spaces. クライアント側ツールを使用すると、有効したコントローラーを操作できます。Once it is enabled, you can interact with it using the client-side tooling.

ユーザーはクライアント側ツールを使用して次の操作を行うことができます。The client-side tooling allows the user to:

  • アプリケーション用の Dockerfile、Helm チャート、および Azure Dev Spaces 構成ファイルを生成する。Generate a Dockerfile, Helm chart, and Azure Dev Spaces configuration file for the application.
  • 親開発スペースと子開発スペースを作成する。Create parent and child dev spaces.
  • アプリケーションをビルドして起動するようコントローラーに通知する。Tell the controller to build and start your application.

クライアント側ツールでは、アプリケーションの実行中に次の操作を行うこともできます。While your application is running, the client-side tooling also:

  • AKS で実行されているアプリケーションから stdout と stderr を受信して表示する。Receives and displays stdout and stderr from your application running in AKS.
  • port-forward を使用して、http://localhost によるアプリケーションへの Web アクセスを許可する。Uses port-forward to allow web access to your application using http://localhost.
  • AKS で実行中のアプリケーションにデバッガーをアタッチする。Attaches a debugger to your running application in AKS.
  • インクリメンタル ビルドに対する変更が検出された場合に、ソース コードを開発スペースと同期して、迅速なイテレーションを可能にする。Syncs source code to your dev space when a change is detected for incremental builds, allowing for rapid iteration.

コマンド ラインから azds コマンドの一部としてクライアント側ツールを使用することができます。You can use the client-side tooling from the command line as part of the azds command. クライアント側ツールを以下のものと共に使用することもできます。You can also use the client-side tooling with:

Azure Dev Spaces の設定と使用の基本的なフローは次のとおりです。Here's the basic flow for setting up and using Azure Dev Spaces:

  1. Azure Dev Spaces 用に AKS クラスターを準備するPrepare your AKS cluster for Azure Dev Spaces
  2. Azure Dev Spaces で実行するためのコードを準備するPrepare your code for running on Azure Dev Spaces
  3. 開発スペースでコードを実行するRun your code on a dev space
  4. 開発スペースでコードをデバッグするDebug your code on a dev space
  5. 開発スペースを共有するShare a dev space

以降の各セクションでは、Azure Dev Spaces のしくみについて詳しく説明します。We'll cover more details of how Azure Dev Spaces works in each of the below sections.

AKS クラスターを準備するPrepare your AKS cluster

AKS クラスターの準備には以下が含まれます。Preparing your AKS cluster involves:

  • AKS クラスターが Azure Dev Spaces でサポートされているリージョン内にあることを確認する。Verifying your AKS cluster is in a region supported by Azure Dev Spaces.
  • Kubernetes 1.10.3 以降が実行されていることを確認する。Verifying you are running Kubernetes 1.10.3 or later.
  • az aks use-dev-spaces を使用して Azure Dev Spaces をクラスターで有効にする。Enabling Azure Dev Spaces on your cluster using az aks use-dev-spaces

Azure Dev Spaces 用の AKS クラスターを作成して構成する方法の詳細については、次に示すいずれかのファースト ステップ ガイドを参照してください。For more information on how to create and configure an AKS cluster for Azure Dev Spaces, see one of the getting started guides:

AKS クラスターで Azure Dev Spaces を有効にすると、クラスター用のコントローラーがインストールされます。When Azure Dev Spaces is enabled on your AKS cluster, it installs the controller for your cluster. このコントローラーは、クラスターの外部にある個別の Azure リソースであり、クラスター内のリソースに対して次のことを行います。The controller is a separate Azure resource outside of your cluster and does the following to resources in your cluster:

  • 開発スペースとして使用する Kubernetes 名前空間を作成または指定する。Creates or designates a Kubernetes namespace to use as a dev space.
  • azds という名前の Kubernetes 名前空間が存在する場合は、それを削除し、新しい名前空間を作成する。Removes any Kubernetes namespace named azds, if it exists, and creates a new one.
  • Kubernetes webhook の構成をデプロイします。Deploys a Kubernetes webhook configuration.
  • webhook 受付サーバーをデプロイします。Deploys a webhook admission server.

また、AKS クラスターが他の Azure Dev Spaces コンポーネントにサービスの呼び出しを行うために使用するものと同じサービス プリンシパルも使用します。It also uses the same service principal that your AKS cluster uses to make service calls to other Azure Dev Spaces components.

Azure Dev Spaces がクラスターを準備する

Azure Dev Spaces を使用するには、開発スペースが少なくとも 1 つ必要です。In order to use Azure Dev Spaces, there must be at least one dev space. Azure Dev Spaces では、AKS クラスター内の Kubernetes 名前空間を開発スペースとして使用します。Azure Dev Spaces uses Kubernetes namespaces within your AKS cluster for dev spaces. コントローラーのインストール時には、最初の開発スペースとして使用する新しい Kubernetes 名前空間の作成または既存の名前空間の選択を求められます。When a controller is being installed, it prompts you to create a new Kubernetes namespace or choose an existing namespace to use as your first dev space. 名前空間が開発スペースとして指定されると、コントローラーでは azds.io/space=true ラベルをその名前空間に追加し、開発スペースとして認定します。When a namespace is designated as a dev space, the controller adds the azds.io/space=true label to that namespace to identify it as a dev space. 作成または指定する最初の開発スペースは、クラスターの準備が完了した後に既定で選択されます。The initial dev space you create or designate is selected by default after you prepare your cluster. 選択されたスペースは、Azure Dev Spaces で新しいワークロードを作成するために使用されます。When a space is selected, it is used by Azure Dev Spaces for creating new workloads.

既定では、コントローラーが既存の default Kubernetes 名前空間をアップグレードして、default という名前の開発スペースを作成します。By default, the controller creates a dev space named default by upgrading the existing default Kubernetes namespace. クライアント側ツールを使用すると、新しい開発スペースを作成して既存の開発スペースを削除できます。You can use the client-side tooling to create new dev spaces and remove existing dev spaces. Kubernetes における制限があるため、default 開発スペースを削除することはできません。Due to a limitation in Kubernetes, the default dev space cannot be removed. また、コントローラーでは、azds という名前の既存の Kubernetes 名前空間を削除して、クライアント側ツールで使用される azds コマンドとの競合を回避します。The controller also removes any existing Kubernetes namespaces named azds to avoid conflicts with the azds command used by the client-side tooling.

Kubernetes webhook 受付サーバーは、インストルメンテーション用のデプロイ時に 3 つのコンテナー (devspaces-proxy コンテナー、devspaces-proxy-init コンテナー、devspaces-build コンテナー) をポッドに挿入するために使用します。The Kubernetes webhook admission server is used to inject pods with three containers during deployment for instrumentation: a devspaces-proxy container, a devspaces-proxy-init container, and a devspaces-build container. これらの 3 つのコンテナーはすべて、AKS クラスターでルート アクセスを使用して実行されます。All three of these containers run with root access on your AKS cluster. また、AKS クラスターが他の Azure Dev Spaces コンポーネントにサービスの呼び出しを行うために使用するものと同じサービス プリンシパルも使用します。They also use the same service principal that your AKS cluster uses to make service calls to other Azure Dev Spaces components.

Azure Dev Spaces Kubernetes webhook 受付サーバー

devspaces-proxy コンテナーは、アプリケーション コンテナーに出入りするすべての TCP トラフィックを処理し、ルーティングの実行に役立つサイドカー コンテナーです。The devspaces-proxy container is a sidecar container that handles all TCP traffic into and out of the application container and helps perform routing. devspaces-proxy コンテナーでは、特定のスペースが使用されている場合に HTTP メッセージを再ルーティングします。The devspaces-proxy container reroutes HTTP messages if certain spaces are being used. たとえば、親スペースと子スペースのアプリケーション間で HTTP メッセージをルーティングできます。For example, it can help route HTTP messages between applications in parent and child spaces. HTTP 以外のすべてのトラフィックは、未変更の状態で devspaces-proxy を通過します。All non-HTTP traffic passes through devspaces-proxy unmodified. また、devspaces-proxy container コンテナーでは、受信と送信の HTTP メッセージをすべてログに記録し、クライアント側ツールにそれらをトレースとして送信します。The devspaces-proxy container also logs all inbound and outbound HTTP messages and sends them to the client-side tooling as traces. これらのトレースは、アプリケーションの動作を調べるために開発者が表示できます。These traces can then be viewed by the developer to inspect the behavior of the application.

devspaces-proxy-init コンテナーは、アプリケーションのコンテナーに対するスペースの階層に基づいてルーティング規則を追加する初期化コンテナーです。The devspaces-proxy-init container is an init container that adds additional routing rules based on the space hierarchy to your application's container. 起動の前にアプリケーションのコンテナーの /etc/resolv.conf ファイルと iptables 構成を更新することでルーティング規則が追加されます。It adds routing rules by updating the application container's /etc/resolv.conf file and iptables configuration before it starts. /etc/resolv.conf に対する更新によって、親スペースにおけるサービスの DNS 解決が可能になります。The updates to /etc/resolv.conf allow for DNS resolution of services in parent spaces. iptables 構成の更新によって、アプリケーションのコンテナーに出入りするすべての TCP トラフィックが devspaces-proxy を経由するようになります。The iptables configuration updates ensure all TCP traffic into and out of the application's container are routed though devspaces-proxy. devspaces-proxy-init からのすべての更新は、Kubernetes で追加される規則に加えて発生します。All updates from devspaces-proxy-init happen in addition to the rules that Kubernetes adds.

devspaces-build コンテナーは初期化コンテナーであり、プロジェクトのソース コードと Docker ソケットがマウントされています。The devspaces-build container is an init container and has the project source code and Docker socket mounted. プロジェクトのソース コードと Docker へのアクセスによって、アプリケーション コンテナーをポッドから直接ビルドできます。The project source code and access to Docker allows the application container to be built directly by the pod.

注意

Azure Dev Spaces では、同じノードを使用して、アプリケーションのコンテナーをビルドおよび実行します。Azure Dev Spaces uses the same node to build your application's container and run it. そのため、Azure Dev Spaces には、アプリケーションをビルドして実行するための外部のコンテナー レジストリが必要ありません。As a result, Azure Dev Spaces does not need an external container registry for building and running your application.

Kubernetes webhook 受付サーバーは AKS クラスターで作成された新しいポッドをリッスンします。The Kubernetes webhook admission server listens for any new pod that's created in the AKS cluster. azds.io/space=true ラベル付きの名前空間にそのポッドがデプロイされる場合は、コンテナーを追加してポッドが挿入されます。If that pod is deployed to any namespace with the azds.io/space=true label, it injects that pod with the additional containers. devspaces-build コンテナーが挿入されるのは、アプリケーションのコンテナーがクライアント側ツールを使用して実行される場合のみです。The devspaces-build container is only injected if the application's container is run using the client-side tooling.

AKS クラスターの準備が完了したら、クライアント側ツールを使用して、開発スペースでコードを準備および実行できます。Once you have prepared your AKS cluster, you can use the client-side tooling to prepare and run your code in your dev space.

コードを準備するPrepare your code

開発スペースでアプリケーションを実行するには、アプリケーションをコンテナー化する必要があります。また、アプリケーションを Kubernetes にデプロイする方法を定義する必要があります。In order to run your application in a dev space, it needs to be containerized, and you need to define how it should be deployed to Kubernetes. アプリケーションをコンテナー化するには、Dockerfile が必要です。To containerize your application, you need a Dockerfile. アプリケーションを Kubernetes にデプロイする方法を定義するには、Helm チャートが必要です。To define how your application is deployed to Kubernetes, you need a Helm chart. アプリケーション用の Dockerfile と Helm チャートの作成を支援するため、クライアント側ツールには prep コマンドが用意されています。To assist in creating both the Dockerfile and Helm chart for your application, the client-side tools provide the prep command:

azds prep --public

prep コマンドは、プロジェクト内のファイルを確認して、アプリケーションを Kubernetes で実行するための Dockerfile と Helm チャートの作成を試行します。The prep command will look at the files in your project and try to create the Dockerfile and Helm chart for running your application in Kubernetes. 現時点では、prep コマンドは次の言語で Dockerfile と Helm チャートを生成します。Currently, the prep command will generate a Dockerfile and Helm chart with the following languages:

  • JavaJava
  • Node.jsNode.js
  • .NET Core.NET Core

ソース コードを含むディレクトリから prep コマンドを実行する "必要があります"。You must run the prep command from a directory that contains source code. 正しいディレクトリから prep コマンドを実行すると、クライアント側ツールで言語を識別し、アプリケーションのコンテナー化に適した Dockerfile を作成できます。Running the prep command from the correct directory allows the client-side tooling to identify the language and create an appropriate Dockerfile to containerize your application. Java プロジェクト用の pom.xml ファイルを含むディレクトリから prep コマンドを実行することもできます。You can also run the prep command from a directory that contains a pom.xml file for Java projects.

ソース コードが含まれないディレクトリから prep コマンドを実行すると、クライアント側ツールでは Dockerfile が生成されません。If you run the prep command from directory that does not contain source code, the client-side tooling will not generate a Dockerfile. また、次のようなエラーが表示されます。"Dockerfile could not be generated due to unsupported language(サポートされていない言語が原因で Dockerfile を生成できませんでした) "。It will also display an error saying: Dockerfile could not be generated due to unsupported language. このエラーは、クライアント側ツールでプロジェクト タイプが認識されない場合にも発生します。This error also occurs if the client-side tooling does not recognize the project type.

prep コマンドの実行時には、--public フラグを指定することができます。When you run the prep command, you have the option of specifying the --public flag. このフラグは、インターネットにアクセス可能なエンドポイントをこのサービス用に作成するようコントローラーに指示します。This flag tells the controller to create an internet-accessible endpoint for this service. このフラグを指定しない場合は、クラスター内から、またはクライアント側ツールで作成された localhost トンネルを使用してサービスにアクセスする必要があります。If you do not specify this flag, the service is only accessible from within the cluster or using the localhost tunnel created by the client-side tooling. 生成された Helm チャートを更新することで、prep コマンドの実行後にこの動作を有効または無効にすることができます。You can enable or disable this behavior after running the prep command by updating the generated Helm chart.

prep コマンドでは、プロジェクト内の既存の Dockerfile または Helm チャートが置き換えられません。The prep command will not replace any existing Dockerfiles or Helm charts you have in your project. 既存の Dockerfile または Helm チャートにおいて prep コマンドで生成されたファイルと同じ名前付け規則が使用される場合、prep コマンドはこれらのファイルの生成をスキップします。If an existing Dockerfile or Helm chart uses the same naming convention as the files generated by the prep command, the prep command will skip generating those files. それ以外の場合、prep コマンドは独自の Dockerfile または Helm チャートを既存のファイルと並行して生成します。Otherwise, the prep command will generate its own Dockerfile or Helm chart along side the existing files.

また、prep コマンドではプロジェクトのルートに azds.yaml ファイルも生成されます。The prep command will also generate a azds.yaml file at the root of your project. Azure Dev Spaces では、このファイルを使用してアプリケーションをビルド、インストール、構成、および実行します。Azure Dev Spaces uses this file to build, install, configure, and run your application. この構成ファイルでは、Dockerfile と Helm チャートの場所が示されており、それらの成果物に加えて追加の構成も提供されます。This configuration file lists the location of your Dockerfile and Helm chart and also provides additional configuration on top of those artifacts.

.NET Core サンプル アプリケーションを使用して作成する azds.yaml ファイルの例を次に示します。Here is an example azds.yaml file created using .NET Core sample application:

kind: helm-release
apiVersion: 1.1
build:
  context: .
  dockerfile: Dockerfile
install:
  chart: charts/webfrontend
  values:
  - values.dev.yaml?
  - secrets.dev.yaml?
  set:
    replicaCount: 1
    image:
      repository: webfrontend
      tag: $(tag)
      pullPolicy: Never
    ingress:
      annotations:
        kubernetes.io/ingress.class: traefik-azds
      hosts:
        # This expands to [space.s.][rootSpace.]webfrontend.<random suffix>.<region>.azds.io
        # Customize the public URL by changing the 'webfrontend' text between the $(rootSpacePrefix) and $(hostSuffix) tokens
        # For more information see https://aka.ms/devspaces/routing
        - $(spacePrefix)$(rootSpacePrefix)webfrontend$(hostSuffix)
configurations:
  develop:
    build:
      dockerfile: Dockerfile.develop
      useGitIgnore: true
      args:
        BUILD_CONFIGURATION: ${BUILD_CONFIGURATION:-Debug}
    container:
      sync:
      - "**/Pages/**"
      - "**/Views/**"
      - "**/wwwroot/**"
      - "!**/*.{sln,csproj}"
      command: [dotnet, run, --no-restore, --no-build, --no-launch-profile, -c, "${BUILD_CONFIGURATION:-Debug}"]
      iterate:
        processesToKill: [dotnet, vsdbg]
        buildCommands:
        - [dotnet, build, --no-restore, -c, "${BUILD_CONFIGURATION:-Debug}"]

prep コマンドで生成される azds.yaml ファイルは、シンプルな単一のプロジェクト開発シナリオに適しています。The azds.yaml file generated by the prep command should work fine for a simple, single project development scenario. 特定のプロジェクトの複雑さが増大した場合は、prep コマンドの実行後にこのファイルの更新が必要になる可能性があります。If your specific project has increased complexity, you may need to update this file after running the prep command. たとえば、開発やデバッグのニーズに基づいて、プロジェクトでビルド プロセスや起動プロセスを調整しなければならない場合などです。For example, your project may require some tweaking to your build or launch process based on your development or debugging needs. また、複数のビルド プロセスまたは別のビルド コンテンツが必要な複数のアプリケーションがプロジェクトに存在する場合などです。You also might have multiple applications in your project, which require multiple build processes or a different build content.

コードを実行するRun your code

開発スペースでコードを実行するには、azds.yaml ファイルと同じディレクトリで up コマンドを実行します。To run your code in a dev space, issue the up command in the same directory as your azds.yaml file:

azds up

up コマンドでは、プロジェクトのビルドと実行に必要なアプリケーションのソース ファイルとその他の成果物が開発スペースにアップロードされます。The up command uploads your application source files and other artifacts needed to build and run your project to the dev space. 開発スペース内のコントローラーは次の処理を実行します。From there, the controller in your dev space:

  1. アプリケーションにデプロイする Kubernetes オブジェクトを作成する。Creates the Kubernetes objects to deploy your application.
  2. アプリケーション用のコンテナーをビルドする。Builds the container for your application.
  3. アプリケーションを開発スペースにデプロイする。Deploys your application to the dev space.
  4. アプリケーション エンドポイント (構成済みの場合) 用に、パブリックにアクセス可能な DNS 名を作成する。Creates a publicly accessible DNS name for your application endpoint if configured.
  5. port-forward を使用して、 http://localhost によるアプリケーション エンドポイントへのアクセスを提供する。Uses port-forward to provide access to your application endpoint using http://localhost.
  6. stdout と stderr をクライアント側ツールに転送する。Forwards stdout and stderr to the client-side tooling.

サービスを開始するStarting a service

開発スペースでサービスを開始する場合は、クライアント側ツールとコントローラーが連携して、ソース ファイルを同期し、コンテナーと Kubernetes オブジェクトを作成し、アプリケーションを実行します。When you start a service in a dev space, the client-side tooling and controller work in coordination to synchronize your source files, create your container and Kubernetes objects, and run your application.

より詳細なレベルでは、azds up の実行時には次の処理が行われます。At a more granular level, here is what happens when you run azds up:

  1. ユーザーのコンピューターから、ユーザーの AKS クラスターに固有の Azure ファイル ストレージにファイルが同期されます。Files are synchronized from the user’s machine to an Azure file storage that is unique to the user’s AKS cluster. ソース コード、Helm チャート、および構成ファイルがアップロードされます。The source code, Helm chart, and configuration files are uploaded. 同期プロセスの詳細については、次のセクションで説明します。More details on the synchronization process are available in the next section.
  2. 新しいセッションを開始する要求がコントローラーによって作成されます。The controller creates a request to start a new session. この要求には、一意の ID、スペース名、ソース コードのパス、デバッグ フラグなどの複数のプロパティが含まれます。This request contains several properties, including a unique ID, space name, path to source code, and a debugging flag.
  3. コントローラーによって、Helm チャート内の $(tag) プレースホルダーが一意のセッション ID に置き換えられ、サービス用の Helm チャートがインストールされます。The controller replaces the $(tag) placeholder in the Helm chart with the unique session ID and installs the Helm chart for your service. 一意のセッション ID への参照を Helm チャートに追加すると、この特定のセッション用に AKS クラスターにデプロイされたコンテナーをセッション要求と関連情報に再び関連付けることができます。Adding a reference to the unique session ID to the Helm chart allows the container deployed to the AKS cluster for this specific session to be tied back to the session request and associated information.
  4. Helm チャートのインストール時には、Kubernetes webhook 受付サーバーによって、インストルメンテーションおよびプロジェクトのソース コードにアクセスするためのコンテナーがアプリケーションのポッドに追加されます。During the installation of the Helm chart, the Kubernetes webhook admission server adds additional containers to your application's pod for instrumentation and access to your project's source code. HTTP トレースとスペースのルーティングを提供するために、devspaces-proxy コンテナーと devspaces-proxy-init コンテナーが追加されます。The devspaces-proxy and devspaces-proxy-init containers are added to provide HTTP tracing and space routing. アプリケーションのコンテナーのビルドに必要な Docker インスタンスとプロジェクトのソース コードへのアクセスをポッドに提供するために、devspaces-build コンテナーが追加されます。The devspaces-build container is added to provide the pod with access to the Docker instance and project source code for building your application's container.
  5. アプリケーションのポッドが開始されると、devspaces-build コンテナーと devspaces-proxy-init コンテナーを使用してアプリケーション コンテナーがビルドされます。When the application's pod is started, the devspaces-build container and devspaces-proxy-init container are used to build the application container. 次に、アプリケーション コンテナーと devspaces-proxy コンテナーが開始されます。The application container and devspaces-proxy containers are then started.
  6. アプリケーション コンテナーの開始後、クライアント側の機能で Kubernetes の port-forward 機能が使用され、 http://localhost を経由してアプリケーションへの HTTP アクセスが提供されます。After the application container has started, the client-side functionality uses the Kubernetes port-forward functionality to provide HTTP access to your application over http://localhost. このポート フォワーディングでは、開発スペース内のサービスに開発用コンピューターを接続します。This port forwarding connects your development machine to the service in your dev space.
  7. ポッド内のすべてのコンテナーが開始されると、サービスが実行されています。When all containers in the pod have started, the service is running. この時点で、クライアント側の機能は HTTP トレース、stdout、および stderr のストリーミングを開始します。At this point, the client-side functionality begins to stream the HTTP traces, stdout, and stderr. この情報は、クライアント側の機能によって開発者向けに表示されます。This information is displayed by the client-side functionality for the developer.

実行中のサービスを更新するUpdating a running service

Azure Dev Spaces では、いずれかのプロジェクトのソース コードが変更された場合に、実行中のサービスを更新することができます。While a service is running, Azure Dev Spaces has the ability to update that service if any of the project source files change. また、Dev Spaces では、変更されたファイルの種類に応じてサービスの更新をさまざまな方法で処理します。Dev Spaces also handles updating the service differently depending on the type of file that is changed. Dev Spaces では、次に示す 3 つの方法で実行中のサービスを更新できます。There are three ways Dev Spaces can update a running service:

  • ファイルを直接更新するDirectly updating a file
  • 実行中のアプリケーションのコンテナー内でアプリケーションのプロセスをリビルドして再起動するRebuilding and restarting the application's process inside the running application's container
  • アプリケーションのコンテナーをリビルドして再デプロイするRebuilding and redeploying the application's container

Azure Dev Spaces のファイル同期

静的な資産である特定のプロジェクト ファイル (html、css、cshtml ファイルなど) をアプリケーションのコンテナー内で直接更新できます。何かを再起動する必要はありません。Certain project files that are static assets, such as html, css, and cshtml files, can be updated directly in the application's container without restarting anything. 静的な資産が変更されると、新しいファイルが開発スペースに同期され、実行中のコンテナーで使用されます。If a static asset changes, the new file is synchronized to the dev space and then used by the running container.

ソース コードやアプリケーションの構成ファイルなどに対する変更は、実行中のコンテナー内でアプリケーションのプロセスを再起動すると適用されます。Changes to files such as source code or application configuration files can be applied by restarting the application's process within the running container. これらのファイルが同期されると、devhostagent プロセスを使用して、実行中のコンテナー内でアプリケーションのプロセスが再起動されます。Once these files are synchronized, the application's process is restarted within the running container using the devhostagent process. アプリケーションのコンテナーを最初に作成する際は、コントローラーによって、アプリケーションのスタートアップ コマンドが別のプロセス (devhostagent) に置き換えられます。When initially creating the application's container, the controller replaces the startup command for the application with a different process called devhostagent. 続いて、アプリケーションの実際のプロセスが子プロセスとして devhostagent で実行され、その出力が devhostagent の出力を使用して行われます。The application's actual process is then run as a child process under devhostagent, and its output is piped out using devhostagent's output. また、devhostagent プロセスは Dev Spaces の一部であり、Dev Spaces の代わりに実行中のコンテナーでコマンドを実行できます。The devhostagent process is also part of Dev Spaces and can execute commands in the running container on behalf of Dev Spaces. 再起動の実行時には、devhostagent によって次の処理が行われます。When performing a restart, devhostagent:

  • アプリケーションに関連付けられている現在のプロセスを停止するStops the current process or processes associated with the application
  • アプリケーションをリビルドするRebuilds the application
  • アプリケーションに関連付けられているプロセスを再起動するRestarts the process or processes associated with the application

devhostagent による先行手順の実行方法は azds.yaml 構成ファイルで構成されます。The way devhostagent executes the preceding steps is configured in the azds.yaml configuration file. この構成の詳細については後述します。This configuration is detailed in a later section.

プロジェクト ファイル (Dockerfile、csproj ファイル、Helm チャートの一部など) に対する更新を行うには、アプリケーションのコンテナーをリビルドおよび再デプロイする必要があります。Updates to project files such as Dockerfiles, csproj files, or any part of the Helm chart require the application's container to be rebuilt and redeployed. これらのいずれかのファイルが開発スペースに同期されると、コントローラーによって helm upgrade コマンドが実行され、アプリケーションのコンテナーがリビルドおよび再デプロイされます。When one of these files is synchronized to the dev space, the controller runs the helm upgrade command and the application's container is rebuilt and redeployed.

ファイルの同期File Synchronization

開発スペースで初めてアプリケーションを起動するときには、アプリケーションのソース ファイルがすべてアップロードされます。The first time an application is started in a dev space, all the application's source files are uploaded. アプリケーションの実行中および以降の再起動の際は、変更されたファイルのみアップロードされます。While the application is running and on later restarts, only the changed files are uploaded. このプロセスを調整するために 2 つのファイル (クライアント側ファイルとコントローラー側ファイル) が使用されます。Two files are used to coordinate this process: a client-side file and a controller-side file.

クライアント側ファイルは一時ディレクトリに格納され、開発スペースで実行中のプロジェクト ディレクトリのハッシュに基づいて命名されます。The client-side file is stored in a temporary directory and is named based on a hash of the project directory you are running in Dev Spaces. たとえば、Windows におけるプロジェクト用のファイルは Users\USERNAME\AppData\Local\Temp\1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.synclog のようになります。For example, on Windows you would have a file like Users\USERNAME\AppData\Local\Temp\1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.synclog for your project. Linux では、クライアント側ファイルは /tmp ディレクトリに格納されます。On Linux, the client-side file is stored in the /tmp directory. echo $TMPDIR コマンドを実行すると、macOS でこのディレクトリを探すことができます。You can find the directory on macOS by running the echo $TMPDIR command.

このファイルは JSON 形式であり、次のものが含まれています。This file is in JSON format and contains:

  • 開発スペースと同期される各プロジェクト ファイルのエントリAn entry for each project file that is synchronized with the dev space
  • 同期 IDA synchronization ID
  • 最後の同期操作のタイムスタンプThe timestamp of the last sync operation

プロジェクト ファイルの各エントリには、ファイルのパスとファイルのタイムスタンプが含まれています。Each project file entry contains a path to the file and its timestamp.

コントローラー側ファイルは、AKS クラスターに格納されます。The controller-side file is stored on the AKS cluster. このファイルには、同期 ID と最後の同期のタイムスタンプが含まれています。It contains the synchronization ID and the timestamp of the last synchronization.

同期は、クライアント側ファイルとコントローラー側ファイルの間で同期のタイムスタンプが一致しない場合に発生します。A sync happens when the synchronization timestamps do not match between the client-side and the controller-side files. 同期の際は、クライアント側ツールによってクライアント側ファイル内のファイル エントリが反復処理されます。During a sync, the client-side tooling iterates over the file entries in the client-side file. ファイルのタイムスタンプが同期のタイムスタンプより後である場合は、そのファイルが開発スペースに同期されます。If the file's timestamp is after the sync timestamp, that file is synced to the dev space. 同期が完了すると、クライアント側とコントローラー側の両方のファイルで同期のタイムスタンプが更新されます。Once the sync is complete, the sync timestamps are updated on both the client-side and controller-side files.

クライアント側ファイルが存在しない場合は、すべてのプロジェクト ファイルが同期されます。All of the project files are synced if the client-side file is not present. この動作では、クライアント側ファイルを削除することによって完全同期を適用できます。This behavior allows you to force a full sync by deleting the client-side file.

ルーティングのしくみHow routing works

開発スペースは AKS 上に構築され、同じネットワークの概念を使用します。A dev space is built on top of AKS and uses the same networking concepts. Azure Dev Spaces には一元化された ingressmanager サービスがあり、独自のイングレス コントローラーを AKS クラスターにデプロイします。Azure Dev Spaces also has a centralized ingressmanager service and deploys its own Ingress Controller to the AKS cluster. ingressmanager サービスでは、AKS クラスターが開発スペースと共に監視され、クラスター内の Azure Dev Spaces イングレス コントローラーをイングレス オブジェクトで強化してアプリケーション ポッドへのルーティングを実現します。The ingressmanager service monitors AKS clusters with dev spaces and augments the Azure Dev Spaces Ingress Controller in the cluster with Ingress objects for routing to application pods. 各ポッド内の devspaces-proxy コンテナーでは、HTTP トラフィック用の azds-route-as HTTP ヘッダーが URL に基づいて開発スペースに追加されます。The devspaces-proxy container in each pod adds an azds-route-as HTTP header for HTTP traffic to a dev space based on the URL. たとえば、URL http://azureuser.s.default.serviceA.fedcba09...azds.io に対する要求では、azds-route-as: azureuser を含む HTTP ヘッダーが取得されます。For example, a request to the URL http://azureuser.s.default.serviceA.fedcba09...azds.io would get an HTTP header with azds-route-as: azureuser. azds-route-as ヘッダーが既に存在する場合は、devspaces-proxy コンテナーによってヘッダーが追加されません。The devspaces-proxy container will not add an azds-route-as header if one is already present.

クラスタの外部からサービスに対して行われた HTTP 要求はイングレス コントローラーに進みます。When an HTTP request is made to a service from outside the cluster, the request goes to the Ingress controller. イングレス コントローラーでは、そのイングレス オブジェクトと規則に基づいて要求を適切なポッドに直接ルーティングします。The Ingress controller routes the request directly to the appropriate pod based on its Ingress objects and rules. ポッド内の devspaces-proxy コンテナーが要求を受信し、URLに基づいて azds-route-as ヘッダーを追加して、要求をアプリケーション コンテナーにルーティングします。The devspaces-proxy container in the pod receives the request, adds the azds-route-as header based on the URL, and then routes the request to the application container.

クラスター内のあるサービスに対して別のサービスから行われた HTTP 要求は、呼び出し元のサービスの devspaces-proxy コンテナーを最初に通過します。When an HTTP request is made to a service from another service within the cluster, the request first goes through the calling service's devspaces-proxy container. devspaces-proxy コンテナーでは、HTTP 要求を調べて azds-route-as ヘッダーをチェックします。The devspaces-proxy container looks at the HTTP request and checks the azds-route-as header. devspaces-proxy コンテナーでは、ヘッダーに基づいて、そのヘッダー値に関連付けられているサービスの IP アドレスを検索します。Based on the header, the devspaces-proxy container will look up the IP address of the service associated with the header value. IP アドレスが見つかった場合、devspaces-proxy コンテナーは要求をその IP アドレスに再ルーティングします。If an IP address is found, the devspaces-proxy container reroutes the request to that IP address. IP アドレスが見つからなかった場合、devspaces-proxy コンテナーは要求を親アプリケーション コンテナーにルーティングします。If an IP address is not found, the devspaces-proxy container routes the request to the parent application container.

たとえば、アプリケーション serviceA および serviceBdefault という名前の親開発スペースにデプロイされるとします。For example, the applications serviceA and serviceB are deployed to a parent dev space called default. serviceAserviceB に依存しており、そのサービスに対する HTTP 呼び出しを行います。serviceA relies on serviceB and makes HTTP calls to it. Azure ユーザーは、default スペースに基づいて、azureuser という子開発スペースを作成します。Azure User creates a child dev space based on the default space called azureuser. また、Azure ユーザーは、独自のバージョンの serviceA をその子スペースにデプロイします。Azure User also deploys their own version of serviceA to their child space. http://azureuser.s.default.serviceA.fedcba09...azds.io に対する要求は以下のような手順で行われます。When a request is made to http://azureuser.s.default.serviceA.fedcba09...azds.io:

Azure Dev Spaces のルーティング

  1. イングレス コントローラーが URL に関連付けられているポッド (serviceA.azureuser) の IP を確認します。The Ingress controller looks up the IP for the pod associated with the URL, which is serviceA.azureuser.
  2. イングレス コントローラーが Azure ユーザーの開発スペースでポッドの IP を検索し、要求を serviceA.azureuser ポッドにルーティングします。The Ingress controller finds the IP for the pod in Azure User's dev space and routes the request to the serviceA.azureuser pod.
  3. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが要求を受信し、HTTP ヘッダーとして azds-route-as: azureuser を追加します。The devspaces-proxy container in the serviceA.azureuser pod receives the request and adds azds-route-as: azureuser as an HTTP header.
  4. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが serviceA.azureuser ポッド内の serviceA アプリケーション コンテナーに要求をルーティングします。The devspaces-proxy container in the serviceA.azureuser pod routes the request to the serviceA application container in the serviceA.azureuser pod.
  5. serviceA.azureuser ポッド内の serviceA アプリケーションが serviceB の呼び出しを行います。The serviceA application in the serviceA.azureuser pod makes a call to serviceB. また、serviceA アプリケーションには、既存の azds-route-as ヘッダー (ここでは azds-route-as: azureuser) を保持するためのコードが含まれています。The serviceA application also contains code to preserve the existing azds-route-as header, which in this case is azds-route-as: azureuser.
  6. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが要求を受信し、azds-route-as ヘッダーの値に基づいて serviceB の IP を確認します。The devspaces-proxy container in the serviceA.azureuser pod receives the request and looks up the IP of serviceB based on the value of the azds-route-as header.
  7. serviceA.azureuser ポッド内の devspaces-proxy コンテナーは serviceB.azureuser の IP を検索しません。The devspaces-proxy container in the serviceA.azureuser pod does not find an IP for serviceB.azureuser.
  8. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが親スペース内の serviceB (serviceB.default) の IP を検索します。The devspaces-proxy container in the serviceA.azureuser pod looks up the IP for serviceB in the parent space, which is serviceB.default.
  9. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが serviceB.default の IP を検索し、要求を serviceB.default ポッドにルーティングします。The devspaces-proxy container in the serviceA.azureuser pod finds the IP for serviceB.default and routes the request to the serviceB.default pod.
  10. serviceB.default ポッド内の devspaces-proxy コンテナーが要求を受信し、serviceB.default ポッド内の serviceB アプリケーション コンテナーに要求をルーティングします。The devspaces-proxy container in the serviceB.default pod receives the request and routes the request to the serviceB application container in the serviceB.default pod.
  11. serviceB.default ポッド内の serviceB アプリケーションが serviceA.azureuser ポッドに応答を返します。The serviceB application in the serviceB.default pod returns a response to the serviceA.azureuser pod.
  12. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが応答を受信し、serviceA.azureuser ポッド内の serviceA アプリケーション コンテナーに応答をルーティングします。The devspaces-proxy container in the serviceA.azureuser pod receives the response and routes the response to the serviceA application container in the serviceA.azureuser pod.
  13. serviceA アプリケーションが応答を受信し、その独自の応答を返します。The serviceA application receives the response and then returns its own response.
  14. serviceA.azureuser ポッド内の devspaces-proxy コンテナーが serviceA アプリケーション コンテナーから応答を受信し、クラスターの外部に存在する元の呼び出し元に応答をルーティングします。The devspaces-proxy container in the serviceA.azureuser pod receives the response from the serviceA application container and routes the response to the original caller outside of the cluster.

HTTP ではないその他の TCP トラフィックはすべて、未変更の状態でイングレス コントローラーと devspaces-proxy コンテナーを通過します。All other TCP traffic that is not HTTP passes through the Ingress controller and devspaces-proxy containers unmodified.

コード実行の構成方法How running your code is configured

Azure Dev Spaces では、azds.yaml ファイルを使用してサービスをインストールおよび構成します。Azure Dev Spaces uses the azds.yaml file to install and configure your service. コントローラーでは、azds.yaml ファイル内の install プロパティを使用して、Helm チャートをインストールし、Kubernetes オブジェクトを作成します。The controller uses the install property in the azds.yaml file to install the Helm chart and create the Kubernetes objects:

...
install:
  chart: charts/webfrontend
  values:
  - values.dev.yaml?
  - secrets.dev.yaml?
  set:
    replicaCount: 1
    image:
      repository: webfrontend
      tag: $(tag)
      pullPolicy: Never
    ingress:
      annotations:
        kubernetes.io/ingress.class: traefik-azds
      hosts:
      # This expands to [space.s.][rootSpace.]webfrontend.<random suffix>.<region>.azds.io
      # Customize the public URL by changing the 'webfrontend' text between the $(rootSpacePrefix) and $(hostSuffix) tokens
      # For more information see https://aka.ms/devspaces/routing
      - $(spacePrefix)$(rootSpacePrefix)webfrontend$(hostSuffix)
...

既定では、Helm チャートは prep コマンドによって生成されます。By default, the prep command will generate the Helm chart. また、install.chart プロパティは Helm チャートのディレクトリに設定されます。It also sets the install.chart property to the directory of the Helm chart. Helm チャートを別の場所で使用する場合は、その場所を使用するようにこのプロパティを更新できます。If you wanted to use a Helm chart in a different location, you can update this property to use that location.

Helm チャートのインストール時には、Helm チャート内の値をオーバーライドする方法が Azure Dev Spaces から提供されます。When installing the Helm charts, Azure Dev Spaces provides a way to override values in the Helm chart. Helm チャートの既定値は charts/APP_NAME/values.yaml に含まれています。The default values for the Helm chart are in charts/APP_NAME/values.yaml.

install.values プロパティを使用すると、Helm チャートで置き換える値を定義する 1 つ以上のファイルを表示できます。Using the install.values property, you can list one or more files that define values you want replaced in the Helm chart. たとえば、開発スペースでアプリケーションを実行する場合にホスト名またはデータベース構成が必要な場合は、このオーバーライド機能を使用できます。For example, if you wanted a hostname or database configuration specifically when running your application in a dev space, you can use this override functionality. また、 ?You can also add a ? ファイル名の末尾に追加して、オプションとして設定することもできます。at the end of any of the file names to set it as optional.

install.set プロパティを使用すると、Helm チャートで置き換える 1 つ以上の値を構成できます。The install.set property allows you to configure one or more values you want replaced in the Helm chart. install.set で構成された値によって、install.values に表示されているファイルで構成された値がオーバーライドされます。Any values configured in install.set will override values configured in files listed in install.values. install.set に属するプロパティは、Helm チャート内の値に依存し、生成される Helm チャートによって異なる場合があります。The properties under install.set are dependent on the values in the Helm chart and may be different depending on the generated Helm chart.

上記の例では、install.set.replicaCount プロパティは、開発スペースで実行するアプリケーションのインスタンス数をコントローラーに通知します。In the above example, the install.set.replicaCount property tells the controller how many instances of your application to run in your dev space. シナリオによっては、この値を増やすことができますが、これはアプリケーションのポッドへのデバッガーのアタッチに影響を及ぼします。Depending on your scenario, you can increase this value, but it will have an impact on attaching a debugger to your application's pod. 詳細については、トラブルシューティングの記事を参照してください。For more information, see the troubleshooting article.

生成される Helm チャートでは、コンテナー イメージが {{ .Values.image.repository }}:{{ .Values.image.tag }} に設定されます。In the generated Helm chart, the container image is set to {{ .Values.image.repository }}:{{ .Values.image.tag }}. azds.yaml ファイルでは、install.set.image.tag プロパティが既定で $(tag) として定義されます。これは、 {{ .Values.image.tag }} の値として使用されます。The azds.yaml file defines install.set.image.tag property as $(tag) by default, which is used as the value for {{ .Values.image.tag }}. この方法で install.set.image.tag プロパティを設定すると、Azure Dev Spaces の実行時に独自の方法でアプリケーションのコンテナー イメージにタグ付けできます。By setting the install.set.image.tag property in this way, it allows the container image for your application to be tagged in a distinct way when running Azure Dev Spaces. この特定のケースでは、イメージは <image.repository の値>:$(tag) としてタグ付けされます。In this specific case, the image is tagged as <value from image.repository>:$(tag). Dev Spaces が AKS クラスター内のコンテナーを認識して特定できるようにするには、 $(tag) 変数を install.set.image.tag の値として使用する必要があります。You must use the $(tag) variable as the value of install.set.image.tag in order for Dev Spaces recognize and locate the container in the AKS cluster.

上記の例では、azds.yaml によって install.set.ingress.hosts が定義されます。In the above example, azds.yaml defines install.set.ingress.hosts. install.set.ingress.hosts プロパティでは、パブリック エンドポイントのホスト名の形式が定義されます。The install.set.ingress.hosts property defines a host name format for public endpoints. また、このプロパティでは $(spacePrefix)$(rootSpacePrefix) 、および $(hostSuffix) を使用します。これらはコントローラーから提供される値です。This property also uses $(spacePrefix), $(rootSpacePrefix), and $(hostSuffix), which are values provided by the controller.

$(spacePrefix) は子開発スペースの名前であり、SPACENAME.s という形式になります。The $(spacePrefix) is the name of the child dev space, which takes the form of SPACENAME.s. $(RootSpacePrefix) は親スペースの名前です。The $(rootSpacePrefix) is the name of the parent space. たとえば、azureuserdefault の子スペースである場合、 $(rootSpacePrefix) の値は default$(spacePrefix) の値は azureuser.s になります。For example, if azureuser is a child space of default, the value for $(rootSpacePrefix) is default and the value of $(spacePrefix) is azureuser.s. スペースが子スペースでない場合、 $(spacePrefix) は空白になります。If the space is not a child space, $(spacePrefix) is blank. たとえば、default スペースに親スペースがない場合、 $(rootSpacePrefix) の値は default$(spacePrefix) の値は空白になります。For example, if the default space has no parent space, the value for $(rootSpacePrefix) is default and the value of $(spacePrefix) is blank. $(hostSuffix) は、AKS クラスターで実行する Azure Dev Spaces イングレス コントローラーを指す DNS サフィックスです。The $(hostSuffix) is a DNS suffix that points to the Azure Dev Spaces Ingress Controller that runs in your AKS cluster. この DNS サフィックスは、Azure Dev Spaces コントローラーが AKS クラスターに追加されたときに作成されたワイルドカードの DNS エントリ (たとえば、 *.RANDOM_VALUE.eus.azds.io) に対応しています。This DNS suffix corresponds to a wildcard DNS entry, for example *.RANDOM_VALUE.eus.azds.io, that was created when the Azure Dev Spaces controller was added to your AKS cluster.

上記の azds.yaml ファイルでは、アプリケーションのホスト名を変更するように install.set.ingress.hosts を更新することも可能でした。In the above azds.yaml file, you could also update install.set.ingress.hosts to change the host name of your application. たとえば、アプリケーションのホスト名を $(spacePrefix)$(rootSpacePrefix)webfrontend$(hostSuffix) から $(spacePrefix)$(rootSpacePrefix)web$(hostSuffix) に簡略化する場合などです。For example, if you wanted to simplify the hostname of your application from $(spacePrefix)$(rootSpacePrefix)webfrontend$(hostSuffix) to $(spacePrefix)$(rootSpacePrefix)web$(hostSuffix).

アプリケーションのコンテナーをビルドするために、コントローラーでは、azds.yaml 構成ファイルの以下のセクションを使用します。To build the container for your application, the controller uses the below sections of the azds.yaml configuration file:

build:
  context: .
  dockerfile: Dockerfile
...
configurations:
  develop:
    build:
      dockerfile: Dockerfile.develop
      useGitIgnore: true
      args:
        BUILD_CONFIGURATION: ${BUILD_CONFIGURATION:-Debug}
...

コントローラーでは、Dockerfile を使用してアプリケーションをビルドおよび実行します。The controller uses a Dockerfile to build and run your application.

build.context プロパティでは、Dockerfile が存在するディレクトリを表示します。The build.context property lists the directory where the Dockerfiles exist. build.dockerfile プロパティでは、運用バージョンのアプリケーションをビルドするための Dockerfile の名前を定義します。The build.dockerfile property defines the name of the Dockerfile for building the production version of the application. configurations.develop.build.dockerfile プロパティでは、開発バージョンのアプリケーション用の Dockerfile の名前を構成します。The configurations.develop.build.dockerfile property configures the name of the Dockerfile for the development version of the application.

開発と運用に異なる Dockerfile を使用すると、開発時に特定の項目を有効にする一方で、運用環境ではそれらの項目を無効にすることができます。Having different Dockerfiles for development and production allows you to enable certain things during development and disable those items for production deployments. たとえば、デバッグや詳細なログを開発時には有効にして、運用環境では無効にすることができます。For example, you can enable debugging or more verbose logging during development and disable in a production environment. また、Dockerfile の名前が異なる場合や、Dockerfile が別の場所にある場合にこれらのプロパティを更新することもできます。You can also update these properties if your Dockerfiles are named differently or are in a different location.

開発時に迅速に反復処理を行えるようにするために、Azure Dev Spaces ではローカル プロジェクトから変更を同期して、アプリケーションを増分更新します。To help you rapidly iterate during development, Azure Dev Spaces will sync changes from your local project and incrementally update your application. azds.yaml 構成ファイルの以下のセクションを使用して、同期と更新を構成します。The below section in the azds.yaml configuration file is used to configure the sync and update:

...
configurations:
  develop:
    ...
    container:
      sync:
      - "**/Pages/**"
      - "**/Views/**"
      - "**/wwwroot/**"
      - "!**/*.{sln,csproj}"
      command: [dotnet, run, --no-restore, --no-build, --no-launch-profile, -c, "${BUILD_CONFIGURATION:-Debug}"]
      iterate:
        processesToKill: [dotnet, vsdbg]
        buildCommands:
        - [dotnet, build, --no-restore, -c, "${BUILD_CONFIGURATION:-Debug}"]
...

変更を同期するファイルとディレクトリは configurations.develop.container.sync プロパティで示されます。The files and directories that will sync changes are listed in the configurations.develop.container.sync property. これらのディレクトリは、up コマンドの実行時および変更が検出されたときに最初に同期されます。These directories are synced initially when you run the up command as well as when changes are detected. 開発スペースと同期させる追加のディレクトリまたは別のディレクトリがある場合は、このプロパティを変更できます。If there are additional or different directories you would like synced to your dev space, you can change this property.

configurations.develop.container.iterate.buildCommands プロパティでは、開発シナリオでアプリケーションをビルドする方法を指定します。The configurations.develop.container.iterate.buildCommands property specifies how to build the application in a development scenario. configurations.develop.container.command プロパティでは、開発シナリオでアプリケーションを実行するためのコマンドを提供します。The configurations.develop.container.command property provides the command for running the application in a development scenario. 開発時に使用するビルドまたは実行時の追加のフラグやパラメーターがある場合は、これらのプロパティのどちらかの更新が必要になることがあります。You may want to update either of these properties if there are additional build or runtime flags or parameters you would like to use during development.

configurations.develop.container.iterate.processesToKill では、アプリケーションを停止するために中止するプロセスを表示します。The configurations.develop.container.iterate.processesToKill lists the processes to kill to stop the application. 開発時にアプリケーションの再起動の動作を変更する場合は、このプロパティの更新が必要になることがあります。You may want to update this property if you want to change the restart behavior of your application during development. たとえば、アプリケーションのビルドや起動の方法を変更するように configurations.develop.container.iterate.buildCommands プロパティまたは configurations.develop.container.command プロパティを更新した場合は、停止するプロセスの変更が必要になることがあります。For example, if you updated the configurations.develop.container.iterate.buildCommands or configurations.develop.container.command properties to change how the application is built or started, you may need to change what processes are stopped.

azds prep コマンドを使用してコードを準備する場合は、--public フラグを追加することができます。When preparing your code using the azds prep command, you have the option of adding the --public flag. --public フラグを追加すると、アプリケーションのパブリックにアクセス可能な URL が作成されます。Adding the --public flag creates a publicly accessible URL for your application. このフラグを省略した場合は、クラスター内から、または localhost トンネルを使用してアプリケーションにアクセスする必要があります。If you omit this flag, the application is only accessible within the cluster or using the localhost tunnel. azds prep コマンドの実行後、charts/APPNAME/values.yamlingress.enabled プロパティを変更して、この設定を変更することができます。After you run the azds prep command, you can change this setting modifying the ingress.enabled property in charts/APPNAME/values.yaml:

ingress:
  enabled: true

コードをデバッグするDebug your code

Java、.NET、および Node.js アプリケーションの場合、Visual Studio Code または Visual Studio を使用して、実行中のアプリケーションを開発スペースで直接デバッグできます。For Java, .NET and Node.js applications, you can debug your application running directly in your dev space using Visual Studio Code or Visual Studio. Visual Studio Code と Visual Studio には、開発スペースに接続してアプリケーションを起動し、デバッガーをアタッチするためのツールが用意されています。Visual Studio Code and Visual Studio provide tooling to connect to your dev space, launch your application, and attach a debugger. azds prep の実行後、Visual Studio Code または Visual Studio でプロジェクトを開くことができます。After running azds prep, you can open your project in Visual Studio Code or Visual Studio. Visual Studio Code または Visual Studio では、azds prep の実行とは別の接続用の独自の構成ファイルが生成されます。Visual Studio Code or Visual Studio will generate their own configuration files for connecting which is separate from running azds prep. Visual Studio Code または Visual Studio 内から、ブレークポイントを設定し、開発スペースに対してアプリケーションを起動できます。From within Visual Studio Code or Visual Studio, you can set breakpoints and launch your application to your dev space.

コードのデバッグ

Visual Studio Code または Visual Studio を使用してデバッグ用にアプリケーションを起動すると、azds up の実行と同じ方法で起動および開発スペースへの接続が処理されます。When you launch your application using Visual Studio Code or Visual Studio for debugging, they handle launching and connecting to your dev space in the same way as running azds up. また、Visual Studio Code および Visual Studio のクライアント側ツールには、デバッグ用の特定の情報を含む追加のパラメーターが用意されています。The client-side tooling in Visual Studio Code and Visual Studio also provide an additional parameter with specific information for debugging. このパラメーターには、デバッガー イメージの名前、デバッガー イメージ内のデバッガーの場所、およびアプリケーションのコンテナー内でのデバッガー フォルダーのマウント先が含まれています。The parameter contains the name of debugger image, the location of the debugger within in the debugger's image, and the destination location within the application's container to mount the debugger folder.

デバッガー イメージは、クライアント側ツールによって自動的に指定されます。The debugger image is automatically determined by the client-side tooling. azds prep の実行時に Dockerfile と Helm チャートの生成に使用したのと同じ方法が使用されます。It uses a method similar to the one used during Dockerfile and Helm chart generate when running azds prep. アプリケーションのイメージにマウントされたデバッガーは azds exec を使用して実行されます。After the debugger is mounted in the application's image, it is run using azds exec.

開発スペースを共有するSharing a dev space

チームで作業している場合は、チーム全体で開発スペースを共有したり、派生の開発スペースを作成したりできます。When working with a team, you can share a dev space across an entire team and create derived dev spaces. 開発スペースは、その開発スペースのリソース グループへの共同作成者アクセス権を持つユーザーが使用できます。A dev space can be used by anyone with contributor access to the dev space's resource group.

別の開発スペースから派生した新しい開発スペースを作成することもできます。You can also create a new dev space that is derived from another dev space. 派生の開発スペースを作成すると、その開発スペースの名前空間に azds.io/parent-space=PARENT-SPACE-NAME ラベルが追加されます。When you create a derived dev space, the azds.io/parent-space=PARENT-SPACE-NAME label is added to the derived dev space's namespace. また、親開発スペースからのすべてのアプリケーションが派生の開発スペースと共有されます。Also, all applications from the parent dev space are shared with the derived dev space. 更新バージョンのアプリケーションを派生の開発スペースにデプロイする場合、そのアプリケーションは派生の開発スペースにのみ存在し、親開発スペースには影響しません。If you deploy an updated version of an application to the derived dev space, it will only exist in the derived dev space and the parent dev space will remain unaffected. 最大で 3 レベルの派生の開発スペースまたは "親の親" であるスペースを使用できます。You can have a maximum of three levels of derived dev spaces or grandparent spaces.

また、派生の開発スペースでは、その独自のアプリケーションと親から共有されるアプリケーションの間で要求がインテリジェントにルーティングされます。The derived dev space will also intelligently route requests between its own applications and the applications shared from its parent. ルーティングの際は、派生の開発スペースでアプリケーションに対する要求のルーティングが試行され、親開発スペースから共有アプリケーションにフォールバックされます。The routing works by attempting to route request to an application in the derived dev space and falling back to the shared application from the parent dev space. アプリケーションが親スペースにない場合は、親の親であるスペース内の共有アプリケーションにルーティングがフォールバックします。The routing will fall back to the shared application in the grandparent space if the application is not in the parent space.

次に例を示します。For example:

  • 開発スペース default にアプリケーション serviceA および serviceB があります。The dev space default has applications serviceA and serviceB .
  • 開発スペース azureuserdefault から派生したものです。The dev space azureuser is derived from default.
  • serviceA の更新バージョンは azureuser にデプロイされます。An updated version of serviceA is deployed to azureuser.

azureuser の使用時には、serviceA に対するすべての要求が azureuser 内の更新バージョンにルーティングされます。When using azureuser, all requests to serviceA will be routed to the updated version in azureuser. serviceB に対する要求は、最初に azureuser バージョンの serviceB へのルーティングが試行されます。A request to serviceB will first try to be routed to the azureuser version of serviceB. これが存在しないため、default バージョンの serviceB にルーティングされます。Since it does not exist, it will be routed to the default version of serviceB. azureuser バージョンの serviceA が削除されると、serviceA に対するすべての要求は default バージョンの serviceA を使用するようにフォールバックされます。If the azureuser version of serviceA is removed, all requests to serviceA will fall back to using the default version of serviceA.

次のステップNext steps

Azure Dev Spaces の使用を開始するには、以下のクイック スタートを参照してください。To get started using Azure Dev Spaces, see the following quickstarts:

チーム開発を開始するには、以下のハウツー記事を参照してください。To get started with team development, see the following how-to articles: