Aktualizacja: Począwszy od Ansible 2.0, jest teraz ogólny i abstrakcyjny packagemoduł
Przykłady użycia:
Teraz, gdy nazwa pakietu jest taka sama w różnych rodzinach systemów operacyjnych, jest tak prosta jak:
---
- name: Install foo
package: name=foo state=latest
Gdy nazwa pakietu różni się w zależności od rodziny systemów operacyjnych, możesz obsługiwać ją za pomocą plików vars związanych z dystrybucją lub rodziną systemów operacyjnych:
---
# 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
Następnie dla każdego systemu operacyjnego, który musisz obsługiwać inaczej ... utwórz plik 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
EDYCJA: Ponieważ Michael DeHaan (twórca Ansible) postanowił nie wyodrębniać modułów menedżera pakietów, tak jak robi to Chef ,
Jeśli nadal używasz starszej wersji Ansible (Ansible <2.0) , niestety musisz poradzić sobie z robieniem tego we wszystkich swoich podręcznikach i rolach. IMHO popycha to wiele niepotrzebnych powtarzających się prac do autorów podręczników i ról ... ale tak już jest. Zauważ, że nie mówię, że powinniśmy próbować oddzielić menedżerów pakietów od siebie, jednocześnie próbując wesprzeć wszystkie ich specyficzne opcje i polecenia, ale po prostu mieć łatwy sposób na zainstalowanie pakietu, który jest niezależny od menedżera pakietów. Nie mówię też, że wszyscy powinniśmy wskoczyć na Smart Package Managerabandwagon, ale ten rodzaj warstwy abstrakcji instalacji pakietu w narzędziu do zarządzania konfiguracją jest bardzo przydatny do uproszczenia wieloplatformowych podręczników / książek kucharskich. Projekt Smart wygląda interesująco, ale ambitne jest ujednolicenie zarządzania pakietami w różnych dystrybucjach i platformach bez większego wdrożenia, jednak ... Ciekawe będzie, czy odniesie sukces. Prawdziwy problem polega na tym, że nazwy pakietów czasami różnią się w zależności od dystrybucji, więc nadal musimy wykonywać instrukcje case lub when:instrukcje, aby poradzić sobie z różnicami.
Sposób, w jaki sobie z tym poradziłem, polega na przestrzeganiu tej tasksstruktury katalogów w podręczniku lub roli:
roles/foo
└── tasks
├── apt_package.yml
├── foo.yml
├── homebrew_package.yml
├── main.yml
└── yum_package.yml
A potem mam to w moim main.yml:
---
# foo: entry point for tasks
# Generally only include other file(s) and add tags here.
- include: foo.yml tags=foo
To w foo.yml(dla pakietu „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'
Następnie dla różnych menedżerów pakietów:
Trafny:
---
# 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
Mniam:
---
# 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
Pamiętaj, że jest to strasznie powtarzalne, a nie SUCHE , i chociaż niektóre rzeczy mogą być różne na różnych platformach i będą musiały być obsługiwane, ogólnie myślę, że jest to pełne i niewygodne w porównaniu do szefa kuchni:
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
I tak, istnieje argument, że niektóre nazwy pakietów różnią się w zależności od dystrybucji. I choć nie jest obecnie brak łatwo dostępnych danych , to ośmielam się domyślać, że najbardziej popularne nazwy pakietów są powszechne w dystrybucji i mogą być instalowane za pomocą pobieranej modułu menedżera pakietów. W każdym razie należałoby poradzić sobie ze specjalnymi przypadkami, które wymagałyby dodatkowej pracy, zmniejszając SUSZENIE W razie wątpliwości sprawdź pkgs.org .