Savo tinklaraštį pradėsime publikacijomis, pagrįstomis naujausiomis mūsų technikos direktoriaus kalbomis (Dmitrijus Stoliarovas). Visi jie vyko 2016 m. įvairiuose profesiniuose renginiuose ir buvo skirti DevOps ir Docker temai. Vieną vaizdo įrašą iš Docker Maskvos susitikimo Badoo biure jau turime Prisijungęs. Prie naujų bus pristatyti straipsniai, perteikiantys pranešimų esmę. Taigi…
Konferencijoje gegužės 31 d , vykusio festivalio „Russian Internet Technologies“ (RIT++ 2016) metu, skyrius „Nuolatinis diegimas ir diegimas“ atidarytas pranešimu „Geriausios nuolatinio pristatymo su Docker praktika“. Jame buvo apibendrinta ir susisteminta geriausia nuolatinio pristatymo (CD) proceso kūrimo praktika naudojant Docker ir kitus atvirojo kodo produktus. Su šiais sprendimais dirbame gamyboje, o tai leidžia pasikliauti praktine patirtimi.
Jei turite galimybę praleisti valandą , rekomenduojame pažiūrėti visą. Kitu atveju toliau pateikiama pagrindinė santrauka teksto forma.
Nuolatinis pristatymas su Docker
po Nepertrauktos Pristatymas Mes suprantame įvykių grandinę, dėl kurios programos kodas iš Git saugyklos pirmiausia patenka į gamybą, o tada patenka į archyvą. Tai atrodo taip: Git → Sukurti → Testuoti → Išleisti → Veikti.
Didžioji ataskaitos dalis skirta kūrimo etapui (programos surinkimui), trumpai paliečiamos išleidimo ir veikimo temos. Kalbėsime apie problemas ir modelius, leidžiančius jas išspręsti, o konkretūs šių modelių įgyvendinimai gali skirtis.
Kam čia išvis reikalingas Dockeris? Ne veltui nusprendėme pakalbėti apie nuolatinio pristatymo praktiką šio atvirojo kodo įrankio kontekste. Nors visa ataskaita skirta jo naudojimui, svarstant pagrindinį programos kodo išleidimo modelį atskleidžiama daug priežasčių.
Pagrindinis išleidimo modelis
Taigi, kai išleidžiame naujas programos versijas, tikrai susiduriame su prastovos problema, sugeneruotas perjungiant gamybos serverį. Srauto iš senos programos versijos į naują negali būti perjungta akimirksniu: pirmiausia turime įsitikinti, kad naujoji versija yra ne tik sėkmingai atsisiųsta, bet ir „apšilusi“ (t. y. visiškai paruošta aptarnauti užklausas).
Taigi kurį laiką abi programos versijos (senoji ir nauja) veiks vienu metu. Kas automatiškai veda prie bendrų išteklių konfliktas: tinklas, failų sistema, IPC ir kt. Naudojant „Docker“, ši problema lengvai išspręsta paleidžiant skirtingas programos versijas atskiruose konteineriuose, kurių resursų izoliavimas garantuojamas tame pačiame pagrindiniame kompiuteryje (serveryje / virtualioje mašinoje). Žinoma, su kai kuriomis gudrybėmis galima apsieiti ir be apšiltinimo, tačiau jei yra paruoštas ir patogus įrankis, tada yra priešinga priežastis – jo neapleisti.
Konteinerių naudojimas suteikia daug kitų privalumų. Bet kuri programa priklauso nuo konkreti versija (arba versijų diapazonas) vertėjas, modulių/plėtinių prieinamumą ir pan., taip pat jų versijas. Ir tai taikoma ne tik tiesioginei vykdomajai aplinkai, bet ir visai aplinkai, įskaitant sistemos programinė įranga ir jo versija (iki naudojamo Linux platinimo). Dėl to, kad konteineriuose yra ne tik programos kodas, bet ir iš anksto įdiegta reikiamų versijų sistemos ir taikomoji programinė įranga, galite pamiršti apie priklausomybių problemas.
Apibendrinkime pagrindinis išleidimo modelis naujos versijos, atsižvelgiant į šiuos veiksnius:
- Iš pradžių senoji programos versija veikia pirmajame konteineryje.
- Tada nauja versija išvyniojama ir „šildoma“ antrame konteineryje. Pastebėtina, kad ši nauja versija gali turėti ne tik atnaujintą programos kodą, bet ir bet kokias jo priklausomybes, taip pat sistemos komponentus (pavyzdžiui, naują OpenSSL versiją arba visą platinimą).
- Kai naujoji versija yra visiškai paruošta teikti užklausas, srautas persijungia iš pirmojo sudėtinio rodinio į antrą.
- Senoji versija dabar gali būti sustabdyta.
Toks skirtingų programos versijų diegimas atskiruose konteineriuose suteikia dar vieną patogumą – greitas atšaukimas į senąją versiją (juk pakanka srautą perjungti į norimą konteinerį).
Paskutinė pirmoji rekomendacija skamba kaip kažkas, dėl ko net kapitonas negalėjo rasti priekaištų: "[organizuojant nuolatinį pristatymą su Docker] Naudokite Docker [ir suprask, ką tai duoda]“ Atminkite, kad tai ne sidabrinė kulka, kuri išspręs kiekvieną problemą, o įrankis, suteikiantis nuostabų pagrindą.
Atkuriamumas
„Atkuriamumas“ reiškia bendrą problemų, su kuriomis susiduriama naudojant programas, rinkinį. Mes kalbame apie tokius atvejus:
- Scenarijai, kuriuos kokybės skyrius patikrino, kad būtų pastatyti, turi būti tiksliai atkurti gamyboje.
- Programos skelbiamos serveriuose, kurie gali gauti paketus iš skirtingų saugyklų veidrodžių (laikui bėgant jos atnaujinamos, o kartu su jais ir įdiegtų programų versijos).
- „Viskas man tinka vietoje! (...ir kūrėjams neleidžiama gaminti.)
- Reikia ką nors patikrinti senoje (archyvuotoje) versijoje.
- ...
Bendra jų esmė susiveda į tai, kad būtina visapusiška naudojamos aplinkos atitiktis (taip pat žmogiškojo faktoriaus nebuvimas). Kaip galime užtikrinti atkuriamumą? Kurkite „Docker“ vaizdus remiantis kodu iš Git, o vėliau panaudoti juos bet kokiai užduočiai: bandymų aikštelėse, gamyboje, vietiniuose programuotojų įrenginiuose... Tuo pačiu svarbu kuo labiau sumažinti atliekamus veiksmus po vaizdo surinkimas: kuo jis paprastesnis, tuo mažesnė klaidų tikimybė.
Infrastruktūra yra kodas
Jei infrastruktūros reikalavimai (serverio programinės įrangos prieinamumas, jos versija ir kt.) nėra formalizuoti ir „užprogramuoti“, bet kurio taikomosios programos naujinimo įdiegimas gali sukelti pražūtingų pasekmių. Pavyzdžiui, inscenizuodami jau perėjote prie PHP 7.0 ir atitinkamai perrašėte kodą – tada jo pasirodymas gamyboje su kokiu senu PHP (5.5) tikrai ką nors nustebins. Galbūt nepamiršite apie esminį vertėjo versijos pakeitimą, tačiau „velnias slypi detalėse“: nustebinti gali būti nedidelis bet kokios priklausomybės atnaujinimas.
Šios problemos sprendimo būdas yra žinomas kaip IaC (infrastruktūra kaip kodas, „infrastruktūra kaip kodas“) ir apima infrastruktūros reikalavimų saugojimą kartu su programos kodu. Ją naudodami kūrėjai ir „DevOps“ specialistai gali dirbti su ta pačia „Git“ programų saugykla, bet skirtingose jos dalyse. Iš šio kodo „Git“ sukuriamas „Docker“ vaizdas, kuriame programa yra įdiegta atsižvelgiant į visą infrastruktūros specifiką. Paprasčiau tariant, vaizdų surinkimo scenarijai (taisyklės) turi būti toje pačioje saugykloje su šaltinio kodu ir sujungti.
Kelių sluoksnių programos architektūros atveju, pavyzdžiui, yra nginx, kuri stovi prieš programą, kuri jau veikia Docker konteineryje, kiekvienam sluoksniui Docker vaizdai turi būti sukurti iš kodo Git. Tada pirmame vaizde bus programa su vertėju ir kitomis „artimomis“ priklausomybėmis, o antrajame vaizde bus nginx.
Docker vaizdai, bendravimas su Gitu
Visus iš Git surinktus „Docker“ vaizdus skirstome į dvi kategorijas: laikinus ir išleistus. Laikini vaizdai pažymėtos filialo pavadinimu Git, gali būti perrašyti kitą kartą ir išleidžiami tik peržiūrai (ne gamybai). Tai yra pagrindinis jų skirtumas nuo išleistų: niekada nežinai, koks konkretus įsipareigojimas juose yra.
Tikslinga rinkti į laikinus vaizdus: pagrindinę šaką (galite automatiškai išskleisti į atskirą svetainę, kad nuolat matytumėte dabartinę pagrindinio versijos versiją), šakas su leidimais, konkrečių naujovių šakas.
Po to, kai laikinų vaizdų peržiūra atsiranda, kai reikia išversti į gamybą, kūrėjai prideda tam tikrą žymą. Automatiškai renkama pagal žymą išleidimo vaizdas (jos žyma atitinka žymą iš Git) ir išleidžiama į sceną. Jei tai sėkmingai patikrina kokybės skyrius, jis pradedamas gaminti.
DAPP
Viskas, kas aprašyta (išleidimas, vaizdo surinkimas, tolesnė priežiūra) gali būti įgyvendinta savarankiškai naudojant „Bash“ scenarijus ir kitus „improvizuotus“ įrankius. Bet jei tai padarysite, tam tikru momentu įgyvendinimas sukels didelį sudėtingumą ir prastą valdymą. Suprasdami tai, sukūrėme savo specializuotą darbo eigos įrankį CI / CD kūrimui - DAPP.
Jo šaltinio kodas parašytas atvirojo kodo Ruby kalba ir paskelbtas . Deja, dokumentacija šiuo metu yra silpniausia įrankio vieta, bet mes su ja dirbame. O apie dapp’ą rašysime ir kalbėsime dar ne kartą, nes... Nekantraujame pasidalinti jo galimybėmis su visa suinteresuota bendruomene, tačiau kol kas siųskite savo problemas ir gaukite užklausas ir (arba) stebėkite projekto vystymąsi GitHub.
Atnaujinta 13 m. rugpjūčio 2019 d.: šiuo metu projektas DAPP pervadintas į , jo kodas buvo visiškai perrašytas programoje Go, o jo dokumentacija buvo žymiai patobulinta.
Kubernetes
Kitas paruoštas atvirojo kodo įrankis, jau sulaukęs nemažo pripažinimo profesinėje aplinkoje, yra Kubernetes,Docker valdymo klasteris. Jo naudojimo tema „Docker“ pagrindu sukurtuose projektuose nepatenka į ataskaitos sritį, todėl pristatymas apsiriboja kai kurių įdomių funkcijų apžvalga.
Išleidimui Kubernetes siūlo:
- parengties zondas – naujos programos versijos pasirengimo tikrinimas (perjungti srautą į ją);
- nuolatinis atnaujinimas - nuoseklus vaizdo atnaujinimas konteinerių klasteryje (išjungimas, atnaujinimas, paruošimas paleidimui, srauto perjungimas);
- sinchroninis atnaujinimas - vaizdo atnaujinimas klasteryje naudojant kitokį metodą: pirmiausia pusėje konteinerių, tada likusiuose;
- canary releases – naujo vaizdo paleidimas ant riboto (nedidelio) konteinerių skaičiaus, kad būtų galima stebėti anomalijas.
Kadangi „Continuous Delivery“ yra ne tik naujos versijos išleidimas, „Kubernetes“ turi daugybę galimybių tolesnei infrastruktūros priežiūrai: integruotą visų konteinerių stebėjimą ir registravimą, automatinį mastelio keitimą ir kt. Visa tai jau veikia ir tik laukia tinkamo įgyvendinimas jūsų procesuose.
Paskutinės rekomendacijos
- Naudokite Docker.
- Kurkite „Docker“ programų vaizdus visiems jūsų poreikiams.
- Laikykitės principo „Infrastruktūra yra kodas“.
- Susiekite „Git“ su „Docker“.
- Reguliuokite išleidimo tvarką.
- Naudokite paruoštą platformą („Kubernetes“ ar kitą).
Vaizdo įrašai ir skaidrės
Vaizdo įrašas iš spektaklio (apie valandą) (pats reportažas prasideda nuo 5 minutės - sekite nuorodą, norėdami žaisti nuo šios akimirkos).
Pranešimo pristatymas:
PS
Kiti pranešimai šia tema mūsų tinklaraštyje:
- «» (Dmitrijus Stoliarovas; 27 m. gegužės 2019 d., „DevOpsConf“);
- «» (Dmitrijus Stoliarovas; 8 m. lapkričio 2018 d. „HighLoad++“);
- «» (Dmitrijus Stoliarovas; 7 m. lapkričio 2017 d. „HighLoad++“);
- «» (Dmitrijus Stolyarovas; 6 m. birželio 2017 d. RootConf).
Šaltinis: www.habr.com