Технически, это Ansible; потому что это без агента; Я использовал его для управления маршрутизаторами, коммутаторами, серверами и т. Д.
Кажется, вы спрашиваете, поддерживает ли package
модуль Arch Linux? Мне лень проверять, поддерживает ли это Arch; но если этого не произойдет, всегда найдется pacman
модуль ... И если это не сработает ... Всегда пишется собственный модуль.
Хотя вы говорите о большей проблеме с запуском нескольких разных дистрибутивов в производственной среде . Становится больно управлять долгое время. Вот почему рекомендуется не запускать несколько дистрибутивов в производственной среде, поскольку с точки зрения управления (исключительно из кода) это большая работа. Наиболее очевидный способ обойти это - использование Ansible when
в сочетании с os_family
:
apt:
name: apache2
when: ansible_facts['os_family'] == "Debian"
pacman:
name: nginx
when: ansible_facts['os_family'] == "Archlinux"
Я был в ситуации, когда мне приходилось управлять серверами Debian и серверами CentOS на производстве; в конце концов я выбрал чистый Debian, потому что:
- Кодовая база для CM была разрезана пополам (вся логика для специфических особенностей дистрибутива была удалена).
- Тестирование стало менее болезненным (если вы не тестируете свой код CM, значит, вы делаете это неправильно).
Вы также столкнетесь с серьезными различиями в любом случае; например:
- Некоторые пакеты называются по-разному;
httpd
(RHEL) против apache2
(Debian).
- Различные «стандартные» каталоги конфигурации;
/etc/default
(Debian) против /etc/sysconfig
(RHEL).
- Различные системы инициализации; хотя в
systemd
значительной степени взял на себя.
- Нет SSH; например WinRM для Windows.
Системы управления конфигурацией - это способ абстрагирования среды в код; и они дают вам логику / условия, чтобы сделать это самостоятельно .
package
Модуль просто вызывает модуль , определенный вansible_pkg_mgr
самом деле для этой системы. Так что любая система упаковки, которую поддерживает Ansible, будет работать.