Fonctionnement et configuration d'Azure Dev SpacesHow Azure Dev Spaces works and is configured

Le développement d’une application Kubernetes peut s'avérer difficile.Developing a Kubernetes application can be challenging. Vous avez besoin des fichiers de configuration Docker et Kubernetes.You need Docker and Kubernetes configuration files. Vous devez trouver comment tester votre application localement et interagir avec d'autres services dépendants.You need to figure out how to test your application locally and interact with other dependent services. Vous devrez éventuellement gérer le développement et le test sur plusieurs services à la fois et avec une équipe de développeurs.You might need to handle developing and testing on multiple services at once and with a team of developers.

Azure Dev Spaces vous aide à développer, déployer et déboguer les applications Kubernetes directement dans Azure Kubernetes Service (AKS).Azure Dev Spaces helps you develop, deploy, and debug Kubernetes applications directly in Azure Kubernetes Service (AKS). Azure Dev Spaces permet également à une équipe de partager un espace de développement.Azure Dev Spaces also allows a team to share a dev space. Le partage d'un espace de développement au sein d'une équipe permet à chacun des membres de cette équipe de se développer de manière isolée sans avoir à répliquer ou à simuler des dépendances ou d'autres applications dans le cluster.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 crée et utilise un fichier de configuration pour déployer, exécuter et déboguer vos applications Kubernetes dans AKS.Azure Dev Spaces creates and uses a configuration file for deploying, running, and debugging your Kubernetes applications in AKS. Ce fichier de configuration contient le code de votre application et peut être ajouté à votre système de contrôle de version.This configuration file resides with your application's code and can be added to your version control system.

Cet article décrit les processus qui alimentent Azure Dev Spaces et comment ces processus sont configurés dans le fichier de configuration 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. Pour configurer rapidement Azure Dev Spaces et le voir en pratique, complétez l'un des démarrages rapides suivants :To get Azure Dev Spaces running quickly and see it in practice, complete one of the quickstarts:

Fonctionnement d’Azure Dev SpacesHow Azure Dev Spaces works

Azure Dev Spaces comporte deux composants distincts avec lesquels vous interagissez : le contrôleur et les outils côté client.Azure Dev Spaces has two distinct components that you interact with: the controller and the client-side tooling.

Composants Azure Dev Spaces

Le contrôleur effectue les actions suivantes :The controller performs the following actions:

  • Gère la création et la sélection de l'espace de développement.Manages dev space creation and selection.
  • Installe le graphique Helm de votre application et crée des objets Kubernetes.Installs your application's Helm chart and creates Kubernetes objects.
  • Génère l'image du conteneur de votre application.Builds your application's container image.
  • Déploie votre application sur AKS.Deploys your application to AKS.
  • Crée des builds incrémentales et redémarre lorsque votre code source change.Does incremental builds and restarts when your source code changes.
  • Gère les journaux et les traces HTTP.Manages logs and HTTP traces.
  • Transfère stdout et stderr vers les outils côté client.Forwards stdout and stderr to the client-side tooling.
  • Permet aux membres de l'équipe de créer des espaces de développement enfants dérivés d'un espace de développement parent.Allows team members to create child dev spaces derived from a parent dev space.
  • Configure le routage pour les applications à l'intérieur d'un espace et entre les espaces parents et enfants.Configures routing for applications within a space as well as across parent and child spaces.

Le contrôleur réside à l'extérieur d’AKS.The controller resides outside AKS. Il gère le comportement et la communication entre les outils côté client et le cluster AKS.It drives the behavior and communication between the client-side tooling and the AKS cluster. Le contrôleur est activé à l'aide de l’interface de ligne de commande CLI Azure lorsque vous préparez votre cluster pour utiliser Azure Dev Spaces.The controller is enabled using the Azure CLI when you prepare your cluster to use Azure Dev Spaces. Une fois ce contrôleur activé, vous pouvez interagir avec lui à l'aide des outils côté client.Once it is enabled, you can interact with it using the client-side tooling.

Les outils côté client permettent à l’utilisateur d’effectuer les tâches suivantes :The client-side tooling allows the user to:

  • Générer un Dockerfile, un graphique Helm et un fichier de configuration Azure Dev Spaces pour l'application.Generate a Dockerfile, Helm chart, and Azure Dev Spaces configuration file for the application.
  • Créer des espaces de développement parents et enfants.Create parent and child dev spaces.
  • Demander au contrôleur de générer et de démarrer votre application.Tell the controller to build and start your application.

Pendant que votre application est en cours d'exécution, les outils côté client effectuent aussi les tâches suivantes :While your application is running, the client-side tooling also:

  • Reçoivent et affichent stdout et stderr depuis votre application en cours d’exécution dans AKS.Receives and displays stdout and stderr from your application running in AKS.
  • Utilisent port-forward pour autoriser l'accès web à votre application via http://localhost.Uses port-forward to allow web access to your application using http://localhost.
  • Associe un débogueur à votre application en cours d'exécution dans AKS.Attaches a debugger to your running application in AKS.
  • Synchronisent le code source sur votre espace de développement lorsqu'un changement est détecté pour les builds incrémentielles, permettant ainsi une itération rapide.Syncs source code to your dev space when a change is detected for incremental builds, allowing for rapid iteration.

Vous pouvez utiliser les outils côté client depuis la ligne de commande dans le cadre de la commande azds.You can use the client-side tooling from the command line as part of the azds command. Vous pouvez également utiliser les outils côté client avec :You can also use the client-side tooling with:

Voici le flux de base pour la configuration et l'utilisation d’Azure Dev Spaces :Here's the basic flow for setting up and using Azure Dev Spaces:

  1. Préparer votre cluster AKS pour Azure Dev SpacesPrepare your AKS cluster for Azure Dev Spaces
  2. Préparer votre code pour une exécution sur Azure Dev SpacesPrepare your code for running on Azure Dev Spaces
  3. Exécuter votre code sur un espace de développementRun your code on a dev space
  4. Déboguer votre code sur un espace de développementDebug your code on a dev space
  5. Partager un espace de développementShare a dev space

Nous reviendrons plus en détail sur le fonctionnement d'Azure Dev Spaces dans chacune des sections ci-dessous.We'll cover more details of how Azure Dev Spaces works in each of the below sections.

Préparer votre cluster AKSPrepare your AKS cluster

La préparation de votre cluster AKS implique les étapes suivantes :Preparing your AKS cluster involves:

  • Vérification que votre cluster Azure Kubernetes Service se trouve dans une région prise en charge par Azure Dev Spaces.Verifying your AKS cluster is in a region supported by Azure Dev Spaces.
  • Vérification que vous exécutez Kubernetes 1.10.3 ou version ultérieure.Verifying you are running Kubernetes 1.10.3 or later.
  • Activer Azure Dev Spaces sur votre cluster avec az aks use-dev-spacesEnabling Azure Dev Spaces on your cluster using az aks use-dev-spaces

Pour plus d'informations sur la création et la configuration d'un cluster AKS pour Azure Dev Spaces, consultez l'un des guides de démarrage suivants :For more information on how to create and configure an AKS cluster for Azure Dev Spaces, see one of the getting started guides:

Quand Azure Dev Spaces est activé sur votre cluster AKS, il installe le contrôleur pour votre cluster.When Azure Dev Spaces is enabled on your AKS cluster, it installs the controller for your cluster. Le contrôleur est une ressource Azure distincte à l'extérieur de votre cluster et qui effectue les actions suivantes sur les ressources de votre cluster :The controller is a separate Azure resource outside of your cluster and does the following to resources in your cluster:

  • Crée ou désigne un espace de noms Kubernetes à utiliser comme espace de développement.Creates or designates a Kubernetes namespace to use as a dev space.
  • Supprime tout espace de noms Kubernetes nommé azds, s'il existe, et en crée un nouveau.Removes any Kubernetes namespace named azds, if it exists, and creates a new one.
  • Déploie une configuration webhook Web Kubernetes.Deploys a Kubernetes webhook configuration.
  • Déploie un serveur d’admission webhook.Deploys a webhook admission server.

Il utilise également le même principal de service que votre cluster AKS pour passer des appels de service vers d'autres composants 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 prépare le cluster

Pour utiliser Azure Dev Spaces, au moins un espace de développement est nécessaire.In order to use Azure Dev Spaces, there must be at least one dev space. Azure Dev Spaces utilise les espaces de noms Kubernetes de votre cluster AKS comme espaces de développement.Azure Dev Spaces uses Kubernetes namespaces within your AKS cluster for dev spaces. Lorsqu'un contrôleur est installé, il vous invite à créer un espace de noms Kubernetes ou à choisir un espace de noms existant à utiliser comme espace de développement initial.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. Lorsqu'un espace de noms est désigné comme espace de développement, le contrôleur ajoute l’étiquette azds.io/space=true à cet espace de noms pour l'identifier comme espace de développement.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. Une fois que vous avez préparé votre cluster, l'espace de développement initial que vous créez ou désignez est sélectionné par défaut.The initial dev space you create or designate is selected by default after you prepare your cluster. Lorsqu'un espace est sélectionné, il est utilisé par Azure Dev Spaces pour créer des charges de travail.When a space is selected, it is used by Azure Dev Spaces for creating new workloads.

Par défaut, le contrôleur crée un espace de développement nommé default (par défaut) en mettant à niveau l'espace de développement existant Kubernetes intitulé default (par défaut).By default, the controller creates a dev space named default by upgrading the existing default Kubernetes namespace. Vous pouvez utiliser les outils côté client pour créer des espaces de développement et supprimer les espaces de développement existants.You can use the client-side tooling to create new dev spaces and remove existing dev spaces. En raison d'une limitation dans Kubernetes, l'espace de développement default (par défaut) ne peut pas être supprimé.Due to a limitation in Kubernetes, the default dev space cannot be removed. Le contrôleur supprime également tous les espaces de noms Kubernetes existants nommés azds pour éviter les conflits avec la commande azds utilisée par les outils côté client.The controller also removes any existing Kubernetes namespaces named azds to avoid conflicts with the azds command used by the client-side tooling.

Le serveur d'admission webhook de Kubernetes sert à injecter des pods avec trois conteneurs pendant le déploiement pour l'instrumentation : un conteneur devspaces-proxy, un conteneur devspaces-proxy-init et un conteneur 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. Ces trois conteneurs s'exécutent avec un accès root sur votre cluster AKS.All three of these containers run with root access on your AKS cluster. Ils utilisent également le même principal de service que votre cluster AKS pour passer des appels de service vers d'autres composants 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.

Serveur d'admission webhook Azure Dev Spaces

Le conteneur devspaces-proxy est un conteneur sidecar qui gère tout le trafic TCP entrant et sortant du conteneur de l'application et en facilite le routage.The devspaces-proxy container is a sidecar container that handles all TCP traffic into and out of the application container and helps perform routing. Le conteneur devspaces-proxy redirige les messages HTTP si certains espaces sont utilisés.The devspaces-proxy container reroutes HTTP messages if certain spaces are being used. Par exemple, il peut faciliter le routage des messages HTTP entre les applications dans les espaces parents et enfants.For example, it can help route HTTP messages between applications in parent and child spaces. Tout le trafic non-HTTP transite par devspaces-proxy, sans être modifié.All non-HTTP traffic passes through devspaces-proxy unmodified. Le conteneur devspaces-proxy enregistre également tous les messages HTTP entrants et sortants et les envoie aux outils côté client sous forme de traces.The devspaces-proxy container also logs all inbound and outbound HTTP messages and sends them to the client-side tooling as traces. Ces traces peuvent ensuite être visualisées par le développeur pour étudier le comportement de l'application.These traces can then be viewed by the developer to inspect the behavior of the application.

Le conteneur devspaces-proxy-init est un conteneur init qui ajoute des règles de routage supplémentaires basées sur la hiérarchie spatiale au conteneur de votre application.The devspaces-proxy-init container is an init container that adds additional routing rules based on the space hierarchy to your application's container. Il ajoute des règles de routage en mettant à jour le fichier /etc/resolv.conf du conteneur de l’application et la configuration des tables d’adresses IP avant le démarrage.It adds routing rules by updating the application container's /etc/resolv.conf file and iptables configuration before it starts. Les mises à jour appliquées à /etc/resolv.conf permettent la résolution DNS des services dans les espaces parents.The updates to /etc/resolv.conf allow for DNS resolution of services in parent spaces. Les mises à jour de la configuration des tables d’adresses IP garantissent que tout le trafic TCP entrant et sortant du conteneur de l'application est acheminé via devspaces-proxy.The iptables configuration updates ensure all TCP traffic into and out of the application's container are routed though devspaces-proxy. Toutes les mises à jour provenant de devspaces-proxy-init viennent compléter les règles que Kubernetes ajoute.All updates from devspaces-proxy-init happen in addition to the rules that Kubernetes adds.

Le conteneur devspaces-build est un conteneur init et contient le code source du projet ainsi que le socket Docker monté.The devspaces-build container is an init container and has the project source code and Docker socket mounted. Le code source du projet et l'accès à Docker permettent au conteneur de l’application d'être généré directement par le pod.The project source code and access to Docker allows the application container to be built directly by the pod.

Notes

Azure Dev Spaces utilise le même nœud pour générer le conteneur de votre application et l'exécuter.Azure Dev Spaces uses the same node to build your application's container and run it. Par conséquent, Azure Dev Spaces n'a pas besoin d'un registre de conteneurs externe pour générer et exécuter votre application.As a result, Azure Dev Spaces does not need an external container registry for building and running your application.

Le serveur d'admission webhook Kubernetes écoute tout nouveau pod créé dans le cluster AKS.The Kubernetes webhook admission server listens for any new pod that's created in the AKS cluster. Si ce pod est déployé dans un espace de noms étiqueté azds.io/space=true, il injecte ce pod avec les conteneurs supplémentaires.If that pod is deployed to any namespace with the azds.io/space=true label, it injects that pod with the additional containers. Le conteneur devspaces-build n'est injecté que si le conteneur de l'application est exécuté avec les outils côté client.The devspaces-build container is only injected if the application's container is run using the client-side tooling.

Une fois que vous avez préparé votre cluster AKS, vous pouvez utiliser les outils côté client pour préparer et exécuter votre code dans votre espace de développement.Once you have prepared your AKS cluster, you can use the client-side tooling to prepare and run your code in your dev space.

Préparer votre codePrepare your code

Pour exécuter votre application dans un espace de développement, elle doit être conteneurisée, et vous devez définir la façon dont elle doit être déployée sur 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. Pour conteneuriser votre application, vous avez besoin d'un Dockerfile.To containerize your application, you need a Dockerfile. Pour définir la façon dont votre application est déployée sur Kubernetes, vous avez besoin d'un graphique Helm.To define how your application is deployed to Kubernetes, you need a Helm chart. Afin vous aider à créer à la fois le Dockerfile et le graphique Helm pour votre application, les outils côté client fournissent la commande 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

La commande prep examinera les fichiers de votre projet et tentera de créer le Dockerfile et le graphique Helm pour exécuter votre application dans Kubernetes.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. Actuellement, la commande prep génère un Dockerfile et un diagramme Helm avec les langages suivants :Currently, the prep command will generate a Dockerfile and Helm chart with the following languages:

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

Vous devez exécuter la commande prep depuis un répertoire contenant le code source.You must run the prep command from a directory that contains source code. Exécuter la commande prep depuis le répertoire adéquat permet aux outils côté client d'identifier le langage et de créer un Dockerfile approprié pour conteneuriser votre application.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. Vous pouvez également exécuter la commande prep à partir d'un répertoire contenant un fichier pom.xml pour les projets Java.You can also run the prep command from a directory that contains a pom.xml file for Java projects.

Si vous exécutez la commande prep à partir d'un répertoire qui ne contient aucun code source, les outils côté client ne généreront aucun Dockerfile.If you run the prep command from directory that does not contain source code, the client-side tooling will not generate a Dockerfile. Ils afficheront également le message d'erreur suivant : Impossible de générer Dockerfile en raison d’un langage non pris en charge.It will also display an error saying: Dockerfile could not be generated due to unsupported language. Cette erreur se produit également si les outils côté client ne reconnaissent pas le type de projet.This error also occurs if the client-side tooling does not recognize the project type.

Lorsque vous exécutez la commande prep, vous avez la possibilité de spécifier l'indicateur --public.When you run the prep command, you have the option of specifying the --public flag. Cet indicateur demande au contrôleur de créer un point d'accès Internet pour ce service.This flag tells the controller to create an internet-accessible endpoint for this service. Si vous ne spécifiez pas cet indicateur, le service n'est accessible que depuis le cluster ou via le tunnel localhost créé par les outils côté client.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. Vous pouvez activer ou désactiver ce comportement après avoir exécuté la commande prep en mettant à jour le graphique Helm généré.You can enable or disable this behavior after running the prep command by updating the generated Helm chart.

La commande prep ne remplacera pas les Dockerfiles ou les graphiques Helm existants que contient votre projet.The prep command will not replace any existing Dockerfiles or Helm charts you have in your project. Si un Dockerfile ou un graphique Helm existant utilise la même convention d'appellation que les fichiers générés par la commande prep, celle-ci prep ignore la génération de ces fichiers.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. Sinon, la commande prep générera son propre Dockerfile ou graphique Helm à côté des fichiers existants.Otherwise, the prep command will generate its own Dockerfile or Helm chart along side the existing files.

La commande prep générera également un fichier azds.yaml à la racine de votre projet.The prep command will also generate a azds.yaml file at the root of your project. Azure Dev Spaces utilise ce fichier pour générer, installer, configurer et exécuter votre application.Azure Dev Spaces uses this file to build, install, configure, and run your application. Ce fichier de configuration indique l'emplacement de votre Dockerfile et de votre graphique Helm et également une configuration supplémentaire en plus de ces artefacts.This configuration file lists the location of your Dockerfile and Helm chart and also provides additional configuration on top of those artifacts.

Voici un exemple de fichier azds.yaml créé avec un exemple d'application .NET Core :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}"]

Le fichier azds.yaml généré par la commande prep devrait fonctionner correctement pour un scénario de développement de projet simple et unique.The azds.yaml file generated by the prep command should work fine for a simple, single project development scenario. Si votre projet spécifique est plus complexe, vous devrez peut-être mettre à jour ce fichier après avoir exécuté la commande prep.If your specific project has increased complexity, you may need to update this file after running the prep command. Par exemple, votre projet peut nécessiter quelques ajustements à votre processus de génération ou de lancement selon vos besoins de développement ou de débogage.For example, your project may require some tweaking to your build or launch process based on your development or debugging needs. Votre projet contient peut-être plusieurs applications nécessitant plusieurs processus de génération ou un contenu de génération différent.You also might have multiple applications in your project, which require multiple build processes or a different build content.

Exécuter votre codeRun your code

Pour exécuter votre code dans un espace de développement, lancez la commande up dans le même répertoire que votre fichier azds.yaml :To run your code in a dev space, issue the up command in the same directory as your azds.yaml file:

azds up

La commande up charge les fichiers source de votre application et autres artefacts nécessaires pour générer et exécuter votre projet dans l'espace de développement.The up command uploads your application source files and other artifacts needed to build and run your project to the dev space. De là, le contrôleur dans votre espace de développement :From there, the controller in your dev space:

  1. Crée les objets Kubernetes pour déployer votre application.Creates the Kubernetes objects to deploy your application.
  2. Génère le conteneur pour votre application.Builds the container for your application.
  3. Déploie votre application dans l'espace de développement.Deploys your application to the dev space.
  4. Crée un nom DNS accessible au public pour votre point de terminaison d'application, s'il est configuré.Creates a publicly accessible DNS name for your application endpoint if configured.
  5. Utilise port-forward pour donner accès à votre point de terminaison d'application grâce à http://localhost.Uses port-forward to provide access to your application endpoint using http://localhost.
  6. Transfère stdout et stderr vers les outils côté client.Forwards stdout and stderr to the client-side tooling.

Démarrage d'un serviceStarting a service

Lorsque vous démarrez un service dans un espace de développement, les outils côté client et le contrôleur se coordonnent pour synchroniser vos fichiers source, créer votre conteneur et vos objets Kubernetes, puis exécuter votre application.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.

À un niveau plus granulaire, voici ce qui se passe lorsque vous exécutez azds up :At a more granular level, here is what happens when you run azds up:

  1. Les fichiers sont synchronisés depuis la machine de l'utilisateur vers un stockage de fichiers Azure spécifique au cluster AKS de cet utilisateur.Files are synchronized from the user’s machine to an Azure file storage that is unique to the user’s AKS cluster. Le code source, le graphique Helm et les fichiers de configuration sont chargés.The source code, Helm chart, and configuration files are uploaded. La section suivant fournit plus de détails sur le processus de synchronisation.More details on the synchronization process are available in the next section.
  2. Le contrôleur crée une demande de démarrage d'une nouvelle session.The controller creates a request to start a new session. Cette requête contient plusieurs propriétés, notamment un ID unique, un nom d'espace, le chemin vers le code source et un indicateur de débogage.This request contains several properties, including a unique ID, space name, path to source code, and a debugging flag.
  3. Le contrôleur remplace le caractère générique $(tag) dans le graphique Helm par l'ID de session unique et installe ce graphique pour votre service.The controller replaces the $(tag) placeholder in the Helm chart with the unique session ID and installs the Helm chart for your service. L'ajout d'une référence à l'ID de session unique au graphique Helm permet de relier le conteneur déployé dans le cluster AKS pour cette session spécifique à la demande de session et aux informations associées.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. Lors de l'installation du graphique Helm Chart, le serveur d'admission webhook Kubernetes ajoute des conteneurs supplémentaires au pod de votre application pour l'instrumentation et l'accès au code source de votre projet.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. Les conteneurs devspaces-proxy et devspaces-proxy-init sont ajoutés pour permettre le traçage HTTP et le routage des espaces.The devspaces-proxy and devspaces-proxy-init containers are added to provide HTTP tracing and space routing. Le conteneur devspaces-build est ajouté pour permettre au pod d'accéder à l'instance Docker et au code source du projet afin de générer le conteneur de votre application.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. Lorsque le pod de l'application est lancé, le conteneur devspaces-build et le conteneur devspaces-proxy-init sont utilisés pour générer le conteneur de l'application.When the application's pod is started, the devspaces-build container and devspaces-proxy-init container are used to build the application container. Le conteneur d'application et les conteneurs devspaces-proxy sont alors démarrés.The application container and devspaces-proxy containers are then started.
  6. Après le démarrage du conteneur d'application, la fonctionnalité côté client utilise la fonctionnalité Kubernetes port-forward pour fournir un accès HTTP à votre application sur http://localhost.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. Cette redirection de port connecte votre machine de développement au service dans votre espace de développement.This port forwarding connects your development machine to the service in your dev space.
  7. Lorsque tous les conteneurs du pod ont démarré, le service est actif.When all containers in the pod have started, the service is running. À ce stade, la fonctionnalité côté client commence à diffuser en continu les traces HTTP, stdout et stderr.At this point, the client-side functionality begins to stream the HTTP traces, stdout, and stderr. Ces informations sont affichées par la fonctionnalité côté client pour le développeur.This information is displayed by the client-side functionality for the developer.

Mise à jour d’un service en cours d’exécutionUpdating a running service

Pendant l'exécution d'un service, Azure Dev Spaces peut mettre à jour ce service si l'un des fichiers source du projet change.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 gère également la mise à jour du service différemment selon le type de fichier modifié.Dev Spaces also handles updating the service differently depending on the type of file that is changed. Il existe trois façons pour Dev Spaces de mettre à jour un service en cours d'exécution :There are three ways Dev Spaces can update a running service:

  • Mise à jour directe d’un fichierDirectly updating a file
  • Régénération et redémarrage du processus de l'application à l'intérieur du conteneur de l'application en cours d'exécutionRebuilding and restarting the application's process inside the running application's container
  • Régénération et redéploiement du conteneur de l'applicationRebuilding and redeploying the application's container

Synchronisation des fichiers Azure Dev Spaces

Certains fichiers du projet représentant des ressources statiques, notamment les fichiers html, css et cshtml, peuvent être mis à jour directement dans le conteneur de l'application, sans aucun redémarrage.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. Si une ressource statique change, le nouveau fichier est synchronisé avec l'espace de développement puis utilisé par le conteneur courant.If a static asset changes, the new file is synchronized to the dev space and then used by the running container.

Les modifications apportées aux fichiers tels que le code source ou les fichiers de configuration de l'application peuvent être appliquées en redémarrant le processus de l'application dans le conteneur actif.Changes to files such as source code or application configuration files can be applied by restarting the application's process within the running container. Une fois ces fichiers synchronisés, le processus de l'application est relancé dans le conteneur en cours d'exécution à l’aide du processus devhostagent.Once these files are synchronized, the application's process is restarted within the running container using the devhostagent process. Lors de la création initiale du conteneur de l'application, le contrôleur remplace la commande de démarrage de l'application par un processus différent appelé devhostagent.When initially creating the application's container, the controller replaces the startup command for the application with a different process called devhostagent. Le processus réel de l'application est alors exécuté en tant que processus enfant sous devhostagent, et sa sortie est extraite à l’aide de 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. Le processus devhostagent fait également partie de Dev Spaces et peut exécuter des commandes dans le conteneur courant pour le compte de Dev Spaces.The devhostagent process is also part of Dev Spaces and can execute commands in the running container on behalf of Dev Spaces. Lors d'un redémarrage, devhostagent :When performing a restart, devhostagent:

  • Arrête le ou les processus actuels associés à l’applicationStops the current process or processes associated with the application
  • Régénère l'applicationRebuilds the application
  • Redémarre le ou les processus associés à l'applicationRestarts the process or processes associated with the application

La façon dont devhostagent exécute les étapes précédentes est définie dans le fichier de configuration azds.yaml.The way devhostagent executes the preceding steps is configured in the azds.yaml configuration file. Cette configuration est détaillée dans une section ultérieure.This configuration is detailed in a later section.

Les mises à jour des fichiers du projet tels que les fichiers Dockerfile, les fichiers csproj ou toute partie du graphique Helm nécessitent la régénération et le redéploiement du conteneur de l’application.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. Si un de ces fichiers est synchronisé avec l’espace de développement, le contrôleur exécute la commande helm upgrade, puis un conteneur de l’application est régénéré et redéployé.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.

Synchronisation de fichiersFile Synchronization

La première fois qu’une application démarre dans un espace de développement, tous les fichiers de l’application source sont chargés.The first time an application is started in a dev space, all the application's source files are uploaded. Pendant l’exécution de l’application et lors des redémarrages ultérieurs, seuls les fichiers modifiés sont chargés.While the application is running and on later restarts, only the changed files are uploaded. Deux fichiers sont utilisés pour coordonner ce processus : un fichier côté client et un autre côté contrôleur.Two files are used to coordinate this process: a client-side file and a controller-side file.

Stocké dans un répertoire temporaire, le fichier côté client est nommé en fonction du hachage du répertoire du projet en cours d’exécution dans les espaces de développement.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. Par exemple, sur Windows, le fichier peut être Users\USERNAME\AppData\Local\Temp\1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.synclog pour votre projet.For example, on Windows you would have a file like Users\USERNAME\AppData\Local\Temp\1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef.synclog for your project. Sur Linux, le fichier côté client est stocké dans le répertoire /tmp.On Linux, the client-side file is stored in the /tmp directory. Vous pouvez trouver le répertoire sur macOS en exécutant la commande echo $TMPDIR.You can find the directory on macOS by running the echo $TMPDIR command.

Ce fichier au format JSON contient :This file is in JSON format and contains:

  • Une entrée pour chaque fichier de projet synchronisé avec l’espace de développementAn entry for each project file that is synchronized with the dev space
  • Un ID de synchronisationA synchronization ID
  • L’horodatage de la dernière opération de synchronisationThe timestamp of the last sync operation

Chaque entrée du fichier du projet contient un chemin d’accès au fichier et son horodatage.Each project file entry contains a path to the file and its timestamp.

Le fichier côté contrôleur est stocké sur le cluster AKS.The controller-side file is stored on the AKS cluster. Il contient l’ID de synchronisation et l’horodatage de la dernière synchronisation.It contains the synchronization ID and the timestamp of the last synchronization.

Une synchronisation se produit lorsque les horodatages de synchronisation ne correspondent pas entre les fichiers côté client et côté contrôleur.A sync happens when the synchronization timestamps do not match between the client-side and the controller-side files. Au cours d'une synchronisation, les outils côté client effectuent une itération sur les entrées du fichier côté client.During a sync, the client-side tooling iterates over the file entries in the client-side file. Si l'horodatage du fichier est postérieur à l'horodatage de synchronisation, ce fichier est synchronisé avec l'espace de développement.If the file's timestamp is after the sync timestamp, that file is synced to the dev space. Une fois la synchronisation terminée, les horodatages de synchronisation sont mis à jour sur les fichiers côté client et côté contrôleur.Once the sync is complete, the sync timestamps are updated on both the client-side and controller-side files.

Tous les fichiers du projet sont synchronisés si le fichier côté client n'est pas présent.All of the project files are synced if the client-side file is not present. Ce comportement vous permet de forcer une synchronisation complète en supprimant le fichier côté client.This behavior allows you to force a full sync by deleting the client-side file.

Fonctionnement du routageHow routing works

Un espace de développement est créé par dessus AKS et utilise les mêmes concepts de mise en réseau.A dev space is built on top of AKS and uses the same networking concepts. Azure Dev Spaces dispose également d'un service ingressmanager centralisé et déploie son propre contrôleur d'entrée sur le cluster AKS.Azure Dev Spaces also has a centralized ingressmanager service and deploys its own Ingress Controller to the AKS cluster. Le service ingressmanager surveille les clusters AKS avec des espaces de développement et augmente le contrôleur d'entrée Azure Dev Spaces dans le cluster avec des objets d’entrée pour le routage vers les pods d’application.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. Le conteneur devspaces-proxy de chaque pod ajoute un en-tête HTTP azds-route-as pour le trafic HTTP vers un espace de développement basé sur l'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. Par exemple, une requête à l'URL http://azureuser.s.default.serviceA.fedcba09...azds.io obtiendrait un en-tête HTTP avec azds-route-as: azureuser.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. Le conteneur devspaces-proxy n'ajoutera pas d'en-tête azds-route-as s'il y en a déjà un.The devspaces-proxy container will not add an azds-route-as header if one is already present.

Lorsqu'une requête HTTP est envoyée à un service extérieur au cluster, la requête est transmise au contrôleur d’entrée.When an HTTP request is made to a service from outside the cluster, the request goes to the Ingress controller. Le contrôleur d’entrée achemine la requête directement au pod approprié en fonction de ses objets et règles d’entrée.The Ingress controller routes the request directly to the appropriate pod based on its Ingress objects and rules. Le conteneur devspaces-proxy du pod reçoit la requête, ajoute l'en-tête azds-route-as basé sur l'URL, puis achemine la requête vers le conteneur d’application.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.

Lorsqu'une requête HTTP est envoyée à un service depuis un autre service au sein du cluster, la requête transite d'abord par le conteneur devspaces-proxy du service appelant.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. Le conteneur devspaces-proxy examine la requête HTTP et vérifie l'en-tête azds-route-as.The devspaces-proxy container looks at the HTTP request and checks the azds-route-as header. Selon l'en-tête, le conteneur devspaces-proxy cherchera l'adresse IP du service associé à la valeur de cet en-tête.Based on the header, the devspaces-proxy container will look up the IP address of the service associated with the header value. Si une adresse IP est trouvée, le conteneur devspaces-proxy redirige la requête vers cette adresse IP.If an IP address is found, the devspaces-proxy container reroutes the request to that IP address. Si aucune adresse IP n'est trouvée, le conteneur devspaces-proxy achemine la requête vers le conteneur de l’application parente.If an IP address is not found, the devspaces-proxy container routes the request to the parent application container.

Par exemple, les applications serviceA et serviceB sont déployées sur un espace de développement parent appelé default (par défaut).For example, the applications serviceA and serviceB are deployed to a parent dev space called default. serviceA s'appuie sur serviceB et lui passe des appels HTTP.serviceA relies on serviceB and makes HTTP calls to it. Azure User crée un espace de développement enfant basé sur l'espace default (par défaut), appelé azureuser.Azure User creates a child dev space based on the default space called azureuser. Azure User déploie également sa propre version de serviceA sur son espace enfant.Azure User also deploys their own version of serviceA to their child space. Lorsqu'une requête est envoyée à http://azureuser.s.default.serviceA.fedcba09...azds.io :When a request is made to http://azureuser.s.default.serviceA.fedcba09...azds.io:

Routage Azure Dev Spaces

  1. Le contrôleur d’entrée recherche l'adresse IP du pod associé à l'URL, soit serviceA.azureuser.The Ingress controller looks up the IP for the pod associated with the URL, which is serviceA.azureuser.
  2. Le contrôleur d'entrée trouve l'adresse IP du pod dans l'espace de développement de l'utilisateur Azure et achemine la requête vers le pod 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. Le conteneur devspaces-proxy du pod serviceA.azureuser reçoit la requête et ajoute azds-route-as: azureuser comme en-tête HTTP.The devspaces-proxy container in the serviceA.azureuser pod receives the request and adds azds-route-as: azureuser as an HTTP header.
  4. Le conteneur devspaces-proxy du pod serviceA.azureuser achemine la requête vers le conteneur serviceA dans le pod serviceA.azureuser.The devspaces-proxy container in the serviceA.azureuser pod routes the request to the serviceA application container in the serviceA.azureuser pod.
  5. L'application serviceA du pod serviceA.azureuser appelle serviceB.The serviceA application in the serviceA.azureuser pod makes a call to serviceB. L'application serviceA contient également un code pour conserver l'en-tête azds-route-as existant, soit azds-route-as: azureuser dans ce cas.The serviceA application also contains code to preserve the existing azds-route-as header, which in this case is azds-route-as: azureuser.
  6. Le conteneur devspaces-proxy du pod serviceA.azureuser reçoit la requête et recherche l'IP de serviceB selon la valeur de l'en-tête azds-route-as.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. Le conteneur devspaces-proxy du pod serviceA.azureuser ne trouve pas d'IP pour serviceB.azureuser.The devspaces-proxy container in the serviceA.azureuser pod does not find an IP for serviceB.azureuser.
  8. Le conteneur devspaces-proxy du pod serviceA.azureuser cherche l'IP pour serviceB dans l'espace parent, soit serviceB.default.The devspaces-proxy container in the serviceA.azureuser pod looks up the IP for serviceB in the parent space, which is serviceB.default.
  9. Le conteneur devspaces-proxy du pod serviceA.azureuser trouve l'IP pour serviceB.default et achemine la requête vers le pod 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. Le conteneur devspaces-proxy du pod serviceB.default reçoit la requête et l'achemine vers le conteneur d’application serviceB dans le pod serviceB.default.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. L'application serviceB du pod serviceB.default renvoie une réponse au pod serviceA.azureuser.The serviceB application in the serviceB.default pod returns a response to the serviceA.azureuser pod.
  12. Le conteneur devspaces-proxy du pod serviceA.azureuser reçoit la réponse et l’achemine vers le conteneur d’application serviceA dans le pod serviceA.azureuser.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. L'application serviceA reçoit la réponse et renvoie ensuite sa propre réponse.The serviceA application receives the response and then returns its own response.
  14. Le conteneur devspaces-proxy du pod serviceA.azureuser reçoit la réponse du conteneur d'application serviceA et achemine la réponse vers l'appelant original en dehors du cluster.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.

Tout autre trafic TCP non HTTP transite par le contrôleur d’entrée et les conteneurs devspaces-proxy ne sont pas modifiés.All other TCP traffic that is not HTTP passes through the Ingress controller and devspaces-proxy containers unmodified.

Configuration de l'exécution de votre codeHow running your code is configured

Azure Dev Spaces utilise le fichier azds.yaml pour installer et configurer votre service.Azure Dev Spaces uses the azds.yaml file to install and configure your service. Le contrôleur utilise la propriété install du fichier azds.yaml pour installer le graphique Helm et créer les objets 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)
...

Par défaut, la commande prep génère le graphique Helm.By default, the prep command will generate the Helm chart. Elle définit également la propriété install.chart sur le répertoire du graphique Helm.It also sets the install.chart property to the directory of the Helm chart. Si vous voulez utiliser un graphique Helm à un autre emplacement, vous pouvez mettre à jour cette propriété en fonction de cet emplacement.If you wanted to use a Helm chart in a different location, you can update this property to use that location.

Lors de l'installation des graphiques Helm, Azure Dev Spaces fournit un moyen de remplacer les valeurs du graphique Helm.When installing the Helm charts, Azure Dev Spaces provides a way to override values in the Helm chart. Les valeurs par défaut du graphique Helm sont affichées dans charts/APP_NAME/values.yaml.The default values for the Helm chart are in charts/APP_NAME/values.yaml.

En utilisant la propriété install.values, vous pouvez répertorier un ou plusieurs fichiers qui définissent les valeurs que vous voulez remplacer dans le graphique Helm.Using the install.values property, you can list one or more files that define values you want replaced in the Helm chart. Par exemple, vous pouvez utiliser cette fonctionnalité de remplacement pour obtenir une configuration de nom d'hôte ou de base de données spécifique lors de l'exécution de votre application dans un espace de développement.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. Vous pouvez également ajouter un ? .You can also add a ? à la fin de n'importe quel nom de fichier pour le définir comme facultatif.at the end of any of the file names to set it as optional.

La propriété install.set vous permet de configurer une ou plusieurs valeurs à remplacer dans le graphique Helm.The install.set property allows you to configure one or more values you want replaced in the Helm chart. Toutes les valeurs configurées dans install.set remplaceront les valeurs configurées dans les fichiers répertoriés dans install.values.Any values configured in install.set will override values configured in files listed in install.values. Les propriétés sous install.set dépendent des valeurs du graphique Helm et peuvent être différentes selon le graphique Helm généré.The properties under install.set are dependent on the values in the Helm chart and may be different depending on the generated Helm chart.

Dans l'exemple ci-dessus, la propriété install.set.replicaCount indique au contrôleur combien d'instances de votre application doivent être exécutées dans votre espace de développement.In the above example, the install.set.replicaCount property tells the controller how many instances of your application to run in your dev space. Selon votre scénario, vous pouvez augmenter cette valeur, mais cela aura un impact sur la connexion d'un débogueur au pod de votre application.Depending on your scenario, you can increase this value, but it will have an impact on attaching a debugger to your application's pod. Pour plus d’informations, consultez l’article de dépannage.For more information, see the troubleshooting article.

Dans le graphique Helm généré, l'image du conteneur est définie sur {{ .Values.image.repository }}:{{ .Values.image.tag }} .In the generated Helm chart, the container image is set to {{ .Values.image.repository }}:{{ .Values.image.tag }}. Le ficher azds.yaml définit la propriété install.set.image.tag sur $(tag) par défaut, utilisée comme valeur pour {{ .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 }}. En définissant la propriété install.set.image.tag de cette façon, l’image du conteneur de votre application sera étiquetée d'une manière distincte lors de l'exécution des espaces de développement Azure.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. Dans ce cas spécifique, l'image est étiquetée ainsi : <valeur de image.repository>:$(tag) .In this specific case, the image is tagged as <value from image.repository>:$(tag). Vous devez utiliser la variable $(tag) comme valeur de install.set.image.tag pour que Dev Spaces reconnaisse et situe le conteneur dans le cluster AKS.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.

Dans l'exemple ci-dessus, azds.yaml définit install.set.ingress.hosts.In the above example, azds.yaml defines install.set.ingress.hosts. La propriété install.set.ingress.hosts définit un format de nom d'hôte pour les points de terminaison publics.The install.set.ingress.hosts property defines a host name format for public endpoints. Cette propriété utilise également $$(spacePrefix) , $(rootSpacePrefix) , et $(hostSuffix) , valeurs fournies par le contrôleur.This property also uses $(spacePrefix), $(rootSpacePrefix), and $(hostSuffix), which are values provided by the controller.

$$(spacePrefix) est le nom de l'espace de développement enfant, qui prend la forme SPACENAME.s.The $(spacePrefix) is the name of the child dev space, which takes the form of SPACENAME.s. $$(rootSpacePrefix) est le nom de l'espace parent.The $(rootSpacePrefix) is the name of the parent space. Par exemple, si azureuser est un espace enfant de default, la valeur pour $(rootSpacePrefix) est default, et la valeur de $(spacePrefix) est 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. Si l'espace n'est pas un espace enfant, $(spacePrefix) est vide.If the space is not a child space, $(spacePrefix) is blank. Par exemple, si l'espace default n'a pas d'espace parent, la valeur pour $(rootSpacePrefix) est default et la valeur de $(spacePrefix) est vide.For example, if the default space has no parent space, the value for $(rootSpacePrefix) is default and the value of $(spacePrefix) is blank. $$(hostSuffix) est un suffixe DNS qui pointe vers le contrôleur d'entrée Azure Dev Spaces exécuté dans votre cluster AKS.The $(hostSuffix) is a DNS suffix that points to the Azure Dev Spaces Ingress Controller that runs in your AKS cluster. Ce suffixe DNS correspond à une entrée DNS générique, par exemple *.RANDOM_VALUE.eus.azds.io, créée lorsque le contrôleur Azure Dev Spaces a été ajouté à votre cluster AKS.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.

Dans le fichier azds.yaml ci-dessus, vous pouvez également mettre à jour install.set.ingress.hosts pour changer le nom d'hôte de votre application.In the above azds.yaml file, you could also update install.set.ingress.hosts to change the host name of your application. Par exemple, si vous voulez simplifier le nom d'hôte de votre application de $$(spacePrefix)$(rootSpacePrefix)$(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).

Afin de générer le conteneur pour votre application, le contrôleur utilise les sections ci-dessous du fichier de configuration 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}
...

Le contrôleur utilise un Dockerfile pour générer et exécuter votre application.The controller uses a Dockerfile to build and run your application.

La propriété build.context indique le répertoire où figurent les Dockerfiles.The build.context property lists the directory where the Dockerfiles exist. La propriété build.dockerfile définit le nom du Dockerfile pour générer la version de production de l'application.The build.dockerfile property defines the name of the Dockerfile for building the production version of the application. La propriété configurations.develop.build.build.dockerfile configure le nom du Dockerfile pour la version de développement de l'application.The configurations.develop.build.dockerfile property configures the name of the Dockerfile for the development version of the application.

Avoir différents Dockerfiles pour le développement et la production vous permet d'activer certains éléments pendant le développement et de désactiver ces éléments pour les déploiements en production.Having different Dockerfiles for development and production allows you to enable certain things during development and disable those items for production deployments. Par exemple, vous pouvez activer le débogage ou la journalisation détaillée pendant le développement et le désactiver dans un environnement de production.For example, you can enable debugging or more verbose logging during development and disable in a production environment. Vous pouvez également mettre à jour ces propriétés si vos Dockerfiles sont nommés différemment ou se trouvent dans un autre emplacement.You can also update these properties if your Dockerfiles are named differently or are in a different location.

Pour accélérer l’itération pendant le développement, Azure Dev Spaces synchronisera les changements de votre projet local et mettra à jour progressivement votre application.To help you rapidly iterate during development, Azure Dev Spaces will sync changes from your local project and incrementally update your application. La section ci-dessous du fichier de configuration azds.yaml sert à configurer la synchronisation et la mise à jour :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}"]
...

Les fichiers et répertoires qui synchroniseront les changements sont répertoriés dans la propriété configurations.develop.container.sync.The files and directories that will sync changes are listed in the configurations.develop.container.sync property. Ces répertoires sont synchronisés initialement lorsque vous exécutez la commande up et lorsque des changements sont détectés.These directories are synced initially when you run the up command as well as when changes are detected. Si vous souhaitez synchroniser des répertoires supplémentaires ou différents avec votre espace de développement, vous pouvez modifier cette propriété.If there are additional or different directories you would like synced to your dev space, you can change this property.

La propriété configurations.develop.container.iterate.buildCommands indique comment générer l'application dans un scénario de développement.The configurations.develop.container.iterate.buildCommands property specifies how to build the application in a development scenario. La propriété configurations.develop.container.command fournit la commande pour exécuter l'application dans un scénario de développement.The configurations.develop.container.command property provides the command for running the application in a development scenario. Vous pouvez mettre à jour l'une ou l'autre de ces propriétés si vous souhaitez utiliser d'autres indicateurs ou paramètres de génération ou d'exécution pendant le développement.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.

La propriété configurations.develop.container.iterate.processesToKill répertorie les processus à tuer pour arrêter l'application.The configurations.develop.container.iterate.processesToKill lists the processes to kill to stop the application. Vous pouvez mettre à jour cette propriété pour changer le comportement de redémarrage de votre application pendant le développement.You may want to update this property if you want to change the restart behavior of your application during development. Par exemple, si vous avez mis à jour les propriétés configurations.develop.container.iterate.buildCommands ou configurations.develop.container.command pour modifier la génération ou le lancement de l'application, vous devrez peut-être changer quels processus sont arrêtés.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.

Lorsque vous préparez votre code à l'aide de la commande azds prep, vous avez la possibilité d'ajouter l'indicateur --public.When preparing your code using the azds prep command, you have the option of adding the --public flag. L'ajout de l'indicateur --public crée une URL accessible au public pour votre application.Adding the --public flag creates a publicly accessible URL for your application. Si vous omettez cet indicateur, l'application n'est accessible que dans le cluster ou en utilisant le tunnel localhost.If you omit this flag, the application is only accessible within the cluster or using the localhost tunnel. Après avoir exécuté la commande azds prep, vous pouvez modifier ce paramètre en changeant la propriété ingress.enabled dans charts/APPNAME/values.yaml :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

Déboguer votre codeDebug your code

Pour les applications Java,.NET et Node.js, vous pouvez déboguer votre application exécutée directement dans votre espace de développement en utilisant Visual Studio Code ou 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 et Visual Studio fournissent des outils pour se connecter à votre espace de développement, lancer votre application et joindre un débogueur.Visual Studio Code and Visual Studio provide tooling to connect to your dev space, launch your application, and attach a debugger. Après avoir lancé azds prep, vous pouvez ouvrir votre projet dans Visual Studio Code ou Visual Studio.After running azds prep, you can open your project in Visual Studio Code or Visual Studio. Visual Studio Code ou Visual Studio généreront leurs propres fichiers de configuration pour la connexion, une opération distincte de l’exécution de azds prep.Visual Studio Code or Visual Studio will generate their own configuration files for connecting which is separate from running azds prep. Depuis Visual Studio Code ou Visual Studio, vous pouvez définir des points d'arrêt et lancer votre application dans votre espace de développement.From within Visual Studio Code or Visual Studio, you can set breakpoints and launch your application to your dev space.

Débogage de votre code

Lorsque vous lancez votre application en utilisant Visual Studio Code ou Visual Studio pour le débogage, ces programmes gèrent le lancement et la connexion à votre espace de développement de la même manière qu'en exécutant 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. Les outils côté client de Visual Studio Code et Visual Studio fournissent également un paramètre supplémentaire avec des informations spécifiques pour le débogage.The client-side tooling in Visual Studio Code and Visual Studio also provide an additional parameter with specific information for debugging. Ce paramètre contient le nom de l'image du débogueur, l'emplacement du débogueur dans cette image, et l'emplacement de destination dans le conteneur de l'application pour monter le dossier du débogueur.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.

L'image du débogueur est automatiquement déterminée par les outils côté client.The debugger image is automatically determined by the client-side tooling. Ces outils adoptent une méthode similaire à celle utilisée lors de l'exécution du Dockerfile et du graphique Helm Chart générés lors de l'exécution de azds prep.It uses a method similar to the one used during Dockerfile and Helm chart generate when running azds prep. Une fois le débogueur monté dans l'image de l'application, il est lancé en utilisant azds exec.After the debugger is mounted in the application's image, it is run using azds exec.

Partage d’un espace de développementSharing a dev space

Lorsque vous travaillez en équipe, vous pouvez partager un espace de développement avec tous les membres de cette équipe et créer des espaces de développement dérivés.When working with a team, you can share a dev space across an entire team and create derived dev spaces. Un espace de développement peut être utilisé par toute personne ayant un accès contributeur au groupe de ressources de cet espace de développement.A dev space can be used by anyone with contributor access to the dev space's resource group.

Vous pouvez également créer un espace de développement dérivé d'un autre espace de développement.You can also create a new dev space that is derived from another dev space. Lorsque vous créez un espace de développement dérivé, l’étiquette azds.io/parent-space=PARENT-SPACE-NAME est ajouté à l'espace de noms de l'espace de développement dérivé.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. De plus, toutes les applications de l'espace de développement parent sont partagées avec l'espace de développement dérivé.Also, all applications from the parent dev space are shared with the derived dev space. Si vous déployez une version mise à jour d'une application dans l'espace de développement dérivé, elle n'existera que dans cet espace de développement dérivé, et l'espace de développement parent ne sera pas affecté.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. Vous pouvez avoir un maximum de trois niveaux d'espaces de développement dérivés ou espaces grands-parents.You can have a maximum of three levels of derived dev spaces or grandparent spaces.

L'espace de développement dérivé acheminera également de façon intelligente les requêtes entre ses propres applications et les applications partagées par son parent.The derived dev space will also intelligently route requests between its own applications and the applications shared from its parent. Le routage fonctionne en tentant d'acheminer la requête vers une application dans l'espace de développement dérivé, puis en revenant à l'application partagée depuis l'espace de développement 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. Le routage reviendra à l'application partagée dans l'espace grand-parent si l'application ne figure pas dans l'espace parent.The routing will fall back to the shared application in the grandparent space if the application is not in the parent space.

Par exemple :For example:

  • L’espace de développement default possède des applications serviceA et serviceB .The dev space default has applications serviceA and serviceB .
  • L’espace de développement azureuser est dérivé de default.The dev space azureuser is derived from default.
  • Une version mise à jour de serviceA est déployée sur azureuser.An updated version of serviceA is deployed to azureuser.

Lorsque vous utilisez azureuser, toutes les requêtes envoyées à serviceA seront acheminées vers la version mise à jour dans azureuser.When using azureuser, all requests to serviceA will be routed to the updated version in azureuser. Une requête envoyée à serviceB tente d’abord d’être acheminée vers la version azureuser de serviceB.A request to serviceB will first try to be routed to the azureuser version of serviceB. Comme elle n’existe pas, elle sera acheminée vers la version default de serviceB.Since it does not exist, it will be routed to the default version of serviceB. Si la version azureuser de serviceA est supprimée, toutes les requêtes envoyées à serviceA seront retournées à l’aide de la version default de serviceA.If the azureuser version of serviceA is removed, all requests to serviceA will fall back to using the default version of serviceA.

Étapes suivantesNext steps

Pour commencer à utiliser Azure Dev Spaces, consultez les guides de démarrage rapide suivants :To get started using Azure Dev Spaces, see the following quickstarts:

Pour bien démarrer avec le développement en équipe, consultez les articles sur les procédures ci-dessous :To get started with team development, see the following how-to articles: