En espera Vitali Khabarov entrevistat Dmitri Stolyarov (), director tècnic i cofundador de l'empresa Flant. Vitaly va preguntar a Dmitry sobre què fa Flant, sobre Kubernetes, desenvolupament d'ecosistemes, suport. Hem comentat per què es necessita Kubernetes i si és necessari. I també sobre els microserveis, Amazon AWS, l'enfocament "tindré sort" de DevOps, el futur de Kubernetes mateix, per què, quan i com s'apoderarà del món, les perspectives de DevOps i per a què haurien de preparar-se els enginyers en el futur brillant i proper amb simplificació i xarxes neuronals.
escolteu com a podcast a DevOps Deflop: un podcast en rus sobre DevOps, i a continuació teniu la versió de text.
Aquí i a continuació fa preguntes enginyer d'Express42.
Sobre "Flant"
- Hola Dima. Vostè és el director tècnic"" i també el seu fundador. Si us plau, digueu-nos què fa l'empresa i en què sou?
Dmitry: Des de fora sembla que som els nois que anem instal·lant Kubernetes per a tothom i fent alguna cosa amb ell. Però això no és cert. Vam començar com una empresa que s'ocupa de Linux, però durant molt de temps la nostra activitat principal ha estat el servei de producció i projectes clau en mà d'alta càrrega. Normalment construïm tota la infraestructura des de zero i després en som responsables durant molt de temps. Per tant, la principal obra que fa “Flant”, per la qual rep diners, és assumir la responsabilitat i implementar la producció clau en mà.
Jo, com a director tècnic i un dels fundadors de l'empresa, passo tot el dia i la nit intentant esbrinar com augmentar l'accessibilitat de la producció, simplificar-ne el funcionament, facilitar la vida dels administradors i la vida dels desenvolupadors més agradable. .
Sobre Kubernetes
— Últimament he estat veient molts reportatges de Flant i sobre Kubernetes. Com hi vas arribar?
Dmitry: Ja n'he parlat moltes vegades, però no m'importa repetir-ho gens. Crec que és correcte repetir aquest tema perquè hi ha confusió entre causa i efecte.
Realment necessitem una eina. Ens vam enfrontar a molts problemes, vam lluitar, els vam superar amb diverses crosses i vam sentir la necessitat d'una eina. Vam passar per moltes opcions diferents, vam construir les nostres pròpies bicicletes i vam guanyar experiència. A poc a poc vam arribar al punt en què vam començar a utilitzar Docker gairebé tan bon punt va aparèixer: cap al 2013. En el moment de la seva aparició, ja teníem molta experiència amb contenidors, ja havíem escrit un anàleg de "Docker": algunes de les nostres crosses en Python. Amb l'arribada de Docker, va ser possible llençar les crosses i utilitzar una solució fiable i recolzada per la comunitat.
Amb Kubernetes la història és semblant. Quan va començar a agafar impuls -per a nosaltres aquesta és la versió 1.2- ja teníem un munt de crosses tant a Shell com a Chef, que d'alguna manera vam intentar orquestrar amb Docker. Estàvem mirant seriosament cap a Rancher i diverses altres solucions, però després va aparèixer Kubernetes, en què tot s'implementa exactament com ho hauríem fet o fins i tot millor. No hi ha res de què queixar-se.
Sí, hi ha algun tipus d'imperfecció aquí, hi ha algun tipus d'imperfecció allà - hi ha moltes imperfeccions, i 1.2 en general és terrible, però... Kubernetes és com un edifici en construcció - mires el projecte i entens que serà genial. Si ara l'edifici té una base i dos pisos, enteneu que és millor no entrar-hi encara, però no hi ha problemes amb el programari, ja el podeu utilitzar.
No vam tenir cap moment en què vam pensar en utilitzar Kubernetes o no. L'estàvem esperant molt abans que aparegués i vam intentar crear anàlegs nosaltres mateixos.
Sobre Kubernetes
— Estàs directament implicat en el desenvolupament de Kubernetes?
Dmitry: Mediocre. Més aviat, participem en el desenvolupament de l'ecosistema. Enviem un cert nombre de sol·licituds d'extracció: a Prometheus, a diversos operadors, a Helm, a l'ecosistema. Malauradament, no sóc capaç de fer un seguiment de tot el que fem i podria estar equivocat, però no hi ha ni un sol grup de nosaltres al nucli.
— Al mateix temps, desenvolupeu moltes de les vostres eines al voltant de Kubernetes?
Dmitry: L'estratègia és aquesta: anem i tirem peticions a tot el que ja existeix. Si les sol·licituds d'extracció no s'accepten allà, simplement les bifurquem nosaltres mateixos i vivim fins que s'accepten amb les nostres versions. Aleshores, quan arriba al riu amunt, tornem a la versió aigües amunt.
Per exemple, tenim un operador Prometheus, amb el qual hem canviat d'anada i tornada a l'aigua amunt del nostre conjunt probablement ja 5 vegades. Necessitem algun tipus de funció, hem enviat una sol·licitud d'extracció, l'hem de llançar demà, però no volem esperar que s'alliberi aigües amunt. En conseqüència, muntem per nosaltres mateixos, desenvolupem el nostre muntatge amb la nostra funció, que necessitem per algun motiu, a tots els nostres clústers. Aleshores, per exemple, ens ho passen a l'aigua amunt amb les paraules: “Nois, fem-ho per un cas més general”, nosaltres, o algú altre, l'acabem, i amb el temps es torna a fusionar.
Intentem desenvolupar tot el que existeix. Molts elements que encara no existeixen, encara no s'han inventat, o s'han inventat, però que no han tingut temps d'implementar-ho estem fent. I no perquè ens agradi el procés o la construcció de bicicletes com a indústria, sinó simplement perquè necessitem aquesta eina. Sovint es fa la pregunta, per què hem fet això o allò? La resposta és senzilla: sí, perquè havíem d'anar més enllà, resoldre algun problema pràctic, i ho hem resolt amb aquesta tula.
El camí sempre és així: busquem amb molta cura i, si no trobem cap solució sobre com fer un troleibús amb un tros de pa, fem el nostre propi pa i el nostre propi troleibús.
Eines Flanta
— Sé que Flant ara té operadors de complements, operadors de shell i eines dapp/werf. Segons tinc entès, aquest és el mateix instrument en diferents encarnacions. També entenc que hi ha moltes més eines diferents dins de Flaunt. Això és cert?
Dmitry: Tenim molt més a GitHub. Pel que recordo ara, tenim un mapa d'estat: un panell de Grafana que tothom ha trobat. S'esmenta gairebé a cada segon article sobre el seguiment de Kubernetes a Medium. És impossible explicar breument què és un mapa d'estat: necessita un article a part, però és una cosa molt útil per controlar l'estat al llarg del temps, ja que a Kubernetes sovint hem de mostrar l'estat al llarg del temps. També tenim LogHouse: això es basa en ClickHouse i màgia negra per recollir registres a Kubernetes.
Moltes utilitats! I encara n'hi haurà més, perquè aquest any es llançaran diverses solucions internes. Dels molt grans basats en l'operador de complements, hi ha un munt de complements per a Kubernetes, com ara com instal·lar correctament el gestor de sert: una eina per gestionar certificats, com instal·lar correctament Prometheus amb un munt d'accessoris; aquests són una vintena diferents. binaris que exporten dades i recullen alguna cosa, a aquest Prometheus té els gràfics i alertes més sorprenents. Tot això és només un munt de complements a Kubernetes, que s'instal·len en un clúster, i passa de simple a fresc, sofisticat, automàtic, en què ja s'han resolt molts problemes. Sí, fem moltes coses.
Desenvolupament d'ecosistemes
"Em sembla que aquesta és una gran contribució al desenvolupament d'aquest instrument i els seus mètodes d'ús". Pots estimar aproximadament qui més faria la mateixa contribució al desenvolupament de l'ecosistema?
Dmitry: A Rússia, de les empreses que operen al nostre mercat, ningú està ni tan sols a prop. Per descomptat, aquesta és una afirmació forta, perquè hi ha actors importants com Mail i Yandex; també estan fent alguna cosa amb Kubernetes, però fins i tot no s'acosten a la contribució d'empreses de tot el món que fan molt més que nosaltres. És difícil comparar Flant, que té una plantilla de 80 persones, i Red Hat, que només té 300 enginyers per Kubernetes, si no m'equivoco. És difícil de comparar. Tenim 6 persones al departament de RnD, inclòs jo, que tallen totes les nostres eines. 6 persones enfront de 300 enginyers de Red Hat; d'alguna manera és difícil de comparar.
- No obstant això, quan fins i tot aquestes 6 persones poden fer alguna cosa realment útil i alienant, quan s'enfronten a un problema pràctic i donen la solució a la comunitat, un cas interessant. Entenc que a les grans empreses tecnològiques, on tenen el seu propi equip de desenvolupament i suport de Kubernetes, en principi, es poden desenvolupar les mateixes eines. Aquest és un exemple per a ells del que es pot desenvolupar i donar a la comunitat, donant impuls a tota la comunitat que utilitza Kubernetes.
Dmitry: Aquesta és probablement una característica de l'integrador, la seva peculiaritat. Tenim molts projectes i veiem situacions molt diferents. Per a nosaltres, la principal manera de crear valor afegit és analitzar aquests casos, trobar punts en comú i fer-los el més barats possible. Estem treballant activament en això. Em costa parlar de Rússia i del món, però tenim uns 40 enginyers DevOps a l'empresa que treballen a Kubernetes. No crec que hi hagi moltes empreses a Rússia amb un nombre comparable d'especialistes que entenguin Kubernetes, si n'hi ha.
Ho entenc tot sobre el títol del treball Enginyer DevOps, tothom ho entén tot i està acostumat a trucar als enginyers DevOps enginyers DevOps, no en parlarem. Tots aquests 40 increïbles enginyers de DevOps s'enfronten i resolen problemes cada dia, només analitzem aquesta experiència i intentem generalitzar. Entenem que si roman dins nostre, en un any o dos l'eina serà inútil, perquè en algun lloc de la comunitat apareixerà una Tula ja feta. No té sentit acumular aquesta experiència internament: simplement està drenant energia i temps a dev/null. I no ho sentim gens. Ho publiquem tot amb molt de gust i entenem que cal publicar-lo, desenvolupar-lo, promocionar-lo, promocionar-lo, perquè la gent l'utilitzi i afegeixi la seva experiència; llavors tot creix i viu. Després de dos anys, l'instrument no surt a les escombraries. No és una llàstima continuar abocant força, perquè està clar que algú està utilitzant la teva eina, i després de dos anys tothom l'està fent servir.
Això forma part de la nostra gran estratègia amb dapp/werf. No recordo quan vam començar a fer-lo, sembla que fa 3 anys. Inicialment, generalment estava a la closca. Va ser una súper prova de concepte, vam resoldre alguns dels nostres problemes particulars: va funcionar! Però hi ha problemes amb el shell, és impossible ampliar-lo més, programar al shell és una altra tasca. Teníem el costum d'escriure en Ruby, per tant, vam tornar a fer alguna cosa en Ruby, vam desenvolupar, desenvolupar, desenvolupar i ens vam trobar amb el fet que la comunitat, la multitud que no diu "ho volem o no ho volem, ” gira el nas a Ruby, què divertit és això? Ens vam adonar que hauríem d'escriure totes aquestes coses a Go només per complir el primer punt de la llista de verificació: L'eina DevOps hauria de ser un binari estàtic. Ser Go o no no és tan important, però és millor un binari estàtic escrit en Go.
Vam gastar la nostra energia, vam reescriure el dapp a Go i l'hem anomenat werf. El Dapp ja no és compatible, no està desenvolupat, s'executa en alguna darrera versió, però hi ha una ruta d'actualització absoluta a la part superior i podeu seguir-la.
Per què es va crear el dapp?
— Ens pots explicar breument per què es va crear la dapp, quins problemes soluciona?
Dmitry: El primer motiu és a l'assemblea. Inicialment, vam tenir problemes greus amb la compilació quan Docker no tenia capacitats multietapa, així que vam fer diverses etapes pel nostre compte. Després vam tenir un munt de problemes més amb la neteja de la imatge. Tothom que fa CI/CD, més aviat que tard, s'enfronta al problema que hi ha un munt d'imatges recollides, cal netejar d'alguna manera el que no es necessita i deixar el que cal.
El segon motiu és el desplegament. Sí, hi ha Helm, però només soluciona alguns dels problemes. Curiosament, està escrit que "Helm és el gestor de paquets per a Kubernetes". Exactament què "el". També hi ha les paraules "Gestor de paquets": quina és l'expectativa habitual d'un gestor de paquets? Diem: "Gestor de paquets: instal·leu el paquet!" i esperem que ens digui: "El paquet ha estat lliurat".
És interessant que diem: "Helm, instal·la el paquet", i quan ell respon que l'ha instal·lat, resulta que acaba de començar la instal·lació; va indicar a Kubernetes: "Llança aquesta cosa!", i si va començar o no. , tant si funciona com si no, Helm no resol aquest problema en absolut.
Resulta que Helm és només un preprocessador de text que carrega dades a Kubernetes.
Però com a part de qualsevol desplegament, volem saber si l'aplicació s'ha llançat per a la producció o no? Llançat a prod significa que l'aplicació s'ha mogut allà, que s'ha desplegat la nova versió i, almenys, no s'estavella allà i respon correctament. Helm no resol aquest problema de cap manera. Per solucionar-ho, heu de dedicar molt d'esforç, perquè heu de donar a Kubernetes l'ordre per implementar i supervisar el que hi passa, tant si s'ha desplegat com si s'ha implementat. I també hi ha moltes tasques relacionades amb el desplegament, la neteja i el muntatge.
Plans
Aquest any començarem el desenvolupament local. Volem aconseguir el que abans hi havia a Vagrant: vam escriure "vagrant up" i vam desplegar màquines virtuals. Volem arribar al punt en què hi ha un projecte a Git, hi escrivim "werf up" i apareix una còpia local d'aquest projecte, desplegada en un mini-Kub local, amb tots els directoris convenients per al desenvolupament connectats. . Depenent del llenguatge de desenvolupament, això es fa de manera diferent, però tanmateix, de manera que el desenvolupament local es pugui dur a terme còmodament sota fitxers muntats.
El següent pas per a nosaltres és invertir en comoditat per als desenvolupadors. Per implementar ràpidament un projecte localment amb una eina, desenvolupeu-lo, introduïu-lo a Git i també es desplegarà a l'etapa o a les proves, depenent dels pipelines, i després utilitzarà la mateixa eina per passar a la producció. Aquesta unitat, unificació, reproductibilitat de la infraestructura des de l'entorn local fins a les vendes és un punt molt important per a nosaltres. Però això encara no està en werf; només estem planejant fer-ho.
Però el camí cap a dapp/werf sempre ha estat el mateix que amb Kubernetes al principi. Hem trobat problemes, els hem resolt amb solucions alternatives: hem trobat algunes solucions per a nosaltres mateixos al shell, a qualsevol cosa. Llavors van intentar redreçar d'alguna manera aquestes solucions, generalitzar-les i consolidar-les en binaris en aquest cas, que simplement compartim.
Hi ha una altra manera de veure tota aquesta història, amb analogies.
Kubernetes és un bastidor de cotxe amb motor. No hi ha portes, vidres, ràdio, arbre de Nadal, res de res. Només el marc i el motor. I hi ha Helm: aquest és el volant. Genial: hi ha un volant, però també necessiteu un passador, una cremallera de direcció, una caixa de canvis i unes rodes, i no podeu prescindir d'ells.
En el cas de werf, aquest és un altre component de Kubernetes. Només ara a la versió alfa de werf, per exemple, Helm està compilat dins de werf, perquè estem cansats de fer-ho nosaltres mateixos. Hi ha moltes raons per fer-ho, us explicaré en detall per què hem compilat tot el timó juntament amb el timón dins del werf .
Ara werf és un component més integrat. Tenim un volant acabat, un passador de direcció: no sóc gaire bo amb cotxes, però aquest és un bloc gran que ja resol una sèrie de problemes bastant ampli. No cal que repassem nosaltres mateixos el catàleg, seleccionem una peça per una altra, pensem com enganxar-les. Obtenim una combinada preparada que resol un gran nombre de problemes alhora. Però a l'interior està construït a partir dels mateixos components de codi obert, encara utilitza Docker per al muntatge, Helm per a algunes de les funcionalitats i hi ha diverses altres biblioteques. Aquesta és una eina integrada per treure CI/CD de la caixa de manera ràpida i còmoda.
És difícil mantenir Kubernetes?
— Parles de l'experiència que vas començar a utilitzar Kubernetes, aquest és un bastidor per a tu, un motor, i que hi pots penjar moltes coses diferents: una carrosseria, un volant, pedals de cargol, seients. Sorgeix la pregunta: quina dificultat és per a vostè l'assistència de Kubernetes? Tens molta experiència, quant temps i recursos dediques a donar suport a Kubernetes de manera aïllada de tota la resta?
Dmitry: Aquesta és una pregunta molt difícil i per respondre, hem d'entendre què és el suport i què volem de Kubernetes. Potser pots revelar?
— Pel que jo sé i veig, ara molts equips volen provar Kubernetes. Tothom s'hi atreveix, s'hi posa de genolls. Tinc la sensació que la gent no sempre entén la complexitat d'aquest sistema.
Dmitry: És així.
— Què tan difícil és agafar i instal·lar Kubernetes des de zero perquè estigui llest per a la producció?
Dmitry: Què tan difícil creus que és trasplantar un cor? Entenc que aquesta és una pregunta comprometedora. Utilitzar un bisturí i no equivocar-se no és tan difícil. Si et diuen on tallar i on cosir, el procediment en si no és complicat. És difícil garantir una rere l'altra que tot funcionarà.
Instal·lar Kubernetes i fer-lo funcionar és fàcil: xick! — instal·lat, hi ha molts mètodes d'instal·lació. Però què passa quan sorgeixen problemes?
Sempre sorgeixen preguntes: què no hem tingut en compte encara? Què no hem fet encara? Quins paràmetres del nucli de Linux s'han especificat incorrectament? Senyor, els hem esmentat?! Quins components de Kubernetes hem lliurat i quins no? Es plantegen milers de preguntes i, per respondre-les, cal passar 15-20 anys en aquesta indústria.
Tinc un exemple recent sobre aquest tema que pot revelar el significat del problema "És difícil mantenir Kubernetes?" Fa un temps ens vam plantejar seriosament si hauríem d'intentar implementar Cilium com a xarxa a Kubernetes.
Deixa'm explicar què és Cilium. Kubernetes té moltes implementacions diferents del subsistema de xarxes, i una d'elles és molt interessant: Cilium. Quin és el seu significat? Al nucli, fa un temps, es va fer possible escriure ganxos per al nucli, que d'una manera o altra envaeixen el subsistema de xarxa i diversos altres subsistemes, i us permeten evitar grans blocs del nucli.
Històricament, el nucli de Linux té una ruta IP, un sobrefiltre, ponts i molts components antics diferents que tenen 15, 20, 30 anys. En general, funcionen, tot és genial, però ara tenen contenidors amuntegats, i sembla una torre de 15 maons uns sobre els altres, i t'hi poses sobre una cama, una sensació estranya. Aquest sistema s'ha desenvolupat històricament amb molts matisos, com l'apèndix al cos. En algunes situacions, per exemple, hi ha problemes de rendiment.
Hi ha un BPF meravellós i la capacitat d'escriure ganxos per al nucli: els nois van escriure els seus propis ganxos per al nucli. El paquet entra al nucli de Linux, el treuen directament a l'entrada, el processen ells mateixos com hauria de ser sense ponts, sense TCP, sense una pila IP; surt al contenidor.
Què va passar? Rendiment molt fantàstic, funcions genials, simplement genial! Però mirem això i veiem que a cada màquina hi ha un programa que es connecta a l'API de Kubernetes i, a partir de les dades que rep d'aquesta API, genera codi C i compila binaris que carrega al nucli perquè funcionin aquests ganxos. a l'espai del nucli.
Què passa si alguna cosa va malament? No ho sabem. Per entendre-ho, cal llegir tot aquest codi, entendre tota la lògica i és increïble com de difícil és. Però, d'altra banda, hi ha aquests ponts, filtres de xarxa, IP rout: no he llegit el seu codi font, i tampoc els 40 enginyers que treballen a la nostra empresa. Potser només uns quants entenen algunes parts.
I quina diferència hi ha? Resulta que hi ha IP rout, el nucli de Linux i hi ha una nova eina: quina diferència hi ha, no entenem ni l'un ni l'altre. Però tenim por d'utilitzar alguna cosa nova, per què? Perquè si l'eina té 30 anys, en 30 anys s'han trobat tots els errors, s'han trepitjat tots els errors i no cal saber-ho tot: funciona com una caixa negra i sempre funciona. Tothom sap quin tornavís de diagnòstic col·locar en quin lloc, quin tcpdump s'ha d'executar en quin moment. Tothom coneix bé les utilitats de diagnòstic i entén com funciona aquest conjunt de components al nucli de Linux, no com funciona, sinó com utilitzar-lo.
I el Cilium increïblement genial no té 30 anys, encara no ha envellit. Kubernetes té el mateix problema, còpia. Que Cilium està instal·lat perfectament, que Kubernetes està instal·lat perfectament, però quan alguna cosa va malament a la producció, pots entendre ràpidament què va fallar en una situació crítica?
Quan diem és difícil mantenir Kubernetes, no, és molt fàcil, i sí, és increïblement difícil. Kubernetes funciona molt bé per si sol, però amb mil milions de matisos.
Sobre l'enfocament "tindré sort".
— Hi ha empreses on aquests matisos estan gairebé garantits? Suposem que Yandex transfereix de sobte tots els serveis a Kubernetes, hi haurà una gran càrrega.
Dmitry: No, això no és una conversa sobre la càrrega, sinó sobre les coses més senzilles. Per exemple, tenim Kubernetes, hi hem desplegat l'aplicació. Com saps que funciona? Simplement no hi ha cap eina preparada per entendre que l'aplicació no s'estavella. No hi ha cap sistema ja preparat que enviï alertes; cal que configureu aquestes alertes i cada programació. I estem actualitzant Kubernetes.
Tinc Ubuntu 16.04. Es pot dir que aquesta és una versió antiga, però encara hi estem perquè és LTS. Hi ha systemd, el matís del qual és que no neteja els grups C. Kubernetes llança pods, crea grups C, després suprimeix pods i, d'alguna manera, resulta que, no recordo els detalls, ho sento, queden els sectors systemd. Això porta al fet que amb el temps, qualsevol cotxe comença a frenar amb força. Aquesta no és ni tan sols una pregunta sobre la càrrega alta. Si es llancen pods permanents, per exemple, si hi ha un treball Cron que genera constantment pods, aleshores la màquina amb Ubuntu 16.04 començarà a alentir-se després d'una setmana. Hi haurà una mitjana de càrrega constantment alta a causa del fet que s'han creat un munt de grups C. Aquest és el problema al qual s'enfrontarà qualsevol persona que simplement instal·li Ubuntu 16 i Kubernetes a la part superior.
Suposem que d'alguna manera actualitza systemd o una altra cosa, però al nucli de Linux fins a la 4.16 és encara més divertit: quan suprimiu els grups C, es filtren al nucli i en realitat no s'eliminen. Per tant, després d'un mes de treball en aquesta màquina, serà impossible mirar les estadístiques de memòria de les llars. Traiem un fitxer, l'enrotllem al programa i un fitxer s'enrotlla durant 15 segons, perquè el nucli triga molt a comptar un milió de grups C dins de si mateix, que sembla que s'han suprimit, però no, s'estan filtrant. .
Encara hi ha moltes coses tan petites aquí i allà. Aquest no és un problema que les empreses gegants puguin enfrontar de vegades amb càrregues molt pesades; no, és una qüestió de coses quotidianes. La gent pot viure així durant mesos: van instal·lar Kubernetes, van desplegar l'aplicació, sembla que funciona. Per a moltes persones això és normal. Ni tan sols sabran que aquesta aplicació es bloquejarà per algun motiu, no rebran cap alerta, però per a ells aquesta és la norma. Abans, vivíem en màquines virtuals sense monitorització, ara ens vam traslladar a Kubernetes, també sense monitoratge: quina diferència hi ha?
La qüestió és que quan caminem sobre gel, mai no sabem el seu gruix si no ho mesurem amb antelació. Molta gent camina i no es preocupi, perquè ja han caminat abans.
Des del meu punt de vista, el matís i la complexitat d'operar qualsevol sistema és garantir que el gruix del gel sigui exactament suficient per resoldre els nostres problemes. Això és del que estem parlant.
En TI, em sembla, hi ha massa plantejaments de "tindré sort". Moltes persones instal·len programari i utilitzen biblioteques de programari amb l'esperança de tenir sort. En general, molta gent té sort. Probablement per això funciona.
— Segons la meva valoració pessimista, sembla així: quan els riscos són alts, i l'aplicació ha de funcionar, llavors cal suport de Flaunt, potser de Red Hat, o necessiteu el vostre propi equip intern dedicat específicament a Kubernetes, que està preparat. per treure'l.
Dmitry: Objectivament, això és així. Entrar a la història de Kubernetes per a un equip petit implica una sèrie de riscos.
Necessitem contenidors?
— Ens pots dir quina difusió té Kubernetes a Rússia?
Dmitry: No tinc aquestes dades, i no estic segur que ningú més les tingui. Diem: "Kubernetes, Kubernetes", però hi ha una altra manera de veure aquest problema. Tampoc no sé fins a quin punt estan estesos els contenidors, però conec una xifra d'informes a Internet que el 70% dels contenidors estan orquestrats per Kubernetes. Va ser una font fiable per a una mostra bastant gran a tot el món.
Aleshores, una altra pregunta: necessitem contenidors? El meu sentiment personal i la posició general de l'empresa Flant és que Kubernetes és un estàndard de facto.
No hi haurà res més que Kubernetes.
Això és un canvi absolut en el camp de la gestió d'infraestructures. Absolut: això és tot, no més Ansible, Chef, màquines virtuals, Terraform. No parlo dels vells mètodes de granja col·lectiva. Kubernetes és un canvi absolut, i ara només serà així.
És evident que per a alguns calen un parell d'anys, i per a altres un parell de dècades, per adonar-se'n. No tinc cap dubte que no hi haurà més que Kubernetes i aquest nou aspecte: ja no malmetem el sistema operatiu, sinó que fem servir infraestructura com a codi, només que no amb codi, sinó amb yml, una infraestructura descrita de manera declarativa. Tinc la sensació que sempre serà així.
— És a dir, aquelles empreses que encara no s'han canviat a Kubernetes definitivament hi canviaran o quedaran en l'oblit. T'he entès bé?
Dmitry: Això tampoc és del tot cert. Per exemple, si tenim la tasca d'executar un servidor DNS, llavors es pot executar amb FreeBSD 4.10 i pot funcionar perfectament durant 20 anys. Només treballa i ja està. Potser d'aquí a 20 anys caldrà actualitzar alguna cosa una vegada. Si estem parlant de programari en el format que vam llançar i realment funciona durant molts anys sense cap actualització, sense fer canvis, llavors, és clar, no hi haurà Kubernetes. No és necessari allà.
Tot el relacionat amb CI/CD, allà on calgui l'entrega contínua, on cal actualitzar versions, fer canvis actius, allà on necessiteu crear tolerància a errors, només Kubernetes.
Sobre els microserveis
- Aquí tinc una lleugera dissonància. Per treballar amb Kubernetes, necessiteu suport extern o intern: aquest és el primer punt. En segon lloc, quan tot just comencem el desenvolupament, som una petita startup, encara no tenim res, el desenvolupament per a Kubernetes o l'arquitectura de microserveis en general pot ser complex i no sempre justificat econòmicament. M'interessa la teva opinió: les startups han de començar immediatament a escriure per a Kubernetes des de zero, o encara poden escriure un monòlit i només arribar a Kubernetes?
Dmitry: Genial pregunta. Tinc una xerrada sobre els microserveis Moltes vegades m'he trobat amb gent que intentava picar claus amb un microscopi. L'enfocament en si és correcte; nosaltres mateixos dissenyem el nostre programari intern d'aquesta manera. Però quan feu això, heu d'entendre clarament el que esteu fent. La paraula que més odio dels microserveis és "micro". Històricament, aquesta paraula es va originar allà, i per alguna raó la gent pensa que micro és molt petit, menys d'un mil·límetre, com un micròmetre. Això està malament.
Per exemple, hi ha un monòlit escrit per 300 persones, i tots els que van participar en el desenvolupament entenen que hi ha problemes i s'hauria de dividir en micropeces: unes 10 peces, cadascuna de les quals està escrita per 30 persones. en una versió mínima. Això és important, necessari i fresc. Però quan ens ve una startup, on 3 nois molt xulos i talentosos van escriure 60 microserveis de genolls, cada vegada que busco Corvalol.
Em sembla que ja se n'ha parlat milers de vegades: tenim un monòlit distribuït d'una forma o una altra. Això no està justificat econòmicament, és molt difícil en general en tot. Acabo de veure això tantes vegades que em fa molt mal, així que continuo parlant-ne.
A la pregunta inicial, hi ha un conflicte entre el fet que, d'una banda, Kubernetes fa por d'utilitzar, perquè no està clar què hi pot trencar o no funcionar, d'altra banda, està clar que tot va allà. i no hi haurà res més que Kubernetes. Resposta - sospesar la quantitat de beneficis que se'n deriven, la quantitat de tasques que pots resoldre. Això està en un costat de l'escala. D'altra banda, hi ha riscos associats amb temps d'inactivitat o amb una disminució del temps de resposta, nivell de disponibilitat, amb una disminució dels indicadors de rendiment.
Aquí està: o ens movem ràpidament i Kubernetes ens permet fer moltes coses molt més ràpid i millor, o utilitzem solucions fiables i provades en el temps, però ens movem molt més lentament. Aquesta és una elecció que tota empresa ha de fer. Pots pensar-ho com un camí a la jungla: quan camines per primera vegada, pots trobar-te amb una serp, un tigre o un teixó boig, i quan has caminat 10 vegades, has trepitjat el camí, tret. les branques i caminar més fàcil. Cada cop el camí es fa més ample. Després és una carretera asfaltada, i després una bonica rambla.
Kubernetes no s'atura. Pregunta de nou: Kubernetes, d'una banda, són 4-5 binaris, d'altra banda, és tot l'ecosistema. Aquest és el sistema operatiu que tenim a les nostres màquines. Què és això? Ubuntu o Curios? Aquest és el nucli de Linux, un munt de components addicionals. Totes aquestes coses aquí, una serp verinosa va ser llançada fora de la carretera, allà es va aixecar una tanca. Kubernetes s'està desenvolupant de forma molt ràpida i dinàmica, i el volum de riscos, el volum de la desconeguda va disminuint cada mes i, en conseqüència, aquestes escales es reequilibren.
Respondre a la pregunta sobre què hauria de fer una startup, diria: veniu a Flaunt, pagueu 150 mil rubles i obteniu un servei fàcil de DevOps clau en mà. Si sou una petita startup amb uns quants desenvolupadors, això funciona. En lloc de contractar el vostre propi DevOps, que haurà d'aprendre a resoldre els vostres problemes i pagar un sou en aquest moment, obtindreu una solució clau en mà per a tots els problemes. Sí, hi ha alguns inconvenients. Nosaltres, com a subcontractadors, no podem estar tan implicats i respondre ràpidament als canvis. Però tenim molta experiència i pràctiques ja fetes. Garantim que en qualsevol situació definitivament ho esbrinarem ràpidament i ressuscitarem qualsevol Kubernetes d'entre els morts.
Recomano fermament l'externalització a startups i empreses consolidades fins a una mida on es pugui dedicar un equip de 10 persones a les operacions, perquè sinó no serveix de res. Definitivament té sentit externalitzar això.
Sobre Amazon i Google
— Es pot considerar un host d'una solució d'Amazon o Google com a subcontractació?
Dmitry: Sí, és clar, això resol una sèrie de problemes. Però de nou hi ha matisos. Encara heu d'entendre com utilitzar-lo. Per exemple, hi ha mil coses petites en el treball d'Amazon AWS: cal escalfar el Load Balancer o s'ha d'escriure una sol·licitud per endavant que "nois, rebrem trànsit, escalfeu-nos el Load Balancer!" Cal conèixer aquests matisos.
Quan recorreu a persones especialitzades en això, es tanquen gairebé totes les coses típiques. Ara tenim 40 enginyers, a finals d'any probablement n'hi haurà 60; definitivament ens hem trobat amb totes aquestes coses. Fins i tot si tornem a trobar aquest problema en algun projecte, ràpidament ens preguntem i sabem com resoldre'l.
Probablement la resposta sigui: per descomptat, una història allotjada facilita alguna part. La pregunta és si esteu preparats per confiar en aquests hosts i si us resoldran els vostres problemes. Amazon i Google ho han fet bé. Per a tots els nostres casos, exactament. No tenim més experiències positives. Tots els altres núvols amb els quals hem intentat treballar creen molts problemes: Ager i tot el que hi ha a Rússia, i tot tipus d'OpenStack en diferents implementacions: Headster, Overage, el que vulgueu. Tots creen problemes que no voleu resoldre.
Per tant, la resposta és sí, però, de fet, no hi ha gaires solucions allotjades madures.
Qui necessita Kubernetes?
— I, tanmateix, qui necessita Kubernetes? Qui ja hauria de canviar a Kubernetes, qui és el client típic de Flaunt que ve específicament per a Kubernetes?
Dmitry: Aquesta és una pregunta interessant, perquè ara mateix, arran de Kubernetes, molta gent ens ve: "Nois, sabem que esteu fent Kubernetes, feu-ho per nosaltres!" Els responem: "Senyors, no fem Kubernetes, fem prod i tot el que hi estigui relacionat". Perquè actualment és simplement impossible fer un producte sense fer tot el CI/CD i tota aquesta història. Tothom s'ha allunyat de la divisió que tenim desenvolupament per desenvolupament, i després explotació per explotació.
Els nostres clients esperen coses diferents, però tothom està esperant un bon miracle que tingui certs problemes, i ara, hop! — Kubernetes els solucionarà. La gent creu en els miracles. En la seva ment entenen que no hi haurà cap miracle, però en la seva ànima esperen: què passa si aquest Kubernetes ara ens ho resol tot, en parlen molt! De sobte ell ara - esternuda! - i una bala de plata, esternuda! — i tenim un temps de funcionament del 100%, tots els desenvolupadors poden llançar qualsevol cosa que entri en producció 50 vegades i no s'estavella. En general, un miracle!
Quan aquestes persones vénen a nosaltres, diem: "Ho sento, però no hi ha cap miracle". Per estar saludable, cal menjar bé i fer exercici. Per tenir un producte fiable, s'ha de fer de manera fiable. Per tenir un CI/CD convenient, cal que sigui així. És molta feina que s'ha de fer.
Responent a la pregunta de qui necessita Kubernetes: ningú no necessita Kubernetes.
Algunes persones tenen la concepció errònia que necessiten Kubernetes. La gent necessita, té una profunda necessitat de deixar de pensar, estudiar i interessar-se per tots els problemes d'infraestructures i els problemes d'execució de les seves aplicacions. Volen que les aplicacions funcionin i només es despleguin. Per a ells, Kubernetes és l'esperança que deixin d'escoltar la història que "estàvem allà estirats", o "no podem desplegar", o alguna altra cosa.
Normalment ens ve el director tècnic. Li demanen dues coses: d'una banda, donar-nos trets, de l'altra, estabilitat. Us suggerim que us ho preneu i feu-ho. La bala de plata, o més aviat platejat, és que deixaràs de pensar en aquests problemes i perdreu el temps. Tindràs gent especial que tancarà aquest número.
La paraula que nosaltres o qualsevol altra persona necessitem Kubernetes és incorrecta.
Els administradors necessiten realment Kubernetes, perquè és una joguina molt interessant amb la qual pots jugar i jugar. Siguem sincers: a tothom li agraden les joguines. Tots som nens en algun lloc, i quan en veiem un de nou, volem jugar-hi. Per a alguns, això s'ha desanimat, per exemple, a l'administració, perquè ja han jugat prou i ja estan cansats fins al punt que simplement no volen. Però això no està completament perdut per a ningú. Per exemple, si fa temps que estic cansat de les joguines en l'àmbit de l'administració de sistemes i DevOps, encara m'encanten les joguines, encara en compro de noves. Totes les persones, d'una manera o altra, encara volen algun tipus de joguines.
No cal jugar amb la producció. Sigui el que us recomano categòricament no fer i el que veig ara en massa: "Oh, una joguina nova!" — van córrer a comprar-lo, el van comprar i: “Ara portem-lo a l’escola i ensenyem-lo a tots els nostres amics”. No facis això. Demano disculpes, els meus fills estan creixent, constantment veig alguna cosa en els nens, ho noto en mi i després ho generalitzo als altres.
La resposta final és: no necessiteu Kubernetes. Necessites resoldre els teus problemes.
El que pots aconseguir és:
- el punxó no cau;
- encara que intenti caure, ho sabem per endavant, i hi podem posar alguna cosa;
- podem canviar-lo a la velocitat a què ho requereix el nostre negoci, i ho podem fer de manera còmoda; no ens causa cap problema.
Hi ha dues necessitats reals: fiabilitat i dinamisme/flexibilitat de desplegament. Tothom que actualment està fent algun tipus de projectes informàtics, independentment de quin tipus de negoci, suau per facilitar el món, i qui ho entengui, ha de resoldre aquestes necessitats. Kubernetes amb l'enfocament adequat, amb la comprensió adequada i amb prou experiència et permet resoldre'ls.
Sobre sense servidor
— Si mireu una mica més al futur, intentant resoldre el problema de l'absència de maldecaps amb la infraestructura, amb la velocitat de llançament i la velocitat dels canvis d'aplicació, apareixen noves solucions, per exemple, sense servidor. Sentiu algun potencial en aquesta direcció i, diguem-ne, un perill per a Kubernetes i solucions similars?
Dmitry: Aquí hem de tornar a fer una observació que jo no sóc un vident que mira endavant i diu: serà així! Encara que jo vaig fer el mateix. Em miro els peus i hi veig un munt de problemes, per exemple, com funcionen els transistors en un ordinador. És divertit, oi? Estem trobant alguns errors a la CPU.
Feu que els servidors siguin bastant fiables, barats, eficients i còmodes, resolent tots els problemes de l'ecosistema. Aquí estic d'acord amb Elon Musk que es necessita un segon planeta per crear tolerància a les falles per a la humanitat. Encara que no sé què diu, entenc que jo mateix no estic preparat per volar a Mart i que no passarà demà.
Amb un servidor sense servidor, és evident que això és una cosa ideològicament correcta, com la tolerància a fallades per a la humanitat: tenir dos planetes és millor que un. Però com fer-ho ara? Enviar una expedició no és un problema si hi concentres els teus esforços. Enviar diverses expedicions i instal·lar-hi diversos milers de persones, crec, també és realista. Però fer que sigui totalment tolerant a errors perquè la meitat de la humanitat hi visqui, ara em sembla impossible, no ser considerat.
Amb un a un sense servidor: la cosa està genial, però està lluny dels problemes del 2019. Més a prop del 2030: visquem per veure-ho. No tinc cap dubte que viurem, definitivament viurem (repetim abans d'anar a dormir), però ara hem de resoldre altres problemes. És com creure en el poni de conte de fades Rainbow. Sí, un parell per cent dels casos estan resolts, i es resolen perfectament, però subjectivament, sense servidor és un arc de Sant Martí... Per a mi, aquest tema és massa llunyà i massa incomprensible. No estic preparat per parlar. El 2019, no podeu escriure una sola aplicació sense servidor.
Com evolucionarà Kubernetes
— A mesura que avancem cap a aquest futur llunyà potencialment meravellós, com creus que es desenvoluparà Kubernetes i l'ecosistema que l'envolta?
Dmitry: He pensat molt en això i tinc una resposta clara. El primer és amb estat; després de tot, sense estat és més fàcil de fer. Kubernetes inicialment va invertir més en això, tot va començar amb això. Sense estat funciona gairebé perfectament a Kubernetes, no hi ha res de què queixar-se. Encara hi ha molts problemes, o millor dit, matisos. Tot allà ja funciona molt bé per a nosaltres, però això som nosaltres. Caldrà almenys un parell d'anys més perquè això funcioni per a tothom. Aquest no és un indicador calculat, sinó el meu sentiment des del meu cap.
En resum, statefull s'hauria de desenvolupar -i ho farà- amb molta força, perquè totes les nostres aplicacions emmagatzemen l'estat; no hi ha aplicacions sense estat. Això és una il·lusió; sempre necessiteu algun tipus de base de dades i alguna cosa més. Statefull consisteix a endreçar tot el que és possible, arreglar tots els errors, millorar tots els problemes que s'enfronten actualment; anomenem-ho adopció.
El nivell de la desconeguda, el nivell de problemes no resolts, el nivell de probabilitat de trobar-se amb alguna cosa baixarà significativament. Aquesta és una història important. I els operadors -tot el relacionat amb la codificació de la lògica d'administració, la lògica de control per tal d'aconseguir un servei fàcil: MySQL easy service, RabbitMQ easy service, Memcache easy service- en general, tots aquests components que hem de garantir que funcionem. la Caixa. Això només soluciona el dolor que volem una base de dades, però no volem administrar-la, o volem Kubernetes, però no volem administrar-la.
Aquesta història de desenvolupament d'operadors d'una forma o una altra serà important en els propers dos anys.
Crec que la facilitat d'ús hauria d'augmentar molt: la caixa es tornarà cada cop més negra, cada cop més fiable, amb botons cada cop més senzills.
Una vegada vaig escoltar una antiga entrevista amb Isaac Asimov dels anys 80 a YouTube a Saturday Night Live, un programa com Urgant, només interessant. Li van preguntar sobre el futur dels ordinadors. Va dir que el futur està en la senzillesa, igual que la ràdio. El receptor de ràdio era originàriament una cosa complexa. Per agafar una ona, calia girar els botons durant 15 minuts, girar les broquetes i, en general, saber com funciona tot, entendre la física de la transmissió de les ones de ràdio. Com a resultat, només quedava un botó a la ràdio.
Ara el 2019 quina ràdio? Al cotxe, el receptor de ràdio troba totes les ones i els noms de les estacions. La física del procés no ha canviat en 100 anys, però sí la facilitat d'ús. Ara, i no només ara, ja l'any 1980, quan hi va haver una entrevista amb Azimov, tothom feia servir la ràdio i ningú pensava en com funcionava. Sempre va funcionar, això és un fet.
Aleshores Azimov va dir que passaria el mateix amb els ordinadors: augmentarà la facilitat d'ús. Tot i que l'any 1980 t'havies d'entrenar per prémer botons en un ordinador, això no serà el cas en el futur.
Tinc la sensació que amb Kubernetes i amb la infraestructura també hi haurà un gran augment de la facilitat d'ús. Això, al meu entendre, és obvi: es troba a la superfície.
Què fer amb els enginyers?
— Què passarà llavors amb els enginyers i administradors de sistemes que donen suport a Kubernetes?
Dmitry: Què va passar amb el comptable després de l'arribada de l'1C? Sobre el mateix. Abans d'això, comptaven amb el paper, ara al programa. La productivitat laboral ha augmentat en ordres de magnitud, però el treball en si no ha desaparegut. Si abans es necessitaven 10 enginyers per cargolar una bombeta, ara n'hi haurà prou amb una.
La quantitat de programari i el nombre de tasques, em sembla, ara creixen a un ritme més ràpid del que estan apareixent nous DevOps i l'eficiència augmenta. Ara mateix hi ha una escassetat específica al mercat i durarà molt de temps. Més tard, tot tornarà a una mena de normalitat, en la qual augmentarà l'eficiència del treball, cada cop hi haurà més servidors, s'adjuntarà una neurona a Kubernetes, que seleccionarà tots els recursos exactament segons sigui necessari, i en general ho farà. fer-ho tot sol, com cal: la persona només s'allunya i no interfereixi.
Però algú encara haurà de prendre decisions. És evident que el nivell de qualificació i especialització d'aquesta persona és superior. Avui en dia, al departament de comptabilitat, no cal que 10 treballadors portin llibres perquè no es cansin les mans. Simplement no és necessari. Molts documents són escanejats i reconeguts automàticament pel sistema de gestió de documents electrònics. N'hi ha prou amb un cap comptable intel·ligent, ja amb habilitats molt més grans, amb una bona comprensió.
En general, aquest és el camí a seguir en tots els sectors. Amb els cotxes passa el mateix: abans venia un cotxe amb un mecànic i tres conductors. Avui en dia, conduir un cotxe és un procés senzill en el qual tots participem cada dia. Ningú pensa que un cotxe és una cosa complicada.
DevOps o enginyeria de sistemes no desapareixeran: augmentarà el treball d'alt nivell i l'eficiència.
— També vaig sentir una idea interessant que la feina augmentarà.
Dmitry: Per descomptat, al cent per cent! Perquè la quantitat de programari que escrivim està en constant creixement. El nombre de problemes que resolem amb el programari està en constant creixement. La quantitat de treball està creixent. Ara el mercat DevOps està terriblement sobreescalfat. Això es pot veure en les expectatives salarials. En bona manera, sense entrar en detalls, hi hauria d'haver júniors que vulguin X, mitjans que vulguin 1,5X i sèniors que vulguin 2X. I ara, si mireu el mercat salarial de Moscou DevOps, un jove vol de X a 3X i un sènior vol de X a 3X.
Ningú sap quant costa. El nivell salarial es mesura per la vostra confiança: un manicomi complet, per ser honest, un mercat terriblement sobreescalfat.
Per descomptat, aquesta situació canviarà molt aviat: hauria de produir-se una mica de saturació. Aquest no és el cas del desenvolupament de programari, malgrat que tothom necessita desenvolupadors i tothom necessita bons desenvolupadors, el mercat entén qui val què, la indústria s'ha assentat. Aquest no és el cas de DevOps en aquests dies.
— Pel que vaig escoltar, vaig concloure que l'actual administrador del sistema no s'hauria de preocupar massa, però és el moment d'actualitzar les seves habilitats i preparar-se per al fet que demà hi haurà més feina, però serà més altament qualificada.
Dmitry: Cent per cent. En general, vivim el 2019 i la regla de vida és aquesta: Aprenentatge al llarg de la vida: aprenem al llarg de la nostra vida. Em sembla que ara tothom ja ho sap i ho sent, però no n'hi ha prou amb saber-ho: ho has de fer. Cada dia hem de canviar. Si no ho fem, tard o d'hora serem deixats al marge de la professió.
Estigueu preparat per a girs bruscos de 180 graus. No descarto una situació en què alguna cosa canviï radicalment, s'inventi alguna cosa nova: passa. Hop! - i ara actuem de manera diferent. És important estar preparat per a això i no preocupar-se. Pot passar que demà tot el que faig resulti innecessari, res, he estudiat tota la vida i estic disposat a aprendre una altra cosa. No és un problema. No cal tenir por a la seguretat laboral, però cal estar preparat per aprendre constantment alguna cosa nova.
Desitjos i un minut de publicitat
- Tens algun desig?
Dmitry: Sí, tinc diversos desitjos.
Primer i mercantil - subscriu-te . Benvolguts lectors, aneu a YouTube i subscriviu-vos al nostre canal. D'aquí a un mes aproximadament començarem l'expansió activa del servei de vídeo, tindrem un munt de continguts educatius sobre Kubernetes, oberts i variats: des de coses pràctiques, fins a laboratoris, fins a aspectes teòrics fonamentals profunds i com utilitzar Kubernetes a la nivell de principis i patrons.
El segon desig mercantil - anar a i posar estrelles perquè ens n'alimentem. Si no ens dones estrelles, no tindrem res per menjar. És com el mana en un joc d'ordinador. Fem alguna cosa, fem, intentem, algú diu que són bicicletes terribles, algú que tot està totalment malament, però seguim i actuem amb absoluta honestedat. Veiem un problema, el solucionem i compartim la nostra experiència. Per tant, dona'ns una estrella, que no s'allunyarà de tu, sinó que vindrà a nosaltres, perquè ens n'alimentem.
Tercer, desig important i ja no mercantil - deixar de creure en els contes de fades. Sou professionals. DevOps és una professió molt seriosa i responsable. Deixeu de jugar al lloc de treball. Deixa que faci clic per tu i ho entendràs. Imagina que véns a l'hospital i allà el metge està experimentant amb tu. Entenc que això pot ser ofensiu per a algú, però, molt probablement, no es tracta de tu, sinó d'una altra persona. Digues als altres que també s'aturin. Això realment arruïna la vida de tots nosaltres: molts comencen a tractar les operacions, els administradors i els DevOps com a nois que han tornat a trencar alguna cosa. Això s'havia "trencat" la majoria de vegades pel fet que anàvem a jugar, i no miràvem amb una consciència freda que així és, i així és.
Això no vol dir que no hagis d'experimentar. Hem d'experimentar, ho fem nosaltres mateixos. Per ser sincers, de vegades juguem a jocs; això, per descomptat, és molt dolent, però res humà no ens és aliè. Declararem el 2019 un any d'experiments seriosos i ben pensats, i no de jocs en producció. Probablement sí.
- Moltes gràcies!
Dmitry: Gràcies, Vitaly, tant pel temps com per l'entrevista. Benvolguts lectors, moltes gràcies si de sobte heu arribat a aquest punt. Espero que us hàgim aportat almenys un parell de reflexions.
A l'entrevista, Dmitry va tocar el tema del werf. Ara, aquest és un ganivet suís universal que resol gairebé tots els problemes. Però no sempre va ser així. Encès a festivals Dmitry Stolyarov us explicarà detalladament aquesta eina. a l'informe hi haurà de tot: problemes i matisos ocults de Kubernetes, opcions per resoldre aquestes dificultats i la implementació actual de werf en detall. Uneix-te a nosaltres els dies 27 i 28 de maig, crearem les eines perfectes.
Font: www.habr.com