使用例：
パッケージ名が異なるOSファミリで同じである場合、次のように簡単です：
---
- name: Install foo
package: name=foo state=latest
パッケージ名がOSファミリ間で異なる場合、ディストリビューションまたはOSファミリ固有の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
次に、異なる方法で処理する必要がある各OSについて... 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
編集： Michael DeHaan（Ansibleの作成者）は、Chefのようにパッケージマネージャーモジュールを抽象化しないことを選択したため、
まだ古いバージョンのAnsible（Ansible <2.0）を使用している場合、残念ながらすべてのプレイブックとロールでこれを処理する必要があります。 私見では、これは多くの不必要な反復作業をプレイブックとロールの作者に押し付けます...しかし、それは現在のやり方です。特定のオプションとコマンドのすべてをサポートしようとしながら、パッケージマネージャーを抽象化しようとするのではなく、パッケージマネージャーに依存しないパッケージをインストールする簡単な方法があるだけです。スマートパッケージマネージャーにジャンプする必要があると言っているわけでもありませんただし、構成管理ツールのパッケージインストール抽象化レイヤーは、クロスプラットフォームのプレイブック/クックブックを簡素化するのに非常に役立ちます。スマートプロジェクトは面白そうに見えますが、まだ採用されていないディストリビューションとプラットフォーム間でパッケージ管理を統一することは非常に野心的です...成功するかどうかは興味深いでしょう。本当の問題は、ディストリビューション間でパッケージ名が異なる場合があるため、ケースステートメントまたは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'
次に、さまざまなパッケージマネージャーについて：
apt：
---
# 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
これはDRYではなくひどく反復的であり、プラットフォームによって異なる場合があり、処理する必要があるかもしれませんが、一般的に、これは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を確認してください。