Quel est l'intérêt de WORKDIR sur Dockerfile?

Question

J'apprends Docker. Pendant de nombreuses fois, j'ai vu que Dockerfile a la commande WORKDIR :

 FROM node:latest
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY package.json /usr/src/app/
RUN npm install
COPY . /usr/src/app
EXPOSE 3000
CMD [ "npm", "start" ] 
 

Je ne peux pas simplement omettre WORKDIR et Copy et avoir juste mon Dockerfile à la racine de mon projet? Quels sont les inconvénients de cette approche?

Answer 1

Selon la documentation:

Le WORKDIR instruction définit le répertoire de travail pour tout EXÉCUTER, CMD, Point d'entrée, COPIER et AJOUTER des instructions qui la suivent dans le Dockerfile.

Aussi, dans le menu fixe les meilleures pratiques , il vous recommande de l'utiliser:

... vous devez utiliser WORKDIR au lieu de la prolifération des instructions comme EXÉCUTEZ le cd ... && faire-quelque chose, qui sont difficiles à lire, de dépannage et de maintenir.

Je suggère de le garder.

Je pense que vous pouvez restructurer le Dockerfile à quelque chose comme:

FROM node:latest
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
COPY package.json .
RUN npm install
COPY . ./
EXPOSE 3000
CMD [ "npm", "start" ] 

Answer 2

Tu n'as pas à

RUN mkdir -p /usr/src/app

Il sera créé automatiquement lorsque vous spécifiez votre WORKDIR

 FROM node:latest
WORKDIR /usr/src/app
COPY package.json .
RUN npm install
COPY . ./
EXPOSE 3000
CMD [ "npm", "start" ] 
 

Answer 3

Vous pouvez penser à de la WORKDIR comme cd à l'intérieur du conteneur (il affecte les commandes à venir plus tard dans le Dockerfile, comme l' RUN de la commande). Si vous avez supprimé WORKDIR dans l'exemple ci-dessus, RUN npm install ne fonctionne pas car vous ne serait pas dans l' /usr/src/app répertoire à l'intérieur de votre conteneur.

Je ne vois pas comment ce serait liée à l'endroit où vous mettez votre Dockerfile (depuis votre Dockerfile emplacement sur la machine hôte n'a rien à voir avec la ddt à l'intérieur du conteneur). Vous pouvez mettre le Dockerfile où vous le souhaitez dans votre projet. Toutefois, le premier argument de COPY est un chemin relatif, donc, si vous déplacez votre Dockerfile vous devez mettre à jour ceux - COPY des commandes.

Answer 4

Avant d'appliquer WORKDIR. Ici, le WORKDIR est au mauvais endroit et n'est pas utilisé à bon escient.

 FROM microsoft/aspnetcore:2
COPY --from=build-env /publish /publish
WORKDIR /publish
ENTRYPOINT ["dotnet", "/publish/api.dll"]
 

Nous avons corrigé le code ci-dessus pour placer WORKDIR au bon endroit et optimisé les instructions suivantes en supprimant /Publish

 FROM microsoft/aspnetcore:2
WORKDIR /publish
COPY --from=build-env /publish .
ENTRYPOINT ["dotnet", "/api.dll"]
 

Answer 5

Méfiez-vous de l'utilisation de vars la cible nom de répertoire pour WORKDIR - faire qui semble résulter en un "ne peut pas normaliser rien" erreur fatale. OMI, il est également important de souligner que, WORKDIR se comporte de la même manière qu' mkdir -p <path> c'est à dire tous les éléments de la trajectoire sont créés s'ils n'existent pas déjà.

Mise à JOUR: J'ai rencontré le problème lié à la variable (mentionné ci-dessus), alors que l'exécution d'un multi-étape de build - il apparaît aujourd'hui que l'aide d'une variable est fine si elle (la variable) est "portée" par exemple, dans la suite, le 2e WORKDIR référence échoue ...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
WORKDIR $varname

attendu qu'il réussisse dans ce ...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
ENV varname varval
WORKDIR $varname

.oO(c'est Peut-être dans les docs & je l'ai raté)