Instalace Red Hat OpenShift Container Platform (OCP) 4 do AWS účtu v rámci Landing Zone organizace přináší specifická omezení, která je třeba zohlednit již při plánování instalace. Landing Zone účty jsou typicky spravovány centrálně a bývají omezeny z hlediska IAM oprávnění, síťové topologie nebo bezpečnostních politik — například zákazem veřejných S3 bucketů, restrikcí na vytváření VPC či požadavkem na použití krátkodobých credentials místo dlouhodobých IAM klíčů.

Moderní architektura založená na microservices přináší značnou provozní složitost. Jednotlivé služby jsou sice malé a nezávislé, ale ve větším systému jich mohou být desítky až stovky. Každá z nich musí řešit bezpečnost, vyvažování zátěže, monitoring a řízení provozu.
Zatímco u monolitické aplikace stačilo tyto oblasti řešit jednou, v microservices architektuře je nutné je řešit pro každou službu zvlášť. Kubernetes sice poskytuje základní podporu (např. objekt Service, L4 load balancing nebo service discovery), ale neřeší pokročilé scénáře, jako jsou:

• metriky na L7 úrovni,
• inteligentní směrování provozu,
• rate limiting,
• circuit breaking.

Samotný Kubernetes proto nestačí ke spolehlivému provozu většího počtu microservices. Jak systém roste, stává se jeho správa a observabilita stále obtížnější. Zde přichází ke slovu service mesh – dedikovaná infrastruktura, která řeší komunikaci mezi službami transparentně a centrálně, bez nutnosti zásahů do aplikačního kódu.

Vývoj AI aplikací se rychle posouvá z prototypů do reálného nasazení. Firmy hledají způsoby, jak bezpečně experimentovat s modely, integrovat je do svých DevOps procesů a zároveň udržet kontrolu nad daty i náklady. Právě zde vstupuje na scénu Podman AI Lab, novinka, která rozšiřuje funkce populárního container engine Podman o přehledné rozhraní pro práci s AI.
Podman AI Lab přináší možnost jednoduše vytvářet, spravovat a testovat AI řešení přímo lokálně – bez odesílání dat do cloudu a bez nutnosti složitých nástrojů. Pro DevOps týmy a architekty jde o výrazné zjednodušení celého procesu.

Nedávno jsem byl na schůzce s klientem, kde popisovali svou linuxovou infrastrukturu a mimo jiné zmínili, že na RHEL operačních systémech mají vypnutý SELinux. Protože téma diskuze bylo jiné, tak jsem nepoložil základní otázku: „Proč?”

Pojďme se v článku seznámit s použitím Red Hat OpenShift Local na reálném use-case. Zároveň si odpovíme na otázku, zda jeho použití naplňuje prvky antického dramatu.

Git je už dávno standardem pro správu verzí. Ale přiznejme si – kdo z nás si v něm nikdy "neustřelil nohu"? Na první pohled nenápadný překlep, špatně provedený rebase nebo špatně pojmenovaný commit… a je zle. Právě na tyhle chvíle míří nový nástroj z dílny Googlu – Jujutsu (zkráceně jj), který chce verzování zjednodušit, zpřehlednit a zpříjemnit. A to bez přetrhání pout s Gitem.

Umělá inteligence se stává součástí běžných IT operací. Firemní týmy už dávno neřeší jen to, jak model natrénovat, ale hlavně jak ho stabilně a bezpečně provozovat. A právě tady přichází na scénu Red Hat AI Inference Server – open source nástroj, který umožňuje nasazení AI modelů do produkce ve velkém měřítku, automatizovaně a v souladu s podnikovými standardy.

Red Hat Developer Hub (RHDH) je moderní portál pro vývojáře, který organizacím umožňuje mít přehled o vývoji, dokumentaci, API i procesech – vše na jednom místě. Je postaven na komunitním projektu Backstage, ale Red Hat jej vylepšuje o funkce, které jsou důležité pro enterprise prostředí: škálovatelnost, bezpečnost, podporu a snadnou integraci do existující infrastruktury.

S rozmachem mikroservisní architektury narůstá i potřeba nástrojů, které usnadní jejich správu, sledování a zabezpečení. Red Hat proto uvádí OpenShift Service Mesh 3.0, novou generaci řešení pro správu komunikace mezi službami v rámci OpenShift prostředí. Tato verze přináší výrazný posun směrem k modernímu, flexibilnímu a škálovatelnému přístupu ke správě servisní sítě.

Docker je dnes jedním z nejpoužívanějších nástrojů pro kontejnerizaci aplikací. Mnoho firem a vývojářů na něm staví svou infrastrukturu, ať už v on-premise prostředí, nebo v cloudu. Často se ale setkáváme s tím, že vývojová prostředí běží "v šuplíku pod stolem" u jednotlivých vývojářů, což může představovat riziko z hlediska spravovatelnosti a dlouhodobé udržitelnosti. Proto se objevuje otázka, zda je Docker skutečně open-source a co to může znamenat pro firmy, které na něm závisí.