🥇Nola hasi Ansible probatzen, urtebete barru proiektu bat birfaktorizatu eta ez erotu

Hau da transkripzioa emanaldiak on DevOps-40 2020-03-18:

Bigarren konpromisotik hasita, edozein kode ondare bihurtzen da, zeren hasierako ideiak errealitate gogorretik aldentzen hasten dira. Hau ez da ez ona ez txarra, eztabaidatzea zaila den eta bizi behar den emandako datu bat da. Prozesu honen zati bat birfaktorizazioa da. Azpiegitura birfactoring Kode gisa. Has dadila urtebetean Ansible nola birfaktorizatu eta ez erotu.

Legatuaren jaiotza

1. eguna: Paziente Zero

Bazen behin baldintzapeko proiektu bat. Dev garapen taldea eta Ops ingeniariak zituen. Arazo bera konpontzen ari ziren: zerbitzariak nola zabaldu eta aplikazio bat exekutatu. Arazoa zen talde bakoitzak arazo hori bere erara konpontzen zuela. Proiektuan, Ansible erabiltzea erabaki zen Dev eta Ops taldeen arteko ezagutza sinkronizatzeko.

89. eguna: Legacyren jaiotza

Beraiek ohartu gabe, ahalik eta ondoen egin nahi izan dute, baina ondarea izan da. Nola gertatzen da hau?

Presazko zeregin bat dugu hemen, egin dezagun hack zikina eta gero konpondu.
Ez duzu dokumentaziorik idatzi behar eta dena argi dago hemen zer gertatzen den.
Ansible/Python/Bash/Terraform ezagutzen dut! Begira nola saihestu dezakedan!
Full Stack Overflow garatzailea naiz eta stackoverflow-etik kopiatu dut, ez dakit nola funtzionatzen duen, baina itxura polita dauka eta arazoa konpontzen du.

Ondorioz, dokumentaziorik ez dagoen kode mota ulertezin bat lor dezakezu, ez dago argi zer egiten duen, behar den ala ez, baina arazoa da garatu behar duzula, aldatu, makuluak eta euskarriak gehitu. , egoera are okerrago eginez.

- 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. eguna: Arazoaren kontzientzia

Hasieran pentsatu eta inplementatutako IaC ereduak ez ditu erabiltzaileen/enpresa/beste talde batzuen eskakizunak betetzen, eta azpiegituran aldaketak egiteko denbora onargarria izateari uzten dio. Momentu honetan, neurriak hartzeko garaia dela ulertzen da.

IaC birfaktorizazioa

139. eguna: Benetan behar al duzu birfactorizazioa?

Refaktoretzera joan aurretik, hainbat galdera garrantzitsu erantzun behar dituzu:

Zergatik behar duzu hau guztia?
Baduzu denbora?
Ezagutza nahikoa al da?

Galderak nola erantzun ez badakizu, birfactorizazioa hasi baino lehen amaituko da, edo agian okerrera egingo du. Zeren esperientzia izan ( Azpiegitura-kodearen 200 lerro probak ikasi dudana), orduan proiektuak laguntza-eskaera jaso zuen rolak konpontzeko eta probekin estaltzeko.

149. eguna: birfactorizazioa prestatzen

Lehenengo gauza prestatzea da. Erabaki zer egingo dugun. Horretarako, komunikatzen gara, arazo-eremuak aurkitzen eta horiek konpontzeko bideak asmatzen ditugu. Sortzen diren kontzeptuak nolabait erregistratzen ditugu, adibidez bat egiten duen artikulu bat, galdera sortzen denean "zer da onena?" edo "zein da zuzena?" Ez dugu bidea galdu. Gure kasuan, ideiari eutsi genion banatu eta gobernatu: azpiegitura zati txiki/adreiluetan zatitzen dugu. Ikuspegi honi esker, azpiegitura isolatu bat hartu, zer egiten duen ulertu, probez estali eta ezer hausteko beldurrik gabe alda dezakezu.

Ematen du azpiegitura probak oinarri bihurtzen direla eta hemen azpiegitura probak piramidea aipatzekoa da. Garatzen ari den ideia bera, baina azpiegituretarako: gauza sinpleak egiaztatzen dituzten proba azkar merkeetatik, koska adibidez, azpiegitura osoa zabaltzen duten proba oso garestietara pasatzen ari gara.

Ansible proba saiakerak

Proiektuan Ansible probak nola landu genituen deskribatzera joan aurretik, hartutako erabakien testuingurua ulertzeko lehenago erabiltzeko aukera izan nuen saiakera eta planteamenduak deskribatuko ditut.

-997. zenbakia: SDS hornidura

Ansible probatu nuen lehen aldiz SDS (Software Defined Storage) garatzeko proiektu batean izan zen. Gai honi buruzko artikulu bereizi bat dago
Nola hautsi bizikletak makuluen gainean zure banaketa probatzerakoan, baina laburbilduz, alderantzizko probaren piramide batekin amaitu genuen eta proban 60-90 minutu eman genituen rol batean, hau da, denbora luzea. Oinarria e2e probak ziren, hau da. erabateko instalazio bat zabaldu genuen eta gero probatu genuen. Are larrigarriagoa zen bere bizikleta asmatzea. Baina aitortu behar dut irtenbide honek funtzionatu zuela eta askapen egonkorra ahalbidetu zuela.

Eguna # -701: Ansible eta probako sukaldea

Ansible testing ideiaren garapena prest egindako tresnak erabiltzea izan zen, hots, test kitchen / kitchen-ci eta inspec. Rubyren ezagutzak erabaki zuen aukera (xehetasun gehiagorako, ikusi Habré-ri buruzko artikulua: YML programatzaileek Ansible probatzearekin amesten al dute?) azkarrago lan egin zuen, 40 minutu inguru 10 roletarako. Makina birtualen pack bat sortu genuen eta barruan probak egin genituen.

Oro har, disoluzioak funtzionatu zuen, baina sedimenturen bat zegoen heterogeneotasunagatik. Probatutako pertsonen kopurua oinarrizko 13 roletara eta 2 meta roletara rol txikiagoak konbinatuz handitu zenean, bat-batean probak 70 minutuz exekutatzen hasi ziren, hau da, ia 2 aldiz luzeagoa. XP (muturreko programazioa) praktikei buruz hitz egitea zaila zen, zeren... inork ez du 70 minutu itxaron nahi. Hori izan zen ikuspegia aldatzearen arrazoia

Eguna # -601: Ansible eta molekula

Kontzeptuki, testkitchen-en antzekoa da, soilik rol-probak dockerera eraman genituen eta pila aldatu genuen. Ondorioz, denbora 20-25 minutu egonkor batera murriztu zen 7 roletarako.

Probatutako rolen kopurua 17ra handituz eta 45 rol lortuz, 28 minututan exekutatu genuen 2 jenkins esklabotan.

167. eguna: proiektuari Ansible probak gehitzea

Seguruenik, ezin izango da refactoring zeregina presaka egin. Zereginak neurgarria izan behar du, zati txikitan apurtu eta koilaratxo batekin elefantea zatiz zati jan dezakezu. Norabide onean mugitzen ari zaren ala ez, zenbat denbora joan behar duzun ulertu behar da.

Oro har, berdin du nola egingo den, paper batean idatzi dezakezu, armairuan eranskailuak jar ditzakezu, Jiran zereginak sor ditzakezu edo Google Docs ireki eta uneko egoera idatzi dezakezu. han. Hankak hazten dira prozesua ez dela berehalakoa, luzea eta neketsua izango da. Nekez da inork nahi izatea ideiak agortzea, nekatzea eta larrituta egotea birfaktorizazioan.

Refactoring erraza da:

Jan.
Lo egin.
Kodea.
IaC proba.
Errepikatu

eta hau errepikatzen dugu aurreikusitako helburua lortu arte.

Agian ezinezkoa izango da dena berehala probatzen hastea, beraz, gure lehen lana linting eta sintaxia egiaztatzen hastea izan zen.

181. eguna: Eraikuntza Berdearen Maisua

Linting Green Build Masterrerako lehen urrats txiki bat da. Horrek ez du ia ezer hautsiko, baina prozesuak arazketa eta eraikuntza berdeak egiteko aukera emango dizu Jenkins-en. Taldearen artean ohiturak garatzea da asmoa:

Proba gorriak txarrak dira.
Zerbait konpontzera etorri naiz eta, aldi berean, kodea zure aurretik zegoena baino apur bat hobea egitera.

193. eguna: lintingetik unitate-probetara

Kodea maisuan sartzeko prozesua eraiki ondoren, urratsez urratseko hobekuntza prozesua has dezakezu - linting-a abiarazteko rolekin ordezkatuz, idempotentziarik gabe ere egin dezakezu. Rolak nola aplikatu eta nola funtzionatzen duten ulertu behar duzu.

211. eguna: Unitatetik integrazio probetara

Rol gehienak unitate-probekin estaltzen direnean eta dena lerrokatuta dagoenean, integrazio-probak gehitzera pasa zaitezke. Horiek. Azpiegituran adreilu bakar bat ez probatzea, horien konbinazioa baizik, adibidez, instantzia osoa konfigurazioa.

Jenkins erabiliz, rolak/playbooks paraleloan lerrokatzen zituzten etapa asko sortu genituen, ondoren ontzietan unitateko probak eta, azkenik, integrazio probak.

Jenkins + Docker + Ansible = Probak

Egin ordainagiria eta sortu eraikuntza faseak.
Exekutatu lint playbook faseak paraleloki.
Exekutatu lint rolaren faseak paraleloki.
Exekutatu sintaxia egiaztatzeko rol faseak paraleloki.
Exekutatu proba-rolen faseak paraleloki.
1. Lint rola.
2. Egiaztatu beste rolekiko mendekotasuna.
3. Egiaztatu sintaxia.
4. Sortu docker instantzia
5. Exekutatu molecule/default/playbook.yml.
6. Idempotentzia egiaztatu.
Egin integrazio probak
Amaitu

271. eguna: Autobus Faktorea

Hasieran, birfactorizazioa bizpahiru laguneko talde txiki batek egiten zuen. Masterrean kodea berrikusi dute. Denborak aurrera egin ahala, taldeak kodea idazteko ezagutzak garatu eta kodearen berrikuspena lagundu zuen azpiegiturari eta funtzionamenduari buruzko ezagutza zabaltzen. Hemen azpimarragarria izan zen ebaluatzaileak banan-banan hautatzen zirela, egutegi baten arabera, hau da. nolabaiteko probabilitatearekin azpiegitura berri batera igoko zara.

Eta erosoa izan beharko luke hemen. Komenigarria da errepaso bat egitea, zein zeregin egin den markoan ikustea eta eztabaidetako historia. Jenkins + bitbucket + jira integratu ditugu.

Baina, beraz, berrikuspena ez da panazea; nolabait, kode maisuan sartu ginen, eta horrek probak flop egin zizkigun:

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

Orduan konpondu zuten, baina hondarra geratu zen.

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. eguna: probak bizkortzea

Denborarekin, proba gehiago egon ziren, eraikuntzak motelagoak izan ziren, ordubete arte kasu txarrenean. Atzerako batean "probak egotea ona da, baina motelak dira" bezalako esaldia zegoen. Ondorioz, makina birtualetan integrazio-probak alde batera utzi eta Docker-erako egokitu genituen azkarrago egiteko. Testinfra egiaztatzaile ansible batekin ere ordeztu dugu erabilitako tresna kopurua murrizteko.

Zorrotz esanda, neurri multzo bat zegoen:

Aldatu dockerra.
Kendu rol probak, menpekotasunengatik bikoiztuta daudenak.
Esklabo kopurua handitu.
Proba egiteko ordena.
Lintatzeko gaitasuna GUZTIAK lokalean komando batekin.

Ondorioz, Pipeline on jenkins ere bateratu zen

Sortu eraikuntza-etapak.
Lint guztiak paraleloan.
Exekutatu proba-rolen faseak paraleloki.
Amaitu.

Ikasitakoak

Saihestu aldagai globalak

Ansiblek aldagai globalak erabiltzen ditu, inprimakian konponbide partziala dago rol_pribatuak, baina hau ez da panazea.

Adibide bat jartzen dizut. Izan dezagun 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}}

Dibertigarria da playbooken emaitza beti agerikoak ez diren gauzen araberakoa izango dela, hala nola rolak zerrendatzen diren ordena. Zoritxarrez, hori da Ansibleren izaera eta egin daitekeen gauzarik onena adostasun motaren bat erabiltzea da, adibidez, rol baten barruan, rol honetan deskribatutako aldagaia soilik erabiltzea.

ADB: aldagai globala erabili.

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

JARDUNBIDE: V defaults beharrezko aldagaiak definitu eta geroago horiek bakarrik erabili.

# 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

Rolaren aurrizkiaren aldagaiak

ADB: aldagai globala erabili.

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

JARDUNBIDE: Aldagaietarako roletan, erabili rolaren izenaren aurrizkia duten aldagaiak; honek, inbentarioari begiratuz, errazago ulertuko du gertatzen ari dena.

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

Erabili begizta kontrolatzeko aldagaia

ADB: Erabili aldagai estandarra begiztetan item, zeregin/jokoliburu hau nonbait sartzen bada, horrek ustekabeko portaera ekar dezake

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

JARDUNBIDE: aldagai bat birdefinitu begizta batean bidez loop_var.

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

Egiaztatu sarrerako aldagaiak

Aurrizki aldakorrak erabiltzea adostu genuen; ez litzateke soberan izango espero dugun moduan definituta daudela eta, adibidez, balio huts batek gainidazten ez dituela egiaztatzea.

JARDUNBIDE: Aldagaiak egiaztatu.

- 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

Saihestu hash-en hiztegiak, erabili egitura laua

Rol batek hash/hiztegi bat espero badu bere parametroetako batean, orduan haur-parametroren bat aldatu nahi badugu, hash/hiztegi osoa gainidatzi beharko dugu, eta horrek konfigurazioaren konplexutasuna areagotuko du.

ADB: Erabili hash/hiztegia.

---
user:
  name: admin
  group: admin

JARDUNBIDE: Erabili egitura aldakor laua.

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

Sortu joko-liburuak eta rolak idempotenteak

Rolak eta jolas liburuak idempotenteak izan behar dira, zeren konfigurazio-noraeza eta zerbait hausteko beldurra murrizten ditu. Baina molekula erabiltzen baduzu, hau da portaera lehenetsia.

Saihestu komando shell moduluak erabiltzea

Shell modulua erabiltzeak deskribapen paradigma ezinbestekoa da, deklaratiboaren ordez, hau da, Ansibleren muina.

Probatu zure rolak molekula bidez

Molekula oso gauza malgua da, ikus ditzagun eszenatoki batzuk.

Molekula Instantzia anitzak

В molecule.yml atalean platforms inplementa ditzakezun ostalari asko deskriba ditzakezu.

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

Horren arabera, ostalari hauek izan daitezke converge.yml erabili:

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

Molekulan ansible erabil daiteke instantzia behar bezala konfiguratuta dagoela egiaztatzeko, gainera, hau lehenetsia izan da 3. bertsiotik. Ez da testinfra/inspec bezain malgua, baina fitxategiaren edukia gure itxaropenekin bat datorrela egiaztatu dezakegu:

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

Edo zabaldu zerbitzua, itxaron erabilgarri egon arte eta egin ke-proba bat:

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

Jarri logika konplexua moduluetan eta pluginetan

Ansiblek ikuspegi deklaratiboa defendatzen du, beraz, kodea adarkatzea, datuen eraldaketa, shell moduluak egiten dituzunean, kodea irakurtzea zaila egiten da. Horri aurre egiteko eta ulertzeko erraza izateko, ez litzateke soberan izango konplexutasun horri aurre egitea zure moduluak sortuz.

Laburtu aholkuak eta trikimailuak

Saihestu aldagai globalak.
Rolaren aurrizkiaren aldagaiak.
Erabili begizta kontrolatzeko aldagaia.
Egiaztatu sarrerako aldagaiak.
Saihestu hash-en hiztegiak, erabili egitura laua.
Sortu joko-liburuak eta rolak idempotenteak.
Saihestu komando shell moduluak erabiltzea.
Probatu zure rolak molekula bidez.
Jarri logika konplexua moduluetan eta pluginetan.

Ondorioa

Ezin zara proiektu batean azpiegitura birfaktorizatu eta IaC baduzu ere. Pazientzia, denbora eta ezagutza eskatzen dituen prozesu luzea da.

Loturak

UPD1 2020.05.01 20:30 — Erabili ditzakezun jolas-liburuen profil nagusia egiteko callback_whitelist = profile_tasks denbora luzez zehazki zer funtzionatzen duen ulertzeko. Gero pasatzen gara Ansible azelerazio klasikoak. Probatu ere egin dezakezu mitogenoa
UPD2 2020.05.03 16:34 - Euskaraz

Iturria: www.habr.com

Nola hasi Ansible probatzen, proiektua urtebete barru birfaktorizatu eta ez erotu