Реклама мешает? Идти Без рекламы Сегодня 

Генератор Dockerfile

Разработчик

Реклама · УДАЛИТЬ?

ВХОД

Автоматический процесс

Куча

Метка изображения

Метка, добавляемая после имени изображения (image:TAG).

Базовое изображение

Полное имя изображения с меткой.

WORKDIR

Аргументы при сборке

Переменные во время сборки. Каждая строка становится инструкцией ARG.

Переменные среды

Переменные во время выполнения. Каждая строка становится инструкцией ENV.

Системные пакеты

Устанавливаются с помощью apk/apt-get в зависимости от базового изображения. Оставьте пустым, чтобы пропустить.

Файлы зависимостей

Копируются первыми для более эффективного кэширования слоёв Docker.

Команда установки

Выполняется после копирования файлов зависимостей.

Команда сборки

Опционально. Выполняется после полной копии исходного кода.

Открывать порты

TCP-порты, разделённые запятой.

Не-корневой пользователь

Опционально. Устанавливает пользователя для выполнения в контейнере.

HEALTHCHECK

Опционально. Команда shell, выполняемая внутри контейнера.

Интервал проверки здоровья

Формат выполнения (рекомендуется)

Формат shell

CMD

Процесс по умолчанию при запуске контейнера.

ENTRYPOINT

Опционально. Используется, когда CMD передаёт только аргументы.

ВЫХОД

Клиентская сторона

Реклама · УДАЛИТЬ?

Гид

Генератор Dockerfile

Создаёт производственный Dockerfile за несколько секунд. Выберите стек, такой как Node.js, Python, Go, OpenJDK, Ruby, PHP, Rust, .NET, Nginx, Alpine, Ubuntu или Debian, и генератор установит разумные значения по умолчанию для базового изображения, переменных среды, файлов зависимостей, команды установки, открытых портов и пользователя во время выполнения. При изменении любого поля Dockerfile мгновенно обновляется в соответствии с лучшими практиками в порядке слоёв.

Как использовать

Выберите стек из выпадающего списка. Имя изображения, метка, переменные среды, файлы зависимостей и CMD заполняются предустановленными значениями.
Настройте метку изображения, WORKDIR, аргументы сборки и переменные среды во время выполнения, чтобы соответствовать вашему проекту.
Укажите любые системные пакеты, которые вам нужны (один на строку). Генератор устанавливает их с помощью apk на изображениях Alpine и с помощью apt-get на изображениях семейства Debian.
Укажите файлы зависимостей, которые должны быть скопированы первыми для кэширования слоёв, команду установки, следующую за этим, и опциональную команду сборки.
Настройте открытые порты, не-корневого пользователя, опциональный HEALTHCHECK и выберите формат выполнения (exec или shell) для конечной команды CMD или ENTRYPOINT.
Скопируйте сгенерированный Dockerfile или скачайте его прямо в корень вашего проекта.

Возможности

Предустановленные стеки — один клик заполняет Node, Python, Go, OpenJDK, Ruby, PHP, Rust, .NET, Nginx, Alpine, Ubuntu, Debian или ваш собственный кастомный образ.
Порядок слоёв по лучшим практикам — FROM, ARG, WORKDIR, ENV, системные пакеты, копирование зависимостей + установка, копирование исходного кода, сборка, EXPOSE, USER, HEALTHCHECK, затем ENTRYPOINT/CMD.
Дружелюбность к кэшированию слоёв — копируются файлы зависимостей до остального исходного кода, чтобы при пересборке при изменении кода избегать повторной установки зависимостей.
Умение работать с менеджером пакетов — emits apk add --no-cache для баз из Alpine и единственный очищенный apt-get update && install слой для баз из семейства Debian.
Формат выполнения (exec или shell) — CMD и ENTRYPOINT отображаются как JSON-массив (рекомендуется) или как строка shell.
Помощник HEALTHCHECK — настраиваемый интервал с разумными значениями таймаута, периода запуска и количества попыток.
Живое обновление — при каждом изменении результат обновляется без необходимости нажимать кнопку «Generate». Скопируйте или скачайте результат одним кликом.

 Часто задаваемые вопросы

Почему порядок инструкций в Dockerfile важен?

Docker кэширует каждую инструкцию как неизменяемый слой, ключом которого являются его входные данные. При изменении слоя все слои ниже него должны пересобираться. Размещение редко изменяемых инструкций, таких как FROM, ENV и установка зависимостей, ближе к верху, а часто изменяемых, таких как копирование исходного кода и сборка, — ближе к низу, позволяет Docker использовать дорогостоящие слои настроек во время большинства пересборок и пересобирать только последние, более дешевые шаги.
Какова разница между форматом CMD exec и форматом shell?

Формат exec — это JSON-массив (например, ["node", "server.js"]), который Docker запускает напрямую с помощью execve, поэтому процесс становится PID 1 и получает сигналы, такие как SIGTERM, чисто. Формат shell — это одна строка, которую Docker оборачивает в /bin/sh -c, что добавляет оболочку как PID 1, поглощает сигналы и нарушает корректное завершение. Формат exec является рекомендуемым по умолчанию для долгосрочных служб.
Почему нужно копировать package.json или requirements.txt до остального исходного кода?

Установка зависимостей обычно является самым медленным шагом в сборке. Копируя сначала только манифест и файл блокировки, а затем запуская установку, Docker может кэшировать этот слой и использовать его на каждом последующем сборке до тех пор, пока эти файлы не изменятся. Копирование всего исходного кода сначала приведёт к недействительности слоя установки при каждом изменении кода, что заставит пересобирать всё заново.
Почему нужно запускать как не-корневой пользователь внутри контейнера?

По умолчанию процессы внутри контейнера запускаются как root. Если атакующий эксплуатирует уязвимость в вашем приложении, он наследует root внутри контейнера, что расширяет радиус воздействия компрометации. Переключение на отдельного неавторизованного пользователя с помощью USER уменьшает то, что может читать, писать или поднимать уровень доступа вредоносный код, и является базовым требованием для многих производственных сред и политик безопасности в Kubernetes-подах.
Что делает HEALTHCHECK на самом деле?

HEALTHCHECK сообщает Docker, какую команду запускать периодически, чтобы определить, здоров контейнер или нет. Результат доступен через docker inspect и используется оркестраторами и балансировщиками нагрузки для управления трафиком, перезапуска неисправных контейнеров и пометки развертываний как неудачных. Хороший проверочный тест должен проходить тот же путь кода, что и реальные клиенты, возвращать результат быстро и запускаться часто, чтобы обнаружить сбои до того, как пользователи это заметят.