I forventning Vitaly Khabarov intervjuet Dmitry Stolyarov (), teknisk direktør og medgründer av Flant-selskapet. Vitaly spurte Dmitry om hva Flant gjør, om Kubernetes, økosystemutvikling, støtte. Vi diskuterte hvorfor Kubernetes er nødvendig og om det er nødvendig i det hele tatt. Og også om mikrotjenester, Amazon AWS, "I'll be lucky"-tilnærmingen til DevOps, fremtiden til Kubernetes selv, hvorfor, når og hvordan den vil ta over verden, utsiktene til DevOps og hva ingeniører bør forberede seg på i lys og nær fremtid med forenkling og nevrale nettverk.
lytt som podcast på DevOps Deflop – en russiskspråklig podcast om DevOps, og under er tekstversjonen.
Her og under stiller han spørsmål ingeniør fra Express42.
Om "Flant"
- Hei Dima. Du er teknisk direktør""og også dens grunnlegger. Fortell oss hva selskapet gjør og er du i det?
Dmitry: Fra utsiden virker det som om vi er gutta som går rundt og installerer Kubernetes for alle og gjør noe med det. Men det er ikke sant. Vi startet som et selskap som driver med Linux, men i svært lang tid har hovedaktiviteten vår vært å betjene produksjon og høylastede nøkkelferdige prosjekter. Vanligvis bygger vi hele infrastrukturen fra bunnen av og er ansvarlige for den i lang, lang tid. Derfor er hovedarbeidet som "Flant" gjør, som det mottar penger for ta ansvar og gjennomføre nøkkelferdig produksjon.
Jeg, som teknisk direktør og en av grunnleggerne av selskapet, bruker hele dagen og natten på å finne ut hvordan jeg kan øke tilgjengeligheten til produksjonen, forenkle driften, gjøre livet til administratorer enklere og livet til utviklerne mer behagelig. .
Om Kubernetes
— I det siste har jeg sett mange rapporter fra Flant og om Kubernetes. Hvordan kom du til det?
Dmitry: Jeg har allerede snakket om dette mange ganger, men jeg har ikke noe imot å gjenta det i det hele tatt. Jeg tror det er riktig å gjenta dette emnet fordi det er forvirring mellom årsak og virkning.
Vi trengte virkelig et verktøy. Vi møtte mange problemer, slet, overvant dem med forskjellige krykker og følte behov for et verktøy. Vi gikk gjennom mange forskjellige alternativer, bygde våre egne sykler og fikk erfaring. Gradvis kom vi til det punktet hvor vi begynte å bruke Docker nesten så snart det dukket opp - rundt 2013. På det tidspunktet det dukket opp, hadde vi allerede mye erfaring med containere, vi hadde allerede skrevet en analog av "Docker" - noen av våre egne krykker i Python. Med ankomsten av Docker ble det mulig å kaste ut krykkene og bruke en pålitelig og fellesskapsstøttet løsning.
Med Kubernetes er historien lik. Da det begynte å ta fart - for oss er dette versjon 1.2 - hadde vi allerede en haug med krykker på både Shell og Chef, som vi på en eller annen måte prøvde å orkestrere med Docker. Vi så seriøst mot Rancher og diverse andre løsninger, men så dukket det opp Kubernetes, der alt er implementert akkurat slik vi ville ha gjort det eller enda bedre. Det er ingenting å klage på.
Ja, det er en slags ufullkommenhet her, det er en slags ufullkommenhet der - det er mange ufullkommenheter, og 1.2 er generelt forferdelig, men... Kubernetes er som en bygning under konstruksjon - du ser på prosjektet og forstår at det blir kult. Hvis bygningen nå har et fundament og to etasjer, forstår du at det er bedre å ikke flytte inn ennå, men det er ingen slike problemer med programvaren - du kan allerede bruke den.
Vi hadde ikke et øyeblikk hvor vi tenkte på å bruke Kubernetes eller ikke. Vi ventet på den lenge før den dukket opp, og prøvde å lage analoger selv.
Om Kubernetes
— Er du direkte involvert i utviklingen av selve Kubernetes?
Dmitry: Middelmådig. Vi deltar heller i utviklingen av økosystemet. Vi sender et visst antall pull-forespørsler: til Prometheus, til forskjellige operatører, til Helm - til økosystemet. Dessverre klarer jeg ikke å holde styr på alt vi gjør og jeg kan ta feil, men det er ikke en eneste pulje fra oss inn i kjernen.
— Utvikler du samtidig mange av verktøyene dine rundt Kubernetes?
Dmitry: Strategien er denne: vi går og trekker forespørsler til alt som allerede eksisterer. Hvis pull-forespørsler ikke godtas der, deler vi dem ganske enkelt selv og lever til de blir akseptert med byggene våre. Så, når den når oppstrøms, går vi tilbake til oppstrømsversjonen.
For eksempel har vi en Prometheus-operatør, med hvilken vi byttet frem og tilbake til oppstrøms for forsamlingen vår sannsynligvis 5 ganger allerede. Vi trenger en slags funksjon, vi sendte en pull-forespørsel, vi må rulle den ut i morgen, men vi ønsker ikke å vente på at den blir utgitt oppstrøms. Følgelig setter vi sammen for oss selv, ruller ut sammenstillingen vår med funksjonen vår, som vi trenger av en eller annen grunn, til alle våre klynger. Så gir de det for eksempel til oss i oppstrøms med ordene: «Gutter, la oss gjøre det for en mer generell sak», vi, eller noen andre, fullfører den, og over tid smelter den sammen igjen.
Vi prøver å utvikle alt som finnes. Mange elementer som ennå ikke eksisterer, ennå ikke er oppfunnet, eller som er oppfunnet, men som ikke har hatt tid til å implementere – vi gjør det. Og ikke fordi vi liker prosessen eller sykkelbyggingen som industri, men rett og slett fordi vi trenger dette verktøyet. Spørsmålet stilles ofte, hvorfor gjorde vi denne eller den tingen? Svaret er enkelt - ja, fordi vi måtte gå lenger, løse et praktisk problem, og vi løste det med denne tulaen.
Veien er alltid slik: vi leter veldig nøye, og hvis vi ikke finner noen løsning på hvordan vi lager en trolleybuss av et brød, lager vi vårt eget brød og vår egen trolleybuss.
Flanta verktøy
— Jeg vet at Flant nå har tilleggsoperatører, skalloperatører og dapp/werf-verktøy. Slik jeg forstår det, er dette det samme instrumentet i forskjellige inkarnasjoner. Jeg forstår også at det er mange flere forskjellige verktøy innen Flaunt. Dette er sant?
Dmitry: Vi har mye mer på GitHub. Etter det jeg husker nå har vi et statuskart – et panel for Grafana som alle har vært borti. Det er nevnt i nesten annenhver artikkel om Kubernetes-overvåking på Medium. Det er umulig å kort forklare hva et statuskart er - det trenger en egen artikkel, men det er en veldig nyttig ting for å overvåke status over tid, siden vi i Kubernetes ofte må vise status over tid. Vi har også LogHouse - dette er en ting basert på ClickHouse og svart magi for å samle logger i Kubernetes.
Mange hjelpemidler! Og enda flere blir det, for det kommer en rekke interne løsninger i år. Av de veldig store basert på addon-operatøren, er det en haug med tillegg for Kubernetes, ala hvordan du installerer sert manager - et verktøy for å administrere sertifikater, hvordan du installerer Prometheus riktig med en haug med tilbehør - disse er omtrent tjue forskjellige binærfiler som eksporterer data og samler noe, til dette har Prometheus den mest fantastiske grafikken og varslene. Alt dette er bare en haug med tillegg til Kubernetes, som er installert i en klynge, og det går fra enkelt til kult, sofistikert, automatisk, der mange problemer allerede er løst. Ja, vi gjør mye.
Økosystemutvikling
"Det virker for meg at dette er et veldig stort bidrag til utviklingen av dette instrumentet og dets bruksmetoder." Kan du grovt anslå hvem andre som ville gitt samme bidrag til utviklingen av økosystemet?
Dmitry: I Russland, av selskapene som opererer i vårt marked, er ingen i nærheten engang. Selvfølgelig er dette en høylytt uttalelse, fordi det er store aktører som Mail og Yandex - de gjør også noe med Kubernetes, men selv de kommer ikke i nærheten av bidraget fra selskaper i hele verden som gjør mye mer enn oss. Det er vanskelig å sammenligne Flant, som har en stab på 80 personer, og Red Hat, som har 300 ingeniører per Kubernetes alene, hvis jeg ikke tar feil. Det er vanskelig å sammenligne. Vi har 6 personer i RnD-avdelingen, inkludert meg, som kutter alt verktøyet vårt. 6 personer mot 300 Red Hat-ingeniører - det er på en eller annen måte vanskelig å sammenligne.
- Men når selv disse 6 personene kan gjøre noe virkelig nyttig og fremmedgjørende, når de står overfor et praktisk problem og gir løsningen til fellesskapet - en interessant sak. Jeg forstår at i store teknologibedrifter, hvor de har sitt eget utviklings- og støtteteam for Kubernetes, kan i prinsippet de samme verktøyene utvikles. Dette er et eksempel for dem på hva som kan utvikles og gis til fellesskapet, og gir impulser til hele samfunnet som bruker Kubernetes.
Dmitry: Dette er sannsynligvis et trekk ved integratoren, dens særegenhet. Vi har mange prosjekter og vi ser mange forskjellige situasjoner. For oss er den viktigste måten å skape merverdi på å analysere disse sakene, finne fellestrekk og gjøre dem så billige som mulig for oss. Vi jobber aktivt med dette. Det er vanskelig for meg å snakke om Russland og verden, men vi har rundt 40 DevOps-ingeniører i selskapet som jobber på Kubernetes. Jeg tror ikke det er mange selskaper i Russland med et sammenlignbart antall spesialister som forstår Kubernetes, om noen i det hele tatt.
Jeg forstår alt om stillingstittelen DevOps-ingeniør, alle forstår alt og er vant til å kalle DevOps-ingeniører for DevOps-ingeniører, dette skal vi ikke diskutere. Alle disse 40 fantastiske DevOps-ingeniørene møter og løser problemer hver dag, vi analyserer bare denne opplevelsen og prøver å generalisere. Vi forstår at hvis det forblir inne i oss, vil verktøyet være ubrukelig om et år eller to, for et sted i samfunnet vil en ferdig Tula dukke opp. Det er ingen vits i å samle denne erfaringen internt - det er rett og slett å tappe energi og tid til dev/null. Og vi synes ikke synd på det i det hele tatt. Vi publiserer alt med stor glede og forstår at det må publiseres, utvikles, promoteres, promoteres, slik at folk bruker det og legger til sin erfaring – så vokser alt og lever. Så etter to år går ikke instrumentet i søpla. Det er ikke synd å fortsette å øse inn styrke, for det er tydelig at noen bruker verktøyet ditt, og etter to år bruker alle det.
Dette er en del av vår store strategi med dapp/werf. Jeg husker ikke når vi begynte å lage den, det virker som 3 år siden. I utgangspunktet var det generelt på skallet. Det var et super proof of concept, vi løste noen av våre spesielle problemer - det fungerte! Men det er problemer med skallet, det er umulig å utvide det ytterligere, programmering på skallet er en annen oppgave. Vi hadde en vane med å skrive i Ruby, følgelig gjenskapte vi noe i Ruby, utviklet, utviklet, utviklet og løp inn i det faktum at samfunnet, mengden som ikke sier "vi vil ha det eller vi vil ikke ha det, ” vender nesen opp mot Ruby, hvor morsomt er det? Vi innså at vi burde skrive alt dette i Go bare for å møte det første punktet på sjekklisten: DevOps-verktøyet skal være en statisk binær. Å være Go eller ikke er ikke så viktig, men en statisk binær skrevet i Go er bedre.
Vi brukte energien vår, skrev om dappen i Go og kalte den werf. Dapp er ikke lenger støttet, ikke utviklet, kjører i en eller annen siste versjon, men det er en absolutt oppgraderingsvei til toppen, og du kan følge den.
Hvorfor ble dappen opprettet?
— Kan du kort fortelle oss hvorfor dappen ble opprettet, hvilke problemer den løser?
Dmitry: Den første grunnen er i forsamlingen. Til å begynne med hadde vi alvorlige problemer med byggingen da Docker ikke hadde flertrinnsfunksjoner, så vi laget flertrinns på egen hånd. Så hadde vi flere problemer med å rense bildet. Alle som driver med CI/CD, før heller enn senere, står overfor problemet med at det er en haug med innsamlede bilder, du må på en eller annen måte rydde ut det som ikke trengs og la det som trengs.
Den andre grunnen er utplassering. Ja, det er Helm, men det løser bare noen av problemene. Morsomt nok skrives det at "Helm er pakkebehandleren for Kubernetes." Nøyaktig hva "den". Det er også ordene "Package Manager" - hva er den vanlige forventningen fra en Package Manager? Vi sier: "Package Manager - installer pakken!" og vi forventer at han forteller oss: "Pakken er levert."
Det er interessant at vi sier: "Helm, installer pakken," og når han svarer at han installerte den, viser det seg at han nettopp startet installasjonen - han indikerte Kubernetes: "Start denne tingen!", og om den startet eller ikke , enten det fungerer eller ikke, løser ikke Helm dette problemet i det hele tatt.
Det viser seg at Helm bare er en tekstforbehandler som laster data inn i Kubernetes.
Men som en del av enhver distribusjon, ønsker vi å vite om applikasjonen er utgitt for produksjon eller ikke? Utrullet til prod betyr at applikasjonen har flyttet dit, den nye versjonen har blitt distribuert, og i det minste krasjer den ikke der og svarer riktig. Helm løser ikke dette problemet på noen måte. For å løse det, må du bruke mye krefter, fordi du må gi Kubernetes kommandoen til å rulle ut og overvåke hva som skjer der - enten det er distribuert eller rullet ut. Og det er også mange oppgaver knyttet til utplassering, rengjøring og montering.
Planer
I år starter vi lokal utvikling. Vi ønsker å oppnå det som tidligere var i Vagrant - vi skrev "vagrant up" og vi distribuerte virtuelle maskiner. Vi ønsker å komme til det punktet hvor det er et prosjekt i Git, vi skriver "werf opp" der, og det tar opp en lokal kopi av dette prosjektet, distribuert i en lokal mini-Kub, med alle katalogene som er praktiske for utvikling koblet til . Avhengig av utviklingsspråket gjøres dette annerledes, men likevel slik at lokal utvikling enkelt kan utføres under monterte filer.
Neste steg for oss er investere i bekvemmelighet for utviklere. For raskt å distribuere et prosjekt lokalt med ett verktøy, utvikle det, skyve det inn i Git, og det vil også rulle ut til scenen eller tester, avhengig av rørledningene, og deretter bruke det samme verktøyet for å gå til produksjon. Denne enheten, foreningen, reproduserbarheten av infrastruktur fra lokalmiljøet til salg er et veldig viktig poeng for oss. Men dette er ikke i werf ennå - vi planlegger bare å gjøre det.
Men veien til dapp/werf har alltid vært den samme som med Kubernetes i begynnelsen. Vi møtte problemer, løste dem med løsninger - vi kom opp med noen løsninger for oss selv på skallet, på hva som helst. Så prøvde de på en eller annen måte å rette opp disse løsningene, generalisere og konsolidere dem til binære filer i dette tilfellet, som vi ganske enkelt deler.
Det er en annen måte å se på hele denne historien, med analogier.
Kubernetes er en bilramme med motor. Det er ingen dører, glass, radio, juletre - ingenting i det hele tatt. Bare rammen og motoren. Og det er Helm - dette er rattet. Kult - det er et ratt, men du trenger også en rattpinne, rattstativ, girkasse og hjul, og du kan ikke klare deg uten dem.
Når det gjelder werf, er dette en annen komponent til Kubernetes. Først nå i alfaversjonen av werf, for eksempel, er Helm kompilert inne i werf, fordi vi er lei av å gjøre det selv. Det er mange grunner til å gjøre dette, jeg skal fortelle deg i detalj om hvorfor vi kompilerte hele roret sammen med rorkult inne i werf .
Nå er werf en mer integrert komponent. Vi får et ferdig ratt, en styrepinne - jeg er ikke så god på biler, men dette er en stor blokk som allerede løser et ganske bredt spekter av problemer. Vi trenger ikke gå gjennom katalogen selv, velge en del for en annen, tenke på hvordan vi skal skru dem sammen. Vi får en ferdig skurtresker som løser en lang rekke problemer på en gang. Men innvendig er den bygget fra de samme open source-komponentene, den bruker fortsatt Docker for montering, Helm for noe av funksjonaliteten, og det er flere andre biblioteker. Dette er et integrert verktøy for å få kul CI/CD ut av esken raskt og enkelt.
Er Kubernetes vanskelig å vedlikeholde?
— Du snakker om opplevelsen av at du begynte å bruke Kubernetes, dette er en ramme for deg, en motor, og at du kan henge mye forskjellig på den: et karosseri, et ratt, skru på pedaler, seter. Spørsmålet oppstår - hvor vanskelig er Kubernetes-støtte for deg? Du har mye erfaring, hvor mye tid og ressurser bruker du på å støtte Kubernetes isolert fra alt annet?
Dmitry: Dette er et veldig vanskelig spørsmål, og for å svare på, må vi forstå hva støtte er og hva vi ønsker fra Kubernetes. Kanskje du kan avsløre?
— Så vidt jeg vet og ser, er det nå mange lag som ønsker å prøve Kubernetes. Alle spenner seg til det, legger det på knærne. Jeg har en følelse av at folk ikke alltid forstår kompleksiteten i dette systemet.
Dmitry: Det er slik det er.
— Hvor vanskelig er det å ta og installere Kubernetes fra bunnen av slik at den er produksjonsklar?
Dmitry: Hvor vanskelig tror du det er å transplantere et hjerte? Jeg forstår at dette er et kompromitterende spørsmål. Å bruke en skalpell og ikke gjøre feil er ikke så vanskelig. Hvis de forteller deg hvor du skal klippe og hvor du skal sy, er selve prosedyren ikke komplisert. Det er vanskelig å garantere gang på gang at alt ordner seg.
Det er enkelt å installere Kubernetes og få det til å fungere: chick! - installert, det er mange installasjonsmetoder. Men hva skjer når problemer oppstår?
Spørsmål dukker alltid opp – hva har vi ikke tatt hensyn til ennå? Hva har vi ikke gjort ennå? Hvilke Linux-kjerneparametere ble angitt feil? Herre, nevnte vi dem i det hele tatt?! Hvilke Kubernetes-komponenter har vi levert og hvilke har vi ikke? Tusenvis av spørsmål dukker opp, og for å svare på dem må du bruke 15-20 år i denne bransjen.
Jeg har et nylig eksempel om dette emnet som kan avsløre betydningen av problemet "Er Kubernetes vanskelig å vedlikeholde?" For en tid tilbake vurderte vi seriøst om vi skulle prøve å implementere Cilium som et nettverk i Kubernetes.
La meg forklare hva Cilium er. Kubernetes har mange forskjellige implementeringer av nettverksundersystemet, og en av dem er veldig kul - Cilium. Hva er dens betydning? I kjernen ble det for en tid siden mulig å skrive kroker for kjernen, som på en eller annen måte invaderer nettverksundersystemet og diverse andre undersystemer, og lar deg omgå store biter i kjernen.
Linux-kjernen har historisk sett en ip-rute, et overfilter, broer og mange forskjellige gamle komponenter som er 15, 20, 30 år gamle. Generelt fungerer de, alt er flott, men nå har de stablet opp containere, og det ser ut som et tårn av 15 murstein oppå hverandre, og du står på det på ett ben - en merkelig følelse. Dette systemet har historisk utviklet seg med mange nyanser, som blindtarmen i kroppen. I noen situasjoner er det for eksempel ytelsesproblemer.
Det er en fantastisk BPF og muligheten til å skrive kroker for kjernen - gutta skrev sine egne kroker for kjernen. Pakken kommer inn i Linux-kjernen, de tar den ut rett ved inngangen, behandler den selv som den skal uten broer, uten TCP, uten IP-stack - kort sagt, omgår alt som er skrevet i Linux-kjernen, og spytter deretter den ut i beholderen.
Hva skjedde? Veldig kul ytelse, kule funksjoner - bare kult! Men vi ser på dette og ser at på hver maskin er det et program som kobles til Kubernetes API og, basert på dataene det mottar fra denne APIen, genererer C-kode og kompilerer binærfiler som det laster inn i kjernen slik at disse krokene fungerer i kjernerommet.
Hva skjer hvis noe går galt? Vi vet ikke. For å forstå dette må du lese all denne koden, forstå all logikken, og det er utrolig hvor vanskelig det er. Men på den annen side er det disse broene, nettfiltrene, ip-ruten - jeg har ikke lest kildekoden deres, og det har heller ikke de 40 ingeniørene som jobber i selskapet vårt. Kanskje bare noen få forstår noen deler.
Og hva er forskjellen? Det viser seg at det er ip-rute, Linux-kjernen, og det er et nytt verktøy - hvilken forskjell gjør det, vi forstår ikke det ene eller det andre. Men vi er redde for å bruke noe nytt – hvorfor? For hvis verktøyet er 30 år gammelt, så er alle feilene funnet på 30 år, alle feilene har blitt tråkket på og du trenger ikke å vite om alt - det fungerer som en svart boks og fungerer alltid. Alle vet hvilken diagnostisk skrutrekker som skal stikkes på hvilket sted, hvilken tcpdump som skal kjøres i hvilket øyeblikk. Alle kjenner diagnoseverktøy godt og forstår hvordan dette settet med komponenter fungerer i Linux-kjernen - ikke hvordan det fungerer, men hvordan det brukes.
Og den utrolig kule Cilium er ikke 30 år gammel, den er ikke gammel ennå. Kubernetes har det samme problemet, kopi. At Cilium er installert perfekt, at Kubernetes er installert perfekt, men når noe går galt i produksjonen, klarer du raskt å forstå i en kritisk situasjon hva som gikk galt?
Når vi sier er det vanskelig å vedlikeholde Kubernetes - nei, det er veldig enkelt, og ja, det er utrolig vanskelig. Kubernetes fungerer utmerket alene, men med en milliard nyanser.
Om "I'll be lucky"-tilnærmingen
— Finnes det selskaper hvor disse nyansene nesten garantert dukker opp? Anta at Yandex plutselig overfører alle tjenester til Kubernetes, vil det være en enorm belastning der.
Dmitry: Nei, dette er ikke en samtale om belastningen, men om de enkleste ting. For eksempel har vi Kubernetes, vi distribuerte applikasjonen der. Hvordan vet du at det fungerer? Det er rett og slett ikke noe ferdig verktøy for å forstå at applikasjonen ikke krasjer. Det er ikke noe ferdig system som sender varsler; du må konfigurere disse varslene og hver tidsplan. Og vi oppdaterer Kubernetes.
Jeg har Ubuntu 16.04. Du kan si at dette er en gammel versjon, men vi er fortsatt på den fordi den er LTS. Det er systemd, hvor nyansen er at den ikke rydder opp i C-grupper. Kubernetes lanserer pods, oppretter C-grupper, sletter deretter pods, og på en eller annen måte viser det seg - jeg husker ikke detaljene, beklager - at systemd-slicer forblir. Dette fører til det faktum at over tid begynner enhver bil å bremse kraftig. Dette er ikke engang et spørsmål om høybelastning. Hvis permanente poder lanseres, for eksempel, hvis det er en Cron Job som konstant genererer pods, vil maskinen med Ubuntu 16.04 begynne å bremse etter en uke. Det vil være et konstant høyt belastningsgjennomsnitt på grunn av at det er opprettet en haug med C-grupper. Dette er problemet som enhver person som bare installerer Ubuntu 16 og Kubernetes på toppen vil møte.
La oss si at han på en eller annen måte oppdaterer systemd eller noe annet, men i Linux-kjernen opp til 4.16 er det enda morsommere - når du sletter C-grupper, lekker de i kjernen og blir faktisk ikke slettet. Derfor, etter en måneds arbeid med denne maskinen, vil det være umulig å se på minnestatistikken for ildstedene. Vi tar ut en fil, ruller den inn i programmet, og en fil ruller i 15 sekunder, fordi kjernen bruker veldig lang tid på å telle en million C-grupper i seg selv, som ser ut til å være slettet, men nei - de lekker .
Det er fortsatt mange slike småting her og der. Dette er ikke et problem som gigantiske selskaper noen ganger kan møte under svært store belastninger – nei, det er et spørsmål om hverdagslige ting. Folk kan leve slik i flere måneder – de installerte Kubernetes, distribuerte applikasjonen – det ser ut til å fungere. For mange mennesker er dette normalt. De vil ikke engang vite at denne applikasjonen vil krasje av en eller annen grunn, de vil ikke motta et varsel, men for dem er dette normen. Tidligere levde vi på virtuelle maskiner uten overvåking, nå flyttet vi til Kubernetes, også uten overvåking – hva er forskjellen?
Spørsmålet er at når vi går på is, vet vi aldri tykkelsen med mindre vi måler den på forhånd. Mange går og bekymrer seg ikke, fordi de har gått før.
Fra mitt synspunkt er nyansen og kompleksiteten ved å betjene ethvert system å sikre at tykkelsen på isen er nøyaktig nok til å løse problemene våre. Det er dette vi snakker om.
Innen IT virker det for meg at det er for mange "I'll be lucky"-tilnærminger. Mange installerer programvare og bruker programvarebibliotek i håp om at de skal være heldige. Generelt er mange mennesker heldige. Det er nok derfor det fungerer.
— Fra min pessimistiske vurdering ser det slik ut: når risikoen er høy, og applikasjonen må fungere, så trengs støtte fra Flaunt, kanskje fra Red Hat, eller du trenger ditt eget interne team dedikert spesifikt til Kubernetes, som er klart å trekke den av.
Dmitry: Objektivt sett er det slik. Å komme inn i Kubernetes-historien for et lite team på egen hånd innebærer en rekke risikoer.
Trenger vi containere?
— Kan du fortelle oss hvor utbredt Kubernetes er i Russland?
Dmitry: Jeg har ikke disse dataene, og jeg er ikke sikker på at noen andre har dem. Vi sier: "Kubernetes, Kubernetes," men det er en annen måte å se på dette problemet. Jeg vet heller ikke hvor utbredt containere er, men jeg vet et tall fra rapporter på Internett om at 70 % av containerne er orkestrert av Kubernetes. Det var en pålitelig kilde for et ganske stort utvalg rundt om i verden.
Så et annet spørsmål - trenger vi containere? Min personlige følelse og den generelle posisjonen til Flant-selskapet er at Kubernetes er en de facto standard.
Det vil ikke være noe annet enn Kubernetes.
Dette er en absolutt gamechanger innen infrastrukturstyring. Bare absolutt - det er det, ikke mer Ansible, Chef, virtuelle maskiner, Terraform. Jeg snakker ikke om de gamle kollektivbruksmetodene. Kubernetes er en absolutt forandring, og nå blir det bare slik.
Det er klart at det for noen tar et par år, og for andre et par tiår, å innse dette. Jeg er ikke i tvil om at det ikke vil være noe annet enn Kubernetes og dette nye utseendet: vi skader ikke lenger operativsystemet, men bruker infrastruktur som kode, bare ikke med kode, men med yml - en deklarativt beskrevet infrastruktur. Jeg har en følelse av at det alltid vil være slik.
— Det vil si at de selskapene som ennå ikke har gått over til Kubernetes vil definitivt bytte til det eller forbli i glemselen. Jeg forsto deg rett?
Dmitry: Dette er heller ikke helt sant. For eksempel, hvis vi har som oppgave å kjøre en DNS-server, kan den kjøres på FreeBSD 4.10 og den kan fungere perfekt i 20 år. Bare jobb og det er det. Kanskje om 20 år må noe oppdateres en gang. Hvis vi snakker om programvare i formatet vi lanserte, og det faktisk fungerer i mange år uten noen oppdateringer, uten å gjøre endringer, så vil det selvfølgelig ikke være noen Kubernetes. Han er ikke nødvendig der.
Alt relatert til CI/CD - uansett hvor Continuous Delivery er nødvendig, hvor du trenger å oppdatere versjoner, gjøre aktive endringer, uansett hvor du trenger å bygge feiltoleranse - kun Kubernetes.
Om mikrotjenester
– Her har jeg en liten dissonans. For å jobbe med Kubernetes trenger du ekstern eller intern støtte - dette er det første punktet. For det andre, når vi nettopp har startet utvikling, er vi en liten oppstart, vi har ikke noe ennå, utvikling for Kubernetes eller mikrotjenestearkitektur generelt kan være kompleks og ikke alltid økonomisk berettiget. Jeg er interessert i din mening - må startups umiddelbart begynne å skrive for Kubernetes fra bunnen av, eller kan de fortsatt skrive en monolitt, og så bare komme til Kubernetes?
Dmitry: Kult spørsmål. Jeg har en prat om mikrotjenester Mange ganger har jeg møtt folk som prøver å slå spiker med et mikroskop. Selve tilnærmingen er riktig, vi designer selv vår interne programvare på denne måten. Men når du gjør dette, må du tydelig forstå hva du gjør. Ordet jeg hater mest om mikrotjenester er "mikro." Historisk sett oppsto dette ordet der, og av en eller annen grunn tror folk at mikro er veldig lite, mindre enn en millimeter, som en mikrometer. Dette er feil.
For eksempel er det en monolitt som er skrevet av 300 personer, og alle som har deltatt i utviklingen forstår at det er problemer der, og den bør brytes i mikrobiter - ca 10 stykker, som hver er skrevet av 30 personer i en minimumsversjon. Dette er viktig, nødvendig og kult. Men når en oppstart kommer til oss, hvor 3 veldig kule og talentfulle gutter skrev 60 mikrotjenester på knærne, hver gang jeg ser etter Corvalol.
Det virker for meg som om dette allerede har blitt snakket om tusenvis av ganger - vi fikk en distribuert monolitt i en eller annen form. Dette er ikke økonomisk begrunnet, det er veldig vanskelig generelt i alt. Jeg har nettopp sett dette så mange ganger at det gjør meg virkelig vondt, så jeg fortsetter å snakke om det.
Til det første spørsmålet er det en konflikt mellom det faktum at Kubernetes på den ene siden er skummelt å bruke, fordi det ikke er klart hva som kan gå i stykker eller ikke fungere, på den andre siden er det klart at alt går der og ingenting annet enn Kubernetes vil eksistere. Svar - veie mengden nytte som kommer, mengden oppgaver du kan løse. Dette er på den ene siden av skalaen. På den annen side er det risiko forbundet med nedetid eller med reduksjon i responstid, tilgjengelighetsnivå - med reduksjon i ytelsesindikatorer.
Her er det – enten beveger vi oss raskt, og Kubernetes lar oss gjøre mange ting mye raskere og bedre, eller så bruker vi pålitelige, tidstestede løsninger, men beveger oss mye saktere. Dette er et valg hver bedrift må ta. Du kan tenke på det som en sti i jungelen - når du går for første gang, kan du møte en slange, en tiger eller en gal grevling, og når du har gått 10 ganger, har du tråkket stien, fjernet grenene og gå lettere. Hver gang blir stien bredere. Så er det asfaltvei, og senere en vakker boulevard.
Kubernetes står ikke stille. Spørsmål igjen: Kubernetes er på den ene siden 4-5 binære filer, på den andre siden er det hele økosystemet. Dette er operativsystemet vi har på maskinene våre. Hva er dette? Ubuntu eller Curios? Dette er Linux-kjernen, en haug med tilleggskomponenter. Alle disse tingene her, en giftig slange ble kastet ut av veien, et gjerde ble satt opp der. Kubernetes utvikler seg veldig raskt og dynamisk, og volumet av risikoer, volumet av det ukjente synker hver måned, og følgelig rebalanserer disse skalaene.
Når jeg svarer på spørsmålet om hva en oppstart bør gjøre, vil jeg si - kom til Flaunt, betal 150 tusen rubler og få en nøkkelferdig DevOps-enkel tjeneste. Hvis du er en liten startup med noen få utviklere, fungerer dette. I stedet for å ansette dine egne DevOps, som må lære å løse problemene dine og betale lønn på dette tidspunktet, vil du få en nøkkelferdig løsning på alle problemer. Ja, det er noen ulemper. Vi som outsourcer kan ikke være så involvert og reagere raskt på endringer. Men vi har mye kompetanse og ferdige praksiser. Vi garanterer at i enhver situasjon vil vi definitivt raskt finne ut av det og reise eventuelle Kubernetes fra de døde.
Jeg anbefaler på det sterkeste å outsource til startups og etablerte virksomheter opp til en størrelse hvor du kan dedikere et team på 10 personer til driften, for ellers er det ingen vits. Det er definitivt fornuftig å outsource dette.
Om Amazon og Google
— Kan en vert fra en løsning fra Amazon eller Google betraktes som en outsource?
Dmitry: Ja, selvfølgelig, dette løser en rekke problemer. Men igjen er det nyanser. Du må fortsatt forstå hvordan du bruker den. For eksempel er det tusen småting i arbeidet til Amazon AWS: Load Balancer må varmes opp eller en forespørsel må skrives på forhånd om at "gutta, vi vil motta trafikk, varm opp Load Balancer for oss!" Du må kjenne til disse nyansene.
Når du henvender deg til folk som spesialiserer seg på dette, får du nesten alle de typiske tingene lukket. Vi har nå 40 ingeniører, innen utgangen av året vil det trolig være 60 - vi har definitivt støtt på alle disse tingene. Selv om vi støter på dette problemet igjen på et eller annet prosjekt, spør vi raskt hverandre og vet hvordan vi skal løse det.
Sannsynligvis er svaret - selvfølgelig, en vertshistorie gjør en del enklere. Spørsmålet er om du er klar til å stole på disse hosterne og om de vil løse problemene dine. Amazon og Google har gjort det bra. For alle våre saker – akkurat. Vi har ikke flere positive erfaringer. Alle de andre skyene som vi prøvde å jobbe med skaper mange problemer - Ager, og alt som er i Russland, og alle slags OpenStack i forskjellige implementeringer: Headster, Overage - hva du vil. De skaper alle problemer som du ikke ønsker å løse.
Derfor er svaret ja, men det er faktisk ikke så mange modne vertsløsninger.
Hvem trenger Kubernetes?
— Og likevel, hvem trenger Kubernetes? Hvem bør allerede bytte til Kubernetes, hvem er den typiske Flaunt-klienten som kommer spesielt for Kubernetes?
Dmitry: Dette er et interessant spørsmål, for akkurat nå, i kjølvannet av Kubernetes, kommer mange mennesker til oss: "Gutter, vi vet at dere driver med Kubernetes, gjør det for oss!" Vi svarer dem: "Mine herrer, vi driver ikke med Kubernetes, vi driver med prod og alt som er forbundet med det." For det er foreløpig rett og slett umulig å lage et produkt uten å gjøre all CI/CD og hele denne historien. Alle har gått bort fra inndelingen at vi har utvikling for utvikling, og deretter utnyttelse for utnyttelse.
Våre kunder forventer forskjellige ting, men alle forventer et godt mirakel at de har visse problemer, og nå - hopp! — Kubernetes vil løse dem. Folk tror på mirakler. I tankene deres forstår de at det ikke vil skje noe mirakel, men i sjelen deres håper de - hva om denne Kubernetes nå vil løse alt for oss, de snakker så mye om det! Plutselig han nå - nys! - og en sølvkule, nys! – og vi har 100 % oppetid, alle utviklere kan slippe det som kommer i produksjon 50 ganger, og det krasjer ikke. Generelt et mirakel!
Når slike mennesker kommer til oss, sier vi: "Beklager, men det er ikke noe som heter et mirakel." For å være sunn må du spise godt og trene. For å ha et pålitelig produkt, må det lages pålitelig. For å ha en praktisk CI/CD må du lage den slik. Det er mye arbeid som må gjøres.
Å svare på spørsmålet om hvem som trenger Kubernetes - ingen trenger Kubernetes.
Noen mennesker har misforståelsen om at de trenger Kubernetes. Folk trenger, de har et dypt behov for å slutte å tenke, studere og være interessert i alle problemene med infrastruktur og problemene med å kjøre applikasjonene deres. De vil at applikasjoner bare skal fungere og bare distribuere. For dem er Kubernetes håpet om at de skal slutte å høre historien om at «vi lå der» eller «vi kan ikke rulle ut» eller noe annet.
Teknisk direktør kommer vanligvis til oss. De spør ham om to ting: på den ene siden, gi oss funksjoner, på den andre siden stabilitet. Vi foreslår at du tar det på deg selv og gjør det. Sølvkulen, eller rettere sagt sølvbelagt, er at du vil slutte å tenke på disse problemene og kaste bort tid. Du vil ha spesielle personer som vil lukke denne saken.
Ordlyden om at vi eller noen andre trenger Kubernetes er feil.
Administratorer trenger virkelig Kubernetes, fordi det er et veldig interessant leketøy som du kan leke med og tukle med. La oss være ærlige - alle elsker leker. Vi er alle barn et sted, og når vi ser en ny, vil vi leke den. For noen har dette blitt frarådet, for eksempel i administrasjonen, fordi de allerede har spilt nok og allerede er trøtte til det punktet at de rett og slett ikke vil. Men dette er ikke helt tapt for noen. For eksempel, hvis jeg har vært lei av leker innen systemadministrasjon og DevOps i lang tid, så elsker jeg fortsatt lekene, jeg kjøper fortsatt noen nye. Alle mennesker, på en eller annen måte, vil fortsatt ha en slags leker.
Du trenger ikke å leke med produksjonen. Uansett hva jeg kategorisk anbefaler å ikke gjøre og hva jeg ser nå i massevis: "Å, en ny leke!" — de løp for å kjøpe den, kjøpte den og: «La oss ta den med på skolen nå og vise den til alle vennene våre.» Ikke gjør dette. Jeg beklager, barna mine vokser bare opp, jeg ser hele tiden noe hos barn, legger merke til det hos meg selv og generaliserer det til andre.
Det endelige svaret er: du trenger ikke Kubernetes. Du må løse problemene dine.
Det du kan oppnå er:
- prod faller ikke;
- selv om han prøver å falle, vet vi om det på forhånd, og vi kan legge noe i det;
- vi kan endre det med den hastigheten virksomheten vår krever det med, og vi kan gjøre det enkelt; det forårsaker oss ingen problemer.
Det er to reelle behov: pålitelighet og dynamikk/fleksibilitet ved utrulling. Alle som for tiden driver med en slags IT-prosjekter, uansett hva slags virksomhet – myk for å lette verden, og som forstår dette, må løse disse behovene. Kubernetes med riktig tilnærming, med riktig forståelse og med nok erfaring lar deg løse dem.
Om serverløs
— Hvis du ser litt lenger inn i fremtiden, for så å prøve å løse problemet med fravær av hodepine med infrastruktur, med hastigheten på utrullingen og hastigheten på applikasjonsendringer, dukker det opp nye løsninger, for eksempel serverløse. Føler du noe potensial i denne retningen og, la oss si, en fare for Kubernetes og lignende løsninger?
Dmitry: Her må vi igjen komme med en bemerkning om at jeg ikke er en seer som ser framover og sier – slik blir det! Selv om jeg nettopp gjorde det samme. Jeg ser på føttene mine og ser en haug med problemer der, for eksempel hvordan transistorer fungerer i en datamaskin. Det er morsomt, ikke sant? Vi møter noen feil i CPU.
Gjør serverløs ganske pålitelig, billig, effektiv og praktisk, og løser alle økosystemproblemer. Her er jeg enig med Elon Musk i at en andre planet er nødvendig for å skape feiltoleranse for menneskeheten. Selv om jeg ikke vet hva han sier, forstår jeg at jeg ikke er klar til å fly til Mars selv, og det vil ikke skje i morgen.
Med serverless er det klart at dette er en ideologisk korrekt ting, som feiltoleranse for menneskeheten - å ha to planeter er bedre enn én. Men hvordan gjør man det nå? Å sende én ekspedisjon er ikke noe problem hvis du konsentrerer innsatsen om det. Å sende flere ekspedisjoner og bosette flere tusen mennesker der tror jeg også er realistisk. Men å gjøre det fullstendig feiltolerant slik at halvparten av menneskeheten bor der, det virker for meg nå umulig, ikke tatt i betraktning.
Med serverløs én mot én: tingen er kul, men den er langt fra problemene i 2019. Nærmere 2030 - la oss leve for å se det. Jeg er ikke i tvil om at vi kommer til å leve, vi vil definitivt leve (gjenta før vi legger oss), men nå må vi løse andre problemer. Det er som å tro på eventyrponnien Rainbow. Ja, et par prosent av sakene blir løst, og de løses perfekt, men subjektivt sett er serverløs en regnbue... For meg er dette temaet for fjernt og for uforståelig. Jeg er ikke klar til å snakke. I 2019 kan du ikke skrive en enkelt applikasjon med serverløs.
Hvordan Kubernetes vil utvikle seg
— Når vi beveger oss mot denne potensielt fantastiske fjerne fremtiden, hvordan tror du Kubernetes og økosystemet rundt det vil utvikle seg?
Dmitry: Jeg har tenkt mye på dette og har et klart svar. Den første er statefull - tross alt er statsløs lettere å gjøre. Kubernetes investerte i utgangspunktet mer i dette, det hele begynte med det. Stateless fungerer nesten perfekt i Kubernetes, det er bare ingenting å klage på. Det er fortsatt mange problemer, eller rettere sagt, nyanser. Alt der fungerer allerede bra for oss, men det er oss. Det vil ta minst et par år til før dette fungerer for alle. Dette er ikke en beregnet indikator, men min følelse fra hodet mitt.
Kort sagt, statefull bør - og vil - utvikle seg veldig sterkt, fordi alle applikasjonene våre lagrer status; det er ingen statsløse applikasjoner. Dette er en illusjon; du trenger alltid en slags database og noe annet. Statefull handler om å rette ut alt som er mulig, fikse alle feilene, forbedre alle problemene som for tiden står overfor – la oss kalle det adopsjon.
Nivået på det ukjente, nivået av uløste problemer, nivået av sannsynlighet for å møte noe vil synke betydelig. Dette er en viktig historie. Og operatører - alt relatert til kodifisering av administrasjonslogikk, kontrolllogikk for å få en enkel tjeneste: MySQL enkel service, RabbitMQ enkel service, Memcache enkel service - generelt, alle disse komponentene som vi må garantert fungere ut av boksen. Dette løser bare smerten at vi vil ha en database, men vi vil ikke administrere den, eller vi vil ha Kubernetes, men vi vil ikke administrere den.
Denne historien om operatørutvikling i en eller annen form vil være viktig de neste par årene.
Jeg tror brukervennligheten bør øke kraftig – boksen vil bli mer og mer svart, mer og mer pålitelig, med flere og flere enkle knotter.
Jeg hørte en gang på et gammelt intervju med Isaac Asimov fra 80-tallet på YouTube på Saturday Night Live – et program som Urgant, bare interessant. De spurte ham om fremtiden til datamaskiner. Han sa at fremtiden er i enkelhet, akkurat som radioen. Radiomottakeren var opprinnelig en kompleks ting. For å fange en bølge, måtte du vri knottene i 15 minutter, snu på spydene og generelt vite hvordan alt fungerer, forstå fysikken til radiobølgeoverføring. Som et resultat var det bare én knott igjen i radioen.
Hvilken radio nå i 2019? I bilen finner radiomottakeren alle bølgene og navnene på stasjonene. Fysikken i prosessen har ikke endret seg på 100 år, men brukervennligheten har gjort det. Nå, og ikke bare nå, allerede i 1980, da det var et intervju med Azimov, brukte alle radioen og ingen tenkte på hvordan det fungerte. Det har alltid fungert – det er gitt.
Azimov sa da at det ville være det samme med datamaskiner - brukervennligheten vil øke. Mens du i 1980 måtte være opplært til å trykke på knapper på en datamaskin, vil det ikke være tilfelle i fremtiden.
Jeg har en følelse av at med Kubernetes og med infrastrukturen vil det også bli en enorm økning i brukervennligheten. Dette er etter min mening åpenbart - det ligger på overflaten.
Hva skal man gjøre med ingeniører?
— Hva vil da skje med ingeniørene og systemadministratorene som støtter Kubernetes?
Dmitry: Hva skjedde med regnskapsføreren etter ankomsten av 1C? Omtrent det samme. Før dette telte de på papiret – nå i programmet. Arbeidsproduktiviteten har økt i størrelsesordener, men selve arbeidskraften har ikke forsvunnet. Hvis det tidligere måtte 10 ingeniører til for å skru inn en lyspære, vil nå én være nok.
Mengden programvare og antall oppgaver, ser det ut for meg, vokser nå i en raskere hastighet enn nye DevOps dukker opp, og effektiviteten øker. Det er en spesifikk mangel i markedet akkurat nå, og den vil vare lenge. Senere vil alt gå tilbake til en slags normalitet, hvor effektiviteten av arbeidet vil øke, det vil bli mer og mer serverløst, en nevron vil bli knyttet til Kubernetes, som vil velge alle ressursene nøyaktig etter behov, og generelt vil gjør alt selv, som det skal - personen bare gå bort og ikke blande seg.
Men noen vil fortsatt måtte ta avgjørelser. Det er tydelig at kvalifikasjonsnivået og spesialiseringen til denne personen er høyere. I dag trenger man i regnskapsavdelingen ikke at 10 ansatte skal føre bøker for at hendene ikke skal bli slitne. Det er rett og slett ikke nødvendig. Mange dokumenter skannes automatisk og gjenkjennes av det elektroniske dokumenthåndteringssystemet. En smart regnskapssjef er nok, allerede med mye større kompetanse, med god forståelse.
Generelt er dette veien å gå i alle bransjer. Det er det samme med biler: tidligere kom en bil med en mekaniker og tre sjåfører. I dag er bilkjøring en enkel prosess der vi alle deltar hver dag. Ingen tror at en bil er noe komplisert.
DevOps eller systemutvikling vil ikke forsvinne - arbeid på høyt nivå og effektivitet vil øke.
— Jeg hørte også en interessant idé om at arbeidet faktisk vil øke.
Dmitry: Selvfølgelig, hundre prosent! Fordi mengden programvare vi skriver vokser stadig. Antallet problemer vi løser med programvare vokser stadig. Arbeidsmengden vokser. Nå er DevOps-markedet fryktelig overopphetet. Dette kan sees i lønnsforventninger. På en god måte, uten å gå i detaljer, bør det være juniorer som vil ha X, midterste som vil ha 1,5X, og seniorer som vil ha 2X. Og nå, hvis du ser på DevOps-lønnsmarkedet i Moskva, vil en junior ha fra X til 3X og en senior vil ha fra X til 3X.
Ingen vet hvor mye det koster. Lønnsnivået måles etter din selvtillit – et komplett galehus, for å være ærlig, et fryktelig overopphetet marked.
Selvfølgelig vil denne situasjonen endre seg veldig snart - en viss metning bør oppstå. Slik er det ikke med programvareutvikling – til tross for at alle trenger utviklere, og alle trenger gode utviklere, forstår markedet hvem som er verdt hva – har bransjen slått seg til ro. Det er ikke tilfelle med DevOps i disse dager.
— Fra det jeg hørte, konkluderte jeg med at den nåværende systemadministratoren ikke burde bekymre seg for mye, men det er på tide å oppgradere ferdighetene sine og forberede seg på at det i morgen blir mer arbeid, men det vil være mer kvalifisert.
Dmitry: Ett hundre prosent. Generelt lever vi i 2019 og leveregelen er denne: livstidslæring – vi lærer gjennom hele livet. Det virker for meg som nå alle vet og føler dette, men det er ikke nok å vite - du må gjøre det. Hver dag må vi forandre oss. Gjør vi ikke dette, så blir vi før eller siden droppet på sidelinjen av yrket.
Vær forberedt på skarpe 180-graders svinger. Jeg utelukker ikke en situasjon der noe endres radikalt, noe nytt blir oppfunnet - det skjer. Hopp! – og nå handler vi annerledes. Det er viktig å være forberedt på dette og ikke bekymre seg. Det kan skje at i morgen vil alt jeg gjør vise seg å være unødvendig - ingenting, jeg har studert hele livet og er klar for å lære noe annet. Det er ikke et problem. Det er ingen grunn til å være redd for jobbsikkerhet, men du må være forberedt på å hele tiden lære noe nytt.
Ønsker og et minutt med reklame
– Har du noe ønske?
Dmitry: Ja, jeg har flere ønsker.
Første og merkantile - abonner på . Kjære lesere, gå til YouTube og abonner på kanalen vår. Om omtrent en måned starter vi aktiv utvidelse av videotjenesten.Vi vil ha mye pedagogisk innhold om Kubernetes, åpent og variert: fra praktiske ting, helt ned til laboratorier, til dype fundamentale teoretiske ting og hvordan man bruker Kubernetes på nivå av prinsipper og mønstre.
Det andre merkantile ønsket - gå til og setter stjerner fordi vi lever av dem. Hvis du ikke gir oss stjerner, har vi ikke noe å spise. Det er som mana i et dataspill. Vi gjør noe, vi gjør, vi prøver, noen sier at dette er forferdelige sykler, noen at alt er helt feil, men vi fortsetter og handler helt ærlig. Vi ser et problem, løser det og deler vår erfaring. Derfor, gi oss en stjerne, den vil ikke gå bort fra deg, men den vil komme til oss, fordi vi lever av dem.
Tredje, viktig og ikke lenger merkantilt ønske - slutte å tro på eventyr. Dere er profesjonelle. DevOps er et veldig seriøst og ansvarlig yrke. Slutt å leke på arbeidsplassen. La det klikke for deg og du vil forstå det. Tenk deg at du kommer til sykehuset, og der eksperimenterer legen med deg. Jeg forstår at dette kan være støtende for noen, men mest sannsynlig handler dette ikke om deg, men om noen andre. Be andre om å slutte også. Dette ødelegger virkelig livet for oss alle - mange begynner å behandle operasjoner, admins og DevOps som karer som har ødelagt noe igjen. Dette ble "ødelagt" som oftest på grunn av at vi dro for å leke, og ikke så med en kald bevissthet på at det er sånn det er, og sånn er det.
Dette betyr ikke at du ikke bør eksperimentere. Vi må eksperimentere, vi gjør det selv. For å være ærlig spiller vi selv noen ganger spill - dette er selvfølgelig veldig dårlig, men ingenting menneskelig er fremmed for oss. La oss erklære 2019 som et år med seriøse, gjennomtenkte eksperimenter, og ikke spill på produksjon. Sannsynligvis det.
- Tusen takk!
Dmitry: Takk, Vitaly, både for tiden og for intervjuet. Kjære lesere, tusen takk hvis du plutselig har nådd dette punktet. Jeg håper at vi kom med deg i det minste et par tanker.
I intervjuet berørte Dmitry spørsmålet om werf. Nå er dette en universal sveitsisk kniv som løser nesten alle problemer. Men det var ikke alltid slik. På på festivalen Dmitry Stolyarov vil fortelle deg om dette verktøyet i detalj. i rapporten det vil være alt: problemer og skjulte nyanser av Kubernetes, alternativer for å løse disse vanskelighetene og den nåværende implementeringen av werf i detalj. Bli med oss 27. og 28. mai, vi lager de perfekte verktøyene.
Kilde: www.habr.com