Архитектура

Lizard организует всё, что вы деплоите, в иерархию из трёх уровней, плюс управляемые аддоны, прикреплённые к проекту.

workspace
└── project
    ├── service (app)          ← built from GitHub or an upload
    ├── service (worker)       ← background job, no HTTP port
    └── addons
        ├── postgres
        ├── redis
        └── s3

Рабочее пространство

Рабочее пространство — это уровень аккаунта или организации. Вы состоите хотя бы в одном, а биллинг, участники и проекты находятся в нём. Посмотреть доступные:

lizard workspace list
lizard whoami        # shows your active workspace

Многие команды принимают -w, --workspace <ws>, чтобы уточнить цель, когда одноимённые проекты существуют в разных рабочих пространствах.

Проект

Проект объединяет связанные сервисы и аддоны внутри рабочего пространства. Ваша рабочая директория связывается с проектом, и эта связь (хранится в ~/.lizard/config.json) сообщает CLI, с чем вы работаете.

lizard init --name my-project   # create or select a project, link the cwd
lizard link --project my-project  # link to an existing project
lizard status                   # show the current directory's link
lizard unlink                   # remove the link
lizard project list             # all projects in the workspace

Совет: Используйте имя репозитория или директории для проекта, а для сервисов — имена в стиле приложений (api, worker, web).

Сервис

Сервис — это единица деплоя. Его источник может быть одним из:

• github — подключённый репозиторий GitHub. Пуш в отслеживаемую ветку вызывает повторный деплой.
• upload — тарболл, загруженный через lizard up.

Каждый запущенный сервис работает как отдельный изолированный под с политикой сети default-deny, сгенерированным доменом <name>.<region>.onlizard.com и автоматическим TLS. Это разделение — вы предоставляете контейнер, платформа его запускает — называется container as a service, а в блоге описано, что ещё остаётся на вашей стороне. Инспектировать и управлять сервисами можно с помощью:

lizard ps                       # list services with status + URL
lizard service show             # full config as JSON
lizard service set <svc> --set <field>=<value>
lizard service rename --service <svc>
lizard service delete --service <svc>

Поля конфигурации сервиса плоские и отображаются 1:1 в схему на проводе (например, repoUrl, branch, buildCommand, startCommand, containerPort, rootDirectory). Вложенности build.* / deploy.* нет. Полный список см. в lizard service.

App-сервисы и воркеры

По умолчанию сервис — HTTP-приложение, слушающее порт (по умолчанию 3000) и доступное на своём домене. Сервису, который не слушает порт — потребителю очереди, реконсилеру или поллинговому циклу — следует запускаться в режиме воркера, установив containerPort=0. Воркеры пропускают инъекцию порта, проверку достижимости и регистрацию в балансировщике.

Управляемые аддоны

Аддоны — это управляемые Postgres, Redis и S3-совместимое хранилище, которые вы создаёте на уровне проекта:

lizard add postgres redis s3

Каждый аддон предоставляет фиксированный набор переменных окружения, которые сервисы используют по ссылке (${{<addon-name>.KEY}}). Подробнее в разделе Управляемые аддоны.

Межресурсные ссылки

Любое значение сервиса или аддона можно сослаться из окружения другого ресурса с помощью:

${{<name>.<KEY>}}

Ссылки разрешаются во время деплоя против объединённого окружения цели. Они хранятся по ID, поэтому последующее переименование цели не ломает ссылку. Ссылка на несуществующую цель или ключ разрешается в пустую строку (деплой не падает); выбрасывают ошибку только циклические ссылки.

# Wire a service to the project's Postgres
lizard secrets set DATABASE_URL='${{postgres.DATABASE_URL}}' --service api

Проверить, что потребитель действительно получил значение:

lizard ssh --service api -- env | grep DATABASE_URL

Переменные, внедряемые платформой

Каждый сервис автоматически получает эти переменные (их нельзя переопределить):

Как они взаимодействуют с вашими переменными и полный порядок приоритетов см. в разделе Переменные и секреты.