Блог

Большинство файлов DockerFiles, похоже, генерируют изображение из каталога исходного кода. Есть ли причина, по которой это делается?

Например, если я выполняю команды сборки на компьютере с Windows, копирую папку dist на компьютер с Linux и выполняю ее в соответствии с вариантом 2, разве это не должно работать?

Вариант 1 — Файл Docker (из исходного каталога)

 FROM node:latest as build    
WORKDIR /usr/local/app    
COPY ./ /usr/local/app/    
RUN npm install    
RUN npm run build    
FROM nginx:latest    
COPY --from=build /usr/local/app/dist /usr/share/nginx/html    
EXPOSE 80
 

Вариант 2 — Файл Dockerfile из выходных данных сборки

 FROM nginx:latest    
COPY dist /usr/share/nginx/html    
EXPOSE 80
 

В вашей первой форме используется многоступенчатая сборка Docker. Это имеет особое преимущество, заключающееся в том, что оно не зависит от каких-либо конкретных инструментов, установленных в хост-системе. Я бы рассмотрел этот путь:

• Если у вас кластеризованная система CI, может быть гораздо проще запустить сборку в контейнере, чем пытаться вручную установить необходимые инструменты в каждой рабочей системе.
• Если вы работаете на скомпилированном языке (C, Go, Rust, …), вы можете последовательно использовать контейнеры Linux, даже если разработчики используют другую ОС хоста.
• Если вам нужно выполнить дополнительную работу по настройке системы сборки, например, установить дополнительные пакеты разработки на языке C.
• Если вам нужна действительно точная версия языковой среды выполнения по какой-либо причине.

Второй путь зависит от наличия цепочки инструментов, доступной за пределами среды контейнера. Это не обязательно проблема; у большинства интерфейсных разработчиков, вероятно, в любом случае будет установлен узел. Я бы рассмотрел этот путь:

• Если результат сборки чрезвычайно переносим в разных средах (скомпилированный HTML и Javascript; .jar файлы Java; интерпретированный код сценариев Python или Ruby в текстовом формате).
• Если нет больших различий в разных версиях самой языковой среды выполнения для создания сборки. (Делает ли ваша сборка Webpack что-либо другое на узле 8, 10, 12 или 14?)
• Если система сборки является чем-то простым в установке или предустановленным в большинстве сред хоста. (Например, в большинстве систем Linux и macOS есть Python.)
• Если система сборки хоста может выполнять инкрементные сборки или иным образом работать намного быстрее, чем сборка контейнера с чистого листа.

Для того, что вы показываете, с помощью простого интерфейсного приложения, скомпилированного в статические файлы, ваша вторая форма просто прекрасна. Если вы посмотрите на вопросы SO Java, они почти всегда COPY представляют собой готовый .jar файл в образ, без включения цепочки сборки.