Před Vitalij Chabarov udělal rozhovor s Dmitrijem Stoljarem (), technickým ředitelem a spoluzakladatelem společnosti „Flant“. Vitalij se ptal Dmitrije, čím se „Flant“ zabývá, na Kubernetes, vývoj ekosystému, podporu. Diskutovali o tom, proč je Kubernetes potřebný a zda je vůbec nutný. Také o mikroservisech, Amazon AWS, přístupu „Mám štěstí“ v DevOps, budoucnosti samotného Kubernetes, proč, kdy a jak ovládne svět, perspektivách DevOps a na co by se měli inženýři připravit v blízké budoucnosti s zjednodušováním a neuronovými sítěmi.
ve formě podcastu si můžete poslechnout na DevOps Deflop — rusky mluveném podcastu o DevOps, a níže je textová verze.
Zde a dále otázky klade inženýr z Express42.
O „Flant“
— Dima, ahoj. Jsi technický ředitel „“ a také jeho zakladatel. Prosím, pověz nám, čím se společnost a ty v ní zabýváte?
Dmitrij: Na venek to vypadá, jako bychom byli takoví kluci, kteří chodí a všem instalují Kubernetes a něco s ním dělají. Ale to není pravda. Začínali jsme jako společnost, která se zabývala Linuxem, ale už velmi dlouho je naší hlavní činností zajištění chodu produkčních a high-load projektů na klíč. Obvykle budujeme celou infrastrukturu od nuly a poté ji dlouho spravujeme. Proto je hlavní prací, kterou „Flant“ vykonává, za což také dostáváme zaplaceno — to je přebírání odpovědnosti a realizace produkce na klíč.
Jako technický ředitel a jeden ze spoluzakladatelů společnosti se neustále zabývám tím, jak zvýšit dostupnost produkce, zjednodušit její provoz, ulehčit život administrátorům a zpříjemnit život vývojářům.
O Kubernetes
— V poslední době vidím od „Flantu“ hodně přednášek a o Kubernetes. Jak jste se k němu dostali?
Dmitrij: O tom jsem již mnohokrát vyprávěl, ale vůbec mi není líto to zopakovat. Považuji za správné tuto tématiku opakovat, protože dochází k záměně příčiny a následku.
Potřebovali jsme nástroj. Setkávali jsme se s mnoha problémy, bojovali jsme s nimi, překonávali je různými improvizovanými řešeními a cítili jsme potřebu nástroje. Prozkoumali jsme mnoho různých variant, vytvářeli své vlastní verze a sbírali zkušenosti. Postupně jsme dospěli k tomu, že jsme začali používat Docker téměř ihned po jeho vzniku – přibližně v roce 2013. V době jeho vzniku jsme již měli hodně zkušeností s kontejnery, už jsme napsali obdobu „Dockeru“ – nějaké naše improvizované řešení na Pythonu. S příchodem Dockeru jsme měli možnost tyto improvizace zahodit a použít spolehlivé a komunitně podporované řešení.
S Kubernetes je to podobné. V době, kdy začal nabírat na síle – pro nás verze 1.2 – jsme již měli spoustu improvizovaných řešení jak na Shell, tak na Chef, které jsme se snažili orchestrací pro Docker. Závažně jsme zvažovali Rancher a různá další řešení, ale pak se objevil Kubernetes, v němž je vše realizováno přesně tak, jak bychom to udělali my, možná i lépe. Není co vytknout.
Ano, tady je nějaký nedodělek, tam je nějaký nedodělek – spousta nedodělků, a verze 1.2 je vůbec hrozná, ale… Kubernetes je jako budova v průstavbě – díváte se na projekt a chápete, že to bude skvělé. Pokud má budova nyní základ a dvě patra, chápete, že je lepší se zatím neosidlovat, ale s softwarem takové problémy nejsou – již se dá používat.
Neměli jsme moment, kdybychom zvažovali, zda použít Kubernetes či nikoli. Čekali jsme na něj dlouho předtím, než se objevil, a snažili se sami vytvořit analogie.
Kubernetes
— Účastníte se přímo vývoje samotného Kubernetes?
Dmitrij: Nepřímo. Spíše se podílíme na rozvoji ekosystému. Odesíláme nějaké množství pull requestů: do Prometheus, do různých operátorů, do Helm – do ekosystému. Bohužel, nejsem schopen sledovat vše, co děláme, a mohu se mýlit, ale od nás není ani jeden pull request do jádra.
— Přitom vy vyvíjíte i mnoho svých nástrojů kolem Kubernetes?
Dmitrij: Strategie je taková: jdeme a odesíláme pull requesty všude, kde to už je. Pokud tam pull requesty nejsou přijímány, prostě si je forkneme k sobě a žijeme, dokud nejsou přijaty s našimi buildy. Poté, když to doletí k upstream, vracíme se zpět na upstreamovou verzi.
Například máme Prometheus operátora, se kterým jsme se už asi pětkrát překlikávali na upstream naší sestavy. Potřebujeme nějakou funkci, poslali jsme pull request, chceme ji nasadit zítra, ale čekat, až ji uvolní do upstreamu, se nám nechce. Takže si sestavíme vlastní verzi s potřebnou funkcí a nasadíme ji na všechny naše clustery. Pak to například v upstreamu zabalí s návrhem: „Kluci, pojďme to udělat pro obecnější případ,“ a my, nebo někdo jiný, to doděláme, a nakonec se to opět sloučí zpět.
Všechno, co existuje, se snažíme rozvíjet.. Mnoho prvků, které ještě neexistují, nebylo vymysleno nebo bylo vymyšleno, ale nebylo realizováno – ty děláme. A ne proto, že nás baví samotný proces nebo stavění bicyklů jako obor, ale prostě proto, že tento nástroj potřebujeme. Často se nás ptají, proč jsme udělali to či ono? Odpověď je jednoduchá – protože jsme museli jít dál, vyřešit nějaký praktický problém, a tento problém jsme vyřešili tímto nástrojem.
Cesta je vždy taková: velmi pečlivě hledáme a pokud nenajdeme žádné řešení, jak z bochníku chleba udělat trolejbus, vyrobíme si svůj bochník a svůj trolejbus.
Nástroje Flanty
— Vím, že nyní má Flanta addon operátory, shell operátory, nástroje dapp/werf. Jak chápu, je to stejný nástroj v různých inkarnacích. Také chápu, že uvnitř Flanty je ještě mnoho různých nástrojů. Je to tak?
Dmitrij: Na GitHubu máme ještě spoustu dalších věcí. Z toho, co si teď pamatuji, máme statusmap – panel pro Grafanu, který si získal všechny. Zmiňuje se téměř v každém druhém článku o monitorování Kubernetes na Mediumu. Není možné to stručně popsat, co statusmap je – potřebujeme na to 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 zobrazit stav v čase. Také máme LogHouse – to je věc na bázi ClickHouse a černé magie pro sběr logů v Kubernetes.
Mnoho utilit! A bude jich ještě více, protože určité interní řešení bude vydáno tento rok. Z velmi velkých, na základě addon operátora, existuje spousta addonů pro Kubernetes, například jak správně nainstalovat certifikát manager – nástroj pro správu certifikátů, jak správně nainstalovat Prometheus s celou řadou doplňků – to jsou desítky různých binárních souborů, které exportují data a něco shromažďují, k tomu Prometheus má skvělou grafiku a alerty. To vše jsou vlastně spousty addonů pro Kubernetes, které se instalují do clusteru, a tím se proměňuje z jednoduchého na výkonnější, sofistikovaný a automatizovaný, ve kterém je mnoho problémů již vyřešeno. Ano, děláme hodně.
Rozvoj ekosystému
— Myslím, že to je velmi velký příspěvek k rozvoji tohoto nástroje a jeho metod použití. Můžeš nějak odhadnout, kdo by ještě přispěl stejným způsobem k rozvoji ekosystému?
Dmitrij: V Rusku z těch společností, které působí na našem trhu – nikdo ani zdaleka. Samozřejmě, to je silné vyjádření, protože tu jsou velcí hráči, jako Mail s Yandexem – ti také něco dělají s Kubernetes, ale ani oni se ani zdaleka nepřiblížili k příspěvkům společností po celém světě, které dělají mnohem víc než my. Těžko se srovnává „Flant“ s týmem o 80 lidech a Red Hat, ve kterém je pouze na jedno Kubernetes 300 inženýrů, pokud se nepletu. Je obtížné srovnávat. U nás v oddělení RnD je 6 lidí včetně mě, kteří vyvíjejí všechny naše nástroje. 6 lidí proti 300 inženýrům Red Hat – takové srovnání je složité.
— Přesto, když i těchto 6 lidí dokáže udělat něco opravdu užitečného a přenosného, když se setkají s praktickým úkolem a předají řešení komunitě – to je zajímavý případ. Chápu, že ve velkých technologických společnostech, kde mají vlastní vývoj a tým podpory Kubernetes, by také mohly být vyvíjeny podobné nástroje. To je pro ně příklad, že je možné vyvinout nástroj a předat ho komunitě, což udělá impuls pro celou komunitu, která používá Kubernetes.
Dmitrij: Je to pravděpodobně zvláštnost integrátora, jeho odlišnost. V našem případě máme mnoho projektů a vidíme různé situace. Hlavní způsob, jak vytváříme přidanou hodnotu, je analyzovat tyto případy, najít společné rysy a co nejvíce je zlevnit. Tím se aktivně zabýváme. O Rusku a světě mohu hovořit obtížně, ale máme přibližně 40 DevOps inženýrů, kteří se věnují Kubernetes. Nemyslím si, že v Rusku existuje mnoho firem srovnatelného počtu specialistů, kteří se vyznají v Kubernetes, pokud vůbec nějaké jsou.
Rozumím všemu ohledně názvu pozice DevOps inženýr, všichni to chápou a zvyklí nazývat DevOps inženýry DevOps inženýry, o tom se bavit nebudeme. Všech těchto 40 skvělých DevOps inženýrů se každý den setkává s problémy a řeší je, my jen analyzujeme tuto zkušenost a snažíme se ji generalizovat. Chápeme, že pokud to zůstane uvnitř, za rok nebo dva bude nástroj k ničemu, protože někde v komunitě se objeví hotový nástroj. Není smysl hromadit tuto zkušenost uvnitř — to je jen vyplývání sil a času do dev/null. Proto nám není líto. S velkou radostí vše publikujeme a chápeme, že je třeba to publikovat, rozvíjet, propagovat, aby lidé používali a přidávali své zkušenosti — pak vše roste a žije. Tehdy za dva roky nástroj nekončí na smetišti. Nepohne nás pokračovat v investování sil, protože je vidět, že někdo tvůj nástroj používá, a za dva roky už ho používají všichni.
To je součást naší velké strategie s dapp/werf. Nepamatuji se, kdy jsme ho začali dělat, zdá se, že před třemi lety. Původně byl vůbec na shellu. Bylo to skvělé proof of concept, vyřešili jsme nějaké naše soukromé úkoly — povedlo se! Ale se shellem jsou tam problémy, dál to není možné rozvíjet, programovat v shellu je tak trochu činnost. Měli jsme zvyk psát v Ruby, a tak jsme něco předělali, rozvíjeli, rozvíjeli, a narazili jsme na to, že komunita, zástupci, kteří neříkají "chceme nebo nechceme", kroutí nos od Ruby, jak to není směšné. Pochopili jsme, že to všechno musíme psát v Go, abychom jednoduše splnili první bod v kontrolním seznamu: DevOps nástroj by měl být statickým binárním souboremNa Go nebo ne na Go není tak důležité, ale je lepší mít statický binární soubor napsaný v Go.
Vynaložili jsme úsilí a přepracovali dapp na Go a nazvali ho werf. Dapp už není podporován, nevyvíjí se, funguje v nějaké poslední verzi, ale existuje absolutní cesta ke zlepšení, kterou lze sledovat.
Proč byl dapp vytvářen
— Můžeš stručně říct, proč byl dapp vytvářen, jaké problémy řeší?
Dmitrij: První důvod je ve stavbě. Původně jsme měli vážné problémy se stavbou, když Docker neuměl multi-stage, a my jsme vytvořili multi-stage vlastními silami. Pak jsme měli ještě spoustu otázek s úklidem obrazů. Všichni, kdo dělají CI/CD, se spíše dříve než později setkávají s problémem, že existuje spousta vytvořených obrazů, a je potřeba nějak vyčistit to, co není potřeba, a nechat to, co je potřeba.
Druhý důvod je v nasazení. Ano, existuje Helm, ale ten řeší pouze část úkolů. Jak vtipně, je napsáno, že "Helm - správce balíčků pro Kubernetes". Přesně, že "the". Jsou tu ještě slova "správce balíčků" - jaká jsou obvykle očekávání od správy balíčků? Říkáme: "Správce balíčků - nainstaluj balíček!" a očekáváme, že nám řekne: "Balíček je nainstalován."
Zajímavé je, že říkáme: "Helm, nainstaluj balíček", a když odpoví, že nainstaloval, zjistí se, že teprve začal instalaci - ukázal Kubernetes: "Tento kousek spusť!", a zda byl spuštěn nebo ne, zafungoval či ne, Helm tuto otázku vůbec neřeší.
Tak se tedy ukazuje, že Helm je jen textový preprocessore, který načítá data do Kubernetes.
Ale v rámci jakéhokoliv nasazení chceme vědět - aplikace byla nasazena do produkce či nikoli? Nasazena do produkce znamená, že aplikace se tam dostala, byla nasazena nová verze a ta tam minimálně nespadne a správně odpovídá. Helm tuto úlohu vůbec neřeší. Abychom ji vyřešili, je nutné vynaložit spoustu úsilí, protože je třeba dát Kubernetes příkaz k nasazení a sledovat, co se tam děje - zda se nasadilo, zda bylo vydáno. A ještě je potřeba vyřešit spoustu úkolů, které souvisejí s nasazením, úklidem, se stavbou.
Plány
Ještě letos se pustíme do lokálního vývoje. Chceme dosáhnout toho, co bylo dříve ve Vagrant – zadali jsme "vagrant up" a naše virtuální stroje se rozběhly. Chceme dosáhnout stavu, kdy máme projekt na Git, napíšeme tam "werf up" a to zvedne lokální kopii tohoto projektu, nasazenou v lokálním mini-Kub, se všemi připojenými adresáři, které jsou vhodné pro vývoj. V závislosti na jazyce vývoje to probíhá různými způsoby, ale přesto, aby bylo možné pohodlně vést lokální vývoj s namontovanými soubory.
Další krok pro nás je výrazně investovat do pohodlí pro vývojáře. Aby bylo možné jedním nástrojem rychle lokálně nasadit projekt, vyvinout, poslat do Git, a ten se stejně tak nasadí na staging nebo do testů, v závislosti na pipeline, a pak stejným nástrojem přejít na produkci. Tato jednotnost, unifikace, reprodukovatelnost infrastruktury od lokálního prostředí až po produkci je pro nás velmi důležitým bodem. Ale to zatím ve werf není – jen to plánujeme.
Ale cesta k dapp/werf byla vždy podobná, jako ta s Kubernetes na začátku. Narazili jsme na problémy, řešili je alternativními cestami – vymýšleli jsme si nějaká řešení na shellu, na čemkoliv. Potom jsme se snažili tyto alternativní cesty nějak zjednodušit, zobecnit a konsolidovat do binárek, které pak prostě sdílíme.
Existuje ještě jiný pohled na celou tuto historii, s analogiemi.
Kubernetes je rám auta s motorem. Není tam žádné dveře, skla, rádio, ani vonná tyčinka – vůbec nic. Jen rám a motor. A je tu Helm – to je volant. Super – volant je, ale potřebujeme ještě řízení, řízení, převodovku a kola, a bez nich to nejde.
V případě werf – to je další komponenta k Kubernetes. Jen nyní máme v alfa verzi werf, kde se například Helm vůbec kompiluje dovnitř werf, protože nás už nebaví to dělat sami. Důvodů, proč jsme to udělali, a podrobně o tom, proč jsme zkompilovali Helm spolu s tiller dovnitř werf, vám řeknu právě .
Nyní je werf více integrovanou součástí. Dostáváme hotový volant, řízení — nejsem moc zdatný v automobilech, ale je to velký blok, který řeší už dost široké spektrum úkolů. Nemusíme sami procházet katalog, vybírat si jednotlivé díly, přemýšlet, jak je k sobě připevnit. Dostáváme hotový kombajn, který okamžitě řeší velké množství úkolů. Ale uvnitř je stále postaven ze stejných open-source komponent, stále používá Docker pro sestavení, Helm pro část funkcionality, a je tu ještě několik dalších knihoven. Je to integrovaný nástroj, aby bylo možné rychle a pohodlně získat skvělý CI/CD z krabice.
Je obtížné udržovat Kubernetes?
— Mluvíš o zkušenostech, že jste začali používat Kubernetes, že to je pro vás rám, motor, a že na to lze připevnit různé součásti: karoserii, volant, připevnit pedály, sedadla. Vzniká otázka — jak těžké je pro vás udržování Kubernetes? Máte bohaté zkušenosti, kolik času a zdrojů věnujete konkrétně udržování Kubernetes od ostatních věcí?
Dmitrij: To je velmi složitá otázka a abychom mohli odpovědět, musíme pochopit, co je podpora, a co chceme od Kubernetes. Můžeš to objasnit?
— Jak mě informovali a jak vidím, nyní mnoho týmů chce zkusit Kubernetes. Všichni se do toho pouštějí, instalují ho na koleni. Mám pocit, že lidé ne vždy chápou složitost tohoto systému.
Dmitrij: Přesně tak.
— Jak těžké je vzít a nainstalovat Kubernetes z ničeho, aby to bylo připravené na produkci?
Dmitrij: Jak si myslíš, jak těžké je transplantovat srdce? Chápu, otázka je provokativní. Opatrně použít skalpel a neudělat chybu — to není tak těžké. Pokud ti řeknou, kde odříznout a kde zašít, tak samotný postup není složitý. Složitější je zaručit, že to vyjde pokaždé.
Nainstalovat Kubernetes a donutit ho fungovat je jednoduché: šup! — nainstaloval se, existuje spousta způsobů instalace. Ale co se stane, když nastanou problémy?
Vždy se objevují otázky — co jsme ještě nezohlednili? Co jsme ještě neudělali? Jaké parametry jádra Linuxu jsme zadali špatně? Bože, zadali jsme je vůbec?! Jaké komponenty Kubernetes jsme nainstalovali a jaké ne? Objevují se tisíce otázek, a abychom na ně odpověděli, je potřeba 15-20 let se pohybovat v tomto odvětví.
Mám čerstvý příklad na toto téma, který může objasnit problém "Je těžké spravovat Kubernetes?". Před nějakým časem jsme vážně uvažovali, zda bychom měli vyzkoušet zavést Cilium jako síť v Kubernetes.
Vysvětlím, co je Cilium. V Kubernetes existuje mnoho různých implementací síťového subsystému a jedna z nich je velmi zajímavá – to je Cilium. Jaký je její smysl? V jádru se před nějakou dobou objevila možnost psát háčky pro jádro, které zasahují do síťového subsystému a dalších různých subsystémů a umožňují obejít velké části jádra.
V linuxovém jádru historicky existují ip rout, netfiltry, mosty a mnoho různých starých komponent, kterým je 15, 20 i 30 let. V zásadě fungují, vše je skvělé, ale v současnosti jsme postavili spoustu kontejnerů, a to vypadá jako věž ze 15 cihel jedna na druhé, a ty na ní stojíš na jedné noze – zvláštní pocit. Tento systém historicky vyvíjel s mnoha nuancemi, podobně jako apendix v organismu. V některých situacích jsou s výkonem problémy, například.
Existuje úžasný BPF a možnost psát háčky pro jádro – kluci napsali své vlastní háčky pro jádro. Paket přichází do linuxového jádra, oni ho přímo na vstupu vytahují, zpracovávají podle potřeby bez mostů, bez TCP, bez IP zásobníku – zkrátka, obejdou vše, co je napsáno v linuxovém jádře, a hned ho vyplyvnou do kontejneru.
Co se stalo? Velmi skvělý výkon, úžasné funkce – prostě super! Ale díváme se na to a vidíme, že na každém stroji běží program, který se připojuje k API Kubernetes a na základě dat, které získá z tohoto API, generuje C kód a kompiluje binární soubory, které nahrává do jádra, aby tyto háčky pracovaly v kernel space.
Co se stane, když něco nevyjde? Nevíme. Abychom to pochopili, musíme přečíst celý ten kód, pochopit celou logiku, a to je neskutečně složité. Ale na druhé straně, jsou tu ty mosty, netfiltry, ip rout – já jsem jejich zdrojové kódy nečetl, a 40 inženýrů, kteří pracují v naší společnosti také ne. Možná, že některé kousky chápou jen jednotlivci.
A jaký je rozdíl? Ukazuje se, že máme ip rout, jádro Linuxu a je tu nový nástroj - jaký je v tom rozdíl, obě možnosti nerozumíme. Ale bojíme se použít to nové - proč? Protože pokud má nástroj 30 let, za těch 30 let byly nalezeny všechny chyby, na všechny úskalí jsme narazili a není třeba o všem vědět - funguje to jako černá skříňka a funguje to vždy. Všichni ví, kterou diagnostickou šroubovák do které díry vložit, který tcpdump v jakém okamžiku spustit. Všichni dobře znají diagnostické nástroje a rozumí tomu, jak soubor komponentů pracuje v jádru Linuxu - ne jak je to postaveno, ale jak to používat.
A skvělému Ciliu není 30 let, ještě není zralé. Stejný problém máme s Kubernetes; je to kopie. Jak Cilium, tak Kubernetes se instalují skvěle, ale když něco nepůjde podle plánu v produkci, jste schopni rychle pochopit, co se stalo v kritické situaci?
Když mluvíme o tom, zda je těžké udržovat Kubernetes - ne, je to velmi jednoduché, a ano, je to neuvěřitelně složité. 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ěř garantovaně objeví? Představme si, že Yandex náhle přenese všechny své služby na Kubernetes, bude to obrovská zátěž.
Dmitrij: Ne, tohle není rozhovor o zátěži, ale o nejjednodušších věcech. Například máme Kubernetes, nasadili jsme tam aplikaci. Jak zjistit, že funguje? Není k dispozici žádný hotový nástroj, který by ukázal, že aplikace neklesá. Neexistuje hotový systém, který posílá upozornění - musíme nastavit tato upozornění a každý graf. A my právě aktualizujeme Kubernetes.
Máte Ubuntu 16.04. Můžeme říci, že je to stará verze, ale stále na ní jsme, protože je to LTS. Obsahuje systemd, jehož nuance spočívá v tom, že nečistí C-skupiny. Kubernetes spouští pody, vytváří C-skupiny, pak pody odstraňuje a nějak tak dochází k tomu – nepamatuji si detaily, omlouvám se – že zůstávají kusy systemd. To způsobuje, že s časem jakýkoli stroj začne silně zpožďovat. Neboť to není ani otázka highload. Pokud se spouští stálé pody, například jestli je Cron Job, který neustále generuje pody, tak stroj s Ubuntu 16.04 začne po týdnu zpomalovat. Bude mít neustále vysoký load average, protože byla vytvořena spousta C-skupin. To je problém, se kterým se setkává kdokoli, kdo si jen nainstaluje Ubuntu 16 a nad to Kubernetes.
Představme si, že nějak aktualizuje systemd nebo něco jiného, ale v jádře Linuxu do 4.16 je to ještě vtipnější – při odstraňování C-skupin se v jádře projevují a v podstatě se neodstraňují. Proto po měsíci práce na tomto stroji nebude možné podívat se na statistiky paměti podle podů. Vytahujeme soubor, otáčíme ho v programu a jeden soubor se otáčí 15 sekund, protože jádro velmi dlouho počítá uvnitř sebe milion C-skupin, které sice byly odstraněny, ale ne – ony se projevují.
Takových maličkostí je stále velmi mnoho tam a tady. To není otázka, s kterou se mohou obří společnosti někdy setkat při velmi vysokých zátěžích – ne, to je otázka každodenních věcí. Lidé mohou žít měsíce takto – nainstalovali Kubernetes, nasadili aplikaci – vypadá to, že funguje. Mnohým to tak vyhovuje. O tom, že tato aplikace jednou z nějakého důvodu spadne, se ani nedozvědí, upozornění nedojde, ale pro ně je to norma. Dříve žili na virtuálních strojích bez monitorování, nyní přešli na Kubernetes také bez monitorování – jaký je rozdíl?
Otázkou je, že když kráčíme po ledu, nikdy nevíme jeho tloušťku, pokud jsme to předem nezměřili. Mnozí chodí a nestarají se, protože dříve chodili.
Z mého pohledu spočívá nuance a složitost provozu jakéhokoli systému v tom, abychom zajistili, že tloušťka ledu je přesně dostatečná k vyřešení našich úloh. O tom to je.
V IT je podle mě příliš mnoho přístupů ''Bude mi přát štěstí''. Mnozí instalují software, používají knihovny v naději, že jim štěstí přinese. Celkově se mnohým daří. Pravděpodobně proto to funguje.
— Z mé pesimistické perspektivy to vypadá takto: když jsou rizika vysoká a aplikace musí fungovat, je potřeba podpora od „Flant“, možná od Red Hat, nebo je zapotřebí vlastní interní tým, který se věnuje přímo Kubernetes a je připraven ho spravovat.
Dmitrij: Objektivně je to pravda. Vstupovat samostatně do problematiky Kubernetes s malým týmem — to představuje určité množství rizik.
Potřebujeme kontejnery?
— Můžeš říct, jak rozšířený je Kubernetes v Rusku?
Dmitrij: Nemám tato data a nejsem si jistý, zda je má opravdu někdo. Říkáme: ''Kubernetes, Kubernetes'', ale existuje jiný pohled na tuto otázku. Jak jsou rozšířené kontejnery, to také nevím, ale znám číslo z internetových zpráv, že 70 % kontejnerů orchestruje Kubernetes. To byl důvěryhodný zdroj na dost velkém vzorku z celého světa.
Další otázka je — potřebujeme vůbec kontejnery? Mám osobní pocit a celkově pozici společnosti „Flant“, že Kubernetes je de facto standard.
Nic jiného než Kubernetes nebude.
To je absolutní game-changer v oblasti správy infrastruktury. Prostě absolutní — už žádný Ansible, Chef, virtuální stroje, Terraform. O starých provizorních metodách už ani nemluvím. Kubernetes je absolutní changer, a nyní to bude jen tak.
Je jasné, že někomu může trvat pár let, jinému pár desítek, než si to uvědomí. Nemám žádné pochybnosti, že kromě Kubernetes a tohoto nového pohledu nic jiného nebude: už nezapínáme operační systém, ale používáme infrastructure as code, jen ne s kódem, ale s yml — deklarovanou infrastrukturou. Mám pocit, že to tak bude vždy.
— Takže ty společnosti, které ještě nepřešly na Kubernetes, nutně na něj přejdou, nebo zůstanou zapomenuty. Rozumím tě správně?
Dmitrij: To také není úplně pravda. Například, pokud máme úkol spustit DNS server, můžeme ho spustit na FreeBSD 4.10 a ten může bez problémů fungovat 20 let. Jen fungovat a to je vše. Možná, že za 20 let bude potřeba něco jednou aktualizovat. Pokud hovoříme o softwaru v tom smyslu, že jsme ho spustili a on reálně funguje mnoho let bez nějakých aktualizací, bez změn, pak tam samozřejmě nebude Kubernetes. Ten tam není potřeba.
Vše, co se týká CI/CD — všude, kde potřebujete Continuous Delivery, kde je třeba aktualizovat verze, provádět aktivní změny, všude, kde je nutné vybudovat odolnost proti výpadkům — jen Kubernetes.
O mikroslužbách
— Tady mám malý disonance. Aby bylo možné pracovat s Kubernetes, potřebujete externí nebo interní podporu — to je první věc. Druhá — když teprve začínáme s vývojem, jsme malý startup, nemáme ještě nic, vývoj pro Kubernetes nebo vůbec pro mikroslužbovou architekturu může být složitý a ekonomicky ne vždy oprávněný. Zajímá mě tvůj názor — měly by startupy hned od začátku psát pro Kubernetes, nebo je možné nejdříve napsat monolit a teprve potom přejít k Kubernetes?
Dmitrij: Skvělá otázka. Mám přednášku o mikroslužbách. Mnohokrát jsem se setkal s tím, že lidé se snaží zatloukat hřebíky mikroskopem. Samotný přístup je správný, my sami navrhujeme interní software tímto způsobem. Ale když to děláte, musíte jasně rozumět, co děláte. Nejvíce nenávidím slovo „mikro“ v mikroslužbách. Historicky se to slovo tam objevilo a z nějakého důvodu lidé si myslí, že mikro — to je velmi malé, menší než milimetr, jako mikrometr. To není pravda.
Například existuje monolit, který píše 300 lidí, a všichni, kdo se podíleli na vývoji, vědí, že tam jsou problémy, a je třeba ho rozdělit na mikroskopické kusy — asi 10, přičemž každý z nich píše minimálně 30 lidí. To je důležité, potřebné a skvělé. Ale když k nám přijde startup, kde 3 velmi schopní a talentovaní kluci napsali na koleni 60 mikroslužeb, každou chvíli hledám korvalol.
Myslím, že o tom už bylo řečeno tisíckrát — dostali jsme distribuovaný monolit v jedné nebo druhé podobě. Je to ekonomicky neudržitelné, velmi složité vůbec ve všem. Jen jsem to viděl tolikrát, že mě to doslova bolí, proto o tom stále mluvím.
K počáteční otázce, že existuje konflikt mezi tím, že z jedné strany je Kubernetes strašné používat, protože není jasné, co se může porouchat nebo nefungovat, a z druhé strany je zřejmé, že všechno směřuje tam a nic kromě Kubernetes nebude. Odpověď je — zvážit objem přínosu, který přichází, a objem úkolů, které můžete vyřešit. To je na jedné straně vah. Na druhé straně — rizika, která souvisejí s prostojem nebo s poklesem doby odezvy, úrovně dostupnosti — s poklesem výkonnostních ukazatelů.
Tady to je tak — buď se rychle pohybujeme, a Kubernetes umožňuje mnohé věci dělat mnohem rychleji a lépe, nebo používáme spolehlivá, léty prověřená řešení, ale pohybujeme se mnohem pomaleji. Toto rozhodnutí by měly učinit každé společnosti. Můžete to považovat za stezku v džungli — když jdete poprvé, můžete potkat hada, tygra nebo zuřivého jezevčíka, a když jdete 10krát — vyšlapete si cestu, odstraníte větve a jde to lépe. S každým dalším krokem je stezka širší. Později je to už asfaltová cesta, a později krásná třída.
Kubernetes nestojí na místě. Opět otázka: Kubernetes, z jedné strany, to jsou 4-5 binárek, z druhé strany — to je celý ekosystém. To je operační systém, který máme na strojích. Co to je? Ubuntu nebo Curios? To je jádro Linuxu, spousta dalších komponentů. Všechny tyto věci tu jednu jedovatou zmiji vyhodili z cesty, tam postavili plot. Kubernetes se velmi rychle a dynamicky vyvíjí, a objem rizik, objem neznáma s každým měsícem klesá a, podle toho, tyto váhy se přebalancovávají.
Když odpovídám na otázku, co dělat se startupem, řekl bych – přijděte k "Flantu", zaplaťte 150 tisíc rublů a získejte DevOps easy service na klíč. Pokud jste malý startup s několika vývojáři – to funguje. Místo najímání vlastního DevOps, který se musí učit, jak řešit vaše problémy, a platit mu v tuto dobu mzdu, obdržíte řešení všech otázek na klíč. Ano, jsou tam některé nevýhody. Jako outsourcer nemůžeme být tak zapojeni a rychle reagovat na změny. Ale máme spoustu odbornosti, hotové praktiky. Zaručujeme, že v jakékoli situaci rychle vyřešíme a znovu vyvedeme na světlo každý Kubernetes.
Kategorie důrazně doporučuji outsourcing startupům a ustáleným podnikům, dokud nedosáhnete velikosti, kdy můžete vyčlenit na provoz tým deseti lidí, protože jinak to nedává smysl. To dává smysl každý z pohledu outsourcingu.
O Amazonu a Googlu
– Lze řešit jako outsourcing hosting od řešení od Amazonu nebo Googlu?
Dmitrij: Ano, určitě, to řeší určitou část otázek. Ale znovu, jsou tu nuanse. Pořád je třeba pochopit, jak to používat. Například v práci Amazon AWS je tisíc drobností: Load Balancer je třeba zahřát nebo předem napsat žádost, že "chlapi, přijdou nám provoz, zahřejte nám Load Balancer!" Tyto nuance je třeba znát.
Když se obracíte na lidi, kteří se na to specializují, získáte téměř všechny typové věci uzavřené. V současnosti máme 40 inženýrů, na konci roku to bude pravděpodobně 60 – určitě jsme se s těmito věcmi setkali. I když se na nějakém projektu znovu setkáváme s tímto problémem, rychle se jeden druhého ptáme a víme, jak to vyřešit.
Odpověď je taková – samozřejmě, hosted historie usnadňuje určitou část. Otázka je, zda jste připraveni důvěřovat těmto hostitelům, a zda vyřeší vaše problémy. Amazon a Google se ukázali dobře. Pro všechny naše případy – přesně. Více pozitivních zkušeností nemáme. Všechny ostatní cloudy, se kterými jsme se pokoušeli pracovat, vytvářejí spoustu problémů – a Ager, a vše, co je v Rusku, a různé implementace OpenStack: Headster, Overage – cokoliv, co chcete. Všechny vytvářejí problémy, které se nechcete řešit.
Proto je odpověď – ano, ale ve skutečnosti není moc zralých hosted řešení.
Komu je Kubernetes potřebný?
— A přece komu je Kubernetes potřebný? Kdo by měl přejít na Kubernetes, kdo je typický klient "Flanta", který přichází právě pro Kubernetes?
Dmitrij: Otázka je zajímavá, protože nyní je na vlně Kubernetes mnoho lidí: "Chlapci, víme, že děláte Kubernetes, udělejte nám to!" Odpovídáme: "Páni, my Kubernetes neděláme, děláme produkci a vše, co s tím souvisí." Protože udělat produkci, aniž by se udělalo celé CI/CD a celá tato historie, je v současnosti prostě nemožné. Všichni se vzdali rozdělení mezi tím, co je vývoj a co je provoz.
Naši klienti očekávají různorodé věci, ale všichni očekávají nějaký zázrak, že mají určité problémy, a teď — hop! — Kubernetes je vyřeší. Lidé věří v zázraky. Rozumově chápou, že zázrak nebude, ale duší doufají — a co když nám teď Kubernetes všechno vyřeší, tolik o něm mluví! Najednou to je — chich! — a stříbrná kulka, chich! — a máme 100% uptime, všichni vývojáři mohou zveřejnit co jen chtějí 50krát na produkci, a nic nespadne. Celkově, zázrak!
Když takoví lidé přicházejí, říkáme: "Omlouváme se, ale zázraky neexistují." Abyste byli zdraví, musíte se správně stravovat a cvičit. Abyste měli spolehlivou produkci, musíte ji udělat pevně. Abyste měli pohodlné CI/CD, musíte ho udělat tak. Je to spousta práce, kterou je třeba vykonat.
Odpovídající na otázku, komu je Kubernetes potřebný — Kubernetes není potřeba nikomu.
Někteří lidé mají mylný pocit, že potřebují Kubernetes. Lidem je potřeba, mají hlubokou touhu přestat myslet, zaobírat se a zajímat o všechny problémy infrastruktury a spuštění jejich aplikací. Chtějí, aby aplikace prostě fungovaly a prostě se nasazovaly. Pro ně je Kubernetes nadějí, že přestanou slyšet příběhy, že "jsme tam leželi", nebo "nemůžeme se nasadit", nebo něco jiného.
Obvykle k nám přichází technický ředitel. Požadují dvě věci: z jedné strany, přineste nám funkce, z druhé strany — stabilitu. Nabízíme, že to vezmeme na sebe a uděláme to. Stříbrná kulka, přesněji, stříbrněná, je v tom, že přestanete myslet na tyto problémy a plýtvat časem. Budete mít specializované lidi, kteří vyřeší tuto otázku.
Formulace, že potřebujeme Kubernetes, je nesprávná.
Kubernetes je velmi užitečný pro administrátory, protože je to fascinující nástroj, se kterým si mohou hrát a experimentovat. Buďme upřímní - všichni máme rádi hračky. Všichni jsme trochu děti, a když vidíme něco nového, chceme si s tím hrát. Někdy to může být odrazené, například u administrátorů, kteří už si s tím dost hráli a mají toho dost, až to přestává být zajímavé. Ale nikdo to nemá úplně přeražené. Pokud mě hračky v oblasti systémového administrativního a DevOps už dávno omrzely, stále si kupuji nějaké nové. Všichni lidé tak či onak stále chtějí nějaké hračky.
Nehrajte si s produkcí. Co bych vám důrazně nedoporučoval a co nyní vidím rozšířené: "A, nová hračka!" - běžíme ji koupit, zakoupili a: "Pojďme ji vzít do školy, ukážeme ji všem kamarádům." Nedělejte to. Omlouvám se, moje děti rostou, neustále vidím něco v dětech, vnímám to v sobě a pak to ještě zobecňuji na ostatní.
Konečná odpověď: Kubernetes nepotřebujete. Potřebujete vyřešit své problémy.
Můžete dosáhnout toho, že:
- produkce nepadá;
- i když se snaží spadnout, víme o tom předem a můžeme něco udělat;
- můžeme ji měnit takovou rychlostí, jakou potřebujeme pro byznys, a dělat to pohodlně, bez problémů.
Skutečné potřeby jsou dvě: spolehlivost a dynamika / flexibilita nasazení. Všem, kdo se nyní věnují nějakým IT projektům, nezávisle na oboru - softwaru pro usnadnění světa, a kteří to chápou, musí tyto potřeby vyřešit. Kubernetes, pokud je používáno správně, s jasným porozuměním a dostatečnými zkušenostmi, umožňuje jejich řešení.
O serverless
Pokud se podíváme o něco dál do budoucnosti, snažíc se vyřešit problém absence bolestí hlavy s infrastrukturou, rychlostí nasazení a změnami aplikací, objevují se nová řešení, například serverless. Vidíš v tomto směru nějaký potenciál a, řekněme, hrozbu pro Kubernetes a podobná řešení?
Dmitrij: Tady je potřeba udělat poznámku, že nejsem věštec, který se dívá vpřed a říká – bude to takhle! Ačkoli jsem právě dělal totéž. Dívám se pod nohy a vidím tam spoustu problémů, například jak v počítači fungují tranzistory. Až k smíchu, co? Narážíme na nějaké chyby v CPU.
Udělání serverless dostatečně spolehlivým, levným, efektivním a pohodlným, vyřešením všech ekosystémových otázek. Tady souhlasím s Ilonem Muskem, že potřebujeme druhou planetu, abychom zajistili odolnost pro lidstvo. I když nevím, co říká, chápeme, že nejsem připraven letět na Mars a že to nebude zítra.
Se serverless je jasné, že je to ideologicky správná věc, jako odolnost pro lidstvo – mít dvě planety je lepší než jednu. Ale jak to udělat nyní? Poslat jednu expedici – to není problém, pokud se soustředíme na tuto snahu. Odeslat několik expedic a osídlit tam několik tisíc lidí, myslím, že to je také realistické. Ale provést kompletní odolnost, aby tam žila polovina lidstva, mi nyní připadá nemožné, nerealizovatelné.
Se serverless je to identické: super věc, ale daleko od problémů roku 2019. Blíže k roku 2030 – pojďme se dožít. Nezpochybňuji, že se dožijeme, určitě se dožijeme (opakujte si to před spaním), ale nyní je třeba řešit jiné problémy. Je to jako věřit na pohádkového poníka Duhového. Ano, pár procent případů se řeší a řeší se skvěle, ale subjektivně serverless – to je duha… Tohle téma je pro mě příliš vzdálené a příliš nejasné. Nejsem připraven o tom mluvit. V roce 2019 nevytvoříte žádnou aplikaci se serverless.
Jak se bude vyvíjet Kubernetes
— Zatímco jdeme k tomuto potenciálně krásnému vzdálenému budoucnu, jak si myslíš, jak se bude vyvíjet Kubernetes a ekosystém kolem něj?
Dmitrij: O tom jsem hodně přemýšlel a mám na to jasnou odpověď. První je stateful - udělat stateless je přece jen snadnější. Kubernetes do toho zprvu investoval více, od něj to všechno začalo. Stateless funguje prakticky dokonale v Kubernetes, není na co si stěžovat. U stateful zůstává ještě hromada problémů, vlastně nuancí. U nás už to funguje skvěle, ale to jsme my. Aby to fungovalo pro všechny, potřebujeme ještě minimálně pár let. To není vypočítaná metrika, ale můj pocit z hlavy.
Zkrátka, stateful by měl - a bude - výrazně růst, protože všechny naše aplikace uchovávají stav, neexistují stateless aplikace. To je iluze, vždy je potřeba nějaká databáze a něco navíc. Stateful je zaměření na vše, co je možné, opravy všech chyb a zlepšení všech problémů, se kterými se teď potýkáme - nazvěme to adopce.
Úroveň neprobádaného, úroveň nevyřešených problémů, úroveň pravděpodobnosti, že se s něčím setkáme, výrazně klesne. To je důležitý příběh. A operátoři - vše, co souvisí s kodifikací logiky administrace, logiky řízení, abychom získali snadnou službu: MySQL snadná služba, RabbitMQ snadná služba, Memcache snadná služba - vlastně všechny tyto komponenty, které potřebujeme, abychom měli garantovanou funkčnost z krabice. To právě řeší tyto bolesti, že chceme databázi, ale nechceme ji administrativně řídit, nebo chceme Kubernetes, ale nechceme ho administrativně řídit.
Tento příběh s vývojem operatorů v nějaké podobě bude důležitý v následujících několika letech.
Myslím, že by měla výrazně vzrůst jednoduchost provozu - krabice se bude stávat stále černější, stále spolehlivější, s stále jednoduššími ovládacími prvky.
Nedávno jsem poslouchal starý rozhovor Isaaca Asimova z 80. let na YouTube v show Saturday Night Live - pořad typu Urgant, jenže zajímavý. Tam se ho ptali na budoucnost počítačů. Řekl, že budoucnost je v jednoduchosti, tak jako to bylo u rádií. Rádiový přijímač byl zpočátku složitá věc. Abychom zachytili vlnu, museli jsme 15 minut točit ovladači, otáčet knoflíky a vůbec rozumět, jak to celé funguje, chápat fyziku přenosu rádiových vln. Výsledkem je, že u rádia zůstala jen jedna klička.
Jaké rádio je teď, v roce 2019? V autě rádio zachytává všechny vlny a názvy stanic. Fyzika procesu se za 100 let nezměnila, změnila se však jednoduchost použití. Dnes, a nejen dnes, už v roce 1980, když bylo interview s Asimovem, všichni používali rádio a nikdo se nezamýšlel nad tím, jak to funguje. Vždy to fungovalo – to je dané.
Asimov tehdy říkal, že s počítači to bude podobné – jednoduchost použití vzroste.Pokud v roce 1980 bylo potřeba mít speciální vzdělání, abyste mohli stisknout tlačítka na počítači, v budoucnu to tak nebude.
Mám pocit, že s Kubernetes a infrastrukturou také dojde k výraznému zvýšení jednoduchosti použití. To je podle mě zřejmé – leží to na povrchu.
Co udělat s inženýry?
— A co se pak stane s inženýry, systémovými administrátory, kteří podporují Kubernetes?
Dmitrij: A co se stalo s účetními po příchodu 1C? Přibližně to stejné. Dříve se počítalo na papíře – nyní v programu. Produktivita práce vzrostla několik násobně, a práce tím nezmizela. Když dříve potřebovalo při výměně žárovky 10 inženýrů, nyní bude stačit jeden.
Počet softwaru a počet úkolů, mi přijde, že nyní roste rychlostí vyšší, než se objevují noví DevOps a zvyšuje se efektivita. Nyní je na trhu konkrétní nedostatek a ten potrvá dlouho. Později se vše dostane do určité normy, při které efektivita práce vzroste, bude stále více serverless, k Kubernetes se připojí neuronka, která bude vybírat veškeré zdroje přesně tak, jak je potřeba, a všechno udělá sama, jak má – člověk se odtáhne a nebude překážet.
Ale rozhodnutí bude stále muset někdo přijímat. Je jasné, že úroveň kvalifikace a specializace tohoto člověka je vyšší. Nyní na účetním oddělení nepotřebujete 10 zaměstnanců, kteří vedou účetní knihy, aby se jejich ruka neunavila. To je prostě zbytečné. Mnoho dokumentů se automaticky skenuje, rozpoznává systémem elektronického oběhu dokumentů. Stačí jeden chytrý hlavní účetní, s mnohem lepšími dovednostmi a dobrým porozuměním.
Celkově je to tak ve všech odvětvích. S automobily je to obdobné: dříve byl k automobilu přidělen mechanik a tři řidiči. Dnes je řízení automobilu jednoduchý proces, kterého se účastníme každý den. Nikdo si neuvědomuje, že auto je něco složitého.
DevOps nebo systémové inženýrství se nikam neztratí — úroveň efektivity práce bude růst.
— Ještě jsem slyšel zajímavou myšlenku, že ve skutečnosti práce vzroste.
Dmitrij: Samozřejmě, sto procent! Protože množství softwaru, které píšeme, neustále roste. Množství problémů, které řešíme pomocí softwaru, neustále roste. Množství práce roste. Trh DevOps je nyní silně přeplněný. Je to vidět na očekáváních platů. Opravdu, aniž bychom se zabývali detaily, by měly být juniory, kteří chtějí X, middle, kteří chtějí 1,5X, a senioři, kteří chtějí 2X. A nyní, pokud se podíváme na moskevský trh platů DevOps, junior chce od X do 3X a senior chce od X do 3X.
Nikdo neví, kolik to stojí. Úroveň platu se měří vaší jistotou — je to naprostý chaos, upřímně, silně přeplněný trh.
Samozřejmě, tato situace se velmi brzy změní — mělo by dojít k určitému nasycení. Se softwarem to však není tak — i když jsou vývojáři potřební a všichni chtějí dobré vývojáře, trh chápe, kolik kdo stojí — odvětví se usadilo. S DevOps to není stejné.
— Z toho, co jsem slyšel, jsem dospěl k závěru, že aktuální systémový administrátor se nemá příliš obávat, ale je čas na zlepšení dovedností a připravit se na to, že zítra bude více práce, ale bude vysoce kvalifikovaná.
Dmitrij: Stoprocentně. Celkově žijeme v roce 2019 a pravidlo života je takové: lifetime learning — učíme se po celý život. Myslím, že to nyní všichni vědí a cítí, ale nestačí jen vědět — je třeba jednat. Každý den se musíme měnit. Pokud to neděláme, tak dříve nebo později nás vykopnou na okraj profese.
Buďte připraveni na náhlé změny o 180 stupňů. Nezavrhuji situace, kdy se něco zásadně změní, vymyslí se něco nového — to se stává. Hop! — a teď jednáme jinak. Je důležité být na to připraven a nedělat si s tím starosti. Může se stát, že zítra všechno, co dělám, bude zbytečné — to nevadí, celý život jsem se učil a jsem připraven učit se něco jiného. Není to problém. Nebojte se o pracovní stabilitu, ale buďte připraveni neustále se učit nové věci.
Přání a chvilka reklamy
— Máš nějaké přání?
Dmitrij: Ano, mám několik přání.
První a materiální — přihlašte se na . Vážení čtenáři, navštivte YouTube a přihlaste se k našemu kanálu. Asi za měsíc začneme aktivně expandovat na video služby, máme spoustu vzdělávacího obsahu o Kubernetes, otevřeného a různorodého: od praktických věcí, až po laboratoře, a hluboké teoretické principy, a jak aplikovat Kubernetes na úrovni principů a vzorů.
Druhé materiální přání — navštivte a dejte nám hvězdičky, protože tím se ž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. Děláme něco, děláme, snažíme se, někdo říká, že to jsou hrozné bicykly, někdo, že je to všechno úplně špatně, a my pokračujeme a jednáme naprosto čestně. Vidíme problém, řešíme ho a sdílíme zkušenosti. Proto nám dejte hvězdičku, vám to neubere, a nám to přidá, protože tím se živíme.
Třetí, důležité, a už ne materiální přání — přestaňte věřit na pohádky. Jste profesionálové. DevOps je velmi vážná a odpovědná profese. Přestaňte si hrát na pracovišti. Nechť vás to zasáhne, a vy si to uvědomíte. Představte si, že přijdete do nemocnice, a tam na vás doktor experimentuje. Chápu, že to může být někoho urazit, ale pravděpodobně to není o vás, ale o někom jiném. Řekněte ostatním, aby také přestali. Opravu to kazí život nám všem — mnozí začínají vnímat správu, administrátory a DevOps jako kluky, kteří znovu něco rozbili. To „rozbili“ je většinou kvůli tomu, že jsme se šli bavit, a ne s chladným rozumem se podívali, že tady to je tak a tady tak.
To neznamená, že bychom neměli experimentovat. Experimentovat je třeba, my sami to děláme. Pokud budeme upřímní, občas si také hrajeme – to je samozřejmě špatně, ale nic lidského nám není cizí. Vyhlásíme rok 2019 rokem vážných a promyšlených experimentů, nikoliv hrami na produkci. Pravděpodobně tak.
– Děkuji vám moc!
Dmitrij: Děkuji Tobě, Vitali, za čas a za rozhovor. Drazí čtenáři, děkuji vám velmi, pokud jste náhodou došli až sem. Doufám, že jsme vám přinesli alespoň pár myšlenek.
V rozhovoru se Dmitrij dotkl otázky werf. Nyní je to univerzální švýcarský nůž, který řeší téměř všechny úkoly. Ale nebylo tomu tak vždy. na festivalu Dmitrij Stolyarov o tomto nástroji podrobně poví. V přednášce bude vše: problémy a skryté nuance Kubernetes, možnosti řešení těchto obtíží a aktuální realizace werf v podrobnostech. Připojte se 27. a 28. května, budeme vytvářet ideální nástroje.
Zdroj: habr.com
