ProHoster > Blogs > Administrācija > Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Å is ir atÅ”ifrējums izrādes par DevOps-40, 2020:

Sākot ar otro apņemÅ”anos, jebkurÅ” kods kļūst mantots, jo sākotnējās idejas sāk atŔķirties no skarbās realitātes. Tas nav ne labi, ne slikti, tas ir dots, ar kuru grÅ«ti strÄ«dēties un ar ko ir jāsadzÄ«vo. Daļa no Ŕī procesa ir pārstrukturÄ“Å”ana. InfrastruktÅ«ras pārstrukturÄ“Å”ana kā kods. Sāksim stāstu par to, kā gada laikā pārveidot Ansible un nekļūt traks.

Mantojuma dzimŔana

1. diena: paciente nulle

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Reiz bija nosacÄ«ts projekts. Tajā bija Dev izstrādes komanda un Ops inženieri. Viņi atrisināja to paÅ”u problēmu: kā izvietot serverus un palaist lietojumprogrammu. Problēma bija tā, ka katra komanda Å”o problēmu atrisināja savā veidā. Projektā tika nolemts izmantot Ansible, lai sinhronizētu zināŔanas starp Dev un Ops komandām.

89. diena: mantojuma dzimŔana

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

PaÅ”iem to nemanot, gribējās to izdarÄ«t pēc iespējas labāk, taču tas izrādÄ«jās mantojums. Kā tas notiek?

  • Mums Å”eit ir steidzams uzdevums, veiksim netÄ«ro uzlauÅ”anu un pēc tam to izlabosim.
  • Jums nav jāraksta dokumentācija, un viss ir skaidrs, kas Å”eit notiek.
  • Es zinu Ansible/Python/Bash/Terraform! Paskaties, kā es varu izvairÄ«ties!
  • Es esmu Full Stack Overflow Developer un nokopēju Å”o no stackoverflow. Es nezinu, kā tas darbojas, bet tas izskatās lieliski un atrisina problēmu.

Rezultātā var iegūt nesaprotamu koda veidu, kuram nav dokumentācijas, nav skaidrs, ko tas dara, vai tas ir vajadzīgs, bet problēma ir tā, ka jums tas ir jāizstrādā, jāpārveido, jāpievieno kruķi un balsti , padarot situāciju vēl sliktāku.

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

109. diena: problēmas apzināŔanās

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Sākotnēji iecerētais un ieviestais IaC modelis vairs neatbilst lietotāju/biznesa/citu komandu prasÄ«bām, un laiks izmaiņu veikÅ”anai infrastruktÅ«rā vairs nav pieņemams. Å ajā brÄ«dÄ« rodas izpratne, ka ir pienācis laiks rÄ«koties.

IaC pārstrukturÄ“Å”ana

139. diena: vai jums tieŔām ir nepiecieÅ”ama pārstrukturÄ“Å”ana?

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Pirms steidzaties uz refraktoru, jums ir jāatbild uz vairākiem svarīgiem jautājumiem:

  1. Kāpēc jums tas viss ir vajadzīgs?
  2. Vai tev ir laiks?
  3. Vai pietiek ar zināŔanām?

Ja jÅ«s nezināt, kā atbildēt uz jautājumiem, tad pārstrukturÄ“Å”ana beigsies, pirms tā pat sāksies, vai arÄ« tā var tikai pasliktināties. Jo bija pieredze ( Ko es uzzināju, pārbaudot 200 000 infrastruktÅ«ras koda lÄ«niju), tad projektā tika saņemts lÅ«gums pēc palÄ«dzÄ«bas, lai salabotu lomas un pārklātu tās ar testiem.

149. diena: Refaktoringa sagatavoŔana

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Pirmā lieta ir sagatavoties. Izlemiet, ko mēs darÄ«sim. Lai to izdarÄ«tu, mēs sazināmies, atrodam problēmzonas un izdomājam veidus, kā tās atrisināt. Mēs kaut kā ierakstām iegÅ«tos jēdzienus, piemēram, rakstu saplÅ«stot, lai tad, kad rodas jautājums "kas ir labākais?" vai "kas ir pareizi?" Mēs neesam apmaldÄ«juÅ”ies. MÅ«su gadÄ«jumā mēs palikām pie idejas sadali un valdi: mēs sadalām infrastruktÅ«ru mazos gabaliņos/Ä·ieÄ£eļos. Å Ä« pieeja ļauj paņemt izolētu infrastruktÅ«ras gabalu, saprast, ko tā dara, pārklāt to ar testiem un mainÄ«t to, nebaidoties kaut ko salauzt.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Izrādās, infrastruktÅ«ras testÄ“Å”ana kļūst par stÅ«rakmeni un Å”eit ir vērts pieminēt infrastruktÅ«ras testÄ“Å”anas piramÄ«du. TieÅ”i tāda pati ideja, kas ir izstrādes stadijā, bet infrastruktÅ«rai: mēs pārejam no lētiem ātrajiem testiem, kas pārbauda vienkārÅ”as lietas, piemēram, ievilkumus, uz dārgiem pilnvērtÄ«giem testiem, kas izvieto visu infrastruktÅ«ru.

Iespējamie testÄ“Å”anas mēģinājumi

Pirms mēs turpinām aprakstÄ«t, kā mēs aptvērām Ansible testus projektā, es aprakstÄ«Å”u mēģinājumus un pieejas, kuras man bija iespēja izmantot agrāk, lai izprastu pieņemto lēmumu kontekstu.

Diena Nr.-997: SDS nodroŔināŔana

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Pirmo reizi es testēju Ansible saistÄ«bā ar SDS (Software Defined Storage) izstrādes projektu. Par Å”o tēmu ir atseviŔķs raksts
Kā salauzt velosipēdus ar kruÄ·iem, pārbaudot savu sadalÄ«jumu, bet Ä«si sakot, mēs nonācām pie apgrieztas testÄ“Å”anas piramÄ«das un testÄ“Å”anā vienai lomai pavadÄ«jām 60-90 minÅ«tes, kas ir ilgs laiks. Pamatā bija e2e testi, t.i. mēs izvietojām pilnvērtÄ«gu instalāciju un pēc tam to pārbaudÄ«jām. Vēl sarežģītāk bija viņa paÅ”a velosipēda izgudrojums. Bet jāatzÄ«st, ka Å”is risinājums darbojās un ļāva nodroÅ”ināt stabilu izlaiÅ”anu.

Diena Nr. -701: Izpētes virtuve

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Ansible testÄ“Å”anas idejas izstrāde bija gatavu instrumentu izmantoÅ”ana, proti, testa virtuve / virtuve-ci un inspec. Izvēli noteica zināŔanas par RubÄ«nu (sÄ«kāku informāciju skatiet rakstā par HabrĆ©: Vai YML programmētāji sapņo par Ansible testÄ“Å”anu?) strādāja ātrāk, apmēram 40 minÅ«tes 10 lomām. Mēs izveidojām virtuālo maŔīnu pakotni un veicām testus.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Kopumā risinājums darbojās, taču neviendabÄ«guma dēļ bija daži nosēdumi. Kad pārbaudāmo cilvēku skaits tika palielināts lÄ«dz 13 pamata lomām un 2 meta lomām, apvienojot mazākas lomas, tad pēkŔņi testi sāka darboties 70 minÅ«tes, kas ir gandrÄ«z 2 reizes ilgāk. Bija grÅ«ti runāt par XP (extreme programming) praksi, jo... neviens nevēlas gaidÄ«t 70 minÅ«tes. Tas bija iemesls pieejas maiņai

Diena # -601: Ansible un molekula

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Konceptuāli tas ir lÄ«dzÄ«gs testkitchen, tikai mēs pārcēlām lomu testÄ“Å”anu uz docker un mainÄ«jām steku. Rezultātā laiks tika samazināts lÄ«dz stabilām 20-25 minÅ«tēm 7 lomām.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Palielinot pārbaudÄ«to lomu skaitu lÄ«dz 17 un izveidojot 45 lomas, mēs to paveicām 28 minÅ«tēs 2 Dženkinsa vergiem.

167. diena: Ansible testu pievienoŔana projektam

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Visticamāk, pārstrukturÄ“Å”anas uzdevumu nebÅ«s iespējams veikt steigā. Uzdevumam jābÅ«t izmērāmam, lai to varētu sadalÄ«t mazos gabaliņos un ar tējkaroti pa gabalu apēst ziloni. Ir jābÅ«t izpratnei par to, vai tu virzies pareizajā virzienā, cik ilgi iet.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Vispār ir vienalga, kā tas tiks darÄ«ts, var rakstÄ«t uz lapiņas, uz skapja var uzlÄ«mēt uzlÄ«mes, Jirā var izveidot uzdevumus vai arÄ« atvērt Google dokumentus un pierakstÄ«t paÅ”reizējo statusu tur. Kājas aug no tā, ka process nav tÅ«lÄ«tējs, tas bÅ«s garÅ” un nogurdinoÅ”s. Maz ticams, ka kāds vēlas, lai jÅ«s pārņemtu idejas, nogurtu un kļūtu pārņemts pārstrukturÄ“Å”anas laikā.

RefaktorÄ“Å”ana ir vienkārÅ”a:

  • Ēd.
  • Gulēt.
  • Kods.
  • IaC tests.
  • Atkārtot

un mēs to atkārtojam, līdz sasniedzam paredzēto mērķi.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Iespējams, ka nevar uzreiz sākt visu testēt, tāpēc mÅ«su pirmais uzdevums bija sākt ar ŔķielÄ“Å”anu un sintakses pārbaudi.

181. diena: Green Build Master

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Linting ir neliels pirmais solis ceļā uz Green Build Master. Tas gandrīz neko neizjauks, taču ļaus jums atkļūdot procesus un izveidot zaļās versijas pakalpojumā Jenkins. Ideja ir komandā attīstīt ieradumus:

  • Sarkanie testi ir slikti.
  • Es atnācu kaut ko salabot un tajā paŔā laikā padarÄ«t kodu mazliet labāku nekā tas bija pirms jums.

193. diena: no plÅ«kÅ”anas lÄ«dz vienÄ«bu testiem

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Kad esat izveidojis koda ievadÄ«Å”anas procesu galvenajā versijā, varat sākt pakāpeniskas uzlaboÅ”anas procesu - aizstājot Ŕķiedru ar palaiÅ”anas lomām, jÅ«s pat varat to izdarÄ«t bez idempotences. Jums ir jāsaprot, kā piemērot lomas un kā tās darbojas.

211. diena: no vienÄ«bas lÄ«dz integrācijas testiem

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Kad lielākā daļa lomu ir pārklātas ar vienÄ«bu pārbaudēm un viss ir izkliedēts, varat pāriet uz integrācijas testu pievienoÅ”anu. Tie. pārbaudot nevis vienu Ä·ieÄ£eli infrastruktÅ«rā, bet gan to kombināciju, piemēram, pilnas instances konfigurāciju.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Izmantojot jenkins, mēs ģenerējām daudzus posmus, kuros paralēli tika sadalītas lomas/spēļu grāmatas, tad vienību testi konteineros un visbeidzot integrācijas testi.

Jenkins + Docker + Ansible = testi

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

  1. Pārbaudiet repo un Ä£enerējiet veidoÅ”anas posmus.
  2. Paralēli izpildiet savārstījumu rokasgrāmatas posmus.
  3. Paralēli izpildiet pūkas lomu posmus.
  4. Paralēli palaist sintakses pārbaudes lomu posmus.
  5. Paralēli palaist pārbaudes lomu posmus.
    1. Lint loma.
    2. Pārbaudiet atkarību no citām lomām.
    3. Pārbaudiet sintaksi.
    4. Izveidojiet docker instanci
    5. Palaidiet molecule/default/playbook.yml.
    6. Pārbaudiet idempotenci.
  6. Palaidiet integrācijas testus
  7. apdare

271. diena: Autobusu faktors

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Sākumā pārstrukturÄ“Å”anu veica neliela divu vai trÄ«s cilvēku grupa. Viņi pārskatÄ«ja kodu galvenajā versijā. Laika gaitā komanda attÄ«stÄ«ja zināŔanas par to, kā rakstÄ«t kodu, un koda pārskatÄ«Å”ana veicināja zināŔanu izplatÄ«Å”anu par infrastruktÅ«ru un tās darbÄ«bu. Å eit galvenais bija tas, ka recenzentus atlasÄ«ja pa vienam, pēc grafika, t.i. ar zināmu varbÅ«tÄ«bas pakāpi jÅ«s iekāpsiet jaunā infrastruktÅ«ras daļā.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Un Å”eit vajadzētu bÅ«t ērti. Ir ērti veikt apskatu, redzēt, kāda uzdevuma ietvaros tas tika veikts, un diskusiju vēsturi. Mums ir integrēti jenkins + bitbucket + jira.

Bet kā tāds apskats nav brīnumlīdzeklis; kaut kā mēs nokļuvām galvenajā kodā, kas lika mums veikt flopa testus:

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

Tad viņi to salaboja, bet nogulsnes palika.

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

311. diena: testu paātrināŔana

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Laika gaitā testu bija vairāk, bÅ«ves darbojās lēnāk, sliktākajā gadÄ«jumā lÄ«dz pat stundai. Uz viena no retro bija tāda frāze kā "labi, ka ir testi, bet tie ir lēni." Tā rezultātā mēs atteicāmies no integrācijas testiem virtuālajās maŔīnās un pielāgojām tos Docker, lai padarÄ«tu to ātrāku. Mēs arÄ« aizstājām testinfra ar piemērotu verificētāju, lai samazinātu izmantoto rÄ«ku skaitu.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Stingri sakot, bija pasākumu kopums:

  1. Pārslēdzieties uz doku.
  2. Noņemiet lomu testÄ“Å”anu, kas tiek dublēta atkarÄ«bu dēļ.
  3. Palieliniet vergu skaitu.
  4. Testa darbības secība.
  5. Spēja plūkt ALL lokāli ar vienu komandu.

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Rezultātā tika apvienots arī jenkins Pipeline

  1. Ä¢enerējiet veidoÅ”anas posmus.
  2. Lint visu paralēli.
  3. Paralēli palaist pārbaudes lomu posmus.
  4. Pabeigt.

Gūtās atziņas

Izvairieties no globālajiem mainīgajiem

Ansible izmanto globālos mainīgos, veidlapā ir daļējs risinājums private_role_vars, bet tā nav panaceja.

Ä»aujiet man sniegt jums piemēru. Ä»aujiet mums 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}}

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

SmieklÄ«gi ir tas, ka rotaļu grāmatu rezultāts bÅ«s atkarÄ«gs no lietām, kas ne vienmēr ir acÄ«mredzamas, piemēram, lomu saraksta secÄ«ba. Diemžēl tāda ir Ansible bÅ«tÄ«ba, un labākais, ko var darÄ«t, ir izmantot kaut kādu vienoÅ”anos, piemēram, lomas ietvaros izmantot tikai Å”ajā lomā aprakstÄ«to mainÄ«go.

BAD: izmantojiet globālo mainīgo.

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

LABA: V defaults definēt nepiecieÅ”amos mainÄ«gos un vēlāk izmantot tikai tos.

# 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

Prefiksa lomu mainīgie

BAD: izmantojiet globālo mainīgo.

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

LABA: Mainīgo lomās izmantojiet mainīgos ar prefiksu ar lomas nosaukumu; tādējādi, aplūkojot inventāru, būs vieglāk saprast, kas notiek.

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

Izmantojiet cilpas vadības mainīgo

BAD: izmantojiet standarta mainÄ«go cilpās item, ja Å”is uzdevums/rokasgrāmata ir kaut kur iekļauta, tas var izraisÄ«t neparedzētu rÄ«cÄ«bu

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

LABA: atkārtoti definējiet mainīgo cilpas caur loop_var.

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

Pārbaudiet ievades mainīgos

Mēs vienojāmies izmantot mainÄ«gos prefiksus; nebÅ«tu lieki pārbaudÄ«t, vai tie ir definēti tā, kā mēs sagaidām, un, piemēram, tos nav ignorējusi tukÅ”a vērtÄ«ba

LABA: pārbaudiet mainīgos.

- 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

Izvairieties no jaukŔanas vārdnīcām, izmantojiet plakanu struktūru

Ja loma kādā no tās parametriem sagaida jaucējumu/vārdnīcu, tad, ja vēlamies mainīt kādu no pakārtotajiem parametriem, mums vajadzēs ignorēt visu jaucējkodu/vārdnīcu, kas palielinās konfigurācijas sarežģītību.

BAD: izmantojiet hash/vārdnīcu.

---
user:
  name: admin
  group: admin

LABA: izmantojiet plakanu mainīgo struktūru.

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

Izveidojiet idempotas rotaļu grāmatas un lomas

Lomām un rotaļu grāmatām jābūt idempotentām, jo samazina konfigurācijas novirzi un bailes kaut ko salauzt. Bet, ja izmantojat molekulu, tā ir noklusējuma darbība.

Izvairieties no komandu čaulas moduļu izmantoŔanas

Izmantojot čaulas moduli, tiek iegūta obligāta apraksta paradigma, nevis deklaratīvā paradigma, kas ir Ansible kodols.

Pārbaudiet savas lomas, izmantojot molekulu

Molekula ir ļoti elastīga lieta, apskatīsim dažus scenārijus.

Molekula Vairāki gadījumi

Š’ molecule.yml sadaļā platforms varat aprakstÄ«t daudzus saimniekdatorus, kurus varat izvietot.

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

AttiecÄ«gi Å”ie saimnieki pēc tam var bÅ«t converge.yml izmantot:

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

Iespējamais pārbaudītājs

Molekulā ir iespējams izmantot ansible, lai pārbaudÄ«tu, vai instance ir pareizi konfigurēta, turklāt kopÅ” 3. izlaiduma tas ir bijis noklusējuma iestatÄ«jums. Tas nav tik elastÄ«gs kā testinfra/inspec, taču mēs varam pārbaudÄ«t, vai faila saturs atbilst mÅ«su cerÄ«bām:

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

Vai arī izvietojiet pakalpojumu, pagaidiet, līdz tas kļūs pieejams, un veiciet dūmu pārbaudi:

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

Ievietojiet sarežģītu loģiku moduļos un spraudņos

Ansible atbalsta deklaratÄ«vu pieeju, tāpēc, veicot koda sazaroÅ”anu, datu pārveidoÅ”anu, čaulas moduļus, kods kļūst grÅ«ti lasāms. Lai cÄ«nÄ«tos pret to un padarÄ«tu to viegli saprotamu, nebÅ«tu lieki cÄ«nÄ«ties ar Å”o sarežģītÄ«bu, izveidojot savus moduļus.

Apkopojiet padomus un ieteikumus

  1. Izvairieties no globālajiem mainīgajiem.
  2. Prefiksa lomu mainīgie.
  3. Izmantojiet cilpas vadības mainīgo.
  4. Pārbaudiet ievades mainīgos.
  5. Izvairieties no jaukŔanas vārdnīcām, izmantojiet plakanu struktūru.
  6. Izveidojiet idempotas rotaļu grāmatas un lomas.
  7. Izvairieties no komandu čaulas moduļu izmantoŔanas.
  8. Pārbaudiet savas lomas, izmantojot molekulu.
  9. Ievietojiet sarežģītu loģiku moduļos un spraudņos.

Secinājums

Kā sākt Ansible testÄ“Å”anu, pēc gada pārstrukturējiet projektu un nekļūstiet traki

Jūs nevarat vienkārŔi iet un pārveidot infrastruktūru projektā, pat ja jums ir IaC. Tas ir ilgs process, kas prasa pacietību, laiku un zināŔanas.

UPD1 2020.05.01. 20:30 ā€” Varat izmantot galveno rokasgrāmatu profilÄ“Å”anu callback_whitelist = profile_tasks lai saprastu, kas tieÅ”i darbojas ilgu laiku. Tad ejam cauri Ansible paātrinājuma klasika. Var arÄ« mēģināt mitogēns
UPD2 2020.05.03. 16:34 Sākot no Angielski versija

Avots: www.habr.com

Pievieno komentāru