Який сенс 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 ... && робити щось, що важко читати, вирішувати проблеми та підтримувати.

Я б запропонував зберегти його.

Я думаю, ви можете переробити свій 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>тобто всі елементи шляху створюються, якщо вони вже не існують.

ОНОВЛЕННЯ: Під час виконання багатоступеневої збірки я зіткнувся з проблемою, пов'язаною зі змінною - тепер, здається, нормально використовувати змінну - якщо вона (змінна) "в області", наприклад, у наступному, 2-е 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або будь-яку віддалену окружність, яку роблять під час налаштування.