Я расскажу о подходе к организации локальных изолированных сред разработки на своей рабочей станции. Подход был выработан под воздействием следующих факторов: Подход заключается в том, чтобы вести разработку внутри LXD контейнеров запущенных локально на ноутбуке или рабочей станции с перенаправлением вывода графики в хост. Конфигурация на примере Ubuntu 20.04. Размышления о вариантах и причинах приведены в конце статьи. В Ubuntu 20.04 LXD больше не доступен для установки как deb пакет, только через snap: После установки нужно выполнить инициализацию: Единственный параметр который я меняю, это storage bakend — я использую dir как самый простой. Так как снимки и копии я не использую, то предупреждения в документации меня не пугают: Профили в LXD — это наборы параметров применяемых к нескольким контейнерам. Для моих нужд мне достаточно единственного созданного по умолчанию профиля default со следующими изменениями: Создание контейнера на базе образа images:ubuntu/20.04: Я предпочитаю образы из репозитория https://images.linuxcontainers.org, так как в них меньше предустановленного софта. По этой причине я добавил префикс images: к имени образа. Создание контейнера на базе образа из репозитория Ubuntu можно выполнить следующим образом: $ lxc launch ubuntu/20.04 dev1. Доступ к рутовому шелу контейнера: Установлю Firefox и VS Code (из репозитория по инструкции): Включу контейнер для наглядности Бонус! Довольно просто пробросить GPU в контейнер для того, чтобы запускаемые в нем приложения могли пользоваться графической картой. Для этого нужно: В том случае, если контейнер еще не запущен, нужно его запустить: Запуск VS Code от имени не привилегированного пользователя ubuntu: Запуск Firefox: Окна приложений будут отображаться на хосте, но при этом выполняться они будут внутри контейнера — подобно пробросу графики с помощью ssh. Я не выключаю запущенных контейнеров вручную, так как не вижу в этом особого смысла — ограничиваюсь закрытием окон запущенных приложений. Я предпочитаю не использовать хостовую ОС для разработки, так как это потребовало бы установки инструментов разработки, отладочных версий библиотек, настройки компонентов системы специфическим образом и других манипуляций. Все это может приводить к неожиданному поведению остального, не связанного с разработкой, программного обеспечения, а то и всей ОС. К примеру изменения в конфигурации OpenSSL могут привести к тому, что ОС перестанет корректно запускаться. Я пробовал разные средства для изоляции сред разработки: Выбранный подход импонирует мне простотой и низким порогом вхождения. В самих контейнерах можно применять специфичные для проектов подходы: устанавливать и настраивать все вручную, либо применять автоматизацию (Puppet, Ansible и т.п.), даже разворачивать инфраструктуру на базе Docker. Я использую контейнеры LXD так же для запуска специфического ПО которое либо требует установки большого количества зависимостей, либо другой версии ОС — в этом случае можно создать контейнер с нужной версией ОС к примеру $ lxc launch images:ubuntu/16.04 dev16. Важно помнить о том, что в разрезе изоляции контейнеризация имеет большую поверхность атаки по сравнению с виртуализацией — хост и контейнер делят одно ядро, уязвимость в котором может позволить вредоносному программному обеспечению сбежать из контейнера. Для экспериментов с сомнительным ПО лучше использовать более подходящие механизмы изоляции. Полезные ссылки