От npm install до продакшена за один подход
npm i -g @inquir/compute-cli && inquir login — вот и вся настройка. Дальше `inquir deploy` выкатывает serverless-функцию, а `inquir apps deploy` — любой Dockerfile как долгоживущий контейнерный сервис, и логи сборки стримятся прямо в терминал.
Обновлено: 2026-06-23
Кратко
Суть ответа
От npm install до продакшена за один подход. CLI ставится из npm и авторизуется через браузер. `inquir deploy` пакует текущую директорию как serverless-функцию и стримит сборку; `inquir apps deploy` собирает ваш Dockerfile на стороне платформы (локальный Docker не нужен) или релизит любой публичный образ — как HTTP-сервисы, так и «сырые» TCP-порты.
Когда подходит и когда нет
- Выкатить функцию или контейнерный сервис, не поднимая сначала CI
- CI/CD-пайплайны, которым нужны скриптуемые деплой, promote и откат
- Команды, которым нужна релизная дисциплина уровня ECS без эксплуатации Kubernetes или ECS
На что обратить внимание
- Деплой по клику работает до второго окружения, второго человека в команде или второго отката в два часа ночи. Что нельзя заскриптовать — нельзя повторить.
- Уйти сразу в Kubernetes — значит решить повторяемость ценой эксплуатации распределённой системы. kubectl, манифесты, ingress, pull-секреты — мощно, но для одного сервиса это слишком много машинерии.
- Золотая середина — CLI, который владеет всем жизненным циклом: сборка, релиз, проверка, promote, откат — одни и те же команды на ноутбуке и в CI.
Ситуация: нагрузка и где обычно ломается
Чтобы выкатить маленький сервис, не нужна платформенная команда
Обычный путь в прод лежит через дашборд, YAML-пайплайн, реестр образов, который вы администрируете сами, и систему деплоя, за здоровьем которой кто-то следит. Для функции или одного контейнера эти накладные расходы больше самой работы.
CLI-обёртки над REST API проблему не решают: сборку, пуш, релиз, health-проверки и откат вы всё равно собираете из отдельных частей — и острые углы вылезают во время инцидента, а не при настройке.
Компромиссы
Дашборды хороши на демо; в прод возят терминалы
Деплой по клику работает до второго окружения, второго человека в команде или второго отката в два часа ночи. Что нельзя заскриптовать — нельзя повторить.
Уйти сразу в Kubernetes — значит решить повторяемость ценой эксплуатации распределённой системы. kubectl, манифесты, ingress, pull-секреты — мощно, но для одного сервиса это слишком много машинерии.
Золотая середина — CLI, который владеет всем жизненным циклом: сборка, релиз, проверка, promote, откат — одни и те же команды на ноутбуке и в CI.
Как Inquir помогает в этом сценарии
Один инструмент, весь жизненный цикл — и оркестрация в стиле ECS под капотом
CLI ставится из npm и авторизуется через браузер. `inquir deploy` пакует текущую директорию как serverless-функцию и стримит сборку; `inquir apps deploy` собирает ваш Dockerfile на стороне платформы (локальный Docker не нужен) или релизит любой публичный образ — как HTTP-сервисы, так и «сырые» TCP-порты.
Внизу — control plane в духе ECS, но без ECS: каждая сборка пушится в приватный реестр и релизится по неизменяемому digest, новый релиз обязан пройти health-проверки, прежде чем на него пойдёт трафик, а реплики размещаются по флоту воркеров с автоматическим восстановлением, если машина пропала. Семантика оркестратора — релизы, promote, откаты, self-healing — без оркестратора, который нужно эксплуатировать.
Day-2 живёт в том же инструменте: `inquir logs` и `inquir apps logs` для вывода, `apps exec` — шелл в работающем контейнере, `rollback` — на любой сохранённый релиз, а `inquir upgrade` держит сам CLI свежим.
Что вы получаете на платформе
Что закрывает CLI
Функции
init создаёт хендлер, run запускает его локально, deploy стримит удалённую сборку, invoke/logs/rollback замыкают цикл — Node.js, Python и Go.
Контейнерные приложения
apps deploy собирает Dockerfile из вашей директории или релизит любой образ; HTTP-маршрутизация, TCP-порты и постоянные тома — это флаги, а не конфиг-файлы.
Релизы в стиле ECS
Образы в приватном реестре с пином по digest, promote через health-гейты, сохранённые релизы для мгновенного отката, реплики по воркерам с автоматическим восстановлением.
CI и автоматизация
Персональные токены вместо браузерного логина, plain-text и JSON-вывод, честные exit-коды — каждая команда чисто скриптуется.
Готов к AI-агентам
inquir mcp поднимает платформу как MCP-сервер: кодинг-агенты деплоят и инспектируют сервисы с теми же правами, что и вы.
Что сделать дальше, по шагам
Три команды между пустой директорией и продом
Установить и войти
npm i -g @inquir/compute-cli, затем inquir login один раз открывает браузер и сохраняет токен воркспейса.
Задеплоить
inquir deploy для функции или inquir apps deploy для контейнерного сервиса — оба стримят сборку и заканчиваются живым URL.
Эксплуатировать
Логи, exec в контейнер, promote превью-релиза, откат — из той же сессии терминала.
Пример кода
Весь жизненный цикл, как он печатается
Без YAML, без кред реестра, без kubeconfig — CLI владеет сборкой, релизом и откатом от начала до конца.
# once per machine npm i -g @inquir/compute-cli && inquir login # serverless function: scaffold, test locally, ship inquir init hello --runtime nodejs inquir run hello --payload '{"name":"World"}' inquir deploy # streams the build, prints the URL # container service: any Dockerfile, or any image inquir apps deploy web # builds ./Dockerfile server-side inquir apps deploy cache --image redis:7-alpine --tcp redis:6379 inquir apps logs web --follow inquir apps rollback web # back to the previous digest-pinned release
Когда подходит и когда нет
Когда CLI — правильный интерфейс
Когда это уместно
- Выкатить функцию или контейнерный сервис, не поднимая сначала CI
- CI/CD-пайплайны, которым нужны скриптуемые деплой, promote и откат
- Команды, которым нужна релизная дисциплина уровня ECS без эксплуатации Kubernetes или ECS
Когда лучше выбрать другое
- Редактировать код в браузере и деплоить оттуда — это сценарий веб-IDE, CLI не нужен
Вопросы и ответы
Вопросы и ответы
Нужен ли локальный Docker?
Нет. `inquir apps deploy` загружает контекст сборки и собирает Dockerfile на платформе, стримя лог обратно. Локальный Docker полезен, только если хотите сначала проверить образ сами.
Это ECS? Что на самом деле запускает мои контейнеры?
Это ECS по форме, но не ECS: сборки пушатся в приватный реестр, релизы пинятся по digest образа, каждый promote проходит health-проверки, а реплики размещаются по флоту воркеров, который сам восстанавливается при падении машины. Та же семантика — без аккаунта AWS и кластера на обслуживании.
Как устроена аутентификация в CI?
На интерактивных машинах — `inquir login` (device-flow через браузер). В CI — персональный токен через переменную окружения: те же команды, без браузера, со скоупом на выбранный воркспейс.
Как работают откаты?
Предыдущие релизы сохраняются вместе с точным digest образа. `inquir rollback` (функции) или `inquir apps rollback` (контейнеры) активируют один из них заново — без пересборки, и health-гейт всё равно срабатывает до переключения трафика.