Jak automatycznie zainstalować role Ansible Galaxy?


129

Wszystkie moje playbooki / role Ansible są rejestrowane w moim repozytorium git.

Jednak w przypadku ról Ansible Galaxy zawsze muszę jawnie pobierać je pojedynczo na każdy komputer, z którego chcę uruchomić Ansible.

Trudno nawet z góry dokładnie wiedzieć, które role Ansible Galaxy są potrzebne, dopóki Ansible nie narzeknie na brakującą rolę w czasie wykonywania.

Jak należy zarządzać zależnościami ról w Ansible Galaxy? Chciałbym, aby zostały one wpisane do mojego repozytorium git wraz z resztą kodu ansible lub aby były automatycznie identyfikowane i pobierane podczas uruchamiania Ansible na nowym komputerze.


galaxy.ansible.com/docs/using/index.html Oto wszystko, czego potrzebujesz, aby używać ansible-galaxy. To dobrze zrobiony doktor! Nawet jeśli jesteś początkującym :)
Ayra

@pdeva Czy możesz zaakceptować jedną z prawidłowych odpowiedzi poniżej?
GG.

Odpowiedzi:


149

Powinieneś użyć requirements.ymlpliku dla tego przypadku użycia. Opisz wymagane role, korzystając z różnych metod instalacji:

# Install a role from the Ansible Galaxy
- src: dfarrell07.opendaylight

# Install a role from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight

# Install a role from a specific git branch
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: origin/master

# Install a role at a specific tag from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: 1.0.0

# Install a role at a specific commit from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: <commit hash>

Następnie zainstaluj je:

ansible-galaxy install -r requirements.yml

Oto działający przykład (instalacja OpenDaylight przy użyciu Ansible jako dostawcy Vagrant). Więcej informacji można znaleźć w odpowiednich dokumentach Ansible .


Zobacz także odpowiedź @Kieran Andrews poniżej. To rozszerza ten.
Marco Ferrari

1
To nie jest tak naprawdę automatyczne instalowanie zależności ról w playbooku, to jawne instalowanie listy zależności, które zostały ręcznie wymienione przez człowieka, który stworzył playbook.
Neil

53

Jak zasugerowano, do tego celu możesz użyć galaktyki ansible.

Ansible ma funkcję, w której możesz utworzyć requirements.ymlplik zawierający listę wszystkich Twoich ról. Możesz dowiedzieć się o tym tutaj: http://docs.ansible.com/ansible/latest/galaxy.html#installing-multiple-roles-from-a-file

Na przykład (Requirements.yml):

- src: yatesr.timezone

Wtedy uciekasz ansible-galaxy install -r requirements.yml ten plik, aby pobrać wszystkie wymienione tam role.

Jeśli chcesz jeszcze bardziej zautomatyzować to, możesz utworzyć prosty skrypt powłoki, który uruchomi dwie komendy.

Na przykład (ansible.sh):

./ansible.sh

ansible-galaxy install -r requirements.yml
ansible-playbook playbook.yml -i inventory 

1
Właśnie przetestowane, wyświetla komunikat, że role są już pobrane, bez błędu. Wersja2.2.1
Igonato,

Jeśli podręcznik wykorzystuje role galaktyki, które instalujesz, nie będą one działać przy pierwszym wywołaniu podręcznika, ponieważ ich obecność jest sprawdzana przed ich pobraniem. Ponowne wywołanie playbooka spowoduje pobranie nowo zainstalowanych ról.
Ben,

Zaktualizowałem sposób, w jaki robię to teraz, ze skryptem opakowującym, aby zmniejszyć liczbę poleceń.
Kieran Andrews

19

Często zdarza mi się instalować pakiet Java JDK. Korzystanie z roli ułatwia ten dotyk. Wypróbowałem kilka różnych sposobów (w tym wiele .gitmodules i submodule ... Muszę używać wielu systemów git do pracy i wszystko robi się brzydkie). Moim największym wymaganiem jest to, że nie sprawdzam kodu ról w projekcie podręcznika, głównie po to, aby wszystko trzymać w jednym miejscu.

Zawartość mojego pliku „Requirements.yml”:

- src: https://github.com/staylorx/ansible-role-wls-prep.git
  version: master
  name: staylorx.wls-prep

- src: https://my-work-git-extravaganza.com
  version: 2.x
  name: coolplace.niftyrole

#From Ansible Galaxy
- src: staylorx.oracle-jdk

Prowadzę osobny podręcznik, install-roles.yml:

---

- hosts: localhost

  tasks:
    - file:
        path:  roles
        state: absent

    - local_action:
        command ansible-galaxy install -r requirements.yml --roles-path roles

    - lineinfile:
        dest:   .gitignore
        regexp: '^\/roles$'
        line:   '/roles'
        state:  present

Uruchamiam ten pierwszy podręcznik, a następnie normalnie uruchamiam role w dowolnym podręczniku. Dla mnie sekret polega na tym, aby upewnić się, że jest ignorowany przez gita, więc nie sprawdzam przez pomyłkę ról. Ponieważ za każdym razem usuwam folder, zapewniam, że nie muszę wymuszać ani ignorować błędów.


Nie powiedzie się z „rolą nie znaleziono”, zanim jeszcze uruchomisz lokalne polecenie.
Daniel Andrei Minca,

1
@ Mincă Daniel Andrei, musisz użyć dynamicznego sposobu, np. Include_role. sprawdź to
user1686407

4

Innym rozwiązaniem jest użycie podmodułów git. W końcu Ansible Galaxy to tylko katalog repozytoriów github ...

Używam tego polecenia, aby automatycznie dodać dowolną rolę Galaxy jako moduł podrzędny:

ansible-galaxy info <package> | grep -A 1 github_repo | tr '\n' ' ' | sed -e "s/.*github_repo: \([^[:space:]]*\)[^\w]*github_user: \([^[:space:]]*\)[[:space:]]*/git submodule add git:\/\/github.com\/\2\/\1.git roles\/\2.\1/g" | sh

Następnie zatwierdź zmiany w swoim repozytorium git. Podczas klonowania repozytorium w przyszłości pamiętaj, aby sklonować je za pomocą modułów podrzędnych, npgit clone ... --recursive

Zaletą tego jest to, że podmoduł git zawsze odwołuje się do określonej wersji (git commit-hash). Uniemożliwi to uruchamianie nieprzetestowanych aktualizacji w środowisku produkcyjnym. Nowa wersja roli Galaxy może zawierać błędy lub działać zupełnie inaczej niż wcześniej. Za pomocą modułu podrzędnego git decydujesz, czy i kiedy aktualizujesz rolę do nowej wersji.

Ponadto nie będziesz musiał dodatkowo zajmować się umieszczaniem ról galaktyk na czarnej liście w swoim, .gitignoreaby zapobiec wysyłaniu ich kodu do repozytorium.


5
Moim zdaniem jest to zła praktyka. Zwykle łatwiej jest użyć narzędzi do zarządzania zależnościami, a następnie skleić repozytoria SCM, zwłaszcza gdy mówimy o modułach podrzędnych git dla SCM.
David Resnick

1
Zgoda. W rzeczywistości już tego nie używam. Wciąż jest to uzasadnione podejście, ponieważ galaktyka ansibla jest daleka od doskonałości. Galaxy nie będzie sprawdzać dostępności aktualizacji, nawet jeśli w pliku wymagań pojawi się wersja, jeśli zmusisz ją do ponownego pobrania wszystkich ról z --forceflagą nieudokumentowaną , nie pokaże Ci, czy lub co faktycznie się zmieniło. To czarna skrzynka, którą możesz kontrolować tylko wtedy, gdy zachowasz pobrane role galaktyk w SCM. Z innych powodów to i tak dobry pomysł. Podczas wyciągania podmodułów widzisz przynajmniej, które role się zmieniły.
udondan

Przy okazji, wszystkie problemy z podmodułami, AFAIK są pomijalne w tej sytuacji, ponieważ są związane z modyfikacją ich zawartości. Z mojego doświadczenia wynika, że ​​ciągnięcie jest w porządku ...
udondan

4

Możesz użyć roli Ansible, aby zainstalować potrzebne role za pomocą modułu poleceń .

Oto bardzo podstawowy przykład, który działa ansible-galaxy install:

- name: Install roles from Ansible Galaxy
  command: ansible-galaxy install {{ item.item }}
  with_items:
    - "{{ ansible_roles_list }}"

ansible_roles_listMogą być dostarczane jako zmienna lub jako parametr do naśladowania.

Jeśli zrobisz to w roli, musisz to zastosować przed innymi rolami, które chcesz zainstalować przy jej użyciu, w osobnym poradniku. Dzieje się tak, ponieważ Ansible sprawdza, czy wszystkie role są dostępne przed uruchomieniem podręcznika, w którym się do nich odwołujesz.


jajko i kurczak :)
bazeusz

2

W tej chwili, o ile wiem, nie ma automatycznego sposobu pobierania ról w czasie wykonywania. Najlepszym rozwiązaniem jest umieszczenie ich we własnym repozytorium lub posiadanie odpowiedniej dokumentacji zawierającej wszystkie wymagania. Możesz nawet utworzyć podręcznik przed lotem, który zainstaluje Twoje role. :)


3
Możesz do tego użyć pliku Requirements.txt. Zobacz: docs.ansible.com/…
toast38coza

0

Tutaj moje wymagania dotyczą roli i są używane w install.yml

main.yml

 # tasks file for MY_ROLE
- name: Install requirements
  local_action: command ansible-galaxy install -r {{ role_path }}/requirements.yml -p /etc/ansible/roles

- include_tasks: install.yml 
.  
├── playbook.yml  
├── inventory  
├── roles  
│    └── My_Role   
│        ├── tasks  
│        │   └── main.yml  
│        │   └── install.yml  
│        └── requirements.yml

0

Jeśli require.yml znajduje się w katalogu ról twojego projektu, Tower / AWX instaluje role automatycznie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.