14.07.2026 14:30
Есть разные способы автоматической доставки необходимых пакетов софта на целевые сервера: ansible или аналоги, bash, в частности с помощью bashible, c…
Есть разные способы автоматической доставки необходимых пакетов софта на целевые сервера: ansible или аналоги, bash, в частности с помощью bashible, cloud-init, различные ci/cd системы со своими агентами. Во всех этих системах первое, что приходит в голову, сформировать список необходимых пакетов и передавать его на установку. В случае необходимости, список можно менять.
Но есть и другой распространённый подход - создание мета-пакета, который включает в себя в виде зависимостей набор отдельных пакетов. В случае каких-то изменений в составе пакетов, вам не придётся менять составленный ранее список. Достаточно изменить сам мета-пакет, и сервера при стандартном обновлении установят недостающее.
В зависимости от ситуации, можно использовать тот или иной подход. У каждого есть как свои плюсы, так и минусы. Например, если список пакетов хранится в ansible и часто меняется, придётся постоянно обновлять список в переменной и пушить эти изменения в репозиторий. Если они несущественны и не требуют отдельного учёта, проще менять мета-пакет, не затрагивая код ролей или плейбуков. Например, если вы ведёте набор софта для настройки рабочей станции на Linux. Там будет масса всего для установки. Удобно всё это завернуть в один мета-пакет workstation и менять именно его.
Мета-пакеты во всю представлены в стандартных репозиториях. Самый популярный мета-пакет - linux-image-amd64, который обновляет ядро. Посмотреть его состав можно так:
# apt show linux-image-amd64
.....
Description: Linux for 64-bit PCs (meta-package)
.....
Набор инструментов build-essential, оболочки gnome, xfce4, kde - это всё тоже мета-пакеты. Узнал о них совершенно случайно не так давно. Сколько лет настраиваю линуксы, всегда пакеты по одному ставил, храня списки в переменных.
Собрать свой мета-пакет очень просто. Покажу на примере мета пакета deb-base с набором программ, которые я обычно ставлю на все сервера:
# mkdir -p ~/deb-base/DEBIAN
# nano ~/deb-base/DEBIAN/control
Package: deb-base
Version: 1.0
Architecture: all
Maintainer: Vladimir <root@serveradmin.ru>
Depends: sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop
Description: Base Debian server configuration
# dpkg-deb --build deb-base
Получил на выходе мета-пакет deb-base.deb, у которого в зависимостях sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop. При установке мета-пакета они все будут установлены:
# apt install ./deb-base.deb
Причём эти пакеты устанавливаются по-отдельности, их можно как обычно посмотреть через dpkg:
# dpkg -l | grep iftop
В случае необходимости любой из установленных пакетов можно удалить как обычно через apt. Если изменить список пакетов и версию в файле control, пересобрать мета-пакет и запустить:
# apt upgrade ./deb-base.deb
То в систему будет добавлено то, чего не хватает из зависимостей в мета-пакете. Если ты свои пакеты хранишь в локальном репозитории, то изменения приедут на целевые сервера с плановым обновлением.
Работают мета-пакеты просто и прозрачно, используя для создания встроенный в deb дистрибутивы менеджер пакетов dpkg. Есть и другие инструменты для этого, но этот проще всего.
#linux
Но есть и другой распространённый подход - создание мета-пакета, который включает в себя в виде зависимостей набор отдельных пакетов. В случае каких-то изменений в составе пакетов, вам не придётся менять составленный ранее список. Достаточно изменить сам мета-пакет, и сервера при стандартном обновлении установят недостающее.
В зависимости от ситуации, можно использовать тот или иной подход. У каждого есть как свои плюсы, так и минусы. Например, если список пакетов хранится в ansible и часто меняется, придётся постоянно обновлять список в переменной и пушить эти изменения в репозиторий. Если они несущественны и не требуют отдельного учёта, проще менять мета-пакет, не затрагивая код ролей или плейбуков. Например, если вы ведёте набор софта для настройки рабочей станции на Linux. Там будет масса всего для установки. Удобно всё это завернуть в один мета-пакет workstation и менять именно его.
Мета-пакеты во всю представлены в стандартных репозиториях. Самый популярный мета-пакет - linux-image-amd64, который обновляет ядро. Посмотреть его состав можно так:
# apt show linux-image-amd64
.....
Description: Linux for 64-bit PCs (meta-package)
.....
Набор инструментов build-essential, оболочки gnome, xfce4, kde - это всё тоже мета-пакеты. Узнал о них совершенно случайно не так давно. Сколько лет настраиваю линуксы, всегда пакеты по одному ставил, храня списки в переменных.
Собрать свой мета-пакет очень просто. Покажу на примере мета пакета deb-base с набором программ, которые я обычно ставлю на все сервера:
# mkdir -p ~/deb-base/DEBIAN
# nano ~/deb-base/DEBIAN/control
Package: deb-base
Version: 1.0
Architecture: all
Maintainer: Vladimir <root@serveradmin.ru>
Depends: sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop
Description: Base Debian server configuration
# dpkg-deb --build deb-base
Получил на выходе мета-пакет deb-base.deb, у которого в зависимостях sudo, curl, wget, htop, rsync, unattended-upgrades, net-tools, lsof, iftop. При установке мета-пакета они все будут установлены:
# apt install ./deb-base.deb
Причём эти пакеты устанавливаются по-отдельности, их можно как обычно посмотреть через dpkg:
# dpkg -l | grep iftop
В случае необходимости любой из установленных пакетов можно удалить как обычно через apt. Если изменить список пакетов и версию в файле control, пересобрать мета-пакет и запустить:
# apt upgrade ./deb-base.deb
То в систему будет добавлено то, чего не хватает из зависимостей в мета-пакете. Если ты свои пакеты хранишь в локальном репозитории, то изменения приедут на целевые сервера с плановым обновлением.
Работают мета-пакеты просто и прозрачно, используя для создания встроенный в deb дистрибутивы менеджер пакетов dpkg. Есть и другие инструменты для этого, но этот проще всего.
#linux