Граф версий
Каждая среда фиксирует точный набор версий runtime, библиотек и системных пакетов. Команда hazedock deps lock пишет hazedock.lock под версионный контроль.
Возможности · Архитектура
Возможности, которым доверяют
Шесть слоёв, из которых складывается HazeDock: от виртуализации рабочих пространств до API для автоматизации. Ниже — как каждый из них устроен внутри и что даёт вашей команде каждый день.
➜hazedock layers --list
01 · workspace-vm enabled
02 · dep-graph enabled
03 · snapshot-core enabled
04 · ide-bridge enabled
05 · cloud-sync enabled
06 · api/automation enabled
➜hazedock layers --status
Слой 01
Виртуализация рабочих пространств
Каждый проект живёт в собственном «комнате»: отдельное виртуальное ядро, сеть и тома. Это не метафора — на уровне агента пространства физически разделены.
Агент HazeDock поднимает лёгкую виртуальную машину (WV) для каждого пространства. По умолчанию на WV выделяется 2 ядра CPU, 4 ГБ RAM и 20 ГБ томов. Параметры задаются в hazedock.toml и пересчитываются без перезапуска при изменении.
Сеть каждого пространства — собственный подсеть /16 с явным маршрутизацией. Порты не пересекаются между проектами, а правила межпространственного доступа задаются декларативно. Типичные конфликты в монорепо («случайно занял порт 5432») исчезают на уровне ядра.
Схема виртуализации →
workspace #017 · 2 vCPU · 4 GB
Слой 02
Управление зависимостями и версиями
Зависимости не «подтягиваются наугад». HazeDock держит граф версий, кэш образов и чёткий журнал изменений.
Локальный кэш образов
Образы, пакеты и зависимости кэшируются в ~/.hazedock/cache. Повторный запуск той же среды занимает в среднем 0.9 секунды — кэш попадает в RAM и не уходит в сеть.
Журнал изменений
Каждое изменение версии логируется с метаданными: кто, когда, из какой среды, какой diff. Команда hazedock deps diff main…feature-x показывает расхождения между ветками за секунды.
Слой 03
Мгновенные снапшоты окружения
Состояние среды — процессы, файлы, сеть, переменные — фиксируется за миллисекунды. Откат к любой точке занимает секунду.
Снапшоты строятся на уровне тома через copy-on-write. Типичный снапшот среды с 20 ГБ данных занимает 180 МБ прироста и создаётся за 420 мс. Хранятся в ~/.hazedock/snapshots и автоматически чистятся по стратегии retention (по умолчанию — 14 дней или 20 штук, что больше).
Снапшот можно восстановить в новую среду (hazedock restore snap-0412 --as staging), сравнить с текущим (hazedock diff snap-0412) или выгрузить в архив. Экспериментальные ветки кода можно запускать «на чистом» снапшоте, не трогая основную среду.
Полный список команд снапшотов →
snap-0412 · 180 MB · 420 ms
Слой 04
Интеграция с IDE
Рабочее пространство видно прямо в редакторе: статус среды, логи, снапшоты и быстрые действия — без переключения в терминал.
Панель статуса
В статус-баре IDE показывается активная среда, её CPU/RAM и сетевой режим. Клик по значку открывает быстрый доступ к up, down, logs и snapshot.
Запуск и отладка
Конфигурации run/debug из IDE транслируются в среду HazeDock. Брейкпоинты, live-reload и attach к процессам работают как локально — только внутри изолированного пространства.
Плагины
Официальные плагины для VS Code, JetBrains IDEA, Neovim и Zed. Поддерживаются также LSP-клиенты через hazedock lsp serve. Плагины подписаны и обновляются по каналу stable / beta.
Слой 05
Локальная облачная синхронизация
Когда локальной машины уже не хватает, HazeDock мягко переносит среду в облако — и обратно. Данные не покидают машину без вашего явного запроса.
Синхронизация работает через лёгкий протокол haze-sync: сначала передаётся метаданные и граф зависимостей, потом — только изменённые блоки данных. Для среды с 20 ГБ полная первая синхронизация занимает 3–5 минут; последующие — от 40 секунд.
Поддерживаются три режима: локальный (по умолчанию, облако не подключено), гибридный (облако как кэш и бэкап) и облачный (среда живёт на стороне провайдера). Переключение между режимами выполняется командой hazedock sync mode и не требует повторной сборки.
Политики синхронизации →
sync · hybrid · 40s
Слой 06
API и скрипты для автоматизации
Всё, что делает пользователь, доступно через CLI, локальный REST API и SDK. CI/CD, оркестрация и собственные скрипты — без костылей.
Локальный REST API
Агент поднимает API на 127.0.0.1:4821 с JWT-токенами. 42 эндпоинта покрывают среды, снапшоты, сети и журналы. OpenAPI-спецификация генерируется из того же кода, что и сам агент.
SDK для Go и Python
Библиотеки github.com/hazedock/go-sdk и pypi.org/hazedock дают типизированный доступ к API. Поддерживаются контексты, ретраи и стриминг логов. Версии SDK синхронизированы с агентом по схеме semver.
CI-агенты и хуки
Готовые действия для GitHub Actions, GitLab CI и TeamCity. Хуки pre-up, post-test, pre-destroy позволяют встраивать свои шаги в жизненный цикл среды. Все артефакты складываются в кэш и переиспользуются между запусками.
420ms
создание снапшота 20 ГБ
42
эндпоинта локального API
3.14.2
текущая версия агента
40s
повторная облачная синхронизация
Вопросы про возможности
Что ещё стоит знать про архитектуру
Коротко о том, о чём чаще спрашивают перед переходом на HazeDock.
Да. В hazedock.toml задаются cpu, memory, storage и network limits для каждого workspace. Ограничения применяются на уровне агента и не зависят от того, сколько других сред запущено на машине.
Снапшоты бинарно совместимы в пределах одной мажорной версии агента. При переходе с 3.x на 4.x агент автоматически переносит существующие снапшоты и создаёт резервную копию в ~/.hazedock/migration.
Да. Протокол haze-sync абстрагирует хранилище. Поддерживаются AWS S3, GCS, Azure Blob и любое S3-совместимое хранилище. Переключение провайдера — одна строка в конфиге.
API слушает только 127.0.0.1. Доступ — по JWT-токену с коротким TTL (по умолчанию 15 минут) и ограниченным набором прав. Все вызовы логируются в ~/.hazedock/audit.log с подписью.
Попробуйте все шесть слоёв
Скачайте агент 3.14.2, поднимите первую среду и создайте снапшот — за минуту. Документация и SDK идут в комплекте.