Come installare automaticamente i ruoli di Ansible Galaxy?


129

Tutti i miei playbook / ruoli Ansible sono registrati nel mio repository git.

Tuttavia, per i ruoli di Ansible Galaxy devo sempre scaricarli esplicitamente uno per uno su ogni macchina da cui voglio eseguire Ansible.

È persino difficile sapere in anticipo esattamente quali ruoli di Ansible Galaxy sono necessari fino a quando Ansible non si lamenta di un ruolo mancante in fase di esecuzione.

Come si può gestire le dipendenze del ruolo Ansible Galaxy? Vorrei che li avessi registrati nel mio repository git insieme al resto del mio codice Ansible o che fossero automaticamente identificati e scaricati quando eseguo Ansible su una nuova macchina.


galaxy.ansible.com/docs/using/index.html Ecco tutto ciò di cui hai bisogno per usare ansible-galaxy. È un documento ben fatto! Anche se sei un principiante :)
Ayra,

@pdeva Potresti accettare una delle risposte valide di seguito?
GG.

Risposte:


148

È necessario utilizzare un requirements.ymlfile per questo caso d'uso. Descrivi i ruoli richiesti, utilizzando uno dei vari metodi di installazione:

# 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>

Quindi installali:

ansible-galaxy install -r requirements.yml

Ecco un esempio funzionante (installazione di OpenDaylight utilizzando Ansible come provisioner di Vagrant). Consulta i documenti Ansible pertinenti per ulteriori informazioni.


Vedi anche la risposta di @Kieran Andrews di seguito. Espande questo.
Marco Ferrari

1
Questo in realtà non sta installando automaticamente le dipendenze dei ruoli di un playbook, sta installando esplicitamente un elenco di dipendenze che sono state elencate manualmente dall'umano che ha creato il playbook.
Neil

53

Come suggerito, puoi usare ansible galaxy per questa esigenza.

Ansible ha una funzione in cui puoi creare un requirements.ymlfile che elenca tutti i tuoi ruoli. Puoi scoprirlo qui: http://docs.ansible.com/ansible/latest/galaxy.html#installing-multiple-roles-from-a-file

Ad esempio (requisito.yml):

- src: yatesr.timezone

Quindi eseguire ansible-galaxy install -r requirements.ymlquesto file per scaricare tutti i ruoli elencati lì.

Se si desidera automatizzarlo ulteriormente, è possibile creare un semplice script shell che eseguirà i due comandi.

Ad esempio (ansible.sh):

./ansible.sh

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

1
Appena testato, mostra un messaggio che i ruoli sono già stati scaricati, nessun errore. Versione2.2.1
Igonato

Se il playbook fa uso dei ruoli della galassia che stai installando, non verranno eseguiti la prima volta che il playbook viene invocato poiché la loro presenza viene verificata prima che siano stati scaricati. Chiamare il playbook una seconda volta raccoglierà i ruoli appena installati.
Ben

Ho aggiornato il modo in cui lo sto facendo ora, con uno script wrapper per ridurre i comandi.
Kieran Andrews,

19

Mi trovo spesso a installare l'installazione di un JDK Java. L'uso di un ruolo semplifica quel tocco. Ho provato un paio di modi diversi (inclusi molti .gitmodules e sottomodule ... Devo usare più sistemi git per lavorare e tutto diventa brutto). Il mio requisito più grande è che non eseguo il check del codice di ruolo nel mio progetto di playbook, soprattutto per poter tenere tutto in un unico posto.

Il contenuto del mio file 'requisito.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

Corro un playbook separato, install-role.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

Gestisco questo primo playbook, quindi eseguo normalmente i miei ruoli in qualsiasi playbook. Per me il segreto è assicurarsi che sia ignorato da Git, quindi non controllo i ruoli per errore. Inoltre, dato che ogni volta pulisco la cartella, mi assicuro di non aver bisogno di forzare o ignorare gli errori.


Fallirà con "ruolo non trovato" prima ancora di eseguire il comando locale.
Daniel Andrei Mincă,

1
@ Mincă Daniel Andrei devi usare un modo dinamico, ad esempio include_role. controlla questo
user1686407

4

Un'altra soluzione è utilizzare i sottomoduli git. Dopotutto, Ansible Galaxy è solo una directory di repository github ...

Uso questo comando per aggiungere automaticamente qualsiasi ruolo Galaxy come sottomodulo:

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

Apporta le modifiche quindi al tuo repository git. Quando clonerai il tuo repository in futuro, assicurati di clonarlo con sottomoduli, ad esgit clone ... --recursive

Un vantaggio di ciò è che un sottomodulo git fa sempre riferimento a una versione specifica (git commit-hash). Ciò ti impedirà di eseguire aggiornamenti non testati nel tuo ambiente produttivo. Una nuova versione di un ruolo Galaxy potrebbe avere bug o funzionare in modo completamente diverso rispetto a prima. Con un sottomodulo git decidi se e quando aggiorni un ruolo alla nuova versione.

Inoltre, non dovrai occuparti ulteriormente della lista nera dei ruoli della galassia nel tuo .gitignoreper evitare di commettere il loro codice nel tuo repository.


5
Questa è una cattiva pratica secondo me. Di solito è più semplice utilizzare gli strumenti di gestione delle dipendenze quindi incollare insieme i repository SCM, soprattutto quando si parla di sottomoduli git per SCM.
David Resnick,

1
Concordato. In realtà non lo sto più usando. Tuttavia è un approccio valido poiché ansible-galaxy è tutt'altro che perfetto. Galaxy non verificherà la presenza di aggiornamenti, anche se una versione è stata inserita nel file dei requisiti, se la costringi a scaricare di nuovo tutti i ruoli con il --forceflag non documentato , non ti mostrerà se o cosa è effettivamente cambiato. È una scatola nera che puoi controllare solo se mantieni i ruoli della galassia scaricati in SCM. Per altri motivi, questa è comunque una buona idea. Quando si estraggono i sottomoduli si vede almeno quali ruoli sono cambiati.
udondan,

A proposito, tutti i problemi che hanno i sottomoduli, AFAIK sono trascurabili in questa situazione perché sono collegati alla modifica del loro contenuto. Tirare è perfettamente perfetto per la mia esperienza ..
udondan,

4

È possibile utilizzare un ruolo Ansible per installare i ruoli necessari utilizzando il modulo comandi .

Ecco un esempio molto semplice che viene eseguito ansible-galaxy install:

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

La ansible_roles_listpuò essere fornito come una variabile o come parametro ruolo.

Se lo fai in un ruolo, deve essere applicato prima di qualsiasi altro ruolo che desideri installare utilizzandolo, in un playbook separato. Questo perché Ansible verifica se tutti i ruoli sono disponibili prima di eseguire il playbook a cui li fai riferimento.


uovo e pollo :)
bazeusz,

2

A questo punto, per quanto ne so non esiste un modo automatico per scaricare i ruoli in fase di esecuzione. La tua scommessa migliore è quella di impegnarli nel tuo repository o avere una documentazione adeguata che elenca tutti i requisiti. Potresti persino creare un playbook pre-volo che installa i tuoi ruoli. :)


3
Per questo puoi usare un file requisito.txt. Vedi: docs.ansible.com/…
toast38coza il

0

Qui, i miei requisiti sono sul ruolo e utilizzati in 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
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.