CRA Cloud: Jak dostat vlastní aplikace do kontejnerů

00:00:19
Přeji všem příjemné dopoledne. Vítám vás tady na našem webináři. Dneska si budeme povídat o tom, jak dostat vlastní aplikace do kontejnerizace. Máme to před sebou poměrně hodně, budeme mluvit o službách v kontejnerech, o dockerfailu, porovnáme si kontejnery v dockerech a kontejnery v kubernetech, protože to je v podstatě to základně zásadní téma. Dotkneme se i bezpečnosti, řekneme si něco o servis meshy. Pak si povíme něco málo o struktuře toho, jak vlastně Kubernetes dovolují ukládat data, vystavovat službu. Máme tam i téma zaměřený na konfiguraci. Řekneme si, jaký struktury vlastně představují ty dnešní kontejnery. A na závěr se podíváme i na to, jak vlastně začít s tou vaší aplikací. Tím mým zájmem dneska bude vám ukázat, že kontejnerizace a vůbec začít s kontejnery není nějak složité. Začnu takovou malou drobnou rekapitulací. My jsme si minule, pokud jste byli na předchozím webináři, říkali, jaký typy vlastně dneska kontejnerů jsou, že existují stavové, že existují nestavové. U stavových řešíme to, jestli jejich restart nebo jejich ztráta nás něco, respektive bolí, nebo jakým způsobem předejít tomu, abychom ten stav, který si takové kontejnery udržují, tak abychom jej nestratili. U nestavových víme, že je nám to jedno, že je používáme zejména tehdy, když chceme nějakou vysokou dostupnost, A budeme potřebovat poprace s tou schopností, jak data efektivně ukládat nebo synchronizovat takovým způsobem, aby pro nás ztráta stavovýho kontejneru nebyla nějakým problémem. Ukázali jsme si jeden velmi speciální kontejner v úzovkách. Dá se v podstatě říct, že bychom dokázali i z dnešních aplikací vytvořit jeden obrovský monolitický kontejner. My si za moment právě ukážeme, jak něčeho takového dosáhnout, jak se do toho vůbec vlastně pustit a mimo jiné ukážeme, proč je zrovna tenhle způsob přechodu do kontejnerizace U toho monolitického kontejneru musíme nutně řešit takový situace, jako to, že není distribuovatelný, velmi špatně se nám s ním bude pracovat, protože je obrovský, obsahuje celou řadu různých služeb, těžko se nám bude specifikovat jediná služba, která uvnitř běží a pokud ano, tak pak je zvláštní, že je nazýváme monolitickým, že pak je to pravděpodobně některý z těch kontejnerů, který jsme jmenovali předtím. My, abychom to pochopili nebo vůbec si to trochu přiblížili, tak se podíváme na to, jak se kontejnery staví. Pravděpodobně řada z vás bude znát systém nebo respektive popis kontejnerů, který jsme dokofajili, za chvíli se mu budeme věnovat víc, ale my se podíváme ještě na tu, dejme tomu teoretickou rovinu, kdy říkáme, jasně, my kontejnery stavíme jako nadstavbu nějakých základních imidží, vezmeme si něco, čemu můžeme říkat nějakou jako základní imidž, base imidž a začínajeme vytvořit ve vší podstatě se takový kontejner příliš nejliší od standardní virtualizace. Jednou z poměrně velkých nevýhod takového systému je to, že aby vám Inido nebo Systemd a podobné věci fungovaly, tak budete potřebovat něco, čemu se říká privilegovaný kontejner. A to je kontejner, u kterého se zase naráží do zásadním způsobem na bezpečnost a jeho prolomení je v podstatě získání, dejme tomu jako rozhodně nadstandardních schopností, nabourat celý ten systém. Podíváme se na to, jak vypadá mikroservisní kontejner, tak ten naopak typicky staví na imidži, která je velmi malá. Častěji říkáme nějakou alpine, kdy říkáme si, že ta imidž, která opravdu obsahuje jen to nejnutnější, nutný k tomu, aby sama o sobě fungovala a definujeme nad ní nějaké balíčky, nějaký balíčkovací systém. Určitě znáte Ubuntu nebo Red Hat, každý z nich má svůj balíčkovací systém, takže ten bychom v takový moment využili. nainstalovali bychom jen ty nejnutnější balíčky, nakopírovali do něj tu službu, kterou představuje to naše know-how a vlastně mohli spustit. Budeme samozřejmě řešit, jestli k tomu připojit disky, což je ten příkaz volume, který tam někde uvádím, nebo naopak nikoliv. Pokud bychom se bavili třeba o nestavovém kontejnu, tak by to pravděpodobně nemuselo být ani nutné. A samozřejmě u obou těch případů budeme řešit, jak takzvaně vexportovat tu službu nebo služby ven, což jsou pro nás v podstatě vž Jak to vypadá v praxi, můžete vidět tady na tom slajdu, kdy vlastně vpravo nahoře je popsaný ten Dockerfile, tak jak reálně vypadá. To je velmi jednoduchá ukázka toho, jak vypadá Dockerfile. Ukážeme si ho za chvilinku i v demo, kdy vezmeme nějaký úplně základní base image, v tomto případě base image, který obsahuje Python. Využil jsem ho, protože jsem Python potom použil v tom dalším příkladu vyexportujeme si nějaký port, v tomhle případě port 8000, nakopírujeme si nějaké základní balíčky, které pro ten Python potřebujeme, které jsme předtím popsali v textovém souboru, který se tady v tomhle případě jmenuje Requirements.txt a jsme schopní vlastně spustit ten Python, respektive tu naši aplikaci, která se v tomhle případě teda jmenuje server.py, jako ten základní komand vlastně toho kontejneru jako takovýho. My si za chvíli ukážeme v tom demo, že jde vlastně v tomhle konkrétním případě o Linux, což je pro nás operační systém, kdy využíváme nějaká volání jeho jádra. Jsme samozřejmě v kontejnerovém engine doku a pokud bychom se dívali na infrastrukturu, tak jsme v instrukční sadě x86. Nebude možný, pokud vybudujeme takovýhle image, tak samozřejmě nebude možné ho použít kdekoliv jinde. Je potřeba se buď omezit na to, co jsme právě vyjmenovali, nebo přebudovat, rebuildnout ten image pro nějakou novou architekturu nebo novej operační systém, tak, jak jej v podstatě budete potřebovat. Existuje nějaká klíčová slova v Dockerfile, v zásadě se dá říct, že takhle jednoduchý Dockerfile, jako teď vidíte, tak by dokázal popsat většinu velmi jednoduchých služeb a pokud disponujete nějakým právě takovým, tak se dá říct, že už jste pravděpodobně začali využívat mikroservisní služby. To, co je na Dockerfile super a velmi často se používá, tak je jednak to, že je kompatibilní s některými dalšími engine, kontejnerů a existuje nad něj řada různých nadstaveb, Já tu pro vás mám připravenou takovou jednoduchou ukázku, kde jsme tady ten dockerfile vzali, vybudovali jsme z něj kontejner v rámci našeho lokálního dockeru, spustili jsme jej, pak jsme jej dokonce upravili a nahradili vlastně tu původní verzi novou verzi s tím, že využíváme ty klasické dockerové věci. Taková jednoduchá ukázka toho, že používat kontejnery a budovat je a vůbec využívat docker je opravdu velmi triviální. můžeme zapnout ukázku. Tak to, co tady máme teď připravený, tak je připravený projekt vlastně tzv. Hello World, prostě úplně základní projekt. Tady ukazuju na ukázku, jak vypadá ten Dockerfile, který používáme, jak vypadají ty requirements. Můžete si všimnout, že tady u těch requirements přímo definujeme i verze, což je jeden z velmi dobrých hintů, jak vůbec imidže dokorovní, vůbec ne kontejnery stavět, což znamená definovat si jejich verze velmi pevně. Ono to dovolí, abyste potom nebyli Teď už jste mohli vidět, že vlastně jednoduchým příkladem jsme vybudovali ten ten image file, tady jenom pro ukázku, tohleto je ta služba, kterou očekáváme, že poběží, zatím nám neběží, zatím je port 8000 prázdný, ale teď ji zpustíme. Tak exportujeme si port 8000 zase na port 8000. definujeme kterou image chceme A teď už na pozadí běží jeden z kontejnerů do kruhu. přetelně vidět a když se podíváme na službu, tak zjistíme, že už normálně běží. Tak. To, co jsme tady použili dál, je ještě i použití tzv. registry. To je velmi důležitá věc, která se hodí v momentě, kdy potom budujete kontejnery. v Kubernetes, tak mít místo, kam imidže vlastně odkládáte, odkud si je zase berete, protože Kubernetes už nejsou samozřejmě single host systém, takže to uvidíme za moment. To, co tady ještě můžete vidět, vidíme vlastně logi toho přístupu, které se nám ukládají na standard out. Zase běžná věc. I způsob, jakým způsobem vlastně vidíte ty logi, tak je běžný způsob, jak se z kontejnery v Dockeru pracuje. A teď použijeme to, že nahrajeme právě tu image do registru. Já v tomto případě využívám ten úplně nejobecnější Docker.io hub vlastně, kde na pozadí na prolížeči potom můžete vidět i otevřenou sešnu právě na můj účet. To, co ukazujeme tady ještě, je dobré okomentovat, tak je vlastně to, že ty jednotlivé hashe, které jste mohli vidět na pozadí, představují právě stage, který se ten Dockerfile vytváří a vychází z toho základního imidže a vytváří nad ním ty další a další vrstvy, kterými definuje, jak přesně vypadá ta vaše imidž. Je to velmi zajímavý a velmi efektivní způsob, protože ve finále, a ukážeme si to ještě v další ukázce, když potom vytvoříte z podobného imidže To, co jste mohli vidět teď, bylo, že jsem upravil jednoduše výstup toho skriptu server.py. Nebudeme teď vypisovat hello world řekneme si ahoj světa nebo světa ahoj Přebudujeme ho. Zase si ho teda pušteme do registrů. Jsme tam měli aktuální verzi. Tady je zase vidět, že vlastně většina těch předchozích vrstev se využila, protože jediný, co jsem změnil, byl jeden ze souborů, který jsem naloudoval vlastně do toho kontejneru až jako poslední. Nejsem si jistý, jestli poslední nebo předposlední, ale ten systém doku respektive kontejneru tohle rozpozná. a pracuje zase jenom s tím rozdílem jako takovým. Tak, teď když reloademe stránku, ta služba už nám vrací zpátky a oj světe tak, jak jsme chtěli. Mezitím jsme ji samozřejmě museli vypnout a zapnout tou novou verzií imidže. Zase můžeme vidět výstup, pokud tady provedeme nějaký refresh, tak na výstupu se nám objeví zase logi výstupu. To, co jsme vlastně v tuhle chvíli viděli, tak je jednoduchá ukázka toho, jak vypadá kontejner, nicméně omezená na jeden konkrétní host do kru. Ten výstup, který jsme použili, v tomto případě port 8000, tak byl vlastně výstupem přímo ven z toho hosta, z toho hardwareového nodu, který který ten Docker jako takový nese. Nepoužili jsme žádné volumy, nic jsme nepřipojovali, pracovali jsme v podstatě čistě jenom s tím, co nám nesla ta image samotná, takže pokud bychom chtěli zpracovávat nějaká data, tak bychom je samozřejmě museli vylevat ven, respektive posílat do nějakých dalších služeb, nebo je zase od někud jinud stahovat, to je jasné. A mohli jste vidět v rámci Docker Hubu, že ty requirements na tuhle konkrétní image byly Linux x86, což bylo definováno jednak tím, kde jsem je budoval a samozřejmě i tou base image, kterou jsem použil, kdy jsem si nevinutil, aby vlastně využil nějakou jinou část týhletý base image. Spousta base image je dneska už dávno připravená, lidé běžně pracují právě s Alpine nějakými vlastně operačními systémy, respektive obrazy těch základních knihoven, které ten operační systém využívají, Tak, to, co nás tady ještě může zajímat na téhle ukázce, tak je to, že ten, kdo se vlastně díval, tak mohl být úplně kdekoliv. My jsme využili prohlížeč, který byl vlastně na tom samém počítači, dívali jsme se na lokálohost, nicméně připojit si ten port 8000, respektive celý ten kontejner nikoliv na lokálohost, ale na jakoukoliv IP adresu toho daného hosta by v tomhle případě nebyl žádný problém. Proč to ukazujeme? Ukazujeme to proto, že v Kubernetes potřebujeme začít uvažovat trochu šířej. Kubernetes nejsou single host Docker, je to samozřejmě systém, který představuje více vrstev než jednu jedinou a my si ukážeme podobnou ukázku, nicméně v Kubernetes. Vlastně kam dojdeme, použijeme-li stejné systémy, které jsme teď vybudovali pro Docker. Zase máme tady Kubernetes Tanzu, který jsme použili už v minulém webináři, jsme si ho vytvořili v rámci výkladu direktoru. Vytvoříme si teď pod, který vlastně využije image, kterou jsme použili v té předchozí ukázce a ukážeme si, jak to funguje v momentě, kdy chceme takovej pod vlastně spustit do Kubernetes. Ještě možná upozorním, vytváříme skutečně jenom pod, nevytváříme žádnou jakoby složitější strukturu. Já to zkusím trochu komentovat. Tak teď jsme mohli vidět, stáhl jsem si tu image Markere Hello World a vlastně expouzuji ten port 8000 v rámci Kubernetes, ty už mám předtím připravený. Můžeme vidět, že ten pod se tam skutečně spustil, že nám běží. A to, co teď ještě udělám speciálně, je, že si vybuduju vlastně druhý kontejner, respektive druhou image, mohl bych potenciálně použít i tu předchozí, ve které se pouze připojím jako sekundární klient do Kubernetes. Já jsem si proto zvolil ještě jednodušší Dockerfile, kdy jsem ořezal ten původní, ale přidal jsem si skrz balíčkova, Takže nám ta služba na portu 8000 na nějakém dalším portu respektive na nějaké jiné službě běží. Tak, tady už je pušnutá do mýho repozitáře a zase při tom puši je možný vidět, že ten systém rozpozná, že jsem využil nějaký jiný image, který už v rámci repozitáře mám, takže vidí nebo vnímá a ukládá pouze rozdíl, který vůči němu je velká výhoda, zvlášť v momentě, kdy ty servisy budujete z jedné imidže nebo z nějakého omezeného spektra imidží, které máte připraveny, což je ostatně jedno z dalších doporučení, Tak, teď už jsem se připojil do nového podu. Jsem v jeho příkazové řádce, můžu vidět, že se jmenuje Bash Test, tak jak jsem ho předtím nazval, to je jasné. Když si zkusím přeložit tu službu Hello World, kterou jsem vytvořil v těch předchozích krocích, tak dostávám zpátky nějakou dynamickou IP adresu, to je strašně super věc, budem si o ní chvilinku povídat. A když se podívám na port 8000, vidím tam ten výsledek, který vlastně očekávám. Tak, vyskočil jsem z toho, dál mi tam běží zase jenom Hello World, Kubernetes tam vlastně zůstávají tak, jak byly. a dál tam běží služba na portu 8000. To, co jsme teď vlastně viděli, když se na to podíváme strukturovaně trošičku, tak už je situace, kdy jsme měli celý Kubernetes klastr. Víme, že ten Kubernetes klastr je tvořený jedním mástrem, třemi workry. To, co jsme mohli vidět celé jako evidentně je, že já vůbec netuším a ani jsem nějak neovlivňoval, kde mi který pod běžel. Absolutně nemám páru, jestli běžel na stejném workru nebo běžel na dvou různých workrech. Ostatně mohlo to být tak i tak, já to skutečně nevím. Kubernetes obsahují nástroje, které vám dovolují, abyste takzvaně selektovali některý z těch konkrétních nodů nebo nějakou konkrétní vlastnost nějakého nodu. Tady v té jednoduché ukázce jsme je nepoužili. To, co jsme zároveň mohli vidět, je, že ty dva pody spolu komunikovali. Mohli jsme vidět, že jsme dostali v podstatě na překlad toho názvu podu, respektive názvu služby, jsme dostali nějakou konkrétní IP adresu, která nám není nějak známá, vůbec s ní nějak nepracujeme a zvenčí samozřejmě není nějak dostupná. To, co se vlastně stalo, je to, že v momentě, kdy jsme vytvořili službu Hello World, ten servis Hello World, tak ten se zaregistruje automaticky do DNS, Zase nevyužili jsme žádné volumy, nesnažili jsme se pracovat s žádnými daty. V podstatě jsme skutečně použili jenom to, co známe z Dockeru. A v momentě, kdybychom se dívali na to, jak vypadá ta struktura v Kubernetes, tak jediné, co bychom viděli, je skutečně pod. Existují další systémy, respektive další struktury nadpody, kterým se říká třeba deploymenty, stateful a další demoncety. Máme je tam potom drobně představený, To, co jsme tady nevyužili, ale je rozhodně vhodný zmínit, tak je určitým způsobem otázka bezpečnosti. Protože to, co jste vlastně mohli vidět, je, že já jsem velmi jednoduchým způsobem vytvořil kontejner, který měl přístup do té vnitřní sítě Kubernetes, využíval tam a sledoval tam nějakou službu, v tomto případě Hello World, ale mohl samozřejmě sledovat a nějakým způsobem skenovat nebo stahovat data z jakékoliv jiné služby, která by tam v tu chvíli byla k dispozici. Obecně v Kubernetes z ohledu bezpečnosti velmi často řeší. Existují různé nástroje, které řeší to, jestli nepoužíváte právě třeba base image, která už je sama o sobě ničím poškozená. dejme tomu, infikovaná takovým způsobem, že by vám na pozadí nebo uvnitř Kubernetes dělala neplechu. V té ukázce jsem to neukázal, nicméně Docker dovoluje skenování a tak, jak jste asi mohli vnímat vlastně z té ukázky, to, co je jednou z těch klíčových komponentů Kubernetes, tak jsou takzvané registry. Já tady využíval registry, které jsou veřejné, respektive můj repozitář je jako takový veřejný. Potom skenu vám to dá případně doporučení, že tenhle image není OK nebo je OK. Aktuálně je to velmi zajímavé téma, protože možná jste nedávno zaznamenali, že jeden z útoků, který proběhl, v rámci Open Source Community, tak bylo napadení vlastně zdrojového kódu PHP engine, respektive PHP jako takového, které by dovolilo, pokud by se dostalo do toho hlavního branche, tak by vlastně dovolilo, aby se útočníci velmi jednoduchým způsobem dostali do systému, které to PHP jako takové využívají. To byl velmi zajímavý útok a je to přesně vlastně ten typ útoku, kdy se vám záškodník snaží nějakou obecnosti Tato skenování obrazu je potom důležitá část. Pokud budete stavit vlastní registry, což vřele doporučuji a budeme se tomu ještě chvilinku věnovat později, tak je rozhodně vhodné uvažovat nad tím, aby vaše registry skenování k dispozici měly. Já se na bezpečnost podívám ještě z jednoho úhlu pohledu a to je bezpečnost právě vlastně kooperace mezi jednotlivými projekty, které do Kubernetes vkládáte. To, co jste mohli vidět, je, že já jsem měl dva pody, ty na sebe viděli, respektive jeden viděl na druhého, ten první by potenciálně viděl i na ten můj pod, který servisu neměl, pokud by. správným způsobem adresoval ten pod a mohly od sebe nebo mohly se navzájem ohlivnit. Dneska existuje několik způsobů, jak vlastně izolovat ty jednotlivý pracovní, dejme tomu, témata, případně pracovní skupiny. Jedna z nich je samozřejmě ta enormní, která říká pro každou věc dneska vytvoříme vlastní kubernety. To je možné. Běžně se taková situace řeší a používá Otázka čistě jen bezpečnosti, ale samozřejmě ovlivňování zdrojů a jejich plánování a případně nějaký průnik zvenčí, nikoli vlastně zevnitř z pohledu toho, že by vám jeden tým nebo jeden projekt svým neuváženým chováním napadl ten druhý. Tohle je, dá se říct, maximální úroveň, které lze dneska z pohledu Kubernetes dosáhnout, prostě pro každý projekt vytvořit vlastní Kubernetes. Není to úplně ideální scéna, Tím druhým způsobem, jak vlastně oddělit jednotlivý pracovní týmy nebo pracovní skupiny, případně projekty, tak je využití tzv. namespaců. Kubernetes obecně a vždycky obsahují namespacy, což je základní dělení, kdy vy jednotlivý struktury definujete, respektive vkládáte do namespaců. Je potřeba chápat to, že namespace není úplná a dokonalá izolace, naopak vy úřady služeb chcete, aby na sebe viděli, i přesto, že jsou v různých namespacech, i přesto, že vlastně typické je potom to, že jeden z těch namespaceů, nebo více dost těch namespaceů je takzvaně systémových, které vám nabízí ty globální služby, jako je třeba logování, nebo monitoring, nebo případně nějaký statistiky a podobné věci. Takže nejde o to, že by vám namespacy dovolili a i nabízeli, abyste provedli dokonalý oddělení. To není vůbec cílem. Krom toho je velmi jednoduché se potom v namespacech ztratit. Existují takové speciality, které vám dovolí, abyste izolovali sítě v rámci namespaceů. Abyste něco takového použili, tak byste museli použít network interface kanál, což taky není úplně jako defaultní stav, takže vyžadujete od vás, dá se říct, jediný a definovat mu nějakým globálním pravidlem práva, tak je mnohem zajímavější, než je definovat per namespace nebo případně, protože kubernety dovolují pracovat s různými maskami a podobnými věcmi, tak si definovat názvo sloví nebo podobné jiné věci, labeling a tak dále vůči namespacům tak, abyste práva dodrželi. Je velmi jednoduché a mnohokrát se stalo se v kubernetech ztratit. Kubernetes obsahují velké množství různých typů objektů. Za chvíli si o několika z nich budeme povídat a ztratit potom ten kontext a vůbec vlastně strukturu je vlastně, dá se říct, skoro běžným stavem, který se vám v průběhu vývoje vašich Kubernetes a vašeho přechodu do nich pravděpodobně stane. Tak to, co jsme mohli vidět v ukázce a je tou velmi důležitou částí Kubernetes, tak je tzv. service mesh. To je vlastně systém, který vám dovoluje, abyste adresovali jednotlivé služby mezi sebou. Využívá se přitom DNS, kdy interní DNS Kubernetes registruje jednotlivé služby, případně jednotlivé pody, které v rámci Kubernetes vznikají, definuje a odděluje i podle namespace. V té cestě se ten namespace jako takový právě objevuje. Je to taková alternativa, kdybyste něco podobného chtěli vytvářet na baremetalu, tak je to taková alternativa k systémům, které jsou tvořeny třeba Avahy nebo třeba Konzulem. Tyhle systémy jsou podobným způsobem schopny vytvořit podobnou jakoby servismešovou síť. Moje zkušenost je taková, že abyste něco takového opravdu kvalitně využili, tak musíte investovat velké množství práce. Ten popis služeb v Konzulu je rozhodně netrviální, Naopak, nebo naopak, kubernety se zaměřují na to, aby tohle bylo jejich nativní součástí. Ono vám to dovoluje, abyste v kubernetech využívali vlastně dynamiku mezi pody a službami. A ten princip kubernet byl od počátku ten, že nepotřebujete exportovat ven každou službu. Potřebujete exportovat ven jenom tu, která je pro vás důležitá. A ty služby si jinak mezi sebou povídají uvnitř těch kubernet, kdy na venek není zřetelné vůbec nic. Takže vřele nedoporučuji. To, co ještě existuje a je zajímavostí, v Service Mesh v rámci DNS-ka Kubernetes definují i tzv. server záznamy, které by vám dovolili, zatím jsem teda nevěděl žádnou realizaci, která by s nimi opravdu aktivně pracovala, ale pokud by pracovala, tak by vám dovolila, abyste v server záznamu našli nejenom název služby a kde ji najdete, ale i port a protokol, na kterém je vlastně vyexportovaná. to, co vám zásadním způsobem zlepší práci s nimi. My se podíváme na další typy objektů, které Kubernetes obsahují. A jedním z nich bude situace, ve které chcete tu službu, když už máte služby, které uvnitř Kubernetes fungují, tak když chcete službu dostat ven, dostat ji skutečně externě do světa. V Dockeru to bylo jednoduché. My jsme připojili tu službu na port, který byl dostupný zvenčí. V Kubernetes to takhle triviálně není. Dá se vlastně říct a je vlastně jednoduché si to představit tak, že ingress je v podstatě balancing pravidlo, kdy ten vlastní load balancer je jenom dalším podem v rámci Kubernetes. To je v podstatě taková je vlastně realita, je otázkou, jak je takový pod zpravován, v jaké je struktuře a další věci. Tyhle věci už se liší. Takže ideálně použít ten, na který jste zvyklí a umíte s ním pracovat a skrz ingress potom definovat strukturovaným způsobem jenom to pravidlo, které vlastně slouží pro danou službu. Ten ingress kontroler jako takový zajistí, aby ho zachytilo a trafik, který potom odpovídá tomu pravidlu, směřoval na tu službu, která je tím definovaná. Další z těch způsobů, jak dostat službu ven, tak je takzvaný not port. To je taková hodně jednoduchá věc. Dá se vlastně říct, že funguje na úrovni L4, takže jste schopni definovat port. Už nevíte doménu, nevíte, dejme tomu, žádné cesty nebo nevíte, jestli je komunikace třeba šifrovaná nebo není. Na druhou stranu velmi se to hodí, pokud máte prostě jednoduché projekty. Už jsme viděli řadu případů, kdy se notporty používají právě proto, že tím způsobem efektivně oddělují právě zprávu load balanceru, které pak potřebujete v podstatě externě, od zprávy těch samotných kubernet, kdy vy notportem vydefinujete službu na jeden port, konkrétní číslo portu, na každém nodu kubernet, které v tom klastru jsou. load balancer v kombinaci s některými dalšími službami, respektive nějakými dalšími plug-iny, jako je třeba Metal LB, by vám mohl zajistit to, že naroutujete na Kubernetes celý adresní blok, ať už teda naroutujete skrz třeba BGP, nebo byste je jenom využili v rámci toho adresního bloku, který máte k dispozici skrz ARP adresaci. Všechny tyhle věci mají svý pro a proti. Je samozřejmě zajímavý se potom bavit o konkrétních užitích, ale zase pokud se bavíme o těch běžných aplikacích, které Kubernetes chcete provozovat, tak je nepravděpodobné, že by vás takový přístup něčem zablokoval. Cluster IP představuje vnitřní IP adresu v kubernetech, takže pro tu propagaci ven nám primárně neslouží. Když se podíváme na další velké téma, a to je ukládání dat v Kubernetes, tak ukládání dat je, dejme tomu, tématem, kterému se mohli věnovat velký prostor. Jedná se právě o věci, které potom můžou rozlišovat, jakým způsobem udržovat stavy kontejnerů, nebo naopak, jestli jsme schopni udržovat i při jejich škálovatelnosti, jejich distribuci, využití třeba více availability zone, to znamená v podstatě oddělení, speciální klása, která, respektive speciální typ, který se jmenuje persistent volume, je to v podstatě třída nebo popis, který říká, jakým způsobem se, anebo kde případně, jakým způsobem se má získat prostor pro persistentní ukládání dat. Dneska je několik způsobů využití toho persistent volume, říká se jim takzvané access módy, což jsou v podstatě typy přístupů, jsou konkrétně tři. Z nichž ten nejsložitější a zároveň taky nejčastěji nutný je takzvaný rewrite menu, kdy vy chcete mít možnost ten samý svazek, ten samý prostor vlastně připojit k vícero nodům a na nich případně k vícero podům a současně na ně i zapisovat a teda i samozřejmě číst. Pro takové systémy se nejčastěji používá nějaké sdílené NFS úložiště, tak jsou v podstatě lokální diskový úložišti pro jednotlivé nody. Takový systém je zajímavý tehdy, pokud chcete dosáhnout nějakého hodně extrémního nebo hodně specifického výkonu, že samozřejmě bavíme se o tom, že NFS má nějakou svoji režii, je tam nějaká síť a další věci. V momentě, kdy pracujete s lokálním diskovým úložištěm, ta situace může vypadat trošičku jinak a taky velmi často, pokud pracujete s blokovým úložištěm, tak je samozřejmě takový přístup o něco, nebo potřebujete, respektive potřebujete pracovat s blokovým úložitím. U toho je typické, že používáme nějaký lokální file system nebo třeba system Local Pass, což je jeden z pluginů, který právě definuje tu persistent volume jako takovou, nebo případně něco, čemu se pak říká storage class, což je v podstatě provisioner toho persistent volume. To jsou detaily, které nejsou až tak podstatné. A ten access mod u něj bývá read-write-once, což je druhý z těch žádaných systémů, byť samozřejmě ne tak zajímavých, a říká, že zapisovat může a číst v podstatě pouze jeden. Existuje teda ještě třetí, který říká read-only-many, což je systém, který je v podstatě read-only, ale může z něj ve stejný okamžik číst spousta nodů, respektive podů, To, co je dneska asi důležité a kam se ten směr ubírá, je něco, čemu se říká standard CSI, to je Container Storage Interface. To je standard, který vlastně říká, že tady ta Pedestin Volume, pokud má tuhle konkrétní podobu, tak vám dovolí, abyste mohli nějakým poměrně jednoduchým a hezkým způsobem dělat spoustu věcí, které doposud byly jen třeba těžko možné a hlavně sjednocuje tu podobu těch jednotlivých interfejsů toho Pedestin Volume. Tou velmi zajímavou věcí, kterou to CSI umí nebo definuje v rámci toho svýho interfejsu, tak je například možnost vytvářet snapshoty, což je námi třeba sledovaná věc, protože je to samozřejmě téma, díky kterému bychom mohli snáze provádět zálohování i systémů, které ty data jako takové vlastně ukládají právě do externích voliumů. a hlavně to zálohování nebo obecně práci s těmi daty v tu chvíli řešit z Kubernetes, nikoli z těch externích technologií, které ty volume jako takové představují. Tak, my si povíme ještě něco málo o dynamické konfiguraci. To je téma, který jsem zařadil zejména proto, že jedním z požadavků, které můžeme mít při práci s kontejnery a vůbec při developmentu a následné produkci aplikací v kontejnerech, tak je v podstatě fakt, že pro development a pro produkci nepoužíváme stejné konfigurace. Nechceme, aby konfigurace byly typicky součástí ConfigMap, případně třídu, která se jmenuje Secret, která slouží v podstatě k tému, nicméně respektive velmi podobným způsobem slouží k tomu, aby data, která do ní v podobě tzv. key value, hodnot nebo párů uložíte, tak aby je držela zašifrovaným způsobem a nedávala vám je k dispozici, nebo respektive nebyly k dispozici jen tak. Podobným způsobem potom můžeme vlastně zařídit to, že můžeme konfiguraci v tomto případě, v této jednoduché ukázce, Konkrétně konfiguraci připojení k databáze. K databázi můžeme oddělit od toho vlastního podu, od té vlastní aplikace. To znamená, v té aplikaci se pouze odkazujeme na nějaký konkrétní config map, nebo secret, nebo případně na víc config mapů. Těch způsobů je samozřejmě celá řada. A přenášíme si je mezi prostředími pod v podstatě konzistentně, ten zůstává stejný a config map je v každém prostředí potom vlastní, jiný, stejný Dockerfile pro vývoj a stejný pro produkci. Museli bychom provádět redeployment, respektive rebuild, což je samozřejmě komplikace a je to přesně ten důvod, proč ty config mapy jako takový vznikají, respektive na co je ideálně použít. A podívám se na poslední část těch vlastních dejme tomu strukturu Kubernetesů. a to je vlastně struktura nadpody. Já už jsem tady říkal jméno pody, nevysvětlil jsem, co to znamená, zkusím to napravit. Podem vlastně rozumíme jednotlivý kontejner na Kubernetes nodu, kdy Vlastně uvnitř toho kontejneru bývá typicky v mikroservicím světě jedna aplikace, ale samozřejmě mohli bychom být v situaci, kdy držíme nějakou velkou monolitickou věc a těch aplikací pro nás by v ní bylo k dispozici vícero. Tady to nebudeme tímhle způsobem komplikovat. V podstatě pojďme to vnímat tak, že pod je skutečně jeden kontejner běžící v rámci do kruhu a to, co nám Kubernetes dovolují, je zabalit do struktur, které potom říkají, Tím prvním z těch typů, který tady uvádím, tak je Demon Set, což je v podstatě struktura, která říká, že tenhle ten konkrétní pod, který v tom Demon Setu je vystavený, respektive zadefinovaný, tak vystaví a spustí na každém Kubernetes nodu, který ten klaster obsahuje. Zase existují nějaké selektory a další věci, nebudeme to komplikovat. Pro jednoduchost je tohleto úplně ideální scénář právě třeba pro collecting logů, pro monitoring, potenciálně by mohl být třeba právě respektive sítěvou orchestraci, ostatně některé ingress kontrolery se deployují právě v tomto typu daemon set. Druhým z těch typů, který je využívaný, tak je tzv. stateful set, což je vlastně popis, který předpokládá, že pody, které jsou v tomto stateful setu, tak jsou stavové a ta jeho zajímavá vlastnost je ta, že V momentě, kdy Kubernetes deployují ty jednotlivé pody, a vy můžete zase zadefinovat, kolik jich má být, nemusí být pouze jeden, tak mezi sebou vnímají závislost. Ta závislost je posádaná na tom, že nevydeplují nový pod, dokud nevědí, že předchozí je v pořádku a funkční a stejně tak je zase odzadu mažou, pokud byste jejich počet redukovali. Respektive tenhle princip je velmi zajímavý použít pro distribuované databáze nebo podobné distribuované věci, kdy vlastně očekáváte, že ta distribuce probíhá postupně který se chová tím způsobem, že pody, které v něm jsou, tak chápe jako nestavové, respektive tak, že na nich v podstatě nějak zvlášť nezáleží, vznikají úplně a stejně taky zanikají naprosto nezávisle na sobě. Na druhou stranu dovolí vám definovat právě něco, co je teda počet replik, případně i něco trochu slojitějšího, čemu se říká replikaset. To je věc, která je víceméně dneska už málo využívaná, takže nebudeme se tím zbytečně zabývat. Dneska je to skutečně jednoznačně nejvyužívanější struktura, kterou zabalíte pody. Na druhou stranu, když si vzpomenete na ty ukázky, které jste viděli na začátku, není žádná nutnost ty pody jako takové do něčeho specificky balit. Můžete je samozřejmě, zvlášť v momentě, kdy z Kubernetes začínáte, tak je můžete využívat prostě as-is, tak, jak jste je třeba v minulosti měli do krech. Tak. Já se podívám ještě na dvě nebo tři témata možná v rychlosti a to jedno z nich je, že já tady celou dobu mluvím o Kubernetes, na druhou stranu jsem i při těch ukázkách, i při těch dalších vlastně, při tom dalším povídání, velmi často využíval schopnosti nějaké další komponenty, v našem případě nejčastěji registrů, vaše vlastní kontejnery. Můžete samozřejmě využívat klaudovou službu, můžete si registry využít vlastní. Typické je, že zákazníci budují registry svoje vlastní, respektive využívají registry, které stancu Kubernetes depoluje provider. Za nás je tím doporušeným scénářem využívat systém, který se jmenuje Harbor. A ten důvod, proč je tady doporučuji, je ten, že v Harboru můžete velmi jednoduchým způsobem jednak synchronizovat další jiný registry, respektive v podstatě repozitáře pro imidže a stejně tak můžete spouštět pravidelný skenování, či případně skenování při změnách a podobných situacích a sledovat tak, že imidže, které tvoříte, jsou pořád ještě bezpečné, či případně, že dodržují nějaké konkrétní bezpečnostní parametry, které jim můžete nadefinovat. Další s komponentou, kterou já jsem tady teda nezmínil, ale je velmi důležitá, je velmi zajímavá a to zejména tehdy, pokud se dostanete do stavu, kdy v Kubernetes nebudete mít pět kontejnerů, ale pětset, případně už třeba jen padesát, tak je CICD, což je Continuous Integration, Continuous Delivery vlastně systém. Ten vám dovolí, abyste i s větším množstvím a s velmi dynamickou CICD, které se říká Argo CD, hrozně mě zaujala vizualizace komponent, kterou dovoluje. Dneska v tom připravujeme úpravu nějakých poměrně složitých helmchartů, které tvoří složitou strukturu, ale my je potřebujeme trochu customizovat a od komunity do téhle míry customizované nejsou a rozhodně doporučuji například ten, či případně konkurs, který je hodně známý zase inde, či případně integraci s GitLabem. No a další s tématem je samozřejmě to využití vlastních voliumů toho systému pro ukládání dat. No a poslední doporučení, které není přímo komponentou, ale při práci s kontejnery zjistíte, že to je jedna z nejčastějších věcí, která se potom v kontejnerách řeší, tak je práce s doménovými jmény a certifikáty. Ať už právě v situaci, kdy pracujete s nějakými vnějšími registry, nebo pracujete s nějakými dalšími vnějšími, nebo případně vašimi, ale vnějšími službami, či případně s těmi vlastními kubernety, tak velká řada těch systémů kubernet, Pokud se vám někam do té cesty připlete certifikát, který nepochází úplně od ideálního vydavatele, tak se vám může stát, že řada těch právě automatických skriptů nebo případně nějakých automatických workloadů, které chcete spouštět, tak bude vyžadovat obrovské úpravy a respektive obrovské úpravy. Bude vyžadovat úpravy těch vlastních skriptů jako takových, tak abyste si vynucovali, že ta bezpečnost vlastně není důležitá. To naše doporučení je hned od začátku začít myslet na to, že chcete znát konkrétní doménová jména, ideálně doménová jména, která jsou naprosto normální, jsou skutečně veřejnou doménou, což nemusí nutně znamenat, že jsou ty služby jako takové dostupné zvenší, ale že jsou přeložitelné, což vám extrémně zjednoduší tu situaci, kdy potom chcete vystavit certifikáty a samozřejmě tím nejjednodušším způsobem a pak se zase zpátky vrátit k práci, dřele nedoporučuji. Tak, pustíme se do poslední části a to je, jak vlastně teda přejít s tou vaší aplikací. My jsme si dlouho povídali o tom, jak vypadá ta struktura Kubernetes, jaké typy tříd můžete potkat, případně využít. Zase mé doporučení je, nesnažte se o všechno, není to jednak jednoduché a ani to není nutné. To, co je tady potřeba určitě říct, je, že vlastně, a vlastně začít s tím, že začnete dělit svoji infrastrukturu jako takovou na jednotlivý dílčí části, dá se říct, že asi ve třech možných streamech. Jedna z nich je, to je moje know-how, jsem schopen jej přepsat tak, abych jej provozoval v kontejneru, i kdyby pouze v doku. a dovedu si do něj zmigrovat data, či případně zmigrovat tu vlastní schopnost, kterou nese. Druhá z nich je, jasně, tohle je něco, co komunita normálně podporuje, je to existující scénář, ať už jde o různý systémy, jako jsou databáze, Rebitiry, Redisy a podobní zdávětosti, cacheování, balancery a tak dál. A jsem schopen vlastně využít toho, že komunita takovouhle aplikaci, takovouhle funkci má a pak ji vřele použijte. No a třetí z těch částí, které se nikdy nezbavíme, a já se ani nesnažím říct, že bychom se ji v budoucnu kompletně zbavili, tak je samozřejmě část, kterou neumíme předělat, neumíme ji rozdělit, je veliká, či případně si dneska nedovedeme představit, že ji rozdělíme. A pak samozřejmě je tady pořád systémy, jako jsou baremetaly, je tady virtualizace, ta tady dál bude. Využívejte toho, že můžete virtualizaci baremetaly, ale i kontejnery, Skončím tím, s tím, čím začít. Začněte tím, že vlastně vůbec začnete. To je moje vřelé doporučení. Já jsem malinko zapomněl na to, jak s otázkami. Takže pokud jste nějaké měli a položili jste je v průběhu, tak můj plán byl je zodpovědět až na závěr. Nevím, jestli teď nějaké máme. A co se týče vlastního webináře, tak já jsem se svým obsahem u konce. Takže vám tímto děkuji za pozornost. Pokud by vás nějaké otázky napadly a chtěli byste se zeptat, určitě neváhejte se na nás obrátit. Já se budu těšit, že se sejdeme zase u nějakého dalšího webináře. Zatím vím, že plánujeme jeden další na červen a věřím, že vám včas pošleme pozvánku. Takže já se tímto loučím. Děkuji moc za pozornost a budu se těšit zase někdy v budoucnu.