Wy sille ús blog begjinne mei publikaasjes basearre op de lêste taspraken fan ús technyske direkteur (Dmitry Stolyarov). Allegear fûnen se plak yn 2016 by ferskate profesjonele eveneminten en wiene wijd oan it ûnderwerp fan DevOps en Docker. Ien fideo fan 'e Docker Moskou-gearkomste by it Badoo-kantoar hawwe wy al Online. Nije sille wurde begelaat troch artikels dy't de essinsje fan 'e rapporten oerbringe. Sa…
31 maaie op de konferinsje , hâlden as ûnderdiel fan it festival "Russian Internet Technologies" (RIT ++ 2016), de seksje "Continuous Deployment and Deployment" iepene mei it rapport "Best Practices of Continuous Delivery with Docker". It gearfette en systematisearre de bêste praktiken foar it bouwen fan in Continuous Delivery (CD) proses mei Docker en oare Open Source produkten. Wy wurkje mei dizze oplossingen yn produksje, wêrtroch't wy kinne fertrouwe op praktyske ûnderfining.
As jo de kâns hawwe om in oere troch te bringen , riede wy oan om it folslein te besjen. Oars, hjirûnder is de haad gearfetting yn tekstfoarm.
Trochrinnende levering mei Docker
By Trochgeande levering wy begripe de keatling fan barrens as gefolch wêrfan de applikaasjekoade fan it Git-repository earst yn produksje komt, en dan yn it argyf einiget. It sjocht der sa út: Git → Build → Test → Release → Operearje.
It grutste part fan it rapport is wijd oan it boustadium (applikaasje-assemblage), en de ûnderwerpen dy't frijlitte en wurkje wurde koart oanrekke. Wy sille prate oer problemen en patroanen wêrtroch jo se kinne oplosse, en de spesifike ymplemintaasje fan dizze patroanen kinne oars wêze.
Wêrom is Docker hjir überhaupt nedich? It is net foar neat dat wy besletten hawwe om te praten oer trochgeande leveringpraktiken yn 'e kontekst fan dit Iepen Boarne-ark. Hoewol it heule rapport is wijd oan it gebrûk, wurde in protte redenen iepenbiere by it beskôgjen fan it haadpatroan fan útrol fan tapassingskoade.
Main rollout patroan
Dat, as wy nije ferzjes fan 'e applikaasje útrolje, wurde wy grif te krijen mei downtime probleem, oanmakke by it wikseljen fan de produksjetsjinner. Ferkear fan 'e âlde ferzje fan' e applikaasje nei de nije kin net direkt oerskeakelje: earst moatte wy derfoar soargje dat de nije ferzje net allinich mei súkses is ynladen, mar ek "opwarmd" (dus folslein klear om oanfragen te tsjinjen).
Sa sille foar in skoft beide ferzjes fan 'e applikaasje (âld en nij) tagelyk wurkje. Wat automatysk liedt ta konflikt mei dielde boarnen: netwurk, triemsysteem, IPC, ensfh. Mei Docker wurdt dit probleem maklik oplost troch ferskate ferzjes fan 'e applikaasje út te fieren yn aparte konteners, wêrfoar boarne-isolaasje garandearre is binnen deselde host (tsjinner / firtuele masine). Fansels kinne jo mei guon trúkjes hielendal sûnder isolaasje komme, mar as d'r in klear en handich ark is, dan is d'r de tsjinoerstelde reden - om it net te negearjen.
Containerisaasje leveret in protte oare foardielen by ynset. Elke applikaasje hinget ôf fan spesifike ferzje (of ferzje berik) tolk, beskikberens fan modules / tafoegings, ensfh., En ek harren ferzjes. En dat jildt net allinnich foar de direkte útfierbere omjouwing, mar ek foar de hiele omjouwing, ynklusyf systeem software en syn ferzje (oant de brûkte Linux-distribúsje). Fanwegen it feit dat konteners net allinich applikaasjekoade befetsje, mar ek foarôf ynstalleare systeem- en applikaasjesoftware fan 'e fereaske ferzjes, kinne jo problemen mei ôfhinklikens ferjitte.
Litte wy gearfetsje wichtichste rollout patroan nije ferzjes mei rekken hâldend mei de folgjende faktoaren:
- Earst rint de âlde ferzje fan 'e applikaasje yn' e earste kontener.
- De nije ferzje wurdt dan útrôle en "opwarmd" yn in twadde kontener. It is opmerklik dat dizze nije ferzje sels net allinich bywurke applikaasjekoade kin drage, mar ek ien fan syn ôfhinklikens, lykas systeemkomponinten (bygelyks in nije ferzje fan OpenSSL of de heule distribúsje).
- As de nije ferzje folslein klear is om oanfragen te tsjinjen, skeakelt ferkear fan 'e earste kontener nei de twadde.
- De âlde ferzje kin no wurde stoppe.
Dizze oanpak fan it ynsetten fan ferskate ferzjes fan 'e applikaasje yn aparte konteners biedt in oar gemak - fluch weromdraaie nei de âlde ferzje (it is ommers genôch om ferkear te wikseljen nei de winske kontener).
De lêste earste oanbefelling klinkt as iets dêr't sels de kaptein gjin fout mei koe fine: "[by it organisearjen fan trochgeande levering mei Docker] Brûk Docker [en begryp wat it jout]" Unthâld, dit is net in sulveren kûgel dy't elk probleem sil oplosse, mar in ark dat in prachtige stifting leveret.
Reproducibility
Mei "reprodusearberens" bedoele wy in generalisearre set fan problemen dy't tsjinkaam by it operearjen fan applikaasjes. Wy prate oer sokke gefallen:
- Skripten kontrolearre troch de kwaliteitsôfdieling foar staging moatte sekuer wurde reprodusearre yn produksje.
- Applikaasjes wurde publisearre op servers dy't pakketten kinne ûntfange fan ferskate repositoryspegels (yn 'e rin fan' e tiid wurde se bywurke, en mei har de ferzjes fan ynstalleare applikaasjes).
- "Alles wurket foar my lokaal!" (... en ûntwikkelders binne net tastien yn produksje.)
- Jo moatte wat kontrolearje yn 'e âlde (argivearre) ferzje.
- ...
Har algemiene essinsje komt del op it feit dat de folsleine neilibjen fan 'e brûkte omjouwings (lykas it ûntbrekken fan' e minsklike faktor) needsaaklik is. Hoe kinne wy garandearje reproducibility? Meitsje Docker-ôfbyldings basearre op koade fan Git, en brûk se dan foar elke taak: op testsites, yn produksje, op lokale masines fan programmeurs ... Tagelyk is it wichtich om de aksjes te minimalisearjen dy't wurde útfierd после de ôfbylding gearstalle: hoe ienfâldiger it is, hoe minder kâns dat der flaters binne.
Ynfrastruktuer is koade
As de ynfrastruktuer-easken (beskikberens fan serversoftware, har ferzje, ensfh.) Net formalisearre en "programmearre" binne, dan kin de útrol fan elke applikaasje-update in desastreus gefolgen hawwe. Bygelyks, yn 'e staging binne jo al oerstapt nei PHP 7.0 en de koade dêroer skreaun - dan sil it ferskinen yn' e produksje mei wat âlde PHP (5.5) ien wis ferrast. Jo kinne miskien net ferjitte oer in grutte feroaring yn 'e tolkferzje, mar "de duvel is yn' e details": de ferrassing kin wêze yn in lytse update fan elke ôfhinklikens.
In oanpak om dit probleem op te lossen is bekend as IaC (ynfrastruktuer as koade, "ynfrastruktuer as koade") en giet it om it opslaan fan ynfrastruktuer easken tegearre mei de applikaasje koade. Troch it te brûken kinne ûntwikkelders en DevOps-spesjalisten wurkje mei itselde Git-applikaasjebewarplak, mar op ferskate dielen dêrfan. Fan dizze koade wurdt in Docker-ôfbylding makke yn Git, wêryn de applikaasje wurdt ynset mei rekkening mei alle spesifikaasjes fan 'e ynfrastruktuer. Simply set, de skripts (regels) foar it gearstallen fan ôfbyldings moatte yn itselde repository wêze mei de boarnekoade en gearfoege.
Yn it gefal fan in multi-laach applikaasje-arsjitektuer - bygelyks is d'r nginx, dy't stiet foar in applikaasje dy't al rint yn in Docker-kontener - Docker-ôfbyldings moatte makke wurde fan koade yn Git foar elke laach. Dan sil de earste ôfbylding in applikaasje befetsje mei in tolk en oare "tichte" ôfhinklikens, en de twadde ôfbylding sil de streamop nginx befetsje.
Docker-ôfbyldings, kommunikaasje mei Git
Wy ferdiele alle Docker-ôfbyldings sammele fan Git yn twa kategoryen: tydlik en frijlitting. Tydlike bylden tagged troch de namme fan 'e tûke yn Git, kinne wurde oerskreaun troch de folgjende commit en wurde allinich útrôle foar foarbyld (net foar produksje). Dit is har wichtichste ferskil fan releases: jo witte noait hokker spesifike commit yn har is.
It makket sin om te sammeljen yn tydlike ôfbyldings: de mastertûke (jo kinne it automatysk útrolje nei in aparte side om de aktuele ferzje fan master konstant te sjen), tûken mei releases, tûken fan spesifike ynnovaasjes.
Nei it foarbyld fan tydlike bylden komt ta de needsaak foar oersetting yn produksje, de ûntwikkelders sette in bepaalde tag. Automatysk sammele troch tag release ôfbylding (syn tag komt oerien mei de tag fan Git) en wurdt útrôle nei staging. As it mei súkses kontrolearre wurdt troch de kwaliteitsôfdieling, giet it nei produksje.
dapp
Alles beskreaun (útrol, ôfbyldingsassemblage, folgjende ûnderhâld) kin ûnôfhinklik wurde ymplementearre mei Bash-skripts en oare "ymprovisearre" ark. Mar as jo dit dogge, dan sil de ymplemintaasje op in stuit liede ta grutte kompleksiteit en minne kontrôle. Troch dit te begripen, kamen wy ús eigen spesjalisearre Workflow-hulpprogramma te meitsjen foar it bouwen fan CI / CD - dapp.
De boarnekoade is skreaun yn Ruby, iepen boarne en publisearre op . Spitigernôch is dokumintaasje op it stuit it swakste punt fan it ark, mar wy wurkje der oan. En wy sille mear as ien kear oer de dapp skriuwe en prate, om't ... Wy kinne oprjocht net wachtsje om har mooglikheden te dielen mei de heule ynteressearre mienskip, mar stjoer yn 'e tuskentiid jo problemen en lûk fersiken en / of folgje de ûntwikkeling fan it projekt op GitHub.
Updated 13 augustus 2019: op it stuit in projekt dapp omdoopt ta , syn koade is folslein opnij skreaun yn Go, en syn dokumintaasje is signifikant ferbettere.
Kubernetes
In oar klearmakke Iepenboarne-ark dat al wichtige erkenning hat krigen yn 'e profesjonele omjouwing is Kubernetes, in Docker behear kluster. It ûnderwerp fan it gebrûk yn 'e eksploitaasje fan projekten boud op Docker is bûten it berik fan it rapport, sadat de presintaasje beheind is ta in oersjoch fan guon nijsgjirrige funksjes.
Foar útrol biedt Kubernetes:
- reewilligensprobe - kontrolearje de reewilligens fan in nije ferzje fan 'e applikaasje (om it ferkear nei it te wikseljen);
- rôljende fernijing - opfolgjende ôfbyldingsfernijing yn in kluster fan konteners (ôfslute, fernijing, tarieding op lansearring, ferkearswikseling);
- syngroane fernijing - it bywurkjen fan in ôfbylding yn in kluster mei in oare oanpak: earst op 'e helte fan' e konteners, dan op 'e rest;
- canary releases - lansearje in nije ôfbylding op in beheind (lyts) oantal konteners om anomalies te kontrolearjen.
Sûnt Continuous Delivery is net allinnich de frijlitting fan in nije ferzje, Kubernetes hat in oantal mooglikheden foar folgjende ynfrastruktuer ûnderhâld: ynboude monitoring en logging foar alle konteners, automatyske skaalfergrutting, ensfh Dit alles wurket al en wachtet gewoan op in goede ymplemintaasje yn jo prosessen.
Finale oanbefellings
- Brûk Docker.
- Meitsje Docker-ôfbyldings fan applikaasjes foar al jo behoeften.
- Folgje it prinsipe "Ynfrastruktuer is koade."
- Keppelje Git nei Docker.
- Regelje de folchoarder fan útrol.
- Brûk in klear makke platfoarm (Kubernetes of in oar).
Fideo's en dia's
Fideo fan de foarstelling (sawat in oere) (it ferslach sels begjint fan 'e 5e minút - folgje de keppeling om fan dit momint ôf te spyljen).
Presintaasje fan it rapport:
PS
Oare rapporten oer it ûnderwerp op ús blog:
- «» (Dmitry Stolyarov; 27 maaie 2019 by DevOpsConf);
- «» (Dmitry Stolyarov; 8 novimber 2018 op HighLoad++);
- «» (Dmitry Stolyarov; 7 novimber 2017 op HighLoad++);
- «» (Dmitry Stolyarov; 6 juny 2017 by RootConf).
Boarne: www.habr.com