Ons sal ons blog begin met publikasies gebaseer op die jongste toesprake van ons tegniese direkteur (Dmitri Stolyarov). Almal van hulle het in 2016 by verskeie professionele geleenthede plaasgevind en was gewy aan die onderwerp van DevOps en Docker. Een video van die Docker Moskou-vergadering by die Badoo-kantoor het ons reeds Aanlyn. Nuwes sal vergesel word van artikels wat die essensie van die verslae oordra. So…
31 Mei by die konferensie , gehou as deel van die fees "Russian Internet Technologies" (RIT++ 2016), het die afdeling "Deurlopende ontplooiing en ontplooiing" geopen met die verslag "Beste praktyke van deurlopende aflewering met Docker". Dit het die beste praktyke vir die bou van 'n deurlopende aflewering (CD)-proses opgesom en gesistematiseer deur Docker en ander oopbronprodukte te gebruik. Ons werk met hierdie oplossings in produksie, wat ons in staat stel om op praktiese ervaring staat te maak.
As jy die geleentheid het om 'n uur te spandeer , beveel ons aan om dit volledig te kyk. Andersins, hieronder is die hoofopsomming in teksvorm.
Deurlopende aflewering met Docker
Onder deurlopende aflewering ons verstaan die ketting van gebeure as gevolg waarvan die toepassingskode van die Git-bewaarplek eers tot produksie kom, en dan in die argief beland. Dit lyk so: Git → Bou → Toets → Vrystelling → Bedryf.
Die meeste van die verslag word gewy aan die boustadium (toepassingsamestelling), en die onderwerpe wat vrygestel en bedryf word, word kortliks aangeroer. Ons sal praat oor probleme en patrone wat jou toelaat om dit op te los, en die spesifieke implementering van hierdie patrone kan anders wees.
Waarom is Docker enigsins hier nodig? Dit is nie verniet dat ons besluit het om te praat oor deurlopende afleweringspraktyke in die konteks van hierdie oopbron-nutsding nie. Alhoewel die hele verslag aan die gebruik daarvan gewy is, word baie redes aan die lig gebring wanneer die hoofpatroon van toepassingskode-ontplooiing oorweeg word.
Hoofontplooiingspatroon
Dus, wanneer ons nuwe weergawes van die toepassing uitrol, word ons beslis gekonfronteer stilstand probleem, gegenereer tydens die omskakeling van die produksiebediener. Verkeer van die ou weergawe van die toepassing na die nuwe een kan nie onmiddellik oorskakel nie: eerstens moet ons seker maak dat die nuwe weergawe nie net suksesvol afgelaai is nie, maar ook "opwarm" is (d.w.s. heeltemal gereed om versoeke te bedien).
Dus, vir 'n geruime tyd sal beide weergawes van die toepassing (oud en nuut) gelyktydig werk. Wat outomaties lei tot gedeelde hulpbronkonflik: netwerk, lêerstelsel, IPC, ens. Met Docker word hierdie probleem maklik opgelos deur verskillende weergawes van die toepassing in aparte houers uit te voer, waarvoor hulpbronisolasie binne dieselfde gasheer (bediener/virtuele masjien) gewaarborg word. Natuurlik kan jy klaarkom met 'n paar truuks sonder isolasie enigsins, maar as daar 'n gereedgemaakte en gerieflike hulpmiddel is, is daar die teenoorgestelde rede - om dit nie te verwaarloos nie.
Houerisering bied baie ander voordele wanneer dit ontplooi word. Enige aansoek hang af van spesifieke weergawe (of weergawe reeks) tolk, beskikbaarheid van modules/uitbreidings, ens., asook hul weergawes. En dit geld nie net vir die onmiddellike uitvoerbare omgewing nie, maar ook vir die hele omgewing, insluitend stelsel sagteware en die weergawe daarvan (tot en met die Linux-verspreiding wat gebruik word). As gevolg van die feit dat houers nie net toepassingskode bevat nie, maar ook vooraf geïnstalleerde stelsel- en toepassingsagteware van die vereiste weergawes, kan u van probleme met afhanklikhede vergeet.
Kom ons som op hoofontplooiingspatroon nuwe weergawes wat die volgende faktore in ag neem:
- Aanvanklik loop die ou weergawe van die toepassing in die eerste houer.
- Die nuwe weergawe word dan uitgerol en in 'n tweede houer "opwarm". Dit is opmerklik dat hierdie nuwe weergawe self nie net opgedateerde toepassingskode kan dra nie, maar ook enige van sy afhanklikhede, sowel as stelselkomponente (byvoorbeeld 'n nuwe weergawe van OpenSSL of die hele verspreiding).
- Wanneer die nuwe weergawe heeltemal gereed is om versoeke te bedien, skakel verkeer van die eerste houer na die tweede.
- Die ou weergawe kan nou gestop word.
Hierdie benadering om verskillende weergawes van die toepassing in aparte houers te ontplooi bied nog 'n gerief - vinnige terugrol na die ou weergawe (dit is immers genoeg om verkeer na die verlangde houer oor te skakel).
Die laaste eerste aanbeveling klink soos iets waarmee selfs die Kaptein nie fout kon vind nie: "[wanneer deurlopende aflewering met Docker georganiseer word] Gebruik Docker [en verstaan wat dit gee]" Onthou, dit is nie 'n silwer koeël wat elke probleem sal oplos nie, maar 'n hulpmiddel wat 'n wonderlike fondament bied.
Reproduceerbaarheid
Met "reproduceerbaarheid" bedoel ons 'n algemene stel probleme wat ondervind word wanneer toepassings bedryf word. Ons praat oor sulke gevalle:
- Skripte wat deur die kwaliteitsafdeling vir opvoering nagegaan is, moet akkuraat in produksie gereproduseer word.
- Toepassings word op bedieners gepubliseer wat pakkette vanaf verskillende bewaarplekspieëls kan ontvang (met verloop van tyd word hulle opgedateer, en daarmee saam die weergawes van geïnstalleerde toepassings).
- “Alles werk vir my plaaslik!” (...en ontwikkelaars word nie in produksie toegelaat nie.)
- Jy moet iets in die ou (geargiveerde) weergawe nagaan.
- ...
Hul algemene wese kom daarop neer dat volle nakoming van die omgewings wat gebruik word (sowel as die afwesigheid van die menslike faktor) nodig is. Hoe kan ons reproduceerbaarheid waarborg? Maak Docker-beelde gebaseer op kode van Git, en gebruik dit dan vir enige taak: op toetswebwerwe, in produksie, op plaaslike masjiene van programmeerders ... Terselfdertyd is dit belangrik om die aksies wat uitgevoer word, te minimaliseer na die samestelling van die beeld: hoe eenvoudiger dit is, hoe minder waarskynlik is daar foute.
Infrastruktuur is kode
As die infrastruktuurvereistes (beskikbaarheid van bedienersagteware, die weergawe daarvan, ens.) nie geformaliseer en "geprogrammeer" is nie, kan die ontplooiing van enige toepassingopdatering rampspoedige gevolge tot gevolg hê. Byvoorbeeld, in opvoering het jy reeds oorgeskakel na PHP 7.0 en die kode dienooreenkomstig herskryf - dan sal die verskyning daarvan in produksie met een of ander ou PHP (5.5) beslis iemand verras. Jy mag nie vergeet van 'n groot verandering in die tolk weergawe, maar "die duiwel is in die besonderhede": die verrassing kan wees in 'n geringe opdatering van enige afhanklikheid.
'n Benadering om hierdie probleem op te los staan bekend as IaC (infrastruktuur as kode, "infrastruktuur as kode") en behels die berging van infrastruktuurvereistes saam met die toepassingskode. Deur dit te gebruik, kan ontwikkelaars en DevOps-spesialiste met dieselfde Git-toepassingsbewaarplek werk, maar op verskillende dele daarvan. Uit hierdie kode word 'n Docker-beeld in Git geskep, waarin die toepassing ontplooi word met inagneming van al die besonderhede van die infrastruktuur. Eenvoudig gestel, die skrifte (reëls) vir die samestelling van beelde moet in dieselfde bewaarplek met die bronkode wees en saamgevoeg word.
In die geval van 'n multi-laag toepassing argitektuur - daar is byvoorbeeld nginx, wat staan voor 'n toepassing wat reeds binne 'n Docker-houer loop - Docker beelde moet geskep word vanaf kode in Git vir elke laag. Dan sal die eerste prent 'n toepassing met 'n tolk en ander "naby" afhanklikhede bevat, en die tweede prent sal die stroomop nginx bevat.
Docker-beelde, kommunikasie met Git
Ons verdeel alle Docker-beelde wat van Git versamel is in twee kategorieë: tydelik en vrystelling. Tydelike beelde gemerk deur die naam van die tak in Git, kan oorskryf word deur die volgende commit en word slegs vir voorskou uitgerol (nie vir produksie nie). Dit is hul belangrikste verskil van vrystellings: jy weet nooit watter spesifieke verbintenis in hulle is nie.
Dit maak sin om in tydelike beelde te versamel: die meestertak (jy kan dit outomaties na 'n aparte webwerf uitrol om voortdurend die huidige weergawe van meester te sien), takke met vrystellings, takke van spesifieke innovasies.
Nadat die voorskou van tydelike beelde tot die behoefte vir vertaling in produksie gekom het, het die ontwikkelaars 'n sekere merker aangebring. Outomaties ingesamel deur etiket beeld vry te stel (die merker stem ooreen met die merker van Git) en word uitgerol na opvoering. As dit suksesvol deur die kwaliteitsafdeling geverifieer word, gaan dit na produksie.
dapp
Alles wat beskryf word (ontplooiing, beeldsamestelling, daaropvolgende instandhouding) kan onafhanklik geïmplementeer word deur Bash-skrifte en ander "geïmproviseerde" gereedskap te gebruik. Maar as jy dit doen, sal die implementering op een of ander stadium tot groot kompleksiteit en swak beheerbaarheid lei. As ons dit verstaan het, het ons ons eie gespesialiseerde Workflow-hulpmiddel geskep vir die bou van CI/CD - dapp.
Die bronkode is in Ruby geskryf, oopbron en gepubliseer op . Ongelukkig is dokumentasie tans die swakste punt van die instrument, maar ons werk daaraan. En ons sal meer as een keer oor die dapp skryf en praat, want... Ons kan opreg nie wag om sy vermoëns met die hele belangstellende gemeenskap te deel nie, maar stuur intussen jou kwessies en trek versoeke en/of volg die ontwikkeling van die projek op GitHub.
Opgedateer 13 Augustus 2019: tans 'n projek dapp herdoop na , sy kode is heeltemal herskryf in Go, en sy dokumentasie is aansienlik verbeter.
Kubernetes
Nog 'n klaargemaakte Oopbron-instrument wat reeds aansienlike erkenning in die professionele omgewing ontvang het, is Kubernetes, 'n Docker-bestuurkluster. Die onderwerp van die gebruik daarvan in die bedryf van projekte wat op Docker gebou is, is buite die bestek van die verslag, so die aanbieding is beperk tot 'n oorsig van 'n paar interessante kenmerke.
Vir ontplooiing bied Kubernetes:
- gereedheidsondersoek — kontrolering van die gereedheid van 'n nuwe weergawe van die toepassing (om verkeer na dit oor te skakel);
- rollende opdatering - opeenvolgende beeldopdatering in 'n groep houers (afsluiting, opdatering, voorbereiding vir bekendstelling, verkeerswisseling);
- sinchroniese opdatering - opdatering van 'n beeld in 'n groepering met 'n ander benadering: eers op die helfte van die houers, dan op die res;
- kanarievrystellings - die bekendstelling van 'n nuwe beeld op 'n beperkte (klein) aantal houers om afwykings te monitor.
Aangesien Continuous Delivery nie net die vrystelling van 'n nuwe weergawe is nie, het Kubernetes 'n aantal geleenthede vir daaropvolgende infrastruktuurinstandhouding: ingeboude monitering en logging vir alle houers, outomatiese skaal, ens. Dit alles werk reeds en wag net vir behoorlike implementering in jou prosesse.
Finale aanbevelings
- Gebruik Docker.
- Skep Docker-beelde van toepassings vir al jou behoeftes.
- Volg die beginsel "Infrastruktuur is kode."
- Koppel Git aan Docker.
- Reguleer die volgorde van ontplooiing.
- Gebruik 'n klaargemaakte platform (Kubernetes of 'n ander).
Video's en skyfies
Video van die optrede (ongeveer 'n uur) (die berig self begin vanaf die 5de minuut - volg die skakel om vanaf hierdie oomblik te speel).
Verslagaanbieding:
PS
Ander berigte oor die onderwerp op ons blog:
- «» (Dmitri Stolyarov; 27 Mei 2019 by DevOpsConf);
- «» (Dmitri Stolyarov; 8 November 2018 op HighLoad++);
- «» (Dmitri Stolyarov; 7 November 2017 op HighLoad++);
- «» (Dmitri Stolyarov; 6 Junie 2017 by RootConf).
Bron: will.com