werf - eisen Tool fir CI / CD zu Kubernetes (Iwwerbléck a Videobericht)

Mee 27 an der Haaptsall vun der DevOpsConf 2019 Konferenz, am Kader vum Festival ofgehalen RIT++ 2019, am Kader vun der Rubrik "Continuous Delivery" gouf e Bericht "werf - our tool for CI/CD in Kubernetes". Et schwätzt iwwer déi Problemer an Erausfuerderungen, déi jidderee konfrontéiert beim Ofbau op Kubernetes, wéi och iwwer Nuancen, déi vläicht net direkt bemierkbar sinn. Analyséiere méiglech Léisungen, mir weisen wéi dëst an engem Open Source Tool ëmgesat gëtt werf.

Zënter der Presentatioun huet eis Utility (fréier als Dapp bekannt) en historesche Meilesteen erreecht 1000 Stären op GitHub - mir hoffen datt seng wuessend Gemeinschaft vu Benotzer d'Liewe méi einfach mécht fir vill DevOps Ingenieuren.

Also, loosst eis virstellen Video vum Bericht (~ 47 Minutten, vill méi informativ wéi den Artikel) an den Haaptextrakt dovunner an Textform. Gitt!

Liwweren Code zu Kubernetes

D'Diskussioun wäert net méi iwwer werf goen, mee iwwer CI/CD zu Kubernetes, wat implizéiert datt eis Software an Docker Container verpackt ass (Ech hunn iwwer dëst geschwat an Rapport 2016), an K8s wäert benotzt ginn et zu Produktioun lafen (méi iwwer dëst an 2017 Joer).

Wéi gesäit d'Liwwerung zu Kubernetes aus?

• Et gëtt e Git Repository mam Code an Instruktioune fir et ze bauen. D'Applikatioun ass an engem Docker Bild agebaut an am Docker Registry publizéiert.
• Dee selwechte Repository enthält och Instruktioune wéi d'Applikatioun z'installéieren an ausféiert. An der Installatiounsstadium ginn dës Instruktiounen un Kubernetes geschéckt, déi de gewënschte Bild aus der Registry kritt an et lancéiert.
• Plus, et ginn normalerweis Tester. E puer vun dësen kënne gemaach ginn wann Dir e Bild publizéiert. Dir kënnt och (no déiselwecht Instruktiounen) eng Kopie vun der Applikatioun ofsetzen (an engem separaten K8s Nummraum oder engem separaten Cluster) an Tester do lafen.
• Schlussendlech braucht Dir e CI System deen Eventer vu Git kritt (oder Knäppercher) an all déi designéiert Etappen nennt: bauen, publizéieren, deployéieren, testen.

Et ginn e puer wichteg Notizen hei:

1. Well mir hunn eng onverännerbar Infrastruktur (onverännerbar Infrastruktur), d'Applikatiounsbild dat an alle Stadien benotzt gëtt (Staging, Produktioun, asw.), et muss een sinn. Ech hunn iwwer dëst méi detailléiert a mat Beispiller geschwat. hei.
2. Well mir verfollegen d'Infrastruktur als Code Approche (IaC), den Applikatiounscode, d'Instruktioune fir ze montéieren an ze lancéieren sollten sinn genee an engem Repository. Fir méi Informatiounen iwwer dëst, kuckt déi selwecht Rapport.
3. Liwwerung Kette (Liwwerung) mir gesinn et normalerweis esou: d'Applikatioun gouf zesummegesat, getest, verëffentlecht (Verëffentlechungsstadium) an dat ass et - d'Liwwerung ass stattfonnt. Awer a Wierklechkeet kritt de Benotzer wat Dir ausgerullt hutt, Net dann wann Dir et zu Produktioun geliwwert, a wann hien dohinner goe konnt an dës Produktioun geschafft. Also ech gleewen datt d'Liwwerungskette endet nëmmen an der operationell Etapp (lafen), oder méi präzis, och am Moment wou de Code aus der Produktioun geläscht gouf (ersetzt et mat engem neien).

Loosst eis zréck op déi uewe genannte Liwwerschema zu Kubernetes: et gouf net nëmme vun eis erfonnt, mee vu wuertwiertlech jiddereen deen mat dësem Problem behandelt huet. Tatsächlech gëtt dëst Muster elo GitOps genannt (Dir kënnt méi iwwer de Begrëff an d'Iddien hannendrun liesen hei). Loosst eis d'Etappe vum Schema kucken.

Etapp bauen

Et géif schéngen datt Dir iwwer Docker-Biller am Joer 2019 schwätze kënnt, wa jidderee weess wéi een Dockerfiles schreift a lafen docker build?.. Hei sinn d'Nuancen op déi ech gären oppassen:

1. Bild Gewiicht wichteg, also benotzen Multi-Etappfir am Bild nëmmen d'Applikatioun ze loossen déi wierklech fir d'Operatioun néideg ass.
2. Zuel vun Schichten muss miniméiert ginn duerch Kombinatioun vun Ketten vun RUN-Commande no Bedeitung.
3. Allerdéngs füügt dëst Problemer Debugging, Well wann d'Versammlung klappt, musst Dir de richtege Kommando aus der Kette fannen, déi de Problem verursaacht huet.
4. Assemblée Vitesse wichteg well mir séier Ännerungen wëllen ausrollen an d'Resultater gesinn. Zum Beispill, Dir wëllt net Ofhängegkeeten a Sproochbibliothéiken opbauen all Kéier wann Dir eng Applikatioun baut.
5. Dacks vun engem Git Repository Dir braucht vill Biller, déi duerch e Set vun Dockerfiles (oder benannte Stadien an enger Datei) an engem Bash Skript mat hirer sequentieller Versammlung geléist kënne ginn.

Dëst war just den Tipp vum Äisbierg mat deem jidderee konfrontéiert ass. Awer et ginn aner Probleemer, besonnesch:

1. Dacks brauche mir op der Montagestadium eppes montéieren (zum Beispill, Cache d'Resultat vun engem Kommando wéi apt an engem Drëtt Partei Verzeechnes).
2. Mir wëllen Sicht amplaz an der Schuel ze schreiwen.
3. Mir wëllen bauen ouni Docker (firwat brauche mir eng zousätzlech virtuell Maschinn, an där mir alles dofir musse konfiguréieren, wa mir schonn e Kubernetes-Cluster hunn, an deem mir Container kënne lafen?).
4. Parallel Assemblée, déi op verschidde Manéiere verstane kënne ginn: verschidde Kommandoen aus der Dockerfile (wann Multi-Stage benotzt gëtt), verschidde Verpflichtungen vum selwechte Repository, verschidde Dockerfiles.
5. Verdeelt Versammlung: Mir wëllen Saachen an Pods sammelen déi "ephemeral" sinn, well hire Cache verschwënnt, dat heescht et muss iergendwou separat gespäichert ginn.
6. Schlussendlech hunn ech den Héichpunkt vun de Wënsch genannt automagic: Et wier ideal fir an de Repository ze goen, e Kommando ze tippen an e fäerdegt Bild ze kréien, zesummegesat mat engem Verständnis vu wéi a wat richteg ze maachen. Ech perséinlech sinn awer net sécher, datt all Nuancen esou virausgesinn sinn.

An hei sinn d'Projeten:

• moby/buildkit - e Builder vun Docker Inc (schonn integréiert an aktuell Versioune vum Docker), dee probéiert all dës Problemer ze léisen;
• kaniko - e Builder vu Google deen Iech erlaabt ouni Docker ze bauen;
• Buildpacks.io - De Versuch vum CNCF fir automatesch Magie ze maachen a besonnesch eng interessant Léisung mat Rebase fir Schichten;
• an eng Rëtsch aner Utilities, wéi z bauen, genuinetools/img...

... a kuckt wéivill Stären se op GitHub hunn. Dat heescht, engersäits, docker build existéiert a kann eppes maachen, awer an der Realitéit de Problem ass net komplett geléist - Beweis dofir ass d'parallel Entwécklung vun alternativen Sammler, déi jidderee en Deel vun de Problemer léist.

Assemblée zu werf

Also hu mir bis werf (virdrun berühmt wéi dapp) - En Open Source Utility vun der Flant Firma, déi mir zënter ville Joere maachen. Et huet alles ugefaang viru 5 Joer mat Bash Scripten déi d'Versammlung vun Dockerfiles optimiséiert hunn, a fir déi lescht 3 Joer ass vollwäerteg Entwécklung am Kader vun engem Projet mat sengem eegene Git Repository duerchgefouert ginn. (éischt am Ruby, an dann ëmgeschriwwen ze goen, a gläichzäiteg ëmbenannt). Wat Assemblée Problemer sinn an werf geléist?

D'Problemer, déi a blo schaarf sinn, si scho implementéiert, de parallele Bau gouf am selwechte Host gemaach, an d'Problemer, déi a giel markéiert sinn, si geplangt bis Enn vum Summer ofgeschloss ze ginn.

Etapp vun der Verëffentlechung am Registry (publicéieren)

Mir hu geruff docker push... - wat kéint schwéier sinn e Bild an d'Registry eropzelueden? An da stellt sech d'Fro: "Wéi eng Tag soll ech op d'Bild setzen?" Et entsteet aus dem Grond datt mir hunn Gitflow (oder aner Git Strategie) a Kubernetes, an d'Industrie probéiert sécherzestellen datt wat an Kubernetes geschitt ass wat am Git geschitt. No allem ass Git eis eenzeg Quell vun der Wourecht.

Wat ass sou schwéier un dësem? Garantéiert d'Reproduktioun: vun engem Engagement am Git, deen an der Natur onverännerbar ass (onverännerbar), zu engem Docker-Bild, dat sollt d'selwecht bleiwen.

Et ass och wichteg fir eis bestëmmen Urspronk, well mir wëlle verstoen aus wéi eng Verpflichtung d'Applikatioun déi am Kubernetes leeft gebaut gouf (da kënne mir Differenzen an ähnlech Saachen maachen).

Tagging Strategien

Déi éischt ass einfach git tag. Mir hunn e Registry mat engem Bild markéiert als 1.0. Kubernetes huet Bühn a Produktioun, wou dëst Bild eropgeluede gëtt. Am Git maache mir Verpflichtungen a mir taggen iergendwann 2.0. Mir sammelen et no den Instruktioune vum Repository a setzen se an de Registry mam Tag 2.0. Mir rullen et op d'Bühn an, wann alles gutt ass, dann op d'Produktioun.

De Problem mat dëser Approche ass datt mir fir d'éischt den Tag setzen, an nëmmen dann getest a gerullt hunn. Firwat? Als éischt ass et einfach onlogesch: mir ginn eng Versioun vu Software eraus, déi mir nach net getest hunn (mir kënnen net anescht maachen, well fir ze kontrolléieren, musse mir e Tag setzen). Zweetens ass dëse Wee net kompatibel mat Gitflow.

Déi zweet Optioun - git commit + tag. D'Meeschtesch Branche huet e Tag 1.0; fir et am Registry - e Bild op d'Produktioun ofgesat. Zousätzlech huet de Kubernetes Cluster Virschau an Inszenéierungskonturen. Als nächst verfollege mir Gitflow: an der Haaptbranche fir Entwécklung (develop) mir maachen nei Fonctiounen, wat zu engem Engagement mam Identifizéierer resultéiert #c1. Mir sammelen et a publizéieren et am Registry mat dësem Identifizéierer (#c1). Mat deemselwechten Identifizéierer rulle mir aus fir ze kucken. Mir maachen datselwecht mat Verpflichtungen #c2 и #c3.

Wann mir gemierkt hunn, datt et genuch Fonctiounen sinn, mir fänken alles ze stabiliséieren. Erstellt eng Filial am Git release_1.1 (op der Basis #c3 aus develop). Et ass net néideg dës Verëffentlechung ze sammelen, well ... dëst gouf am virege Schrëtt gemaach. Dofir kënne mir et einfach op d'Inszenéierung rullen. Mir fixen Bugs an #c4 an ähnlech ausrollen op d'Bühn. Zur selwechter Zäit ass d'Entwécklung amgaang develop, wou Ännerungen periodesch geholl ginn release_1.1. Iergendwann kréie mir eng Verpflichtung kompiléiert an op d'Staging eropgelueden, mat deem mir frou sinn (#c25).

Da fusionéiere mir (mat Fast-Forward) d'Verëffentlechungszweige (release_1.1) am Meeschter. Mir setzen en Tag mat der neier Versioun op dësem Engagement (1.1). Awer dëst Bild ass schonn am Registry gesammelt, also fir et net erëm ze sammelen, addéiere mer einfach en zweeten Tag op dat existent Bild (elo huet et Tags am Registry #c25 и 1.1). Duerno rullen mir et an d'Produktioun aus.

Et gëtt en Nodeel datt nëmmen ee Bild op d'Staging eropgeluede gëtt (#c25), an an der Produktioun ass et anescht (1.1), awer mir wëssen datt "physesch" dëst datselwecht Bild aus der Registry sinn.

De richtege Nodeel ass datt et keng Ënnerstëtzung fir Fusiounsverpflichtungen ass, Dir musst séier viru maachen.

Mir kënne méi wäit goen an en Trick maachen ... Loosst eis e Beispill vun engem einfachen Dockerfile kucken:

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/public

Loosst eis e Fichier dovunner bauen no dem folgende Prinzip:

• SHA256 vun den Identifizéierer vun de benotzte Biller (ruby:2.3 и nginx:alpine), déi Kontrollsumme vun hirem Inhalt sinn;
• all Équipen (RUN, CMD a sou weider.);
• SHA256 aus Dateien déi dobäigesat goufen.

... an huelt de Checksum (erëm SHA256) aus esou engem Fichier. Dëst Ënnerschrëft alles wat den Inhalt vum Docker Bild definéiert.

Loosst eis zréck op d'Diagramm an amplaz engagéiert wäerte mir esou Ënnerschrëften benotzen, d.h. Tag Biller mat Ënnerschrëften.

Elo, wann et néideg ass, zum Beispill, Ännerungen vun enger Verëffentlechung op Meeschter ze fusionéieren, kënne mir e richtege Fusiounsverpflichtung maachen: et wäert en aneren Identifizéierer hunn, awer déiselwecht Ënnerschrëft. Mat deemselwechten Identifizéierer wäerte mir d'Bild op d'Produktioun rullen.

Den Nodeel ass datt et elo net méiglech ass ze bestëmmen wat fir eng Engagement op d'Produktioun gedréckt gouf - d'Checksumme funktionnéieren nëmmen an eng Richtung. Dëse Problem gëtt duerch eng zousätzlech Schicht mat Metadaten geléist - ech soen Iech méi spéit méi.

Tagging in werf

Zu werf si mir nach méi wäit gaang a si preparéiere fir e verdeelt Build mat engem Cache ze maachen deen net op enger Maschinn gespäichert ass ... Also, mir bauen zwou Zorte vun Docker Biller, mir nennen se Etapp и Bild.

De werf Git Repository späichert Bauspezifesch Instruktiounen déi déi verschidden Etappe vum Bau beschreiwen (virun Installéieren, installéieren, virum Setup, ageriicht). Mir sammelen déi éischt Stuf Bild mat enger Ënnerschrëft definéiert als Checksum vun den éischte Schrëtt. Dann addéiere mer de Quellcode, fir dat neit Bühnbild berechene mir seng Kontrollsumme ... Dës Operatioune gi fir all Etappe widderholl, als Resultat vun deem mir e Set vu Bühnebiller kréien. Da maache mir dat lescht Bild, dat och Metadaten iwwer hiren Hierkonft enthält. A mir markéieren dëst Bild op verschidde Manéieren (Detailer méi spéit).

Ugeholl datt duerno en neien Engagement erschéngt an deem nëmmen den Uwendungscode geännert gouf. Wat wäert geschéien? Fir Code Ännerungen gëtt e Patch erstallt an en neit Bühnbild gëtt virbereet. Seng Ënnerschrëft gëtt als Checksum vum alen Bühnbild an dem neie Patch bestëmmt. En neit lescht Bild gëtt aus dësem Bild geformt. Ähnlech Verhalen wäert geschéien mat Ännerungen an anere Stadien.

Also, Bühnebiller sinn e Cache, dee verdeelt ka gespäichert ginn, an d'Biller, déi scho erstallt goufen, ginn an den Docker Registry eropgelueden.

Botzen vum Registry

Mir schwätzen net iwwer d'Läsche vun Schichten déi no geläscht Tags hänke bliwwen - dëst ass eng Standard Feature vum Docker Registry selwer. Mir schwätzen iwwer eng Situatioun wou vill Docker Tags accumuléieren a mir verstinn datt mir e puer vun hinnen net méi brauchen, awer se huelen Plaz op (an/oder mir bezuelen dofir).

Wat sinn d'Botzstrategien?

1. Dir kënnt just näischt maachen net botzen. Heiansdo ass et wierklech méi einfach e bëssen fir extra Plaz ze bezuelen wéi e risege Wirbel vun Tags z'entdecken. Awer dëst funktionnéiert nëmme bis zu engem gewësse Punkt.
2. Voll reset. Wann Dir all Biller läscht an nëmmen déi aktuell am CI System opbaut, kann e Problem entstoen. Wann de Container an der Produktioun nei gestart gëtt, gëtt en neit Bild dofir gelueden - een deen nach net vu jidderengem getest gouf. Dëst killt d'Iddi vun onverännerbarer Infrastruktur ëm.
3. Blo-gréng. Ee Registry huet ugefaang ze iwwerflësseg - mir lued Biller op eng aner erop. Dee selwechte Problem wéi an der viregter Method: op wéi engem Punkt kënnt Dir de Registry läschen, deen ugefaang huet ze iwwerlafen?
4. No der Zäit. All Biller méi al wéi 1 Mount läschen? Awer et wäert definitiv e Service ginn deen zënter engem Mount net aktualiséiert gouf ...
5. Manuell bestëmmen wat scho geläscht ka ginn.

Et ginn zwou wierklech liewensfäeg Optiounen: net botzen oder eng Kombinatioun vu blo-gréng + manuell. Am leschte Fall schwätze mir iwwer déi folgend: Wann Dir versteet datt et Zäit ass de Registry ze botzen, erstellt Dir en neit a füügt all nei Biller derbäi am Laf vun zum Beispill engem Mount. A no engem Mount, kuckt wéi eng Pods an Kubernetes nach ëmmer déi al Registry benotzen, a transferéiert se och an déi nei Registry.

Wat sinn mir komm werf? Mir sammelen:

1. Git Head: all Tags, all Branchen - unzehuelen datt mir alles brauchen wat am Git an de Biller markéiert ass (a wann net, da musse mir et am Git selwer läschen);
2. all Pods déi momentan op Kubernetes gepompelt ginn;
3. al ReplicaSets (wat viru kuerzem verëffentlecht gouf), a mir plangen och Helm Verëffentlechungen ze scannen a wielt déi lescht Biller do.

... a maacht eng Wäisslëscht aus dësem Set - eng Lëscht vu Biller déi mir net läschen. Mir botzen alles anescht, duerno fanne mir orphan Bühnbilder a läschen se och.

Deploy Stage

Zouverlässeg Deklarativitéit

Den éischte Punkt deen ech gären opmierksam maachen an der Deployment ass d'Rollout vun der aktualiséierter Ressourcekonfiguratioun, deklarativ deklaréiert. D'Original YAML Dokument Kubernetes Ressourcen beschreift ass ëmmer ganz anescht wéi d'Resultat tatsächlech am Cluster lafen. Well Kubernetes der Konfiguratioun bäidréit:

1. Identifizéierer;
2. Service Informatiounen;
3. vill Default Wäerter;
4. Sektioun mat aktuellen Zoustand;
5. Ännerungen gemaach als Deel vun der Entrée Webhook;
6. d'Resultat vun der Aarbecht vu verschiddene Controller (an dem Scheduler).

Dofir, wann eng nei Ressourcekonfiguratioun erschéngt (nei), kënne mir net nëmmen déi aktuell, "live" Konfiguratioun mat him huelen an iwwerschreiwen (liewen). Fir dëst ze maachen, musse mir vergläichen nei mat der lescht applizéierter Konfiguratioun (lescht applizéiert) a rullt op liewen krut Patch.

Dës Approche gëtt genannt 2-Wee Fusioun. Et gëtt zum Beispill an Helm benotzt.

Et gëtt och 3-Wee Fusioun, déi ënnerscheet sech an deem:

• vergläichen lescht applizéiert и nei, mir kucken op wat geläscht gouf;
• vergläichen nei и liewen, mir kucken wat dobäi oder geännert gouf;
• de summéierten Patch gëtt ugewannt liewen.

Mir deployéieren 1000+ Uwendungen mat Helm, sou datt mir tatsächlech mat 2-Wee Fusioun liewen. Wéi och ëmmer, et huet eng Rei Probleemer déi mir mat eise Patches geléist hunn, déi hëllefen den Helm normal ze schaffen.

Real Rollout Status

Nodeems eise CI System eng nei Konfiguratioun fir Kubernetes generéiert baséiert op dem nächsten Event, iwwerdréit et fir ze benotzen (anwenden) zu engem Stärekoup - benotzt Helm oder kubectl apply. Als nächst geschitt déi scho beschriwwe N-Wee Fusioun, op déi d'Kubernetes API approuvéierend op den CI System reagéiert, an dat op säi Benotzer.

Et gëtt awer e grousse Problem: schliisslech erfollegräich Applikatioun heescht net erfollegräich Rollout. Wann Kubernetes versteet wéi eng Ännerungen applizéiert musse ginn an et applizéiert, wësse mir nach ëmmer net wat d'Resultat wäert sinn. Zum Beispill, d'Aktualiséierung an d'Restart vun Pods am Frontend kann erfollegräich sinn, awer net am Backend, a mir kréien verschidde Versioune vun de lafende Applikatiounsbiller.

Fir alles richteg ze maachen, erfuerdert dëse Schema en zousätzleche Link - e spezielle Tracker, deen Statusinformatioun vun der Kubernetes API kritt an iwwerdroe fir weider Analyse vum realen Zoustand vun de Saachen. Mir hunn eng Open Source Bibliothéik am Go erstallt - cubedog (kuckt seng Ukënnegung hei), déi dëse Problem léist an an werf agebaut ass.

D'Behuele vun dësem Tracker um werf Niveau ass konfiguréiert mat Annotatiounen déi op Deployments oder StatefulSets gesat ginn. Haaptannotatioun - fail-mode - versteet déi folgend Bedeitungen:

• IgnoreAndContinueDeployProcess — mir ignoréieren d'Problemer vun der Ausrollung vun dëser Komponent a fuere weider mat der Deployment;
• FailWholeDeployProcessImmediately - e Feeler an dësem Komponent stoppt den Deploymentprozess;
• HopeUntilEndOfDeployProcess — mir hoffen, datt dës komponent bis zum enn vun der deployment funktionéiert.

Zum Beispill, dës Kombinatioun vu Ressourcen an Annotatiounswäerter fail-mode:

Wa mir fir d'éischte Kéier ofsetzen, ass d'Datebank (MongoDB) vläicht nach net fäerdeg - Deployments falen. Awer Dir kënnt op de Moment waarden bis et ufänkt, an d'Deployment wäert nach ëmmer stattfannen.

Et ginn zwou weider Annotatiounen fir kubedog zu werf:

• failures-allowed-per-replica - d'Zuel vun erlaabt Falen fir all Replica;
• show-logs-until - reguléiert de Moment, bis deen werf (am stdout) Logbicher vun all ausgerullten Pods weist. De Standard ass PodIsReady (fir Messagen ze ignoréieren déi mir wahrscheinlech net wëllen wann de Traffic ufänkt op de Pod ze kommen), awer Wäerter sinn och valabel: ControllerIsReady и EndOfDeploy.

Wat soss wëlle mir vum Asaz?

Zousätzlech zu deenen zwee schonn beschriwwenen Punkte wëlle mir:

• ze gesinn Logbicher - an nëmmen déi néideg, an net alles an enger Zeil;
• Streck Fortschrëtt, well wann d'Aarbecht e puer Minutten "roueg" hänkt, ass et wichteg ze verstoen wat do geschitt;
• hunn automatesch Réckroll am Fall wou eppes falsch gaang ass (an dofir ass et kritesch de richtege Status vun der Deployment ze kennen). D'Rollout muss atomesch sinn: entweder geet et bis zum Enn, oder alles geet zréck an säi fréiere Staat.

Resultater

Fir eis als Firma, all beschriwwen Nuancen a verschiddene Liwwerstadien ëmzesetzen (bauen, publizéieren, ofsetzen), CI System an Utility sinn genuch werf.

Amplaz vun enger Conclusioun:

Mat der Hëllef vu werf hu mir gutt Fortschrëtter gemaach fir eng grouss Zuel vu Probleemer fir DevOps Ingenieuren ze léisen a wiere frou wann déi breet Gemeinschaft op d'mannst dëst Utility an Aktioun probéiert. Et wäert méi einfach sinn e gutt Resultat zesummen ze erreechen.

Videoen a Rutschen

Video vun der Leeschtung (~ 47 Minutten):

Presentatioun vum Rapport:

PS

Aner Berichter iwwer Kubernetes op eisem Blog:

• «Autoscaling a Ressourcemanagement zu Kubernetes» (Dmitry Stolyarov; Abrëll 27, 2019 op "Strike");
• «Kubernetes verlängeren an ergänzen» (Andrey Polovov; Abrëll 8, 2019 op Saint HighLoad++);
• «Datenbanken a Kubernetes» (Dmitry Stolyarov; 8. November 2018 op HighLoad++);
• «Iwwerwachung an Kubernetes» (Dmitry Stolyarov; Mee 28, 2018 bei RootConf);
• «CI / CD Best Practices mat Kubernetes a GitLab» (Dmitry Stolyarov; 7. November 2017 op HighLoad++);
• «Eis Erfahrung mat Kubernetes a klenge Projeten» (Dmitry Stolyarov; Juni 6, 2017 bei RootConf).

Source: will.com