2016-03-03 10 views
5

Sono bloccato. Googled fuori dal Web e non riuscivo a trovare una risposta.Come distinguere tra staging/produzione con un inventario dinamico?

Utilizzo Ansible da anni, ma sempre con inventari statici. Per distinguere tra diversi ambienti come la gestione temporanea e la produzione, ho utilizzato diversi file di inventario statico, staging e production, rispettivamente. Quando ho bisogno di server di gestione temporanea disposizione, farei:

ansible-playbook site.yml -i staging 

Quando ho voluto fare lo stesso per la produzione, lo farei:

ansible-playbook site.yml -i production 

Sia messa in scena e la produzione hanno bisogno di variabili con diversi valori, quindi ho group_vars/staging e group_vars/production. Tutto bene e secondo le migliori pratiche.

Ora, ho bisogno di fornire istanze EC2 in AWS. Sto usando this AWS guide. Ho un playbook con due giochi. Il primo viene eseguito su localhost, crea/trova istanze EC2 necessarie in AWS e popola un gruppo con add_host. Il secondo gioco usa quel gruppo per correre contro le istanze EC2 scoperte nel primo gioco. Tutto secondo quella guida.

Tutto funziona alla grande tranne una cosa. Non ho idea di come specificare quale ambiente eseguire il provisioning e quindi le variabili richieste non vengono caricate da group_vars/(staging|production). Fondamentalmente, quello che voglio è qualcosa di simile a -i (staging|production) Ho usato tutti questi anni con inventari statici, ma sembra che l'utilizzo di -i non abbia senso ora dato che l'inventario è dinamico. Voglio un modo per essere in grado di caricare variabili da group_vars/staging o da group_vars/production in base a un argomento che passo a ansible-playbook durante l'esecuzione.

Come posso fare? Qual è la migliore pratica?

+0

Forse potresti fare qualcosa con i playbook separati? Qualcosa come production.yml e staging.yml. Questi quaderni includevano quindi site.yml, ma includevano anche le loro vv specifiche per env. –

risposta

3

Mentre non sono sicuro di come farlo con EC2 anabolizzante, poiché non lo usiamo per costruire scatole da livello ansible, c'è un modo semplice per ottenere quello che vuoi con e le impostazioni semplici nel tuo inventories/main. Quello che devi fare è configurare ec2.py e ec2.ini all'interno del tuo inventories così da essere usato come fonte di istanze. Assicurati di rimuovere il commento da group_by_tag_keys = True all'interno di ec2.ini.

Il passo successivo è quello di differenziare quale istanza va dove. Mentre ci sono molti metodi di selezione disponibili in ec2.py, preferisco taggare specificamente ogni istanza di conseguenza. Quindi tutte le mie istanze hanno un tag chiamato environment che viene riempito di conseguenza (nel tuo caso sarebbe la gestione o la produzione). Quindi non resta che gestirlo all'interno del tuo inventories/main, ed ecco un piccolo esempio su come farlo.

In primo luogo è necessario definire gruppo vuoto per i tag che si desidera utilizzare:

[tag_environment_staging] 

[tag_environment_production] 

in modo che possiamo poi fare riferimento a loro. Dopodiché tutto ciò che resta da fare è specificare quei gruppi come figli per le fasi appropriate. Quindi dopo questo il nostro file minimale sarà simile a quello:

[tag_environment_staging] 

[tag_environment_production] 

[staging:children] 
tag_environment_staging 

[production:children] 
tag_environment_production 

Ed ecco fatto.D'ora in poi ogni istanza estratta da ec2 tramite lo script di inventario dinamico fornito con tag di ambiente verrà abbinata alla configurazione appropriata in group_vars. Tutto quello che devi ricordare è che quando si ha a che fare con inventari dinamici, si desidera che il punto inventories della directory inventories anziché il file specifico funzioni correttamente per il suo punto.

+0

Sezioni come '[tag_environment_staging]' presuppongono già che ci siano istanze con tag. Cosa succede se voglio usare Ansible per creare effettivamente * quei tag e * tag * istanze con loro? Per farlo correttamente, ho bisogno di alcune variabili 'env' impostate su' staging' * prima * Ho anche iniziato a recuperare i dati da AWS. Prima di eseguire il mio playbook, il nostro account AWS è pulito e non c'è niente lì. –

+0

Tagging stesso è facile e [presentato in modo ordinato nella documentazione] (http://docs.ansible.com/ansible/guide_aws.html#provisioning). Poi, naturalmente, devi passare al playbook che tipo di stage stai distribuendo, che è un uso abbastanza semplice di extra_vars o di env. –

+0

Ho serie di variabili - più di una dozzina di variabili - per ogni ambiente. Passo ognuno di essi con '-e' ogni volta che devo eseguire il provisioning/deploy in ogni ambiente? Questo è esattamente ciò di cui si tratta: come faccio a rendere 'group_vars/(staging | production)' magicamente incluso nel modo in cui fanno quando usano inventari statici? –

2

Ho un problema simile con gli inventari dinamici ma per Openstack. La soluzione che ho individuato finora è quella di utilizzare una variabile di ambiente per specificare se voglio indirizzare l'ambiente di staging o di produzione. Dovrebbe essere applicabile anche al tuo caso. Nella nostra configurazione $OS_PROJECT_NAME è stage o prod. In ansible.cfg set

inventory = ./inventories/${OS_PROJECT_NAME}/openstack.py 

Poi abbiamo le variabili di gruppo specifici ambiente sotto

inventories/(stage|prod)/group_vars/ 

Lo svantaggio è che devi avere lo script di inventario in due punti o lo hanno un link simbolico. Fai attenzione anche al fatto che group_vars trovato rispetto alla directory della cartella di gioco continuerà a sostituire l'inventario group_vars.

+1

Questo è l'approccio che ho trovato il migliore dopo giorni di guardare su Internet e leggere il libro ... La cosa strana è che questo aspetto abbastanza importante di Ansible non è ben documentato. – DejanLekic