Was ist der Sinn von WORKDIR auf Dockerfile?

Ich lerne Docker. Ich habe schon oft gesehen, dass Dockerfiledas WORKDIRBefehl hat:

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” ] 

Kann ich nicht einfach weglassen WORKDIRund Copymeine Dockerfilean der Wurzel meines Projekts haben? Was sind die Nachteile dieses Ansatzes?

Laut Dokumentation :

Die Anweisung WORKDIR legt das Arbeitsverzeichnis für alle Anweisungen RUN, CMD, ENTRYPOINT, COPY und ADD fest, die in der Docker-Datei darauf folgen. Wenn das WORKDIR nicht vorhanden ist, wird es erstellt, auch wenn es in keiner nachfolgenden Dockerfile-Anweisung verwendet wird.

In den Best Practices von Docker wird außerdem empfohlen, Folgendes zu verwenden:

... Sie sollten WORKDIR verwenden, anstatt Anweisungen wie RUN cd zu verbreiten ... && etwas zu tun, die schwer zu lesen, zu beheben und zu warten sind.

Ich würde vorschlagen, es zu behalten.

Ich denke, Sie können Ihre Docker-Datei in Folgendes umgestalten:

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

Das musst du nicht

RUN mkdir -p /usr/src/app

Dies wird automatisch erstellt, wenn Sie Ihre angeben WORKDIR

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

Sie können sich WORKDIRwie in einem cdContainer vorstellen (dies wirkt sich auf Befehle aus, die später in der Docker-Datei eingehen, wie z. B. den RUNBefehl). Wenn Sie WORKDIRin Ihrem obigen Beispiel entfernt haben, RUN npm installwürde dies nicht funktionieren, da Sie sich nicht im /usr/src/appVerzeichnis in Ihrem Container befinden würden.

Ich sehe nicht, wie dies damit zusammenhängt, wo Sie Ihre Docker-Datei ablegen (da Ihr Docker-Datei-Speicherort auf dem Host-Computer nichts mit dem pwd im Container zu tun hat). Sie können die Docker-Datei an einer beliebigen Stelle in Ihrem Projekt ablegen. Das erste Argument COPYist jedoch ein relativer Pfad. Wenn Sie also Ihre Docker-Datei verschieben, müssen Sie diese COPYBefehle möglicherweise aktualisieren .

Vor dem Auftragen von WORKDIR. Hier ist der WORKDIR am falschen Ort und wird nicht mit Bedacht eingesetzt.

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

Wir haben den obigen Code korrigiert, um WORKDIR an der richtigen Stelle zu platzieren, und die folgenden Anweisungen durch Entfernen optimiert /Publish

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

Achten Sie darauf, dass Sie vars nicht als Zielverzeichnisnamen verwenden. WORKDIRDies scheint zu einem schwerwiegenden Fehler zu führen, bei dem nichts normalisiert werden kann. IMO, es ist auch erwähnenswert, dass es WORKDIRsich genauso verhält wie mkdir -p <path>alle Elemente des Pfades erstellt werden, wenn sie noch nicht vorhanden sind.

UPDATE: Ich bin beim Ausführen eines mehrstufigen Builds auf das oben erwähnte variable Problem gestoßen. Es scheint nun, dass die Verwendung einer Variablen in Ordnung ist. Wenn sie (die Variable) "im Gültigkeitsbereich" ist, z. B. im Folgenden, WORKDIRschlägt die zweite Referenz fehl ...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
WORKDIR $varname

in der Erwägung, dass dies gelingt ...

FROM <some image>
ENV varname varval
WORKDIR $varname

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

.oO ( Vielleicht ist es in den Dokumenten und ich habe es verpasst )

Seien Sie vorsichtig, wo Sie einstellen, WORKDIRda dies den kontinuierlichen Integrationsfluss beeinträchtigen kann. Wenn Sie es beispielsweise so einstellen, /home/circleci/projectwird ein Fehler verursacht, wie .sshoder was auch immer der Remote Circleci zur Einrichtungszeit tut.