🥇Cumu principià à pruvà Ansible, refactor un prughjettu in un annu è micca impazzisce

Questu hè a trascrizione spettaculi nantu DevOps-40 2020-03-18:

Partendu da a seconda cummissione, ogni codice diventa legatu, perchè l'idee iniziali cumincianu à diverghje da a dura realità. Questu ùn hè nè bè nè male, hè un datu chì hè difficiule di discutiri è deve esse campatu. Parte di stu prucessu hè refactoring. Refactoring Infrastruttura cum'è Codice. Chì a storia principia nantu à cumu refactor Ansible in un annu è micca impazzisce.

A nascita di l'eredità

Ghjornu #1: Patient Zero

Una volta ci era un prughjettu cundizionale. Hà avutu una squadra di sviluppu di Dev è ingegneri Ops. Anu risolviu u listessu prublema: cumu implementà i servitori è eseguite una applicazione. U prublema era chì ogni squadra risolve stu prublema in u so modu. À u prugettu, hè statu decisu di utilizà Ansible per sincronizà a cunniscenza trà e squadre Dev è Ops.

Ghjornu #89: A nascita di l'eredità

Senza avè nutatu elli stessi, vulianu fà u megliu pussibule, ma s'hè risultatu in eredità. Cumu succede questu?

Avemu un compitu urgente quì, facemu un pirate bruttu è poi riparà.
Ùn avete micca à scrive documentazione è tuttu hè chjaru ciò chì passa quì.
So Ansible/Python/Bash/Terraform! Fighjate cumu possu esquivà !
Sò un Sviluppatore Full Stack Overflow è copiatu questu da stackoverflow, ùn sò micca sapè cumu funziona, ma pare bellu è risolve u prublema.

In u risultatu, pudete ottene un tipu incomprensibile di codice per quale ùn ci hè micca documentazione, ùn hè micca chjaru ciò chì faci, s'ellu hè necessariu, ma u prublema hè chì avete bisognu di sviluppà, mudificà, aghjunghje crutches è supporti. , facendu a situazione ancu peghju.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Ghjornu #109: Cuscenza di u prublema

U mudellu IaC inizialmente cuncipitu è implementatu ùn risponde più à i requisiti di l'utilizatori / imprese / altre squadre, è u tempu per fà cambiamenti à l'infrastruttura cessà di esse accettabile. A stu mumentu, a capiscitura vene chì hè ora di piglià l'azzioni.

Refactoring IaC

Ghjornu #139: Avete veramente bisognu di refactoring?

Prima di affruntà à refactor, duvete risponde à parechje dumande impurtanti:

Perchè avete bisognu di tuttu questu?
Avete tempu ?
A cunniscenza hè abbastanza?

Se ùn sapete micca risponde à e dumande, u refactoring finisce prima ancu di principià, o pò esse solu peghju. Perchè avia sperienza ( Ciò chì aghju amparatu da a prova di 200 000 Linee di Codice Infrastruttura), allura u prughjettu hà ricevutu una dumanda d'aiutu per riparà i roli è copre cù testi.

Ghjornu #149: Preparazione di u refactoring

A prima cosa hè di preparà. Decide ciò chì faremu. Per fà questu, cumunicemu, truvamu e spazii prublemi è scopre modi per risolve. Ricordemu i cuncetti resultanti d'una certa manera, per esempiu un articulu in cunfluenza, cusì chì quandu a quistione sorge "chì hè megliu?" o "quale hè currettu?" Ùn avemu micca persu u nostru modu. In u nostru casu, avemu attaccatu à l'idea divide è guverna: fraccionemu l'infrastruttura in picculi pezzi / mattoni. Stu approcciu permette di piglià un pezzu isolatu di infrastruttura, capisce ciò chì face, copre cù testi è cambià senza teme di rompe nunda.

Risulta chì a prova di l'infrastruttura diventa a basa è quì vale a pena menzionate a piramide di prova di l'infrastruttura. Esattamente a listessa idea chì hè in sviluppu, ma per l'infrastruttura: passemu da teste veloci à pocu pressu chì verificanu e cose simplici, cum'è l'indentazione, à teste cumpletu caru chì implementanu tutta l'infrastruttura.

Tentativi di teste Ansible

Prima di andà à discrìviri comu avemu cupertu Ansible testi nant'à u prugettu, vi discrìviri i tentativi è avvicinamenti ch'e aghju avutu l'uppurtunità di utilizà prima per capisce u cuntestu di e decisioni prese.

Ghjornu N ° -997: SDS provision

A prima volta chì aghju pruvatu Ansible era nantu à un prughjettu di sviluppà SDS (Software Defined Storage). Ci hè un articulu separatu nantu à questu tema
Cumu rompe e biciclette sopra crutches quandu pruvate a vostra distribuzione, Ma in corta, avemu finitu cù una piramide di teste invertita è a prova avemu passatu 60-90 minuti nantu à un rolu, chì hè assai tempu. A basa era e teste e2e, i.e. avemu implementatu una installazione cumpleta è poi pruvata. Ciò chì era ancu più aggravante era l'invenzione di a so propria bicicletta. Ma devu ammette chì sta suluzione hà travagliatu è hà permessu una liberazione stabile.

Ghjornu # -701: Cucina Ansible è prova

U sviluppu di l'idea di teste Ansible hè stata l'usu di strumenti pronti, vale à dì test kitchen / kitchen-ci è inspec. A scelta hè stata determinata da a cunniscenza di Ruby (per più dettagli, vede l'articulu di Habré: I programatori YML sognu di pruvà Ansible?) hà travagliatu più veloce, circa 40 minuti per 10 roli. Avemu creatu un pacchettu di macchine virtuali è eseguimu testi in l'internu.

In generale, a suluzione hà travagliatu, ma ci era qualchì sedimentu per l'eterogeneità. Quandu u numeru di persone testate hè stata aumentata à 13 roli basi è 2 meta roles chì combinanu roli più chjuchi, allora di colpu i testi cuminciaru à curriri per 70 minuti, chì hè quasi 2 volte più longu. Era difficiuli di parlà di pratiche XP (programmazione estrema) perchè ... nimu ùn vole aspittà 70 minuti. Questu era u mutivu di cambià l'approcciu

Ghjornu # -601: Ansible è molécula

Conceptually, questu hè simile à testkitchen, solu avemu spustatu a prova di rolu in docker è cambiatu a pila. In u risultatu, u tempu hè stata ridutta à una stabile 20-25 minuti per 7 roli.

Aumentendu u nùmeru di roli pruvati à 17 è linting 45 roles, avemu eseguitu questu in 28 minuti nantu à 2 schiavi jenkins.

Day #167: Aghjunghjenu testi Ansible à u prugettu

Hè assai prubabile, ùn serà micca pussibule di fà u compitu di refactoring in fretta. U compitu deve esse misurabile in modu chì pudete rompe in pezzi chjuchi è manghjà l'elefante pezzu per pezzu cù una cucchiara. Ci deve esse una cunniscenza di s'ellu si move in a direzzione ghjusta, quantu longu andà.

In generale, ùn importa micca cumu si farà, pudete scrive nantu à un pezzu di carta, pudete mette stickers nantu à l'armadiu, pudete creà compiti in Jira, o pudete apre Google Docs è scrive u statu attuale. culà. I gammi crescenu da u fattu chì u prucessu ùn hè micca immediata, serà longu è tedious. Hè improbabile chì qualcunu vole chì voi brusgià l'idee, stancu, è diventate sopraffattu durante a refactoring.

U refactoring hè simplice:

Manghjate.
Sleep.
Codice.
Test IaC.
Repetite

è ripetemu questu finu à ghjunghje à u scopu previstu.

Pò esse micca pussibule di cumincià à pruvà tuttu immediatamente, cusì u nostru primu compitu era di principià cù linting è cuntrollà a sintassi.

Ghjornu #181: Maestru di custruzzione verde

Linting hè un picculu primu passu versu Green Build Master. Questu ùn romperà quasi nunda, ma vi permetterà di debug processi è fà custruzzioni verdi in Jenkins. L'idea hè di sviluppà abitudini trà a squadra:

I testi rossi sò cattivi.
Sò ghjuntu à riparà qualcosa è à u stessu tempu fà u codice un pocu megliu cà prima di voi.

Ghjornu # 193: Da u linting à e teste di unità

Dopu avè custruitu u prucessu di ottene u codice in u maestru, pudete inizià u prucessu di migliione passu à passu - rimpiazzà linting cù roli di lanciamentu, pudete ancu fà senza idempotenza. Avete bisognu di capiscenu cumu applicà i roli è cumu travaglianu.

Ghjornu #211: Da unità à teste di integrazione

Quandu a maiò parte di i roli sò cuparti cù teste di unità è tuttu hè linatu, pudete passà à aghjunghje testi di integrazione. Quelli. Prova micca un solu brick in l'infrastruttura, ma una cumminazione di elli, per esempiu, una cunfigurazione di istanza cumpleta.

Aduprendu jenkins, avemu generatu parechje tappe chì linted roles / playbooks in parallelu, dopu teste unità in cuntenituri, è infine testi di integrazione.

Jenkins + Docker + Ansible = Testi

Checkout repo è generà fasi di creazione.
Eseguite lint playbook stages in parallelu.
Eseguite tappe di rolu di lint in parallelu.
Eseguite tappe di rolu di verificazione di sintassi in parallelu.
Eseguite tappe di rolu di teste in parallelu.
1. U rolu di lint.
2. Verificate a dipendenza da altri roles.
3. Verificate a sintassi.
4. Crea l'istanza di docker
5. Eseguite molecule/default/playbook.yml.
6. Verificate l'idempotenza.
Eseguite testi di integrazione
Finisci

Ghjornu #271: Bus Factor

À u principiu, a refactoring hè stata realizata da un gruppu di dui o trè persone. Hanu rivisatu u codice in u maestru. À u tempu, a squadra hà sviluppatu a cunniscenza di cumu scrive u codice è a rivista di codice cuntribuitu à a diffusione di a cunniscenza nantu à l'infrastruttura è cumu si travaglia. U puntu culminante quì hè chì i critichi sò stati scelti unu per unu, secondu un calendariu, i.e. cù un certu gradu di probabilità vi cullà in un novu pezzu di infrastruttura.

È duverebbe esse còmode quì. Hè cunvenutu per fà una rivista, vede in u quadru di quale compitu hè statu fattu, è a storia di discussioni. Avemu integratu jenkins + bitbucket + jira.

Ma cum'è tali, una rivista ùn hè micca una panacea; in qualchì modu, avemu ghjuntu in u codice maestru, chì ci hà fattu teste flop:

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

Allora l'arraggianu, ma u sedimentu ferma.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

Ghjornu #311: Accelerazione di e teste

À u tempu, ci sò stati più teste, e custruzzioni scorri più lentamente, finu à una ora in u peghju casu. In unu di i retros ci era una frasa cum'è "hè bè chì ci sò testi, ma sò lenti". In u risultatu, avemu abbandunatu e teste d'integrazione nantu à e macchine virtuali è l'adattamu per Docker per fà più veloce. Avemu ancu rimpiazzatu testinfra cun verificatore ansible per riduce u numeru di arnesi utilizati.

In modu strettu, ci era una serie di misure:

Cambia à docker.
Eliminate a prova di rolu, chì hè duplicata per via di dipendenze.
Aumentà u numeru di schiavi.
Ordine di corsa di prova.
Capacità di lint TUTTI lucale cù un cumandamentu.

In u risultatu, Pipeline on jenkins hè statu ancu unificatu

Genera tappe di custruzzione.
Lint tuttu in parallelu.
Eseguite tappe di rolu di teste in parallelu.
Finish.

Studii nfurmazioni

Evite variabili globali

Ansible usa variabili globale, ci hè una soluzione parziale in a forma private_role_vars, ma questu ùn hè micca una panacea.

Lasciami dà un esempiu. Lasciamu avè role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

A cosa divertente hè chì u risultatu di i playbooks dependerà di e cose chì ùn sò micca sempre evidenti, cum'è l'ordine in quale i roli sò listati. Sfurtunatamente, questu hè a natura di Ansible è u megliu chì pò esse fattu hè di utilizà un tipu d'accordu, per esempiu, in un rolu, utilizate solu a variàbile descritta in questu rolu.

Bad: aduprà a variabile globale.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

BENE: V defaults definisce e variàbili necessarii è dopu aduprà solu.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

Prefissu variabili di rolu

Bad: aduprà a variabile globale.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

BENE: In roli per variàbili, aduprate variabili prefissati cù u nome di u rolu; questu, fighjendu l'inventariu, farà più faciule per capisce ciò chì succede.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

Utilizà a variabile di cuntrollu di loop

Bad: Utilizà a variabile standard in i loops item, Se questu compitu / playbook hè inclusu in qualchì locu, questu pò purtà à un cumpurtamentu inesperu

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

BENE: Ridefinisce una variabile in un ciclu via loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

Verificate e variabili di input

Avemu accunsentutu d'utilizà prefissi variabili ; ùn saria superfluu di verificà chì sò definiti cum'è l'aspittavamu è, per esempiu, ùn sò micca stati rimpiazzati da un valore viotu.

BENE: Verificate e variabili.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

Evite dizziunari hashes, aduprà struttura flat

Se un rolu aspetta un hash / dizziunariu in unu di i so paràmetri, allora se vulemu cambià unu di i paràmetri di u zitellu, avemu bisognu di annullà tuttu u hash / dizziunariu, chì aumenterà a cumplessità di cunfigurazione.

Bad: Aduprà hash / dizziunariu.

---
user:
  name: admin
  group: admin

BENE: Aduprate una struttura variabile piatta.

---
user_name: admin
user_group: "{{ user_name }}"

Crea playbooks è roli idempotenti

Roles è playbooks deve esse idempotent, perchè riduce a deriva di cunfigurazione è a paura di rompe qualcosa. Ma s'è vo aduprate a molécula, allora questu hè u cumpurtamentu predeterminatu.

Evite aduprà moduli di shell di cumanda

Utilizà un modulu di cunchiglia risultati in un paradigma di descrizzione imperativu, invece di quellu dichjarativu, chì hè u core di Ansible.

Pruvate i vostri roli via molecule

Molecule hè una cosa assai flexible, fighjemu uni pochi di scenarii.

Molecule Casi multipli

В molecule.yml in rùbbrica platforms pudete discrive assai ospiti chì pudete implementà.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

In cunsiquenza, questi ospiti ponu esse converge.yml usu:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

verificatore Ansible

In a molecule hè pussibule aduprà ansible per verificà chì l'istanza hè stata cunfigurata currettamente, in più, questu hè statu u predefinitu da a versione 3. Ùn hè micca cusì flexible cum'è testinfra/inspec, ma pudemu verificà chì u cuntenutu di u schedariu currisponde à e nostre aspettative:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

O implementate u serviziu, aspettate ch'ellu sia dispunibule è fate una prova di fumu:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

Mettite una logica cumplessa in moduli è plugins

Ansible favurisce un approcciu dichjarazione, cusì quandu fate ramificazione di codice, trasfurmazioni di dati, moduli di cunchiglia, u codice diventa difficiule di leghje. Per cumbatte questu è mantene a simplicità di capiscenu, ùn saria micca superfluu per cumbatte sta cumplessità creendu i vostri moduli.

Riassume Cunsiglii è Trucchi

Evite variabili globali.
Prefissu variabili di rolu.
Utilizà a variabile di cuntrollu di loop.
Verificate e variabili di input.
Evite dizziunari hashes, aduprà struttura flat.
Crea playbooks è roli idempotenti.
Evite aduprà moduli di shell di cumanda.
Pruvate i vostri roli via molecule.
Mettite una logica cumplessa in moduli è plugins.

cunchiusioni

Ùn pudete micca solu andà è refactor l'infrastruttura nantu à un prughjettu, ancu s'ellu avete IaC. Questu hè un prucessu longu chì richiede pacienza, tempu è cunniscenze.

Links

UPD1 2020.05.01 20:30 - Per prufilu primariu di playbooks pudete aduprà callback_whitelist = profile_tasks per capisce ciò chì funziona esattamente per un bellu pezzu. Allora andemu à traversu I classici di accelerazione Ansible. Pudete ancu pruvà mitogenu
UPD2 2020.05.03 16:34 - versione francese

Source: www.habr.com

Cumu cumincià à pruvà Ansible, refactor u prughjettu in un annu è ùn andate micca pazzi