Mise à jour: à partir de Ansible 2.0, il existe maintenant un module générique et résumépackage
Exemples d'utilisation:
Désormais, lorsque le nom du package est identique dans différentes familles de systèmes d'exploitation, il suffit de:
---
- name: Install foo
package: name=foo state=latest
Lorsque le nom du package diffère selon les familles de systèmes d'exploitation, vous pouvez le gérer avec des fichiers vars de distribution ou de familles de systèmes d'exploitation:
---
# 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
Ensuite, pour chaque système d'exploitation que vous devez gérer différemment ... créez un fichier 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
EDIT: Depuis que Michael DeHaan (créateur d’Ansible) a choisi de ne pas faire abstraction des modules de gestion de paquets comme le fait Chef ,
Si vous utilisez toujours une ancienne version de Ansible (Ansible <2.0) , vous devrez malheureusement le faire dans tous vos playbooks et rôles. IMHO, cela impose beaucoup de travail répétitif inutile sur les auteurs de playbooks et de rôles ... mais c'est comme ça actuellement. Notez que je ne dis pas que nous devrions essayer d’abstraire les gestionnaires de paquets tout en essayant de prendre en charge toutes leurs options et commandes spécifiques, mais simplement un moyen facile d’installer un paquet qui n’est pas agnostique. Je ne dis pas non plus que nous devrions tous sauter dans le gestionnaire de paquets intelligent.Cela dit, une couche d’abstraction pour l’installation de paquetages dans votre outil de gestion de la configuration est très utile pour simplifier les livres de lecture / livres de cuisine multiplates-formes. Le projet Smart semble intéressant, mais il est assez ambitieux d’unifier la gestion des paquets entre les distributrices et les plates-formes sans grande adoption pour le moment… il sera intéressant de voir s’il a du succès. Le vrai problème, c'est que les noms de paquets ont parfois tendance à être différents d'une distribution à l'autre. Nous devons donc toujours faire des déclarations de cas ou des when:déclarations pour gérer les différences.
La façon dont je l'ai traitée est de suivre cette tasksstructure de répertoire dans un livre de lecture ou un rôle:
roles/foo
└── tasks
├── apt_package.yml
├── foo.yml
├── homebrew_package.yml
├── main.yml
└── yum_package.yml
Et puis avoir ceci dans mon main.yml:
---
# foo: entry point for tasks
# Generally only include other file(s) and add tags here.
- include: foo.yml tags=foo
Ceci dans foo.yml(pour le paquet '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'
Ensuite pour les différents gestionnaires de paquets:
Apte:
---
# 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
Miam:
---
# 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
Homebrew:
---
- name: Tap homebrew foobar/foo
homebrew_tap: >
name=foobar/foo
state=present
- homebrew: >
name=foo
state=latest
Notez que ceci est terriblement répétitif et non DRY , et bien que certaines choses puissent être différentes sur les différentes plates-formes et devront être gérées, généralement je pense que cela est verbeux et difficile à manier par rapport à Chef's:
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
Et oui, il y a l'argument selon lequel certains noms de paquetages sont différents d'une distribution à l'autre. Et bien qu’il existe actuellement un manque de données facilement accessibles , je me risquerais à deviner que les noms de paquets les plus populaires sont communs à toutes les distributions et qu’ils pourraient être installés via un module de gestionnaire de paquets abstraite. Les cas spéciaux devront de toute façon être traités et nécessiteront déjà un travail supplémentaire rendant les choses moins sèches . En cas de doute, vérifiez pkgs.org .