Njia IaC (Miundombinu kama Kanuni) haijumuishi tu msimbo ambao umehifadhiwa kwenye ghala, bali pia watu na michakato inayozunguka msimbo huu. Je, inawezekana kutumia tena mbinu kutoka kwa ukuzaji wa programu hadi usimamizi wa miundombinu na maelezo? Itakuwa wazo nzuri kuweka wazo hili akilini wakati unasoma makala.

Hii ni nakala yangu maonyesho juu ya DevopsConf 2019-05-28.

Slaidi na video

english version
Toleo la Urusi
Mbio kavu 2019-04-24 SpbLUG
Video(RU) kutoka DevopsConf 2019-05-28
Video(RU) kutoka kwa DINS DevOps EVENING 2019-06-20
Slides

Miundombinu kama historia ya bash

Tuseme unakuja kwenye mradi mpya, na wanakuambia: "tumefanya Miundombinu kama Kanuni". Katika hali halisi inageuka Miundombinu kama historia ya bash au kwa mfano Hati kama historia ya bash. Hii ni hali halisi, kwa mfano, kesi kama hiyo ilielezewa na Denis Lysenko katika hotuba Jinsi ya kuchukua nafasi ya miundombinu yote na kuanza kulala vizuri, alisimulia jinsi walivyopata miundombinu thabiti ya mradi kutoka kwa historia ya bash.

Kwa hamu fulani, tunaweza kusema hivyo Miundombinu kama historia ya bash hii ni kama kanuni:

kuzaliana: Unaweza kuchukua historia ya bash, endesha amri kutoka hapo, na unaweza, kwa njia, kupata usanidi wa kufanya kazi kama pato.
utayarishaji: unajua ni nani aliyeingia na walifanya nini, tena, sio ukweli kwamba hii itakuongoza kwenye usanidi wa kufanya kazi wakati wa kuondoka.
historia: hadithi ya nani alifanya nini. tu hutaweza kuitumia ikiwa utapoteza seva.

Nini cha kufanya?

Miundombinu kama Kanuni

Hata kesi ya ajabu kama Miundombinu kama historia ya bash unaweza kuvuta kwa masikio Miundombinu kama Kanuni, lakini tunapotaka kufanya kitu ngumu zaidi kuliko seva nzuri ya zamani ya LAMP, tutakuja kumalizia kwamba kanuni hii inahitaji kurekebishwa kwa namna fulani, kubadilishwa, kuboreshwa. Ifuatayo tungependa kuzingatia ulinganifu kati ya Miundombinu kama Kanuni na maendeleo ya programu.

D.R.Y.

Kwenye mradi wa ukuzaji wa mfumo wa uhifadhi, kulikuwa na kazi ndogo mara kwa mara sanidi SDS: tunatoa toleo jipya - linahitaji kuchapishwa kwa majaribio zaidi. Kazi ni rahisi sana:

ingia hapa kupitia ssh na utekeleze amri.
nakili faili hapo.
rekebisha usanidi hapa.
anza huduma hapo
...
Fanya!

Kwa mantiki iliyoelezwa, bash ni zaidi ya kutosha, hasa katika hatua za mwanzo za mradi, wakati unaanza tu. Hii sio mbaya kwamba unatumia bash, lakini baada ya muda kuna maombi ya kupeleka kitu sawa, lakini tofauti kidogo. Jambo la kwanza linalokuja akilini ni nakala-kubandika. Na sasa tayari tunayo hati mbili zinazofanana ambazo hufanya karibu kitu kimoja. Baada ya muda, idadi ya maandishi ilikua, na tulikuwa tunakabiliwa na ukweli kwamba kuna mantiki fulani ya biashara ya kupeleka usakinishaji ambao unahitaji kusawazishwa kati ya maandishi tofauti, hii ni ngumu sana.

Inabadilika kuwa kuna mazoezi kama vile D.R.Y. (Usijirudie). Wazo ni kutumia tena nambari iliyopo. Inaonekana rahisi, lakini hatukuja kwa hili mara moja. Kwa upande wetu, ilikuwa wazo la banal: kutenganisha usanidi kutoka kwa maandishi. Wale. mantiki ya biashara ya jinsi usakinishaji unavyotumwa kando, husanidi kando.

S.O.L.I.D. kwa CFM

Baada ya muda mradi ulikua na muendelezo wa asili ilikuwa kuibuka kwa Ansible. Sababu kuu ya kuonekana kwake ni kwamba kuna utaalam kwenye timu na kwamba bash haijaundwa kwa mantiki ngumu. Ansible pia ilianza kuwa na mantiki ngumu. Ili kuzuia mantiki ngumu kugeuka kuwa machafuko, kuna kanuni za kupanga kanuni katika maendeleo ya programu S.O.L.I.D. Pia, kwa mfano, Grigory Petrov katika ripoti "Kwa nini mtaalam wa IT anahitaji chapa ya kibinafsi" aliuliza swali kwamba mtu ameundwa kwa njia ambayo ni rahisi kwake kufanya kazi na vyombo vingine vya kijamii, katika ukuzaji wa programu hizi. ni vitu. Ikiwa tutachanganya mawazo haya mawili na kuendelea kuyaendeleza, tutaona kwamba tunaweza pia kutumia S.O.L.I.D. ili iwe rahisi kudumisha na kurekebisha mantiki hii katika siku zijazo.

Kanuni ya Wajibu Mmoja

Kila darasa hufanya kazi moja tu.

Hakuna haja ya kuchanganya kanuni na kufanya monolithic monsters tambi kimungu. Miundombinu inapaswa kuwa na matofali rahisi. Inabadilika kuwa ikiwa unagawanya kitabu cha kucheza cha Ansible katika vipande vidogo, soma majukumu yanayostahili, basi ni rahisi kudumisha.

Kanuni ya Fungua Iliyofungwa

Kanuni iliyofunguliwa/iliyofungwa.

Fungua kwa kiendelezi: inamaanisha kuwa tabia ya huluki inaweza kupanuliwa kwa kuunda aina mpya za huluki.
Imefungwa kubadilika: Kutokana na kupanua tabia ya huluki, hakuna mabadiliko yanayopaswa kufanywa kwa msimbo unaotumia huluki hizo.

Hapo awali, tulipeleka miundombinu ya majaribio kwenye mashine pepe, lakini kwa sababu ya ukweli kwamba mantiki ya biashara ya uwekaji ilikuwa tofauti na utekelezaji, tuliongeza kusambaza kwa baremetall bila shida yoyote.

Kanuni ya Kubadilisha Liskov

Kanuni ya badala ya Barbara Liskov. vitu kwenye programu lazima vibadilishwe na visa vya aina zao ndogo bila kubadilisha utekelezwaji sahihi wa programu.

Ukiiangalia kwa upana zaidi, sio kipengele cha mradi wowote ambao unaweza kutumika hapo S.O.L.I.D., kwa ujumla ni kuhusu CFM, kwa mfano, kwenye mradi mwingine ni muhimu kupeleka maombi ya Java ya sanduku juu ya Java mbalimbali, seva za maombi, hifadhidata, OS, nk. Kwa kutumia mfano huu, nitazingatia kanuni zaidi S.O.L.I.D.

Kwa upande wetu, kuna makubaliano ndani ya timu ya miundombinu kwamba ikiwa tumesakinisha jukumu la imbjava au oraclejava, basi tuna java binary inayoweza kutekelezwa. Hii ni lazima kwa sababu Majukumu ya juu yanategemea tabia hii; wanatarajia java. Wakati huo huo, hii inaturuhusu kubadilisha utekelezaji/toleo moja la java na lingine bila kubadilisha mantiki ya uwekaji programu.

Shida hapa iko katika ukweli kwamba haiwezekani kutekeleza hii kwa Ansible, kama matokeo ambayo makubaliano kadhaa yanaonekana ndani ya timu.

Kanuni ya Kutenganisha Kiolesura

Kanuni ya utenganishaji wa kiolesura: “Miunganisho mingi ya mteja mahususi ni bora kuliko kiolesura kimoja cha madhumuni ya jumla.

Hapo awali, tulijaribu kuweka tofauti zote za upelekaji wa programu kwenye kitabu kimoja cha kucheza, lakini ilikuwa ngumu kuunga mkono, na mbinu tukiwa na kiolesura cha nje kilichoainishwa (mteja anatarajia bandari 443), basi miundombinu inaweza kukusanywa kutoka kwa mtu binafsi. matofali kwa utekelezaji maalum.

Kanuni ya Ugeuzi wa Utegemezi

Kanuni ya ubadilishaji wa utegemezi. Module katika viwango vya juu hazipaswi kutegemea moduli katika viwango vya chini. Aina zote mbili za moduli lazima zitegemee vifupisho. Vifupisho haipaswi kutegemea maelezo. Maelezo lazima yategemee vifupisho.

Hapa mfano utakuwa msingi wa antipattern.

Mmoja wa wateja alikuwa na wingu binafsi.
Tuliagiza mashine pepe ndani ya wingu.
Lakini kwa sababu ya asili ya wingu, utumaji wa programu uliunganishwa kwa ambayo kiashiria cha VM kilikuwa kimewashwa.

Wale. Mantiki ya uwekaji wa programu ya kiwango cha juu ilitiririka na tegemezi kwa viwango vya chini vya hypervisor, na hii ilimaanisha matatizo wakati wa kutumia tena mantiki hii. Usifanye hivi.

Maingiliano

Miundombinu kama msimbo sio tu kuhusu msimbo, lakini pia kuhusu uhusiano kati ya msimbo na watu, kuhusu mwingiliano kati ya watengenezaji miundombinu.

Sababu ya basi

Wacha tufikirie kuwa una Vasya kwenye mradi wako. Vasya anajua kila kitu kuhusu miundombinu yako, nini kitatokea ikiwa Vasya atatoweka ghafla? Hii ni hali halisi, kwa sababu anaweza kugongwa na basi. Wakati mwingine hutokea. Ikiwa hii itatokea na ujuzi kuhusu kanuni, muundo wake, jinsi inavyofanya kazi, kuonekana na nywila hazijasambazwa kati ya timu, basi unaweza kukutana na hali kadhaa zisizofurahi. Ili kupunguza hatari hizi na kusambaza ujuzi ndani ya timu, unaweza kutumia mbinu mbalimbali

Jozi Devopsing

Sio kama kama mzaha, kwamba wasimamizi walikunywa bia, walibadilisha manenosiri, na analogi ya upangaji wa programu jozi. Wale. wahandisi wawili huketi kwenye kompyuta moja, kibodi moja na kuanza kusanidi miundombinu yako pamoja: kusanidi seva, kuandika jukumu linalofaa, nk. Inaonekana nzuri, lakini haikufanya kazi kwetu. Lakini kesi maalum za mazoezi haya zilifanya kazi. Mfanyakazi mpya anakuja, mshauri wake anachukua kazi halisi pamoja naye, anafanya kazi na kuhamisha ujuzi.

Kesi nyingine maalum ni simu ya tukio. Wakati wa shida, kikundi cha wale walio kwenye zamu na wale wanaohusika hukusanyika, kiongozi mmoja anateuliwa, ambaye anashiriki skrini yake na kutoa sauti ya mawazo. Washiriki wengine hufuata mawazo ya kiongozi, kupeleleza hila kutoka kwa console, angalia kwamba hawajakosa mstari kwenye logi, na kujifunza mambo mapya kuhusu mfumo. Mbinu hii ilifanya kazi mara nyingi zaidi kuliko sivyo.

Mapitio ya Kanuni

Kimsingi, ilikuwa na ufanisi zaidi kusambaza maarifa kuhusu miundombinu na jinsi inavyofanya kazi kwa kutumia uhakiki wa kanuni:

Miundombinu inaelezewa na nambari kwenye ghala.
Mabadiliko hutokea katika tawi tofauti.
Wakati wa ombi la kuunganisha, unaweza kuona delta ya mabadiliko katika miundombinu.

Jambo kuu hapa lilikuwa kwamba wahakiki walichaguliwa mmoja mmoja, kulingana na ratiba, i.e. kwa kiwango fulani cha uwezekano utapanda kwenye kipande kipya cha miundombinu.

Mtindo wa Kanuni

Baada ya muda, squabbles zilianza kuonekana wakati wa ukaguzi, kwa sababu ... wakaguzi walikuwa na mtindo wao wenyewe na mzunguko wa wakaguzi uliziweka kwa mitindo tofauti: nafasi 2 au 4, Case ya ngamia au snake_case. Haikuwezekana kutekeleza hili mara moja.

Wazo la kwanza lilikuwa kupendekeza kutumia linter, baada ya yote, kila mtu ni mhandisi, kila mtu ni smart. Lakini wahariri tofauti, OS, sio rahisi
Hii ilibadilika kuwa bot ambayo iliandika kuteleza kwa kila ahadi yenye shida na kushikamana na matokeo ya linter. Lakini katika hali nyingi kulikuwa na mambo muhimu zaidi ya kufanya na nambari ilibaki bila kusuluhishwa.

Mwalimu wa Kujenga Kijani

Muda unapita, na tumefikia hitimisho kwamba ahadi ambazo hazipiti vipimo fulani haziwezi kuruhusiwa kwa bwana. Voila! Tulivumbua Green Build Master, ambayo imekuwa ikitekelezwa katika ukuzaji wa programu kwa muda mrefu:

Maendeleo yanaendelea katika tawi tofauti.
Majaribio yanaendelea kwenye uzi huu.
Ikiwa vipimo vinashindwa, msimbo hautaifanya kuwa bwana.

Kuchukua uamuzi huu ilikuwa chungu sana, kwa sababu ... ilisababisha mabishano mengi, lakini ilistahili, kwa sababu ... Mapitio yalianza kupokea maombi ya kuunganishwa bila tofauti katika mtindo, na baada ya muda idadi ya maeneo ya shida ilianza kupungua.

Uchunguzi wa IaC

Mbali na kuangalia mtindo, unaweza kutumia vitu vingine, kwa mfano, kuangalia ikiwa miundombinu yako inaweza kusambaza. Au angalia kuwa mabadiliko ya miundombinu hayatasababisha upotevu wa pesa. Kwa nini hii inaweza kuhitajika? Swali ni ngumu na la kifalsafa, ni bora kujibu kwa hadithi kwamba kwa namna fulani kulikuwa na kiboreshaji kiotomatiki kwenye Powershell ambacho hakikuangalia hali ya mipaka => VM nyingi ziliundwa kuliko inavyohitajika => mteja alitumia pesa zaidi kuliko ilivyopangwa. Hii haipendezi sana, lakini itawezekana kabisa kupata kosa hili katika hatua za awali.

Mtu anaweza kuuliza, kwa nini kufanya miundombinu tata hata ngumu zaidi? Majaribio ya miundombinu, kama tu ya msimbo, hayahusu kurahisisha, lakini kuhusu kujua jinsi miundombinu yako inapaswa kufanya kazi.

Piramidi ya Kupima IaC

Upimaji wa IaC: Uchambuzi Tuli

Ikiwa utapeleka miundombinu yote mara moja na uangalie ikiwa inafanya kazi, unaweza kupata kwamba inachukua muda mwingi na inahitaji muda mwingi. Kwa hivyo, msingi lazima uwe kitu kinachofanya kazi haraka, kuna mengi yake, na inashughulikia maeneo mengi ya zamani.

Bash ni gumu

Hebu tuangalie mfano usio na maana. chagua faili zote kwenye saraka ya sasa na unakili hadi eneo lingine. Jambo la kwanza linalokuja akilini:

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

Je, ikiwa kuna nafasi katika jina la faili? Kweli, sawa, sisi ni werevu, tunajua jinsi ya kutumia nukuu:

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

Umefanya vizuri? Hapana! Je, ikiwa hakuna kitu kwenye saraka, i.e. globbing haitafanya kazi.

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

Umefanya vizuri sasa? Hapana... Umesahau kinachoweza kuwa kwenye jina la faili n.

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

Zana za uchambuzi tuli

Shida kutoka kwa hatua ya awali inaweza kupatikana wakati tulisahau nukuu, kwa hili kuna tiba nyingi katika asili. Shellcheck, kwa ujumla kuna mengi yao, na uwezekano mkubwa unaweza kupata linter kwa stack yako chini ya IDE yako.

lugha
Chombo

bash
Shellcheck

Ruby
RuboCop

python
Mtungi

inayohusika
Ansible Lint

Jaribio la IaC: Majaribio ya Kitengo

Kama tulivyoona kutoka kwa mfano uliopita, linters sio nguvu zote na haziwezi kuashiria maeneo yote ya shida. Zaidi ya hayo, kwa kulinganisha na majaribio katika ukuzaji wa programu, tunaweza kukumbuka majaribio ya kitengo. Kinachokuja akilini mara moja ni shunit, juniti, rspec, pytest. Lakini nini cha kufanya na ansible, chef, saltstack na wengine kama wao?

Hapo mwanzo tulizungumza S.O.L.I.D. na kwamba miundombinu yetu iwe na matofali madogo. Wakati wao umefika.

Miundombinu imegawanywa katika matofali madogo, kwa mfano, majukumu ya Ansible.
Aina fulani ya mazingira yametumwa, iwe docker au VM.
Tunatumia jukumu letu Linalostahili kwa mazingira haya ya majaribio.
Tunaangalia kuwa kila kitu kilifanya kazi kama tulivyotarajia (tunaendesha vipimo).
Tunaamua sawa au si sawa.

Jaribio la IaC: Zana za Kupima Kitengo

Swali, vipimo vya CFM ni nini? Unaweza tu kuendesha hati, au unaweza kutumia suluhisho zilizotengenezwa tayari kwa hili:

CFM
Chombo

Inawezekana
Testinfra

Chef
Ukaguzi

Chef
Serverspec

chumvi
Pato

Mfano kwa testinfra, kuangalia kwamba watumiaji test1, test2 zipo na ziko kwenye kundi 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

Nini cha kuchagua? Swali ni ngumu na ngumu, hapa kuna mfano wa mabadiliko katika miradi kwenye github ya 2018-2019:

Mifumo ya Upimaji wa IaC

Swali linatokea: jinsi ya kuweka yote pamoja na kuzindua? Je! ichukue na uifanye mwenyewe ikiwa kuna idadi ya kutosha ya wahandisi. Au unaweza kuchukua suluhisho zilizotengenezwa tayari, ingawa hakuna nyingi sana:

CFM
Chombo

Inawezekana
molekuli

Chef
Jikoni ya Jaribio

Terraform
Terrates

Mfano wa mabadiliko katika miradi kwenye github ya 2018-2019:

Molekuli dhidi ya Jikoni ya mtihani

Awali sisi alijaribu kutumia testkitchen:

Unda VM sambamba.
Tekeleza majukumu Yanayofaa.
Endesha ukaguzi.

Kwa majukumu 25-35 ilifanya kazi dakika 40-70, ambayo ilikuwa ndefu.

Hatua iliyofuata ilikuwa mpito kwa jenkins/docker/ansible/molecule. Kiitikadi kila kitu ni sawa

Lint vitabu vya kucheza.
Panga majukumu.
Chombo cha uzinduzi
Tekeleza majukumu Yanayofaa.
Endesha testinfra.
Angalia kutokuwa na uwezo.

Kuweka majukumu 40 na majaribio kwa dazeni ilianza kuchukua kama dakika 15.

Nini cha kuchagua inategemea mambo mengi, kama vile stack kutumika, utaalamu katika timu, nk. hapa kila mtu anajiamulia jinsi ya kufunga swali la upimaji wa Kitengo

Upimaji wa IaC: Majaribio ya Ujumuishaji

Hatua inayofuata katika piramidi ya upimaji wa miundombinu itakuwa majaribio ya ujumuishaji. Zinafanana na vipimo vya kitengo:

Miundombinu imegawanywa katika matofali madogo, kwa mfano majukumu Ansible.
Aina fulani ya mazingira yametumwa, iwe docker au VM.
Kwa mazingira haya ya jaribio yanatumika nyingi Majukumu yanayofaa.
Tunaangalia kuwa kila kitu kilifanya kazi kama tulivyotarajia (tunaendesha vipimo).
Tunaamua sawa au si sawa.

Kwa kusema, hatuangalii utendaji wa kipengele cha mtu binafsi cha mfumo kama ilivyo katika majaribio ya vitengo, tunaangalia jinsi seva imesanidiwa kwa ujumla.

Jaribio la IaC: Mwisho hadi Mwisho wa Majaribio

Juu ya piramidi tunasalimiwa na vipimo vya End to End. Wale. Hatuangalii utendakazi wa seva tofauti, hati tofauti, au tofali tofauti la miundombinu yetu. Tunaangalia kama seva nyingi zimeunganishwa pamoja, miundombinu yetu inafanya kazi kama tunavyotarajia. Kwa bahati mbaya, sijawahi kuona suluhisho zilizotengenezwa tayari za sanduku, labda kwa sababu ... Miundombinu mara nyingi ni ya kipekee na ngumu kuorodhesha na kuunda mfumo wa majaribio. Matokeo yake, kila mtu anajenga ufumbuzi wao wenyewe. Kuna mahitaji, lakini hakuna jibu. Kwa hiyo, nitakuambia nini kuna ili kusukuma wengine kwa mawazo ya sauti au kusugua pua yangu kwa ukweli kwamba kila kitu kilizuliwa zamani kabla yetu.

Mradi wenye historia tajiri. Inatumika katika mashirika makubwa na labda kila mmoja wenu amevuka njia isiyo ya moja kwa moja nayo. Programu inasaidia hifadhidata nyingi, miunganisho, nk. Kujua jinsi miundombinu inaweza kuonekana ni faili nyingi za kutunga docker, na kujua ni majaribio gani ya kufanya katika mazingira gani Jenkins.

Mpango huu ulifanya kazi kwa muda mrefu, hadi ndani ya mfumo utafiti hatujajaribu kuhamisha hii kwa Openshift. Vyombo vinabaki vile vile, lakini mazingira ya uzinduzi yamebadilika (hello D.R.Y. tena).

Wazo la utafiti lilienda mbali zaidi, na katika mabadiliko ya wazi walipata kitu kama vile APB (Ansible Playbook Bundle), ambayo hukuruhusu kukusanya maarifa ya jinsi ya kupeleka miundombinu kwenye kontena. Wale. kuna ufahamu unaorudiwa, unaoweza kujaribiwa juu ya jinsi ya kupeleka miundombinu.

Yote haya yalisikika vizuri hadi tukaingia kwenye miundombinu tofauti: tulihitaji Windows kwa majaribio. Matokeo yake, ujuzi wa nini, wapi, jinsi ya kupeleka, na mtihani ni katika jenkins.

Hitimisho

Miundombinu kama Kanuni zilivyo

Kanuni katika hazina.
Mwingiliano wa kibinadamu.
Upimaji wa miundombinu.

viungo

Chanzo: mapenzi.com

Nilichojifunza kwa Kujaribu Laini 200 za Kanuni za Miundombinu