Poradniki Ansible a role

Według dokumentacji Ansible, Playbook to:

... podstawa naprawdę prostego systemu zarządzania konfiguracją i wdrażania na wielu maszynach, w przeciwieństwie do innych, które już istnieją, a także bardzo dobrze dostosowanego do wdrażania złożonych aplikacji.

I znowu, zgodnie z tymi samymi dokumentami, role to:

... sposoby automatycznego ładowania niektórych vars_files, zadań i handlerów w oparciu o znaną strukturę plików. Grupowanie treści według ról umożliwia również łatwe udostępnianie ról innym użytkownikom.

Jednak rozróżnienie między nimi a ich różnymi przypadkami użycia nie jest dla mnie od razu oczywiste. Na przykład, jeśli skonfiguruję mój /etc/ansible/hostsplik tak, aby wyglądał następująco:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

... więc co to za [databases]wpis ... rola ? A może nazwa pliku YAML playbooka? Albo coś innego?!?

Gdyby ktoś mógł mi wyjaśnić różnice w tych kwestiach, moje zrozumienie Ansible znacznie by się poprawiło!

• Playbook vs Role vs [databases]i podobne wpisy w/etc/ansible/hosts
• Jeśli Playbooks są zdefiniowane w plikach YAML, to gdzie są zdefiniowane role?
• Oprócz ansible.cfgżycia na serwerze Ansible, w jaki sposób mogę dodać / skonfigurować Ansible z dostępnymi Playbookami / Rólami? Na przykład, kiedy uruchamiam ansible-playbook someplaybook.yaml, skąd Ansible wie, gdzie znaleźć ten poradnik?

Playbook vs Role vs [bazy danych] i podobne wpisy w / etc / ansible / hosts

[databases]to pojedyncza nazwa grupy hostów. Umożliwia odwoływanie się do wielu hostów za pomocą jednej nazwy.

Rola to zestaw zadań i dodatkowych plików umożliwiających skonfigurowanie hosta do pełnienia określonej roli .

Playbook to mapowanie między hostami i rolami.

Przykład z dokumentacji opisuje przykładowy projekt. Zawiera dwie rzeczy:

• Poradniki. site.yml, webservers.yml, fooservers.ymlSą playbooks.
• Role: roles/common/i roles/webservers/zawierają odpowiednie definicje commoni webserversrole.

Wewnątrz playbook ( webservers.yml) masz coś takiego:

---
- hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question
  roles: <- this is list of roles to assign to these hosts
     - common
     - webservers

Jeśli Playbooks są zdefiniowane w plikach YAML, to gdzie są zdefiniowane role?

Są zdefiniowane w roles/*katalogach. Role są definiowane głównie za pomocą plików YAML, ale mogą również zawierać zasoby dowolnego typu ( files/, templates/). Zgodnie z dokumentacją definicja roli ma następującą strukturę:

• Jeśli role / x / jobs / main.yml istnieją, zadania tam wymienione zostaną dodane do gry
• Jeśli istnieje roles / x / handlers / main.yml, wymienione tam podręczniki zostaną dodane do gry
• Jeśli istnieje roles / x / vars / main.yml, wymienione w nim zmienne zostaną dodane do gry
• Jeśli istnieje roles / x / meta / main.yml, wszelkie wymienione w nim zależności ról zostaną dodane do listy ról (1.3 i nowsze)
• Każde zadanie kopiowania może odnosić się do plików w rolach / x / files / bez konieczności względnego lub bezwzględnego podawania ich ścieżek
• Wszelkie zadania skryptowe mogą odwoływać się do skryptów w rolach / x / plikach / bez konieczności względnego lub bezwzględnego określania ich ścieżek
• Każde zadanie szablonu może odnosić się do plików w rolach / x / templates / bez konieczności względnego lub bezwzględnego ścieżkowania do nich
• Każde zadanie dołączania może odwoływać się do plików w rolach / x / zadaniach / bez konieczności ich względnego lub absolutnego ścieżkowania

Najważniejszy plik to roles/x/tasks/main.ymltutaj definiujesz zadania, które zostaną wykonane po wykonaniu roli.

Oprócz pliku ansible.cfg znajdującego się na serwerze Ansible, w jaki sposób mogę dodać / skonfigurować Ansible z dostępnymi Playbookami / Rólami? Na przykład, kiedy uruchamiam plik ansible-playbook someplaybook.yaml, skąd Ansible wie, gdzie znaleźć ten podręcznik?

$ ansible-playbook someplaybook.yaml

Poszuka playbooka w bieżącym katalogu.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Poszuka playbooka w somedir/somedir/katalogu.

Twoim obowiązkiem jest umieszczenie projektu ze wszystkimi playbookami i rolami na serwerze. Ansible nie ma z tym nic wspólnego.

Playbook vs Role vs [bazy danych] i podobne wpisy w / etc / ansible / hosts

Role to sposób na grupowanie zadań w jednym kontenerze. Możesz mieć rolę do skonfigurowania MySQL, inną do skonfigurowania Postfix itp.

Playbook określa, co się dzieje i gdzie . Jest to miejsce, w którym definiujesz hosty (grupy hostów, patrz poniżej) i role, które zostaną przypisane do tych hostów.

[databases]a inne wpisy w twoim ekwipunku to grupy hostów. Grupy hostów definiują zestaw hostów, na których będzie działać gra.

Zabawa to zestaw zadań lub ról (lub obu) w playbooku. W większości przypadków (i przykładów) podręcznik zawiera tylko jedną grę. Ale możesz mieć tyle, ile chcesz. Oznacza to, że możesz mieć playbook, który będzie pełnił rolę postfixw grupie hostów mail_serversi rolę mysqlw grupie hostów databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Jeśli Playbooks są zdefiniowane w plikach YAML, to gdzie są zdefiniowane role?

W Ansible prawie wszystko jest zdefiniowane w YAML, co dotyczy ról i scenariuszy.

Oprócz pliku ansible.cfg znajdującego się na serwerze Ansible, w jaki sposób mogę dodać / skonfigurować Ansible z dostępnymi Playbookami / Rólami? Na przykład, kiedy uruchamiam plik ansible-playbook someplaybook.yaml, skąd Ansible wie, gdzie znaleźć ten podręcznik?

AFAIK, musisz podać ścieżkę do playbooka podczas wywoływania ansible-playbook. ansible-playbook someplaybook.yamlSpodziewałbym someplaybook.yamlsię więc , że będzie w twoim bieżącym katalogu. Ale możesz podać pełną ścieżkę:ansible-playbook /path/to/someplaybook.yaml

To kwestia terminologiczno-semantyczna. Może być subiektywne, mimo że istnieje podstawowa definicja.

Mój pogląd jest następujący:

Każdy system zarządzania / wdrażania konfiguracji ma:

1. source data - dane użyte do stworzenia konfiguracji hosta docelowego
2. target data - dane używane do identyfikacji docelowych hostów
3. config changes- lista / zestaw reguł / działań, które stosujemy z source datahostem docelowym na podstawietarget data

W kategoriach Ansible:

1. source data- to różne miejsca, możemy umieścić dane - group_vars, playbookVars, roleVars, itd., Miejsca te wpływają pierwszeństwo (jeśli zmienna nazwana tak samo jest ponowne zdefiniowane w różnych miejscach, są bardzo specyficzne zasady jaka byłaby wartość materiałów zmienna podczas ansible/ ansible-playbookwykonywania
2. target data - to ekwipunek (możliwe jest również zdefiniowanie zmiennych inwentarza / grupy hostów w ekwipunku!)
3. config changes - ansibl ma 4 poziomy abstrakcji:
   1. zadanie - pojedyncze działanie
   2. lista zadań - lista czynności
   3. role - lista działań (lub lista list) pogrupowanych według tego samego „tematu”, zwykle wszystkie cele działają na tym samym hoście / grupie hostów
   4. playbook - lista odtworzeń, z których każda działa na możliwie innej grupie hostów, stosująca kilka list roles / tasks / zadań (i zadań specjalnych, takich jak handlers)

Z punktu widzenia „oprogramowania” - rola powinna być na tyle ogólna, aby można ją było ponownie wykorzystać .

Również w niektórych (raczej dużych) organizacjach `` role '' są przypisywane przez grupę A, podczas gdy są używane w podręcznikach utrzymywanych przez grupę B.

Podsumowanie

Wszystko to pozwala na grupowanie podobnych konfiguracji - w plik role. grupowanie powiązanych podsystemów / komponentów w jeden playbook. Ponadto, warto wspomnieć, 1 YAML pozycja w playbook (w tym hosts:i albo albo tasks, pre_tasks, post_tasks, roles) nazywamyplay

A teraz pytanie:

Tak, na początku jest to zagmatwane.

Zwykle łączysz się source dataz semantyką swojej roli, więc kiedy widzisz, że ta rola setup_dbjest stosowana w grze na powiązanej grupie hostów (np. db_hosts) Ale playmoże przebiegać przez sumę kilku grup hostów. To tylko kwestia konwencji kontra elastyczności.

PS

Proszę o odpowiedź, czy to zwiększyło zamieszanie, czy też wyjaśniło. Dzięki.

Należy również pamiętać, że podręcznik może przywołać więcej niż jedną rolę, jeśli używany jest metaplik, który ma wpływać na różne role.

Przykładowy podręcznik: dual_role-playbook.yml

- name: Some Action for two roles
  hosts: localhost

  vars_files:
    - roles/dual_role/meta/main.yml

  roles:
    - dual_role/container-1
    - dual_role/container-2

Folder ról i schemat plików będzie wyglądał następująco:

dual_role-playbook.yml
  -- roles
     -- dual_role
        -- meta/main.yml
        -- container-1
           -- tasks/main.yml
           -- templates/template.j2
        -- container-2
           -- tasks/main.yml
           -- templates/template.j2

Mówiąc najprościej:

Playbook jest jak główny program, zawiera kompletne instrukcje, jak zakończyć pracę. Jednak w przypadku dużych projektów nie jest pożądane umieszczanie w nich każdego szczegółu. Więc potrzebujesz roli.

Rola jest podprogramem i zwykle osiąga jeden cel, np. Konfigurację serwera bazy danych. Możesz umieścić go w roles/katalogu lub pobrać role stron trzecich, dostarczając identyfikatory URI rolesfile.ymli poprosić ansible-galaxy o pobranie ich za Ciebie.

Jest [database]to grupa hostów zdefiniowana w pliku spisu, która zawiera listę hostów należących do tej databasegrupy. Możesz także określić grupę serwerów internetowych, określając coś takiego jak

[web]
web1.example.com
web2.example.com

Grupa weblub databasemoże być następnie używana w playbookach lub rolach, aby określić hosty do zastosowania.

Grupy mogą być również używane w poleceniu ansibledo uruchamiania poleceń ad-hoc.