Повседневная работа

После подключения к проекту и зелёного первого деплоя ежедневная работа с DWE сводится к небольшому набору команд. Это руководство проходит по ним примерно в том порядке, в каком вы будете к ним обращаться: поднять стек, проверить статус, переключить сервис, зайти в шелл, запустить проектную команду, посмотреть логи, остановить или перезапустить.

Поднять стек

Первое, с чего начинается день, — запустить стек:

dwe run

Команда поднимает все включённые сервисы через Docker Compose, дополняя последовательность docker up + ожидание health-проверок опциональной проверкой обновлений git и хуками before/after-run. Деплой готовит на диске заведомо рабочее состояние, а сами контейнеры поднимает уже dwe run.

dwe run требует зелёного деплоя: если отслеживаемый сервис ещё ни разу не деплоился, команда остановится с сообщением «run dwe deploy run first» — она не станет запускаться в наполовину подготовленном окружении. Чтобы пропустить проверку обновлений git:

dwe run --no-update

dwe stop и dwe restart — это парные команды на другом конце цикла, см. стоп и рестарт ниже.

Быстрый статус

dwe status

По умолчанию выводится здоровье стека и каждая секция по порядку: apps, tools, infra, deploy, topology, git workspace, daemons. Каждую секцию можно адресовать напрямую — удобно, когда нужен только один срез:

dwe status apps
dwe status deploy
dwe status daemons

Чтобы сократить дефолтный вывод, передавайте флаги --no-<секция> — например, dwe status --no-git --no-topology пропустит две самые медленные секции, если хочется быстро проверить контейнеры.

dwe status — read-only и работает без локов, так что её безопасно вызывать во время идущего деплоя или рестарта. Печатаемую «обложку» проекта (URL-ы, host-алиасы, учётные данные) выводит dwe info, она описана в подключении к проекту.

Переключение опциональных сервисов

Большинство проектов поставляют пару опциональных сервисов — дашборд метрик, второго воркера, UI для администрирования базы. Они объявлены enabled: false в workspace/defaults.yml, и вы включаете их отдельно на каждой машине.

Интерактивный multi-select:

dwe services

Откроется чек-лист опциональных сервисов. Подтверждение запишет ваш выбор в workspace/local.yml и пересоберёт .env.

CLI-форма:

dwe services enable adminer
dwe services disable second

По умолчанию переключение только пишет local.yml и фиксирует отложенную операцию. Контейнер при этом не запускается и не останавливается — dwe status подсветит отложенные изменения. Чтобы сразу выполнить шаги жизненного цикла, передайте --apply:

dwe services enable adminer --apply

Без --apply новый выбор применит следующий dwe deploy (или dwe deploy run --service adminer). Модель отложенных изменений нужна, чтобы можно было накопить несколько переключений и применить их разом.

Справочник: ../reference/config/state/index.md о механике pending-state, ../reference/config/services/index.md о схеме.

Шелл-доступ

dwe shell <сервис>

Открывает интерактивный шелл внутри указанного контейнера. Без аргумента команда автоматически выбирает единственный включённый сервис или показывает селектор, если их несколько.

Режим определяет, как открывается шелл:

Режим	Поведение
auto (по умолчанию)	docker exec, если контейнер работает; compose run --rm, если нет; ошибка, если контейнер остановлен.
exec	Всегда docker exec — ошибка, если контейнер не работает.
run	Всегда поднимает свежий контейнер через docker compose run --rm. Удобно, когда нужен чистый шелл, не трогая работающий.

dwe shell main --mode run --shell sh
dwe shell main --root
dwe shell main --user deploy --workdir /app

Для одноразового запуска (один вызов команды и выход с её exit-кодом) используйте -c:

dwe shell main -c "composer install"
dwe shell main -c "php artisan migrate" --mode run

TTY выделяется только если и stdin, и stdout — терминалы, так что пайпы работают корректно (dwe shell main -c "ls -la" | grep ...). Плата за это — буферизация: у процесса, чей stdout это пайп, вывод буферизуется блоками, поэтому долгая команда молчит до самого завершения. --tty (-t) принудительно выделяет псевдо-TTY, чтобы вывод шёл потоком, ценой трансляции \n → \r\n; --no-tty делает обратное даже на интерактивном терминале. Эти два флага взаимоисключающие. --tty невозможно выполнить, когда шеллу нужно поднять новый контейнер (--mode run), а stdin не терминал: compose отказывается выделять PTY в этом случае, и dwe пишет предупреждение в stderr, а не падает.

Шелл-бинарь, пользователь, рабочая директория и значения env по умолчанию берутся из блока cli: каждого сервиса в service.yml; флаги переопределяют их при каждом вызове.

Запуск проектных команд

Проекты объявляют свои операции под workspace/commands/ — сидинг базы, сброс кэшей, инициализация окружения, деплои. Каждая операция становится вызываемой командой:

dwe commands              # интерактивный селектор по всем публичным командам
dwe commands list         # обычный листинг
dwe commands db.seed      # прямой запуск
dwe cmd db.seed           # `cmd` — короткий алиас

Параметры передаются через --set key=value:

dwe cmd db.seed --set env=staging --set count=10

Для скриптов:

• -y / --yes пропускает промты подтверждения (в том числе любое confirmation: true у команды).
• --silent подавляет финальное desktop-уведомление для команд с notify: true.
• -i / --inspect печатает разрешённое определение команды вместо запуска — удобно проверить, что соберут --set и шаблонизатор, перед выполнением.

dwe cmd db.seed --yes --silent
dwe cmd db.seed --inspect

Справочник: ../reference/config/commands/index.md, ../reference/config/commands/types.md.

Просмотр логов

dwe logs              # весь стек (все включённые сервисы)
dwe logs <сервис>     # один сервис

Без аргумента dwe logs стримит логи всего стека — каждый включённый сервис, с мультиплексом и префиксами, как docker compose logs. С именем сервиса стримит контейнер одного сервиса. По умолчанию печатает последние 50 строк и выходит. Чтобы следить:

dwe logs --follow
dwe logs main --follow
dwe logs main --tail 100 --follow
dwe logs main --since 5m

Контейнер находится по меткам compose (проект + сервис), поэтому логи работают независимо от переопределения container_name и дефолтного именования compose <project>-<service>-<index> — пинить container_name в compose-файле не нужно.

Ctrl-C прерывает стрим; стек продолжает работать. --since принимает длительность (5m, 1h) или RFC3339-временную метку. С --output json вывод — NDJSON (по одному {"ts","stream","msg"} на строку; в режиме всего стека добавляется поле "service") для пайпа в инструменты сбора логов.

dwe logs — read-only и без локов, как и dwe status.

Повторный осмотр состояния проекта

Для URL-ов, host-алиасов и печатаемой «где что лежит» страницы смотрите подключение к проекту → дашборд info — dwe info это та же команда, только в повседневном использовании.

Стоп и рестарт

dwe stop
dwe restart

dwe stop запускает полный жизненный цикл остановки: хуки before-stop → docker compose down → хуки after-stop. Демоны, объявленные пользовательскими командами, при этом автоматически завершаются (отключить нельзя). dwe restart сцепляет полную остановку с фазой run, пропуская проверку обновлений git.

Варианты для отдельного сервиса:

dwe stop main
dwe restart main

Они обходят compose и lifecycle-хуки — напрямую вызывают docker stop / docker restart для одного контейнера. Вариант для одного сервиса работает даже после того, как сервис был отключён, — иногда именно это и нужно при подчистке только что переключённого сервиса. Демоны при остановке/перезапуске отдельного сервиса не завершаются автоматически.

Для простой остановки через compose вообще без хуков остаются низкоуровневые команды: dwe docker stop (остановить контейнеры на месте) и dwe docker down (остановить и удалить). Это запасные варианты на крайний случай; в обычной работе нужны dwe stop и dwe restart.

Что дальше

• troubleshooting.md — что делать, когда одна из команд на этой странице повела себя не так, как ожидалось.
• switching-tasks-with-snapshots.md — поставить одну задачу на паузу, переключиться на другую и вернуться без потери состояния.