Конвейер сборки

Сборки выполняются на узлах сборки Lizard — вам не нужен Docker локально. При развёртывании платформа по заданному порядку решает, как превратить ваш исходный код в образ контейнера, а затем запускает этот образ в изолированном поде. Не каждый контейнер как сервис собирает образ за вас; в блоге сравниваются три формы, в которых встречается эта категория.

Порядок выбора стратегии сборки

Платформа выбирает ровно одну стратегию сборки, в таком порядке:

1. Dockerfile из репозитория по пути dockerfilePath: если на сервисе задан dockerfilePath, этот Dockerfile используется без изменений, даже если заданы также команды сборки или запуска. Заданный startCommand по-прежнему заменяет ENTRYPOINT и CMD из Dockerfile во время выполнения. См. Развёртывание с Dockerfile.
2. Синтезированный Dockerfile — иначе, если на сервисе заданы buildCommand и/или startCommand (или переданы через lizard up --build-command / --start-command), Lizard генерирует Dockerfile из этих команд. lizardpack не вызывается.
3. Dockerfile в исходном коде — иначе используется Dockerfile в корне директории сборки (см. исключение для GitHub ниже).
4. Автоопределение lizardpack — иначе платформа запускает lizardpack, свой генератор Dockerfile / buildpack.

Автоопределение lizardpack

lizardpack анализирует ваш репозиторий и собирает оптимизированный многостадийный образ. Поддерживаемые стеки, проверяемые в таком порядке:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

См. Руководства по фреймворкам для продакшн-скриптов, адаптеров, путей вывода и портов: Hugo, Go, Node (Node.js, Next.js, Nuxt, SvelteKit, Astro, React, Vue, Docusaurus, VitePress), Python (Django, FastAPI, Streamlit) и Ruby (Rails). lizardpack определяет стек по файлам проекта и зависимостям. Если подходят несколько провайдеров, он выбирает их в указанном порядке. Как закрепить версию Node.js или Python, см. в разделе версии runtime.

На этом пути:

• Загруженный исходный код (lizard up) всегда использует корневой Dockerfile как есть.
• Исходный код из GitHub использует корневой Dockerfile как есть, если он не выглядит неполным: в нём есть COPY для build, dist, out, .next или public, записанный без завершающего слеша (COPY dist /usr/share/nginx/html), и нет строки RUN, начинающейся с npm, yarn, pnpm, bun, pip, pip3, bundle, cargo, go build, mvn или gradle. Тогда lizardpack генерирует замену.
• Если Dockerfile нет, lizardpack генерирует его за вас.
• Команда запуска определяется автоматически: строка Procfile web: (Python/Ruby) или package.json scripts.start (Node) подхватывается автоматически. Для точной строки, которую хотят Django, Flask и FastAPI, см. Хостинг Python-приложений.
• Порт выводится из EXPOSE, значений фреймворка по умолчанию или явной переменной окружения PORT.

Подвох: Для исходного кода из GitHub Dockerfile, который копирует предварительно собранный результат (COPY dist /dest) и не содержит шага RUN с менеджером пакетов, считается неполным и регенерируется lizardpack. Добавьте реальный шаг сборки или задайте dockerfilePath для принудительного использования как есть. См. Изменения Dockerfile не применяются.

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

Не дублируйте сборку. После service set, меняющего поле сборки на запущенном сервисе, пересборка запускается автоматически. Не ставьте в цепочку lizard redeploy после этого, иначе поставите в очередь вторую избыточную сборку (почему). Упавший или ни разу не развёрнутый сервис сам не пересобирается; запустите lizard redeploy.

Переменные времени сборки

Lizard записывает переменные VITE_* и NEXT_PUBLIC_* в Dockerfile в виде строк ENV в двух случаях:

• Сервисы из GitHub без dockerfilePath: их получает Dockerfile от lizardpack или корневой Dockerfile репозитория.
• Сервисы с buildCommand или startCommand, для которых сгенерированный Dockerfile собирает Node.

Сервисы, развёрнутые через lizard up без команды сборки или запуска, не получают переменных Lizard во время сборки. Ни один сервис не получает аргументов сборки, кроме COMMIT_SHA, поэтому ARG в вашем Dockerfile остаётся пустым. Для публичных значений при lizard up закоммитьте их в .env.production (проверьте, что .gitignore его не исключает), впишите их в свой Dockerfile или, для серверного приложения на Node, задайте и buildCommand, и startCommand.

Наблюдение за сборкой

Логи сборки стримятся во время lizard up. Для любого сервиса:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

Если сборка упала, прочитайте lizard logs --build, устраните причину (в репозитории или скорректировав buildCommand / startCommand через lizard service set), затем lizard redeploy.

Примечания к рантайму

• Нет Docker HEALTHCHECK. Рантайм не запускает цикл healthcheck Docker, поэтому директивы HEALTHCHECK игнорируются. Lizard выполняет TCP-пробирование вашего порта вместо этого (пропускается в режиме воркера).
• Не пишите Dockerfile без нужды. lizardpack автоопределяет большинство стеков — попробуйте сначала задеплоить, и добавляйте Dockerfile (или задавайте dockerfilePath) только если автосборка не подходит.

Справочник по конфигурации сборки

Любое из этих полей можно задать через lizard service set <svc> --set <field>=<value>. Очистить поле можно пустым значением, например --set buildCommand=. См. lizard service.

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