В чем смысл WORKDIR в Dockerfile?

Я изучаю Докер. Я много раз видел, что Dockerfileесть 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” ] 

Разве я не могу просто опустить WORKDIRи оставить Copyсвой Dockerfileв корне моего проекта? Каковы недостатки использования этого подхода?

По документации :

Инструкция WORKDIR устанавливает рабочий каталог для любых инструкций RUN, CMD, ENTRYPOINT, COPY и ADD, которые следуют за ней в Dockerfile. Если WORKDIR не существует, он будет создан, даже если он не будет использоваться в последующих инструкциях Dockerfile.

Кроме того, в лучших практиках Docker рекомендуется использовать его:

... вам следует использовать WORKDIR вместо множества инструкций, таких как RUN cd… && do-something, которые трудно читать, устранять неполадки и поддерживать.

Я бы посоветовал оставить его себе.

Я думаю, вы можете реорганизовать свой Dockerfile примерно так:

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

Вам не нужно

RUN mkdir -p /usr/src/app

Он будет создан автоматически, когда вы укажете свой WORKDIR

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

Вы можете думать об этом WORKDIRкак о cdвнутри контейнера (он влияет на команды, которые появляются позже в Dockerfile, например, на RUNкоманду). Если вы удалили WORKDIRв своем примере выше, RUN npm installэто не сработает, потому что вы не будете в /usr/src/appкаталоге внутри вашего контейнера.

Я не понимаю, как это связано с тем, куда вы помещаете свой Dockerfile (поскольку местоположение вашего Dockerfile на хост-машине не имеет ничего общего с pwd внутри контейнера). Вы можете разместить Dockerfile в любом месте вашего проекта. Однако первый аргумент для COPY- это относительный путь, поэтому, если вы переместите свой Dockerfile, вам может потребоваться обновить эти COPYкоманды.

Перед применением WORKDIR. Здесь WORKDIR находится не в том месте и используется неразумно.

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

Мы исправили приведенный выше код, чтобы поместить WORKDIR в нужное место, и оптимизировали следующие операторы, удалив /Publish

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

Остерегайтесь использования vars в качестве имени целевого каталога для WORKDIR- это может привести к фатальной ошибке «ничего не может нормализовать». IMO, также стоит отметить, что он WORKDIRведет себя так же, как и mkdir -p <path>все элементы пути, если они еще не существуют.

ОБНОВЛЕНИЕ: я столкнулся с проблемой, связанной с переменной (упомянутой выше), при запуске многоэтапной сборки - теперь кажется, что использование переменной нормально - если она (переменная) находится «в области действия», например, в следующем примере, вторая WORKDIRссылка не работает ...

FROM <some image>
ENV varname varval
WORKDIR $varname

FROM <some other image>
WORKDIR $varname

тогда как он преуспевает в этом ...

FROM <some image>
ENV varname varval
WORKDIR $varname

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

.oO ( Возможно, это в документации, и я это пропустил )

Будьте осторожны при установке, WORKDIRпоскольку это может повлиять на поток непрерывной интеграции. Например, установка его на /home/circleci/projectвызовет ошибку, что-то вроде .sshили того, что удаленный circleci делает во время установки.