Tutaanzisha blogu yetu kwa machapisho kulingana na hotuba za hivi punde za mkurugenzi wetu wa kiufundi (Dmitry Stolyarov). Zote zilifanyika mnamo 2016 kwenye hafla tofauti za kitaalam na zilijitolea kwa mada ya DevOps na Docker. Video moja kutoka kwa mkutano wa Docker Moscow katika ofisi ya Badoo, tayari tunayo Mtandaoni. Mpya zitaambatana na makala zinazowasilisha kiini cha ripoti hizo. Hivyoβ¦
Mei 31 kwenye mkutano huo , iliyofanyika kama sehemu ya tamasha la "Teknolojia za Mtandao wa Urusi" (RIT++ 2016), sehemu ya "Usambazaji na Usambazaji Kuendelea" ilifunguliwa na ripoti "Mazoea Bora ya Uwasilishaji Unaoendelea na Docker". Ilifanya muhtasari na kuweka utaratibu wa mbinu bora za kuunda mchakato wa Uwasilishaji Endelevu (CD) kwa kutumia Doka na bidhaa zingine za Open Source. Tunafanya kazi na ufumbuzi huu katika uzalishaji, ambayo inaruhusu sisi kutegemea uzoefu wa vitendo.
Ikiwa una nafasi ya kutumia saa moja , tunapendekeza kuitazama kwa ukamilifu. Vinginevyo, chini ni muhtasari kuu katika fomu ya maandishi.
Uwasilishaji unaoendelea na Docker
Chini ya Uwasilishaji unaoendelea tunaelewa msururu wa matukio kama matokeo ambayo msimbo wa maombi kutoka kwenye hazina ya Git huja kwa uzalishaji, na kisha kuishia kwenye kumbukumbu. Anaonekana kama hii: Git β Jenga β Jaribio β Toa β Fanya kazi.
Ripoti nyingi zimetolewa kwa hatua ya uundaji (mkusanyiko wa maombi), na mada zinazotolewa na kuendeshwa zimeguswa kwa ufupi. Tutazungumzia kuhusu matatizo na mifumo ambayo inakuwezesha kutatua, na utekelezaji maalum wa mifumo hii inaweza kuwa tofauti.
Kwa nini Docker inahitajika hapa kabisa? Sio bure kwamba tuliamua kuzungumza juu ya mazoea ya Utoaji Unaoendelea katika muktadha wa zana hii ya Open Source. Ingawa ripoti nzima imejikita katika matumizi yake, sababu nyingi hufichuliwa wakati wa kuzingatia muundo mkuu wa utoaji wa msimbo wa programu.
Muundo mkuu wa uchapishaji
Kwa hivyo, tunapotoa matoleo mapya ya programu, hakika tunakabiliwa nayo tatizo la muda wa chini, iliyotolewa wakati wa kubadili seva ya uzalishaji. Trafiki kutoka kwa toleo la zamani la programu hadi mpya haiwezi kubadili mara moja: kwanza ni lazima tuhakikishe kwamba toleo jipya halijapakuliwa kwa ufanisi tu, bali pia "limeongezwa joto" (yaani, tayari kabisa kutumikia maombi).
Kwa hivyo, kwa muda matoleo yote mawili ya programu (ya zamani na mpya) yatafanya kazi wakati huo huo. Ambayo inaongoza kwa moja kwa moja mgongano wa rasilimali za pamoja: mtandao, mfumo wa faili, IPC, nk. Na Docker, tatizo hili linatatuliwa kwa urahisi kwa kuendesha matoleo tofauti ya programu katika vyombo tofauti, ambavyo kutengwa kwa rasilimali kunahakikishwa ndani ya seva pangishi sawa (seva/mashine pepe). Kwa kweli, unaweza kupata hila kadhaa bila insulation kabisa, lakini ikiwa kuna zana iliyotengenezwa tayari na inayofaa, basi kuna sababu tofauti - sio kuipuuza.
Uwekaji wa vyombo hutoa faida zingine nyingi wakati unatumwa. Programu yoyote inategemea toleo maalum (au anuwai ya toleo) mkalimani, upatikanaji wa moduli/viendelezi, n.k., pamoja na matoleo yao. Na hii inatumika si tu kwa mazingira ya haraka ya kutekelezwa, lakini pia kwa mazingira yote, ikiwa ni pamoja na programu ya mfumo na toleo lake (hadi usambazaji wa Linux unaotumika). Kutokana na ukweli kwamba vyombo vyenye msimbo wa maombi tu, lakini pia mfumo uliowekwa kabla na programu ya maombi ya matoleo yanayotakiwa, unaweza kusahau kuhusu matatizo na utegemezi.
Hebu tufanye muhtasari muundo kuu wa usambazaji matoleo mapya kwa kuzingatia mambo yafuatayo:
- Mara ya kwanza, toleo la zamani la programu linaendesha kwenye chombo cha kwanza.
- Toleo jipya kisha linatolewa na "kupashwa moto" kwenye chombo cha pili. Ni vyema kutambua kwamba toleo hili jipya lenyewe linaweza kubeba sio tu msimbo wa maombi uliosasishwa, lakini pia utegemezi wake wowote, pamoja na vipengele vya mfumo (kwa mfano, toleo jipya la OpenSSL au usambazaji mzima).
- Wakati toleo jipya liko tayari kuwasilisha maombi, trafiki hubadilika kutoka kwa kontena la kwanza hadi la pili.
- Toleo la zamani sasa linaweza kusimamishwa.
Njia hii ya kupeleka matoleo tofauti ya programu katika vyombo tofauti hutoa urahisi mwingine - urejeshaji wa haraka kwa toleo la zamani (baada ya yote, inatosha kubadili trafiki kwenye chombo kinachohitajika).
Pendekezo la mwisho la kwanza linasikika kama jambo ambalo hata Kapteni hakuweza kupata kosa: "[wakati wa kupanga Uwasilishaji Unaoendelea na Docker] Tumia Docker [na kuelewa inatoa]" Kumbuka, hii sio risasi ya fedha ambayo itasuluhisha kila shida, lakini chombo ambacho hutoa msingi mzuri.
Uzalishaji tena
Kwa "kuzalisha tena" tunamaanisha seti ya jumla ya matatizo yanayopatikana wakati wa kufanya kazi kwa programu. Tunazungumza juu ya kesi kama hizi:
- Hati zilizokaguliwa na idara ya ubora kwa ajili ya uandaaji lazima zitolewe tena kwa usahihi katika uzalishaji.
- Maombi huchapishwa kwenye seva ambazo zinaweza kupokea vifurushi kutoka kwa vioo tofauti vya kumbukumbu (baada ya muda zinasasishwa, na pamoja nao matoleo ya programu zilizosakinishwa).
- "Kila kitu kinanifanyia kazi ndani ya nchi!" (...na watengenezaji hawaruhusiwi katika uzalishaji.)
- Unahitaji kuangalia kitu katika toleo la zamani (lililohifadhiwa).
- ...
Kiini chao cha jumla kinapungua kwa ukweli kwamba kufuata kamili kwa mazingira yaliyotumiwa (pamoja na kutokuwepo kwa sababu ya kibinadamu) ni muhimu. Je, tunawezaje kuhakikisha uzalishwaji tena? Tengeneza picha za Docker kulingana na msimbo kutoka kwa Git, na kisha uitumie kwa kazi yoyote: kwenye maeneo ya mtihani, katika uzalishaji, kwenye mashine za mitaa za waandaaji wa programu ... Wakati huo huo, ni muhimu kupunguza vitendo vinavyofanyika. baada ya kukusanya picha: ni rahisi zaidi, kuna uwezekano mdogo wa makosa.
Miundombinu ni kanuni
Ikiwa mahitaji ya miundombinu (upatikanaji wa programu ya seva, toleo lake, n.k.) hayajarasimishwa na "yamepangwa," basi uchapishaji wa sasisho lolote la programu unaweza kusababisha matokeo mabaya. Kwa mfano, katika utayarishaji tayari umebadilisha hadi PHP 7.0 na kuandika upya nambari ipasavyo - basi kuonekana kwake katika uzalishaji na PHP ya zamani (5.5) hakika kutashangaza mtu. Huenda usisahau kuhusu mabadiliko makubwa katika toleo la mkalimani, lakini "shetani yuko katika maelezo": mshangao unaweza kuwa katika sasisho ndogo la utegemezi wowote.
Mbinu ya kutatua tatizo hili inajulikana kama IaC (Miundombinu kama Kanuni, "miundombinu kama kanuni") na inahusisha kuhifadhi mahitaji ya miundombinu pamoja na msimbo wa maombi. Kwa kuitumia, watengenezaji na wataalamu wa DevOps wanaweza kufanya kazi na hazina sawa ya programu ya Git, lakini kwa sehemu tofauti zake. Kutoka kwa nambari hii, picha ya Docker imeundwa katika Git, ambayo maombi hutumwa kwa kuzingatia maelezo yote ya miundombinu. Kwa ufupi, hati (kanuni) za kukusanya picha zinapaswa kuwa kwenye hazina moja na msimbo wa chanzo na kuunganishwa pamoja.
Katika kesi ya usanifu wa maombi ya safu nyingi - kwa mfano, kuna nginx, ambayo inasimama mbele ya programu tayari inayoendesha ndani ya chombo cha Docker - Picha za Docker lazima ziundwe kutoka kwa msimbo katika Git kwa kila safu. Kisha picha ya kwanza itakuwa na programu iliyo na mkalimani na vitegemezi vingine vya "karibu", na picha ya pili itakuwa na nginx ya juu.
Picha za Docker, mawasiliano na Git
Tunagawanya picha zote za Docker zilizokusanywa kutoka Git katika makundi mawili: ya muda na ya kutolewa. Picha za muda iliyotambulishwa kwa jina la tawi katika Git, inaweza kubatilishwa kwa ahadi inayofuata na inatolewa kwa hakikisho tu (sio kwa uzalishaji). Hii ndio tofauti yao kuu kutoka kwa zile za kutolewa: haujui ni ahadi gani maalum iliyo ndani yao.
Ni mantiki kukusanya katika picha za muda: tawi kuu (unaweza kuipeleka moja kwa moja kwenye tovuti tofauti ili kuona mara kwa mara toleo la sasa la bwana), matawi yenye matoleo, matawi ya ubunifu maalum.
Baada ya hakikisho la picha za muda huja kwa hitaji la tafsiri katika uzalishaji, watengenezaji huweka lebo fulani. Imekusanywa kiotomatiki kwa lebo picha ya kutolewa (lebo yake inalingana na tepe kutoka kwa Git) na imetolewa kwa hatua. Ikiwa imethibitishwa kwa ufanisi na idara ya ubora, huenda kwa uzalishaji.
dapp
Kila kitu kilichoelezwa (usambazaji, mkusanyiko wa picha, matengenezo ya baadaye) yanaweza kutekelezwa kwa kujitegemea kwa kutumia maandishi ya Bash na zana zingine "zilizoboreshwa". Lakini ikiwa utafanya hivyo, basi wakati fulani utekelezaji utasababisha utata mkubwa na udhibiti mbaya. Kwa kuelewa hili, tulikuja kuunda matumizi yetu maalum ya Workflow kwa ajili ya kujenga CI/CD - dapp.
Nambari yake ya chanzo imeandikwa kwa Ruby, chanzo wazi na kuchapishwa . Kwa bahati mbaya, hati kwa sasa ndio sehemu dhaifu zaidi ya zana, lakini tunaifanyia kazi. Na tutaandika na kuzungumza juu ya dapp zaidi ya mara moja, kwa sababu ... Hatuwezi kusubiri kwa dhati kushiriki uwezo wake na jumuiya nzima inayovutiwa, lakini kwa wakati huu, tuma masuala yako na kuvuta maombi na/au ufuate maendeleo ya mradi kwenye GitHub.
Ilisasishwa tarehe 13 Agosti 2019: kwa sasa ni mradi dapp imebadilishwa jina kuwa , msimbo wake umeandikwa upya kabisa katika Go, na hati zake zimeboreshwa kwa kiasi kikubwa.
Mabernet
Chombo kingine kilicho tayari cha Open Source ambacho tayari kimepokea kutambuliwa muhimu katika mazingira ya kitaaluma ni Mabernet, nguzo ya usimamizi wa Docker. Mada ya matumizi yake katika uendeshaji wa miradi iliyojengwa kwenye Docker ni zaidi ya upeo wa ripoti, hivyo uwasilishaji ni mdogo kwa muhtasari wa baadhi ya vipengele vya kuvutia.
Kwa uchapishaji, Kubernetes inatoa:
- uchunguzi wa utayari - kuangalia utayari wa toleo jipya la programu (kubadilisha trafiki kwake);
- sasisho la kusonga - sasisho la picha la mlolongo katika kundi la vyombo (kuzima, sasisha, maandalizi ya uzinduzi, ubadilishaji wa trafiki);
- sasisho la synchronous - kusasisha picha katika nguzo na mbinu tofauti: kwanza kwenye nusu ya vyombo, kisha kwa wengine;
- matoleo ya canary - kuzindua picha mpya kwenye idadi ndogo (ndogo) ya vyombo ili kufuatilia hitilafu.
Kwa kuwa Utoaji Unaoendelea sio tu kutolewa kwa toleo jipya, Kubernetes ina uwezo kadhaa wa matengenezo ya miundombinu inayofuata: ufuatiliaji uliojengwa ndani na ukataji miti kwa vyombo vyote, kuongeza kiotomatiki, n.k. Yote haya tayari yanafanya kazi na inangojea tu sahihi. utekelezaji katika michakato yako.
Mapendekezo ya mwisho
- Tumia Docker.
- Unda picha za Docker za programu kwa mahitaji yako yote.
- Fuata kanuni "Miundombinu ni kanuni."
- Unganisha Git kwa Docker.
- Dhibiti mpangilio wa uchapishaji.
- Tumia jukwaa lililotengenezwa tayari (Kubernetes au lingine).
Video na slaidi
Video kutoka kwa utendaji (takriban saa moja) (ripoti yenyewe inaanza kutoka dakika ya 5 - fuata kiungo ili kucheza kutoka wakati huu).
Uwasilishaji wa ripoti:
PS
Ripoti zingine juu ya mada kwenye blogi yetu:
- «» (Dmitry Stolyarov; Mei 27, 2019 katika DevOpsConf);
- «» (Dmitry Stolyarov; Novemba 8, 2018 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Novemba 7, 2017 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 katika RootConf).
Chanzo: mapenzi.com