I forventning Vitaly Khabarov interviewet Dmitry Stolyarov (), teknisk direktør og medstifter af virksomheden Flant. Vitaly spurgte Dmitry om, hvad Flant gør, om Kubernetes, økosystemudvikling, support. Vi diskuterede, hvorfor Kubernetes er nødvendig, og om det overhovedet er nødvendigt. Og også om mikrotjenester, Amazon AWS, "I'll be lucky"-tilgangen til DevOps, fremtiden for Kubernetes selv, hvorfor, hvornår og hvordan den vil overtage verden, udsigterne for DevOps og hvad ingeniører bør forberede sig på i lys og nær fremtid med forenkling og neurale netværk.
lyt som podcast på DevOps Deflop - en russisksproget podcast om DevOps, og herunder er tekstversionen.
Her og nedenfor stiller han spørgsmål ingeniør fra Express42.
Om "Flant"
- Hej Dima. Du er teknisk direktør""og også dens grundlægger. Fortæl os venligst, hvad virksomheden laver, og hvad du er i den?
Dmitry: Udefra ser det ud til, at vi er de fyre, der går rundt og installerer Kubernetes for alle og laver noget med det. Men det er ikke sandt. Vi startede som en virksomhed, der beskæftiger sig med Linux, men i meget lang tid har vores hovedaktivitet været at servicere produktion og højbelastningsnøglefærdige projekter. Normalt bygger vi hele infrastrukturen fra bunden og er så ansvarlige for den i lang, lang tid. Derfor er det vigtigste arbejde, "Flant" udfører, som den modtager penge for tage ansvar og gennemføre nøglefærdig produktion.
Jeg, som teknisk direktør og en af grundlæggerne af virksomheden, bruger hele dagen og natten på at finde ud af, hvordan man øger tilgængeligheden af produktionen, forenkler dens drift, gør livet for administratorer lettere og livet for udviklerne mere behageligt. .
Om Kubernetes
— På det seneste har jeg set mange rapporter fra Flant og om Kubernetes. Hvordan kom du til det?
Dmitry: Jeg har allerede talt om det her mange gange, men jeg gider slet ikke gentage det. Jeg synes, det er rigtigt at gentage dette emne, fordi der er 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 krykker og følte behov for et værktøj. Vi gennemgik mange forskellige muligheder, byggede vores egne cykler og fik erfaring. Efterhånden kom vi til det punkt, hvor vi begyndte at bruge Docker næsten lige så snart det dukkede op - omkring 2013. På tidspunktet for dets fremkomst havde vi allerede meget erfaring med containere, vi havde allerede skrevet en analog af "Docker" - nogle af vores egne krykker i Python. Med fremkomsten af Docker blev det muligt at smide krykkerne ud og bruge en pålidelig og community-understøttet løsning.
Med Kubernetes ligner historien. Da det begyndte at tage fart - for os er dette version 1.2 - havde vi allerede en masse krykker på både Shell og Chef, som vi på en eller anden måde forsøgte at orkestrere med Docker. Vi kiggede seriøst mod Rancher og forskellige andre løsninger, men så dukkede Kubernetes op, hvor alt er implementeret præcis, som vi ville have gjort det eller endnu bedre. Der er ikke noget at klage over.
Ja, der er en form for ufuldkommenhed her, der er en form for ufuldkommenhed der - der er mange ufuldkommenheder, og 1.2 er generelt forfærdeligt, men... Kubernetes er som en bygning under opførelse - du ser på projektet og forstår at det bliver fedt. Hvis bygningen nu har et fundament og to etager, så forstår du, at det er bedre ikke at flytte ind endnu, men der er ingen sådanne problemer med softwaren - du kan allerede bruge den.
Vi havde ikke et øjeblik, hvor vi tænkte på at bruge Kubernetes eller ej. Vi ventede på det længe før det dukkede op, og prøvede selv at skabe analoger.
Om Kubernetes
— Er du direkte involveret i udviklingen af selve Kubernetes?
Dmitry: Middelmådig. I stedet deltager vi i udviklingen af økosystemet. Vi sender et vist antal pull-anmodninger: til Prometheus, til forskellige operatører, til Helm - til økosystemet. Jeg er desværre ikke i stand til at holde styr på alt, hvad vi gør, og jeg kan tage fejl, men der er ikke en eneste pulje fra os ind i kernen.
— Udvikler du samtidig mange af dine værktøjer omkring Kubernetes?
Dmitry: Strategien er denne: vi går og trækker forespørgsler til alt, hvad der allerede eksisterer. Hvis pull-anmodninger ikke accepteres der, fordeler vi dem simpelthen selv og lever, indtil de accepteres med vores builds. Så, når den når opstrøms, går vi tilbage til opstrømsversionen.
For eksempel har vi en Prometheus-operatør, med hvilken vi skiftede frem og tilbage til opstrøms for vores samling sandsynligvis 5 gange allerede. Vi har brug for en form for funktion, vi sendte en pull-anmodning, vi skal rulle den ud i morgen, men vi ønsker ikke at vente på, at den bliver frigivet opstrøms. Derfor samler vi for os selv, ruller vores samling ud med vores funktion, som vi har brug for af en eller anden grund, til alle vores klynger. Så vender de det for eksempel til os i opstrøms med ordene: "Gunner, lad os gøre det for en mere generel sag", vi eller en anden afslutter den, og med tiden smelter den sammen igen.
Vi forsøger at udvikle alt, hvad der findes. Mange elementer, der endnu ikke eksisterer, endnu ikke er opfundet, eller er opfundet, men ikke har haft tid til at implementere – vi gør det. Og ikke fordi vi kan lide processen eller cykelbyggeriet som industri, men simpelthen fordi vi har brug for dette værktøj. Spørgsmålet bliver ofte stillet, hvorfor gjorde vi den eller den ting? Svaret er enkelt - ja, for vi skulle videre, løse et eller andet praktisk problem, og vi løste det med denne tula.
Vejen er altid sådan: Vi søger meget omhyggeligt, og hvis vi ikke finder nogen løsning på, hvordan man laver en trolleybus af et brød, så laver vi vores eget brød og vores egen trolleybus.
Flanta værktøjer
— Jeg ved, at Flant nu har addon-operatorer, shell-operatorer og dapp/werf-værktøjer. Som jeg forstår det, er dette det samme instrument i forskellige inkarnationer. Jeg forstår også, at der er mange flere forskellige værktøjer inden for Flaunt. Det er rigtigt?
Dmitry: Vi har meget mere på GitHub. Fra hvad jeg husker nu, har vi et statuskort – et panel for Grafana, som alle er stødt på. Det er nævnt i næsten hver anden artikel om Kubernetes-overvågning på Medium. Det er umuligt kort at forklare, hvad et statuskort er - det har brug for en separat artikel, men det er en meget nyttig ting til at overvåge status over tid, da vi i Kubernetes ofte skal vise status over tid. Vi har også LogHouse - dette er en ting baseret på ClickHouse og sort magi til indsamling af logs i Kubernetes.
Masser af hjælpemidler! Og der kommer endnu flere, for i år udkommer en række interne løsninger. Af de meget store, der er baseret på addon-operatøren, er der en masse tilføjelser til Kubernetes, ala hvordan man korrekt installerer sert manager - et værktøj til at administrere certifikater, hvordan man korrekt installerer Prometheus med en masse tilbehør - disse er omkring tyve forskellige binære filer, der eksporterer data og indsamler noget, til dette har Prometheus den mest fantastiske grafik og advarsler. Alt dette er blot en flok tilføjelser til Kubernetes, som er installeret i en klynge, og det bliver fra simpelt til cool, sofistikeret, automatisk, hvor mange problemer allerede er løst. Ja, vi gør meget.
Økosystemudvikling
"Det forekommer mig, at dette er et meget stort bidrag til udviklingen af dette instrument og dets brugsmetoder." Kan du groft vurdere, hvem der ellers ville yde det samme bidrag til udviklingen af økosystemet?
Dmitry: I Rusland, af de virksomheder, der opererer på vores marked, er ingen engang tæt på. Det er selvfølgelig et højt udsagn, for der er store aktører som Mail og Yandex – de laver også noget med Kubernetes, men selv kommer de ikke i nærheden af bidraget fra virksomheder i hele verden, der gør meget mere end os. Det er svært at sammenligne Flant, som har en stab på 80 personer, og Red Hat, som har 300 ingeniører pr. Kubernetes alene, hvis jeg ikke tager fejl. Det er svært at sammenligne. Vi har 6 personer i RnD afdelingen, inklusive mig, som skærer alt vores værktøj. 6 personer mod 300 Red Hat-ingeniører - det er på en eller anden måde svært at sammenligne.
- Men når selv disse 6 mennesker kan gøre noget virkelig nyttigt og fremmedgørende, når de står med et praktisk problem og giver løsningen til fællesskabet - en interessant sag. Jeg forstår, at i store teknologivirksomheder, hvor de har deres eget Kubernetes udviklings- og supportteam, kan de samme værktøjer i princippet udvikles. Dette er et eksempel for dem på, hvad der kan udvikles og gives til samfundet, hvilket giver impulser til hele det samfund, der bruger Kubernetes.
Dmitry: Dette er sandsynligvis et træk ved integratoren, dens ejendommelighed. Vi har mange projekter, og vi ser mange forskellige situationer. For os er den vigtigste måde at skabe merværdi på at analysere disse sager, finde fællestræk og gøre dem så billige som muligt for os. Det arbejder vi aktivt på. Det er svært for mig at tale om Rusland og verden, men vi har omkring 40 DevOps-ingeniører i virksomheden, som arbejder på Kubernetes. Jeg tror ikke, der er mange virksomheder i Rusland med et sammenligneligt antal specialister, der forstår Kubernetes, hvis nogen overhovedet.
Jeg forstår alt om jobtitlen DevOps-ingeniør, alle forstår alt og er vant til at kalde DevOps-ingeniører for DevOps-ingeniører, det vil vi ikke diskutere. Alle disse 40 fantastiske DevOps-ingeniører står over for og løser problemer hver dag, vi analyserer bare denne oplevelse og forsøger at generalisere. Vi forstår, at hvis det forbliver inde i os, så vil værktøjet være ubrugeligt om et år eller to, for et sted i samfundet vil en færdiglavet Tula dukke op. Det nytter ikke at akkumulere denne erfaring internt – det dræner simpelthen energi og tid til dev/null. Og vi har slet ikke ondt af det. Vi udgiver alt med stor fornøjelse og forstår, at det skal udgives, udvikles, promoveres, promoveres, så folk bruger det og tilføjer deres erfaring – så vokser alt og lever. Så efter to år går instrumentet ikke i skraldespanden. Det er ikke ærgerligt at fortsætte med at hælde kræfter ind, for det er tydeligt, at nogen bruger dit værktøj, og efter 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 lave den, det ser ud til at være 3 år siden. I starten var det generelt på skallen. Det var et super proof of concept, vi løste nogle af vores særlige problemer – det virkede! Men der er problemer med skallen, det er umuligt at udvide den yderligere, programmering på skallen er en anden opgave. Vi havde en vane med at skrive i Ruby, derfor lavede vi noget om i Ruby, udviklede, udviklede, udviklede og løb ind i det faktum, at samfundet, mængden, der ikke siger "vi vil have det eller vi vil ikke have det, ” vender næsen op ad Ruby, hvor sjovt er det? Vi indså, at vi skulle skrive alle disse ting i Go bare for at opfylde det første punkt på tjeklisten: DevOps-værktøjet skal være et statisk binært. At være Go eller ej er ikke så vigtigt, men en statisk binær skrevet i Go er bedre.
Vi brugte vores energi, omskrev dappen i Go og kaldte den werf. Dapp er ikke længere understøttet, ikke udviklet, kører i en eller anden seneste version, men der er en absolut opgraderingssti til toppen, og du kan følge den.
Hvorfor blev dappen oprettet?
— Kan du kort fortælle os, hvorfor dappen blev oprettet, hvilke problemer den løser?
Dmitry: Den første årsag er i forsamlingen. I starten havde vi alvorlige problemer med opbygningen, da Docker ikke havde multi-stage-kapacitet, så vi lavede multi-stage på egen hånd. Så havde vi en masse flere problemer med at rense billedet. Alle, der laver CI/CD, står før snarere end siden med det problem, at der er en masse indsamlede billeder, man skal på en eller anden måde rydde ud i det, der ikke er nødvendigt, og efterlade det, der er nødvendigt.
Den anden grund er udrulning. Ja, der er Helm, men det løser kun nogle af problemerne. Sjovt nok er det skrevet, at "Helm er pakkeadministratoren for Kubernetes." Præcis hvad "den". Der er også ordene "Package Manager" - hvad er den sædvanlige forventning fra en Package Manager? Vi siger: "Package Manager - installer pakken!" og vi forventer, at han fortæller os: "Pakken er blevet leveret."
Det er interessant, at vi siger: "Hjælp, installer pakken," og da han svarer, at han installerede den, viser det sig, at han lige har startet installationen - han indikerede Kubernetes: "Start denne ting!", og om den startede eller ej , uanset om det virker eller ej, løser Helm overhovedet ikke dette problem.
Det viser sig, at Helm blot er en tekstforbehandler, der indlæser data i Kubernetes.
Men som en del af enhver implementering vil vi gerne vide, om applikationen er blevet frigivet til produktion eller ej? Udrullet til prod betyder, at applikationen er flyttet dertil, den nye version er blevet implementeret, og i det mindste går den ikke ned der og reagerer korrekt. Helm løser ikke dette problem på nogen måde. For at løse det skal du bruge en masse kræfter, fordi du skal give Kubernetes kommandoen til at rulle ud og overvåge, hvad der sker der - uanset om det blev implementeret eller rullet ud. Og der er også en masse opgaver relateret til udrulning, rengøring og montering.
Planer
I år starter vi lokal udvikling. Vi ønsker at opnå, hvad der tidligere var i Vagrant - vi skrev "vagrant up", og vi implementerede virtuelle maskiner. Vi ønsker at komme til det punkt, hvor der er et projekt i Git, vi skriver "werf deroppe", og det bringer en lokal kopi af dette projekt op, implementeret i en lokal mini-Kub, med alle de mapper, der er praktiske til udvikling forbundet . Afhængigt af udviklingssproget gøres dette forskelligt, men ikke desto mindre, så lokal udvikling bekvemt kan udføres under monterede filer.
Det næste skridt for os er investere i bekvemmelighed for udviklere. For hurtigt at implementere et projekt lokalt med ét værktøj, skal du udvikle det, skubbe det ind i Git, og det vil også rulle ud til etape eller test, afhængigt af pipelines, og derefter bruge det samme værktøj til at gå til produktion. Denne enhed, forening, reproducerbarhed af infrastruktur fra det lokale miljø til salg er et meget vigtigt punkt for os. Men det er ikke i werf endnu - vi planlægger bare 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 løsninger - vi fandt på nogle løsninger til os selv på skallen, på hvad som helst. Så forsøgte de på en eller anden måde at rette op på disse løsninger, generalisere og konsolidere dem til binære filer i dette tilfælde, som vi simpelthen deler.
Der er en anden måde at se på hele denne historie, med analogier.
Kubernetes er et bilstel med motor. Der er ingen døre, glas, radio, juletræ - slet ingenting. Kun rammen og motoren. Og der er Helm - dette er rattet. Fedt - der er et rat, men du har også brug for en ratpind, styrestang, gearkasse og hjul, og du kan ikke undvære dem.
I tilfælde af werf er dette en anden komponent til Kubernetes. Først nu i alfaversionen af werf, for eksempel, er Helm kompileret inde i werf, fordi vi er trætte af at gøre det selv. Der er mange grunde til at gøre dette, jeg vil fortælle dig i detaljer om, hvorfor vi kompilerede hele roret sammen med rorpind inde i werf .
Nu er werf en mere integreret komponent. Vi får et færdigt rat, en ratpind - jeg er ikke særlig god til biler, men dette er en stor blok, der allerede løser en ret bred vifte af problemer. Vi behøver ikke selv at gennemgå kataloget, vælge en del til en anden, tænke over, hvordan vi skruer dem sammen. Vi får en færdigsyet mejetærsker, der løser en lang række problemer på én gang. Men indeni er den bygget af de samme open source-komponenter, den bruger stadig Docker til montering, Helm til noget af funktionaliteten, og der er flere andre biblioteker. Dette er et integreret værktøj til at få sej CI/CD ud af æsken hurtigt og bekvemt.
Er Kubernetes svære at vedligeholde?
— Du taler om oplevelsen af, at du begyndte at bruge Kubernetes, det her er et stel til dig, en motor, og at du kan hænge mange forskellige ting på den: en krop, et rat, skrue på pedaler, sæder. Spørgsmålet opstår - hvor svært er Kubernetes-support for dig? Du har meget erfaring, hvor meget tid og ressourcer bruger du på at understøtte Kubernetes isoleret fra alt muligt andet?
Dmitry: Dette er et meget vanskeligt spørgsmål, og for at besvare, er vi nødt til at forstå, hvad support er, og hvad vi ønsker fra Kubernetes. Måske du kan afsløre?
- Så vidt jeg ved, og som jeg ser, vil mange hold nu prøve Kubernetes. Alle spænder sig til det, lægger det på knæ. Jeg har en fornemmelse af, at folk ikke altid forstår kompleksiteten i dette system.
Dmitry: Sådan er det.
— Hvor svært er det at tage og installere Kubernetes fra bunden, så den er produktionsklar?
Dmitry: Hvor svært tror du, det er at transplantere et hjerte? Jeg forstår, at dette er et kompromitterende spørgsmål. At bruge en skalpel og ikke lave en fejl er ikke så svært. Hvis de fortæller dig, hvor du skal klippe og hvor du skal sy, så er selve proceduren ikke kompliceret. Det er svært at garantere gang på gang, at det hele lykkes.
Det er nemt at installere Kubernetes og få det til at fungere: chick! — installeret, er der mange installationsmetoder. Men hvad sker der, når der opstår problemer?
Spørgsmål opstår altid – hvad har vi ikke taget højde for endnu? Hvad har vi ikke gjort endnu? Hvilke Linux-kerneparametre blev angivet forkert? Herre, nævnte vi dem overhovedet?! Hvilke Kubernetes-komponenter har vi leveret, og hvilke har vi ikke? Der opstår tusindvis af spørgsmål, og for at besvare dem skal du bruge 15-20 år i denne branche.
Jeg har et nyligt eksempel om dette emne, der kan afsløre betydningen af problemet "Er Kubernetes svært at vedligeholde?" For noget tid siden overvejede vi seriøst, om vi skulle forsøge at implementere Cilium som et netværk i Kubernetes.
Lad mig forklare, hvad Cilium er. Kubernetes har mange forskellige implementeringer af netværksundersystemet, og en af dem er meget cool - Cilium. Hvad er dens betydning? I kernen blev det for noget tid siden muligt at skrive hooks til kernen, som på den ene eller anden måde invaderer netværksundersystemet og diverse andre undersystemer, og giver dig mulighed for at omgå store bidder i kernen.
Linux-kernen har historisk set en ip-rute, et overfilter, broer og mange forskellige gamle komponenter, der er 15, 20, 30 år gamle. Generelt fungerer de, alt er fantastisk, men nu har de stablet containere op, og det ligner et tårn af 15 klodser oven på hinanden, og man står på det på et ben – en mærkelig følelse. Dette system har historisk udviklet sig med mange nuancer, såsom blindtarmen i kroppen. I nogle situationer er der f.eks. præstationsproblemer.
Der er en vidunderlig BPF og evnen til at skrive kroge til kernen - fyrene skrev deres egne kroge til kernen. Pakken kommer ind i Linux-kernen, de tager den ud lige ved indgangen, behandler den selv som den skal uden broer, uden TCP, uden en IP-stak - kort sagt omgå alt, hvad der er skrevet i Linux-kernen, og spytter så det ud i beholderen.
Hvad skete der? Meget fed ydeevne, fede funktioner - bare cool! Men vi ser på dette og ser, at der på hver maskine er et program, der forbinder til Kubernetes API og, baseret på de data, det modtager fra denne API, genererer C-kode og kompilerer binære filer, som det indlæser i kernen, så disse hooks fungerer i kernerummet.
Hvad sker der, hvis noget går galt? Vi ved det ikke. For at forstå dette skal du læse al denne kode, forstå al logikken, og det er utroligt, hvor svært det er. Men på den anden side er der disse broer, netfiltre, ip rout - jeg har ikke læst deres kildekode, og det har de 40 ingeniører, der arbejder i vores virksomhed heller ikke. Måske er det kun få, der forstår nogle dele.
Og hvad er forskellen? Det viser sig, at der er ip-rout, Linux-kernen, og der er et nyt værktøj - hvilken forskel gør det, vi forstår ikke det ene eller det andet. Men vi er bange for at bruge noget nyt – hvorfor? For hvis værktøjet er 30 år gammelt, så er alle fejlene fundet om 30 år, alle fejlene er blevet trådt på, og du behøver ikke vide om alt - det fungerer som en sort boks og virker altid. Alle ved hvilken diagnostisk skruetrækker der skal stikkes på hvilket sted, hvilken tcpdump der skal køre i hvilket øjeblik. Alle kender diagnostiske hjælpeprogrammer godt og forstår, hvordan dette sæt komponenter fungerer i Linux-kernen - ikke hvordan det fungerer, men hvordan man bruger det.
Og den fantastisk seje Cilium er ikke 30 år gammel, den er ikke ældet endnu. Kubernetes har det samme problem, kopi. At Cilium er installeret perfekt, at Kubernetes er installeret perfekt, men når noget går galt i produktionen, er man så hurtigt i stand til i en kritisk situation at forstå, hvad der gik galt?
Når vi siger, er det svært at vedligeholde Kubernetes - nej, det er meget nemt, og ja, det er utroligt svært. Kubernetes fungerer fremragende alene, men med en milliard nuancer.
Om "I'll be lucky"-tilgangen
— Er der virksomheder, hvor disse nuancer næsten med garanti vil dukke op? Antag, at Yandex pludselig overfører alle tjenester til Kubernetes, vil der være en enorm belastning der.
Dmitry: Nej, det er ikke en samtale om belastningen, men om de simpleste ting. For eksempel har vi Kubernetes, vi implementerede applikationen der. Hvordan ved du, at det virker? Der er simpelthen ikke noget færdigt værktøj til at forstå, at applikationen ikke går ned. Der er ikke noget færdigt system, der sender advarsler; du skal konfigurere disse advarsler og hver tidsplan. Og vi opdaterer Kubernetes.
Jeg har Ubuntu 16.04. Man kan sige, at dette er en gammel version, men vi er stadig på den, fordi det er LTS. Der er systemd, hvis nuance er, at det ikke rydder op i C-grupper. Kubernetes lancerer pods, opretter C-grupper, sletter derefter pods, og på en eller anden måde viser det sig - jeg kan ikke huske detaljerne, undskyld - at systemd-slices forbliver. Dette fører til det faktum, at enhver bil med tiden begynder at bremse kraftigt. Dette er ikke engang et spørgsmål om højbelastning. Hvis der lanceres permanente pods, hvis der for eksempel er et Cron Job, der konstant genererer pods, så vil maskinen med Ubuntu 16.04 begynde at sænke farten efter en uge. Der vil være et konstant højt belastningsgennemsnit på grund af, at der er oprettet en flok C-grupper. Dette er problemet, som enhver person, der blot installerer Ubuntu 16 og Kubernetes ovenpå, vil stå 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 du sletter C-grupper, lækker de i kernen og bliver faktisk ikke slettet. Derfor vil det efter en måneds arbejde på denne maskine være umuligt at se på hukommelsesstatistikken for ildstederne. Vi tager en fil ud, ruller den i programmet, og en fil ruller i 15 sekunder, fordi kernen tager meget lang tid at tælle en million C-grupper i sig selv, som ser ud til at være slettet, men nej - de lækker .
Der er stadig mange sådanne småting hist og her. Det er ikke et problem, som gigantiske virksomheder nogle gange kan stå over for under meget tunge belastninger – nej, det er et spørgsmål om hverdagsting. Folk kan leve sådan i månedsvis - de installerede Kubernetes, implementerede applikationen - det ser ud til at virke. For mange mennesker er dette normalt. De ved ikke engang, at denne applikation vil gå ned af en eller anden grund, de vil ikke modtage en advarsel, men for dem er dette normen. Tidligere levede vi på virtuelle maskiner uden overvågning, nu flyttede vi til Kubernetes, også uden overvågning – hvad er forskellen?
Spørgsmålet er, at når vi går på is, kender vi aldrig dens tykkelse, medmindre vi måler den på forhånd. Mange mennesker går og bekymrer sig ikke, for de har gået før.
Fra mit synspunkt er nuancen og kompleksiteten ved at betjene ethvert system at sikre, at tykkelsen af isen er nøjagtig nok til at løse vores problemer. Det er hvad vi taler om.
Inden for IT, forekommer det mig, er der for mange "I'll be lucky"-tilgange. Mange mennesker installerer software og bruger softwarebiblioteker i håbet om, at de vil være heldige. Generelt er mange mennesker heldige. Det er nok derfor det virker.
— Ud fra min pessimistiske vurdering ser det sådan ud: når risikoen er høj, og applikationen skal virke, så er der brug for support fra Flaunt, måske fra Red Hat, eller du har brug for dit eget interne team dedikeret specifikt til Kubernetes, som er klar at trække det af.
Dmitry: Objektivt set er det sådan. At komme ind i Kubernetes-historien for et lille team på egen hånd involverer en række risici.
Har vi brug for containere?
— Kan du fortælle os, hvor udbredt Kubernetes er i Rusland?
Dmitry: Jeg har ikke disse data, og jeg er ikke sikker på, at nogen andre har dem. Vi siger: "Kubernetes, Kubernetes," men der er en anden måde at se på dette problem. Jeg ved heller ikke, hvor udbredte containere er, men jeg kender et tal fra rapporter på internettet om, at 70% af containerne er orkestreret af Kubernetes. Det var en pålidelig kilde til en ret stor prøve rundt om i verden.
Så endnu et spørgsmål - skal vi have containere? Min personlige følelse og Flant-virksomhedens overordnede holdning er, at Kubernetes er en de facto standard.
Der vil ikke være andet end Kubernetes.
Dette er en absolut game-changer inden for infrastrukturstyring. Bare absolut - det er det, ikke mere Ansible, Chef, virtuelle maskiner, Terraform. Jeg taler ikke om de gamle kollektive landbrugsmetoder. Kubernetes er en absolut forandring, og nu bliver det kun sådan.
Det er klart, at det for nogle tager et par år, og for andre et par årtier, at indse dette. Jeg er ikke i tvivl om, at der ikke vil være andet end Kubernetes og dette nye udseende: vi beskadiger ikke længere operativsystemet, men bruger infrastruktur som kode, kun ikke med kode, men med yml - en deklarativt beskrevet infrastruktur. Jeg har en fornemmelse af, at det altid vil være sådan.
— Det vil sige, at de virksomheder, der endnu ikke er skiftet til Kubernetes, helt sikkert vil skifte til det eller forblive i glemmebogen. Jeg har forstået dig rigtigt?
Dmitry: Dette er heller ikke helt rigtigt. Hvis vi for eksempel har til opgave at køre en DNS-server, så kan den køres på FreeBSD 4.10 og den kan fungere perfekt i 20 år. Bare arbejde og det er det. Måske om 20 år skal noget opdateres én gang. Hvis vi taler om software i det format, vi lancerede, og det faktisk fungerer i mange år uden nogen opdateringer, uden at lave ændringer, så vil der selvfølgelig ikke være nogen Kubernetes. Han er ikke nødvendig der.
Alt relateret til CI/CD - hvor der er behov for Kontinuerlig levering, hvor du skal opdatere versioner, foretage aktive ændringer, hvor end du skal opbygge fejltolerance - kun Kubernetes.
Om mikrotjenester
- Her har jeg en lille dissonans. For at arbejde med Kubernetes har du brug for ekstern eller intern support - dette er det første punkt. For det andet, når vi lige er i gang med udvikling, er vi en lille startup, vi har ikke noget endnu, udvikling til Kubernetes eller mikroservicearkitektur generelt kan være kompleks og ikke altid økonomisk berettiget. Jeg er interesseret i din mening - skal startups straks begynde at skrive til Kubernetes fra bunden, eller kan de stadig skrive en monolit og så kun komme til Kubernetes?
Dmitry: Fedt spørgsmål. Jeg har en snak om mikrotjenester Mange gange har jeg stødt på folk, der forsøgte at slå søm med et mikroskop. Selve tilgangen er korrekt, vi designer selv vores interne software på denne måde. Men når du gør dette, skal du klart forstå, hvad du gør. Det ord, jeg hader mest ved mikrotjenester, er "mikro". Historisk set opstod dette ord der, og af en eller anden grund tror folk, at mikro er meget lille, mindre end en millimeter, ligesom en mikrometer. Det er forkert.
For eksempel er der en monolit, der er skrevet af 300 personer, og alle, der har deltaget i udviklingen, forstår, at der er problemer der, og den bør brydes op i mikrostykker - cirka 10 stykker, som hver er skrevet af 30 personer. i en minimumsversion. Dette er vigtigt, nødvendigt og fedt. Men når en startup kommer til os, hvor 3 meget seje og talentfulde fyre skrev 60 mikrotjenester på deres knæ, hver gang jeg leder efter Corvalol.
Det forekommer mig, at dette allerede er blevet talt om tusindvis af gange - vi fik en distribueret monolit i en eller anden form. Dette er ikke økonomisk begrundet, det er meget svært generelt i alt. Jeg har lige set det her så mange gange, at det gør virkelig ondt på mig, så jeg fortsætter med at tale om det.
Til det indledende spørgsmål er der en konflikt mellem det faktum, at Kubernetes på den ene side er skræmmende at bruge, fordi det ikke er klart, hvad der kan gå i stykker der eller ikke virker, på den anden side er det klart, at alt går der og intet andet end Kubernetes vil eksistere. Svar - afvej mængden af fordel, der kommer, mængden af opgaver, du kan løse. Dette er på den ene side af skalaen. På den anden side er der risici forbundet med nedetid eller med et fald i responstid, niveau af tilgængelighed - med et fald i præstationsindikatorer.
Her er det - enten bevæger vi os hurtigt, og Kubernetes giver os mulighed for at gøre mange ting meget hurtigere og bedre, eller også bruger vi pålidelige, tidstestede løsninger, men bevæger os meget langsommere. Dette er et valg, som enhver virksomhed skal træffe. Du kan tænke på det som en sti i junglen - når du går første gang, kan du møde en slange, en tiger eller en gal grævling, og når du har gået 10 gange, har du trådt stien, fjernet grenene og gå lettere. Hver gang bliver stien bredere. Så er det en asfaltvej, og senere en smuk boulevard.
Kubernetes står ikke stille. Spørgsmål igen: Kubernetes er på den ene side 4-5 binære filer, på den anden side er det hele økosystemet. Dette er det operativsystem, vi har på vores maskiner. Hvad er dette? Ubuntu eller Curios? Dette er Linux-kernen, en masse ekstra komponenter. Alle disse ting her, en giftig slange blev smidt ud af vejen, et hegn blev rejst der. Kubernetes udvikler sig meget hurtigt og dynamisk, og mængden af risici, mængden af det ukendte falder hver måned, og følgelig genbalancerer disse skalaer.
Ved at besvare spørgsmålet om, hvad en startup skal gøre, vil jeg sige - kom til Flaunt, betal 150 tusind rubler og få en nøglefærdig DevOps nem service. Hvis du er en lille startup med et par udviklere, fungerer dette. I stedet for at ansætte dine egne DevOps, som skal lære at løse dine problemer og betale løn på dette tidspunkt, får du en nøglefærdig løsning på alle problemer. Ja, der er nogle ulemper. Vi som outsourcer kan ikke være så involveret og reagere hurtigt på ændringer. Men vi har en masse ekspertise og færdige praksisser. Vi garanterer, at vi i enhver situation helt sikkert hurtigt vil finde ud af det og rejse eventuelle Kubernetes fra de døde.
Jeg anbefaler på det kraftigste at outsource til startups og etablerede virksomheder op til en størrelse, hvor man kan dedikere et team på 10 personer til driften, for ellers er der ingen mening. Det giver helt klart mening at outsource dette.
Om Amazon og Google
— Kan en vært fra en løsning fra Amazon eller Google betragtes som en outsource?
Dmitry: Ja, selvfølgelig, dette løser en række problemer. Men igen er der nuancer. Du skal stadig forstå, hvordan du bruger det. For eksempel er der tusinde små ting i Amazon AWS' arbejde: Load Balancer skal varmes op, eller der skal skrives en anmodning på forhånd om, at "fyre, vi modtager trafik, varm Load Balancer op for os!" Du skal kende disse nuancer.
Når man henvender sig til folk, der har specialiseret sig i dette, får man næsten alle de typiske ting lukket. Vi har nu 40 ingeniører, ved årets udgang vil der formentlig være 60 - vi er helt sikkert stødt på alle disse ting. Selvom vi støder på dette problem igen på et eller andet projekt, spørger vi hurtigt hinanden og ved, hvordan vi skal løse det.
Sandsynligvis er svaret - selvfølgelig gør en hostet historie en del lettere. Spørgsmålet er, om du er klar til at stole på disse hostere, og om de vil løse dine problemer. Amazon og Google har gjort det godt. Til alle vores sager - præcis. Vi har ikke flere positive oplevelser. Alle de andre skyer, som vi forsøgte at arbejde med, skaber en masse problemer - Ager, og alt hvad der er i Rusland, og alle former for OpenStack i forskellige implementeringer: Headster, Overage - hvad end du vil. De skaber alle problemer, som du ikke ønsker at løse.
Derfor er svaret ja, men faktisk er der ikke ret mange modne hostede løsninger.
Hvem har brug for Kubernetes?
— Og dog, hvem har brug for Kubernetes? Hvem skal allerede skifte til Kubernetes, hvem er den typiske Flaunt-klient, der kommer specifikt til Kubernetes?
Dmitry: Dette er et interessant spørgsmål, for lige nu, i kølvandet på Kubernetes, kommer mange mennesker til os: "Gunner, vi ved, at I laver Kubernetes, gør det for os!" Vi svarer dem: "Mine herrer, vi laver ikke Kubernetes, vi laver prod og alt, hvad der er forbundet med det." For det er i øjeblikket simpelthen umuligt at lave et produkt uden at lave hele CI/CD'en og hele denne historie. Alle har bevæget sig væk fra den opdeling, at vi har udvikling for udvikling, og så udnyttelse ved udnyttelse.
Vores kunder forventer forskellige ting, men alle venter på et godt mirakel, at de har visse problemer, og nu - hop! — Kubernetes vil løse dem. Folk tror på mirakler. I deres sind forstår de, at der ikke vil ske noget mirakel, men i deres sjæle håber de - hvad nu hvis denne Kubernetes nu vil løse alt for os, de taler så meget om det! Pludselig er han nu - nys! - og en sølvkugle, nys! - og vi har 100 % oppetid, alle udviklere kan frigive, hvad der kommer i produktion 50 gange, og det går ikke ned. Generelt et mirakel!
Når sådanne mennesker kommer til os, siger vi: "Undskyld, men der er ikke noget, der hedder et mirakel." For at være sund skal du spise godt og træne. For at have et pålideligt produkt skal det være fremstillet pålideligt. For at have en praktisk CI/CD skal du lave den sådan her. Det er meget arbejde, der skal gøres.
At besvare spørgsmålet om, hvem der har brug for Kubernetes - ingen har brug for Kubernetes.
Nogle mennesker har den misforståelse, at de har brug for Kubernetes. Folk har brug for, de har et dybt behov for at stoppe med at tænke, studere og være interesseret i alle problemerne med infrastruktur og problemerne med at køre deres applikationer. De vil have, at applikationer bare fungerer og bare implementeres. For dem er Kubernetes håbet om, at de holder op med at høre historien om, at "vi lå der", eller "vi kan ikke rulle ud", eller noget andet.
Den tekniske direktør kommer normalt til os. De spørger ham om to ting: Giv os på den ene side træk, på den anden side stabilitet. Vi foreslår, at du tager det på dig selv og gør det. Sølvkuglen, eller rettere forsølvet, er, at du holder op med at tænke på disse problemer og spilde tid. Du vil have særlige folk, der vil lukke dette spørgsmål.
Formuleringen om, at vi eller nogen anden har brug for Kubernetes, er forkert.
Admins har virkelig brug for Kubernetes, for det er et meget interessant legetøj, som du kan lege med og pille ved. Lad os være ærlige – alle elsker legetøj. Vi er alle børn et eller andet sted, og når vi ser en ny, vil vi gerne lege den. For nogle er dette blevet frarådet, for eksempel i administrationen, fordi de allerede har spillet nok og allerede er trætte til det punkt, at de simpelthen ikke vil. Men dette er ikke helt tabt for nogen. Hvis jeg for eksempel har været træt af legetøj inden for systemadministration og DevOps i lang tid, så elsker jeg stadig legetøjet, jeg køber stadig noget nyt. Alle mennesker, på den ene eller anden måde, vil stadig have en slags legetøj.
Ingen grund til at lege med produktionen. Uanset hvad jeg kategorisk anbefaler ikke at gøre, og hvad jeg ser nu i massevis: "Åh, et nyt legetøj!" - de løb for at købe det, købte det og: "Lad os tage det i skole nu og vise det til alle vores venner." Gør ikke dette. Jeg undskylder, mine børn vokser bare op, jeg ser hele tiden noget hos børn, lægger mærke til det i mig selv og generaliserer det så til andre.
Det endelige svar er: du behøver ikke Kubernetes. Du skal løse dine problemer.
Det du kan opnå er:
- prod falder ikke;
- selv om han forsøger at falde, ved vi det i forvejen, og vi kan lægge noget i det;
- vi kan ændre det med den hastighed, hvormed vores virksomhed kræver det, og vi kan gøre det bekvemt; det giver os ingen problemer.
Der er to reelle behov: pålidelighed og dynamik/fleksibilitet ved udrulning. Alle, der i øjeblikket laver en eller anden form for it-projekter, uanset hvilken slags virksomhed - blød for at lette verden, og som forstår dette, skal løse disse behov. Kubernetes med den rigtige tilgang, med den rette forståelse og med nok erfaring giver dig mulighed for at løse dem.
Om serverløs
— Hvis man ser lidt længere ud i fremtiden, så prøver man at løse problemet med fraværet af hovedpine med infrastruktur, med hastigheden af udrulning og hastigheden af applikationsændringer, dukker nye løsninger op, for eksempel serverløse. Føler du noget potentiale i denne retning og, lad os sige, en fare for Kubernetes og lignende løsninger?
Dmitry: Her skal vi igen komme med en bemærkning om, at jeg ikke er en seer, der ser fremad og siger – sådan bliver det! Selvom jeg lige gjorde det samme. Jeg kigger på mine fødder og ser en masse problemer der, for eksempel hvordan transistorer fungerer i en computer. Det er sjovt, ikke? Vi støder på nogle fejl i CPU'en.
Gør serverløs ret pålidelig, billig, effektiv og bekvem, og løs alle økosystemproblemer. Her er jeg enig med Elon Musk i, at en anden planet er nødvendig for at skabe fejltolerance for menneskeheden. Selvom jeg ikke ved, hvad han siger, forstår jeg, at jeg ikke er klar til at flyve til Mars selv, og det vil ikke ske i morgen.
Med serverless er det klart, at dette er en ideologisk korrekt ting, som f.eks. fejltolerance for menneskeheden - at have to planeter er bedre end én. Men hvordan gør man det nu? At sende én ekspedition er ikke et problem, hvis du koncentrerer din indsats om det. At sende flere ekspeditioner og bosætte flere tusinde mennesker der, tror jeg også er realistisk. Men at gøre det fuldstændigt fejltolerant, så halvdelen af menneskeheden bor der, forekommer det mig nu umuligt, ikke taget i betragtning.
Med serverløs én mod én: sagen er cool, men den er langt fra problemerne i 2019. Tættere på 2030 - lad os leve for at se det. Jeg er ikke i tvivl om, at vi vil leve, vi vil helt sikkert leve (gentag inden vi går i seng), men nu skal vi løse andre problemer. Det er som at tro på eventyrponyen Rainbow. Ja, et par procent af sagerne bliver løst, og de løses perfekt, men subjektivt er serverløs en regnbue... For mig er dette emne for fjernt og for uforståeligt. Jeg er ikke klar til at tale. I 2019 kan du ikke skrive en enkelt applikation med serverløs.
Hvordan Kubernetes vil udvikle sig
— Når vi bevæger os mod denne potentielt vidunderlige fjerne fremtid, hvordan tror du, at Kubernetes og økosystemet omkring det vil udvikle sig?
Dmitry: Jeg har tænkt meget over dette, og jeg har et klart svar. Den første er statefull - trods alt er statsløs lettere at gøre. Kubernetes investerede oprindeligt mere i dette, det hele begyndte med det. Stateless fungerer næsten perfekt i Kubernetes, der er bare ikke noget at klage over. Der er stadig mange problemer, eller rettere sagt, nuancer. Alt der fungerer allerede godt for os, men det er os. Det vil tage mindst et par år mere, før dette virker for alle. Dette er ikke en beregnet indikator, men min følelse fra mit hoved.
Kort sagt, statefull bør - og vil - udvikle sig meget stærkt, fordi alle vores applikationer gemmer status; der er ingen statsløse applikationer. Dette er en illusion; du har altid brug for en form for database og noget andet. Statefull handler om at rette op på alt, hvad der er muligt, rette alle fejlene, forbedre alle de problemer, der lige nu står over for – 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 betydeligt. Dette er en vigtig historie. Og operatører - alt relateret til kodificering af administrationslogik, kontrollogik for at få en nem service: MySQL nem service, RabbitMQ nem service, Memcache nem service - generelt alle disse komponenter, som vi skal garanteres at fungere ud af kassen. Dette løser bare den smerte, at vi vil have en database, men vi ønsker ikke at administrere den, eller vi vil have Kubernetes, men vi ønsker ikke at administrere den.
Denne historie om operatørudvikling i en eller anden form bliver vigtig i de næste par år.
Jeg tror, at brugervenligheden skal stige meget – kassen bliver mere og mere sort, mere og mere driftsikker, med flere og flere simple knopper.
Jeg lyttede engang til et gammelt interview med Isaac Asimov fra 80'erne på YouTube på Saturday Night Live - et program som Urgant, kun interessant. De spurgte ham om fremtiden for computere. Han sagde, at fremtiden er i enkelhed, ligesom radioen. Radiomodtageren var oprindeligt en kompleks ting. For at fange en bølge skulle du dreje knapperne i 15 minutter, dreje spyddene og generelt vide, hvordan alting fungerer, forstå fysikken i radiobølgetransmission. Som følge heraf var der kun én knap tilbage i radioen.
Hvilken radio nu i 2019? I bilen finder radiomodtageren alle bølgerne og navnene på stationerne. Processens fysik har ikke ændret sig i 100 år, men brugervenligheden har. Nu, og ikke kun nu, allerede i 1980, da der var et interview med Azimov, brugte alle radioen, og ingen tænkte over, hvordan det fungerede. Det virkede altid – det er givet.
Azimov sagde så, at det ville være det samme med computere - brugervenligheden vil stige. Mens man i 1980 skulle uddannes til at trykke på knapper på en computer, så bliver det ikke tilfældet i fremtiden.
Jeg har en fornemmelse af, at der med Kubernetes og med infrastrukturen også vil ske en enorm stigning i brugervenlighed. Dette er efter min mening indlysende - det ligger på overfladen.
Hvad skal man gøre med ingeniører?
— Hvad vil der så ske med de ingeniører og systemadministratorer, der understøtter Kubernetes?
Dmitry: Hvad skete der med revisoren efter fremkomsten af 1C? Cirka det samme. Før dette regnede de på papiret – nu i programmet. Arbejdsproduktiviteten er steget i størrelsesordener, men selve arbejdet er ikke forsvundet. Hvis det tidligere tog 10 ingeniører at skrue en pære i, så er en nu nok.
Mængden af software og antallet af opgaver, forekommer det mig, vokser nu i et hurtigere tempo end nye DevOps dukker op, og effektiviteten er stigende. Der er en specifik mangel på markedet lige nu, og det vil vare længe. Senere vil alt vende tilbage til en form for normalitet, hvor effektiviteten af arbejdet vil stige, der vil være mere og mere serverløse, en neuron vil blive knyttet til Kubernetes, som vil vælge alle ressourcerne nøjagtigt efter behov, og generelt vil gøre alt selv, som det skal - personen går bare væk og blander sig ikke.
Men nogen skal stadig træffe beslutninger. Det er klart, at denne persons kvalifikations- og specialiseringsniveau er højere. I dag behøver man i regnskabsafdelingen ikke 10 medarbejdere, der skal føre bog, så hænderne ikke bliver trætte. Det er simpelthen ikke nødvendigt. Mange dokumenter scannes automatisk og genkendes af det elektroniske dokumenthåndteringssystem. Én smart regnskabschef er nok, allerede med meget større kompetencer, med god forståelse.
Generelt er dette vejen at gå i alle brancher. Det er det samme med biler: Tidligere kom en bil med en mekaniker og tre chauffører. I dag er bilkørsel en simpel proces, som vi alle deltager i hver dag. Ingen tror, at en bil er noget kompliceret.
DevOps eller system engineering vil ikke forsvinde - arbejde på højt niveau og effektivitet vil stige.
— Jeg hørte også en interessant idé om, at arbejdet faktisk vil stige.
Dmitry: Selvfølgelig, hundrede procent! For mængden af software, vi skriver, vokser konstant. Antallet af problemer, som vi løser med software, vokser konstant. Mængden af arbejde vokser. Nu er DevOps-markedet frygtelig overophedet. Det kan ses i lønforventningerne. På en god måde, uden at gå i detaljer, skal der være juniorer, der vil have X, midterste, der vil 1,5X, og seniorer, der vil 2X. Og nu, hvis du ser på Moskvas DevOps-lønmarked, vil en junior have fra X til 3X, og en senior vil have fra X til 3X.
Ingen ved, hvor meget det koster. Lønniveauet måles på din selvtillid – et komplet galehus, for at være ærlig, et frygteligt overophedet marked.
Selvfølgelig vil denne situation ændre sig meget snart - en vis mætning skulle forekomme. Sådan er det ikke med softwareudvikling – på trods af at alle har brug for udviklere, og alle har brug for gode udviklere, så forstår markedet, hvem der er hvad værd – har branchen faldet til ro. Det er ikke tilfældet med DevOps i disse dage.
— Ud fra det, jeg hørte, konkluderede jeg, at den nuværende systemadministrator ikke skulle bekymre sig for meget, men det er tid til at opgradere sine færdigheder og forberede sig på, at der i morgen vil være mere arbejde, men det vil være mere højt kvalificeret.
Dmitry: Et hundrede procent. Generelt lever vi i 2019 og leveregelen er denne: livslang læring – vi lærer hele livet. Det forekommer mig, at alle nu allerede ved og føler dette, men det er ikke nok at vide - du skal gøre det. Hver dag skal vi ændre os. Gør vi ikke dette, så bliver vi før eller siden droppet på sidelinjen af faget.
Vær forberedt på skarpe 180-graders drejninger. Jeg udelukker ikke en situation, hvor noget ændrer sig radikalt, noget nyt er opfundet - det sker. Hoppe! - og nu handler vi anderledes. Det er vigtigt at være forberedt på dette og ikke at bekymre sig. Det kan ske, at i morgen vil alt, hvad jeg gør, vise sig at være unødvendigt - ingenting, jeg har studeret hele mit liv og er klar til at lære noget andet. Det er ikke et problem. Der er ingen grund til at være bange for jobsikkerhed, men du skal være forberedt på hele tiden at lære noget nyt.
Ønsker og et minuts reklame
- Har du et ønske?
Dmitry: Ja, jeg har flere ønsker.
Første og merkantile - abonner på . Kære læsere, gå til YouTube og abonner på vores kanal. Om cirka en måned begynder vi aktiv udvidelse af videotjenesten. Vi vil have en masse undervisningsindhold om Kubernetes, åbent og varieret: fra praktiske ting, helt ned til laboratorier, til dybe grundlæggende teoretiske ting og hvordan man bruger Kubernetes på niveau af principper og mønstre.
Det andet merkantile ønske - gå til og sætte stjerner, fordi vi lever af dem. Hvis du ikke giver os stjerner, har vi ikke noget at spise. Det er ligesom mana i et computerspil. Vi gør noget, vi gør, vi prøver, nogen siger, at det er forfærdelige cykler, nogen, at alt er helt galt, men vi fortsætter og handler helt ærligt. Vi ser et problem, løser det og deler vores erfaringer. Derfor, giv os en stjerne, den forsvinder ikke fra dig, men den vil komme til os, fordi vi lever af dem.
Tredje, vigtigt og ikke længere merkantilt ø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 klikke for dig, og du vil forstå det. Forestil dig, at du kommer på hospitalet, og der eksperimenterer lægen med dig. Jeg forstår, at dette kan være stødende for nogen, men højst sandsynligt handler det ikke om dig, men om en anden. Fortæl andre, at de også skal stoppe. Dette ødelægger virkelig livet for os alle - mange begynder at behandle operationer, administratorer og DevOps som fyre, der har ødelagt noget igen. Dette blev ”brudt” oftest på grund af, at vi gik til leg, og ikke så med kold bevidsthed ud på, at sådan er det, og sådan er det.
Det betyder ikke, at du ikke skal eksperimentere. Vi skal eksperimentere, vi gør det selv. For at være ærlig spiller vi selv nogle gange spil - det er selvfølgelig meget dårligt, men intet menneskeligt er os fremmed. Lad os erklære 2019 for et år med seriøse, gennemtænkte eksperimenter og ikke spil i produktion. Sandsynligvis det.
- Mange tak!
Dmitry: Tak, Vitaly, både for tiden og for interviewet. Kære læsere, mange tak, hvis I pludselig er nået hertil. Jeg håber, at vi har bragt dig mindst et par tanker.
I interviewet berørte Dmitry spørgsmålet om werf. Nu er dette en universal schweizisk kniv, der løser næsten alle problemer. Men det var ikke altid sådan. På på festivalen Dmitry Stolyarov vil fortælle dig om dette værktøj i detaljer. i rapporten der vil være alt: problemer og skjulte nuancer af Kubernetes, muligheder for at løse disse vanskeligheder og den nuværende implementering af werf i detaljer. Kom med den 27. og 28. maj, vi skaber de perfekte værktøjer.
Kilde: www.habr.com