V očekávání Vitalij Chabarov rozhovor Dmitrij Stolyarov (), technický ředitel a spoluzakladatel společnosti Flant. Vitaly se zeptal Dmitryho na to, co Flant dělá, na Kubernetes, vývoj ekosystému, podporu. Diskutovali jsme o tom, proč je Kubernetes potřeba a zda je vůbec potřeba. A také o mikroslužbách, Amazon AWS, přístupu „budu mít štěstí“ k DevOps, budoucnosti Kubernetes samotného, proč, kdy a jak ovládne svět, vyhlídkách DevOps a na co by se měli inženýři připravit v světlé a blízké budoucnosti se zjednodušením a neuronovými sítěmi.
poslouchejte jako podcast na DevOps Deflop - rusky psaný podcast o DevOps a níže je textová verze.
Zde a níže klade otázky inženýr z Express42.
O "Flant"
- Ahoj Dimo. Vy jste technický ředitel"“ a také její zakladatel. Řekněte nám prosím, čím se společnost zabývá a čím se zabýváte?
Dmitry: Zvenčí to vypadá, jako bychom byli chlapi, kteří instalují Kubernetes pro všechny a něco s tím dělají. Ale to není pravda. Začínali jsme jako společnost zabývající se Linuxem, ale již velmi dlouhou dobu byl naší hlavní činností servis výroby a velkoobjemových projektů na klíč. Obvykle celou infrastrukturu vybudujeme od nuly a pak za ni neseme dlouhou, dlouhou dobu zodpovědnost. Hlavní práce, kterou „Flant“ dělá, za kterou dostává peníze, je tedy převzetí odpovědnosti a realizace výroby na klíč.
Já jako technický ředitel a jeden ze zakladatelů firmy se celé dny a noci snažím vymýšlet, jak zvýšit dostupnost výroby, zjednodušit její provoz, usnadnit život administrátorům a zpříjemnit život vývojářům. .
O Kubernetes
— V poslední době jsem viděl hodně zpráv od Flata a o Kubernetes. jak jsi k tomu přišel?
Dmitry: Už jsem o tom mluvil mnohokrát, ale vůbec mi nevadí to opakovat. Myslím, že je správné toto téma opakovat, protože dochází k záměně mezi příčinou a následkem.
Opravdu jsme potřebovali nástroj. Čelili jsme spoustě problémů, bojovali, překonávali je různými berličkami a cítili potřebu nástroje. Prošli jsme mnoha různými možnostmi, postavili si vlastní kola a získali zkušenosti. Postupně jsme se dostali do bodu, kdy jsme Docker začali používat téměř hned, jak se objevil – kolem roku 2013. V době jeho vzniku jsme již měli s kontejnery bohaté zkušenosti, již jsme napsali obdobu „Docker“ – některé z našich vlastních berliček v Pythonu. S příchodem Dockeru bylo možné zahodit berličky a použít spolehlivé a komunitou podporované řešení.
S Kubernetes je příběh podobný. V době, kdy to začalo nabírat na síle – pro nás je to verze 1.2 – jsme už měli na Shell i Chef spoustu berliček, které jsme se nějakým způsobem pokusili zorganizovat s Dockerem. Vážně jsme hledali Rancher a různá další řešení, ale pak se objevil Kubernetes, ve kterém je vše implementováno přesně tak, jak bychom to udělali nebo ještě lépe. Není co vytknout.
Ano, je tu nějaká nedokonalost, je tam nějaká nedokonalost - je tam spousta nedokonalostí a 1.2 je obecně hrozná, ale... Kubernetes je jako budova ve výstavbě - podíváte se na projekt a pochopíte že to bude v pohodě. Pokud má budova nyní základy a dvě patra, pak chápete, že je lepší se ještě nenastěhovat, ale se softwarem nejsou žádné takové problémy - již jej můžete používat.
Neměli jsme okamžik, kdy jsme přemýšleli o použití Kubernetes nebo ne. Čekali jsme na to dlouho předtím, než se objevil, a sami jsme se snažili vytvořit analogy.
O Kubernetes
— Podílíte se přímo na vývoji samotného Kubernetes?
Dmitry: Průměrný. Spíše se podílíme na rozvoji ekosystému. Posíláme určitý počet žádostí o stažení: Prometheovi, různým operátorům, Helmu - do ekosystému. Bohužel nejsem schopen sledovat vše, co děláme, a mohu se mýlit, ale od nás do jádra není jediný fond.
— Zároveň vyvíjíte mnoho svých nástrojů kolem Kubernetes?
Dmitry: Strategie je tato: jdeme a stahujeme požadavky na vše, co již existuje. Pokud tam žádosti o stažení nejsou akceptovány, jednoduše je sami forkneme a žijeme, dokud nebudou přijaty s našimi stavbami. Poté, když dosáhne upstream, vrátíme se zpět k upstream verzi.
Máme například operátor Prometheus, se kterým jsme se asi 5x přepínali tam a zpět proti proudu naší sestavy. Potřebujeme nějakou funkci, poslali jsme žádost o stažení, potřebujeme ji zítra zavést, ale nechceme čekat, až bude uvolněna. V souladu s tím sestavujeme pro sebe, zavádíme naši sestavu s naší funkcí, kterou z nějakého důvodu potřebujeme, do všech našich clusterů. Pak nám to třeba v upstreamu předají se slovy: „Kluci, uděláme to na obecnější případ,“ doděláme to my nebo někdo jiný a časem se to zase spojí.
Snažíme se rozvíjet vše, co existuje. Mnoho prvků, které ještě neexistují, ještě nebyly vynalezeny, nebo byly vynalezeny, ale nestihli je implementovat – děláme to. A ne proto, že se nám líbí proces nebo stavba kol jako odvětví, ale jednoduše proto, že tento nástroj potřebujeme. Často se klade otázka, proč jsme udělali to či ono? Odpověď je jednoduchá - ano, protože jsme museli jít dál, vyřešit nějaký praktický problém a vyřešili jsme ho touto tulou.
Cesta je vždy taková: velmi pečlivě hledáme, a když nenajdeme řešení, jak z bochníku chleba udělat trolejbus, uděláme si svůj bochník a svůj trolejbus.
Nástroje Flata
— Vím, že Flant má nyní operátory doplňků, operátory shellu a nástroje dapp/werf. Pokud tomu rozumím, jedná se o stejný nástroj v různých inkarnacích. Také chápu, že ve Flauntu je mnohem více různých nástrojů. To je pravda?
Dmitry: Na GitHubu toho máme mnohem víc. Co si teď pamatuji, máme statusmapu – panel pro Grafana, na který každý narazil. Je zmíněn téměř v každém druhém článku o monitorování Kubernetes na médiu. Není možné stručně vysvětlit, co je to statusmap - potřebuje samostatný článek, ale je to velmi užitečná věc pro sledování stavu v čase, protože v Kubernetes často potřebujeme zobrazovat stav v čase. Máme také LogHouse - to je věc založená na ClickHouse a černé magii pro sběr logů v Kubernetes.
Spousta utilit! A bude jich ještě více, protože letos vyjde řada interních řešení. Z těch hodně velkých založených na operátorovi addonů existuje hromada addonů pro Kubernetes, ala jak správně nainstalovat sert manager - nástroj pro správu certifikátů, jak správně nainstalovat Prometheus s hromadou příslušenství - těch je asi dvacet různých binární soubory, které exportují data a něco sbírají, k tomu má Prometheus nejúžasnější grafiku a upozornění. To vše je jen hromada doplňků do Kubernetes, které se instalují do clusteru a z jednoduchých se to stává cool, sofistikované, automatické, ve kterých je již mnoho problémů vyřešeno. Ano, děláme hodně.
Vývoj ekosystému
"Zdá se mi, že je to velmi velký příspěvek k rozvoji tohoto nástroje a jeho metod použití." Dokážete zhruba odhadnout, kdo další by stejně přispěl k rozvoji ekosystému?
Dmitry: V Rusku se z firem, které působí na našem trhu, nikdo ani neblíží. Samozřejmě je to hlasité prohlášení, protože existují významní hráči jako Mail a Yandex – také něco dělají s Kubernetes, ale ani oni se nepřibližují přínosu společností z celého světa, které dělají mnohem víc než my. Je těžké srovnávat Flant, který má 80 zaměstnanců, a Red Hat, který má 300 inženýrů na Kubernetes, pokud se nepletu. Těžko se to srovnává. Na oddělení RnD máme 6 lidí včetně mě, kteří nám řežou veškeré nářadí. 6 lidí versus 300 inženýrů Red Hat – je to nějak těžké srovnávat.
- Když však i těchto 6 lidí může udělat něco opravdu užitečného a odcizujícího, když stojí před praktickým problémem a dávají řešení komunitě - zajímavý případ. Chápu, že ve velkých technologických firmách, kde mají vlastní vývojový a podpůrný tým Kubernetes, lze v principu vyvíjet stejné nástroje. Je to pro ně příklad toho, co lze vyvinout a dát komunitě, což dává impuls celé komunitě, která používá Kubernetes.
Dmitry: To je asi vlastnost integrátoru, jeho zvláštnost. Máme mnoho projektů a vidíme mnoho různých situací. Pro nás je hlavní cestou k vytváření přidané hodnoty analyzovat tyto případy, najít společné rysy a udělat je pro nás co nejlevnější. Aktivně na tom pracujeme. Je pro mě těžké mluvit o Rusku a světě, ale ve společnosti máme asi 40 inženýrů DevOps, kteří pracují na Kubernetes. Nemyslím si, že v Rusku je mnoho společností se srovnatelným počtem specialistů, kteří rozumí Kubernetes, pokud vůbec nějací.
Rozumím všemu o pracovním názvu DevOps engineer, každý rozumí všemu a je zvyklý nazývat DevOps inženýry DevOps inženýry, o tom se nebudeme bavit. Všech těchto 40 úžasných inženýrů DevOps čelí a řeší problémy každý den, my jen analyzujeme tuto zkušenost a snažíme se zobecnit. Chápeme, že pokud to v nás zůstane, tak za rok nebo dva bude nástroj k ničemu, protože někde v komunitě se objeví hotová Tula. Nemá smysl tuto zkušenost vnitřně hromadit – je to prostě vysávání energie a času do dev/null. A vůbec nám to není líto. Vše zveřejňujeme s velkou radostí a chápeme, že je to potřeba zveřejňovat, rozvíjet, propagovat, propagovat, aby to lidé využívali a přidávali své zkušenosti – pak vše roste a žije. Po dvou letech pak nástroj nejde do koše. Není škoda pokračovat v nalévání síly, protože je jasné, že váš nástroj někdo používá a po dvou letech ho používají všichni.
To je součástí naší velké strategie s dapp/werf. Nepamatuji si, kdy jsme to začali vyrábět, připadá mi to jako před 3 lety. Zpočátku to bylo obecně na skořápce. Byl to super důkaz konceptu, vyřešili jsme některé z našich konkrétních problémů - fungovalo to! Problémy jsou ale s shellem, nelze jej dále rozšiřovat, programování na shellu je další úkol. Měli jsme ve zvyku psát v Ruby, podle toho jsme něco předělali v Ruby, vyvinuli, vyvinuli, vyvinuli a narazili jsme na to, že komunita, dav, který neříká „chceme to nebo to nechceme, “ ohrnuje nos nad Ruby, jak vtipné to je? Uvědomili jsme si, že bychom měli všechny tyto věci napsat do Go, abychom splnili první bod na kontrolním seznamu: Nástroj DevOps by měl být statický binární soubor. Být Go nebo ne není tak důležité, ale statický binární soubor napsaný v Go je lepší.
Utratili jsme energii, přepsali dapp v Go a nazvali jsme to werf. Dapp již není podporován, není vyvíjen, běží v nějaké nejnovější verzi, ale existuje absolutní cesta upgradu na vrchol a můžete ji sledovat.
Proč byl dapp vytvořen?
— Můžete nám stručně říci, proč dapp vznikl, jaké problémy řeší?
Dmitry: První důvod je ve shromáždění. Zpočátku jsme měli vážné problémy se sestavením, když Docker neměl vícestupňové schopnosti, takže jsme si udělali vícestupňový sami. Pak jsme měli spoustu dalších problémů s čištěním obrazu. Každý, kdo dělá CI/CD, se spíše dříve než později potýká s problémem, že je hromada nasbíraných obrázků, je potřeba nějak uklidit nepotřebné a nechat to, co je potřeba.
Druhým důvodem je nasazení. Ano, existuje Helm, ale řeší jen některé problémy. Je zábavné, že je napsáno, že „Helm je správcem balíčků pro Kubernetes“. Přesně to „to“. Jsou zde také slova „Správce balíčků“ – jaká jsou obvyklá očekávání od správce balíčků? Říkáme: "Správce balíčků - nainstalujte balíček!" a očekáváme, že nám řekne: "Balík byl doručen."
Je zajímavé, že říkáme: „Kormidlo, nainstaluj balíček,“ a když odpoví, že jej nainstaloval, ukáže se, že právě spustil instalaci – naznačil Kubernetesovi: „Spusťte tuto věc!“ a zda to začalo nebo ne ať už to funguje nebo ne, Helm tento problém vůbec neřeší.
Ukazuje se, že Helm je pouze textový preprocesor, který načítá data do Kubernetes.
Ale v rámci jakéhokoli nasazení chceme vědět, zda byla aplikace uvolněna pro produkci nebo ne? Rolled to prod znamená, že se tam aplikace přesunula, nová verze byla nasazena a alespoň tam nepadá a reaguje správně. Helm tento problém nijak neřeší. Chcete-li to vyřešit, musíte vynaložit velké úsilí, protože musíte dát Kubernetes příkaz k zavedení a sledování toho, co se tam děje – ať už se to nasadilo nebo zavedlo. A je tu také spousta úkolů souvisejících s nasazením, čištěním a montáží.
Plány
Letos zahájíme místní rozvoj. Chceme dosáhnout toho, co bylo dříve ve Vagrant – zadali jsme „vagrant up“ a nasadili jsme virtuální stroje. Chceme se dostat do bodu, kdy je v Gitu projekt, napíšeme tam „werf up“ a vyvolá místní kopii tohoto projektu nasazenou v místním mini-Kubu se všemi adresáři vhodnými pro vývoj připojenými . V závislosti na vývojovém jazyce se to dělá jinak, ale přesto tak, aby místní vývoj mohl být pohodlně prováděn pod připojenými soubory.
Dalším krokem pro nás je investovat do pohodlí pro vývojáře. Chcete-li rychle nasadit projekt lokálně pomocí jednoho nástroje, vyviňte jej, vložte jej do Gitu a také se spustí do fáze nebo testů v závislosti na kanálech a poté použije stejný nástroj k přechodu do produkce. Tato jednota, sjednocení, reprodukovatelnost infrastruktury od lokálního prostředí až po prodej je pro nás velmi důležitým bodem. Ale to ještě není ve werfu - teprve to plánujeme.
Ale cesta k dapp/werf byla vždy stejná jako u Kubernetes na začátku. Setkali jsme se s problémy, vyřešili je pomocí řešení – přišli jsme s nějakými řešeními pro sebe na shellu, na čemkoli. Pak se pokusili tato řešení nějak narovnat, zobecnit a sjednotit je v tomto případě do binárních souborů, které jednoduše sdílíme.
Existuje jiný způsob, jak se na celý tento příběh podívat s analogiemi.
Kubernetes je rám auta s motorem. Nejsou tam žádné dveře, sklo, rádio, vánoční stromeček – vůbec nic. Jen rám a motor. A je tu Helm - to je volant. Skvělé - je tu volant, ale potřebujete také čep řízení, hřeben řízení, převodovku a kola a bez nich se neobejdete.
V případě werf je to další součást Kubernetes. Teprve nyní v alfa verzi werf je například Helm zkompilován uvnitř werf, protože nás to nebaví dělat sami. Existuje mnoho důvodů, proč to udělat, řeknu vám podrobně o tom, proč jsme sestavili celou kormidlo společně s kormidlem uvnitř werf .
Nyní je werf integrovanější komponentou. Dostáváme hotový volant, čep řízení - nejsem moc dobrý v autech, ale je to velký blok, který již řeší poměrně širokou škálu problémů. Nemusíme sami procházet katalog, vybírat jeden díl za druhý, přemýšlet, jak je sešroubovat. Dostáváme tak hotový kombajn, který řeší velké množství problémů najednou. Ale uvnitř je postaven ze stejných open source komponent, stále používá Docker pro sestavení, Helm pro některé funkce a existuje několik dalších knihoven. Jedná se o integrovaný nástroj pro rychlé a pohodlné vyjmutí chladného CI/CD z krabice.
Je údržba Kubernetes náročná?
— Mluvíš o zkušenosti, že jsi začal používat Kubernetes, tohle je pro tebe rám, motor, a že na něj můžeš pověsit spoustu různých věcí: karoserii, volant, přišroubovat pedály, sedačky. Nabízí se otázka – jak náročná je pro vás podpora Kubernetes? Máte mnoho zkušeností, kolik času a zdrojů věnujete podpoře Kubernetes izolovaně od všeho ostatního?
Dmitry: Toto je velmi těžká otázka a na odpověď musíme pochopit, co je podpora a co od Kubernetes chceme. Možná můžete prozradit?
— Pokud vím a jak vidím, mnoho týmů chce nyní Kubernetes vyzkoušet. Všichni se k tomu zapřahají, položí si to na kolena. Mám pocit, že ne vždy lidé chápou složitost tohoto systému.
Dmitry: Je to tak.
— Jak těžké je vzít a nainstalovat Kubernetes od začátku, aby byl připraven na výrobu?
Dmitry: Jak těžké je podle vás transplantovat srdce? Chápu, že je to kompromitující otázka. Používat skalpel a neudělat chybu není tak těžké. Pokud vám řeknou, kde stříhat a kde šít, tak samotný postup není složitý. Je těžké zaručit, že vše bude fungovat.
Instalace Kubernetes a uvedení do provozu je snadné: kuřátko! — nainstalováno, existuje mnoho způsobů instalace. Ale co se stane, když nastanou problémy?
Vždy se objevují otázky – co jsme ještě nevzali v úvahu? Co jsme ještě neudělali? Které parametry linuxového jádra byly zadány nesprávně? Pane, zmínili jsme je vůbec?! Které komponenty Kubernetes jsme dodali a které ne? Vyvstávají tisíce otázek a abyste na ně odpověděli, musíte v tomto odvětví strávit 15–20 let.
Mám nedávný příklad na toto téma, který může odhalit význam problému „Je obtížné udržovat Kubernetes?“ Před časem jsme vážně zvažovali, zda bychom neměli zkusit implementovat Cilium jako síť v Kubernetes.
Dovolte mi vysvětlit, co je Cilium. Kubernetes má mnoho různých implementací síťového subsystému a jedna z nich je velmi cool - Cilium. jaký je jeho význam? V jádře bylo před časem možné psát háčky pro jádro, které tak či onak napadají síťový subsystém a různé další subsystémy a umožňují obejít velké kusy v jádře.
Linuxové jádro má historicky ip rout, přefiltr, mosty a mnoho různých starých komponent, které jsou staré 15, 20, 30 let. Obecně fungují, všechno je super, ale teď naskládali kontejnery a vypadá to jako věž z 15 cihel na sobě a stojíte na ní na jedné noze - zvláštní pocit. Tento systém se historicky vyvíjel s mnoha nuancemi, jako je slepé střevo v těle. V některých situacích dochází například k problémům s výkonem.
Je tam úžasný BPF a možnost psát háčky pro jádro - kluci si pro jádro napsali vlastní háčky. Balíček přijde do linuxového jádra, vytáhnou ho hned na vstupu, zpracují ho sami jak má bez mostů, bez TCP, bez IP stacku - zkrátka obejdou vše, co je napsáno v linuxovém jádře, a pak vyplivnou to ven do kontejneru.
Co se stalo? Velmi skvělý výkon, skvělé funkce - prostě skvělé! Ale podíváme se na to a vidíme, že na každém počítači je program, který se připojí k Kubernetes API a na základě dat, která z tohoto API obdrží, vygeneruje C kód a zkompiluje binární soubory, které nahraje do jádra, aby tyto háčky fungovaly v prostoru jádra.
Co se stane, když se něco pokazí? Nevíme. Abyste tomu porozuměli, musíte si přečíst celý tento kód, pochopit veškerou logiku a je úžasné, jak je to obtížné. Ale na druhou stranu jsou tu tyto mosty, síťové filtry, ip rout – nečetl jsem jejich zdrojový kód a ani těch 40 inženýrů, kteří v naší společnosti pracují. Možná jen málokdo rozumí některým částem.
A jaký je v tom rozdíl? Ukazuje se, že existuje ip rout, linuxové jádro a nový nástroj - jaký je v tom rozdíl, nerozumíme jednomu nebo druhému. Ale bojíme se použít něco nového – proč? Protože pokud je nástroj 30 let starý, pak za 30 let byly všechny chyby nalezeny, všechny chyby byly zašlápnuty a nemusíte o všem vědět - funguje to jako černá skříňka a vždy funguje. Každý ví, který diagnostický šroubovák na které místo nalepit, který tcpdump v jakém okamžiku spustit. Každý dobře zná diagnostické nástroje a rozumí tomu, jak tato sada komponent funguje v linuxovém jádře – ne jak funguje, ale jak ji používat.
A úžasně cool Cilium není 30 let staré, ještě nezestárlo. Kubernetes má stejný problém, zkopírujte. Že Cilium je nainstalováno perfektně, že Kubernetes je nainstalováno perfektně, ale když se něco pokazí ve výrobě, dokážete v kritické situaci rychle pochopit, co se pokazilo?
Když říkáme, že je obtížné udržovat Kubernetes - ne, je to velmi snadné a ano, je to neuvěřitelně obtížné. Kubernetes funguje skvěle sám o sobě, ale s miliardou nuancí.
O přístupu „budu mít štěstí“.
— Existují společnosti, kde se tyto nuance téměř zaručeně objeví? Předpokládejme, že Yandex náhle přenese všechny služby do Kubernetes, bude tam obrovské zatížení.
Dmitry: Ne, tohle není rozhovor o zátěži, ale o těch nejjednodušších věcech. Máme například Kubernetes, tam jsme aplikaci nasadili. Jak víš, že to funguje? Jednoduše neexistuje žádný hotový nástroj, který by pochopil, že aplikace nepadá. Neexistuje žádný hotový systém, který by zasílal výstrahy, je třeba tato upozornění a každý plán nakonfigurovat. A aktualizujeme Kubernetes.
Mám Ubuntu 16.04. Můžete říci, že je to stará verze, ale stále na ní máme, protože je to LTS. Existuje systemd, jehož nuance je v tom, že nečistí C-skupiny. Kubernetes spustí pody, vytvoří C-skupiny, pak vymaže pody a nějak se ukáže – nepamatuji si podrobnosti, promiň – že systemd slices zůstávají. To vede k tomu, že v průběhu času každé auto začne silně zpomalovat. To není ani otázka vysoké zátěže. Pokud jsou spuštěny permanentní moduly, například pokud existuje Cron Job, která neustále generuje moduly, pak se stroj s Ubuntu 16.04 začne po týdnu zpomalovat. Díky tomu, že se vytvořila hromada C-skupin, bude neustále vysoký průměr zatížení. To je problém, kterému bude čelit každý, kdo si jednoduše nainstaluje Ubuntu 16 a Kubernetes.
Řekněme, že nějak aktualizuje systemd nebo něco jiného, ale v linuxovém jádře do 4.16 je to ještě zábavnější – když smažete C-skupiny, uniknou v jádře a ve skutečnosti se nesmažou. Proto po měsíci práce na tomto stroji nebude možné se podívat na statistiky paměti pro ohniště. Vyjmeme soubor, natočíme ho v programu a jeden soubor se bude točit 15 sekund, protože jádru trvá velmi dlouho, než v sobě spočítá milion C-skupin, které se zdají být smazány, ale ne - unikají .
Takových drobností je tu a tam ještě spousta. To není problém, se kterým se někdy obří společnosti mohou potýkat při velmi velkém zatížení – ne, je to záležitost každodenních věcí. Lidé mohou takto žít měsíce – nainstalovali Kubernetes, nasadili aplikaci – zdá se, že to funguje. Pro mnoho lidí je to normální. Nebudou ani vědět, že tato aplikace z nějakého důvodu spadne, nedostanou upozornění, ale pro ně je to norma. Dříve jsme žili na virtuálních strojích bez monitorování, nyní jsme přešli na Kubernetes, také bez monitorování – jaký je v tom rozdíl?
Otázkou je, že když jdeme po ledu, nikdy nepoznáme jeho tloušťku, pokud si ji předem nezměříme. Mnoho lidí chodí a nebojí se, protože už šli.
Z mého pohledu je nuance a složitost ovládání jakéhokoli systému zajistit, aby tloušťka ledu byla přesně dostatečná k vyřešení našich problémů. To je to, o čem mluvíme.
Zdá se mi, že v IT existuje příliš mnoho přístupů typu „budu mít štěstí“. Mnoho lidí instaluje software a používá softwarové knihovny v naději, že budou mít štěstí. Obecně platí, že mnoho lidí má štěstí. Asi proto to funguje.
— Z mého pesimistického hodnocení to vypadá takto: když jsou rizika vysoká a aplikace musí fungovat, pak je potřeba podpora od Flauntu, možná od Red Hatu, nebo potřebujete vlastní interní tým věnovaný speciálně Kubernetes, který je připraven vytáhnout to.
Dmitry: Objektivně je to tak. Dostat se do příběhu Kubernetes pro malý tým vlastními silami s sebou nese řadu rizik.
Potřebujeme kontejnery?
— Můžete nám říci, jak rozšířený je Kubernetes v Rusku?
Dmitry: Tyto údaje nemám a nejsem si jistý, zda je má někdo jiný. Říkáme: „Kubernetes, Kubernetes“, ale existuje jiný způsob, jak se na tento problém podívat. Také nevím, jak rozšířené jsou kontejnery, ale znám údaj ze zpráv na internetu, že 70 % kontejnerů řídí Kubernetes. Byl to spolehlivý zdroj pro poměrně velký vzorek z celého světa.
Pak další otázka - potřebujeme kontejnery? Můj osobní pocit a celkový postoj firmy Flant je takový, že Kubernetes je de facto standard.
Nebude nic jiného než Kubernetes.
To je absolutní změna hry v oblasti správy infrastruktury. Prostě absolutní – to je ono, už žádný Ansible, Chef, virtuální stroje, Terraform. Nemluvím o starých metodách JZD. Kubernetes je absolutní změna, a teď to bude jen takhle.
Je jasné, že někomu to trvá pár let a jinému pár desetiletí, než si to uvědomí. Nepochybuji, že nebude nic jiného než Kubernetes a tento nový vzhled: již nepoškozujeme operační systém, ale používáme infrastruktura jako kód, jen ne s kódem, ale s yml - deklarativně popsaná infrastruktura. Mám pocit, že to tak bude pořád.
— To znamená, že ty společnosti, které ještě nepřešly na Kubernetes, na něj definitivně přejdou nebo zůstanou v zapomnění. pochopil jsem tě správně?
Dmitry: To také není úplně pravda. Pokud máme například za úkol provozovat DNS server, pak jej lze provozovat na FreeBSD 4.10 a může perfektně fungovat 20 let. Stačí pracovat a je to. Možná za 20 let bude potřeba jednou něco aktualizovat. Pokud se bavíme o softwaru ve formátu, který jsme spustili, a skutečně funguje mnoho let bez jakýchkoli aktualizací, bez provádění změn, tak samozřejmě žádný Kubernetes nebude. Není tam potřeba.
Vše, co souvisí s CI/CD – všude tam, kde je potřeba Continuous Delivery, kde potřebujete aktualizovat verze, provádět aktivní změny, kdekoli potřebujete vybudovat odolnost proti chybám – pouze Kubernetes.
O mikroslužbách
- Tady mám mírnou disonanci. Pro práci s Kubernetes potřebujete externí nebo interní podporu – to je první bod. Za druhé, když vývoj teprve začínáme, jsme malý startup, zatím nic nemáme, vývoj pro Kubernetes nebo architekturu mikroslužeb obecně může být složitý a ne vždy ekonomicky opodstatněný. Zajímá mě váš názor – potřebují startupy okamžitě začít psát pro Kubernetes od nuly, nebo mohou stále psát monolit a pak teprve přijít na Kubernetes?
Dmitry: Skvělá otázka. Mám tu řeč o mikroslužbách Mnohokrát jsem se setkal s lidmi, kteří se snažili zatlouct hřebíky mikroskopem. Samotný přístup je správný, sami si takto navrhujeme interní software. Ale když to uděláte, musíte jasně pochopit, co děláte. Slovo, které na mikroslužbách nesnáším nejvíc, je „mikro“. Historicky toto slovo vzniklo tam a z nějakého důvodu si lidé myslí, že mikro je velmi malé, méně než milimetr, jako mikrometr. To je špatně.
Například existuje monolit, který píše 300 lidí a každý, kdo se podílel na vývoji, chápe, že tam jsou problémy, a měl by být rozbit na mikrodíly - asi 10 dílků, z nichž každý píše 30 lidí v minimální verzi. To je důležité, potřebné a cool. Ale když k nám přijde startup, kde 3 velmi cool a talentovaní kluci napsali na koleně 60 mikroslužeb, pokaždé hledám Corvalola.
Zdá se mi, že se o tom již mluvilo tisíckrát - dostali jsme distribuovaný monolit v té či oné podobě. To není ekonomicky opodstatněné, je to obecně ve všem velmi těžké. Právě jsem to viděl tolikrát, že mě to opravdu bolí, takže o tom pokračuji.
Na úvodní otázku je rozpor mezi tím, že na jedné straně je Kubernetes děsivé používat, protože není jasné, co se tam může rozbít nebo nefunguje, na druhé straně je jasné, že tam všechno jde a nebude existovat nic jiného než Kubernetes . Odpovědět - zvažte množství přínosu, který přichází, množství úkolů, které můžete vyřešit. To je na jedné straně stupnice. Na druhé straně existují rizika spojená s prostoji nebo s poklesem doby odezvy, úrovně dostupnosti - s poklesem výkonnostních ukazatelů.
Tady to je – buď se pohybujeme rychle a Kubernetes nám umožňuje dělat mnoho věcí mnohem rychleji a lépe, nebo používáme spolehlivá, časem prověřená řešení, ale pohybujeme se mnohem pomaleji. To je volba, kterou musí udělat každá společnost. Můžete si to představit jako cestu v džungli - když jdete poprvé, můžete potkat hada, tygra nebo šíleného jezevce, a když jste šli 10krát, cestu jste prošlapali, odstranili větve a chodit snadněji. Pokaždé se cesta rozšíří. Pak je to asfaltka a později krásný bulvár.
Kubernetes nestojí na místě. Znovu otázka: Kubernetes je na jedné straně 4-5 binárních souborů, na druhé straně je to celý ekosystém. Toto je operační systém, který máme na našich strojích. co to je? Ubuntu nebo Curios? Toto je linuxové jádro, spousta dalších komponent. Všechny tyhle věci tady, jeden jedovatý had byl vyhozen ze silnice, byl tam postaven plot. Kubernetes se vyvíjí velmi rychle a dynamicky a objem rizik, objem neznámého se každým měsícem snižuje a podle toho se tyto váhy rebalancují.
V odpovědi na otázku, co by měl startup dělat, bych řekl – přijďte na Flaunt, zaplaťte 150 tisíc rublů a získejte jednoduchou službu DevOps na klíč. Pokud jste malý startup s několika vývojáři, funguje to. Namísto najímání vlastních DevOps, kteří se v tuto chvíli budou muset naučit řešit vaše problémy a platit mzdu, získáte řešení všech problémů na klíč. Ano, existují určité nevýhody. My jako outsourcing se nemůžeme tolik angažovat a rychle reagovat na změny. Máme ale spoustu odborných znalostí a hotových postupů. Garantujeme, že v každé situaci na to určitě rychle přijdeme a případné Kubernetese vzkřísíme z mrtvých.
Vřele doporučuji outsourcing startupům a zavedeným firmám do velikosti, kdy můžete provozům věnovat tým 10 lidí, protože jinak to nemá smysl. Rozhodně má smysl to outsourcovat.
O Amazonu a Google
— Lze hostitele z řešení od Amazonu nebo Google považovat za outsourcing?
Dmitry: Ano, samozřejmě, toto řeší řadu problémů. Ale opět jsou tu nuance. Stále musíte pochopit, jak jej používat. Například v práci Amazon AWS je tisíc drobností: Load Balancer je třeba zahřát nebo je třeba předem napsat požadavek, že „hoši, dostaneme provoz, zahřejte nám Load Balancer!“ Musíte znát tyto nuance.
Když se obrátíte na lidi, kteří se na to specializují, dostanete téměř všechny typické věci uzavřené. Nyní máme 40 inženýrů, do konce roku jich bude pravděpodobně 60 - se všemi těmito věcmi jsme se určitě setkali. I když se s tímto problémem na nějakém projektu znovu setkáme, rychle se ptáme jeden druhého a víme, jak jej vyřešit.
Pravděpodobně odpověď zní – hostovaný příběh samozřejmě některé části usnadňuje. Otázkou je, zda jste připraveni těmto hostitelům věřit a zda vyřeší vaše problémy. Amazon a Google si vedly dobře. Pro všechny naše případy - přesně. Pozitivnější zkušenosti nemáme. Všechny ostatní cloudy, se kterými jsme se snažili pracovat, vytvářejí spoustu problémů - Ager a vše, co je v Rusku, a všechny druhy OpenStack v různých implementacích: Headster, Overage - cokoli chcete. Všechny vytvářejí problémy, které nechcete řešit.
Proto je odpověď ano, ale ve skutečnosti neexistuje příliš mnoho vyspělých hostovaných řešení.
Kdo potřebuje Kubernetes?
— A přesto, kdo potřebuje Kubernetes? Kdo by již měl přejít na Kubernetes, kdo je typický klient Flaunt, který přichází speciálně pro Kubernetes?
Dmitry: To je zajímavá otázka, protože právě teď, po Kubernetes, k nám chodí mnoho lidí: "Kluci, my víme, že děláte Kubernetes, udělejte to pro nás!" Odpovídáme jim: "Pánové, neděláme Kubernetes, děláme prod a vše, co s tím souvisí." Protože v současné době je prostě nemožné vyrobit produkt, aniž bychom udělali všechny CI/CD a celý tento příběh. Všichni se vzdálili od rozdělení, že máme vývoj za vývojem a pak vykořisťování vykořisťováním.
Naši klienti očekávají různé věci, ale každý čeká na nějaký dobrý zázrak, že má určité problémy, a teď - hop! — Kubernetes je vyřeší. Lidé věří v zázraky. V duchu chápou, že se žádný zázrak nekoná, ale v duši doufají – co když za nás teď všechno vyřeší tenhle Kubernetes, tolik o tom mluví! Najednou teď - kýchnout! - a stříbrná kulka, kýchej! — a máme 100% dostupnost, všichni vývojáři mohou vydat cokoliv, co se dostane do produkce, 50krát a nespadne. Obecně platí, že zázrak!
Když k nám takoví lidé přijdou, říkáme: „Promiň, ale nic takového jako zázrak neexistuje.“ Abyste byli zdraví, musíte dobře jíst a cvičit. Aby byl produkt spolehlivý, musí být vyroben spolehlivě. Chcete-li mít pohodlný CI/CD, musíte to udělat takto. To je hodně práce, kterou je potřeba udělat.
Odpověď na otázku, kdo potřebuje Kubernetes - nikdo nepotřebuje Kubernetes.
Někteří lidé mají mylnou představu, že potřebují Kubernetes. Lidé potřebují, mají hlubokou potřebu přestat přemýšlet, studovat a zajímat se o všechny problémy infrastruktury a problémy s provozováním svých aplikací. Chtějí, aby aplikace jen fungovaly a jen se nasazovaly. Pro ně je Kubernetes nadějí, že přestanou slyšet příběh, že „tam jsme leželi“, „nemůžeme se rozjet“ nebo něco jiného.
Obvykle k nám chodí technický ředitel. Ptají se ho na dvě věci: na jednu stranu nám dej vlastnosti, na druhou stranu stabilitu. Doporučujeme, abyste to vzali na sebe a udělali to. Stříbrná kulka, nebo spíše postříbřená, je v tom, že na tyto problémy přestanete myslet a ztrácet čas. Budete mít speciální lidi, kteří toto téma uzavřou.
Formulace, že my nebo kdokoli jiný potřebuje Kubernetes, je nesprávná.
Správci Kubernetes opravdu potřebují, protože je to velmi zajímavá hračka, se kterou si můžete hrát a šťourat. Buďme upřímní – každý má rád hračky. Všichni jsme někde děti, a když vidíme nového, chceme si ho zahrát. Někoho to odradilo například v administraci, protože už mají odehráno dost a už jsou unavení tak, že se jim prostě nechce. To ale není nikomu úplně ztraceno. Pokud mě například už delší dobu omrzely hračky v oblasti správy systému a DevOps, tak ty hračky stále miluji, stále si kupuji nějaké nové. Všichni lidé, tak či onak, stále chtějí nějaké hračky.
Není třeba si hrát s výrobou. Cokoli kategoricky nedoporučuji nedělat a co teď hromadně vidím: "Ach, nová hračka!" - běželi si to koupit, koupili a: "Vezmeme to teď do školy a ukažme to všem našim přátelům." Nedělej to. Omlouvám se, moje děti teprve rostou, neustále na dětech něco vidím, všímám si toho na sobě a pak to zobecňuji na ostatní.
Konečná odpověď je: nepotřebujete Kubernetes. Potřebujete vyřešit své problémy.
Čeho můžete dosáhnout, je:
- prod nespadne;
- i když se pokusí spadnout, víme o tom předem a můžeme do toho něco dát;
- můžeme to změnit rychlostí, jakou to naše podnikání vyžaduje, a můžeme to udělat pohodlně; nečiní nám to žádné problémy.
Existují dvě skutečné potřeby: spolehlivost a dynamika/flexibilita zavádění. Každý, kdo v současné době dělá nějaké IT projekty, bez ohledu na to, v jakém byznysu - soft pro ulehčení světa, a kdo tomu rozumí, musí tyto potřeby řešit. Kubernetes se správným přístupem, správným porozuměním a dostatkem zkušeností je umožňuje řešit.
O bezserveru
— Pokud se podíváte trochu dále do budoucnosti, pak se pokusíte vyřešit problém absence bolestí hlavy s infrastrukturou, s rychlostí zavádění a rychlostí změn aplikací se objevují nová řešení, například bez serveru. Cítíte v tomto směru nějaký potenciál a řekněme nebezpečí pro Kubernetes a podobná řešení?
Dmitry: Tady je potřeba znovu poznamenat, že nejsem věštec, který se dívá dopředu a říká – bude to tak! I když jsem právě udělal to samé. Koukám na nohy a vidím tam hromadu problémů, třeba jak fungují tranzistory v počítači. Je to vtipné, že? Narážíme na nějaké chyby v CPU.
Udělejte bez serverů docela spolehlivý, levný, efektivní a pohodlný řešení všech problémů s ekosystémem. Zde souhlasím s Elonem Muskem, že k vytvoření odolnosti lidstva k chybám je zapotřebí druhá planeta. I když nevím, co říká, chápu, že já sám nejsem připraven letět na Mars a zítra se to nestane.
S bezserverem je jasně jasné, že jde o ideologicky správnou věc, jako je odolnost lidstva proti chybám – mít dvě planety je lepší než jednu. Ale jak to udělat teď? Vyslání jedné výpravy není problém, pokud na ni soustředíte své úsilí. Vyslání několika expedic a usazení několika tisíc lidí tam, myslím, je také reálné. Ale udělat to naprosto odolné proti chybám, aby tam žila polovina lidstva, se mi teď zdá nemožné, když se to nebere v úvahu.
S bezserverem jeden na jednoho: věc je skvělá, ale má daleko k problémům roku 2019. Blíž k roku 2030 – dožijme se toho. Nepochybuji o tom, že budeme žít, určitě budeme žít (opakovat před spaním), ale teď potřebujeme vyřešit jiné problémy. Je to jako věřit v pohádkového poníka Rainbow. Ano, pár procent případů je vyřešeno a jsou vyřešeny perfektně, ale subjektivně je serverless duha... Pro mě je toto téma příliš vzdálené a příliš nesrozumitelné. Nejsem připravený mluvit. V roce 2019 nemůžete napsat jednu aplikaci s bezserverem.
Jak se bude Kubernetes vyvíjet
— Jak se podle vás bude Kubernetes a ekosystém kolem něj vyvíjet, když se posuneme k této potenciálně nádherné vzdálené budoucnosti?
Dmitry: Hodně jsem o tom přemýšlel a mám jasnou odpověď. První je stavový – koneckonců bezstátní je jednodušší. Kubernetes do toho zpočátku investoval více, tím to všechno začalo. Stateless funguje v Kubernetes téměř dokonale, prostě není co vytknout. Stále existuje spousta problémů, nebo spíše nuancí. Všechno tam už nám funguje skvěle, ale to jsme my. Bude trvat ještě minimálně pár let, než to bude fungovat pro všechny. To není vypočítaný ukazatel, ale můj pocit z hlavy.
Stručně řečeno, statefull by se měl - a bude - vyvíjet velmi silně, protože všechny naše aplikace ukládají stav, neexistují žádné bezstavové aplikace. To je iluze; vždy potřebujete nějakou databázi a něco jiného. Statefull je o narovnání všeho, co je možné, opravě všech chyb, zlepšení všech problémů, se kterými se aktuálně potýkáme – říkejme tomu adopce.
Výrazně klesne míra neznáma, míra nevyřešených problémů, míra pravděpodobnosti, že se s něčím setkáme. Toto je důležitý příběh. A operátoři - vše, co souvisí s kodifikací logiky správy, logiky ovládání, abychom získali snadnou službu: snadná služba MySQL, snadná služba RabbitMQ, snadná služba Memcache - obecně všechny tyto komponenty, které musíme zaručeně vypracovat krabice. To jen řeší bolest, že chceme databázi, ale nechceme ji spravovat, nebo chceme Kubernetes, ale nechceme ji spravovat.
Tento příběh vývoje operátorů v té či oné podobě bude důležitý v příštích několika letech.
Myslím, že snadnost použití by se měla výrazně zvýšit - krabice bude stále více černá, stále spolehlivější, s více a více jednoduchými knoflíky.
Jednou jsem na YouTube na Saturday Night Live poslouchal starý rozhovor s Isaacem Asimovem z 80. let – pořad jako Urgant, jen zajímavý. Ptali se ho na budoucnost počítačů. Řekl, že budoucnost je v jednoduchosti, stejně jako rádio. Rozhlasový přijímač byl původně složitá věc. Abyste chytili vlnu, museli jste 15 minut otáčet knoflíky, otáčet špejlí a obecně vědět, jak všechno funguje, rozumět fyzice přenosu rádiových vln. Výsledkem bylo, že v rádiu zbyl pouze jeden knoflík.
Jaké rádio teď v roce 2019? V autě radiopřijímač najde všechny vlny a názvy stanic. Fyzika procesu se za 100 let nezměnila, ale snadnost použití ano. Teď a nejen teď, už v roce 1980, když byl rozhovor s Azimovem, všichni používali rádio a nikdo nepřemýšlel o tom, jak to funguje. Vždy to fungovalo – to je dané.
Azimov pak řekl, že to bude stejné s počítači - zvýší se snadnost použití. Zatímco v roce 1980 jste museli být naučení mačkat tlačítka na počítači, v budoucnu tomu tak nebude.
Mám pocit, že s Kubernetes a s infrastrukturou dojde také k obrovskému nárůstu jednoduchosti používání. To je podle mě zřejmé – leží to na povrchu.
Co dělat s inženýry?
— Co se pak stane s inženýry a správci systému, kteří podporují Kubernetes?
Dmitry: Co se stalo s účetní po příchodu 1C? O tom samém. Před tím se počítalo na papíře - nyní v programu. Produktivita práce vzrostla řádově, ale samotná práce nezmizela. Jestliže dříve zašroubování žárovky vyžadovalo 10 inženýrů, nyní bude stačit jeden.
Zdá se mi, že množství softwaru a počet úkolů nyní roste rychleji, než se objevují nové DevOps, a zvyšuje se efektivita. Právě teď je na trhu specifický nedostatek a bude trvat dlouho. Později se vše vrátí do jakéhosi normálu, ve kterém se zvýší efektivita práce, bude stále více bez serverů, ke Kubernetes se připojí neuron, který bude vybírat všechny zdroje přesně podle potřeby a obecně bude udělej všechno sám, jak má - ten člověk prostě odstoupí a nezasahuje.
Ale někdo bude muset stále rozhodovat. Je zřejmé, že úroveň kvalifikace a specializace tohoto člověka je vyšší. V dnešní době v účetním oddělení nepotřebujete 10 zaměstnanců, kteří by vedli účetnictví, aby se jim neunavily ruce. Jednoduše to není nutné. Mnoho dokumentů je automaticky naskenováno a rozpoznáno systémem elektronické správy dokumentů. Stačí jeden chytrý hlavní účetní, již s mnohem většími dovednostmi, s dobrým porozuměním.
Obecně je to cesta, kterou se dá jít ve všech odvětvích. S auty je to stejné: dříve bylo auto s mechanikem a třemi řidiči. Řízení auta je v dnešní době jednoduchý proces, kterého se každý den účastníme všichni. Nikdo si nemyslí, že auto je něco složitého.
DevOps nebo systémové inženýrství nikam nevedou – práce na vysoké úrovni a efektivita se zvýší.
— Slyšel jsem také zajímavou myšlenku, že práce skutečně přibude.
Dmitry: Samozřejmě na sto procent! Protože množství softwaru, který píšeme, neustále roste. Počet problémů, které řešíme pomocí softwaru, neustále roste. Množství práce roste. Nyní je trh DevOps strašně přehřátý. To je vidět na platových očekáváních. V dobrém slova smyslu, aniž bychom zacházeli do detailů, by měli být junioři, kteří chtějí X, střední, kteří chtějí 1,5X, a senioři, kteří chtějí 2X. A teď, když se podíváte na moskevský platový trh DevOps, junior chce od X do 3X a senior chce od X do 3X.
Nikdo neví, kolik to stojí. Úroveň platu se měří vaším sebevědomím – naprostý blázinec, upřímně řečeno, strašně přehřátý trh.
Tato situace se samozřejmě velmi brzy změní – k nějakému nasycení by mělo dojít. To není případ vývoje softwaru - navzdory skutečnosti, že každý potřebuje vývojáře a každý potřebuje dobré vývojáře, trh chápe, kdo za co stojí - průmysl se usadil. To v dnešní době není případ DevOps.
— Z toho, co jsem slyšel, jsem usoudil, že současný správce systému by se neměl příliš znepokojovat, ale je čas upgradovat své dovednosti a připravit se na to, že zítra bude více práce, ale bude to kvalifikovanější.
Dmitry: Stoprocentně. Obecně žijeme v roce 2019 a životní pravidlo je toto: celoživotní učení – učíme se celý život. Zdá se mi, že už to každý ví a cítí, ale nestačí to vědět - musíte to udělat. Každý den se musíme změnit. Pokud to neuděláme, dříve nebo později budeme odstaveni na okraj profese.
Připravte se na ostré zatáčky o 180 stupňů. Nevylučuji situaci, kdy se něco radikálně změní, vymyslí se něco nového - stane se. Poskok! - a teď jednáme jinak. Je důležité být na to připraven a nebát se. Může se stát, že zítra se všechno, co dělám, ukáže jako zbytečné – nic, celý život jsem studoval a jsem připraven se naučit něco dalšího. To není problém. Jistoty zaměstnání se není třeba bát, ale je potřeba být připraven se neustále učit něco nového.
Přání a minuta reklamy
- Máš nějaké přání?
Dmitry: Ano, mám několik přání.
První a obchodní – přihlaste se k odběru . Vážení čtenáři, přejděte na YouTube a odebírejte náš kanál. Zhruba za měsíc začneme s aktivním rozšiřováním video služby. Budeme mít spoustu vzdělávacího obsahu o Kubernetes, otevřeného a rozmanitého: od praktických věcí, až po laboratoře, až po hluboké základní teoretické věci a jak používat Kubernetes na úroveň principů a vzorců.
Druhé obchodní přání - jděte do a dát hvězdy, protože se jimi živíme. Pokud nám nedáte hvězdičky, nebudeme mít co jíst. Je to jako mana v počítačové hře. Něco děláme, děláme, zkoušíme, někdo říká, že to jsou hrozná kola, někdo, že je všechno úplně špatně, ale my pokračujeme a jednáme naprosto čestně. Vidíme problém, řešíme ho a sdílíme své zkušenosti. Dej nám proto hvězdu, neodejde od tebe, ale přijde k nám, protože se jimi živíme.
Třetí, důležité a již ne obchodní přání - přestaň věřit na pohádky. Jste profesionálové. DevOps je velmi seriózní a zodpovědná profese. Přestaňte si hrát na pracovišti. Ať vám to klikne a pochopíte to. Představte si, že přijdete do nemocnice a tam na vás doktor experimentuje. Chápu, že to může být pro někoho urážlivé, ale s největší pravděpodobností to není o vás, ale o někom jiném. Řekněte ostatním, aby také přestali. To nám všem opravdu ničí život – mnozí začnou jednat s operacemi, administrátory a DevOps jako s týpci, kteří zase něco rozbili. To se „zlomilo“ nejčastěji tím, že jsme šli hrát a nedívali se s chladným vědomím, že to tak je a je to tak.
To neznamená, že byste neměli experimentovat. Musíme experimentovat, děláme to sami. Abych byl upřímný, my sami někdy hrajeme hry - to je samozřejmě velmi špatné, ale nic lidského nám není cizí. Vyhlašme rok 2019 rokem seriózních, promyšlených experimentů a ne her na produkci. Pravděpodobně ano.
- Děkuji mnohokrát!
Dmitry: Děkuji ti, Vitaliji, jak za čas, tak za rozhovor. Vážení čtenáři, mnohokrát vám děkuji, pokud jste náhle dosáhli tohoto bodu. Doufám, že jsme vám přinesli alespoň pár myšlenek.
V rozhovoru se Dmitrij dotkl otázky werf. Nyní se jedná o univerzální švýcarský nůž, který řeší téměř všechny problémy. Ale nebylo tomu tak vždy. Na na festivalu Dmitrij Stolyarov vám o tomto nástroji podrobně řekne. ve zprávě bude tam všechno: problémy a skryté nuance Kubernetes, možnosti řešení těchto potíží a současná implementace werf v detailu. Přidejte se k nám 27. a 28. května, vytvoříme dokonalé nástroje.
Zdroj: www.habr.com