27 maj në sallën kryesore të konferencës DevOpsConf 2019, e mbajtur në kuadër të festivalit , si pjesë e seksionit "Dorëzimi i vazhdueshëm", u dha një raport "werf - mjeti ynë për CI/CD në Kubernetes". Flet për ato problemet dhe sfidat me të cilat përballen të gjithë kur vendosen në Kubernetes, si dhe për nuancat që mund të mos vihen re menjëherë. Duke analizuar zgjidhjet e mundshme, ne tregojmë se si zbatohet kjo në një mjet me burim të hapur .
Që nga prezantimi, shërbimi ynë (i njohur më parë si dapp) ka arritur një moment historik të 1000 yje në GitHub — Shpresojmë që komuniteti i tij në rritje i përdoruesve do ta bëjë jetën më të lehtë për shumë inxhinierë DevOps.
Pra, le të prezantojmë (~47 minuta, shumë më informuese se artikulli) dhe ekstrakti kryesor prej tij në formë teksti. Shkoni!
Dorëzimi i kodit në Kubernetes
Biseda nuk do të jetë më për werf, por për CI/CD në Kubernetes, duke nënkuptuar që softueri ynë është i paketuar në kontejnerë Docker (Kam folur për këtë në ), dhe K8 do të përdoret për ta përdorur atë në prodhim (më shumë rreth kësaj në ).
Si duket dorëzimi në Kubernetes?
- Ekziston një depo Git me kodin dhe udhëzimet për ndërtimin e tij. Aplikacioni është ndërtuar në një imazh Docker dhe publikohet në Regjistrin Docker.
- I njëjti depo përmban gjithashtu udhëzime se si të vendoset dhe ekzekutohet aplikacioni. Në fazën e vendosjes, këto udhëzime i dërgohen Kubernetes, i cili merr imazhin e dëshiruar nga regjistri dhe e lëshon atë.
- Plus, zakonisht ka teste. Disa nga këto mund të bëhen kur publikoni një imazh. Ju gjithashtu mund (duke ndjekur të njëjtat udhëzime) të vendosni një kopje të aplikacionit (në një hapësirë të veçantë emri të K8s ose në një grup të veçantë) dhe të kryeni teste atje.
- Së fundi, ju nevojitet një sistem CI që merr ngjarje nga Git (ose klikimet e butonave) dhe thërret të gjitha fazat e përcaktuara: ndërtimi, publikimi, vendosja, testimi.
Këtu ka disa shënime të rëndësishme:
- Sepse ne kemi një infrastrukturë të pandryshueshme (infrastruktura e pandryshueshme), imazhi i aplikacionit që përdoret në të gjitha fazat (inskenimi, prodhimi, etj.), duhet të ketë një. Unë fola për këtë në mënyrë më të detajuar dhe me shembuj. .
- Sepse ne ndjekim infrastrukturën si qasje kodi (IaC), kodi i aplikacionit, udhëzimet për montimin dhe lëshimin e tij duhet të jenë pikërisht në një depo. Për më shumë informacion rreth kësaj, shihni .
- Zinxhiri i dorëzimit (dorëzimi) ne zakonisht e shohim kështu: aplikacioni u montua, u testua, u lëshua (faza e lëshimit) dhe kjo është ajo - dorëzimi ka ndodhur. Por në realitet, përdoruesi merr atë që keni nxjerrë, jo atëherë kur e dorëzove në prodhim, dhe kur ai mundi të shkonte atje dhe ky prodhim funksionoi. Kështu që unë besoj se zinxhiri i dërgesave përfundon vetëm në fazën operative (vrapim), ose më saktë, edhe në momentin kur kodi u hoq nga prodhimi (duke e zëvendësuar me një të ri).
Le të kthehemi te skema e mësipërme e dorëzimit në Kubernetes: ajo u shpik jo vetëm nga ne, por edhe fjalë për fjalë nga të gjithë ata që u morën me këtë problem. Në fakt, ky model tani quhet GitOps (mund të lexoni më shumë rreth termit dhe ideve pas tij ). Le të shohim fazat e skemës.
Ndërtimi i skenës
Duket se mund të flisni për ndërtimin e imazheve Docker në 2019, kur të gjithë dinë të shkruajnë Dockerfiles dhe të ekzekutojnë docker build?.. Këtu janë nuancat që do të doja t'i kushtoja vëmendje:
- Pesha e imazhit ka rëndësi, prandaj përdorni për të lënë në imazh vetëm aplikacionin që është vërtet i nevojshëm për operacionin.
- Numri i shtresave duhet të minimizohet duke kombinuar zinxhirët e
RUN-urdhëron sipas kuptimit. - Megjithatë, kjo shton probleme korrigjimi i gabimeve, sepse kur montimi prishet, duhet të gjeni komandën e duhur nga zinxhiri që shkaktoi problemin.
- Shpejtësia e montimit e rëndësishme sepse ne duam të nxjerrim shpejt ndryshimet dhe të shohim rezultatet. Për shembull, ju nuk dëshironi të rindërtoni varësitë në bibliotekat e gjuhëve sa herë që ndërtoni një aplikacion.
- Shpesh nga një depo Git që ju nevojitet shumë imazhe, të cilat mund të zgjidhen nga një grup Dockerfiles (ose faza të emërtuara në një skedar) dhe një skript Bash me montimin e tyre vijues.
Kjo ishte vetëm maja e ajsbergut me të cilin përballen të gjithë. Por ka probleme të tjera, në veçanti:
- Shpesh në fazën e montimit na duhet diçka montoj (për shembull, ruani rezultatin e një komande si apt në një drejtori të palëve të treta).
- Ne duam Ansible në vend që të shkruani me guaskë.
- Ne duam ndërtuar pa Docker (pse na duhet një makinë virtuale shtesë në të cilën duhet të konfigurojmë gjithçka për këtë, kur tashmë kemi një grup Kubernetes në të cilin mund të ekzekutojmë kontejnerë?).
- Montimi paralel, të cilat mund të kuptohen në mënyra të ndryshme: komanda të ndryshme nga Dockerfile (nëse përdoret shumëfazor), disa kryerje të të njëjtit depo, disa Dockerfiles.
- Asambleja e shpërndarë: Ne duam të mbledhim gjëra në bishtaja që janë "efemere" sepse cache e tyre zhduket, që do të thotë se duhet të ruhet diku veçmas.
- Më në fund emërova majën e dëshirave automagjike: Do të ishte ideale të shkoni në depo, të shkruani një komandë dhe të merrni një imazh të gatshëm, të mbledhur me një kuptim se si dhe çfarë të bëni saktë. Megjithatë, unë personalisht nuk jam i sigurt se të gjitha nuancat mund të parashikohen në këtë mënyrë.
Dhe këtu janë projektet:
- — një ndërtues nga Docker Inc (i integruar tashmë në versionet aktuale të Docker), i cili po përpiqet të zgjidhë të gjitha këto probleme;
- — një ndërtues nga Google që ju lejon të ndërtoni pa Docker;
- — Përpjekja e CNCF për të bërë magji automatike dhe, në veçanti, një zgjidhje interesante me ribazë për shtresat;
- dhe një mori shërbimesh të tjera, si p.sh , ...
...dhe shikoni sa yje kanë në GitHub. Kjo është, nga njëra anë, docker build ekziston dhe mund të bëjë diçka, por në realitet çështja nuk është zgjidhur plotësisht - Dëshmi për këtë është zhvillimi paralel i kolektorëve alternativë, secili prej të cilëve zgjidh një pjesë të problemeve.
Kuvendi në werf
Kështu arritëm (formerly si dapp) — Një mjet me kod të hapur nga kompania Flant, të cilin ne e kemi bërë për shumë vite. Gjithçka filloi 5 vjet më parë me skriptet Bash që optimizuan montimin e Dockerfiles dhe për 3 vitet e fundit zhvillimi i plotë është kryer në kuadrin e një projekti me depon e tij Git (së pari në Ruby, dhe më pas në Go, dhe në të njëjtën kohë u riemërua). Cilat çështje të montimit zgjidhen në werf?
Problemet e ngjyrosura në blu tashmë janë zbatuar, ndërtimi paralel është bërë brenda të njëjtit host dhe çështjet e theksuara në të verdhë janë planifikuar të përfundojnë deri në fund të verës.
Faza e publikimit në regjistër (publikim)
Ne thirrëm docker push... - çfarë mund të jetë e vështirë për ngarkimin e një imazhi në regjistër? Dhe pastaj lind pyetja: "Çfarë etikete duhet të vendos në imazh?" Ajo lind për arsyen që ne kemi Gitflow (ose strategji tjetër Git) dhe Kubernetes, dhe industria po përpiqet të sigurojë që ajo që ndodh në Kubernetes të ndjekë atë që ndodh në Git. Në fund të fundit, Git është burimi ynë i vetëm i së vërtetës.
Çfarë është kaq e vështirë për këtë? Siguroni riprodhueshmëri: nga një commit në Git, e cila është e pandryshueshme në natyrë (e pandryshueshme), në një imazh Docker, i cili duhet të mbahet i njëjtë.
Është gjithashtu e rëndësishme për ne përcaktoni origjinën, sepse duam të kuptojmë se nga cili commit është ndërtuar aplikacioni që ekzekutohet në Kubernetes (atëherë mund të bëjmë ndryshime dhe gjëra të ngjashme).
Strategjitë e etiketimit
E para është e thjeshtë dita e git. Ne kemi një regjistër me një imazh të etiketuar si 1.0. Kubernetes ka skenën dhe prodhimin, ku është ngarkuar kjo imazh. Në Git ne bëjmë commits dhe në një moment etiketojmë 2.0. Ne e mbledhim atë sipas udhëzimeve nga depoja dhe e vendosim në regjistër me etiketën 2.0. Ne e nxjerrim atë në skenë dhe, nëse gjithçka është mirë, atëherë në prodhim.
Problemi me këtë qasje është se ne fillimisht vendosëm etiketën dhe vetëm më pas e testuam dhe e lëshuam atë. Pse? Së pari, është thjesht e palogjikshme: ne po lëshojmë një version të softuerit që as nuk e kemi testuar ende (nuk mund të bëjmë ndryshe, sepse për të kontrolluar, duhet të vendosim një etiketë). Së dyti, kjo rrugë nuk është në përputhje me Gitflow.
Mundësia e dytë është git commit + etiketë. Dega master ka një etiketë 1.0; për të në regjistër - një imazh i vendosur në prodhim. Për më tepër, grupi Kubernetes ka konturet e pamjes paraprake dhe skenike. Më pas ndjekim Gitflow: në degën kryesore për zhvillim (develop) ne krijojmë veçori të reja, duke rezultuar në një angazhim me identifikuesin #c1. Ne e mbledhim atë dhe e publikojmë në regjistër duke përdorur këtë identifikues (#c1). Me të njëjtin identifikues ne hapemi për të parë paraprakisht. Ne bëjmë të njëjtën gjë me angazhimet #c2 и #c3.
Kur kuptuam se ka mjaft veçori, fillojmë të stabilizojmë gjithçka. Krijo një degë në Git release_1.1 (në bazë #c3 nga develop). Nuk ka nevojë të mblidhet ky version, sepse... kjo është bërë në hapin e mëparshëm. Prandaj, ne thjesht mund ta hapim atë në skenë. Ne rregullojmë defektet në #c4 dhe në mënyrë të ngjashme kaloni në skenë. Në të njëjtën kohë, zhvillimi është duke u zhvilluar në develop, nga ku merren periodikisht ndryshimet release_1.1. Në një moment, ne marrim një commit të përpiluar dhe ngarkuar në skenë, me të cilin jemi të kënaqur (#c25).
Pastaj bashkojmë (me fast-forward) degën e lëshimit (release_1.1) në master. Ne vendosëm një etiketë me versionin e ri në këtë commit (1.1). Por ky imazh është mbledhur tashmë në regjistër, kështu që për të mos e mbledhur përsëri, ne thjesht shtojmë një etiketë të dytë në imazhin ekzistues (tani ka etiketa në regjistër #c25 и 1.1). Pas kësaj, ne e hedhim atë në prodhim.
Ka një pengesë që vetëm një imazh është ngarkuar në skenë (#c25), dhe në prodhim është disi ndryshe (1.1), por ne e dimë se "fizikisht" këto janë të njëjtat imazhe nga regjistri.
Disavantazhi i vërtetë është se nuk ka mbështetje për bashkimet, ju duhet të bëni përpara.
Mund të shkojmë më tej dhe të bëjmë një mashtrim... Le të shohim një shembull të një Dockerfile të thjeshtë:
FROM ruby:2.3 as assets
RUN mkdir -p /app
WORKDIR /app
COPY . ./
RUN gem install bundler && bundle install
RUN bundle exec rake assets:precompile
CMD bundle exec puma -C config/puma.rb
FROM nginx:alpine
COPY --from=assets /app/public /usr/share/nginx/www/publicLe të ndërtojmë një skedar prej tij sipas parimit të mëposhtëm:
- SHA256 nga identifikuesit e imazheve të përdorura (
ruby:2.3иnginx:alpine), të cilat janë kontrolle të përmbajtjes së tyre; - të gjitha ekipet (
RUN,CMDdhe kështu me radhë.); - SHA256 nga skedarët që u shtuan.
... dhe merrni kontrollin (përsëri SHA256) nga një skedar i tillë. Kjo nënshkrim gjithçka që përcakton përmbajtjen e imazhit të Docker.
Le të kthehemi te diagrami dhe në vend të angazhimeve ne do të përdorim nënshkrime të tilla, d.m.th. etiketoni imazhet me nënshkrime.
Tani, kur është e nevojshme, për shembull, të bashkohen ndryshimet nga një version në master, ne mund të bëjmë një bashkim të vërtetë: ai do të ketë një identifikues të ndryshëm, por të njëjtin nënshkrim. Me të njëjtin identifikues ne do ta nxjerrim imazhin në prodhim.
Disavantazhi është se tani nuk do të jetë e mundur të përcaktohet se çfarë lloj angazhimi u shty në prodhim - shumat e kontrollit funksionojnë vetëm në një drejtim. Ky problem zgjidhet nga një shtresë shtesë me metadata - do t'ju tregoj më shumë më vonë.
Etiketimi në werf
Në werf shkuam edhe më tej dhe po përgatitemi të bëjmë një ndërtim të shpërndarë me një cache që nuk ruhet në një makinë... Pra, po ndërtojmë dy lloje imazhesh Docker, i quajmë fazë и imazh.
Depoja werf Git ruan udhëzime specifike për ndërtimin që përshkruajnë fazat e ndryshme të ndërtimit (para instalimit, instaloj, përpara konfigurimit, Setup). Ne mbledhim imazhin e fazës së parë me një nënshkrim të përcaktuar si kontrolli i hapave të parë. Më pas shtojmë kodin burimor, për imazhin e fazës së re llogarisim kontrollin e tij... Këto operacione përsëriten për të gjitha fazat, si rezultat i të cilave marrim një grup imazhesh të skenës. Më pas bëjmë imazhin përfundimtar, i cili gjithashtu përmban meta të dhëna për origjinën e tij. Dhe ne e etiketojmë këtë imazh në mënyra të ndryshme (detajet më vonë).
Supozoni se pas kësaj shfaqet një commit i ri në të cilin është ndryshuar vetëm kodi i aplikacionit. Çfarë do të ndodhë? Për ndryshimet e kodit, do të krijohet një patch dhe do të përgatitet një imazh i ri i fazës. Nënshkrimi i tij do të përcaktohet si shuma e kontrollit të imazhit të skenës së vjetër dhe patch-it të ri. Një imazh i ri përfundimtar do të formohet nga ky imazh. Sjellje e ngjashme do të ndodhë me ndryshime në faza të tjera.
Kështu, imazhet e skenës janë një cache që mund të ruhet në mënyrë të shpërndarë, dhe imazhet e krijuara tashmë prej saj ngarkohen në Regjistrin Docker.
Pastrimi i regjistrit
Ne nuk po flasim për fshirjen e shtresave që mbetën të varura pas etiketave të fshira - kjo është një veçori standarde e vetë Regjistrit Docker. Po flasim për një situatë kur grumbullohen shumë etiketa Docker dhe kuptojmë që disa prej tyre nuk na duhen më, por ato zënë hapësirë (dhe/ose paguajmë për të).
Cilat janë strategjitë e pastrimit?
- Ju thjesht nuk mund të bëni asgjë mos pastro. Ndonjëherë është me të vërtetë më e lehtë të paguash pak për hapësirë shtesë sesa të zgjidhësh një lëmsh të madh etiketash. Por kjo funksionon vetëm deri në një pikë të caktuar.
- Rivendosja e plotë. Nëse fshini të gjitha imazhet dhe rindërtoni vetëm ato aktuale në sistemin CI, mund të lindë një problem. Nëse kontejneri riniset në prodhim, një imazh i ri do të ngarkohet për të - një që nuk është testuar ende nga askush. Kjo vret idenë e infrastrukturës së pandryshueshme.
- BLU jeshile. Një regjistër filloi të tejmbushet - ne ngarkojmë imazhe në një tjetër. I njëjti problem si në metodën e mëparshme: në cilën pikë mund të pastroni regjistrin që ka filluar të tejmbushet?
- Nga koha. Të fshihen të gjitha imazhet më të vjetra se 1 muaj? Por patjetër do të ketë një shërbim që nuk është përditësuar prej një muaji...
- manualisht përcaktoni se çfarë mund të fshihet tashmë.
Ekzistojnë dy opsione vërtet të zbatueshme: mos e pastroni ose një kombinim blu-jeshile + me dorë. Në rastin e fundit, ne po flasim për sa vijon: kur e kuptoni se është koha për të pastruar regjistrin, krijoni një të ri dhe shtoni të gjitha imazhet e reja në të gjatë, për shembull, një muaji. Dhe pas një muaji, shikoni se cilat pods në Kubernetes ende përdorin regjistrin e vjetër dhe transferojini ato gjithashtu në regjistrin e ri.
Në çfarë kemi ardhur werf? Ne mbledhim:
- Kreu i Git: të gjitha etiketat, të gjitha degët - duke supozuar se ne kemi nevojë për gjithçka që është etiketuar në Git në imazhe (dhe nëse jo, atëherë duhet ta fshijmë atë në vetë Git);
- të gjitha pods që pompohen aktualisht në Kubernetes;
- ReplicaSets të vjetra (ajo që u publikua së fundmi), dhe ne gjithashtu planifikojmë të skanojmë publikimet e Helm dhe të zgjedhim imazhet më të fundit atje.
... dhe bëni një listë të bardhë nga ky grup - një listë imazhesh që nuk do t'i fshijmë. Ne pastrojmë gjithçka tjetër, pas së cilës gjejmë imazhe të skenës jetime dhe i fshijmë gjithashtu.
Faza e vendosjes
Deklarativitet i besueshëm
Pika e parë që do të doja të tërhiqja vëmendjen në vendosjen është nxjerrja e konfigurimit të burimeve të përditësuara, të deklaruara në mënyrë deklarative. Dokumenti origjinal YAML që përshkruan burimet e Kubernetes është gjithmonë shumë i ndryshëm nga rezultati që ekzekutohet në të vërtetë në grup. Sepse Kubernetes shton konfigurimin:
- identifikues;
- informacion për shërbimin;
- shumë vlera të paracaktuara;
- seksioni me statusin aktual;
- ndryshimet e bëra si pjesë e lidhjes së internetit të pranimit;
- rezultati i punës së kontrollorëve të ndryshëm (dhe planifikuesit).
Prandaj, kur shfaqet një konfigurim i ri burimi (i ri), ne nuk mund thjesht të marrim dhe të mbishkruajmë konfigurimin aktual, "live" me të (jetoj). Për ta bërë këtë do të duhet të krahasojmë i ri me konfigurimin e fundit të aplikuar (i fundit i aplikuar) dhe rrokulliset mbi jetoj arnimi i marrë.
Kjo qasje quhet Bashkim 2-kahësh. Përdoret, për shembull, në Helm.
Ka edhe Bashkim 3-kahësh, e cila ndryshon në atë:
- duke krahasuar i fundit i aplikuar и i ri, shikojmë atë që u fshi;
- duke krahasuar i ri и jetoj, shikojmë se çfarë është shtuar ose ndryshuar;
- aplikohet arnimi i përmbledhur jetoj.
Ne vendosim mbi 1000 aplikacione me Helm, kështu që ne në fakt jetojmë me bashkimin e dyanshëm. Megjithatë, ajo ka një sërë problemesh që ne i kemi zgjidhur me arnimet tona, të cilat e ndihmojnë Helm të punojë normalisht.
Statusi real i paraqitjes
Pasi sistemi ynë CI gjeneron një konfigurim të ri për Kubernetes bazuar në ngjarjen tjetër, ai e transmeton atë për përdorim (aplikoni) në një grup - duke përdorur Helm ose kubectl apply. Më tej, ndodh bashkimi i përshkruar tashmë N-way, të cilit API Kubernetes i përgjigjet në mënyrë miratuese sistemit CI, dhe atij përdoruesit të tij.
Sidoqoftë, ekziston një problem i madh: në fund të fundit aplikimi i suksesshëm nuk do të thotë lëshim i suksesshëm. Nëse Kubernetes kupton se çfarë ndryshimesh duhen zbatuar dhe e zbaton atë, ne ende nuk e dimë se cili do të jetë rezultati. Për shembull, përditësimi dhe rinisja e pods në frontend mund të jetë i suksesshëm, por jo në backend, dhe ne do të marrim versione të ndryshme të imazheve të aplikacionit që ekzekutohen.
Për të bërë gjithçka në mënyrë korrekte, kjo skemë kërkon një lidhje shtesë - një gjurmues special që do të marrë informacionin e statusit nga Kubernetes API dhe do ta transmetojë atë për analiza të mëtejshme të gjendjes reale të gjërave. Ne krijuam një bibliotekë me burim të hapur në Go - (shih njoftimin e tij ), e cila e zgjidh këtë problem dhe është e ndërtuar në werf.
Sjellja e këtij gjurmuesi në nivelin werf është konfiguruar duke përdorur shënime që vendosen në Deployments ose StatefulSets. Shënimi kryesor - fail-mode - kupton këto kuptime:
-
IgnoreAndContinueDeployProcess— ne i shpërfillim problemet e nxjerrjes së këtij komponenti dhe vazhdojmë vendosjen; -
FailWholeDeployProcessImmediately— një gabim në këtë komponent ndalon procesin e vendosjes; -
HopeUntilEndOfDeployProcess— Shpresojmë që ky komponent të funksionojë deri në fund të vendosjes.
Për shembull, ky kombinim i burimeve dhe vlerave të shënimeve fail-mode:
Kur vendosemi për herë të parë, baza e të dhënave (MongoDB) mund të mos jetë ende gati - Vendosjet do të dështojnë. Por mund të prisni momentin që të fillojë dhe vendosja do të vazhdojë të ndodhë.
Ka edhe dy shënime të tjera për kubedog në werf:
-
failures-allowed-per-replica— numri i rënieve të lejuara për çdo kopje; -
show-logs-until— rregullon momentin deri në të cilin werf shfaq (në stdout) regjistrat nga të gjitha podet e mbështjella. Parazgjedhja ështëPodIsReady(për të injoruar mesazhet që ndoshta nuk i duam kur trafiku fillon të vijë në pod), por vlerat janë gjithashtu të vlefshme:ControllerIsReadyиEndOfDeploy.
Çfarë tjetër duam nga vendosja?
Përveç dy pikave të përshkruara tashmë, ne dëshirojmë:
- për të parë trungje - dhe vetëm ato të nevojshme, dhe jo gjithçka me radhë;
- udhë progres, sepse nëse puna qëndron "në heshtje" për disa minuta, është e rëndësishme të kuptoni se çfarë po ndodh atje;
- иметь kthim automatik në rast se diçka shkon keq (dhe për këtë arsye është kritike të dihet statusi real i vendosjes). Përhapja duhet të jetë atomike: ose shkon deri në fund, ose çdo gjë kthehet në gjendjen e mëparshme.
Rezultatet e
Për ne si kompani, për të zbatuar të gjitha nuancat e përshkruara në faza të ndryshme të ofrimit (ndërtimi, publikimi, vendosja), mjafton një sistem CI dhe shërbimi. .
Në vend të përfundimit:
Me ndihmën e werf, ne kemi bërë përparim të mirë në zgjidhjen e një numri të madh problemesh për inxhinierët DevOps dhe do të ishim të lumtur nëse komuniteti i gjerë të paktën do ta provonte këtë mjet në veprim. Do të jetë më e lehtë për të arritur një rezultat të mirë së bashku.
Video dhe sllajde
Video nga performanca (~47 minuta):
Prezantimi i raportit:
PS
Raporte të tjera rreth Kubernetes në blogun tonë:
- «» (Dmitry Stolyarov; 27 Prill 2019 në "Strike");
- «» (Andrey Polovov; 8 Prill 2019 në Saint HighLoad++);
- «» (Dmitry Stolyarov; 8 nëntor 2018 në HighLoad++);
- «» (Dmitry Stolyarov; 28 maj 2018 në RootConf);
- «» (Dmitry Stolyarov; 7 nëntor 2017 në HighLoad++);
- «» (Dmitry Stolyarov; 6 qershor 2017 në RootConf).
Burimi: www.habr.com