web-dev-qa-db-fra.com

Quand, où et comment Visual Studio 2017 définit-il la variable d'environnement DOCKER_BUILD_SOURCE?

Lors de la création d'une nouvelle application .NET de base avec prise en charge de docker dans Visual Studio 2017, un certain nombre de fichiers docker-compose.yml sont créés. Le fichier docker-compose.vs.debug.yml et la variante de publication contiennent tous deux une référence à une variable d'environnement appelée DOCKER_BUILD_SOURCE:

version: '2'

services:
  app:
    image: app:dev
    build:
      args:
        source: ${DOCKER_BUILD_SOURCE}
    environment:
      - DOTNET_USE_POLLING_FILE_WATCHER=1
    volumes:
      - ./app:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro
      - ~/clrdbg:/clrdbg:ro
    entrypoint: tail -f /dev/null
    labels:
      - "com.Microsoft.visualstudio.targetoperatingsystem=linux"

The purpose of this variable seems to be a reference to the source directory, however, it always seems to be empty.

Je n'ai pas pu trouver d'informations plus détaillées sur ce sujet ... Quelqu'un a-t-il une idée ou un pointeur sur certains documents?

dockerenvironment-variablesdocker-composevisual-studio-2017
27
Maurice CGP Peters

Je pense que cela a à voir avec la configuration qui peut être utilisée avec le CI/CD de Visual Studio Team Services. Cependant, lorsqu'elle est exécutée localement, cette valeur est vide et si vous examinez le fichier docker, vous voyez que si la valeur est vide, elle remplace "obj/Docker/publish"

Dockerfile:

DE Microsoft/aspnetcore: 1.0

Source ARG

WORKDIR/app

EXPOSE 80

COPY $ {source: -obj/Docker/publish}.

ENTRYPOINT ["dotnet", "app.dll"]

Cependant, pour moi, je ne vois pas ce dossier ni quoi que ce soit dedans. Où la "magie" se produit est dans la section des volumes. qui déplace essentiellement votre code sur le conteneur en tant que bind mound . c'est là que votre code est déplacé sur le conteneur. Il y a quelques autres choses qui se passent qui ne me sont pas claires parce que je vois une ligne dans la sortie de construction où le code est construit/publié, mais pas la commande réelle en cours d'exécution.

1
Nick

Cela n'a aucun impact réel lors de la création d'images de développement. Comme Nick l'a expliqué, nous obtenons du code en utilisant bind mount.

Ceci est utilisé lors de la création d'images pour la production à utiliser avec le fichier docker-compose.ci.build.yml, qui renvoie à obj/Docker/publish de chaque projet Web de solution.

0
Samuel