Tento příspěvek byl napsán, protože naši zaměstnanci vedli poměrně hodně rozhovorů s klienty o vývoji aplikací na Kubernetes a specifikách takového vývoje na OpenShift.
Obvykle začínáme tezí, že Kubernetes je jen Kubernetes a OpenShift je již platforma Kubernetes, jako Microsoft AKS nebo Amazon EKS. Každá z těchto platforem má své výhody zaměřené na konkrétní cílové publikum. A poté se rozhovor stočí k porovnání silných a slabých stránek konkrétních platforem.
Obecně nás napadlo napsat tento příspěvek se závěrem jako „Poslouchejte, nezáleží na tom, kde spustit kód, na OpenShift nebo na AKS, na EKS, na nějakém vlastním Kubernetes nebo na jakémkoli Kubernetes (pro stručnost tomu říkejme KUK) "Je to opravdu jednoduché, tam i tam."
Poté jsme plánovali vzít nejjednodušší „Hello World“ a na jeho příkladu ukázat, co je společné a jaký je rozdíl mezi KUC a Red Hat OpenShift Container Platform (dále jen OCP nebo jednoduše OpenShift).
Když jsme však psali tento příspěvek, uvědomili jsme si, že jsme byli tak dlouho zvyklí používat OpenShift, že jsme si jednoduše neuvědomovali, jak vyrostl a proměnil se v úžasnou platformu, která se stala mnohem víc než jen distribucí Kubernetes. Máme tendenci považovat vyspělost a jednoduchost OpenShift za samozřejmost a ztrácíme ze zřetele jeho brilantnost.
Obecně platí, že nadešel čas aktivního pokání a nyní krok za krokem porovnáme zprovoznění našeho „Hello World“ na KUK a na OpenShift, a uděláme to co nejobjektivněji (dobře, kromě toho, že někdy ukážeme osobní přístup k tématu). Pokud vás zajímá čistě subjektivní názor na tuto problematiku, pak si jej můžete přečíst . A v tomto příspěvku se budeme držet faktů a pouze faktů.
Shluky
Takže náš „Hello World“ vyžaduje clustery. Okamžitě řekneme „ne“ jakémukoli veřejnému cloudu, abychom neplatili za servery, registry, sítě, přenos dat atd. Podle toho zvolíme jednoduchý jednouzlový cluster zapnutý (pro KUK) a (pro cluster OpenShift). Obě tyto možnosti se instalují opravdu snadno, ale budou vyžadovat poměrně hodně prostředků na vašem notebooku.
Montáž na KUK-e
Tak pojďme.
Krok 1 – vytvoření image kontejneru
Začněme nasazením našeho „Hello World“ do minikube. K tomu budete potřebovat:
- 1. Docker nainstalován.
- 2. Git nainstalován.
- 3. Nainstalovaný Maven (ve skutečnosti tento projekt používá binární soubor mvnw, takže se bez něj obejdete).
- 4. Vlastně samotný zdroj, tzn. klon úložiště
Prvním krokem je vytvoření projektu Quarkus. Nelekejte se, pokud jste s Quarkus.io nikdy nepracovali – je to snadné. Stačí si vybrat komponenty, které chcete v projektu použít (RestEasy, Hibernate, Amazon SQS, Camel atd.), a pak sám Quarkus bez vaší účasti nakonfiguruje maven archetyp a vše vloží na github. To znamená doslova jedno kliknutí myší a máte hotovo. To je důvod, proč milujeme Quarkus.
Nejjednodušší způsob, jak zabudovat náš „Hello World“ do obrazu kontejneru, je použít rozšíření quarkus-maven pro Docker, která udělají veškerou potřebnou práci. S příchodem Quarkusu se to stalo opravdu snadným a jednoduchým: přidejte rozšíření container-image-docker a můžete vytvářet obrázky pomocí příkazů maven.
./mvnw quarkus:add-extension -Dextensions=”container-image-docker”
Nakonec si vytvoříme image pomocí Maven. Výsledkem je, že se náš zdrojový kód změní na hotový obrázek kontejneru, který již lze spustit v běhovém prostředí kontejneru.
./mvnw -X clean package -Dquarkus.container-image.build=true
To je vše, nyní můžete spustit kontejner pomocí příkazu docker run a namapovat naši službu na port 8080, aby k ní byl přístup.
docker run -i — rm -p 8080:8080 gcolman/quarkus-hello-world
Po spuštění instance kontejneru zbývá pouze zkontrolovat pomocí příkazu curl, že naše služba běží:
Takže vše funguje a bylo to opravdu snadné a jednoduché.
Krok 2 – odešlete náš kontejner do úložiště obrázků kontejneru
Obraz, který jsme vytvořili, je prozatím uložen lokálně, v našem místním kontejnerovém úložišti. Pokud chceme tento obrázek použít v našem prostředí COOK, musí být umístěn v nějakém jiném úložišti. Kubernetes takové funkce nemá, takže použijeme dockerhub. Protože za prvé je to zdarma a za druhé to dělá (skoro) každý.
To je také velmi jednoduché a vše, co potřebujete, je účet dockerhub.
Takže nainstalujeme dockerhub a pošleme tam náš obrázek.
Krok 3 – spusťte Kubernetes
Existuje mnoho způsobů, jak sestavit konfiguraci kubernetes pro spuštění našeho „Ahoj světe“, ale my použijeme ten nejjednodušší z nich, tak jsme...
Nejprve spustíme cluster minikube:
minikube start
Krok 4 – nasaďte náš obrázek kontejneru
Nyní musíme převést náš kód a obrázek kontejneru do konfigurací kubernetes. Jinými slovy, potřebujeme pod a definici nasazení ukazující na náš obrázek kontejneru na dockerhubu. Jedním z nejjednodušších způsobů, jak toho dosáhnout, je spustit příkaz create deployment ukazující na náš obrázek:
kubectl create deployment hello-quarkus — image =gcolman/quarkus-hello-world:1.0.0-SNAPSHOT
Tímto příkazem jsme řekli našemu COO, aby vytvořil konfiguraci nasazení, která by měla obsahovat specifikaci podu pro náš obrázek kontejneru. Tento příkaz také použije tuto konfiguraci na náš cluster minikube a vytvoří nasazení, které stáhne náš obrázek kontejneru a spustí modul v clusteru.
Krok 5 – otevření přístupu k naší službě
Nyní, když máme nasazenou image kontejneru, je čas přemýšlet o tom, jak nakonfigurovat externí přístup k této službě Restful, která je ve skutečnosti naprogramována v našem kódu.
Zde je mnoho způsobů. Můžete například použít příkaz expose k automatickému vytvoření příslušných součástí Kubernetes, jako jsou služby a koncové body. Ve skutečnosti provedeme toto provedením příkazu expose pro náš objekt nasazení:
kubectl expose deployment hello-quarkus — type=NodePort — port=8080
Pojďme se na chvíli podívat na volbu "-type" příkazu expose.
Když odhalujeme a vytváříme komponenty nezbytné pro provoz naší služby, mimo jiné potřebujeme být schopni se zvenčí připojit ke službě hello-quarkus, která je umístěna v naší softwarově definované síti. A parametr typ nám umožňuje vytvářet a propojovat věci, jako jsou nástroje pro vyrovnávání zatížení, které směrují provoz do této sítě.
Například psaním type=LoadBalancer, automaticky poskytujeme nástroj pro vyrovnávání zatížení ve veřejném cloudu pro připojení k našemu clusteru Kubernetes. To je samozřejmě skvělé, ale musíte pochopit, že taková konfigurace bude přísně vázána na konkrétní veřejný cloud a bude obtížnější ji přenášet mezi instancemi Kubernetes v různých prostředích.
V našem příkladu type=NodePort, to znamená, že naše služba je přístupná pomocí IP adresy uzlu a čísla portu. Tato možnost vám umožňuje nepoužívat žádné veřejné cloudy, ale vyžaduje řadu dalších kroků. Za prvé potřebujete svůj vlastní nástroj pro vyrovnávání zatížení, takže nástroj pro vyrovnávání zatížení NGINX nasadíme do našeho clusteru.
Krok 6 – nainstalujte load balancer
minikube má řadu funkcí platformy, které usnadňují vytváření externě přístupných komponent, jako jsou řadiče vstupu. Minikube je dodáván s řadičem vstupu Nginx a vše, co musíme udělat, je povolit a nakonfigurovat.
minikube addons enable ingress
Nyní vytvoříme řadič vstupu Nginx pomocí jediného příkazu, který bude fungovat v našem clusteru minikube:
ingress-nginx-controller-69ccf5d9d8-j5gs9 1/1 Running 1 33m
Krok 7 – Nastavení vstupu
Nyní musíme nakonfigurovat řadič vstupu Nginx tak, aby přijímal požadavky hello-quarkus.
A nakonec musíme tuto konfiguraci použít.
kubectl apply -f ingress.yml
Protože to všechno děláme na našem vlastním počítači, jednoduše přidáme IP adresu našeho uzlu do souboru /etc/ hosts, abychom směrovali http požadavky do našeho minikube do nástroje pro vyrovnávání zatížení NGINX.
192.168.99.100 hello-quarkus.info
To je vše, nyní je naše služba minikube přístupná externě prostřednictvím řadiče vstupu Nginx.
No, to bylo snadné, že? Nebo ne tolik?
Běží na OpenShift (kontejnery připravené na kód)
Nyní se podívejme, jak se to všechno dělá na Red Hat OpenShift Container Platform (OCP).
Stejně jako u minikube volíme jednouzlový design clusteru OpenShift ve formě kontejnerů připravených na kód (CRC). Dříve se jmenoval minishift a byl založen na projektu OpenShift Origin, ale nyní je to CRC a je postaven na OpenShift Container Platform společnosti Red Hat.
Zde si, promiň, nemůžeme pomoct, než říci: „OpenShift je úžasný!“
Původně nás napadlo napsat, že vývoj na OpenShift se neliší od vývoje na Kubernetes. A v podstatě to tak je. Ale v procesu psaní tohoto příspěvku jsme si vzpomněli, kolik dalších pohybů musíte udělat, když nemáte OpenShift, a proto je to opět skvělé. Milujeme, když se vše dělá snadno, a jak snadné je nasazení a spuštění našeho příkladu na OpenShift ve srovnání s minikube, je to, co nás přimělo napsat tento příspěvek.
Pojďme si projít procesem a uvidíme, co musíme udělat.
Takže v příkladu minikube jsme začali s Dockerem... Počkejte, už nepotřebujeme Docker nainstalovaný na počítači.
A nepotřebujeme místní git.
A Maven není potřeba.
A nemusíte vytvářet obrázek kontejneru ručně.
A nemusíte hledat žádné úložiště obrázků kontejnerů.
A není potřeba instalovat vstupní kontrolér.
A nemusíte ani konfigurovat vstup.
Rozumíš, že? K nasazení a spuštění naší aplikace na OpenShift nepotřebujete nic z výše uvedeného. A samotný proces vypadá takto.
Krok 1 – Spusťte cluster OpenShift
Používáme Code Ready Containers od Red Hat, což je v podstatě stejný Minikube, ale pouze s plnohodnotným jednouzlovým clusterem Openshift.
crc start
Krok 2 – Sestavte a nasaďte aplikaci do clusteru OpenShift
Právě v tomto kroku se ukazuje jednoduchost a pohodlí OpenShift v celé své kráse. Stejně jako u všech distribucí Kubernetes máme mnoho způsobů, jak spustit aplikaci v clusteru. A stejně jako v případě KUK konkrétně vybíráme ten nejjednodušší.
OpenShift byl vždy postaven jako platforma pro vytváření a provozování kontejnerizovaných aplikací. Budování kontejnerů bylo vždy nedílnou součástí této platformy, takže existuje spousta dalších zdrojů Kubernetes pro související úkoly.
Budeme používat proces Source 2 Image (S2I) OpenShift, který má několik různých způsobů, jak vzít náš zdrojový kód (kód nebo binární soubory) a převést jej na kontejnerový obrázek, který běží na clusteru OpenShift.
K tomu potřebujeme dvě věci:
- Náš zdrojový kód je v úložišti git
- Obrázek tvůrce, na jehož základě bude sestavení provedeno.
Existuje mnoho takových obrazů spravovaných jak Red Hatem, tak na úrovni komunity a my budeme používat obraz OpenJDK, protože já stavím Java aplikaci.
Sestavení S2I můžete spustit jak z grafické konzole OpenShift Developer, tak z příkazového řádku. Použijeme příkaz new-app, který mu řekne, kde získat obrázek tvůrce a náš zdrojový kód.
oc new-app registry.access.redhat.com/ubi8/openjdk-11:latest~https://github.com/gcolman/quarkus-hello-world.git
To je vše, naše aplikace je vytvořena. Přitom proces S2I provedl následující věci:
- Vytvořil servisní build-pod pro všechny druhy věcí souvisejících s vytvářením aplikace.
- Vytvořil konfiguraci OpenShift Build.
- Stáhl jsem si obrázek builderu do interního registru dockeru OpenShift.
- Klonováno „Hello World“ do místního úložiště.
- Viděl jsem, že tam byl maven pom, tak jsem zkompiloval aplikaci pomocí maven.
- Vytvořil nový obrázek kontejneru obsahující zkompilovanou aplikaci Java a vložil tento obrázek do interního registru kontejnerů.
- Vytvořeno nasazení Kubernetes se specifikacemi pro pod, službu atd.
- Začal jsem nasazovat image kontejneru.
- Byl odstraněn modul pro sestavení služby.
Na tomto seznamu je toho hodně, ale hlavní věc je, že celé sestavení probíhá výhradně uvnitř OpenShift, interní registr Dockeru je uvnitř OpenShift a proces sestavení vytváří všechny komponenty Kubernetes a spouští je v clusteru.
Pokud vizuálně sledujete spuštění S2I v konzole, můžete vidět, jak se modul sestavení spouští po dokončení sestavení.
Nyní se podívejme na protokoly builder pod: za prvé, ukazuje, jak maven dělá svou práci a stahuje závislosti pro vytvoření naší java aplikace.
Po dokončení sestavení maven se spustí sestavení obrazu kontejneru a poté se tento vytvořený obraz odešle do interního úložiště.
To je vše, proces sestavení je dokončen. Nyní se ujistěte, že moduly a služby naší aplikace běží v clusteru.
oc get service
To je vše. A jen jeden tým. Jediné, co musíme udělat, je vystavit tuto službu pro přístup zvenčí.
Krok 3 – vystavte službu přístupu zvenčí
Stejně jako v případě KUC, na platformě OpenShift potřebuje náš „Hello World“ také router, který směruje externí provoz na službu v rámci clusteru. OpenShift to velmi usnadňuje. Za prvé, směrovací komponenta HAProxy je standardně nainstalována v clusteru (lze ji změnit na stejný NGINX). Za druhé, existují speciální a vysoce konfigurovatelné zdroje zvané Routes a připomínající objekty Ingress ve starých dobrých Kubernetes (ve skutečnosti Routes OpenShift výrazně ovlivnily design objektů Ingress, které lze nyní použít v OpenShift), ale pro náš „Hello World“ , a téměř ve všech ostatních případech nám stačí standardní Route bez dodatečné konfigurace.
Chcete-li vytvořit směrovatelný FQDN pro „Hello World“ (ano, OpenShiift má svůj vlastní DNS pro směrování podle názvů služeb), jednoduše vystavíme naši službu:
oc expose service quarkus-hello-world
Pokud se podíváte na nově vytvořenou trasu, najdete tam FQDN a další informace o směrování:
oc get route
A nakonec přistupujeme k naší službě z prohlížeče:
Ale teď to bylo opravdu snadné!
Milujeme Kubernetes a vše, co nám tato technologie umožňuje, a také milujeme jednoduchost a snadnost. Kubernetes byl vytvořen, aby neuvěřitelně zjednodušil provoz distribuovaných, škálovatelných kontejnerů, ale jeho jednoduchost už dnes nestačí na uvedení aplikací do produkce. Zde vstupuje do hry OpenShift, který drží krok s dobou a nabízí Kubernetes zaměřený především na vývojáře. Mnoho úsilí bylo investováno do přizpůsobení platformy OpenShift speciálně pro vývojáře, včetně vytvoření nástrojů, jako je S2I, ODI, Developer Portal, OpenShift Operator Framework, integrace IDE, katalogy pro vývojáře, integrace Helm, monitorování a mnoho dalších.
Doufáme, že tento článek byl pro vás zajímavý a užitečný. Další zdroje, materiály a další věci užitečné pro vývoj na platformě OpenShift najdete na portálu .
Zdroj: www.habr.com