Blogun tonĂ« do ta fillojmĂ« me publikimet e krijuara mbi bazĂ«n e paraqitjeve mĂ« tĂ« fundit tĂ« drejtorit tonĂ« teknik (Dmitri Stolyarov). TĂ« gjitha kĂ«to ndodhĂ«n nĂ« vitin 2016 nĂ« ngjarje tĂ« ndryshme profesionale dhe ishin tĂ« dedikuara temĂ«s sĂ« DevOps dhe Docker. NjĂ« video, nga takimi Docker Moscow nĂ« zyrĂ«n e Badoo, ne tashmĂ« nĂ« faqen tonĂ«. TĂ« rejat do tĂ« shoqĂ«rohen me artikuj qĂ« pĂ«rcjellin thelbin e paraqitjeve. PraâŠ
Një maj, në konferencën , e cila u zhvillua në kuadër të festivalit "Teknologjitë internetore të Rusisë" (RIT++ 2016), sesioni "Implementimi dhe deployi i vazhdueshëm" u hap me paraqitjen "Practikat më të mira të Continuous Delivery me Docker". Në të u përmbledhën dhe sistematizuan praktikat më të mira për ndërtimin e procesit të Continuous Delivery (CD) duke përdorur Docker dhe produkte të tjera Open Source. Me këto zgjidhje ne punojmë në production, duke na lejuar të mbështetemi në përvojën praktike.
NĂ«se keni mundĂ«si tĂ« kaloni njĂ« orĂ« pĂ«r , rekomandojmĂ« ta shikoni tĂ« tĂ«rĂ«. Ndryshe â mĂ« poshtĂ« Ă«shtĂ« pĂ«rmbledhja kryesore nĂ« formĂ« tekstuale.
Continuous Delivery me Docker
NĂ«n Continuous Delivery ne e kuptojmĂ« zinxhirin e aktiviteteve, nĂ« rezultat tĂ« cilave kodi i aplikacionit nga depoja Git fillimisht pĂ«rfundon nĂ« production dhe pastaj nĂ« arkiv. ĂshtĂ« si mĂ« poshtĂ«: Git â Build (ndĂ«rtimi) â Test (testimi) â Release (çlirimi) â Operate (mbikĂ«qyrja).
Pjesa më e madhe e raportit i kushtohet fazës së ndërtimit (ndërtimi i aplikacionit), ndërsa temat e çlirimit dhe operimit përmenden përmbledhtas. Do të flasim për problemet dhe modelët që lejojnë zgjidhjen e tyre, ndërsa realizimet specifike të këtyre modeleve mund të jenë të ndryshme.
Pse na nevojitet Docker? Nuk jemi vetëm për t'u folur për praktikat e Continuous Delivery në kontekstin e këtij mjeti Open Source. Edhe pse e gjithë kjo prezantohet në referat, shumë arsye shpalosen që në shqyrtimin e modelit kryesor për lëshimin e kodit të aplikacionit.
Modeli kryesor për lëshim
Pra, kur lëshojmë versionet e reja të aplikacionit, ne pa dyshim përballemi me problemin e ndaljes, që formohet gjatë kalimit të serverit të prodhimit. Trafiku nga versioni i vjetër i aplikacionit në atë të ri nuk mund të kalojë menjëherë: duhet të sigurohemi paraprakisht që versioni i ri jo vetëm të jetë ngarkuar me sukses, por gjithashtu të jetë "ngrohur" (dmth. komplet i gatshëm për të shërbyer kërkesave).
NĂ« kĂ«tĂ« mĂ«nyrĂ«, pĂ«r njĂ«farĂ« kohe tĂ« dy versionet e aplikacionit (i vjetĂ«r dhe i ri) do tĂ« funksionojnĂ« njĂ«kohĂ«sisht. Kjo automatikisht shkakton konflikt tĂ« burimeve tĂ« pĂ«rbashkĂ«ta: rrjetit, sistemit tĂ« skedarĂ«ve, IPC etj. Me Docker, ky problem zgjidhet lehtĂ«sisht duke nisur versione tĂ« ndryshme tĂ« aplikacionit nĂ« konteinerĂ« tĂ« ndarĂ«, pĂ«r tĂ« cilĂ«t garantohen izolimi i burimeve brenda njĂ« hosti (server/machine virtuale). Sigurisht, Ă«shtĂ« e mundur tĂ« kalosh edhe pa izolim fare, por nĂ«se ekziston njĂ« mjet i gatshĂ«m dhe tĂ«rheqĂ«s, ka edhe njĂ« arsyetim tĂ« kundĂ«rt â mos e injoroni atĂ«.
Kontenizimi ofron shumĂ« pĂ«rfitime tĂ« tjera kur bĂ«het fjalĂ« pĂ«r deploy. Ădo aplikacion varet nga njĂ« version tĂ« caktuar (apo njĂ« interval versionesh) tĂ« interpretuesit, disponueshmĂ«risĂ« sĂ« moduleve/ekspansionit etj., si dhe tĂ« versioneve tĂ« tyre. Kjo i pĂ«rket jo vetĂ«m mjedisit tĂ« drejtpĂ«rdrejtĂ« tĂ« ekzekutimit, por edhe gjithĂ« ambientit pĂ«rfshirĂ« softi sistemor dhe versionet e tij (deri nĂ« distribucionin Linux qĂ« pĂ«rdoret). Duke pasur parasysh se kontejnerĂ«t pĂ«rmbajnĂ« jo vetĂ«m kodin e aplikacioneve, por gjithashtu softin sistemor dhe aplikativ tĂ« instaluar paraprakisht me versionet e nevojshme, mund tĂ« harrohen problemet me varĂ«sitĂ«.
Le të përgjithësojmë patternin kryesor të lançimit të versioneve të reja duke marrë parasysh faktorët e përmendur:
- Së pari, versioni i vjetër i aplikacionit punon në kontejnerin e parë.
- Pastaj, versi i ri lancohet dhe "ngrohet" nĂ« kontejnerin e dytĂ«. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se ky version i ri mund tĂ« pĂ«rmbajĂ« jo vetĂ«m kodin e pĂ«rditĂ«suar tĂ« aplikacionit, por gjithashtu varĂ«sitĂ« e tij dhe komponentĂ«t sistemorĂ« (pĂ«r shembull, njĂ« version tĂ« ri tĂ« OpenSSL ose tĂ« gjithĂ« distribucionit).
- Kur versioni i ri është plotësisht i gatshëm për të përpunuar kërkesat, trafiku kalon nga kontejneri i parë në të dytin.
- Tani, versioni i vjetër mund të ndalet.
Ky kyqje i shpĂ«rndarjes sĂ« versioneve tĂ« ndryshme tĂ« aplikacionit nĂ« konteinerĂ« tĂ« veçantĂ« ofron njĂ« avantazh tjetĂ«r â rrethit tĂ« shpejtĂ« nĂ« versionin e vjetĂ«r (mjafton tĂ« kalosh trafikun nĂ« konteinerin e duhur).
Rekomandimi i parë përfundimtar është i tillë, që as Kapitani nuk mund ta kritikojë: "[kur organizoni Continuous Delivery me Docker] Përdorni Docker [dhe kuptoni se çfarë ofron]". Mos harroni se kjo nuk është një "plumb argjendi", që zgjidh çdo problem, por një instrument që ofron një themel të shkëlqyer.
Riprodhueshmëria
Me "riprodhueshmëri" kuptojmë një grup të përbashkët problemesh me të cilat përballen gjatë operimit të aplikacioneve. Po flasim për raste të tilla si:
- Skenaret e verifikuara nga departamenti i cilësisë në staging duhet të riprodhohen saktësisht në prodhim.
- Aplikacionet publikohen nĂ« serverĂ« qĂ« mund tĂ« marrin paketa nga pasqyrat e ndryshme tĂ« repositorĂ«ve (me kalimin e kohĂ«s, ato pĂ«rditĂ«sohen dhe bashkĂ« me to â edhe versionet e aplikacioneve tĂ« instaluara).
- "Mua lokalisht gjithçka funksionon!" (⊠dhe zhvilluesit nuk lejohet të hyjnë në prodhim.)
- Kërkohet të verifikohet diçka në versionin e vjetër (arkivor).
- âŠ
The essence of it all is that there must be complete compliance of the environments used (as well as the absence of human factors). How can reproducibility be guaranteed? Create Docker images based on code from Git, and then use them for any tasks: on testing sites, in production, on local developer machines... It's important to minimize the actions performed pas during image assembly: the simpler, the lower the probability of errors.
Infrastructure is code
If the requirements for infrastructure (availability of server software, its versions, etc.) are not formalized and 'programmed', deploying any application update can end with unfortunate consequences. For example, if you have already transitioned to PHP 7.0 on staging and rewritten the code accordingly â its appearance on production with some old PHP (5.5) will undoubtedly surprise someone. While you may not forget about a major change in interpreter versions, 'the devil is in the details': the surprise may arise from a minor update of any dependency.
The approach that addresses this issue is known as IaC (Infrastructure as Code) dhe parashikon ruajtjen e kërkesave për infrastrukturën së bashku me kodin e aplikacionit. Me përdorimin e tij, zhvilluesit dhe specialistët DevOps mund të punojnë me një depot Git të aplikacionit, por mbi pjesë të ndryshme të tij. Nga ky kod në Git krijohet një imazh Docker, në të cilin aplikacioni është vendosur duke marrë parasysh të gjitha specifikat e infrastrukturës. Thënë ndryshe, skenaret (rregullat) për ndërtimin e imazheve duhet të jenë në të njëjtën depo me burimet dhe të bashkohen së bashku.
NĂ« rastin e arkitekturĂ«s shumĂ«planĂ«she tĂ« aplikacionit â pĂ«r shembull, kur ka nginx qĂ« qĂ«ndron para aplikacionit, i cili tashmĂ« Ă«shtĂ« hapur brenda kontejnerit Docker â imazhet Docker duhet tĂ« krijohen nga kodi nĂ« Git pĂ«r çdo shtresĂ«. KĂ«shtu, nĂ« imazhin e parĂ« do tĂ« jetĂ« aplikacioni me interpretorin dhe varĂ«sitĂ« e tjera 'mĂ« tĂ« afĂ«rta', ndĂ«rsa nĂ« tĂ« dytin â nginx-i mĂ« i lartĂ«.
Imazhet Docker, lidhja me Git
Të gjitha imazhet Docker, që krijohen nga Git, ne i ndajnë në dy kategori: përkohshme dhe lëshime. Imazhet përkohshme etiketohen sipas emrit të degës në Git, mund të shkruhen përsëri me një angazhim të ri dhe publikohen vetëm për shikim paraprak (jo për prodhim). Kjo është dallimi i tyre kryesor nga versionet: ju kurrë nuk e dini se cili angazhim konkret ndodhet në to.
Ka kuptim të mblidhen në imazhe përkohshme: dega master (mund të publikohet automatikisht në një ambient të veçantë për të parë vazhdimisht versionin aktual të master), degët me versione, degët e risive specifike.
Pasi shikimi paraprak i imazheve të përkohshme arrin nevojën për të kaluar në prodhim, zhvilluesit vendosin një etiketë specifike. Në bazë të etiketës, mblidhen automatikisht imazhi i versionit (etiketa e tij i përgjigjet etiketës në Git) dhe publikohet në staging. Nëse kalon me sukses kontrollin nga departamenti i cilësisë, ai shkon në prodhim.
dapp
Ădo gjĂ« e pĂ«rshkruar (implementimi, ndĂ«rtimi i imazheve, mbĂ«shtetje e mĂ«vonshme) mund tĂ« realizohet nĂ« mĂ«nyrĂ« tĂ« pavarur pĂ«rmes skripteve Bash dhe mjeteve tĂ« tjera "tĂ« lehta". Por nĂ«se e bĂ«ni kĂ«shtu, nĂ« njĂ« moment implementimi do tĂ« çojĂ« nĂ« njĂ« kompleksitet tĂ« madh dhe menaxhim tĂ« keq. Duke e kuptuar kĂ«tĂ«, ne erdhĂ«m nĂ« krijimin e utilitarit tonĂ« tĂ« specializuar pĂ«r Workflow pĂ«r ndĂ«rtimin e CI/CD â dapp.
Kodi i saj burimor është shkruar në Ruby, i hapur dhe i publikuar në . Fatkeqësisht, dokumentacioni në këtë moment është pika më e dobët e mjetit, por ne po punojmë mbi këtë. Dhe ne do të shkruajmë dhe tregojmë më shumë për dapp, sepse ne me sinqeritet mezi presim të ndajmë mundësitë e tij me tërë komunitetin e interesuar, për momentin dërgoni problemet dhe kërkesat tuaja dhe/ose ndiqni zhvillimin e projektit në GitHub.
E rinovuar më 13 gusht 2019: aktualisht projekti dapp është ripërkufizuar në , kodi i tij është shkruar plotësisht në Go, dhe dokumentacioni është përmirësuar ndjeshëm.
Kubernetes
Një tjetër mjet i gatshëm Open Source, që tashmë ka marrë njohje të konsiderueshme në mjedisin profesional, është Kubernetes, një kluster për menaxhimin e Docker. Tema e përdorimit të tij në eksploatimin e projekteve të ndërtuara mbi Docker kalon përtej kësaj paraqitjeje, prandaj ligjërata është e kufizuar në një përmbledhje të disa mundësive interesante.
PĂ«r versionimin, Kubernetes ofron:
- readiness probe â kontrollimin e gatishmĂ«risĂ« sĂ« versionit tĂ« ri tĂ« aplikacionit (pĂ«r tĂ« kaluar trafikun mbi tĂ«);
- rolling update â pĂ«rditĂ«simi i njĂ«pasnjĂ«shĂ«m i imazhit nĂ« klasterin e kontejnerĂ«ve (ndalimi, pĂ«rditĂ«simi, pĂ«rgatitja pĂ«r nisje, kalimi i trafikut);
- synchronous update â pĂ«rditĂ«simi i imazhit nĂ« klaster me njĂ« qasje tjetĂ«r: fillimisht nĂ« gjysmĂ« tĂ« kontejnerĂ«ve, pastaj tek tĂ« tjerĂ«t;
- canary releases â lançimi i njĂ« imazhi tĂ« ri nĂ« njĂ« numĂ«r tĂ« kufizuar (tĂ« vogĂ«l) kontejnerĂ«sh pĂ«r monitorimin e anomali.ve.
Dhe për shkak se Continuous Delivery nuk është vetëm lëshimi i një versioni të ri, Kubernetes ka një sërë mundësish për mbështetje të mëtejshme të infrastrukturës: monitorim të integruar dhe regjistrim për të gjithë kontejnerët, automatizimi i shkallëzimit dhe më shumë. Gjithçka kjo tashmë funksionon dhe pret vetëm zbatimin e mençur në proceset tuaja.
Rekomandimet përfundimtare
- PĂ«rdorni Docker.
- Krijoni imazhe Docker për aplikacionin për të gjitha nevojat.
- Dijeni parimin «Infrastruktura është kod».
- Lidhni Git me Docker.
- Rregulloni procesin e publikimit.
- Përdorni një platformë të gatshme (Kubernetes ose ndonjë tjetër).
Video dhe prezentime
Video nga prezantimi (rreth njĂ« ore) (prezantimi fillon nĂ« minutĂ«n e 5-tĂ« â ndiqni linkun pĂ«r ta luajtur nga ky moment).
Prezantimi i referatit:
P.S.
Të tjera prezantime mbi këtë temë në blogun tonë:
- «» (Dmitry Stolyarov; 27 maj 2019 në DevOpsConf);
- «» (Dmitri Stolyarov; 8 Nëntor 2018 në HighLoad++);
- «» (Dmitri Stolyarov; 7 Nëntor 2017 në HighLoad++);
- «» (Dmitri Stolyarov; 6 qershor 2017 në RootConf).
Burimi: habr.com
