Kubernetes vil erobre verden. Hvornår og hvordan?

I takt med DevOpsConf Vitaliy Khabarov har interviewet Dmitry Stolyarov (distol), teknisk direktør og medstifter af firmaet «Flant». Vitaliy spurgte Dmitry om, hvad «Flant» arbejder med, om Kubernetes, udvikling af økosystemet, støtte. De diskuterede, hvorfor Kubernetes er nødvendigt, og om det overhovedet er nødvendigt. Og også om mikrotjenester, Amazon AWS, tilgang til «Jeg er heldig» i DevOps, fremtiden for Kubernetes, hvorfor, hvornår og hvordan det vil overtage verden, perspektiverne for DevOps og hvad ingeniører skal forberede sig på i en lys og nær fremtid med forenkling og neurale netværk.

Originalen af interviewet i form af et podcast kan du lytte til på DevOps Deflope — en russisk podcast om DevOps, og nedenfor er den tekstlige version.

Her stiller Vitaliy Khabarov ingeniøren fra Express42.

Om «Flant»

— Dima, hej. Du er teknisk direktør for «Flant» og også dens grundlægger. Fortæl venligst, hvad firmaet laver, og hvad du laver i det?

Dmitry: Udefra ser det ud til, at vi er sådan nogle fyre, der går rundt, sætter Kubernetes op og laver noget med det. Men sådan er det ikke. Vi startede som et firma, der arbejder med Linux, men allerede for længe siden blev vores hovedaktivitet at servicere produktions- og highload-projekter fra bunden. Normalt bygger vi hele infrastrukturen fra bunden og tager derefter ansvar for den i lang tid. Derfor er det primære arbejde, som «Flant» udfører, hvad de får penge for — det er at påtage sig ansvar og implementere produktion fra bunden.




Som teknisk direktør og en af medstifterne af firmaet bruger jeg hele dagen på at finde ud af, hvordan jeg kan øge tilgængeligheden af produktionen, forenkle driften, gøre livet lettere for administratorerne, og gøre livet mere behageligt for udviklerne.

Om Kubernetes

— På det seneste har jeg set mange foredrag fra «Flant» og artikler om Kubernetes. Hvordan kom I til det?

Dmitry: Jeg har allerede fortalt om dette mange gange, men jeg har slet ikke noget imod at gentage det. Jeg mener, det er korrekt at gentage dette emne, fordi der opstår forvirring mellem årsag og virkning.

Vi havde virkelig brug for et værktøj. Vi stod over for en masse problemer, kæmpede, overvandt dem med forskellige hacks og ledte efter et værktøj. Vi gennemgik mange forskellige muligheder, byggede vores egne løsninger og akkumulerede erfaring. Gradvist nåede vi til det punkt, hvor vi begyndte at bruge Docker næsten lige efter, det blev lanceret – omkring 2013. På tidspunktet for dets introduktion havde vi allerede meget erfaring med containere, og vi havde allerede skrevet vores egen version af 'Docker' – nogle hacks i Python. Med introduktionen af Docker fik vi muligheden for at kaste vores løsninger væk og bruge en pålidelig og fællesskabsunderstøttet løsning.

Historien med Kubernetes er tilsvarende. På det tidspunkt, hvor det begyndte at tage fart – for os var det version 1.2 – havde vi allerede en masse hacks både i Shell og i Chef, som vi forsøgte at orkestrere Docker med. Vi kiggede seriøst på Rancher og forskellige andre løsninger, men så kom Kubernetes, som er designet præcist som vi ville have gjort det – eller endda bedre. Der er ingen kritik her.

Ja, der er nogle ufuldkommenheder her og der – mange ufuldkommenheder, og 1.2 var helt forfærdelig, men…. Kubernetes er som en bygning under opførelse – man ser på projektet og forstår, at det bliver fantastisk. Hvis bygningen har et fundament og to etager nu, forstår man, at det er bedre ikke at flytte ind endnu, men med softwaren er der ingen sådanne problemer – den kan allerede bruges.

Vi havde ikke et øjeblik, hvor vi overvejede, om vi skulle bruge Kubernetes eller ej. Vi ventede på det længe før det blev lanceret og forsøgte selv at bygge analoger.

Om Kubernetes

— Deltager I direkte i udviklingen af Kubernetes?

Dmitry: Midt imellem. Vi deltager snarere i udviklingen af økosystemet. Vi sender et vist antal pull requests: i Prometheus, i forskellige operatører, i Helm – ind i økosystemet. Desværre kan jeg ikke holde styr på alt, hvad vi gør, og jeg kan tage fejl, men der er ikke én eneste pull request fra os til kernen.

— Samtidig udvikler I også mange egne værktøjer omkring Kubernetes?

Dmitry: Strategien er sådan: Vi går og laver pull requests til alt, hvad der allerede findes. Hvis der ikke accepteres pull requests der, så fork'er vi dem bare til os selv og lever, indtil de bliver accepteret med vores builds. Derefter, når det når upstream, vender vi tilbage til den upstream-version.

For eksempel har vi Prometheus-operatoren, som vi har skiftet frem og tilbage mellem i vores upstream-implementering allerede omkring fem gange, tror jeg. Vi har brug for en funktion, vi har sendt en pull request, vi skal have den implementeret i morgen, og vi ønsker ikke at vente på, at den bliver udgivet i upstream. Således samler vi vores egen version og ruller vores opbygning med den funktion, vi har brug for, ud til alle vores klynger. Så omdanner de det for os i upstream og siger: "Hey, lad os gøre det for en mere generel anvendelse", så færdiggør vi det, eller nogen andre, og på et tidspunkt bliver det igen flettet tilbage.

Alt, hvad der eksisterer, forsøger vi at udvikle.. Mange elementer, som endnu ikke findes, enten ikke er blevet opfundet, eller som er blevet opfundet, men ikke implementeret – det skaber vi. Og ikke fordi vi elsker selve processen eller at konstruere cykler som en branche, men simpelthen fordi vi har brug for dette værktøj. Ofte bliver spørgsmålet stillet, hvorfor vi har lavet den eller den funktion? Svaret er enkelt – fordi vi måtte komme videre, løse et praktisk problem, som vi har løst med dette værktøj.

Vejen er altid sådan: vi søger meget grundigt, og hvis vi ikke finder nogen løsning på, hvordan man laver en trolleybus ud af et brød, så laver vi vores egen brød og vores egen trolleybus.

Flanta-værktøjer

— Jeg er klar over, at Flanta i øjeblikket har addon-operatører, shell-operatører, dapp/werf værktøjer. Som jeg forstår det, er dette det samme værktøj i forskellige inkarnationer. Jeg forstår også, at der inden for Flanta er mange forskellige værktøjer. Er det korrekt?

Dmitry: Vi har meget mere på GitHub. Af det jeg kan huske nu, har vi statusmap – et panel til Grafana, som alle kan lide. Det nævnes næsten i hver anden artikel om overvågning af Kubernetes på Medium. Det er umuligt at forklare kort, hvad statusmap er – det kræver en separat artikel, men det er et meget nyttigt værktøj til overvågning af status over tid, da vi ofte har brug for at vise status over tid i Kubernetes. Vi har også LogHouse – det er en løsning baseret på ClickHouse og lidt magi til indsamling af logs i Kubernetes.

Mange nyttige værktøjer! Og der vil komme endnu flere, da en række interne løsninger vil blive udgivet i år. Blandt de store på addon-operationsniveauet er der en masse addons til Kubernetes, såsom hvordan man korrekt installerer sert manager – et værktøj til håndtering af certifikater, hvordan man sætter Prometheus op med en masse tilknyttede værktøjer – der er omkring tyve forskellige binære filer, der eksporterer data og samler information; til dette er der en fantastisk grafik og alarmer i Prometheus. Alt dette er blot en mængde addons til Kubernetes, der installeres i klyngen, og som forvandler den fra simpel til en avanceret, automatiseret løsning, hvor mange problemer allerede er blevet løst. Ja, vi laver meget.

Udviklingen af økosystemet

— Jeg mener, at dette er et stort bidrag til udviklingen af dette værktøj og dets anvendelsesmetoder. Kan du anslå, hvem der ellers ville kunne bidrage på samme måde til udviklingen af økosystemet?

Dmitry: Ingeniørerne i Rusland, blandt de virksomheder, der opererer på vores marked – ingen er i nærheden.. Selvfølgelig er dette en dristig påstand, fordi der er store spillere som Mail og Yandex – de laver også noget med Kubernetes, men selv de er ikke i nærheden af det bidrag, som virksomheder gør globalt, der laver meget mere end os. Det er svært at sammenligne «Flant» med en stab på 80 personer og Red Hat, hvor der kun til én Kubernetes er 300 ingeniører, hvis jeg ikke tager fejl. Det er svært at sammenligne. I vores RnD-afdeling er der 6 personer, inklusive mig, der arbejder på alle vores værktøjer. 6 personer mod 300 ingeniører i Red Hat – det er lidt svært at sammenligne.

— Ikke desto mindre, når selv disse 6 personer kan skabe noget virkelig nyttigt og delbart, når de står over for en praktisk opgave og giver løsningen til fællesskabet – det er en interessant sag. Jeg forstår, at i store teknologiselskaber, hvor der er egen udvikling og et team, der støtter Kubernetes, kan der i princippet også udvikles tilsvarende værktøjer. Dette er et eksempel for dem på, at det er muligt at udvikle og give det videre til fællesskabet og give et skub til hele fællesskabet, der bruger Kubernetes.

Dmitry: Det er sikkert en integratorfunktion, en særlig egenskab ved ham. Vi har mange projekter, og vi ser mange forskellige situationer. Den primære måde, vi skaber merværdi på, er ved at analysere disse cases, finde fælles træk og maksimalt reducere omkostningerne for os. Det arbejder vi aktivt med. Det er svært for mig at sige noget om Rusland og verden, men vi har cirka 40 DevOps-ingeniører i firmaet, der arbejder med Kubernetes. Jeg tror ikke, der er mange virksomheder i Rusland med et sammenligneligt antal specialister, der kender til Kubernetes, hvis de overhovedet findes.

Jeg forstår alt om titlen DevOps-ingeniør, alle forstår det, og det er blevet en vane at kalde DevOps-ingeniører for DevOps-ingeniører, så det behøver vi ikke at diskutere. Alle de 40 fantastiske DevOps-ingeniører står hver dag over for problemer og løser dem. Vi analyserer blot denne erfaring og prøver at generalisere den. Vi ved, at hvis vi holder denne viden indad, vil værktøjet være værdiløst om et år eller to, fordi et færdigt værktøj vil dukke op et eller andet sted i communityen. Der er ikke nogen mening i at akkumulere denne erfaring internt – det er kun spild af kræfter og tid i dev/null. Men så er vi slet ikke kede af at dele. Vi publicerer med stor glæde alt dette og forstår, at det skal publiceres, udvikles, promoveres, så folk kan bruge det og tilføje deres erfaring – så vokser og lever alt. Så om to år ender værktøjet ikke i skraldespanden. Det er ikke kedeligt at fortsætte med at investere kræfter, fordi det er tydeligt, at nogen bruger dit værktøj, og om to år bruger alle det.

Dette er en del af vores store strategi med dapp/werf. Jeg kan ikke huske, hvornår vi begyndte at udvikle det, men det virker som om, det var for tre år siden. Oprindeligt var det helt på shell. Det var en super proof of concept, vi løste nogle af vores specifikke opgaver – det lykkedes! Men der er problemer med shell, det er umuligt at skalere det op, at programmere på shell er en svær opgave. Vi havde en vane med at skrive i Ruby, så vi ændrede og udviklede noget i Ruby, men så stødte vi ind i, at communityen, den gruppe, der ikke siger “vi ønsker eller ikke ønsker”, vender næsen væk fra Ruby, som det er mærkeligt. Vi indså, at vi skulle skrive alt dette i Go for simpelthen at opfylde det første punkt på tjeklisten: DevOps-værktøjet skal være en statisk binærfil. Uanset om det er Go eller ej, er det ikke så vigtigt, men det er bedre med en statisk binærfil skrevet i Go.

Vi har brugt kræfter på at omskrive dapp'en til Go og kaldt den werf. Dapp'en er ikke længere vedligeholdt, den udvikles ikke, den fungerer i en eller anden sidste version, men der er en absolut opgraderingsvej opad, som kan følges.

Hvorfor blev dapp'en oprettet

— Kan du kort fortælle, hvorfor dapp'en blev oprettet, hvilke problemer den løser?

Dmitry: Den første grund er bygning. Oprindeligt havde vi store problemer med bygning, da Docker ikke kunne multi-stage, og vi lavede multi-stage selv. Så havde vi en masse andre spørgsmål om oprydning af billeder. Alle, der laver CI/CD, støder før eller senere på problemet med en masse opbyggede billeder, der kræver oprydning af det, der ikke er nødvendigt, og at bevare det, der er nødvendigt.

Den anden grund er deployment. Ja, der er Helm, men det løser kun en del af problemerne. Uden at skulle joke, står der, at "Helm er Package Manager for Kubernetes". Præcis, "the". Der er også ordene "Package Manager" - hvad forventes der typisk af en Package Manager? Vi siger: "Package Manager - installer pakken!" og forventer, at den siger: "Pakken er installeret."

Det er interessant, at vi siger: "Helm, installer pakken", men når den svarer, at den har installeret, viser det sig, at den kun har startet installationen - den sagde til Kubernetes: "Start denne ting!", og om den er startet eller fungerer, løser Helm slet ikke det spørgsmål.

Det viser sig, at Helm blot er en tekstbehandler, der indlæser data i Kubernetes.

Men inden for enhver deployment ønsker vi at vide - er applikationen rullet ud til produktion eller ej? At være rullet ud til produktion betyder, at applikationen er sendt derud, den nye version er udrullet, og den faller ikke og svarer korrekt. Helm løser slet ikke denne opgave. For at løse den skal der bruges meget kraft, for det kræver, at du giver Kubernetes en kommando om at rulle ud og overvåge, hvad der sker - om det er blevet udrullet, om det er rullet ud. Der er også mange opgaver relateret til deployment, oprydning, bygning.

Planer

Allerede i år vil vi gå over til lokal udvikling. Vi ønsker at nå det niveau, som tidligere blev gjort i Vagrant — vi skriver "vagrant up", og vores virtuelle maskiner bliver oprettet. Vi vil til det punkt, hvor der er et projekt i Git, og vi skriver "werf up", som starter en lokal kopi af dette projekt, der kører i et lokalt mini-Kub, med alle mapper tilsluttet, så det er nemt at udvikle. Afhængig af programmeringssproget udføres dette på forskellige måder, men vi ønsker, at det skal være nemt at drive lokal udvikling med monterede filer.

Næste skridt for os er at investere kraftigt i udviklerens bekvemmelighed.. For hurtigt at kunne starte et projekt lokalt med ét værktøj, udvikle, pushe til Git, og det skal derefter også kunne deployes til staging eller tests afhængigt af pipelines, og så til produktion med det samme værktøj. Dette sammenhæng, ensartethed, reproducerbarhed af infrastrukturen fra lokal miljø til produktion er meget vigtig for os. Men det findes endnu ikke i werf — vi planlægger stadig at gøre det.

Men vejen til dapp/werf har altid været den samme som med Kubernetes i begyndelsen. Vi stødte på problemer, løste dem med omveje — fandt på nogle løsninger i shell eller hvad som helst. Derefter forsøgte vi at gøre disse omveje mere lige, generalisere og konsolidere dem i binære filer, som vi blot deler.

Der er også et andet syn på hele denne historie, med analogier.

Kubernetes er som en bilramme med motor. Der er ingen døre, vinduer, radio, luftfrisker — slet ikke noget. Kun rammen og motoren. Og der er Helm — det er rettet. Det er dejligt at have et rat, men vi har også brug for styrestift, styretøj, gearkasse og hjul; ellers fungerer det ikke.

I tilfældet med werf er det endnu en komponent til Kubernetes. Men lige nu har vi i alfa-versionen af werf for eksempel, at Helm er kompileret inden i werf, fordi vi blev trætte af at gøre det selv. Der er mange grunde til at gøre det sådan, jeg vil grundigt forklare, hvorfor vi har kompilere helm helt sammen med tiller ind i werf på foredraget ved RIT++..

Nu er werf et mere integreret komponent. Vi får et færdigt styr, styrstang - jeg er ikke særlig god til biler, men det er en stor blok, der løser et ret stort spektrum af opgaver. Vi behøver ikke selv at lede i kataloget, finde en del til en anden, og tænke over, hvordan de skal skrues sammen. Vi får en færdig kombination, der straks løser mange opgaver. Men indeni er den lavet af de samme open source-komponenter, bruger stadig Docker til bygning, Helm til dele af funktionaliteten, og der er også et par andre biblioteker. Det er et integreret værktøj til hurtigt og nemt at få en fantastisk CI/CD ud af boksen.

Er det svært at vedligeholde Kubernetes?

— Du taler om erfaringen med at begynde at bruge Kubernetes, det fungerer som ramme, motor, og at du kan tilføje meget forskelligt: karrosseri, styretøj, sætte pedaler og sæder på. Spørgsmålet opstår - hvor svært er det for dig at vedligeholde Kubernetes? I har stor erfaring, hvor meget tid og ressourcer bruger I specifikt på at vedligeholde Kubernetes adskilt fra resten?

Dmitry: Det er et meget komplekst spørgsmål, og for at svare på det, skal vi forstå, hvad vedligeholdelse er, og hvad vi ønsker fra Kubernetes. Måske kan du uddybe?

— Efter hvad jeg ved, og som jeg ser det, ønsker mange teams nu at prøve Kubernetes. Alle hopper ind i det, sætter det op på egen hånd. Jeg har en fornemmelse af, at folk ikke altid forstår kompleksiteten af dette system.

Dmitry: Det er korrekt.

— Hvor svært er det at tage og installere Kubernetes fra bunden, så det er produktionsklar?

Dmitry: Hvad tror du, hvor svært er det at transplantere et hjerte? Jeg forstår, det er et kompromitterende spørgsmål. At håndtere en skalpel og ikke lave fejl – det er ikke så svært. Hvis de fortæller dig, hvor du skal skære og hvor du skal sy, så selve proceduren er ikke kompliceret. Det er svært at garantere, at det lykkes hver gang.

At installere Kubernetes og få det til at fungere er let: klik! – det er installeret, der er mange installationsmetoder. Men hvad sker der, når problemer opstår?

Der opstår altid spørgsmål - hvad har vi ikke taget højde for? Hvad har vi ikke gjort? Hvilke Linux-kernparametre angav vi forkert? Herregud, angav vi dem overhovedet?! Hvilke Kubernetes-komponenter installerede vi, og hvilke gjorde vi ikke? Tusind spørgsmål opstår, og for at besvare dem kræver det 15-20 års erfaring i denne branche.

Jeg har et friskt eksempel på dette emne, som kan belyse spørgsmålet "Er det svært at vedligeholde Kubernetes?" For nogle tid siden overvejede vi seriøst, om vi skulle forsøge at implementere Cilium som netværket i Kubernetes.

Lad mig forklare, hvad Cilium er. I Kubernetes er der mange forskellige implementeringer af netværkssystemet, og en af dem er virkelig fed - det er Cilium. Hvad går det ud på? For nogle tid siden blev der i kernen introduceret muligheden for at skrive hooks til kernen, der på en eller anden måde blander sig i netværkssystemet og forskellige andre systemer, og som tillader at omgå store dele af kernen.

I Linux-kernen er der historisk ip rout, netfilter, broere og mange forskellige gamle komponenter, som har eksisteret i 15, 20, 30 år. Generelt fungerer de, det er alt godt, men nu har vi fyldt med containere, og det ligner et tårn af 15 mursten oven på hinanden, mens du står på det på ét ben - en underlig følelse. Dette system er historisk udviklet med mange nuancer, ligesom et appendix i kroppen. I nogle situationer er der problemer med performance, for eksempel.

Der er fremragende BPF og muligheden for at skrive hooks til kernen - folkene har skrevet deres egne hooks til kernen. Pakken kommer ind i Linux-kernen, de tager den lige ved indgangen, behandler den, som de vil uden broer, uden TCP, uden IP-stak - kort sagt, forbi alt, hvad der er skrevet i Linux-kernen, og spytter den lige ud i containeren.

Hvad har vi opnået? Meget flot performance, fantastiske features - simpelthen klasse! Men vi ser på det og ser, at der på hver maskine kører et program, der tilslutter sig Kubernetes API'et, og baseret på de data, det får fra denne API, genererer det C-kode og kompilerer binære filer, som det loader ind i kernen, så disse hooks fungerer i kernelspace.

Hvad sker der, hvis noget går galt? Vi ved det ikke. For at finde ud af det skal man læse hele denne kode, forstå hele logikken, og det er virkelig svært. Men på den anden side er der disse broer, netfiltre, ip rout - jeg har ikke læst deres kildekoder, og 40 ingeniører, der arbejder i vores virksomhed, har det heller ikke. Måske er der nogle stykker, der forstår visse dele.

Og hvad gør det? Det viser sig, at der er en ip-rout, Linux-kernen, og der er et nyt værktøj - hvad gør det, vi forstår hverken den ene eller den anden. Men vi er bange for at bruge det nye - hvorfor? Fordi hvis værktøjet har 30 år på bagen, så har man fundet alle fejlene, og man er kommet til at støde på alle faldgruberne, så man behøver ikke at vide om alt - det fungerer som en sort boks, og det gør det altid. Alle ved, hvilken diagnostisk skrue der skal bruges, og hvilket tcpdump der skal køres på hvilket tidspunkt. Alle kender godt diagnostiske værktøjer og forstår, hvordan dette sæt komponenter fungerer i Linux-kernen - ikke hvordan det er bygget op, men hvordan man bruger det.

Men den fantastiske Cilium er ikke 30 år gammel, den er ikke engang modnet. Der er det samme problem med Kubernetes, det er en kopi. Både Cilium og Kubernetes kan installeres uden problemer, men hvis noget går galt i produktionen, vil I så være i stand til hurtigt at forstå, hvad der gik galt i en kritisk situation?

Når vi taler om, hvor svært det er at vedligeholde Kubernetes - nej, det er meget enkelt, og ja, det er utroligt svært. Kubernetes fungerer fint for sig selv, men med milliarder af nuancer.

Om tilgangen "Jeg er heldig"

— Er der virksomheder, hvor disse nuancer næsten garanteret vil dukke op? Lad os antage, at Yandex pludselig flytter alle deres tjenester til Kubernetes, så vil der være en betydelig belastning.

Dmitry: Nej, det handler ikke om belastningen, men om de mest simple ting. For eksempel, vi har Kubernetes, og vi har deployet en applikation der. Hvordan forstår vi, at den fungerer? Der er simpelthen ikke et klar værktøj til at forstå, at applikationen ikke falder. Der er ikke et færdigt system, der sender alarmer - man skal opsætte disse alarmer og hver graf. Og vi opdaterer Kubernetes.

Der er Ubuntu 16.04. Man kan sige, at det er en gammel version, men vi bruger stadig den, fordi der er LTS. Den har systemd, hvis detalje er, at den ikke renser C-grupperne. Kubernetes starter pods, opretter C-grupper, fjerner derefter pods, og på en eller anden måde sker det - jeg kan ikke huske detaljerne, undskyld - at der forbliver systemd-slices. Dette fører til, at enhver maskine over tid begynder at bremse betydeligt. Det handler ikke engang om highload. Hvis der køres vedvarende pods, f.eks. hvis der er et Cron Job, der konstant genererer pods, så vil en maskine med Ubuntu 16.04 begynde at bremse efter en uge. Der vil hele tiden være et højt load average på grund af det store antal C-grupper, der er oprettet. Dette er et problem, som enhver person, der bare installerer Ubuntu 16 og derpå Kubernetes, står over for.

Lad os sige, at han på en eller anden måde opdaterer systemd eller noget andet, men i Linux-kernen op til 4.16 er det endnu sjovere - når C-grupperne bliver fjernet, lækker de i kernen og bliver faktiske ikke slettet. Derfor vil det efter en måneds arbejde på denne maskine være umuligt at se statistikkerne om hukommelsen for pods. Vi henter en fil, kører den i programmet, og den ene fil tager 15 sekunder at køre, fordi kernen bruger lang tid på at gennemgå millioner af C-grupper, som tilsyneladende er fjernet, men nej - de lækker.

Der er stadig mange sådanne små detaljer her og der. Det er ikke noget, som gigantiske virksomheder kun nogle gange kan støde på under meget store belastninger - nej, det er et spørgsmål om daglige ting. Folk kan leve sådan i flere måneder - installerede Kubernetes, deployede applikationen - det ser ud til at fungere. Mange har det fint med det. De aner ikke, at applikationen på et tidspunkt vil falde ud af en eller anden grund, alarmerne kommer ikke, men for dem er det normalt. Tidligere levede de på virtuelle maskiner uden overvågning, nu er de gået over til Kubernetes også uden overvågning - hvad er forskellen?

Spørgsmålet er, at når vi går på isen, ved vi aldrig dens tykkelse, medmindre vi har målt den på forhånd. Mange går rundt og bekymrer sig ikke, fordi de også gik før.

Fra mit synspunkt er detaljen og kompleksiteten ved at drifte ethvert system i at garantere, at isens tykkelse helt sikkert er tilstrækkelig til at løse vores opgaver. Det handler om det.

I IT-branchen synes jeg, der er for mange tilgange til "Jeg er heldig." Mange installerer software og bruger biblioteker i håbet om, at de vil have held. Generelt har mange held. Måske er det derfor, det fungerer.

— I min pessimistiske vurdering ser det således ud: Når risikoen er høj, og applikationen skal fungere, er der brug for støtte fra "Flant", muligvis fra Red Hat, eller der kræves et internt team, der er dedikeret til Kubernetes og klar til at håndtere det.

Dmitry: Objektivt set er det sådan. At dykke selv ind i Kubernetes-historien for et lille team er en vis mængde risiko.

Har vi brug for containere?

— Kan du fortælle, hvor udbredt Kubernetes faktisk er i Rusland?

Dmitry: Jeg har ikke disse data, og jeg er ikke sikker på, om nogen overhovedet har dem. Vi siger: "Kubernetes, Kubernetes", men der er også et andet synspunkt på dette spørgsmål. Hvor udbredte containere er, ved jeg heller ikke, men jeg kender et tal fra rapporter på internettet, der siger, at 70% af containerne orkestreres af Kubernetes. Det var en pålidelig kilde baseret på et ganske stort datasæt globalt.

Et andet spørgsmål er – har vi brug for containere? Min personlige følelse og generelt positionen for virksomheden "Flant" er sådan, at Kubernetes er de facto-standarden.

Ingenting andet end Kubernetes vil være der.

Det er en absolut game-changer inden for infrastrukturadministration. Absolut – alt, ikke mere Ansible, Chef, virtuelle maskiner, Terraform. Jeg nævner endda ikke de gamle landsbymetoder. Kubernetes er en absolut changer, og nu vil det kun være sådan.

Det er klart, at nogle har brug for et par år, mens andre har brug for et par årtier for at indse dette. Jeg har ingen tvivl om, at der ikke vil være noget andet end Kubernetes og denne nye tilgang: vi går ikke længere ind i operativsystemet, men bruger infrastruktur som kode, bare ikke med kode, men med yml – en deklarativt beskreven infrastruktur. Jeg har en følelse af, at det altid vil være sådan.

— Så de virksomheder, der endnu ikke er gået over til Kubernetes, vil uundgåeligt komme til at gøre det eller forsvinde i glemsel. Forstod jeg dig korrekt?

Dmitry: Det er heller ikke helt rigtigt. For eksempel, hvis vi har til opgave at starte en dns-server, kan den startes på FreeBSD 4.10 og kan fungere fint i 20 år. Bare fungere og det er det. Måske skal der opdateres noget én gang i løbet af de 20 år. Hvis vi taler om software i formatet, hvor vi har startet det og det faktisk fungerer i mange år uden opdateringer, uden ændringer, så vil der selvfølgelig ikke være Kubernetes. Det er ikke nødvendigt der.

Alt der angår CI/CD - hvor som helst der er brug for Continuous Delivery, hvor versioner skal opdateres, hvor aktive ændringer er nødvendige, hvor det er nødvendigt at opbygge fejltolerance - kun Kubernetes.

Om mikrotjenester

— Her har jeg en lille diskrepans. For at arbejde med Kubernetes kræves der ekstern eller intern support - det er det første punkt. Det andet - når vi lige er begyndt at udvikle, er vi en lille startup, vi har stadig ikke noget, udvikling til Kubernetes eller overhovedet til mikrotjenestearkitektur kan være besværlig, og det er ikke altid økonomisk forsvarligt. Jeg er interesseret i din mening - skal startups helt fra bunden begynde at skrive til Kubernetes, eller kan de stadig skrive en monolit, og så derefter komme til Kubernetes?

Dmitry: Godt spørgsmål. Jeg har en præsentation om mikrotjenester. «Mikrotjenester: størrelse betyder noget». Jeg har mange gange stødt på, at mennesker prøver at slå søm i med en mikroskop. Selve tilgangen er rigtig, vi designer selv vores interne software på denne måde. Men når man gør det, skal man klart forstå, hvad man gør. Det jeg hader mest ved mikrotjenester er ordet «mikro». Historisk set er ordet opstået, og af en eller anden grund mener folk, at mikro er meget lille, mindre end en millimeter, som en mikrometer. Det er ikke sådan.

For eksempel er der en monolit, som 300 personer arbejder på, og alle der deltager i udviklingen forstår, at der er problemer, og den skal deles op i mikro-stykker - omkring 10 stykker, som hver skrives af 30 personer i minimum. Det er vigtigt, nødvendigt og fantastisk. Men når en startup kommer til os, hvor 3 helt fantastiske og talentfulde fyre har skrevet 60 mikrotjenester på knæet, søger jeg altid efter corvalol.

Jeg synes, dette er blevet sagt tusind gange før - vi har fået en distribueret monolit i en eller anden form. Det er økonomisk uholdbart og meget svært generelt. Jeg har set det så mange gange, at det gør mig ondt, derfor fortsætter jeg med at tale om det.

Til det oprindelige spørgsmål, at der er en konflikt mellem, at Kubernetes er skræmmende at bruge, fordi det er uklart, hvad der kan gå galt eller ikke fungerer, og på den anden side, at det er klart, at alt går den vej, og at der ikke vil være noget andet end Kubernetes. Svaret er - at veje mængden af ​​nytte, der kommer, og mængden af ​​opgaver, du kan løse.. Dette er den ene side af vægten. På den anden side er der risici, der er forbundet med nedetid eller nedsættelse af svartid, tilgængelighedsniveau - nedsættelse af præstationsmetrikker.

Det er sådan - enten skal vi bevæge os hurtigt, og Kubernetes gør mange ting meget hurtigere og bedre, eller bruge pålidelige, tidstestede løsninger, men bevæge os meget langsommere. Dette valg skal hver virksomhed træffe. Man kan betragte det som en sti i junglen - første gang man går, kan man møde en slange, en tiger eller en sindssyg surikat, men efter du har været der 10 gange - har du slået en sti, ryddet grene, og det bliver lettere at gå. Hver gang bliver stien bredere. Senere bliver det en asfalteret vej, og senere en smuk boulevard.

Kubernetes står ikke stille. Igen spørgsmålet: Kubernetes, på den ene side, er det 4-5 binære filer, på den anden side er det hele økosystemet. Dette er styresystemet, der kører på vores maskiner. Hvad er det? Ubuntu eller Curios? Det er Linux-kernen, en masse ekstra komponenter. Alle disse ting her, en giftig slange er blevet fjernet fra vejen, der er blevet sat et hegn op der. Kubernetes udvikler sig meget hurtigt og dynamisk, og mængden af ​​risici, mængden af ​​det ukendte falder hver måned, og dermed ombalanceres disse vægte.

Når det kommer til spørgsmålet om, hvad en startup skal gøre, ville jeg sige – kom til "Flant", betal 150.000 rubler og få DevOps easy service leveret nøglefærdigt. Hvis du er en lille startup med et par udviklere – så fungerer det. I stedet for at ansætte din egen DevOps, som skal lære at løse dine problemer og få løn i mellemtiden, får du løsning på alle spørgsmål nøglefærdigt. Ja, der er nogle ulemper. Som en outsourcer kan vi ikke være så involverede og reagere hurtigt på ændringer. Men til gengæld har vi masser af ekspertise og klare praktiske løsninger. Vi garanterer, at vi i enhver situation hurtigt vil finde ud af det og tage fat om enhver Kubernetes fra det døde.

Jeg anbefaler kategorisk outsourcing til startups og etablerede virksomheder, indtil du kan allokere et driftsteam på 10 personer, for ellers giver det ikke mening. Det giver kategorisk mening at outsource.

Om Amazon og Google

— Kan outsourcing fra Amazon eller Google betragtes som en løsning?

Dmitry: Ja, selvfølgelig løser det et antal spørgsmål. Men igen er der nuancer. Man skal stadig forstå, hvordan man bruger det. For eksempel er der tusind småting ved arbejdet med Amazon AWS: Load Balanceren skal opvarmes eller man skal på forhånd skrive en forespørgsel om, at "drengene, vi får trafik, opvarm vores Load Balancer!" Man skal kende til disse nuancer.

Når du henvender dig til folk, der specialiserer sig i dette, får du næsten alle standardtingene dækket. Vi har nu 40 ingeniører, ved udgangen af året vil der nok være 60 – vi har helt sikkert stødt på alle disse ting. Selv hvis vi igen støder på dette problem i et projekt, spørger vi hurtigt hinanden og ved, hvordan vi løser det.

Svaret er formentlig sådan – selvfølgelig letter en hosted-løsning en del. Spørgsmålet er, om du er klar til at stole på disse hostingudbydere, og om de løser dine problemer. Amazon og Google har bevist deres værd. For alle vores sager – helt sikkert. Vi har ikke haft nogen positive erfaringer andre steder. Alle andre cloud-løsninger, vi har prøvet at arbejde med, skaber mange problemer – både Ager og alt, hvad der findes i Rusland, samt forskellige implementeringer af OpenStack: Headster, Overage – hvad som helst. De skaber alle problemer, som man ikke gider at løse.

Derfor er svaret – ja, men i praksis er der ikke mange modne hosted-løsninger.

Hvem har brug for Kubernetes?

— Og alligevel, hvem har brug for Kubernetes? Hvem skal allerede skifte til Kubernetes, hvem er den typiske kunde hos "Flant", som kommer netop for Kubernetes?

Dmitry: Det er et interessant spørgsmål, for lige nu, i bølgen af Kubernetes, kommer der mange til os: "Vi ved, at I laver Kubernetes, gør det for os!" Vi svarer: "Mine damer og herrer, vi laver ikke Kubernetes, vi laver produktion og alt hvad der har med det at gøre." Fordi det er i øjeblikket umuligt at lave produktion uden at lave hele CI/CD og hele den historie. Alle er gået væk fra at adskille udvikling fra drift.

Vores kunder forventer forskellige ting, men alle venter på et eller andet godt mirakel, der siger, at de har nogle problemer, og nu — hop! — Kubernetes vil løse dem. Folk tror på mirakler. De forstår fornuftigt, at der ikke vil være noget mirakel, men i deres hjerte håber de — hvad nu hvis dette Kubernetes lige vil løse alt for os, der tales så meget om det! Hvad nu hvis det lige — nip! — er sølvkuglen, nip! — og vi har 100% oppetid, alle udviklere kan udgive hvad som helst til produktion 50 gange, og det falder ikke. Generelt, et mirakel!

Når sådanne mennesker kommer til os, siger vi: "Undskyld, men der findes ikke noget mirakel." For at være sund, skal man spise godt og dyrke sport. For at have en pålidelig produktion, skal den laves pålideligt. For at have en bekvem CI/CD, skal den laves sådan. Det er meget arbejde, der skal gøres.

Når man svarer på spørgsmålet om, hvem der har brug for Kubernetes — Kubernetes er ikke nødvendigt for nogen.

Nogle mennesker har den fejlagtige opfattelse, at de har brug for Kubernetes. Folk ønsker at slippe for at tænke på, besætte sig med, eller interessere sig for alle problemer med infrastruktur og problemer med at starte deres applikationer. De vil have, at applikationerne bare skal fungere og blive deployeret simpelthen. For dem er Kubernetes håbet om, at de ikke længere vil høre historier som "vi lå der" eller "kan ikke udgive", eller noget andet.

Normalt kommer den tekniske direktør til os. Der bliver spurgt to ting: på den ene side, giv os funktioner, på den anden side — stabilitet. Vi foreslår at tage dette på os og gøre det. Den sølvkugle, eller rettere sagt, den sølvbelagte, er, at du vil stoppe med at tænke på disse problemer og spilde tid. Du vil have specialiserede folk, der vil tage sig af dette.

Formuleringen om, at vi eller nogen har brug for Kubernetes, er forkert.

Kubernetes er meget nødvendigt for administratorer, fordi det er en meget interessant legeplads, man kan eksperimentere med. Lad os være ærlige – alle elsker legesager. Vi er alle børn et eller andet sted, og når vi ser noget nyt, vil vi lege med det. For nogle er det blevet kedeligt i administrationen, fordi de allerede har leget nok. Men ingen har fuldstændig mistet interessen. For eksempel, selvom jeg er blevet træt af legetøj inden for systemadministration og DevOps, elsker jeg stadig legetøj og køber stadig noget nyt.

Man skal ikke lege med produktionen. Hvad jeg kategorisk ikke anbefaler at gøre, og hvad jeg ser sker massivt: "Åh, et nyt legetøj!" – så løber man for at købe det, man har købt det og: "Lad os tage det med i skolen og vise det til alle vennerne." Gør ikke sådan. Undskyld, men jeg har bare børn, der vokser op, og jeg ser hele tiden noget i dem, bemærker det i mig selv, og så generaliserer jeg det til andre.

Det endelige svar er: du har ikke brug for Kubernetes. Du skal løse dine problemer.

Det, man kan opnå, er:

• at produktionen ikke falder;
• selv hvis den forsøger at falde, ved vi det på forhånd, og vi kan gøre noget ved det;
• vi kan ændre det med den hastighed, vi har brug for i vores forretning, og gøre det nemt, det giver os ikke problemer.

De reelle behov er to: pålidelighed og dynamik/fleksibilitet i deployment. Alle, der i øjeblikket laver IT-projekter, uanset hvilken branche de er i – software for at lette verden, og dem der forstår dette, skal opfylde disse behov. Kubernetes tillader, med den rigtige tilgang, den rette forståelse og tilstrækkelig erfaring, at disse behov løses.

Om serverless

– Hvis man ser lidt længere frem i fremtiden, så opstår der nye løsninger, som f.eks. serverless, når man forsøger at løse problemet med hovedpiner ved infrastrukturen, hastigheden af deployment og hastigheden af ændringer i applikationen. Føler du noget potentiale i denne retning og, lad os sige, en trussel mod Kubernetes og lignende løsninger?

Dmitry: Her skal jeg igen bemærke, at jeg ikke er en spåmand, der ser fremad og siger - det bliver sådan her! Selvom jeg netop har gjort det samme. Jeg kigger ned og ser en bunke problemer, for eksempel hvordan transistorer fungerer i computeren. Komisk, ikke? Vi står med nogle bugs i CPU'en.

At gøre serverless pålideligt, billigt, effektivt og bekvemt, mens man løser alle økosystemmæssige udfordringer, er muligt. Her er jeg enig med Elon Musk i, at vi har brug for en anden planet for at sikre menneskehedens redundans. Selvom jeg ikke ved, hvad han siger, forstår jeg, at jeg ikke er klar til selv at flyve til Mars, og det er ikke noget, der sker i morgen.

Med serverless er det klart, at det ideologisk er den rigtige vej, da det er bedre at have to planeter end én for menneskehedens redundans. Men hvordan gør vi det nu? At sende en ekspedition ud - det er ikke et problem, hvis vi fokuserer kræfterne. At sende flere ekspeditioner og kolonisere med flere tusinde mennesker virker for mig også realistisk. Men at skabe fuld redundans, så halvdelen af menneskeheden bor der, virker umuligt og ikke overkommeligt lige nu.

Med serverless er det det samme: det er en fantastisk ting, men det er langt fra problemerne i 2019. Tættere på 2030 - lad os leve til den tid. Jeg er ikke i tvivl om, at vi vil leve, vi vil helt sikkert leve (gentag det, før du går i seng), men lige nu skal vi tackle andre problemer. Det er som at tro på den magiske pony Rainbow. Ja, et par procent af sagerne løses, og de løses fantastisk, men subjektivt set er serverless en regnbue… For mig er dette emne for fjernet og for ukendt. Jeg er ikke klar til at tale om det. I 2019 kunne man ikke skrive en eneste applikation med serverless.

Hvordan vil Kubernetes udvikle sig?

— Mens vi bevæger os mod denne potentielt strålende fjerne fremtid, hvad mener du om, hvordan Kubernetes og økosystemet omkring det vil udvikle sig?

Dmitry: Jeg har tænkt meget over dette, og jeg har et klart svar. Det første er, at stateful er lettere at gøre stateless. Kubernetes har oprindeligt investeret mere i dette; det var her det hele begyndte. Stateless fungerer nærmest perfekt i Kubernetes, der er simpelthen ikke noget at påpege. Der er stadig en hel del problemer, eller rettere sagt, nuancer med stateful. Vi har det hele til at fungere fantastisk der, men det er os. For at det skal fungere for alle, kræver det mindst et par år mere. Det er ikke en målelig indikator, men mit indtryk fra hovedet.

Kort sagt, stateful skal udvikles enormt meget – og vil også gøre det – fordi alle vores applikationer gemmer status, der findes ikke stateless-applikationer. Det er en illusion, man har altid brug for en eller anden database og noget andet. Stateful handler om at strømligne alt, hvad der er muligt, rette alle fejl og forbedre alle problemer, som vi i øjeblikket står overfor – lad os kalde det adoption.

Niveauet af det ukendte, niveauet af uløste problemer, niveauet af sandsynlighed for at støde på noget vil falde markant. Det er en vigtig historie. Og operatører – alt hvad der har med kodificering af administrationslogik, styringslogik at gøre for at få en nem service: MySQL nem service, RabbitMQ nem service, Memcache nem service – alle disse komponenter, som vi har brug for for at få det til at fungere ud af boksen, er præcis det, der løser de problemer, hvor vi ønsker en database, men ikke vil administrere den, eller ønsker Kubernetes, men ikke vil administrere det.

Denne udvikling af operatører i en eller anden form vil være vigtig i de kommende par år.

Jeg tror, at enkelheden i drift skal stige kraftigt – kassen vil blive mere og mere sort, mere og mere pålidelig, med mere og mere enkle nitter.

Jeg hørte engang et gammelt interview med Isaac Asimov fra 80'erne på YouTube i showet Saturday Night Live – et program som Urgant, bare interessant. De spurgte ham om fremtiden for computere. Han sagde, at fremtiden ligger i enkelheden, ligesom det var med radiosendere. Radioen var oprindeligt en kompliceret ting. For at fange en bølge skulle man dreje på knapperne i 15 minutter, bøje og dreje og overhovedet vide, hvordan alt fungerede, forstå fysikken bag radiobølger. I sidste ende blev der kun tilbage en knap på radioen.

Hvad er radioen nu i 2019? Bilens radiomodtager finder alle bølger og navne på stationer. Den fysiske proces har ikke ændret sig i 100 år, men brugervenligheden er blevet lettere. I dag, og ikke kun i dag, allerede i 1980, da der blev lavet et interview med Asimov, brugte alle radio, og ingen tænkte over, hvordan det fungerar. Det har altid fungeret – det er en kendsgerning.

Asimov sagde dengang, at det ville være på samme måde med computere – brugerbetjeningen vil stige.Hvis man i 1980 skulle have en særlig uddannelse for at kunne trykke på knapperne på en computer, vil dette ikke længere være nødvendigt i fremtiden.

Jeg har en fornemmelse af, at med Kubernetes og infrastrukturen også vil brugervenligheden stige kraftigt. Det er, efter min mening, indlysende – det ligger lige foran os.

Hvad med ingeniørerne?

— Men hvad vil der så ske med ingeniørerne og systemadministratorerne, der understøtter Kubernetes?

Dmitry: Hvad skete der med bogholderen efter fremkomsten af 1C? Nøjagtig det samme. Før blev der regnet på papir – nu er det i programmet. Produktiviteten er steget mange gange, men arbejdet er ikke forsvundet af den grund. Hvis man før havde brug for 10 ingeniører til at skrue en pære i, så vil én nu være tilstrækkelig.

Mængden af software og opgaver vokser, efter min mening, nu hurtigere, end nye DevOps'er dukker op og effektiviteten stiger. Der er konkret mangel på markedet, og det vil vare længe. Senere vil alt falde ind i en vis normalitet, hvor effektiviteten i arbejdet vil stige, der vil komme mere serverless, en neural netværk vil blive tilkoblet Kubernetes, som selv finder de nødvendige ressourcer, og alt gør sig selv, som det skal – mennesket skal trække sig tilbage og ikke blande sig.

Men beslutningerne skal stadig tages af nogen. Det står klart, at den kvalifikationsniveau og specialisering, denne person har, er højere. I dag i regnskabsafdelingen har du ikke brug for 10 medarbejdere, der fører regnskab, for at deres hænder ikke skal blive trætte. Det er simpelthen ikke nødvendigt. Mange dokumenter scannes automatisk, og genkendes af det elektroniske dokumenthåndteringssystem. Det er tilstrækkeligt med én dygtig hovedbogholder, der allerede har langt større færdigheder og en god forståelse.

Generelt er denne udvikling til stede i alle industrier. Med biler er det det samme: før var der en mekaniker og tre chauffører til hver bil. Nu er det at køre bil en simpel proces, som vi alle deltager i hver dag. Ingen tænker over, at en bil er noget komplekst.

DevOps eller systemingeniørarbejde vil ikke forsvinde – højere niveau og effektivitet vil stige.

— Jeg har også hørt en interessant idé om, at arbejdet faktisk vil stige.

Dmitry: Selvfølgelig, hundrede procent! Fordi mængden af software, vi skriver, konstant vokser. Antallet af problemer, vi løser med software, vokser konstant. Mængden af arbejde stiger. Lige nu er DevOps-markedet ekstremt overophedet. Det kan ses i lønforventningerne. Rent hypotetisk, uden at gå ind i detaljer, burde der være juniorer, der ønsker X, mid-level som ønsker 1,5X, og seniorer der ønsker 2X. Men nu, hvis vi ser på lønmarkedet for DevOps i Moskva, ønsker junioren fra X til 3X, og senioren ønsker fra X til 3X.

Ingen ved, hvad det koster. Lønnen måles ud fra din selvsikkerhed - det er ren galskab, hvis jeg skal være ærlig, et ekstremt overophedet marked.

Selvfølgelig vil denne situation ændre sig meget snart - der skal komme en vis mætning. Med softwareudvikling er det ikke sådan - på trods af at udviklere er eftertragtede, og gode udviklere er nødvendige, forstår markedet, hvad folk er værd - branchen har stabiliseret sig. Sådan er det ikke med DevOps lige nu.

— Ud fra hvad jeg har hørt, har jeg konkluderet, at den nuværende systemadministrator ikke skal bekymre sig, men at tiden er inde til at opgradere sine færdigheder og forberede sig på, at der i morgen vil være mere arbejde, og det vil være mere kvalificeret.

Dmitry: Helt sikkert. Generelt lever vi i 2019, og livsreglen er sådan: livslang læring - vi lærer hele livet. Jeg tror, at folk nu allerede ved og føler dette, men det er ikke nok bare at vide – vi skal handle. Hver dag skal vi ændre os. Hvis vi ikke gør det, vil vi før eller senere blive sat af på professionens kant.

Vær forberedt på pludselige drejninger på 180 grader. Jeg udelukker ikke situationer, hvor noget radikalt ændrer sig, og der findes noget nyt – sådan sker det nogle gange. Hov! – og nu handler vi på en anden måde. Det er vigtigt at være klar til dette og ikke stresse over det. Det kan ske, at alt, hvad jeg gør i morgen, viser sig at være unødvendigt – det er fint, jeg har lært hele mit liv og er klar til at lære noget andet. Det er ikke et problem. Det er ikke værd at frygte jobusikkerhed, men man skal være klar til konstant at lære noget nyt.

Ønsker og et øjeblik med reklame

– Har du et ønske?

Dmitry: Ja, jeg har et par ønsker.

Det første og mere forretningsmæssige – tilmeld dig YouTube. Kære læsere, gå ind på YouTube og tilmeld dig vores kanal. Om cirka en måned vil vi starte en aktiv ekspansion på video-platformen, vi vil have en masse undervisningsindhold om Kubernetes, både åbent og forskelligt: fra praktiske emner til laboratorier og dybe, principielle teoretiske emner og hvordan man anvender Kubernetes på niveau med principper og mønstre.

Det andet forretningsmæssige ønske – gå ind på GitHub og giv os stjerner, for vi lever af dem. Hvis I ikke giver os stjerner, vil vi ikke have noget at spise. Det er som manna i et computerspil. Vi gør noget, gør noget, prøver, nogle siger, det er grimme cykler, andre siger, at alt overhovedet er forkert, men vi fortsætter og handler helt ærligt. Vi ser problemet, løser det og deler erfaringen. Derfor bedes I give os en stjerne, det koster ikke noget for jer, men vi får noget mere, for vi lever af dem.

Det tredje, vigtige, og allerede ikke-mercantile ønske – stop med at tro på eventyr. I er professionelle. DevOps er en meget seriøs og ansvarlig profession. Stop med at lege på arbejdspladsen. Lad det ramme jer, og I vil forstå det. Forestil jer, at I kommer ind på et hospital, og der eksperimenterer lægen med jer. Jeg forstår, at det kan såre nogen, men det er sandsynligvis ikke om jer, men om nogen andre. Fortæl de andre, at de også skal stoppe. Det ødelægger virkelig livet for os alle – mange begynder at se på driftsfolk, administratorer og DevOps’ere som fyre, der igen har noget gået galt. Det 'gået galt' sker oftest, fordi vi er gået i gang med at lege i stedet for at se klart og forstå, hvordan tingene hænger sammen.

Det betyder ikke, at man ikke skal eksperimentere. Man skal eksperimentere, vi gør det selv. Hvis vi skal være ærlige, leger vi også nogle gange — det er selvfølgelig meget dårligt, men intet menneskeligt er os fremmed. Lad os erklære 2019 som året for seriøse, gennemtænkte eksperimenter, ikke for lege i produktion. Måske er det sådan.

— Mange tak!

Dmitry: Tak til dig, Vitaly, både for tiden og interviewet. Kære læsere, mange tak til jer, hvis I er nået hertil. Jeg håber, vi har givet jer nogle tankevækkende indspark.

I interviewet berørte Dmitry spørgsmålet om werf. Det er nu en universel schweizerkniv, der løser næsten alle opgaver. Men det har ikke altid været sådan. DevOpsConf  på festivalen RIT++ Dmitry Stolyarov vil detaljeret fortælle om dette værktøj. I foredraget «werf — vores værktøj til CI/CD i Kubernetes» vil der være alt: problemer og skjulte nuancer i Kubernetes, løsninger på disse udfordringer og den nuværende implementering af werf i detaljer. Deltag den 27. og 28. maj, vi skal skabe ideelle værktøjer.

Kilde: habr.com