Čím dál tím častěji se ve své práci setkáváme s požadavky na provoz aplikací v kontejnerech. Není to jen požadavek vývojářů, kteří mají rádi vše nové, ale i potřeba IT provozu mít jednotnou platformu, která poskytuje co nejvíce prostoru vývojářům při zachování provozních parametrů, zejména bezpečnosti a dostupnosti. Díky kontejnerům je spokojený i "byznys", protože nasazení požadovaných změn v aplikacích trvá výrazně kratší dobu.
Takový ideální scénář však v praxi naráží na několik překážek. Jednou z nich je nekoordinované nasazení kontejnerové platformy. Obvykle s kontejnery přichází vývojáři. A je to pochopitelné, protože nainstalovat si Docker a začít tvořit kontejnery s aplikacemi je velmi snadné a kontejnerizací jim odpadnou problémy, se kterými se dosud potýkali.
Svou práci (nové aplikace nebo jejich úpravy) jsou schopni odevzdat formou kódu včetně prostředí, a to v kontejneru, který je prakticky nezávislý na okolním světě. Toto řešení má velké výhody v podobě přenositelnosti mezi různými běhovými prostředími (firemní infrastruktura, veřejný cloud nebo počítač kolegy) a jasně popsanými závislostmi. Jenže existence kontejneru nestačí, je nutné ho někde provozovat, a to už je úloha pro lidi z IT provozu.
Zdánlivě správné řešení
Na základě zadání vývojářů začne IT provoz budovat platformu pro provoz kontejnerů. Když si osahají Docker a zamyslí se nad požadavky na tuto platformu, musí zákonitě dospět k rozhodnutí, že je nutné postavit platformu, která bude umět koordinovat běh velkého množství kontejnerů, řešit jejich startování, distribuci mezi různými servery a škálování aplikací. A tak sáhnou po Kubernetes, platformě pro orchestraci kontejnerů, která je vyvíjena pro řešení těchto požadavků.
Vzniká tak vysoce dostupná, orchestrovatelná platforma pro provoz kontejnerů, závislostí mezi nimi, jejich správou a organizací. Kontejnerizovaných aplikací přibývá, platforma roste a stává se z ní důležitá součást firemního prostředí. A objevují se další požadavky – na straně IT provozu roste potřeba standardního kontejnerového vybavení, jako jsou verze
programovacích jazyků nebo nastavení a zajištění bezpečnosti, monitoring platformy a škálování. Na straně vývojářů jsou to požadavky na automatizaci CI/CD procesů do platformy. Společným jmenovatelem jsou ale rostoucí nároky na pracnost na obou těchto frontách.
Vývojáři chtějí rychleji vyvíjet a měnit prostředí, IT provoz nestíhá jejich požadavky zapracovávat a zároveň udržovat celou platformu aktuální a bezpečnou. Navíc změny v nástrojích pro správu kontejnerů, Kubernetes a dalších komponentech probíhají velmi rychle a zvyšují nároky na znalosti i nasazení pracovníků IT provozu. Celá platforma se začíná nafukovat, její komplexita roste, stejně jako její závislost na několika lidech s vysokou odborností, což může být nebezpečné.
A zde výrazně roste riziko, že jednoho dne přestane něco fungovat a člověk s odbornou znalostí nebude v dosahu. V lepším případě ho někdo alespoň částečně zastoupí, v horším případě chyba zasáhne "byznys".
Mýty a fakta
Nesčetně organizací si při hledání vhodného řešení kontejnerové platformy prošlo stejnou cestou. A tak plně v souladu s principem otevřenosti se poučme z dosavadních omylů a řiďme se ověřenými postupy. Mezi ty nejvíce diskutované omyly patří i dojem, že komunitní, nepodporované verze technologií či produktů jsou zdarma.
Ano, to sice jsou, ale ve výsledku vyjde implementace výrazně dráž než technologie od prověřeného, spolehlivého partnera. Důvod je jednoduchý, komunitní verze se velmi rychle mění, je potřeba často provádět změny v prostředí a aktualizovat. Není na koho se obrátit, když je potřeba, a je zde více práce s obsahem. Oproti tomu v produktizované verzi je už vše připraveno k nasazení do produkce včetně vždy dostupné technické i vzdělávací podpory partnera.
Vyplatí se zamyslet i nad tím, nakolik je zvažovaná platforma kompatibilní s jinými technologiemi. Možnost volby a případné změny použitých nástrojů a využití všeho, co je nejen dnes, ale bude i v budoucnu k dispozici, je zcela zásadní.
Setkáváme se i s názorem, že stačí „mít“ jenom kontejnery, bez komplexnějšího přístupu v podobě spolupráce a integrace mezi vývojáři a IT odborníky z provozu. Například Openshift toto umožňuje, ale jak z praxe víme, vzájemná závislost vývoje softwaru a IT provozu je nepopiratelná, a tak dříve či později vás potřeba DevOps přístupu dožene. Začněte ji raději uplatňovat hned od počátku. I zde jsou důvody prosté, pouze kontejnery s Kubernetes nebo podobné technologie nestačí.
Jejich použití nepokryje reálné požadavky na vývoj a provoz aplikací. CI/CD, Jenkins, Maven, Java, audit, SDN, security, multitenancy – to je jen část témat, která v reálném provozu budete řešit, a pouze sofistikovaná platforma vám je pomůže efektivně orchestrovat. Zároveň pro vývojáře aplikací jsou zajímavé nové postupy a technologie jako serverless, AI/ML, zprostředkování služeb a API dalším vývojářům a podobně. V takovém případě se hodí podpora OpenShiftu pro jednoduchou instalaci a práci s těmito technologiemi buď s podporou Red Hatu nebo komunit kolem těchto technologií.
OpenShift spojuje všechny tyto aspekty a požadavky na provoz aplikací v kontejnerech do jednoho celku tak, aby usnadnil práci nejen oběma světům – vývojářům a IT provozu, ale především umožnil balancovat provoz, jednoduše spravovat kontejnery, koordinovat všechny procesy a zároveň mít kontrolu nad celou infrastrukturou a jejími prostředky.
Autor: Radek Vokal, senior engineer manager, Red Hat