🥇Hoe kinne jo Ansible begjinne te testen, in projekt yn in jier opnij meitsje en net gek wurde

Dit is it transkripsje optredens op DevOps-40 2020-03-18:

Begjin fan 'e twadde commit wurdt elke koade legacy, om't inisjele ideeën begjinne te ôfwike fan hurde realiteit. Dit is net goed noch min, it is in gegeven dêr't it dreech is om te argumintearjen en mei te libjen. In part fan dit proses is refactoring. Refactoring ynfrastruktuer as koade. Lit it ferhaal begjinne oer hoe't jo Ansible oer in jier refaktorearje kinne en net gek wurde.

De berte fan Legacy

Dei #1: Patient Zero

Eartiids wie der in betingst projekt. It hie in Dev-ûntwikkelingsteam en Ops-yngenieurs. Se losten itselde probleem op: hoe kinne jo servers ynsette en in applikaasje útfiere. It probleem wie dat elk team dit probleem op syn eigen manier oploste. By it projekt waard besletten om Ansible te brûken om kennis te syngronisearjen tusken de Dev- en Ops-teams.

Dei # 89: The Birth of Legacy

Sûnder it sels te fernimmen woene se it sa goed mooglik dwaan, mar it die bliken dat it legacy wie. Hoe komt dit?

Wy hawwe hjir in driuwende taak, litte wy in smoarge hack dwaan en it dan reparearje.
Jo hoege gjin dokumintaasje te skriuwen en alles is dúdlik wat hjir bart.
Ik wit Ansible / Python / Bash / Terraform! Sjoch hoe't ik kin ûntwykje!
Ik bin in Full Stack Overflow Untwikkelder en kopiearre dit út stackoverflow, Ik wit net hoe't it wurket, mar it sjocht der cool út en lost it probleem.

As resultaat kinne jo in ûnbegryplik type koade krije wêrfoar't gjin dokumintaasje is, it is net dúdlik wat it docht, oft it nedich is, mar it probleem is dat jo it moatte ûntwikkelje, wizigje, krukken tafoegje en stipet , wêrtroch de situaasje noch slimmer wurdt.

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

Dei # 109: Bewustwêzen fan it probleem

It yn earste ynstânsje betocht en ymplementearre IaC-model foldocht net mear oan 'e easken fan brûkers / bedriuw / oare teams, en de tiid om feroaringen oan 'e ynfrastruktuer te meitsjen hâldt op te akseptabel. Op dit stuit komt it begryp dat it tiid is om aksje te nimmen.

IaC refactoring

Dei # 139: Hawwe jo echt refactoring nedich?

Foardat jo nei refactor haasten, moatte jo in oantal wichtige fragen beantwurdzje:

Wêrom hawwe jo dit alles nedich?
Hasto it oan tiid?
Is kennis genôch?

As jo net witte hoe't jo de fragen moatte beantwurdzje, dan sil de refactoring einigje foardat it sels begjint, of it kin allinich slimmer wurde. Omdat ûnderfining hie ( Wat ik learde fan it testen fan 200 rigels fan ynfrastruktuerkoade), dan krige it projekt in fersyk om help om de rollen te reparearjen en te dekken mei tests.

Dei # 149: Tariede de refactoring

It earste ding is om te meitsjen. Beslute wat wy sille dwaan. Om dit te dwaan, kommunisearje wy, fine probleemgebieten en sykje manieren om se op te lossen. Wy registrearje de resultearjende begripen op ien of oare manier, bygelyks in artikel yn gearrin, sadat as de fraach opkomt "wat is it bêste?" of "wat is goed?" Wy binne de wei net ferlern. Yn ús gefal hâlde wy fêst oan it idee ferdiele en hearskje: wy brekke de ynfrastruktuer op yn lytse stikken/stiennen. Dizze oanpak lit jo in isolearre stik ynfrastruktuer nimme, begripe wat it docht, it mei tests dekke en it feroarje sûnder eangst om wat te brekken.

It docht bliken dat testen fan ynfrastruktuer de hoekstien wurdt en hjir is it de muoite wurdich om de piramide foar testen fan ynfrastruktuer te neamen. Krekt itselde idee dat yn ûntwikkeling is, mar foar ynfrastruktuer: wy geane fan goedkeape fluchtests dy't ienfâldige dingen kontrolearje, lykas ynspringen, nei djoere folweardige tests dy't de hiele ynfrastruktuer ynsette.

Unsible testpogingen

Foardat wy geane om te beskriuwen hoe't wy Ansible-tests oer it projekt behannele hawwe, sil ik de besykjen en oanpak beskriuwe dy't ik earder de kâns hie om te brûken om de kontekst fan 'e makke besluten te begripen.

Dei No.. -997: SDS foarsjenning

De earste kear dat ik Ansible testen wie op in projekt om SDS (Software Defined Storage) te ûntwikkeljen. D'r is in apart artikel oer dit ûnderwerp
Hoe kinne jo fytsen brekke oer krukken by it testen fan jo distribúsje, mar koartsein, wy bedarre mei in omkearde testing piramide en testen wy trochbrocht 60-90 minuten op ien rol, dat is in lange tiid. De basis wie e2e tests, d.w.s. wy hawwe in folsleine ynstallaasje ynset en dêrnei testen. Wat noch slimmer wie, wie de útfining fan syn eigen fyts. Mar ik moat tajaan, dizze oplossing wurke en tastien foar in stabile release.

Dei # -701: Ansible en test keuken

De ûntwikkeling fan it Ansible-testidee wie it brûken fan klearmakke ark, nammentlik testkeuken/keuken-ci en inspec. De kar waard bepaald troch kennis fan Ruby (foar mear details, sjoch it artikel oer Habré: Dreame YML-programmeurs fan it testen fan Ansible?) wurke flugger, sawat 40 minuten foar 10 rollen. Wy hawwe in pakket mei firtuele masines makke en testen binnen útfierd.

Yn it algemien wurke de oplossing, mar der wie wat sedimint troch heterogeniteit. Doe't it oantal testte minsken waard ferhege nei 13 basisrollen en 2 meta-rollen dy't lytsere rollen kombinearje, dan begûnen de tests ynienen 70 minuten te rinnen, dat is hast 2 kear langer. It wie lestich om te praten oer XP (ekstreme programmearring) praktiken, om't ... gjinien wol wachtsje 70 minuten. Dit wie de reden om de oanpak te feroarjen

Dei # -601: Ansible en molekule

Konseptueel is dit gelyk oan testkitchen, allinich hawwe wy roltesten ferpleatst nei docker en de stapel feroare. As gefolch, de tiid waard werombrocht ta in stabile 20-25 minuten foar 7 rollen.

Troch it oantal testen rollen te ferheegjen nei 17 en 45 rollen te linten, rûnen wy dit yn 28 minuten op 2 jenkinsslaven.

Dei # 167: Ansible tests tafoegje oan it projekt

Meast wierskynlik sil it net mooglik wêze om de refactoring-taak yn 'e haast te dwaan. De taak moat mjitber wêze, sadat jo it yn lytse stikken brekke kinne en de oaljefant stik foar stik mei in teeleppel ite. D'r moat in begryp wêze fan oft jo yn 'e goede rjochting bewege, hoe lang te gean.

Yn 't algemien makket it net út hoe't it dien wurde sil, jo kinne op in stikje papier skriuwe, jo kinne stickers op 'e kast sette, jo kinne taken meitsje yn Jira, of jo kinne Google Docs iepenje en de hjoeddeistige status opskriuwe dêr. De skonken groeie út it feit dat it proses net direkt is, it sil lang en ferfeelsum wêze. It is net wierskynlik dat immen wol dat jo ideeën útbaarne, wurch wurde en oerweldige wurde by refactoring.

De refactoring is ienfâldich:

Ite.
Sliep.
Koade.
IaC test.
repeat

en wy werhelje dit oant wy berikke it beëage doel.

It is miskien net mooglik om alles fuort te testen, dus ús earste taak wie om te begjinnen mei linting en kontrolearje de syntaksis.

Dei # 181: Green Build Master

Linting is in lytse earste stap nei Green Build Master. Dit sil hast neat brekke, mar it sil jo tastean om prosessen te debuggen en griene builds te meitsjen yn Jenkins. It idee is om gewoanten te ûntwikkeljen ûnder it team:

Reade testen binne min.
Ik kaam om wat te reparearjen en tagelyk de koade wat better te meitsjen as foar jo.

Dei #193: Fan linting oant ienheidstests

Nei't jo it proses hawwe boud om de koade yn 'e master te krijen, kinne jo it proses fan stap-foar-stap ferbettering begjinne - linting ferfange troch lansearjende rollen, jo kinne it sels dwaan sûnder idempotens. Jo moatte begripe hoe't jo rollen tapasse en hoe't se wurkje.

Dei # 211: Fan ienheid oant yntegraasjetests

As de measte rollen binne bedekt mei ienheidstests en alles is lint, kinne jo trochgean mei it tafoegjen fan yntegraasjetests. Dy. testen net ien bakstien yn de ynfrastruktuer, mar in kombinaasje fan harren, bygelyks, in folsleine eksimplaar konfiguraasje.

Mei jenkins hawwe wy in protte stadia generearre dy't rollen / playbooks parallele linten, dan ienheidstests yn konteners, en úteinlik yntegraasjetests.

Jenkins + Docker + Ansible = Tests

Checkout repo en generearje boustadia.
Run lint playbook stadia parallel.
Run lint rol stadia parallel.
Run syntaksis kontrôle rol stadia parallel.
Run test rol stadia parallel.
1. Lint rol.
2. Kontrolearje ôfhinklikens fan oare rollen.
3. Kontrolearje syntaksis.
4. Meitsje docker-eksimplaar
5. Run molecule/default/playbook.yml.
6. Kontrolearje idempotinsje.
Run yntegraasje tests
Ein

Dei # 271: Bus Factor

Yn earste ynstânsje waard refactoring útfierd troch in lytse groep fan twa of trije minsken. Se beoardiele de koade yn 'e master. Yn 'e rin fan' e tiid ûntwikkele it team kennis oer hoe't jo koade skriuwe en koadebeoardieling bydroegen oan 'e fersprieding fan kennis oer de ynfrastruktuer en hoe't it wurket. It hichtepunt hjir wie dat de resinsinten ien foar ien selektearre waarden, neffens in skema, d.w.s. mei wat graad fan kâns silst klimme yn in nij stik ynfrastruktuer.

En it moat hjir noflik wêze. It is handich om in resinsje te dwaan, te sjen yn it ramt fan hokker taak it dien is en de skiednis fan diskusjes. Wy hawwe yntegrearre jenkins + bitbucket + jira.

Mar as sadanich is in resinsje gjin panacee; op ien of oare manier kamen wy yn 'e masterkoade, dy't ús floptesten makke:

- 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 }}"

Doe makken se it fêst, mar it sedimint bleau.

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 }}"

Dei # 311: Testen fersnelle

Yn 'e rin fan' e tiid wiene d'r mear testen, builds rûnen stadiger, oant in oere yn it slimste gefal. Op ien fan 'e retro's wie d'r in sin lykas "it is goed dat d'r tests binne, mar se binne stadich." As gefolch hawwe wy yntegraasjetests op firtuele masines ferlitten en se oanpast foar Docker om it rapper te meitsjen. Wy hawwe ek ferfongen testinfra mei ansible verifier te ferminderjen it oantal ark brûkt.

Strikt sjoen wie d'r in set fan maatregels:

Wikselje nei docker.
Ferwiderje roltesten, dy't duplikearre wurdt fanwegen ôfhinklikens.
Fergrutsje it oantal slaven.
Test run folchoarder.
Mooglikheid om lint ALLE lokaal mei ien kommando.

As gefolch, Pipeline op jenkins waard ek ferienige

Generearje boustadia.
Lint alles parallel.
Run test rol stadia parallel.
Ein.

Lessen leard

Avoid globale fariabelen

Ansible brûkt globale fariabelen, d'r is in foar in part workaround yn 'e foarm private_role_vars, mar dit is gjin wondermiddel.

Lit my dy in foarbyld jaan. Lit ús hawwe 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}}

It grappige is dat it resultaat fan toanielboeken ôfhingje sil fan dingen dy't net altyd fanselssprekkend binne, lykas de folchoarder wêryn't rollen steane. Spitigernôch, dit is de aard fan Ansible en it bêste dat kin dien wurde is in gebrûk wat soarte fan oerienkomst, Bygelyks, binnen in rol, brûk allinnich de fariabele beskreaun yn dizze rol.

BAD: brûke globale fariabele.

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

GOED: V defaults definiearje de nedige fariabelen en letter brûke se allinnich.

# 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

Prefix rol fariabelen

BAD: brûke globale fariabele.

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

GOED: Brûk yn rollen foar fariabelen fariabelen foarôfgeand mei de rolnamme; dit, troch nei ynventarisaasje te sjen, sil it makliker meitsje om te begripen wat der bart.

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

Brûk loop control fariabele

BAD: Brûk standert fariabele yn loops item, as dizze taak / playbook is opnommen earne, dit kin liede ta ûnferwacht gedrach

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

GOED: Redefiniearje in fariabele yn in loop fia loop_var.

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

Kontrolearje ynfierfariabelen

Wy hawwe ôfpraat om fariabele foarheaksels te brûken; it soe net oerstallich wêze om te kontrolearjen dat se definieare binne lykas wy ferwachtsje en, bygelyks, net oerskreaun binne troch in lege wearde

GOED: Kontrolearje fariabelen.

- 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

Avoid hashes wurdboeken, brûk platte struktuer

As in rol in hash/wurdboek ferwachtet yn ien fan syn parameters, dan as wy ien fan 'e bernparameters wizigje wolle, moatte wy de hiele hash/wurdboek oerskriuwe, wat de konfiguraasjekompleksiteit sil tanimme.

BAD: Brûk hash/wurdboek.

---
user:
  name: admin
  group: admin

GOED: Brûk in platte fariabele struktuer.

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

Meitsje idempotinte playbooks en rollen

Rollen en playbooks moatte idempotent, omdat ferminderet konfiguraasje drift en eangst foar brekken wat. Mar as jo molekule brûke, dan is dit it standertgedrach.

Mije it brûken fan kommando shell modules

It brûken fan in shell-module resulteart yn in ymperatyf beskriuwingsparadigma, ynstee fan it deklarative, dat de kearn is fan Ansible.

Test jo rollen fia molekule

Molecule is in heul fleksibel ding, litte wy nei in pear senario's sjen.

Molecule Meardere eksimplaren

В molecule.yml yn seksje platforms jo kinne in protte hosts beskriuwe dy't jo kinne ynsette.

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

Dêrtroch kinne dizze hosts dan wêze converge.yml brûke:

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

Ansible ferifiearder

Yn molecule is it mooglik om ansible te brûken om te kontrolearjen dat it eksimplaar goed is konfigureare, boppedat is dit de standert sûnt release 3. It is net sa fleksibel as testinfra/inspec, mar wy kinne kontrolearje dat de ynhâld fan it bestân oerienkomt mei ús ferwachtingen:

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

Of set de tsjinst yn, wachtsje oant it beskikber komt en doch in reektest:

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

Set komplekse logika yn modules en plugins

Ansible pleitet foar in deklarative oanpak, dus as jo koadefertakking, gegevenstransformaasje, shellmodules dogge, wurdt de koade lestich te lêzen. Om dit te bestriden en it ienfâldich te begripen te hâlden, soe it net oerstallich wêze om dizze kompleksiteit te bestriden troch jo eigen modules te meitsjen.

Gearfetsje Tips & Tricks

Avoid globale fariabelen.
Prefix rol fariabelen.
Brûk loop control fariabele.
Kontrolearje ynfierfariabelen.
Avoid hashes wurdboeken, brûk platte struktuer.
Meitsje idempotinte playbooks en rollen.
Mije it brûken fan kommando shell modules.
Test jo rollen fia molekule.
Set komplekse logika yn modules en plugins.

konklúzje

Jo kinne net gewoan gean en refaktorearje de ynfrastruktuer op in projekt, sels as jo IaC. Dit is in lang proses dat geduld, tiid en kennis fereasket.

Links

UPD1 2020.05.01 20:30 - Foar primêre profilearring fan playbooks kinne jo brûke callback_whitelist = profile_tasks om te begripen wat krekt wurket foar in lange tiid. Dan geane wy troch Ansible fersnelling klassikers. Jo kinne ek besykje mitogen
UPD2 2020.05.03 16:34 - Ingelske ferzje

Boarne: www.habr.com

Hoe kinne jo Ansible begjinne te testen, refaktorearje it projekt yn in jier en gean net gek