Развёртывание Docker-контейнера из Dockerfile

Lizard (lizard.build) запускает Docker-контейнеры, которые собирает из вашего Dockerfile. Положите файл в корень проекта и выполните lizard up или подключите репозиторий GitHub: Lizard соберёт образ на своих сборочных машинах, так что локальный Docker не нужен. Lizard берёт порт из EXPOSE или --port, передаёт его в контейнер в переменной PORT и отдаёт контейнер по HTTPS на домене onlizard.com. Готовые образы из registry Lizard не скачивает; чтобы запустить публичный образ, напишите Dockerfile из одной строки FROM с этим образом.

Статус тестов: страница описывает сборщик, деплойер и CLI 4.0.42 Lizard по состоянию на 2026-10-12 и сверена с их исходным кодом. Нового деплоя для неё мы не запускали. Руководство по Umami так же развёртывает Dockerfile из одной строки FROM и описывает свой тест.

Перед началом

• Dockerfile с приложением, которое слушает 0.0.0.0. Сервер, привязанный к 127.0.0.1, не принимает подключений извне контейнера.
• Lizard CLI, в который вы вошли через lizard login, на тарифе Pro или в 7-дневном пробном периоде Pro (нужна карта). См. цены.

Если Dockerfile нет, сначала попробуйте деплой без него: lizardpack распознаёт Go, Node.js, Python, Ruby, PHP, Java, Rust и статические сайты. См. конвейер сборки.

Пример Dockerfile

Для сервера на Node.js, например из руководства Развёртывание приложения Node.js:

FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "server.js"]

Добавьте .dockerignore, чтобы локальные файлы не попали в образ:

node_modules
.git
.env*

Деплой через lizard up

lizard init --name my-container
lizard add --service web
lizard up --service web

lizard up читает первую строку EXPOSE в локальном Dockerfile, выводит Detected port 3000 from Dockerfile и назначает этот порт портом сервиса. Чтобы выбрать другой, передайте --port <number>. Загрузка всегда использует корневой Dockerfile как есть. Что входит в загрузку, см. в разделе развёртывание из локального кода.

Деплой из GitHub

lizard add -r your-org/your-app -n web

Каждый push в отслеживаемую ветку пересобирает образ. Lizard берёт корневой Dockerfile, если только тот не копирует результат, собранный где-то ещё (COPY dist … без шага RUN с npm, pip, go build и подобным); тогда lizardpack пишет замену. Чтобы всегда использовался ваш файл, задайте dockerfilePath:

lizard service set web --set dockerfilePath=Dockerfile

См. изменения в Dockerfile не применяются и развёртывание из GitHub.

Dockerfile в подкаталоге или с другим именем

dockerfilePath задаётся относительно каталога сборки, который определяет rootDirectory. Для сервиса в монорепозитории:

lizard service set api --set rootDirectory=apps/api --set dockerfilePath=Dockerfile.prod

Оставьте buildCommand и startCommand пустыми у сервиса с Dockerfile. Без dockerfilePath любая из этих команд заставляет Lizard написать собственный Dockerfile из команд вместо вашего. Если dockerfilePath задан, startCommand всё равно заменяет ENTRYPOINT и CMD образа: Lizard запускает sh -c "<start command>".

На какой порт Lizard направляет трафик

Lizard выбирает порт сервиса в таком порядке:

1. Порт, который вы задали: lizard up --port, lizard port, панель управления или строка EXPOSE, которую прочитал lizard up.
2. 0 включает режим воркера: ни порта, ни маршрута.
3. Переменная PORT, которую вы задали у сервиса.
4. Первый порт, который открывает собранный образ, включая порты из базового образа. Порты сортируются как текст, поэтому 3000 идёт раньше 80.
5. 3000.

Внутри контейнера в PORT лежит выбранный порт. Читайте его или слушайте тот же фиксированный порт. Чтобы позже сменить порт, выполните lizard port 8080 --service web, затем lizard redeploy --service web. См. сеть.

Что попадает в сборку

• Аргументы сборки: только COMMIT_SHA. Чтобы его использовать, объявите ARG COMMIT_SHA. Остальные строки ARG сохраняют значение по умолчанию или остаются пустыми.
• Переменные: переменные и секреты сервиса не попадают в сборку по Dockerfile; исключение составляют значения VITE_* и NEXT_PUBLIC_*, описанные в разделе переменные во время сборки. Публичные значения впишите в Dockerfile или закоммитьте; секреты оставьте для времени выполнения.
• Базовые образы: у сборщика нет входа в ваши registry, поэтому каждый образ во FROM должен быть публичным.
• Что меняет Lizard: перед сборкой Lizard добавляет ARG COMMIT_SHA перед COPY с исходниками и добавляет кэш-монтирования BuildKit к шагам установки npm, yarn, pnpm и bun. Кэш-монтирования, которые вы написали сами, продолжают работать в пределах этого сервиса; опция --mount, записанная в кавычках, ломает сборку.

Следите за сборкой командой lizard logs --build --service web.

Во время выполнения

• Проверка здоровья: Lizard игнорирует HEALTHCHECK и проверяет, что контейнер принимает TCP-подключения на порту сервиса. См. сервис никогда не становится healthy.
• Пользователь: действует USER из образа. У пользователя без root может не быть прав открыть порт ниже 1024, поэтому для таких образов берите 8080, а не 80.
• Переменные: контейнер получает переменные сервиса, PORT и платформенные переменные LIZARD_*. См. переменные и секреты.
• Файлы: всё, что контейнер записал, пропадает при следующем деплое. Для данных используйте Managed Postgres, Managed Object Storage или другой сервис; см. хранилище и восстановление.

Запуск публичного образа

Lizard собирает каждый сервис из исходников, поэтому оберните публичный образ в Dockerfile:

FROM ghcr.io/umami-software/umami:3.3.1
EXPOSE 3000

Используйте тег версии вместо latest, чтобы выбрать нужный релиз. Так сделано в руководствах Запуск Umami и Запуск Flowise, где образ работает вместе с Managed Postgres.

Частые проблемы

См. также

• Конвейер сборки
• Версии рантайма
• Развёртывание приложения Rails
• Фоновые воркеры
• lizard up

Обновлено 12 октября 2026 г.