Компания, стоящая за Ubuntu, также создает эти удивительно полезные инструменты для разработчиков
Когда вы слышите «Canonical», первое, что приходит на ум, — это Ubuntu, самая популярная в мире облачная операционная система. Но лондонская компания незаметно собрала арсенал инструментов с открытым исходным кодом, которые меняют то, как разработчики создают, тестируют и поставляют программное обеспечение. От мгновенных локальных виртуальных машин до Kubernetes производственного уровня — побочные проекты Canonical работают далеко за пределами своей весовой категории. Это глубокое погружение исследует три скрытых жемчужины в портфолио Canonical, которые должны быть в арсенале каждого фронтенд-разработчика, DevOps-инженера и системного архитектора.
Multipass: Мгновенные виртуальные машины Ubuntu на любой платформе
Бич кроссплатформенного разработчика — это единообразие среды. Вы пишете код на macOS, развертываете на Linux и молитесь, чтобы CI-конвейер поймал то, что не заметила ваша локальная машина. Multipass устраняет это трение. Это легковесный менеджер виртуальных машин, который одной командой в терминале запускает свежий экземпляр Ubuntu. Никаких Vagrantfile, никакого GUI VirtualBox, никакой сложной сетевой магии.
Multipass использует родные гипервизоры: Hyper-V на Windows, QEMU на macOS и KVM на Linux, что делает его значительно быстрее альтернатив на основе VirtualBox. Время загрузки на современном оборудовании составляет менее трех секунд.
Как Multipass превосходит Docker для чистых Linux-нагрузок
Контейнеры замечательны, но они разделяют ядро хоста. Когда вам нужна среда с настоящим ядром Linux — для тестирования модулей ядра, запуска snap-пакетов или использования systemd — Multipass предоставляет полноценную ОС, а не наряженный процесс. CLI ощущается родным для современных рабочих процессов:
# Запустить виртуальную машину с именем 'dev-node', 4 ГБ ОЗУ и 2 ЦП
multipass launch --name dev-node --memory 4G --cpus 2
# Выполнить команду напрямую
multipass exec dev-node -- sudo apt update
# Примонтировать директорию хост-проекта внутрь виртуальной машины
multipass mount ~/my-project dev-node:/home/ubuntu/workДля фронтенд-разработчиков, работающих с серверным рендерингом или бэкендами на Node.js, возможность тестировать на точной копии производственной инфраструктуры локально является преобразующей. Никаких больше споров «работает на моей машине».
LXD: Системные контейнеры, которые ощущаются как виртуальные машины
LXD стирает грань между контейнерами и виртуальными машинами. Это «системные контейнеры»: они запускают полноценную систему инициализации, имеют постоянное хранилище и ведут себя в точности как отдельный Linux-сервер. При этом они потребляют значительно меньше ресурсов, чем традиционная виртуальная машина, поскольку разделяют ядро хоста. LXD — это ответ Canonical на вопрос: «Что, если бы внутри Docker была полноценная ОС?»
Реальный рабочий процесс: локальная микросервисная архитектура
Представьте, что вы создаете современное веб-приложение с фронтендом на React, Python API, кэшем Redis и базой данных PostgreSQL. С помощью LXD вы можете смоделировать всю производственную топологию локально:
# Создать контейнер для базы данных
lxc launch ubuntu:22.04 db-server
lxc exec db-server -- apt install postgresql -y
# Создать контейнер для API
lxc launch ubuntu:22.04 api-server
lxc exec api-server -- apt install python3-pip -y
# Назначить статические IP-адреса и связать их
lxc network attach lxdbr0 db-server eth0
lxc config device set db-server eth0 ipv4.address=10.0.0.10Каждый контейнер получает собственный сетевой интерфейс, правила брандмауэра и ограничения ресурсов. Вы можете симулировать задержки в сети, потерю пакетов или даже отключить сервис, чтобы проверить отказоустойчивость.
LXD изначально интегрируется с cloud-init, что позволяет подготавливать контейнеры с теми же инструментами управления конфигурацией, которые используются в AWS, Azure и Google Cloud. Ваша локальная тестовая среда соответствует производственной инфраструктуре вплоть до версий пакетов ОС.
Juju: Моделирование приложений за пределами YAML-хаоса
Инфраструктура как код обычно означает огромные YAML-файлы и Bash-скрипты, которые становятся неподдерживаемыми в течение нескольких месяцев. Juju использует принципиально иной подход: он моделирует отношения между сервисами, а не только их конфигурации. «Пакет» Juju — это декларация всего вашего стека и того, как компоненты соединяются.
Экосистема Charm автоматизирует операционные знания
«Charm» — это оператор, фрагмент кода, который инкапсулирует операционную мудрость развертывания и управления сервисом. Нужен высокодоступный кластер PostgreSQL с автоматическим переключением при сбое? Для этого есть charm, поддерживаемый экспертами по базам данных. Развернуть его можно одной командой:
juju deploy postgresql --channel 14/stable -n 3
juju deploy my-django-app
juju relate my-django-app postgresql:dbПоследняя строка — это магия. juju relate говорит Juju, что вашему Django-приложению нужна база данных. Juju автоматически настраивает PostgreSQL, создает базу данных и пользователя и вставляет строку подключения в переменные окружения вашего Django-приложения. Никакой ручной настройки.
Преодоление разрыва между разработкой и производством
Истинная мощь экосистемы Canonical проявляется, когда вы используете эти инструменты вместе. Типичный рабочий процесс выглядит так:
- Разрабатывайте локально с помощью виртуальных машин Multipass, соответствующих вашей целевой версии Ubuntu.
- Симулируйте полную топологию с помощью контейнеров LXD для каждого сервиса.
- Моделируйте развертывание с помощью пакетов Juju, которые определяют отношения и правила масштабирования.
- Развертывайте идентично в любом публичном или частном облаке или на «голом железе».
<ComparisonTable headers="
