Ne do të fillojmë blogun tonë me botime të bazuara në fjalimet e fundit të drejtorit tonë teknik (Dmitry Stolyarov). Të gjitha ato u zhvilluan në vitin 2016 në ngjarje të ndryshme profesionale dhe iu kushtuan temës së DevOps dhe Docker. Një video nga takimi i Docker Moscow në zyrën e Badoo, ne kemi tashmë Online. Të rejat do të shoqërohen me artikuj që përcjellin thelbin e raporteve. Kështu që…
31 maj në konferencë , i mbajtur në kuadër të festivalit “Teknologjitë Ruse të Internetit” (RIT++ 2016), seksioni “Dislokimi dhe vendosja e vazhdueshme” u hap me raportin “Praktikat më të mira të dorëzimit të vazhdueshëm me Docker”. Ai përmblodhi dhe sistemoi praktikat më të mira për ndërtimin e një procesi të shpërndarjes së vazhdueshme (CD) duke përdorur Docker dhe produkte të tjera me burim të hapur. Ne punojmë me këto zgjidhje në prodhim, gjë që na lejon të mbështetemi në përvojën praktike.
Nëse keni mundësi të kaloni një orë , ju rekomandojmë ta shikoni të plotë. Përndryshe, më poshtë është përmbledhja kryesore në formë teksti.
Dorëzimi i vazhdueshëm me Docker
Nën Dorëzimi i vazhdueshëm ne kuptojmë zinxhirin e ngjarjeve si rezultat i të cilave kodi i aplikacionit nga depoja Git fillimisht vjen në prodhim, dhe më pas përfundon në arkiv. Duket kështu: Git → Build → Test → Release → Operate.
Pjesa më e madhe e raportit i kushtohet fazës së ndërtimit (montimi i aplikacionit), dhe temat e lëshimit dhe funksionimit janë prekur shkurtimisht. Ne do të flasim për problemet dhe modelet që ju lejojnë t'i zgjidhni ato, dhe zbatimet specifike të këtyre modeleve mund të jenë të ndryshme.
Pse është i nevojshëm Docker këtu? Jo më kot vendosëm të flasim për praktikat e shpërndarjes së vazhdueshme në kontekstin e këtij mjeti me burim të hapur. Megjithëse i gjithë raporti i kushtohet përdorimit të tij, shumë arsye zbulohen kur merret parasysh modeli kryesor i paraqitjes së kodit të aplikacionit.
Modeli kryesor i paraqitjes
Pra, kur nxjerrim versione të reja të aplikacionit, sigurisht që përballemi problemi i joproduktive, i krijuar gjatë ndërrimit të serverit të prodhimit. Trafiku nga versioni i vjetër i aplikacionit në të riun nuk mund të kalojë menjëherë: së pari duhet të sigurohemi që versioni i ri jo vetëm të shkarkohet me sukses, por edhe të "ngrohet" (d.m.th., plotësisht i gatshëm për të shërbyer kërkesa).
Kështu, për ca kohë të dy versionet e aplikacionit (i vjetër dhe i ri) do të funksionojnë njëkohësisht. Që çon automatikisht në konflikti i burimeve të përbashkëta: rrjeti, sistemi i skedarëve, IPC, etj. Me Docker, ky problem zgjidhet lehtësisht duke ekzekutuar versione të ndryshme të aplikacionit në kontejnerë të veçantë, për të cilët izolimi i burimeve është i garantuar brenda të njëjtit host (server/makinë virtuale). Sigurisht, mund t'ia dilni me disa truke pa izolim fare, por nëse ekziston një mjet i gatshëm dhe i përshtatshëm, atëherë ekziston arsyeja e kundërt - të mos e neglizhoni.
Kontejnerizimi ofron shumë përfitime të tjera kur vendoset. Çdo aplikim varet nga version specifik (ose diapazoni i versionit) përkthyes, disponueshmëria e moduleve/ekstensioneve, etj., si dhe versionet e tyre. Dhe kjo vlen jo vetëm për mjedisin e menjëhershëm të ekzekutueshëm, por edhe për të gjithë mjedisin, duke përfshirë softuerin e sistemit dhe versionin e tij (deri në shpërndarjen Linux të përdorur). Për shkak të faktit se kontejnerët përmbajnë jo vetëm kodin e aplikacionit, por edhe sistemin e para-instaluar dhe softuerin e aplikacionit të versioneve të kërkuara, mund të harroni problemet me varësitë.
Le të përgjithësojmë modeli kryesor i paraqitjes versionet e reja duke marrë parasysh faktorët e mëposhtëm:
- Në fillim, versioni i vjetër i aplikacionit funksionon në kontejnerin e parë.
- Versioni i ri më pas hapet dhe "ngrohet" në një enë të dytë. Vlen të përmendet se vetë ky version i ri mund të mbajë jo vetëm kodin e përditësuar të aplikacionit, por edhe ndonjë nga varësitë e tij, si dhe komponentët e sistemit (për shembull, një version i ri i OpenSSL ose të gjithë shpërndarjen).
- Kur versioni i ri është plotësisht gati për të shërbyer kërkesa, trafiku kalon nga kontejneri i parë në të dytin.
- Versioni i vjetër tani mund të ndalet.
Kjo qasje e vendosjes së versioneve të ndryshme të aplikacionit në kontejnerë të veçantë ofron një lehtësi tjetër - rikthim i shpejtë në versionin e vjetër (në fund të fundit, mjafton të kaloni trafikun në kontejnerin e dëshiruar).
Rekomandimi i parë i fundit tingëllon si diçka që as Kapiteni nuk mund ta gjente fajin: "[kur organizoni dorëzim të vazhdueshëm me Docker] Përdorni Docker [dhe kuptoni se çfarë jep]" Mos harroni, ky nuk është një plumb argjendi që do të zgjidhë çdo problem, por një mjet që ofron një bazë të mrekullueshme.
Riprodhueshmëria
Me "riprodhueshmëri" nënkuptojmë një grup të përgjithësuar problemesh që hasen gjatë funksionimit të aplikacioneve. Po flasim për raste të tilla:
- Skriptet e kontrolluara nga departamenti i cilësisë për vënien në skenë duhet të riprodhohen me saktësi në prodhim.
- Aplikacionet publikohen në serverë që mund të marrin paketa nga pasqyra të ndryshme të depove (me kalimin e kohës ato përditësohen dhe bashkë me to edhe versionet e aplikacioneve të instaluara).
- "Gjithçka funksionon për mua në vend!" (...dhe zhvilluesit nuk lejohen në prodhim.)
- Duhet të kontrolloni diçka në versionin e vjetër (të arkivuar).
- ...
Thelbi i tyre i përgjithshëm qëndron në faktin se është e nevojshme përputhja e plotë e mjediseve të përdorura (si dhe mungesa e faktorit njerëzor). Si mund të garantojmë riprodhueshmëri? Bëni imazhe Docker bazuar në kodin nga Git, dhe më pas t'i përdorësh për çdo detyrë: në vendet e testimit, në prodhim, në makinat lokale të programuesve... Njëkohësisht, është e rëndësishme të minimizohen veprimet që kryhen. pas montimi i imazhit: sa më i thjeshtë të jetë, aq më pak ka gjasa të ketë gabime.
Infrastruktura është kod
Nëse kërkesat e infrastrukturës (disponueshmëria e softuerit të serverit, versioni i tij, etj.) nuk janë zyrtarizuar dhe "programuar", atëherë vendosja e çdo përditësimi aplikacioni mund të rezultojë në pasoja katastrofike. Për shembull, në skenë ju keni kaluar tashmë në PHP 7.0 dhe keni rishkruar kodin në përputhje me rrethanat - atëherë shfaqja e tij në prodhim me disa PHP të vjetër (5.5) sigurisht që do të befasojë dikë. Ju nuk mund të harroni për një ndryshim të madh në versionin e përkthyesit, por "djalli është në detaje": surpriza mund të jetë në një përditësim të vogël të çdo varësie.
Një qasje për të zgjidhur këtë problem njihet si IaC (Infrastruktura si kod, "infrastruktura si kod") dhe përfshin ruajtjen e kërkesave të infrastrukturës së bashku me kodin e aplikacionit. Duke e përdorur atë, zhvilluesit dhe specialistët e DevOps mund të punojnë me të njëjtin depo të aplikacionit Git, por në pjesë të ndryshme të tij. Nga ky kod, krijohet një imazh Docker në Git, në të cilin aplikacioni vendoset duke marrë parasysh të gjitha specifikat e infrastrukturës. E thënë thjesht, skriptet (rregullat) për montimin e imazheve duhet të jenë në të njëjtin depo me kodin burimor dhe të bashkohen së bashku.
Në rastin e një arkitekture aplikacioni me shumë shtresa - për shembull, ekziston nginx, i cili qëndron përballë një aplikacioni që tashmë funksionon brenda një kontejneri Docker - Imazhet e Docker duhet të krijohen nga kodi në Git për secilën shtresë. Pastaj imazhi i parë do të përmbajë një aplikacion me një përkthyes dhe varësi të tjera "të afërta", dhe imazhi i dytë do të përmbajë nginx në rrjedhën e sipërme.
Imazhet e dokerit, komunikimi me Git
Ne i ndajmë të gjitha imazhet Docker të mbledhura nga Git në dy kategori: të përkohshme dhe të lëshuara. Imazhe të përkohshme etiketuar me emrin e degës në Git, mund të mbishkruhen nga kryerja e radhës dhe shpërndahen vetëm për pamje paraprake (jo për prodhim). Ky është ndryshimi i tyre kryesor nga ato të lëshimit: kurrë nuk e dini se cili angazhim specifik është në to.
Ka kuptim të grumbullohen në imazhe të përkohshme: dega kryesore (mund ta hapni automatikisht në një faqe të veçantë për të parë vazhdimisht versionin aktual të masterit), degët me lëshime, degë të risive specifike.
Pasi paraqitja paraprake e imazheve të përkohshme vjen tek nevoja për përkthim në prodhim, zhvilluesit vendosin një etiketë të caktuar. Mbledhur automatikisht sipas etiketës imazhin e lëshimit (etiketa e tij korrespondon me etiketën nga Git) dhe shtrihet në skenë. Nëse verifikohet me sukses nga departamenti i cilësisë, shkon në prodhim.
DAPP
Gjithçka e përshkruar (shfaqja, montimi i imazhit, mirëmbajtja pasuese) mund të zbatohet në mënyrë të pavarur duke përdorur skriptet Bash dhe mjete të tjera "të improvizuara". Por nëse e bëni këtë, atëherë në një moment zbatimi do të çojë në kompleksitet të madh dhe kontrollueshmëri të dobët. Duke e kuptuar këtë, ne arritëm të krijojmë programin tonë të specializuar të Workflow për ndërtimin e CI/CD - DAPP.
Kodi i tij burimor është shkruar në Ruby, me burim të hapur dhe është publikuar në . Fatkeqësisht, dokumentacioni aktualisht është pika më e dobët e mjetit, por ne po punojmë për të. Dhe ne do të shkruajmë dhe flasim për dap më shumë se një herë, sepse ... Sinqerisht mezi presim të ndajmë aftësitë e tij me të gjithë komunitetin e interesuar, por ndërkohë, dërgoni problemet tuaja dhe tërhiqni kërkesat dhe/ose ndiqni zhvillimin e projektit në GitHub.
Përditësuar më 13 gusht 2019: aktualisht një projekt DAPP riemëruar në , kodi i tij është rishkruar plotësisht në Go dhe dokumentacioni i tij është përmirësuar ndjeshëm.
Kubernetes
Një tjetër mjet i gatshëm me burim të hapur që tashmë ka marrë njohje të konsiderueshme në mjedisin profesional është Kubernetes,një grup menaxhimi Docker. Tema e përdorimit të tij në funksionimin e projekteve të ndërtuara në Docker është përtej qëllimit të raportit, kështu që prezantimi është i kufizuar në një pasqyrë të disa veçorive interesante.
Për shpërndarje, Kubernetes ofron:
- hetimi i gatishmërisë - kontrollimi i gatishmërisë së një versioni të ri të aplikacionit (për të kaluar trafikun në të);
- Përditësimi i rrotullimit - përditësimi i njëpasnjëshëm i imazhit në një grup kontejnerësh (fikje, përditësim, përgatitje për nisje, ndërrim trafiku);
- përditësimi sinkron - përditësimi i një imazhi në një grup me një qasje të ndryshme: së pari në gjysmën e kontejnerëve, pastaj në pjesën tjetër;
- lëshimet e kanarinave - lëshimi i një imazhi të ri në një numër të kufizuar (të vogël) kontejnerësh për të monitoruar anomalitë.
Meqenëse Dorëzimi i Vazhdueshëm nuk është vetëm lëshimi i një versioni të ri, Kubernetes ka një sërë aftësish për mirëmbajtjen e mëvonshme të infrastrukturës: monitorim dhe regjistrim të integruar për të gjithë kontejnerët, shkallëzim automatik, etj. E gjithë kjo tashmë po funksionon dhe thjesht po pret për të duhur zbatimin në proceset tuaja.
Rekomandimet përfundimtare
- Përdorni Docker.
- Krijoni imazhe Docker të aplikacioneve për të gjitha nevojat tuaja.
- Ndiqni parimin "Infrastruktura është kod".
- Lidhni Git me Docker.
- Rregulloni rendin e paraqitjes.
- Përdorni një platformë të gatshme (Kubernetes ose një tjetër).
Video dhe sllajde
Video nga performanca (rreth një orë) (Vetë raporti fillon nga minuta e 5-të - ndiqni lidhjen për të luajtur nga ky moment).
Prezantimi i raportit:
PS
Raporte të tjera mbi këtë temë në blogun tonë:
- «» (Dmitry Stolyarov; 27 maj 2019 në DevOpsConf);
- «» (Dmitry Stolyarov; 8 nëntor 2018 në HighLoad++);
- «» (Dmitry Stolyarov; 7 nëntor 2017 në HighLoad++);
- «» (Dmitry Stolyarov; 6 qershor 2017 në RootConf).
Burimi: www.habr.com