{"id":97254,"date":"2020-10-17T02:42:32","date_gmt":"2020-10-17T00:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe"},"modified":"2020-10-17T02:42:32","modified_gmt":"2020-10-17T00:42:32","slug":"prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"Przykro mi, OpenShift, za ma\u0142o ci\u0119 doceniali\u015bmy i traktowali\u015bmy jako rzecz oczywist\u0105","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ten post zosta\u0142 napisany, poniewa\u017c nasi pracownicy mieli wiele rozm\u00f3w z klientami na temat tworzenia aplikacji w Kubernetes oraz specyfiki takiego rozwoju na OpenShift.<\/p>\n

\"Przykro
\n
\nZwykle zaczynamy od tezy, \u017ce Kubernetes to po prostu Kubernetes, a OpenShift to ju\u017c platforma Kubernetes, jak Microsoft AKS czy Amazon EKS. Ka\u017cda z tych platform ma swoje zalety, ukierunkowane na r\u00f3\u017cne grupy docelowe. A p\u00f3\u017aniej rozmowa p\u0142ynnie przechodzi w por\u00f3wnanie mocnych i s\u0142abych stron konkretnych platform.
\n<\/a><\/noindex>
\nOg\u00f3lnie rzecz bior\u0105c, my\u015bleli\u015bmy o napisaniu tego posta z wnioskiem w stylu: \u201eS\u0142uchajcie, gdzie uruchamia\u0107 kod, na OpenShift czy na AKS, EKS, jakim\u015b dostosowanym Kubernetes, czy na jakimkolwiek Kubernetes, to naprawd\u0119 nie ma znaczenia\u201d. (dla skr\u00f3tu nazwijmy to KUK)<\/i> \u2013 to naprawd\u0119 proste zar\u00f3wno tam, jak i tam.<\/p>\n

Nast\u0119pnie planowali\u015bmy wzi\u0105\u0107 najprostsz\u0105 aplikacj\u0119 \u201eHello World\u201d i na jej przyk\u0142adzie pokaza\u0107, co jest wsp\u00f3lnego i jakie s\u0105 r\u00f3\u017cnice mi\u0119dzy KUK a Red Hat OpenShift Container Platform (dalej, OCP lub po prostu OpenShift).<\/p>\n

Jednak w trakcie pisania tego posta zrozumieli\u015bmy, \u017ce tak bardzo przywykli\u015bmy do korzystania z OpenShift, \u017ce po prostu nie dostrzegamy, jak bardzo si\u0119 rozwin\u0105\u0142 i sta\u0142 niesamowit\u0105 platform\u0105, kt\u00f3ra sta\u0142a si\u0119 czym\u015b wi\u0119cej ni\u017c tylko dystrybucj\u0105 Kubernetes. Przyzwyczaili\u015bmy si\u0119 traktowa\u0107 dojrza\u0142o\u015b\u0107 i prostot\u0119 OpenShift jako co\u015b naturalnego, pomijaj\u0105c jego wspania\u0142o\u015b\u0107.<\/p>\n

Czas na aktywne zado\u015b\u0107uczynienie, a teraz krok po kroku por\u00f3wnamy wprowadzenie do dzia\u0142ania naszego \u201eHello World\u201d na KUK i na OpenShift, i zrobimy to jak najbardziej obiektywnie (cho\u0107 czasami wyra\u017caj\u0105c osobiste zainteresowanie tematem). Je\u015bli interesuje Ci\u0119 wy\u0142\u0105cznie subiektywna opinia na ten temat, to mo\u017cna j\u0105 przeczyta\u0107. tutaj (EN)<\/a><\/noindex>. A w tym po\u015bcie b\u0119dziemy trzyma\u0107 si\u0119 fakt\u00f3w i tylko fakt\u00f3w.<\/p>\n

Klastery<\/h3>\n

\nWi\u0119c do naszego \u201eHello World\u201d potrzebne s\u0105 klastry. Od razu m\u00f3wimy \u201enie\u201d wszelkim publicznym chmurom, aby nie p\u0142aci\u0107 za serwery, rejestry, sieci, transfer danych itp. W zwi\u0105zku z tym wybieramy proste, jednouwzgl\u0119dnione klastry na Minikube<\/a><\/noindex> (dla KUK) oraz Code Ready Containers<\/a><\/noindex> (dla klastra OpenShift). Oba te warianty s\u0105 naprawd\u0119 proste w instalacji, ale wymagaj\u0105 sporo zasob\u00f3w na Twoim laptopie.<\/p>\n

\"Przykro<\/p>\n

Budowanie na KUK<\/h3>\n

\nNo to zaczynajmy.<\/p>\n

Krok 1 \u2013 budujemy nasz obraz kontenera<\/h4>\n

\nZacznijmy od tego, \u017ce uruchomimy nasze \u201eHello World\u201d na minikube. W tym celu potrzebne b\u0119d\u0105:<\/p>\n

    \n
  1. 1. Zainstalowany Docker.<\/li>\n
  2. 2. Zainstalowany Git.<\/li>\n
  3. 3. Zainstalowany Maven (tak naprawd\u0119 w tym projekcie u\u017cywany jest binarka mvnw, wi\u0119c mo\u017cna to pomin\u0105\u0107).<\/li>\n
  4. 4. Sam kod \u017ar\u00f3d\u0142owy, czyli klon repozytorium github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nNa pocz\u0105tku musimy stworzy\u0107 projekt Quarkus. Nie martwcie si\u0119, je\u015bli nigdy nie pracowali\u015bcie z stron\u0105 Quarkus.io \u2013 to jest proste. Wystarczy wybra\u0107 komponenty, kt\u00f3re chcecie u\u017cy\u0107 w projekcie (RestEasy, Hibernate, Amazon SQS, Camel itp.), a nast\u0119pnie Quarkus samodzielnie, bez waszego udzia\u0142u, skonfiguruje archetyp maven i umie\u015bci wszystko na githubie. To znaczy, dos\u0142ownie jeden klik myszk\u0105 \u2013 i gotowe. Za to w\u0142a\u015bnie kochamy Quarkus.<\/p>\n

    \"Przykro<\/p>\n

    Najprostszym sposobem na zbudowanie naszego \"Hello World\" w obrazie kontenera \u2013 jest u\u017cycie rozszerze\u0144 quarkus-maven dla Dockera, kt\u00f3re wykonaj\u0105 ca\u0142\u0105 niezb\u0119dn\u0105 prac\u0119. Z pojawieniem si\u0119 Quarkus to naprawd\u0119 sta\u0142o si\u0119 \u0142atwe i proste: dodajecie rozszerzenie container-image-docker i mo\u017cecie tworzy\u0107 obrazy za pomoc\u0105 polece\u0144 maven.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \nA teraz przeprowadzamy budow\u0119 naszego obrazu, u\u017cywaj\u0105c Maven. W wyniku nasz kod \u017ar\u00f3d\u0142owy zostaje przekszta\u0142cony w gotowy obraz kontenera, kt\u00f3ry mo\u017cna ju\u017c uruchomi\u0107 w \u015brodowisku wykonywania kontener\u00f3w.<\/p>\n
    \"Przykro<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nOto, i wszystko, teraz mo\u017cna uruchomi\u0107 kontener poleceniem docker run, mapuj\u0105c nasz\u0105 us\u0142ug\u0119 na port 8080, aby mo\u017cna by\u0142o si\u0119 do niej odwo\u0142a\u0107.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"Przykro<\/p>\n
    Po uruchomieniu instancji kontenera wystarczy tylko sprawdzi\u0107 poleceniem curl, czy nasza us\u0142uga dzia\u0142a:<\/p>\n
    \"Przykro<\/p>\n
    Tak wi\u0119c, wszystko dzia\u0142a i naprawd\u0119 by\u0142o to \u0142atwe i proste.<\/p>\n
    Krok 2 \u2013 wysy\u0142amy nasz kontener do repozytorium obraz\u00f3w kontener\u00f3w<\/h4>\n
    \nJak dot\u0105d nasz stworzony obraz jest przechowywany lokalnie, w naszym lokalnym repozytorium kontener\u00f3w. Je\u015bli chcemy u\u017cywa\u0107 tego obrazu w naszym \u015brodowisku K8S, musimy go umie\u015bci\u0107 w jakim\u015b innym repozytorium. W Kubernetes nie ma takich funkcji, wi\u0119c b\u0119dziemy u\u017cywa\u0107 dockerhub. Po pierwsze, jest darmowy, a po drugie, (prawie) wszyscy tak robi\u0105.<\/p>\n
    To r\u00f3wnie\u017c jest bardzo proste i potrzebne jest tutaj tylko konto na dockerhubie.<\/p>\n
    A wi\u0119c logujemy si\u0119 do dockerhub i wysy\u0142amy tam nasz obraz.<\/p>\n
    \"Przykro<\/p>\n
    Krok 3 \u2013 uruchamiamy Kubernetes<\/h4>\n
    \nIstnieje wiele sposob\u00f3w na z\u0142o\u017cenie konfiguracji kubernetes do uruchomienia naszego \"Hello World\", ale skorzystamy z najprostszej z nich, tacy ju\u017c jeste\u015bmy...<\/p>\n
    Na pocz\u0105tek uruchamiamy klaster minikube:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Krok 4 - wdra\u017camy nasz obraz kontenera<\/h4>\n
    \nTeraz musimy przekszta\u0142ci\u0107 nasz kod i obraz kontenera na konfiguracje kubernetes. Innymi s\u0142owy, potrzebujemy definicji pod i deploymentu wskazuj\u0105cej na nasz obraz na dockerhub. Jednym z najprostszych sposob\u00f3w, aby to zrobi\u0107, jest uruchomienie polecenia create deployment, wskazuj\u0105c na nasz obraz:<\/p>\n
    \"Przykro<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nTym poleceniem powiedzieli\u015bmy naszemu KUBECIE stworzy\u0107 konfiguracj\u0119 deploymentu, kt\u00f3ra powinna zawiera\u0107 specyfikacj\u0119 pod'a dla naszego obrazu kontenera. To polecenie r\u00f3wnie\u017c zastosuje t\u0119 konfiguracj\u0119 do naszego klastra minikube i stworzy deployment, kt\u00f3ry pobierze nasz obraz kontenera i uruchomi pod w klastrze.<\/p>\n
    Krok 5 - otwieramy dost\u0119p do naszego serwisu<\/h4>\n
    \nTeraz, gdy mamy wdro\u017cony obraz kontenera, czas pomy\u015ble\u0107, jak skonfigurowa\u0107 zewn\u0119trzny dost\u0119p do tego serwisu Restful, kt\u00f3ry rzeczywi\u015bcie jest zaprogramowany w naszym kodzie.<\/p>\n
    Jest wiele sposob\u00f3w na to. Na przyk\u0142ad, mo\u017cna u\u017cy\u0107 polecenia expose, aby automatycznie stworzy\u0107 odpowiednie komponenty Kubernetes, takie jak us\u0142ugi i punkty ko\u0144cowe. W\u0142a\u015bnie tak zamierzamy zrobi\u0107, wykonuj\u0105c polecenie expose dla naszego obiektu deployment:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nZatrzymajmy si\u0119 na chwil\u0119 przy opcji \"--type\" polecenia expose.<\/p>\n
    Kiedy wykonujemy expose i tworzymy komponenty niezb\u0119dne do uruchomienia naszego serwisu, musimy, mi\u0119dzy innymi, zapewni\u0107, \u017ce na zewn\u0105trz mo\u017cliwe b\u0119dzie po\u0142\u0105czenie z us\u0142ug\u0105 hello-quarkus, kt\u00f3ra znajduje si\u0119 w naszej definiowanej programowo sieci. I parametr type<\/b> pozwala nam stworzy\u0107 i po\u0142\u0105czy\u0107 takie rzeczy, jak load balancery, aby kierowa\u0107 ruch do tej sieci.<\/p>\n
    Na przyk\u0142ad, wpisuj\u0105c type=LoadBalancer<\/b>, automatycznie inicjujemy load balancer w publicznej chmurze, aby po\u0142\u0105czy\u0107 si\u0119 z naszym klastrem Kubernetes. To, oczywi\u015bcie, wspaniale, ale trzeba rozumie\u0107, \u017ce taka konfiguracja b\u0119dzie \u015bci\u015ble zwi\u0105zana z konkretn\u0105 publiczn\u0105 chmur\u0105 i b\u0119dzie trudniejsza do przenoszenia mi\u0119dzy instancjami Kubernetes w r\u00f3\u017cnych \u015brodowiskach.<\/p>\n
    W naszym przyk\u0142adzie type=NodePort<\/b>, czyli dost\u0119p do naszej us\u0142ugi odbywa si\u0119 za po\u015brednictwem adresu IP i numeru portu w\u0119z\u0142a. Ta opcja pozwala na niekorzystanie z \u017cadnych publicznych chmur, ale wymaga kilku dodatkowych krok\u00f3w. Po pierwsze, potrzebny jest w\u0142asny load balancer, dlatego wdro\u017cymy w naszym klastrze load balancer NGINX.<\/p>\n
    Krok 6 \u2013 instalacja load balancera<\/h4>\n
    \nMinikube ma szereg funkcji platformowych, u\u0142atwiaj\u0105cych tworzenie wymaganych komponent\u00f3w do zewn\u0119trznego dost\u0119pu, takich jak kontrolery ingress. Minikube dostarczany jest z kontrolerem ingress Nginx, wi\u0119c wystarczy go tylko w\u0142\u0105czy\u0107 i skonfigurowa\u0107.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nTeraz za pomoc\u0105 jednego polecenia utworzymy kontroler ingress Nginx, kt\u00f3ry b\u0119dzie dzia\u0142a\u0142 wewn\u0105trz naszego klastra minikube:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Krok 7 \u2013 konfiguracja ingress<\/h4>\n
    \nTeraz musimy skonfigurowa\u0107 kontroler ingress Nginx, aby obs\u0142ugiwa\u0142 \u017c\u0105dania hello-quarkus.<\/p>\n
    \"Przykro<\/p>\n
    \"Przykro<\/p>\n
    I w ko\u0144cu musimy zastosowa\u0107 t\u0119 konfiguracj\u0119.<\/p>\n
    \"Przykro<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"Przykro<\/p>\n
    Poniewa\u017c robimy to wszystko na swoim komputerze, po prostu dodajemy adres IP swojego w\u0119z\u0142a do pliku \/etc\/hosts, aby kierowa\u0107 \u017c\u0105dania http do naszego minikube na load balancer NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nGotowe, teraz nasza us\u0142uga minikube jest dost\u0119pna z zewn\u0105trz przez kontroler ingress Nginx.<\/p>\n
    \"Przykro<\/p>\n
    No c\u00f3\u017c, to by\u0142o \u0142atwe, prawda? A mo\u017ce nie za bardzo?<\/h3>\n
    \"Przykro<\/p>\n
    Uruchomienie na OpenShift (Code Ready Containers)<\/h3>\n
    \nA teraz zobaczmy, jak to wszystko dzia\u0142a na platformie Red Hat OpenShift Container Platform (OCP).<\/p>\n
    Podobnie jak w przypadku minikube, wybieramy schemat z jedno w\u0119z\u0142owym klastrem OpenShift w formie Code Ready Containers (CRC). Wcze\u015bniej nazywa\u0142o si\u0119 to minishift i by\u0142o oparte na projekcie OpenShift Origin, teraz to CRC i jest zbudowane na platformie Red Hat OpenShift Container.<\/p>\n
    Tutaj, przepraszamy, nie mo\u017cemy powstrzyma\u0107 si\u0119 od powiedzenia: \u201eOpenShift jest wspania\u0142y!\u201d<\/p>\n
    Pocz\u0105tkowo my\u015bleli\u015bmy, \u017ce napisanie, i\u017c rozw\u00f3j na OpenShift niczym si\u0119 nie r\u00f3\u017cni od rozwoju na Kubernetes, b\u0119dzie zasadne. I w zasadzie tak jest. Jednak podczas pisania tego posta przypomnieli\u015bmy sobie, ile zb\u0119dnych ruch\u00f3w trzeba wykona\u0107, gdy nie masz OpenShift, dlatego powtarzamy: jest wspania\u0142y. Lubimy, gdy wszystko dzieje si\u0119 \u0142atwo, a to, jak prosto w por\u00f3wnaniu do minikube wdra\u017ca si\u0119 i uruchamia nasz przyk\u0142ad na OpenShift, sk\u0142oni\u0142o nas do napisania tego posta.<\/p>\n
    Przejd\u017amy do procesu i sprawd\u017amy, co b\u0119dziemy musieli zrobi\u0107.<\/p>\n
    Zatem w przyk\u0142adzie z minikube zaczynali\u015bmy od Dockera\u2026 Chwileczk\u0119, nie potrzebujemy ju\u017c, aby Docker by\u0142 zainstalowany na maszynie.<\/p>\n
    I lokalny git nie jest nam potrzebny.
    \nI Maven nie jest potrzebny.
    \nNie musimy te\u017c r\u0119cznie tworzy\u0107 obrazu kontenera.
    \nNie musimy szuka\u0107 jakiego\u015b repozytorium obraz\u00f3w kontenerowych.
    \nNie musimy te\u017c instalowa\u0107 kontrolera ingress.
    \nKonfiguracja ingress r\u00f3wnie\u017c nie jest konieczna.<\/b><\/p>\n
    Rozumiesz, tak? Aby wdro\u017cy\u0107 i uruchomi\u0107 nasz\u0105 aplikacj\u0119 na OpenShift, nie potrzebujemy nic z wymienionych wcze\u015bniej rzeczy. A sam proces wygl\u0105da nast\u0119puj\u0105co.<\/p>\n
    Krok 1 \u2013 Uruchamiamy sw\u00f3j klaster OpenShift<\/h4>\n
    \nU\u017cywamy Code Ready Containers od Red Hat, kt\u00f3ry w zasadzie jest tym samym co Minikube, ale oferuje pe\u0142noprawny jednolity klaster Openshift.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Krok 2 \u2013 Wykonujemy budow\u0119 i wdro\u017cenie aplikacji w klastrze OpenShift<\/h4>\n
    \nTo w\u0142a\u015bnie na tym etapie prostota i wygoda OpenShift ukazuj\u0105 si\u0119 w ca\u0142ej okaza\u0142o\u015bci. Jak w ka\u017cdym dystrybucji Kubernetes, mamy wiele sposob\u00f3w uruchomienia aplikacji w klastrze. I, jak w przypadku K8s, celowo wybieramy najprostsze rozwi\u0105zanie.<\/p>\n
    OpenShift zawsze by\u0142 budowany jako platforma do tworzenia i uruchamiania aplikacji kontenerowych. Budowanie kontener\u00f3w od pocz\u0105tku by\u0142o nieod\u0142\u0105czn\u0105 cz\u0119\u015bci\u0105 tej platformy, dlatego istnieje tutaj mn\u00f3stwo dodatkowych zasob\u00f3w Kubernetes do odpowiednich zada\u0144.<\/p>\n
    B\u0119dziemy korzysta\u0107 z procesu Source 2 Image (S2I) OpenShift, kt\u00f3ry oferuje kilka r\u00f3\u017cnych metod, aby wzi\u0105\u0107 nasz \u017ar\u00f3d\u0142owy kod (lub pliki binarne) i przekszta\u0142ci\u0107 go w obraz kontenera, kt\u00f3ry mo\u017cna uruchomi\u0107 w klastrze OpenShift.<\/p>\n
    Do tego b\u0119d\u0105 nam potrzebne dwie rzeczy:<\/p>\n