☰

Как унифицировать задачи установки пакетов в ansible?

tag-icon • tag-icon package-management ansible
Как унифицировать задачи установки пакетов в ansible?

Я начинаю сansibleи будет использовать его, среди прочего, для установки пакетов на несколько дистрибутивов Linux.

Я вижу в документации, что команды yumи aptразделены. Какой самый простой способ объединить их и использовать что-то вроде этого:

- name: install the latest version of Apache
  unified_install: name=httpd state=latest

вместо

- name: install the latest version of Apache on CentOS
  yum: name=httpd state=latest
  when: ansible_os_family == "RedHat"

- name: install the latest version of Apache on Debian
  apt: pkg=httpd state=latest 
  when: ansible_os_family == "Debian"

Я понимаю, что эти два менеджера пакетов отличаются, но у них все равно есть набор общих базовых применений. Другие оркестраторы (соль например) имеют одну команду установки.

решение1

Обновление: Начиная с Ansible 2.0, теперь есть общий и абстрактныйpackageмодуль

Примеры использования:

Теперь, когда имя пакета одинаково в разных семействах ОС, это так просто:

---
- name: Install foo
  package: name=foo state=latest

Если имя пакета отличается в разных семействах ОС, это можно исправить с помощью vars-файлов, специфичных для дистрибутива или семейства ОС:

---
# roles/apache/apache.yml: Tasks entry point for 'apache' role. Called by main.yml
# Load a variable file based on the OS type, or a default if not found.
- include_vars: "{{ item }}"
  with_first_found:
    - "../vars/{{ ansible_distribution }}-{{ ansible_distribution_major_version | int}}.yml"
    - "../vars/{{ ansible_distribution }}.yml"
    - "../vars/{{ ansible_os_family }}.yml"
    - "../vars/default.yml"
  when: apache_package_name is not defined or apache_service_name is not defined

- name: Install Apache
  package: >
    name={{ apache_package_name }}
    state=latest

- name: Enable apache service
  service: >
    name={{ apache_service_name }}
    state=started
    enabled=yes
  tags: packages

Затем для каждой ОС, с которой вам придется работать по-разному, создайте файл vars:

---
# roles/apache/vars/default.yml
apache_package_name: apache2
apache_service_name: apache2

---
# roles/apache/vars/RedHat.yml
apache_package_name: httpd
apache_service_name: httpd

---
# roles/apache/vars/SLES.yml
apache_package_name: apache2
apache_service_name: apache2

---
# roles/apache/vars/Debian.yml
apache_package_name: apache2
apache_service_name: apache2

---
# roles/apache/vars/Archlinux.yml
apache_package_name: apache
apache_service_name: httpd



РЕДАКТИРОВАТЬ: С тех пор как Майкл ДеХаан (создатель Ansible)решил не абстрагироваться от модулей менеджера пакетовнравитьсяШеф-поварделает,

Если вы все еще используете старую версию Ansible (Ansible < 2.0), к сожалению, вам придется заниматься этим самостоятельновсеваших сценариев и ролей. ИМХОэто накладывает много ненужной повторяющейся работы на авторов плейбуков и ролей... но это так, как есть сейчас. Обратите внимание, что я не говорю, что мы должны попытаться абстрагировать менеджеров пакетов, продолжая при этом поддерживать все их конкретные опции и команды, а просто иметь простой способ установки пакета, который не зависит от менеджера пакетов. Я также не говорю, что мы все должны прыгнуть наУмный менеджер пакетовпобедитель, но что некий уровень абстракции установки пакетов в вашем инструменте управления конфигурацией очень полезен для упрощения кроссплатформенных плейбуков/кулинарных книг. Проект Smart выглядит интересным, но он довольно амбициозен для унификации управления пакетами между дистрибутивами и платформами без особого внедрения... будет интересно посмотреть, будет ли он успешным. Реальная проблема заключается в том, что имена пакетов иногда имеют тенденцию различаться в разных дистрибутивах, поэтому нам все равно приходится делать операторы case или when:операторы для обработки различий.

Я справляюсь с этим, следуя следующей tasksструктуре каталогов в сценарии или роли:

roles/foo
└── tasks
    ├── apt_package.yml
    ├── foo.yml
    ├── homebrew_package.yml
    ├── main.yml
    └── yum_package.yml

И тогда это будет у меня main.yml:

---
# foo: entry point for tasks
#                 Generally only include other file(s) and add tags here.

- include: foo.yml tags=foo

Это в foo.yml(для пакета 'foo'):

---
# foo: Tasks entry point. Called by main.yml
- include: apt_package.yml
  when: ansible_pkg_mgr == 'apt'
- include: yum_package.yml
  when: ansible_pkg_mgr == 'yum'
- include: homebrew_package.yml
  when: ansible_os_family == 'Darwin'

- name: Enable foo service
  service: >
    name=foo
    state=started
    enabled=yes
  tags: packages
  when: ansible_os_family != 'Darwin'

Затем для разных менеджеров пакетов:

Кв.:

---
# tasks file for installing foo on apt based distros

- name: Install foo package via apt
  apt: >
    name=foo{% if foo_version is defined %}={{ foo_version }}{% endif %}
    state={% if foo_install_latest is defined and foo_version is not defined %}latest{% else %}present{% endif %}
  tags: packages

Ммм:

---
# tasks file for installing foo on yum based distros
- name: Install EPEL 6.8 repos (...because it's RedHat and foo is in EPEL for example purposes...)
  yum: >
    name={{ docker_yum_repo_url }}
    state=present
  tags: packages
  when: ansible_os_family == "RedHat" and ansible_distribution_major_version|int == 6

- name: Install foo package via yum
  yum: >
    name=foo{% if foo_version is defined %}-{{ foo_version }}{% endif %}
    state={% if foo_install_latest is defined and foo_version is not defined %}latest{% else %}present{% endif %}
  tags: packages

- name: Install RedHat/yum-based distro specific stuff...
  yum: >
    name=some-other-custom-dependency-on-redhat
    state=latest
  when: ansible_os_family == "RedHat"
  tags: packages

Домашнее пиво:

---
- name: Tap homebrew foobar/foo
  homebrew_tap: >
    name=foobar/foo
    state=present

- homebrew: >
    name=foo
    state=latest

Обратите внимание, что это ужасно повторяется и неСУХОЙ, и хотя некоторые вещимощьотличаться на разных платформах и их нужно будет обрабатывать; в целом я считаю, что это многословно и громоздко по сравнению с Chef:

package 'foo' do
  version node['foo']['version']
end

case node["platform"]
when "debian", "ubuntu"
  # do debian/ubuntu things
when "redhat", "centos", "fedora"
  # do redhat/centos/fedora things
end

И да, есть аргумент, чтонекоторыйНазвания пакетов различаются в разных дистрибутивах. И хотя в настоящее время существуетотсутствие легкодоступных данных, я рискну предположить, чтобольшинствоПопулярные имена пакетов являются общими для всех дистрибутивов и могут быть установлены через абстрактный модуль менеджера пакетов. Особые случаи должны быть обработаны в любом случае, и уже требуют дополнительной работы, делая вещи менее DRY Если вы сомневаетесь, проверьтеpkgs.org.

решение2

Вы можете абстрагировать менеджеров пакетов с помощью фактов

- name: Install packages
  with_items: package_list
  action: "{{ ansible_pkg_mgr }} state=installed name={{ item }}"

Все, что вам нужно, это некоторая логика, которая устанавливает ansible_pkg_mgrили aptи yumт. д.

Ансибльтакже работаете над тем, чтобы реализовать то, что вы хотите в будущем модуле.

решение3

Начиная с Ansible 2.0 появился новый Package-modul.

http://docs.ansible.com/ansible/package_module.html

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

- name: install the latest version of Apache
  package: name=httpd state=latest

Вам все равно придется учитывать разницу в названиях.

решение4

Вы не хотите этого делать, потому что некоторые имена пакетов различаются в разных дистрибутивах. Например, в дистрибутивах, связанных с RHEL, популярный пакет веб-сервера называется httpd, тогда как в дистрибутивах, связанных с Debian, он называется apache2. Аналогично с огромным списком других системных и вспомогательных библиотек.

Может быть набор общих базовых параметров, но также есть ряд более продвинутых параметров, которые различаются между менеджерами пакетов. И вы не хотите оказаться в двусмысленной ситуации, когда для некоторых команд вы используете один синтаксис, а для других команд — другой.

Связанный контент