Canonical Workshop — быстрые контейнерные окружения для разработки на Ubuntu

Canonical выпустила Workshop — утилиту для запуска воспроизводимых сред разработки через YAML-файл и одну команду. Инструмент помогает командам быстрее поднимать одинаковые рабочие окружения, изолировать зависимости в контейнерах и аккуратнее работать с современными сценариями, включая локальные AI-инструменты.

Workshop превращает настройку среды разработки в управляемый файл проекта

Canonical представила Workshop 27 мая 2026 года как инструмент для запуска изолированных сред разработки на Ubuntu и других Linux-дистрибутивах со Snap. Идея простая: разработчик описывает окружение в YAML-файле, кладёт этот файл рядом с проектом, затем запускает среду командой workshop launch.

Официальный блог Canonical описывает Workshop как решение для запуска development environments «with a single command». Такие окружения можно настроить один раз, воспроизвести на разных машинах и использовать в рабочих станциях, командной разработке и CI-сценариях. Подробнее об анонсе можно прочитать в публикации Canonical.

Главная ценность Workshop — предсказуемость. В обычной разработке окружение часто собирается вручную: одна версия компилятора, другая версия интерпретатора, отдельные системные библиотеки, локальные сервисы, переменные окружения, драйверы, доступ к GPU или SSH-агенту. Через несколько месяцев такую конфигурацию трудно повторить даже на той же машине. Workshop переносит существенную часть этой настройки в файл проекта.

Простейший пример workshop.yaml выглядит так:

name: dev
base: ubuntu@24.04
sdks:
  - name: go

После запуска Workshop создаёт контейнерное окружение, подтягивает указанные SDK и даёт возможность выполнять команды внутри подготовленной среды. В репозитории canonical/workshop проект описан как инструмент для определения временных development environments через YAML и SDK.

Контейнеры LXD дают изоляцию без тяжёлой ручной сборки

Workshop использует LXD для низкоуровневой работы с контейнерами. По документации, ему требуется LXD 6.8 или новее, а установка выполняется через Snap:

sudo snap install --channel=6/stable lxd
sudo snap install --classic workshop

Документация Ubuntu указывает, что Workshop поддерживается на Ubuntu и других snap-enabled Linux-дистрибутивах, а также совместим с WSL2. В WSL2 для хранения применяется Btrfs, тогда как на обычных Linux-системах часто используется связка LXD с ZFS. Эти детали важны для тех, кто планирует использовать Workshop в корпоративной среде или на рабочих ноутбуках с разными платформами. Инструкция доступна в официальном tutorial.

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

Такой подход особенно полезен в командах, где разработчики работают на разных машинах. Один участник проекта запускает окружение на Ubuntu, другой — в WSL2, третий — на новой рабочей станции. YAML-файл помогает всем получить сопоставимую базу, снижая риск ошибок из-за локальной настройки.

SDK Store собирает зависимости в повторно используемые блоки

В Workshop важную роль играют SDK. Это готовые строительные блоки окружения: язык программирования, фреймворк, локальный сервис, AI-инструмент, GPU-компонент или другой набор зависимостей. В документации Canonical в качестве примеров упоминаются Ollama, OpenCode, NVIDIA CUDA и AMD ROCm.

Разработчик добавляет SDK в workshop.yaml, а Workshop подтягивает и устанавливает нужные компоненты при запуске. Перед добавлением SDK можно выполнить поиск:

sdk find ollama
sdk info ollama

Команда sdk info показывает каналы, версии, базовые образы и размер. Это важно, потому что один и тот же SDK может иметь разные варианты: CPU, CUDA, ROCm, Vulkan, stable, beta или edge. Для повседневной разработки обычно безопаснее начинать со stable-каналов.

Пример окружения для локального AI-сценария из документации выглядит так:

name: dev
base: ubuntu@22.04
sdks:
  - name: ollama
    channel: cpu/stable

После запуска можно выполнить команду внутри окружения:

workshop exec dev -- ollama run tinyllama

В таком сценарии проект остаётся на хостовой системе, а инструментальная часть работает внутри управляемой среды. Разработчик может запускать команды, открывать shell, обновлять окружение, подключать интерфейсы и фиксировать состояние через механизмы Workshop.

Изоляция помогает безопаснее запускать AI-агентов и экспериментальные инструменты

Canonical отдельно подчёркивает сценарии agentic AI. Под этим термином обычно понимают инструменты, где AI-система способна выполнять цепочки действий: читать файлы проекта, запускать команды, вызывать утилиты, генерировать код и проверять результат. Такие инструменты удобны, но требуют аккуратного ограничения доступа.

Workshop запускает окружения в непривилегированных системных контейнерах. Это снижает площадь атаки и помогает отделить рабочие нагрузки от основной системы. Доступ к ресурсам хоста оформляется через интерфейсы. Например, можно управлять доступом к рабочему столу для GUI-приложения, SSH-агенту, GPU, сетевым сервисам, камере или отдельным каталогам.

Для команды это даёт понятную модель: AI-агент или экспериментальный инструмент работает внутри описанного окружения, а доступ к чувствительным ресурсам задаётся явно. Такой подход особенно актуален для проектов, где разработчики тестируют новые code assistants, локальные LLM, автоматические ревью и генераторы кода.

Изоляция не отменяет обычные меры безопасности. Команде всё равно стоит проверять SDK, смотреть издателя, фиксировать каналы, ограничивать секреты и не выдавать окружению лишний доступ к домашнему каталогу, SSH-ключам и приватным токенам.

Базовый рабочий цикл состоит из запуска, команд, обновления и восстановления

Workshop рассчитан на повторяемый цикл работы. Сначала в проекте создают workshop.yaml, затем запускают окружение:

workshop launch

После запуска можно посмотреть состояние:

workshop list
workshop info

Для выполнения команды внутри окружения используется workshop exec:

workshop exec dev -- go version

Для интерактивной работы доступна оболочка:

workshop shell

Когда среда временно не нужна, её можно остановить:

workshop stop

Затем вернуть в рабочее состояние:

workshop start

Если в YAML-файле изменились SDK, база Ubuntu или канал, применяется обновление:

workshop refresh

Документация подчёркивает важную особенность refresh: если обновление ломается, Workshop откатывает изменение к предыдущему рабочему состоянию. Для повседневной разработки это полезнее ручной пересборки, где сбой часто оставляет систему в промежуточном состоянии.

Для сброса изменений внутри окружения есть команда:

workshop restore

Её стоит использовать осознанно: она возвращает окружение к последнему успешному состоянию и может удалить изменения, сделанные внутри контейнера после запуска или refresh.

Командная разработка выигрывает от версионирования workshop.yaml

Workshop особенно полезен там, где окружение проекта нужно передавать между людьми. Файл workshop.yaml можно хранить в Git вместе с кодом. Новый разработчик клонирует репозиторий, устанавливает Workshop и запускает окружение с теми же SDK.

В репозиторий также можно добавлять директорию .workshop/, если она используется для определения окружений. Локальный файл .workshop.lock документация рекомендует добавить в .gitignore, потому что он относится к конкретной машине и конкретному запуску.

Практический результат для команды:

Ситуация	Польза Workshop
Новый разработчик подключается к проекту	Среда поднимается по описанию из репозитория
Проект требует редких версий библиотек	Зависимости не смешиваются с основной системой
Нужно проверить баг коллеги	Окружение проще воспроизвести по одному YAML
Используются локальные AI-инструменты	Доступ к ресурсам можно ограничивать через интерфейсы
В проекте есть GPU-сценарии	SDK могут описывать CUDA, ROCm или Vulkan-ветки

Для небольших личных проектов Workshop тоже может быть полезен, если разработчик часто переключается между языками, фреймворками и экспериментальными инструментами.

Ограничения связаны с Snap, LXD и зрелостью нового инструмента

Workshop выглядит перспективно, но перед внедрением стоит учитывать несколько практических моментов.

Первое ограничение — зависимость от Snap и LXD. В Ubuntu это естественная связка, а в других дистрибутивах потребуется проверить поддержку Snap, свежую версию LXD и настройки хранения. В корпоративных окружениях Snap иногда ограничен политиками безопасности, поэтому установку лучше согласовать с администратором.

Второй момент — размер SDK и базовых образов. Некоторые SDK могут занимать гигабайты, особенно варианты для AI, GPU и крупных фреймворков. Перед массовым внедрением стоит оценить дисковое пространство, скорость загрузки и поведение кэша.

Третья зона внимания — доверие к SDK. Разработчику нужно проверять издателя, канал и назначение пакета. Для стабильной работы лучше фиксировать осознанные каналы, документировать выбор SDK и избегать случайного перехода на edge-ветки в командных проектах.

Четвёртый фактор — ранняя стадия развития. На GitHub у Workshop уже есть открытые issues и обсуждения новых возможностей. Это нормальная ситуация для свежей developer utility. Для критичных рабочих процессов разумно сначала протестировать инструмент на отдельном проекте, затем переносить в командную практику.

Workshop лучше всего подходит проектам с повторяемыми окружениями и AI-экспериментами

Workshop стоит рассмотреть разработчикам, которые регулярно настраивают сложные окружения, работают с несколькими версиями инструментов, подключают локальные модели, тестируют AI-агентов или хотят уменьшить хаос в onboarding. Самый простой путь — взять небольшой проект, описать один SDK, запустить окружение и проверить, насколько удобно выполнять обычные команды.

Минимальный стартовый сценарий:

Проверить наличие Snap и установить LXD 6.8+.
Установить Workshop через sudo snap install --classic workshop.
Создать в проекте workshop.yaml.
Запустить workshop launch.
Выполнить пару команд через workshop exec.
Добавить workshop.yaml в Git и .workshop.lock в .gitignore.

Для одиночного разработчика Workshop даёт чистую среду и меньше ручной настройки. Для команды он даёт общий язык описания окружений. Для AI-сценариев он добавляет важный слой изоляции и управления доступом к ресурсам хоста.

Главный вывод для разработчиков

Canonical Workshop закрывает понятную боль современной разработки: локальные окружения быстро усложняются, а команды хотят воспроизводимости, изоляции и простого запуска. Утилита делает ставку на YAML-описания, LXD-контейнеры, SDK Store и управляемые интерфейсы доступа к ресурсам.

Инструмент особенно интересен пользователям Ubuntu, командам с container-first подходом и разработчикам, которые экспериментируют с локальными AI-инструментами. Начать стоит с тестового проекта и одного стабильного SDK, чтобы оценить удобство команд launch, exec, shell, refresh и restore без риска для основного рабочего процесса.