Qual è il punto di WORKDIR su Dockerfile?

Sto imparando Docker. Per molte volte ho visto che Dockerfileha il WORKDIRcomando:

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

Non posso semplicemente omettere WORKDIRe Copyavere il mio Dockerfilealla radice del mio progetto? Quali sono gli svantaggi dell'utilizzo di questo approccio?

Secondo la documentazione :

L'istruzione WORKDIR imposta la directory di lavoro per qualsiasi istruzione RUN, CMD, ENTRYPOINT, COPY e ADD che la segue nel Dockerfile. Se la WORKDIR non esiste, verrà creata anche se non viene utilizzata in nessuna istruzione Dockerfile successiva.

Inoltre, nelle migliori pratiche Docker ti consiglia di usarlo:

... dovresti usare WORKDIR invece di proliferare istruzioni come RUN cd… && do-something, che sono difficili da leggere, risolvere e mantenere.

Suggerirei di tenerlo.

Penso che tu possa rifattorizzare il tuo Dockerfile in qualcosa di simile:

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

Non devi

RUN mkdir -p /usr/src/app

Questo verrà creato automaticamente quando specifichi il tuo WORKDIR

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

Puoi pensare a WORKDIRcome un cdall'interno del contenitore (influisce sui comandi che vengono successivamente nel Dockerfile, come il RUNcomando). Se rimuovessi WORKDIRnel tuo esempio sopra, RUN npm installnon funzionerebbe perché non saresti nella /usr/src/appdirectory all'interno del tuo contenitore.

Non vedo come questo sarebbe correlato a dove metti il ​​tuo Dockerfile (dato che la tua posizione Dockerfile sulla macchina host non ha nulla a che fare con il pwd all'interno del contenitore). Puoi inserire il Dockerfile dove preferisci nel tuo progetto. Tuttavia, il primo argomento di COPYè un percorso relativo, quindi se sposti il ​​Dockerfile potresti dover aggiornare quei COPYcomandi.

Prima di applicare WORKDIR. Qui il WORKDIR si trova nel posto sbagliato e non viene usato saggiamente.

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

Abbiamo corretto il codice precedente per inserire WORKDIR nella posizione corretta e ottimizzato le seguenti istruzioni rimuovendo /Publish

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

WORKDIRFare attenzione a usare vars come nome della directory di destinazione per - fare ciò sembra risultare in un errore irreversibile "non è possibile normalizzare nulla". IMO, vale anche la pena sottolineare che WORKDIRsi comporta allo stesso modo, mkdir -p <path>cioè tutti gli elementi del percorso vengono creati se non esistono già.

AGGIORNAMENTO: ho riscontrato il problema relativo alla variabile (menzionato sopra) durante l'esecuzione di una build in più fasi - ora sembra che l'uso di una variabile vada bene - se (la variabile) è "nell'ambito", ad esempio nel seguito, il 2 ° WORKDIRriferimento fallisce ...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
WORKDIR $varname

mentre ci riesce ...

FROM <some image>
ENV varname varval
WORKDIR $varname

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

.oO ( Forse è nei documenti e l'ho perso )

Fare attenzione a dove si imposta WORKDIRperché può influire sul flusso di integrazione continua. Ad esempio, impostarlo su /home/circleci/projectcauserà un errore come .ssho qualunque cosa stia facendo il circleci remoto al momento dell'installazione.