Ni komencos nian blogon per publikaĵoj bazitaj sur la plej novaj paroladoj de nia teknika direktoro (Dmitrij Stolyarov). Ĉiuj ili okazis en 2016 ĉe diversaj profesiaj eventoj kaj estis dediĉitaj al la temo DevOps kaj Docker. Unu filmeton de la kunveno de Docker Moskvo ĉe la oficejo de Badoo, ni jam havas Rete. Novaj estos akompanataj de artikoloj transdonantaj la esencon de la raportoj. Do…
La 31-an de majo ĉe la konferenco , okazigita kadre de la festivalo "Rusian Internet Technologies" (RIT++ 2016), la sekcio "Kontinua Deplojo kaj Deplojo" malfermiĝis kun la raporto "Plej bonaj Praktikoj de Kontinua Livero kun Docker". Ĝi resumis kaj sistemigis la plej bonajn praktikojn por konstrui Kontinuan Liveran (KD) procezon uzante Docker kaj aliajn Malfermfontajn produktojn. Ni laboras kun ĉi tiuj solvoj en produktado, kio permesas al ni fidi praktikan sperton.
Se vi havas la ŝancon pasigi horon , ni rekomendas spekti ĝin plene. Alie, sube estas la ĉefa resumo en tekstformo.
Kontinua Livero kun Docker
Sub Kontinua Transdono ni komprenas la ĉenon de eventoj kiel rezulto de kiu la aplika kodo de la Git-deponejo unue venas al produktado, kaj poste finiĝas en la arkivo. Ŝi aspektas jene: Git → Konstrui → Testi → Liberigi → Funkcii.
Plejparto de la raporto estas dediĉita al la konstrustadio (aplika asembleo), kaj la temoj liberigas kaj funkciigas estas mallonge tuŝitaj. Ni parolos pri problemoj kaj ŝablonoj, kiuj permesas vin solvi ilin, kaj la specifaj efektivigoj de ĉi tiuj ŝablonoj povas esti malsamaj.
Kial Docker estas bezonata ĉi tie entute? Ne vane ni decidis paroli pri Daŭraj Liveraj praktikoj en la kunteksto de ĉi tiu Malfermfonta ilo. Kvankam la tuta raporto estas dediĉita al ĝia uzo, multaj kialoj estas malkaŝitaj kiam oni konsideras la ĉefan ŝablonon de aplika kodo.
Ĉefa lanĉa ŝablono
Do, kiam ni lanĉas novajn versiojn de la aplikaĵo, ni certe alfrontas problemo de malfunkcio, generita dum ŝanĝado de la produktservilo. Trafiko de la malnova versio de la aplikaĵo al la nova ne povas tuj ŝanĝi: unue ni devas certigi, ke la nova versio estas ne nur sukcese elŝutita, sed ankaŭ "varmigita" (t.e., tute preta por servi petojn).
Tiel, dum iom da tempo ambaŭ versioj de la aplikaĵo (malnova kaj nova) funkcios samtempe. Kiu aŭtomate kondukas al konflikto pri komunaj rimedoj: reto, dosiersistemo, IPC, ktp. Kun Docker, ĉi tiu problemo estas facile solvita rulante malsamajn versiojn de la aplikaĵo en apartaj ujoj, por kiuj la izolado de rimedoj estas garantiita ene de la sama gastiganto (servilo/virtuala maŝino). Kompreneble, vi povas sukcesi per iuj lertaĵoj tute sen izolado, sed se ekzistas preta kaj oportuna ilo, tiam ekzistas la kontraŭa kialo - ne neglekti ĝin.
Kontenigo disponigas multajn aliajn avantaĝojn kiam deplojita. Ajna aplikaĵo dependas de specifa versio (aŭ versio gamo) interpretisto, havebleco de moduloj/etendaĵoj, ktp., same kiel iliaj versioj. Kaj ĉi tio validas ne nur por la tuja plenumebla medio, sed ankaŭ por la tuta medio, inkluzive sistema programaro kaj ĝia versio (ĝis la Linuksa distribuo uzata). Pro la fakto, ke ujoj enhavas ne nur aplikan kodon, sed ankaŭ antaŭinstalitan sistemon kaj aplikaĵon de la bezonataj versioj, vi povas forgesi pri problemoj kun dependecoj.
Ni resumu ĉefa lanĉa ŝablono novaj versioj konsiderante la jenajn faktorojn:
- Komence, la malnova versio de la aplikaĵo funkcias en la unua ujo.
- La nova versio tiam estas lanĉita kaj "varmigita" en dua ujo. Estas rimarkinde, ke ĉi tiu nova versio mem povas porti ne nur ĝisdatigitan aplikaĵokodon, sed ankaŭ ajnan el ĝiaj dependecoj, same kiel sistemajn komponantojn (ekzemple, nova versio de OpenSSL aŭ la tuta distribuo).
- Kiam la nova versio estas plene preta por servi petojn, trafiko ŝanĝas de la unua ujo al la dua.
- La malnova versio nun povas esti ĉesigita.
Ĉi tiu aliro de deploji malsamajn versiojn de la aplikaĵo en apartaj ujoj provizas alian oportunon - rapida retroiro al la malnova versio (finfine, sufiĉas ŝanĝi trafikon al la dezirata ujo).
La fina unua rekomendo sonas kiel io, pri kio eĉ la Kapitano ne povis trovi kulpon: "[dum organizado de Kontinua Livero kun Docker] Uzu Docker [kaj komprenu, kion ĝi donas]" Memoru, ĉi tio ne estas arĝenta kuglo, kiu solvos ĉiun problemon, sed ilo, kiu provizas mirindan fundamenton.
Reproduktebleco
Per "reproduktebleco" ni signifas ĝeneraligitan aron de problemoj renkontitaj dum funkciigado de aplikaĵoj. Ni parolas pri tiaj kazoj:
- Skriptoj kontrolitaj de la kvalita fako por enscenigo devas esti precize reproduktitaj en produktado.
- Aplikoj estas publikigitaj sur serviloj, kiuj povas ricevi pakaĵojn de malsamaj deponejo-speguloj (kun la tempo ili estas ĝisdatigitaj, kaj kun ili la versioj de instalitaj aplikaĵoj).
- "Ĉio funkcias por mi loke!" (...kaj programistoj ne estas permesitaj en produktadon.)
- Vi devas kontroli ion en la malnova (arkivita) versio.
- ...
Ilia ĝenerala esenco resumas al tio, ke necesas plena konformeco de la uzataj medioj (same kiel la foresto de la homa faktoro). Kiel ni povas garantii reprodukteblecon? Faru Docker-bildojn surbaze de kodo de Git, kaj poste uzu ilin por ajna tasko: en testejoj, en produktado, sur lokaj maŝinoj de programistoj... Samtempe gravas minimumigi la agojn, kiuj estas faritaj. после kunmeti la bildon: ju pli simpla ĝi estas, des malpli verŝajne estas eraroj.
Infrastrukturo estas kodo
Se la infrastrukturaj postuloj (havebleco de servila programaro, ĝia versio, ktp.) ne estas formaligitaj kaj "programitaj", tiam la lanĉo de iu ajn aplikaĵo ĝisdatigo povas rezultigi katastrofajn sekvojn. Ekzemple, en surscenigo vi jam ŝanĝis al PHP 7.0 kaj reskribis la kodon laŭe - tiam ĝia apero en produktado kun iu malnova PHP (5.5) certe surprizos iun. Vi eble ne forgesas pri grava ŝanĝo en la interpretista versio, sed "la diablo estas en la detaloj": la surprizo povas esti en eta ĝisdatigo de iu dependeco.
Aliro por solvi ĉi tiun problemon estas konata kiel IaC (Infrastrukturo kiel Kodo, "infrastrukturo kiel kodo") kaj implikas stoki infrastrukturpostulojn kune kun la aplika kodo. Uzante ĝin, programistoj kaj DevOps-specialistoj povas labori kun la sama Git-aplika deponejo, sed sur malsamaj partoj de ĝi. El ĉi tiu kodo, Docker-bildo estas kreita en Git, en kiu la aplikaĵo estas deplojita konsiderante ĉiujn specifaĵojn de la infrastrukturo. Simple dirite, la skriptoj (reguloj) por kunmeti bildojn devus esti en la sama deponejo kun la fontkodo kaj kunfanditaj.
En la kazo de plurtavola aplikaĵarkitekturo - ekzemple, ekzistas nginx, kiu staras antaŭ aplikaĵo jam funkcianta ene de Docker-ujo - Docker-bildoj devas esti kreitaj el kodo en Git por ĉiu tavolo. Tiam la unua bildo enhavos aplikaĵon kun interpretisto kaj aliaj "proksimaj" dependecoj, kaj la dua bildo enhavos la kontraŭfluan nginx.
Docker-bildoj, komunikado kun Git
Ni dividas ĉiujn Docker-bildojn kolektitajn de Git en du kategoriojn: provizorajn kaj eldonajn. Provizoraj bildoj etikeditaj per la nomo de la branĉo en Git, povas esti anstataŭitaj de la sekva kommit kaj estas eligitaj nur por antaŭrigardo (ne por produktado). Ĉi tio estas ilia ŝlosila diferenco de eldonoj: vi neniam scias, kiu specifa kommit estas en ili.
Ĝi havas sencon kolekti en provizorajn bildojn: la majstra branĉo (vi povas aŭtomate ruliĝi ĝin al aparta retejo por konstante vidi la nunan version de majstro), branĉoj kun eldonoj, branĉoj de specifaj novigoj.
Post kiam la antaŭrigardo de provizoraj bildoj venas al la bezono de tradukado en produktadon, la programistoj metas certan etikedon. Aŭtomate kolektite per etikedo liberigi bildon (ĝia etikedo respondas al la etikedo de Git) kaj estas eligita al enscenigo. Se ĝi estas sukcese kontrolita de la kvalita fako, ĝi iras al produktado.
paĉjo
Ĉio priskribita (elvolvo, bilda asembleo, posta prizorgado) povas esti efektivigita sendepende uzante Bash-skriptojn kaj aliajn "improvizitajn" ilojn. Sed se vi faras tion, tiam iam la efektivigo kondukos al granda komplekseco kaj malbona kontrolebleco. Komprenante ĉi tion, ni kreis nian propran specialecan Laborfluan ilon por konstrui CI/KD - paĉjo.
Ĝia fontkodo estas skribita en Ruby, malferma fonto kaj publikigita sur . Bedaŭrinde, dokumentado estas nuntempe la plej malforta punkto de la ilo, sed ni laboras pri ĝi. Kaj ni skribos kaj parolos pri la dapp pli ol unufoje, ĉar... Ni sincere ne povas atendi kunhavigi ĝiajn kapablojn kun la tuta interesita komunumo, sed dume, sendu viajn problemojn kaj tiru petojn kaj/aŭ sekvu la evoluon de la projekto en GitHub.
Ĝisdatigita la 13-an de aŭgusto 2019: nuntempe projekto paĉjo renomita al , ĝia kodo estis tute reverkita en Go, kaj ĝia dokumentado estis signife plibonigita.
Kubernetoj
Alia preta Malfermfonta ilo, kiu jam ricevis gravan rekonon en la profesia medio, estas Kubernetoj,Docker-administra areto. La temo de ĝia uzo en la funkciado de projektoj konstruitaj sur Docker estas preter la amplekso de la raporto, do la prezento estas limigita al superrigardo de iuj interesaj funkcioj.
Por lanĉo, Kubernetes ofertas:
- readiness probe — kontroli la pretecon de nova versio de la aplikaĵo (por ŝanĝi trafikon al ĝi);
- ruliĝanta ĝisdatigo - sinsekva bilda ĝisdatigo en aro de ujoj (malŝalto, ĝisdatigo, preparo por lanĉo, trafikŝanĝo);
- sinkrona ĝisdatigo - ĝisdatigi bildon en areto kun malsama aliro: unue sur duono de la ujoj, poste sur la resto;
- kanariaj eldonoj - lanĉante novan bildon sur limigita (malgranda) nombro da ujoj por monitori anomaliojn.
Ĉar Kontinua Livero ne nur estas la ĵeto de nova versio, Kubernetes havas kelkajn kapablojn por posta infrastruktura prizorgado: enkonstruita monitorado kaj protokolado por ĉiuj ujoj, aŭtomata skalo, ktp. Ĉio ĉi jam funkcias kaj nur atendas taŭgan. efektivigo en viaj procezoj.
Finaj rekomendoj
- Uzu Docker.
- Kreu Docker-bildojn de aplikaĵoj por ĉiuj viaj bezonoj.
- Sekvu la principon "Infrastrukturo estas kodo."
- Ligu Git al Docker.
- Reguli la ordon de lanĉo.
- Uzu pretan platformon (Kubernetes aŭ alian).
Filmetoj kaj diapozitivoj
Video de la prezentado (ĉirkaŭ horo) (la raporto mem komenciĝas de la 5-a minuto - sekvu la ligilon por ludi de ĉi tiu momento).
Prezento de la raporto:
PS
Aliaj raportoj pri la temo en nia blogo:
- «» (Dmitry Stolyarov; la 27-an de majo 2019 ĉe DevOpsConf);
- «» (Dmitry Stolyarov; la 8-an de novembro 2018 ĉe HighLoad++);
- «» (Dmitry Stolyarov; la 7-an de novembro 2017 ĉe HighLoad++);
- «» (Dmitry Stolyarov; junio 6, 2017 ĉe RootConf).
fonto: www.habr.com