🔹 Контейнеризация приложения.
Классический сценарий использования - Dockerfile описывает всё окружение и последовательность действий для запуска приложения, а снаружи "торчит" только порт который приложению позволено слушать.
Такой контейнер запускается и в норме работает до следующего деплоя изменений. Запускается обычно командой
docker run🔹 Build container
Это менее известный сценарий (хотя я его использую даже чаще) - Dockerfile описывает окружение необходимое для сборки приложения, собирает его, и на выход отдает некие артефакты.
Запускается командой
docker build -o output/path. Dockerfile выглядит (упрощенно) так:FROM whatewer AS build
# describe build env
# describe build steps
FROM scratch AS export
COPY --from=build /target/ ./
В результате получаем полностью изолированный пайплайн сборки где на вход нужно закинуть исходный код а на выход получить готовый артефакт.
В довесок можем получить инкрементальность сборки, и даже удаленный кэш
Пример
🔹 Песочница
Пожалуй самый редкий сценарий использования. Это dockerfile в котором главная роль принадлежит инструкции ENTRYPOINT и флаги
:ro, --network=none.Представим что мы хотим запустить какой curl bash, ну или даже подозрительный npm пакет у себя в системе, один из тех в которые любят встраивать бекдоры.
Оговорюсь что такие вещи бывает опасно запускать даже в одном контейнере с приложением, т.к. они могут, например, украсть ключи из переменных окружения.
Но довольно безопасно запускать их в песочнице, например
htmlhint
FROM node:24-alpine3.21
RUN npm install -g htmlhint
ENTRYPOINT ["htmlhint"]
и потом запустить в полностью иммутабельном окружении и с запретом на доступ в сеть
docker run --rm --network=none -v ${PWD}:${PWD}:ro htmlhint ${PWD}Впрочем для таких простых случаев можно и без Dockerfile (да, учтите что его надо будет разочек предсобрать командой docker build с разрешением доступа в сеть, ведь npx-у надо пакет откуда-то взять)
docker run --network=none -v ${PWD}:${PWD} --workdir=${PWD} node:24-alpine3.21 npx prettier --fix