Linee guida Ansible

Le variabili sono ampiamente utilizzate in Ansible. Ma una delle cose frustranti di Ansible è che offre troppa libertà. Questo ha sia vantaggi che svantaggi. Lo svantaggio è la complessità insieme all'elevata responsabilità e il vantaggio è la flessibilità. Esaminiamo e organizziamo ciò che sappiamo sulle variabili Ansible.

Le variabili possono essere suddivise in due categorie:

• Variabili in file separati (nella tabella sotto "Filesystem").
• Variabili nel codice (nella tabella sottostante "Codice").

Ora, se guardi alla loro priorità, allora tutto va a posto.

Le variabili del file system hanno una precedenza inferiore rispetto alle variabili del codice. Hai notato la suddetta flessibilità e l'eccessiva libertà? Continuiamo ulteriormente con questa conoscenza in mente.

1. Dichiarare le variabili in file separati

È meglio posizionare le variabili in file separati (Inventory ,group_vars ,host_vars ,role/defaults/main.yml erole/vars/main.yml ). Tutte le variabili "costanti" devono essere definite in modo esplicito. Le variabili costanti sono variabili che influenzano il ruolo o il comportamento del playbook. A differenza delle variabili "temporanee", utilizzate come buffer per memorizzare temporaneamente valori, spesso con ambito limitato. Ad esempio, le variabili dichiarate invars esiste solo dentroblock ... Per esempio:

- name: Variables scope
  hosts: localhost
  connection: local
  vars:
    MY_VAR: "I am global var"
  tasks:
    - block:
      - name: Print variable inside the block.
        debug:
          var: MY_VAR
        vars:
          MY_VAR: "I am local var"
- name: Print variable outside the block.
  debug:
    var: MY_VAR

PLAY [Variables scope]
 TASK [Gathering Facts]
 ok: [localhost]
 TASK [Print variable inside the block.]
 ok: [localhost] => {
 "MY_VAR": "I am local var"
 }
 TASK [Print variable outside the block.]
 ok: [localhost] => {
 "MY_VAR": "I am global var"
 }

Quindi, dobbiamo definire le variabili nei file. E tutte le variabili devono essere definite in modo esplicito. C'è un file per il ruolodefaults/main.yml ... I valori in questo file hanno la priorità più bassa, quindi qui possono essere posizionate anche variabili vuote. Ciò semplificherà la vita ai contributori, in particolare a quelli che vedono il codice per la prima volta.

2. Usa il LEGGIMI

Se il ruolo utilizza molte variabili diverse, forse tutte anche necessarie e utili, allora descrivile nel file README. Il comando ansible-galaxy init ti aiuterà in questo generando un modello README. Probabilmente, tu stesso, in un repository sconosciuto, sarai felice di vedere un README con informazioni su ciò che il ruolo si aspetta di vedere dentro e fuori. Un cattivo esempio potrebbe essere la separazione tra codice e descrizione. Ad esempio, il codice è in git e la descrizione è nella pagina wiki. Non vi è alcuna garanzia che i contributori aggiornino sia il codice che la pagina wiki. Di solito, dopo la richiesta pull, il lavoro termina.

3. Usa i prefissi

Tutte le variabili "costanti" (menzionate nel primo suggerimento) devono essere precedute. È meglio usare il nome del ruolo come prefisso. Questo è molto utile quando le variabili per ruoli diversi devono essere collocate nello stesso posto. Ad esempio, cosa succede in un playbook multiruolo se tutti i ruoli utilizzano la variabile porta? Aggiungendo un prefisso, garantiamo che alcune variabili non verranno sovrascritte da altre. Esempio: ruolo è console. la variabile è url, il nome della variabile è consul_url.

4. Assegna un nome alle attività con nomi significativi.

Le attività Ansible hanno nomi. Usa nomi significativi per loro come appaiono nell'output. Ricorda: questo è il tuo log, dal quale in caso di errori puoi capire cosa è andato storto.

Per esempio:

# No name/description
- copy: dest=/tmp/text.txt, content="bla-bla"
- name: Print variable global var.
 debug:
   var: MY_VAR

TASK [copy]
changed: [localhost]
TASK [Print variable global var.] *
ok: [localhost] => {
"MY_VAR": "I am global var"
}

5. ASCIUTTO (non ripeterti)

Ansible è come un normale linguaggio di programmazione. E proprio come un linguaggio normale, Ansible ha vari meccanismi per aiutarti a seguire il principio DRY (Don't Repeat Yourself). Ma ciò richiede una pianificazione anticipata per l'organizzazione del codice. Quando scrivi il codice, pensa alla riutilizzabilità.

Grandi blocchi:

Blocchi all'interno di un ruolo:(include/import)tasks ,(include/import)role ... Come può essere utilizzato? Ad esempio, stai utilizzando il modulo uri per inviare richieste API. Diciamo che queste sono richieste POST. Invece di ripetere l'URI 10 volte con tutte le impostazioni, puoi creare qualcosa come un metodo e usarlo ovunque. Simile ai metodi nei linguaggi di programmazione convenzionali, il nostro metodo accetta anche i parametri di input.

Per esempio:send_post.yml

- name: .::::::::::::. [ Sent POST request ] .::::::::::::.
 uri:
   url: "{{ URL }}"
   method: POST
   status_code: 200
   body: "{{ BODY_VAR | to_nice_json }}"
   body_format: json
   validate_certs: yes
   client_cert: tls.crt
   client_key: tls.key
   register: return_values
 when: BODY_VAR is defined

Questo codice può essere riutilizzato.

- name: Bla-bla
   include_tasks: send_post.yml
   vars:
       URL: "{{ main_url }}/{{ item }}"
       BODY_VAR: "{{ item }}"

URL e BODY_VAR sono parametri del metodo.

6. Usa i blocchi

Usobloccare.

Descrivi i parametri dell'attività solo una volta, raggruppandoli. Anche il blocco può essere utilizzato in modo simile per provare/catturare il blocco nei linguaggi di programmazione tradizionali.

- block:
   ...
  rescue:
   ...

block/rescue È un'ottima alternativaignore_errors ... Gestione degli errori essenzialmente avanzata. Ciò può essere utile, ad esempio, quando è necessario eseguire del codice in un playbook, anche in caso di errore. Ad esempio, elimina alcuni file.

 - block:
   - name: .....
   - name: .....
   - name: .....
   always:
     file:
       path: /tmp/xxxx
       state: absent

7. Non usare i moduli di comando e shell

Cerca di non usare i modulicommand eshell perché non sono idempotenti. Sebbene ci siano una serie di trucchi che possono aiutare ad alleviare questo problema. Uso:

• when
• creates (se il file esiste, questo passaggio non viene eseguito).
• removes (se il file esiste, viene eseguito questo passaggio).
• changedwhen ...

Tuttavia, se possibile, stai lontano dacommand eshell ...

8. Non usare i tag

Non utilizzare i tag. I tag possono essere un incubo per le persone che vedono il tuo codice per la prima volta. Le combinazioni di tag aumentano il numero di possibili opzioni per l'esecuzione di un playbook. Ma se non hai scelta, allora dettaglia i tag e le loro combinazioni nel README. Tuttavia, non tutti i tag sono cattivi. Ci sono eccezioni. Per esempio,always ,never - leggi di più .

skip_ansible_lint - Saltaansible-lint per il compito.

9. Principio del minimo privilegio

Usa il principio del privilegio minimo. Parametrobecome dovrebbe essereno finché non ne avrai davvero bisogno. Usa semprebecome chiaramente. Per esempio:

---
 - hosts: wordpress
    become: no
     ...
    role:
      - role: wordpress

tasks/main.yml
---
- name: Install mysql-server pkg
  apt:
    name: mysql-server
    state: present
  become: yes

10.Utilizzare la sintassi YAML per i parametri

Usa YAML invece della sintassi in linea. Confronta queste due opzioni:

YAML

- name: Install apache httpd
  apt:
    name: apache2
    state: present

Incorporato

- name: Install apache httpd
  apt: pkg=apache2 state=pesent

11. Usa gitignore

Inserisci.gitignore ai tuoi ruoli se memorizzi il codice in un repository git. pianura.gitignore potrebbe assomigliare a questo:

*.retry
*/__pycache__
*.pyc
*.log
### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr

12. Usa i consigli della documentazione di Ansible

Usa le linee guida per organizzare i contenuti dalla pagina ufficiale di ansible  

13. Utilizzare una directory separata per i ruoli della comunità

Usa una directory separata per i ruoli della community, insieme alle linee guida del suggerimento precedente.

14. Testa il tuo codice Ansible

Usa i framework per testare il tuo codice Ansible. Ad esempio, molecola . Questo framework ti consente di testare il tuo codice da diverse angolazioni. Oltre ai test tradizionali, può anche eseguire tutti i tipi di linter e controllare il codice per l'idempotenza.

15. Versionamento dei ruoli

Che cos'è il versioning nel mondo di Ansible? Questo è l'approccio utilizzato da git e ti consente di eseguire diverse versioni di ruoli semplicemente specificando la versione. Una versione può essere un tag, un ramo o un commit specifico. Puoi leggere di più su questo qui . Il tuo compito è personalizzare la procedura in base ai requisiti di controllo delle versioni del tuo ruolo.

requisiti.yaml:

---
- src: git@gitlab.company.com:mygroup/ansible.git
 scm: git
 version: "0.1"
...

Attributi validi:

• src
• sccm
• versione
• nome

La traduzione dell'articolo è stata preparata alla vigilia dell'inizio del corso "DevOps Practices and Tools" .

Invitiamo tutti ad iscriversi ad una lezione demo gratuita del corso sul tema: "Prometeo: avvio rapido" . Durante la lezione, i partecipanti, insieme a un esperto, considereranno l'architettura Prometheus e il suo modo di lavorare con le metriche, oltre ad analizzare come generare avvisi ed eventi nel sistema.