Naš blog bomo začeli z objavami, ki temeljijo na zadnjih govorih našega tehničnega direktorja (Dmitrij Stoljarov). Vsi so potekali v letu 2016 na različnih strokovnih dogodkih in so bili posvečeni temi DevOps in Docker. En video s sestanka Docker Moscow v pisarni Badoo že imamo Na spletu. Nove bodo spremljali članki, ki bodo podajali bistvo poročil. Torej …
31. maja na konferenci , ki je potekal v okviru festivala »Ruske internetne tehnologije« (RIT++ 2016), se je razdelek »Neprekinjeno uvajanje in uvajanje« odprl s poročilom »Najboljše prakse neprekinjene dostave z Dockerjem«. Povzel je in sistematiziral najboljše prakse za izgradnjo procesa neprekinjene dostave (CD) z uporabo Dockerja in drugih odprtokodnih izdelkov. S temi rešitvami delamo v proizvodnji, kar nam omogoča, da se zanašamo na praktične izkušnje.
Če imate možnost preživeti eno uro , priporočamo ogled v celoti. Sicer pa je spodaj glavni povzetek v besedilni obliki.
Neprekinjena dostava z Dockerjem
Pod Nenehna dostava razumemo verigo dogodkov, zaradi katerih koda aplikacije iz repozitorija Git najprej pride v produkcijo, nato pa konča v arhivu. Videti je takole: Git → Gradnja → Test → Sprostitev → Delovanje.
Večji del poročila je posvečen stopnji gradnje (sestavljanje aplikacije), na kratko pa se dotaknemo tem izdaje in delovanja. Govorili bomo o problemih in vzorcih, ki vam omogočajo, da jih rešite, specifične izvedbe teh vzorcev pa so lahko različne.
Zakaj je Docker sploh potreben tukaj? Ni zaman, da smo se odločili govoriti o praksah neprekinjene dostave v kontekstu tega odprtokodnega orodja. Čeprav je celotno poročilo posvečeno njeni uporabi, se ob upoštevanju glavnega vzorca uvajanja kode aplikacije razkrije veliko razlogov.
Glavni vzorec razgrnitve
Torej, ko uvajamo nove različice aplikacije, se zagotovo soočamo z problem izpadov, ki nastane med preklopom produkcijskega strežnika. Promet iz stare različice aplikacije v novo se ne more takoj preklopiti: najprej se moramo prepričati, da je nova različica ne le uspešno prenesena, ampak tudi "ogreta" (tj. popolnoma pripravljena za streženje zahtevkom).
Tako bosta nekaj časa obe različici aplikacije (stara in nova) delovali hkrati. Kar samodejno vodi do konflikt skupnih virov: omrežje, datotečni sistem, IPC itd. Z Dockerjem je to težavo enostavno rešiti z izvajanjem različnih različic aplikacije v ločenih vsebnikih, za katere je zagotovljena izolacija virov znotraj istega gostitelja (strežnik/virtualni stroj). Seveda se lahko z nekaterimi triki sploh izognete brez izolacije, a če obstaja že pripravljeno in priročno orodje, potem obstaja nasprotni razlog - da ga ne zanemarite.
Kontejnerizacija zagotavlja številne druge prednosti, ko je uvedena. Vsaka aplikacija je odvisna od posebna različica (ali obseg različic) tolmač, razpoložljivost modulov/razširitev itd., kot tudi njihove različice. In to ne velja samo za neposredno izvršljivo okolje, ampak tudi za celotno okolje, vključno z sistemsko programsko opremo in njegovo različico (do uporabljene distribucije Linuxa). Ker vsebniki ne vsebujejo samo kode aplikacije, temveč tudi vnaprej nameščeno sistemsko in aplikacijsko programsko opremo zahtevanih različic, lahko pozabite na težave z odvisnostmi.
Povzemimo glavni vzorec razgrnitve nove različice ob upoštevanju naslednjih dejavnikov:
- Sprva se stara različica aplikacije izvaja v prvem vsebniku.
- Nova različica se nato razvije in "segreje" v drugi posodi. Omeniti velja, da lahko ta nova različica sama nosi ne le posodobljeno kodo aplikacije, ampak tudi vse njene odvisnosti, pa tudi sistemske komponente (na primer novo različico OpenSSL ali celotno distribucijo).
- Ko je nova različica popolnoma pripravljena za serviranje zahtev, se promet preklopi s prvega vsebnika na drugega.
- Staro različico je zdaj mogoče ustaviti.
Ta pristop uvajanja različnih različic aplikacije v ločenih vsebnikih zagotavlja še eno udobje – hitro vrnitev nazaj na staro različico (navsezadnje je dovolj, da preklopite promet na želeni vsebnik).
Zadnje prvo priporočilo zveni kot nekaj, čemur niti kapitan ni mogel očitati: "[pri organiziranju neprekinjene dostave z Dockerjem] Uporabi Docker [in razumeti, kaj daje]" Ne pozabite, da to ni srebrna paleta, ki bo rešila vsako težavo, ampak orodje, ki zagotavlja čudovito podlago.
Ponovljivost
Z "ponovljivostjo" mislimo na splošen nabor težav, ki se pojavijo pri delovanju aplikacij. Govorimo o takih primerih:
- Scenariji, ki jih je oddelek za kakovost preveril za uprizoritev, morajo biti v produkciji natančno reproducirani.
- Aplikacije so objavljene na strežnikih, ki lahko sprejemajo pakete iz različnih zrcalnih repozitorijev (čez čas se posodabljajo, z njimi pa tudi različice nameščenih aplikacij).
- “Vse mi deluje lokalno!” (...in razvijalcem ni dovoljeno v proizvodnjo.)
- Nekaj morate preveriti v stari (arhivirani) verziji.
- ...
Njihovo splošno bistvo se spušča v dejstvo, da je potrebna popolna skladnost uporabljenih okolij (pa tudi odsotnost človeškega faktorja). Kako lahko zagotovimo ponovljivost? Ustvarite Dockerjeve slike temeljijo na kodi iz Gita in jih nato uporabijo za poljubna opravila: na testnih mestih, v produkciji, na lokalnih strojih programerjev ... Hkrati je pomembno zmanjšati dejanja, ki se izvajajo po sestavljanje slike: preprostejše kot je, manjša je verjetnost napak.
Infrastruktura je koda
Če infrastrukturne zahteve (razpoložljivost strežniške programske opreme, njena različica itd.) niso formalizirane in »programirane«, ima lahko uvedba kakršne koli posodobitve aplikacije katastrofalne posledice. Na primer, v uprizarjanju ste že prešli na PHP 7.0 in ustrezno prepisali kodo - potem bo njegov videz v produkciji s starim PHP (5.5) zagotovo koga presenetil. Ne smete pozabiti na veliko spremembo v različici tolmača, vendar "hudič je v podrobnostih": presenečenje je lahko v manjši posodobitvi katere koli odvisnosti.
Pristop k reševanju tega problema je znan kot IaC (Infrastructure as Code, »infrastruktura kot koda«) in vključuje shranjevanje infrastrukturnih zahtev skupaj s kodo aplikacije. Z njegovo uporabo lahko razvijalci in strokovnjaki za DevOps delajo z istim repozitorijem aplikacij Git, vendar na njegovih različnih delih. Iz te kode se v Git-u ustvari slika Dockerja, v kateri se aplikacija razmesti z upoštevanjem vseh posebnosti infrastrukture. Preprosto povedano, skripti (pravila) za sestavljanje slik bi morali biti v istem repozitoriju z izvorno kodo in združeni skupaj.
V primeru večplastne arhitekture aplikacije - na primer obstaja nginx, ki stoji pred aplikacijo, ki se že izvaja znotraj vsebnika Docker - morajo biti slike Dockerja ustvarjene iz kode v Gitu za vsako plast. Potem bo prva slika vsebovala aplikacijo s tolmačem in drugimi "tesnimi" odvisnostmi, druga slika pa bo vsebovala zgornji nginx.
Docker slike, komunikacija z Gitom
Vse Dockerjeve slike, zbrane iz Gita, delimo v dve kategoriji: začasne in izdajne. Začasne slike označeni z imenom veje v Gitu, jih lahko prepiše naslednja objava in so uvedeni samo za predogled (ne za proizvodnjo). To je njihova ključna razlika od izdanih: nikoli ne veste, katera posebna potrditev je v njih.
Smiselno je zbrati v začasne slike: glavna veja (lahko jo samodejno prenesete na ločeno spletno mesto, da nenehno vidite trenutno različico glavnega), veje z izdajami, veje posebnih inovacij.
Po predogledu začasnih slik pride do potrebe po prevodu v proizvodnjo, razvijalci postavijo določeno oznako. Samodejno zbrano po oznaki sprosti sliko (njena oznaka ustreza oznaki iz Gita) in je uvedena v uprizoritev. Če ga služba za kakovost uspešno preveri, gre v proizvodnjo.
dapp
Vse opisano (rollout, sestavljanje slike, naknadno vzdrževanje) je mogoče implementirati samostojno z uporabo Bash skriptov in drugih "improviziranih" orodij. Toda če to storite, bo na neki točki izvedba povzročila veliko zapletenost in slabo nadzorljivost. Ko smo to razumeli, smo ustvarili lasten specializiran pripomoček za potek dela za gradnjo CI/CD - dapp.
Njegova izvorna koda je napisana v Rubyju, odprtokodna in objavljena na . Na žalost je dokumentacija trenutno najšibkejša točka orodja, vendar delamo na tem. In o dappu bomo pisali in govorili večkrat, ker ... Iskreno komaj čakamo, da svoje zmogljivosti delimo s celotno zainteresirano skupnostjo, medtem pa pošljite svoje težave in zahteve za vleko in/ali spremljajte razvoj projekta na GitHubu.
Posodobljeno 13. avgusta 2019: trenutno projekt dapp preimenovan v , njegova koda je bila popolnoma prepisana v Go, njegova dokumentacija pa je bila znatno izboljšana.
Kubernetes
Drugo že pripravljeno odprtokodno orodje, ki je že dobilo pomembno priznanje v strokovnem okolju, je Kubernetes, gruča za upravljanje Docker. Tema njegove uporabe pri delovanju projektov, zgrajenih na Dockerju, presega obseg poročila, zato je predstavitev omejena na pregled nekaterih zanimivih funkcij.
Za uvajanje Kubernetes ponuja:
- sonda pripravljenosti — preverjanje pripravljenosti nove različice aplikacije (za preklop prometa nanjo);
- tekoča posodobitev - zaporedna posodobitev slike v gruči vsebnikov (zaustavitev, posodobitev, priprava na zagon, preklapljanje prometa);
- sinhrono posodabljanje - posodabljanje slike v gruči z drugačnim pristopom: najprej na polovici vsebnikov, nato na preostalih;
- canary releases - zagon nove slike na omejenem (majhnem) številu kontejnerjev za spremljanje anomalij.
Ker Continuous Delivery ni samo izdaja nove različice, ima Kubernetes številne možnosti za naknadno vzdrževanje infrastrukture: vgrajeno spremljanje in beleženje vseh vsebnikov, samodejno skaliranje itd. Vse to že deluje in samo še čaka na ustrezno implementacijo v vaše procese.
Končna priporočila
- Uporabi Docker.
- Ustvarite Docker slike aplikacij za vse vaše potrebe.
- Sledite načelu "Infrastruktura je koda."
- Povežite Git z Dockerjem.
- Uredite vrstni red uvajanja.
- Uporabite že pripravljeno platformo (Kubernetes ali drugo).
Video posnetki in diapozitivi
Video z nastopa (približno uro) (samo poročilo se začne od 5. minute - sledite povezavi za predvajanje od tega trenutka).
Predstavitev poročila:
PS
Druga poročila o temi na našem blogu:
- «» (Dmitry Stolyarov; 27. maj 2019 na DevOpsConf);
- «» (Dmitry Stolyarov; 8. november 2018 na HighLoad++);
- «» (Dmitry Stolyarov; 7. november 2017 na HighLoad++);
- «» (Dmitry Stolyarov; 6. junij 2017 na RootConf).
Vir: www.habr.com