ProHoster > Blog > Pangangasiwa > Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Diskarte IaC (Imprastraktura bilang Code) ay binubuo hindi lamang ng code na nakaimbak sa repositoryo, kundi pati na rin ng mga tao at mga prosesong nakapaligid sa code na ito. Posible bang gumamit muli ng mga diskarte mula sa pagbuo ng software hanggang sa pamamahala at paglalarawan ng imprastraktura? Magandang ideya na isaisip ang ideyang ito habang binabasa mo ang artikulo.

Angielski bersiyon

Ito ay isang transcript ng aking mga pagtatanghal sa DevopsConf 2019-05-28.

Mga slide at video

Imprastraktura bilang kasaysayan ng bash

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ipagpalagay na dumating ka sa isang bagong proyekto, at sasabihin nila sa iyo: "namin Ang imprastraktura bilang Code". Sa katotohanan lumalabas Imprastraktura bilang kasaysayan ng bash o halimbawa Dokumentasyon bilang kasaysayan ng bash. Ito ay isang tunay na sitwasyon, halimbawa, ang isang katulad na kaso ay inilarawan ni Denis Lysenko sa isang talumpati Paano palitan ang buong imprastraktura at simulan ang pagtulog nang mapayapa, sinabi niya kung paano sila nakakuha ng magkakaugnay na imprastraktura para sa proyekto mula sa kasaysayan ng bash.

Sa ilang pagnanais, masasabi natin iyan Imprastraktura bilang kasaysayan ng bash ito ay tulad ng code:

  1. reproducibility: Maaari kang kumuha ng kasaysayan ng bash, patakbuhin ang mga utos mula doon, at maaari kang, sa pamamagitan ng paraan, makakuha ng gumaganang pagsasaayos bilang isang output.
  2. versioning: alam mo kung sino ang pumasok at kung ano ang kanilang ginawa, muli, hindi ito isang katotohanan na ito ay magdadala sa iyo sa isang gumaganang configuration sa exit.
  3. kuwento: ang kwento ng kung sino ang gumawa ng ano. hindi mo lang ito magagamit kapag nawala mo ang server.

Ano ang dapat gawin?

Ang imprastraktura bilang Code

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Kahit na tulad ng isang kakaibang kaso bilang Imprastraktura bilang kasaysayan ng bash maaari mong hilahin ito sa pamamagitan ng tainga Ang imprastraktura bilang Code, ngunit kapag gusto naming gumawa ng isang bagay na mas kumplikado kaysa sa magandang lumang LAMP server, kami ay darating sa konklusyon na ang code na ito ay kailangang kahit papaano ay mabago, baguhin, mapabuti. Susunod na nais naming isaalang-alang ang mga parallel sa pagitan Ang imprastraktura bilang Code at pagbuo ng software.

TUYO

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa isang proyekto sa pagbuo ng sistema ng imbakan, mayroong isang subtask pana-panahong i-configure ang SDS: naglalabas kami ng bagong release - kailangan itong ilunsad para sa karagdagang pagsubok. Ang gawain ay napaka-simple:

  • mag-log in dito sa pamamagitan ng ssh at isagawa ang utos.
  • kopyahin ang file doon.
  • itama ang config dito.
  • simulan ang serbisyo doon
  • ...
  • KITA!

Para sa inilarawan na lohika, ang bash ay higit pa sa sapat, lalo na sa mga unang yugto ng proyekto, kapag ito ay nagsisimula pa lamang. Ito hindi naman masama na gumamit ka ng bash, ngunit sa paglipas ng panahon ay may mga kahilingang mag-deploy ng katulad, ngunit bahagyang naiiba. Ang unang bagay na pumapasok sa isip ay copy-paste. At ngayon mayroon na tayong dalawang magkatulad na script na halos pareho ang ginagawa. Sa paglipas ng panahon, ang bilang ng mga script ay lumago, at kami ay nahaharap sa katotohanan na mayroong isang tiyak na lohika ng negosyo para sa pag-deploy ng isang pag-install na kailangang i-synchronize sa pagitan ng iba't ibang mga script, ito ay medyo kumplikado.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

May practice pala na DRY (Do not Repeat Yourself). Ang ideya ay muling gamitin ang umiiral na code. Mukhang simple, ngunit hindi kami nakarating dito kaagad. Sa aming kaso, ito ay isang banal na ideya: upang paghiwalayin ang mga config mula sa mga script. Yung. lohika ng negosyo kung paano naka-deploy nang hiwalay ang pag-install, hiwalay ang mga config.

SOLID para sa CFM

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa paglipas ng panahon lumago ang proyekto at natural na pagpapatuloy ay ang paglitaw ng Ansible. Ang pangunahing dahilan para sa hitsura nito ay na mayroong kadalubhasaan sa koponan at ang bash ay hindi idinisenyo para sa kumplikadong lohika. Nagsimula rin ang Ansible na maglaman ng kumplikadong lohika. Upang maiwasan ang kumplikadong lohika na maging kaguluhan, may mga prinsipyo ng organisasyon ng code sa pagbuo ng software SOLID Gayundin, halimbawa, si Grigory Petrov sa ulat na "Bakit kailangan ng isang espesyalista sa IT ng isang personal na tatak" ay itinaas ang tanong na ang isang tao ay idinisenyo sa paraang mas madali para sa kanya na gumana sa ilang mga social entity, sa pagbuo ng software ang mga ito. ay mga bagay. Kung pagsasamahin natin ang dalawang ideyang ito at patuloy nating bubuoin, mapapansin natin na magagamit din natin SOLID upang gawing mas madaling mapanatili at baguhin ang lohika na ito sa hinaharap.

Ang Prinsipyo ng Iisang Pananagutan

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang bawat klase ay gumaganap lamang ng isang gawain.

Hindi na kailangang maghalo ng code at gumawa ng monolitikong banal na spaghetti monsters. Ang imprastraktura ay dapat na binubuo ng mga simpleng brick. Lumalabas na kung hahatiin mo ang Ansible playbook sa maliliit na piraso, basahin ang mga tungkulin ng Ansible, kung gayon mas madaling mapanatili ang mga ito.

Ang Open Closed na Prinsipyo

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Bukas/sarado na prinsipyo.

  • Bukas sa extension: nangangahulugan na ang pag-uugali ng isang entity ay maaaring palawigin sa pamamagitan ng paglikha ng mga bagong uri ng entity.
  • Isinara sa pagbabago: Bilang resulta ng pagpapalawak ng gawi ng isang entity, walang mga pagbabagong dapat gawin sa code na gumagamit ng mga entity na iyon.

Noong una, inilagay namin ang pagsubok na imprastraktura sa mga virtual machine, ngunit dahil sa katotohanan na ang lohika ng negosyo ng deployment ay hiwalay sa pagpapatupad, idinagdag namin ang paglulunsad sa baremetall nang walang anumang problema.

Ang Prinsipyo ng Pagpapalit ng Liskov

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang prinsipyo ng pagpapalit ni Barbara Liskov. ang mga bagay sa isang programa ay dapat mapalitan ng mga pagkakataon ng kanilang mga subtype nang hindi binabago ang tamang pagpapatupad ng programa

Kung titingnan mo ito nang mas malawak, hindi ito isang tampok ng anumang partikular na proyekto na maaaring ilapat doon SOLID, ito ay karaniwang tungkol sa CFM, halimbawa, sa isa pang proyekto, kinakailangan na mag-deploy ng isang boxed Java application sa ibabaw ng iba't ibang Java, application server, database, OS, atbp. Gamit ang halimbawang ito, isasaalang-alang ko ang mga karagdagang prinsipyo SOLID

Sa aming kaso, mayroong isang kasunduan sa loob ng koponan ng imprastraktura na kung na-install namin ang papel na imbjava o oraclejava, mayroon kaming isang java binary na maipapatupad. Ito ay kailangan dahil Ang mga upstream na tungkulin ay nakasalalay sa pag-uugaling ito; Kasabay nito, nagbibigay-daan ito sa amin na palitan ang isang pagpapatupad/bersyon ng java ng isa pa nang hindi binabago ang logic sa pag-deploy ng application.

Ang problema dito ay nakasalalay sa katotohanan na imposibleng ipatupad ito sa Ansible, bilang isang resulta kung saan lumilitaw ang ilang mga kasunduan sa loob ng koponan.

Ang Prinsipyo ng Interface Segregation

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Prinsipyo ng paghihiwalay ng interface: "Maraming mga interface na partikular sa kliyente ang mas mahusay kaysa sa isang pangkalahatang layunin na interface.

Sa una, sinubukan naming ilagay ang lahat ng pagkakaiba-iba ng pag-deploy ng application sa isang Ansible playbook, ngunit mahirap itong suportahan, at ang diskarte kapag mayroon kaming isang panlabas na interface na tinukoy (inaasahan ng kliyente ang port 443), pagkatapos ay ang isang imprastraktura ay maaaring tipunin mula sa indibidwal. brick para sa isang partikular na pagpapatupad.

Ang Dependency Inversion Principle

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang prinsipyo ng dependency inversion. Ang mga module sa mas mataas na antas ay hindi dapat nakadepende sa mga module sa mas mababang antas. Ang parehong uri ng mga module ay dapat nakadepende sa mga abstraction. Ang mga abstraction ay hindi dapat nakadepende sa mga detalye. Ang mga detalye ay dapat nakadepende sa mga abstraction.

Dito ibabatay ang halimbawa sa isang antipattern.

  1. Ang isa sa mga customer ay may pribadong ulap.
  2. Nag-order kami ng mga virtual machine sa loob ng cloud.
  3. Ngunit dahil sa likas na katangian ng cloud, ang pag-deploy ng application ay nakatali sa kung saan naka-on ang hypervisor ng VM.

Yung. Ang mataas na antas ng lohika sa pag-deploy ng application ay dumaloy na may mga dependency sa mas mababang antas ng hypervisor, at nangangahulugan ito ng mga problema kapag muling ginagamit ang logic na ito. Huwag gawin ito sa ganitong paraan.

Pakipagtulungan

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang imprastraktura bilang code ay hindi lamang tungkol sa code, ngunit tungkol din sa ugnayan sa pagitan ng code at mga tao, tungkol sa mga pakikipag-ugnayan sa pagitan ng mga developer ng imprastraktura.

Salik ng bus

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ipagpalagay natin na mayroon kang Vasya sa iyong proyekto. Alam ni Vasya ang lahat tungkol sa iyong imprastraktura, ano ang mangyayari kung biglang mawala si Vasya? Ito ay isang tunay na sitwasyon, dahil maaari siyang mabangga ng isang bus. Nangyayari minsan. Kung nangyari ito at ang kaalaman tungkol sa code, istraktura nito, kung paano ito gumagana, pagpapakita at mga password ay hindi ibinahagi sa koponan, kung gayon maaari kang makatagpo ng isang bilang ng mga hindi kasiya-siyang sitwasyon. Upang mabawasan ang mga panganib na ito at maipamahagi ang kaalaman sa loob ng koponan, maaari kang gumamit ng iba't ibang mga diskarte

Pair Devopsing

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ito ay hindi tulad ng bilang isang biro, na ang mga admin ay umiinom ng beer, nagpalit ng mga password, at isang analogue ng pares na programming. Yung. dalawang inhinyero ang nakaupo sa isang computer, isang keyboard at nagsimulang i-set up ang iyong imprastraktura nang magkasama: pag-set up ng server, pagsusulat ng Ansible na tungkulin, atbp. Mukhang maganda, ngunit hindi ito gumana para sa amin. Ngunit gumana ang mga espesyal na kaso ng pagsasanay na ito. Dumating ang isang bagong empleyado, ang kanyang tagapagturo ay nagsasagawa ng isang tunay na gawain kasama niya, nagtatrabaho at naglilipat ng kaalaman.

Ang isa pang espesyal na kaso ay isang tawag sa insidente. Sa panahon ng isang problema, ang isang grupo ng mga nasa tungkulin at mga kasangkot ay nagtitipon, isang pinuno ang hinirang, na nagbabahagi ng kanyang screen at tinig ang tren ng pag-iisip. Sinusunod ng ibang mga kalahok ang mga iniisip ng pinuno, nag-espiya sa mga trick mula sa console, tingnan kung wala silang napalampas na linya sa log, at matuto ng mga bagong bagay tungkol sa system. Ang diskarte na ito ay gumana nang mas madalas kaysa sa hindi.

Pagaaral ng Koda

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa pangkalahatan, mas epektibo ang pagpapalaganap ng kaalaman tungkol sa imprastraktura at kung paano ito gumagana gamit ang pagsusuri ng code:

  • Inilalarawan ang imprastraktura sa pamamagitan ng code sa repositoryo.
  • Ang mga pagbabago ay nangyayari sa isang hiwalay na sangay.
  • Sa panahon ng kahilingan sa pagsasama, makikita mo ang delta ng mga pagbabago sa imprastraktura.

Ang highlight dito ay ang mga reviewer ay napili nang isa-isa, ayon sa isang iskedyul, i.e. na may ilang antas ng posibilidad na aakyat ka sa isang bagong piraso ng imprastraktura.

Estilo ng Code

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa paglipas ng panahon, nagsimulang lumitaw ang mga squabble sa panahon ng mga pagsusuri, dahil... may sariling istilo ang mga reviewer at ang pag-ikot ng mga reviewer ay nakasalansan sa kanila ng iba't ibang istilo: 2 space o 4, camelCase o snake_case. Hindi posible na ipatupad ito kaagad.

  • Ang unang ideya ay irekomenda ang paggamit ng linter, pagkatapos ng lahat, lahat ay isang inhinyero, lahat ay matalino. Ngunit ang iba't ibang mga editor, OS, ay hindi maginhawa
  • Nag-evolve ito sa isang bot na sumulat upang maluwag para sa bawat may problemang commit at naka-attach ang linter na output. Ngunit sa karamihan ng mga kaso mayroong mas mahahalagang bagay na dapat gawin at ang code ay nanatiling hindi naayos.

Green Build Master

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Lumipas ang oras, at nakarating kami sa konklusyon na ang mga commit na hindi pumasa sa ilang mga pagsubok ay hindi maaaring payagan sa master. Voila! Nag-imbento kami ng Green Build Master, na ginagawa sa pagbuo ng software sa mahabang panahon:

  • Ang pag-unlad ay isinasagawa sa isang hiwalay na sangay.
  • Ang mga pagsubok ay tumatakbo sa thread na ito.
  • Kung mabibigo ang mga pagsubok, ang code ay hindi makapasok sa master.

Ang paggawa ng desisyong ito ay napakasakit, dahil... Nagdulot ng maraming kontrobersya, ngunit sulit ito, dahil... Ang mga review ay nagsimulang makatanggap ng mga kahilingan para sa mga pagsasanib nang walang mga pagkakaiba sa istilo, at sa paglipas ng panahon ang bilang ng mga lugar ng problema ay nagsimulang bumaba.

Pagsusuri sa IaC

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Bilang karagdagan sa pagsusuri ng istilo, maaari kang gumamit ng iba pang mga bagay, halimbawa, upang suriin kung ang iyong imprastraktura ay maaaring aktwal na i-deploy. O suriin na ang mga pagbabago sa imprastraktura ay hindi hahantong sa pagkawala ng pera. Bakit maaaring kailanganin ito? Ang tanong ay kumplikado at pilosopo, mas mahusay na sagutin sa isang kuwento na kahit papaano ay mayroong isang auto-scaler sa Powershell na hindi nagsuri sa mga kundisyon sa hangganan => mas maraming VM ang nilikha kaysa sa kinakailangan => ang kliyente ay gumastos ng mas maraming pera kaysa sa binalak. Ito ay hindi masyadong kaaya-aya, ngunit magiging posible na mahuli ang error na ito sa mga naunang yugto.

Maaaring may magtanong, bakit ginagawang mas kumplikado ang kumplikadong imprastraktura? Ang mga pagsubok para sa imprastraktura, tulad ng para sa code, ay hindi tungkol sa pagpapasimple, ngunit tungkol sa pag-alam kung paano dapat gumana ang iyong imprastraktura.

IaC Testing Pyramid

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Pagsusuri sa IaC: Static na Pagsusuri

Kung i-deploy mo ang buong imprastraktura nang sabay-sabay at titingnan kung gumagana ito, maaari mong makita na tumatagal ito ng maraming oras at nangangailangan ng maraming oras. Samakatuwid, ang batayan ay dapat na isang bagay na mabilis na gumagana, mayroong maraming nito, at sumasaklaw ito sa maraming primitive na lugar.

Nakakalito si Bash

Tingnan natin ang isang maliit na halimbawa. piliin ang lahat ng mga file sa kasalukuyang direktoryo at kopyahin sa ibang lokasyon. Ang unang bagay na pumapasok sa isip:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Paano kung may puwang sa pangalan ng file? Well, ok, matalino kami, marunong kaming gumamit ng mga quotes:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Magaling? Hindi! Paano kung wala sa direktoryo, i.e. hindi gagana ang globbing.

find . -type f -exec mv -v {} dst/{}.bak ;

Magaling na ngayon? Hindi... Nakalimutan kung ano ang maaaring nasa pangalan ng file n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Mga tool sa static na pagsusuri

Ang problema mula sa nakaraang hakbang ay maaaring makuha kapag nakalimutan natin ang mga panipi, para dito mayroong maraming mga remedyo sa kalikasan Shellcheck, sa pangkalahatan ay marami sa kanila, at malamang na makakahanap ka ng linter para sa iyong stack sa ilalim ng iyong IDE.

Wika
Kasangkapan

malakas na palo
Shellcheck

Mapula
RuboCop

python
pylint

ansible
Ansible Lint

IaC Testing: Mga Unit Test

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Tulad ng nakita natin mula sa nakaraang halimbawa, ang mga linter ay hindi makapangyarihan sa lahat at hindi maaaring ituro ang lahat ng mga lugar ng problema. Dagdag pa, sa pamamagitan ng pagkakatulad sa pagsubok sa pagbuo ng software, maaari nating maalala ang mga pagsubok sa yunit. Ang agad na pumasok sa isip sunit, junit, rspec, pytest. Ngunit ano ang gagawin sa ansible, chef, saltstack at iba pang katulad nila?

Sa umpisa pa lang napag-usapan namin SOLID at ang ating imprastraktura ay dapat na binubuo ng maliliit na ladrilyo. Dumating na ang kanilang oras.

  1. Ang imprastraktura ay nahahati sa maliliit na brick, halimbawa, Ansible roles.
  2. Ang ilang uri ng kapaligiran ay na-deploy, ito man ay docker o isang VM.
  3. Inilapat namin ang aming Ansible na tungkulin sa kapaligiran ng pagsubok na ito.
  4. Sinusuri namin na gumagana ang lahat gaya ng inaasahan namin (nagpapatakbo kami ng mga pagsubok).
  5. We decide ok o hindi ok.

Pagsusuri sa IaC: Mga tool sa Pagsusuri ng Unit

Tanong, ano ang mga pagsubok para sa CFM? Maaari mo lamang patakbuhin ang script, o maaari mong gamitin ang mga handa na solusyon para dito:

CFM
Kasangkapan

Ansible
Testinfra

Punong tagapagluto
Sinabi ni Inspec

Punong tagapagluto
Serverspec

saltstack
Tsismis

Halimbawa para sa testinfra, pagsuri sa mga user na iyon test1, test2 umiiral at nasa isang grupo sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Ano ang pipiliin? Ang tanong ay kumplikado at hindi maliwanag, narito ang isang halimbawa ng mga pagbabago sa mga proyekto sa github para sa 2018-2019:

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Mga framework ng IaC Testing

Ang tanong ay arises: kung paano pagsamahin ang lahat ng ito at ilunsad ito? Pwede kunin mo at gawin mo mismo kung may sapat na bilang ng mga inhinyero. O maaari kang kumuha ng mga handa na solusyon, kahit na hindi masyadong marami sa kanila:

CFM
Kasangkapan

Ansible
Molecule

Punong tagapagluto
Pagsubok sa Kusina

Terraform
Terratest

Halimbawa ng mga pagbabago sa mga proyekto sa github para sa 2018-2019:

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Molecule vs. Testkitchen

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa una kami sinubukang gumamit ng testkitchen:

  1. Lumikha ng isang VM sa parallel.
  2. Ilapat ang mga tungkuling Ansible.
  3. Patakbuhin ang inspeksyon.

Para sa 25-35 na tungkulin ay nagtrabaho ito ng 40-70 minuto, na mahaba.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang susunod na hakbang ay ang paglipat sa jenkins/docker/ansible/molecule. Sa idiologically lahat ay pareho

  1. Lint playbooks.
  2. Ihanay ang mga tungkulin.
  3. Ilunsad ang lalagyan
  4. Ilapat ang mga tungkuling Ansible.
  5. Patakbuhin ang testinfra.
  6. Suriin ang idempotency.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang linting para sa 40 na tungkulin at pagsusulit para sa isang dosena ay nagsimulang tumagal ng mga 15 minuto.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang pipiliin ay depende sa maraming salik, gaya ng stack na ginamit, kadalubhasaan sa team, atbp. dito lahat ay nagpapasya para sa kanilang sarili kung paano isasara ang tanong sa pagsubok ng Unit

Pagsusuri sa IaC: Mga Pagsusuri sa Pagsasama

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang susunod na hakbang sa infrastructure testing pyramid ay ang integration tests. Ang mga ito ay katulad ng mga pagsubok sa Unit:

  1. Ang imprastraktura ay nahahati sa maliliit na brick, halimbawa Ansible roles.
  2. Ang ilang uri ng kapaligiran ay na-deploy, ito man ay docker o isang VM.
  3. Para sa kapaligiran ng pagsubok na ito ay nalalapat marami Ansible na mga tungkulin.
  4. Sinusuri namin na gumagana ang lahat gaya ng inaasahan namin (nagpapatakbo kami ng mga pagsubok).
  5. We decide ok o hindi ok.

Sa halos pagsasalita, hindi namin sinusuri ang pagganap ng isang indibidwal na elemento ng system tulad ng sa mga pagsubok sa yunit, sinusuri namin kung paano naka-configure ang server sa kabuuan.

IaC Testing: End to End Tests

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Sa tuktok ng pyramid ay binabati tayo ng End to End test. Yung. Hindi namin sinusuri ang pagganap ng isang hiwalay na server, isang hiwalay na script, o isang hiwalay na brick ng aming imprastraktura. Sinusuri namin na maraming mga server ang konektado nang magkasama, gumagana ang aming imprastraktura gaya ng inaasahan namin. Sa kasamaang palad, hindi pa ako nakakita ng mga nakahanda na solusyon sa kahon, marahil dahil... Ang imprastraktura ay madalas na natatangi at mahirap i-template at lumikha ng isang balangkas para sa pagsubok. Bilang resulta, ang bawat isa ay lumilikha ng kanilang sariling mga solusyon. May hinihiling, ngunit walang sagot. Samakatuwid, sasabihin ko sa iyo kung ano ang mayroon upang itulak ang iba na mag-isip ng mabuti o kuskusin ang aking ilong sa katotohanan na ang lahat ay naimbento noon pa man bago tayo.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Isang proyektong may mayamang kasaysayan. Ito ay ginagamit sa malalaking organisasyon at malamang na ang bawat isa sa inyo ay hindi direktang nakipagtagpo dito. Sinusuportahan ng application ang maraming mga database, pagsasama, atbp. Ang pag-alam kung ano ang maaaring hitsura ng imprastraktura ay maraming mga docker-compose file, at pag-alam kung aling mga pagsubok ang tatakbo sa kung aling kapaligiran ang Jenkins.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang pamamaraan na ito ay nagtrabaho nang medyo mahabang panahon, hanggang sa loob ng balangkas pananaliksik hindi namin sinubukang ilipat ito sa Openshift. Ang mga lalagyan ay nananatiling pareho, ngunit ang kapaligiran ng paglulunsad ay nagbago (hello DRY muli).

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Ang ideya sa pagsasaliksik ay nagpatuloy, at sa openshift ay natagpuan nila ang isang bagay tulad ng APB (Ansible Playbook Bundle), na nagbibigay-daan sa iyong mag-pack ng kaalaman kung paano mag-deploy ng imprastraktura sa isang lalagyan. Yung. mayroong isang nauulit, masusubok na punto ng kaalaman kung paano i-deploy ang imprastraktura.

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Maganda ang lahat ng ito hanggang sa napunta kami sa isang magkakaibang imprastraktura: kailangan namin ng Windows para sa mga pagsubok. Bilang resulta, nasa jenkins ang kaalaman kung ano, saan, paano i-deploy, at pagsubok.

Konklusyon

Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code

Imprastraktura bilang Code ay

  • Code sa repositoryo.
  • Interaksyon ng tao.
  • Pagsubok sa imprastraktura.

mga link

Pinagmulan: www.habr.com

Magdagdag ng komento