{"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\/ro\/blog\/administrirovanie\/prosti-openshift-my-nedostatochno-czenili-tebya-i-prinimali-kak-dolzhnoe","title":{"rendered":"\u00cemi pare r\u0103u, OpenShift, nu te-am apreciat suficient \u0219i te-am considerat ca un dat.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Acest post este scris deoarece angaja\u021bii no\u0219tri au avut o mul\u021bime de discu\u021bii cu clien\u021bii despre dezvoltarea aplica\u021biilor pe Kubernetes \u0219i despre specificul acestei dezvolt\u0103ri pe OpenShift.<\/p>\n

\"\u00cemi
\n
\nDe obicei, \u00eencepem cu teza c\u0103 Kubernetes este pur \u0219i simplu Kubernetes, iar OpenShift este deja o platform\u0103 Kubernetes, la fel ca Microsoft AKS sau Amazon EKS. Fiecare dintre aceste platforme are avantajele sale, orientate c\u0103tre o anumit\u0103 audien\u021b\u0103 \u021bint\u0103. Dup\u0103 aceasta, discu\u021bia trece la compararea punctelor forte \u0219i slabe ale platformelor specifice.
\n<\/a><\/noindex>
\n\u00cen general, ne-am g\u00e2ndit s\u0103 scriem acest post cu concluzia de genul \u201eAsculta\u021bi, nu conteaz\u0103 unde s\u0103 rulezi codul, fie pe OpenShift, fie pe AKS, fie pe EKS, fie pe un Kubernetes personalizat, pur \u0219i simplu pe orice Kubernetes. (pentru scurt, s\u0103-i spunem KUK).<\/i> Este \u00eentr-adev\u0103r simplu, at\u00e2t acolo, c\u00e2t \u0219i aici.<\/p>\n

Apoi, pl\u0103nuiam s\u0103 lu\u0103m un simplu \u201eHello World\u201d \u0219i s\u0103 ar\u0103t\u0103m prin exemplul acestuia ce este comun \u0219i care sunt diferen\u021bele dintre KUK \u0219i Red Hat OpenShift Container Platform (mai departe, OCP sau pur \u0219i simplu OpenShift).<\/p>\n

Cu toate acestea, pe parcursul scrierii acestui post, ne-am dat seama c\u0103 ne-am obi\u0219nuit at\u00e2t de mult s\u0103 folosim OpenShift, \u00eenc\u00e2t pur \u0219i simplu nu realiz\u0103m cum a evoluat \u0219i s-a transformat \u00eentr-o platform\u0103 uimitoare, care a devenit mult mai mult dec\u00e2t un simplu distribu\u021bie Kubernetes. Ne-am obi\u0219nuit s\u0103 consider\u0103m maturitatea \u0219i simplitatea OpenShift ca pe ceva normal, neglij\u00e2nd splendoarea sa.<\/p>\n

\u00cen general, a venit vremea c\u0103in\u021bei active, \u0219i acum vom compara pas cu pas debutul \u201eHello World\u201d pe KUK \u0219i pe OpenShift, \u0219i vom face acest lucru c\u00e2t mai obiectiv posibil (dar, poate, vom exprima uneori o p\u0103rere personal\u0103 asupra subiectului). Dac\u0103 e\u0219ti interesat de o opinie pur subiectiv\u0103 pe aceast\u0103 tem\u0103, o po\u021bi citi aici (EN).<\/a><\/noindex>\u00cen acest post, \u00eens\u0103, ne vom men\u021bine la fapte \u0219i doar fapte.<\/p>\n

Clustere.<\/h3>\n

\nA\u0219adar, pentru \u201eHello World\u201d avem nevoie de clustere. S\u0103 spunem \u201enu\u201d tuturor cloudurilor publice pentru a nu pl\u0103ti pentru servere, registre, re\u021bele, transfer de date etc. Prin urmare, alegem un cluster simplu pe un singur nod pe Minikube<\/a><\/noindex> (pentru KUK) \u0219i Code Ready Containers<\/a><\/noindex> (pentru clusterul OpenShift). Ambele op\u021biuni sunt realmente simple de instalat, dar vor necesita destul de multe resurse pe laptopul t\u0103u.<\/p>\n

\"\u00cemi<\/p>\n

Construirea pe KUK.<\/h3>\n

\nA\u0219adar, s\u0103 \u00eencepem.<\/p>\n

Pasul 1 \u2013 construim imaginea noastr\u0103 de container.<\/h4>\n

\nVoi \u00eencepe prin a desf\u0103\u0219ura \u201eHello World\u201d pe minikube. Pentru aceasta, avem nevoie de:<\/p>\n

    \n
  1. 1. Docker instalat.<\/li>\n
  2. 2. Git instalat.<\/li>\n
  3. 3. Maven instalat (de fapt, \u00een acest proiect se folose\u0219te binarul mvnw, a\u0219a c\u0103 se poate s\u0103 s\u0103rim aceast\u0103 etap\u0103).<\/li>\n
  4. 4. De fapt, sursa, adic\u0103 clonarea repo-ului github.com\/gcolman\/quarkus-hello-world.git<\/a><\/noindex><\/li>\n<\/ol>\n

    \nPrimul lucru pe care trebuie s\u0103-l facem este s\u0103 cre\u0103m un proiect Quarkus. Nu v\u0103 speria\u021bi dac\u0103 nu a\u021bi lucrat niciodat\u0103 cu site-ul Quarkus.io \u2013 este simplu. Trebuie doar s\u0103 selecta\u021bi componentele pe care dori\u021bi s\u0103 le folosi\u021bi \u00een proiect (RestEasy, Hibernate, Amazon SQS, Camel etc.), iar apoi Quarkus configureaz\u0103 singur arhetipul maven \u0219i public\u0103 totul pe github. Asta \u00eenseamn\u0103, practic, un singur click \u0219i gata. De asta iubim Quarkus.<\/p>\n

    \"\u00cemi<\/p>\n

    Cea mai simpl\u0103 metod\u0103 de a construi \u201eHello World\u201d \u00een imaginea de container este s\u0103 folose\u0219ti extensiile quarkus-maven pentru Docker, care vor face \u00eentreaga munc\u0103 necesar\u0103. Odat\u0103 cu apari\u021bia Quarkus, acest lucru a devenit cu adev\u0103rat simplu: ad\u0103uga\u021bi extensia container-image-docker \u0219i pute\u021bi crea imagini cu comenzile maven.<\/p>\n

    .\/mvnw quarkus:add-extension -Dextensions=\"container-image-docker\"\n<\/code><\/pre>\n
    \n\u0218i, \u00een final, execut\u0103m construc\u021bia imaginii noastre folosind Maven. Ca rezultat, codul nostru surs\u0103 se transform\u0103 \u00eentr-o imagine de container care poate fi deja rulat\u0103 \u00een mediul de execu\u021bie al containerelor.<\/p>\n
    \"\u00cemi<\/p>\n
    .\/mvnw -X clean package -Dquarkus.container-image.build=true\n<\/code><\/pre>\n
    \nIat\u0103, \u0219i asta este tot, acum putem rula containerul cu comanda docker run, map\u00e2nd serviciul nostru pe portul 8080, astfel \u00eenc\u00e2t s\u0103 poat\u0103 fi accesat.<\/p>\n
    docker run -i --rm -p 8080:8080 gcolman\/quarkus-hello-world\n<\/code><\/pre>\n
    \"\u00cemi<\/p>\n
    Dup\u0103 ce instan\u021ba containerului s-a pornit, r\u0103m\u00e2ne doar s\u0103 verific\u0103m cu comanda curl c\u0103 serviciul nostru func\u021bioneaz\u0103:<\/p>\n
    \"\u00cemi<\/p>\n
    A\u0219adar, totul func\u021bioneaz\u0103, \u0219i a fost cu adev\u0103rat simplu.<\/p>\n
    Pasul 2 \u2013 trimitem containerul nostru \u00een repository-ul de imagini de containere<\/h4>\n
    \nDeocamdat\u0103, imaginea pe care am creat-o este stocat\u0103 local, \u00een depozitul nostru local de containere. Dac\u0103 dorim s\u0103 folosim aceast\u0103 imagine \u00een mediul nostru K8S, trebuie s\u0103 o plas\u0103m \u00eentr-un alt repository. \u00cen Kubernetes nu exist\u0103 astfel de func\u021bii, a\u0219a c\u0103 vom folosi dockerhub. Deoarece, pe de o parte, este gratuit, iar pe de alt\u0103 parte, (aproape) toat\u0103 lumea face asta.<\/p>\n
    Este, de asemenea, foarte simplu, \u0219i avem nevoie doar de un cont pe dockerhub.<\/p>\n
    A\u0219adar, ne conect\u0103m la dockerhub \u0219i trimitem imaginea noastr\u0103 acolo.<\/p>\n
    \"\u00cemi<\/p>\n
    Pasul 3 \u2013 pornim Kubernetes<\/h4>\n
    \nExist\u0103 multe modalit\u0103\u021bi de a construi configura\u021bia Kubernetes pentru a rula \u201eHello World\u201d, dar vom folosi cea mai simpl\u0103 dintre ele, suntem a\u0219a\u2026<\/p>\n
    Pentru \u00eenceput, pornim clusterul minikube:<\/p>\n
    minikube start\n<\/code><\/pre>\n
    <\/p>\n
    Pasul 4 \u2013 desf\u0103\u0219ur\u0103m imaginea noastr\u0103 de container<\/h4>\n
    \nAcum trebuie s\u0103 transform\u0103m codul nostru \u0219i imaginea containerului \u00een configura\u021biile Kubernetes. Cu alte cuvinte, avem nevoie de o defini\u021bie pod \u0219i deployment care s\u0103 fac\u0103 referire la imaginea noastr\u0103 pe Docker Hub. Una dintre cele mai simple modalit\u0103\u021bi de a face asta este s\u0103 rul\u0103m comanda create deployment, specific\u00e2nd imaginea noastr\u0103:<\/p>\n
    \"\u00cemi<\/p>\n
    kubectl create deployment hello-quarkus --image=gcolman\/quarkus-hello-world:1.0.0-SNAPSHOT\n<\/code><\/pre>\n
    \nPrin aceast\u0103 comand\u0103 am spus Kubernetes-ului nostru s\u0103 creeze configura\u021bia deployment, care trebuie s\u0103 con\u021bin\u0103 specifica\u021bia pod-ului pentru imaginea noastr\u0103 de container. Aceast\u0103 comand\u0103 va aplica, de asemenea, aceast\u0103 configura\u021bie \u00een clusterul nostru Minikube \u0219i va crea un deployment care va desc\u0103rca imaginea noastr\u0103 de container \u0219i va porni pod-ul \u00een cluster.<\/p>\n
    Pasul 5 \u2013 deschidem accesul la serviciul nostru<\/h4>\n
    \nAcum, c\u00e2nd avem imaginea de container desf\u0103\u0219urat\u0103, este momentul s\u0103 ne g\u00e2ndim cum putem configura accesul extern la acest serviciu RESTful, care este, de fapt, programat \u00een codul nostru.<\/p>\n
    Exist\u0103 multe modalit\u0103\u021bi. De exemplu, putem folosi comanda expose pentru a crea automat componentele Kubernetes corespunz\u0103toare, cum ar fi servicii \u0219i endpoint-uri. A\u0219a c\u0103 asta vom face, execut\u00e2nd comanda expose pentru obiectul nostru de deployment:<\/p>\n
    kubectl expose deployment hello-quarkus --type=NodePort --port=8080\n<\/code><\/pre>\n
    \nS\u0103 ne oprim pentru o clip\u0103 asupra op\u021biunii \u201e--type\u201d din comanda expose.<\/p>\n
    C\u00e2nd facem expose \u0219i cre\u0103m componentele necesare pentru a rula serviciul nostru, trebuie, printre altele, s\u0103 ne asigur\u0103m c\u0103 putem accesa din exterior serviciul hello-quarkus, care se afl\u0103 \u00een interiorul re\u021belei noastre definite prin software. \u0218i parametru type<\/b> ne permite s\u0103 cre\u0103m \u0219i s\u0103 conect\u0103m lucruri precum balansoarele de \u00eenc\u0103rcare, pentru a direc\u021biona traficul \u00een aceast\u0103 re\u021bea.<\/p>\n
    De exemplu, specific\u00e2nd type=LoadBalancer<\/b>, vom ini\u021bializa automat un balansoar de \u00eenc\u0103rcare \u00een cloud public, pentru a ne conecta la clusterul nostru Kubernetes. Desigur, asta este minunat, dar trebuie s\u0103 \u00een\u021belegem c\u0103 o astfel de configura\u021bie va fi str\u00e2ns legat\u0103 de un anumit cloud public \u0219i va fi mai greu de mutat \u00eentre instan\u021bele Kubernetes \u00een medii diferite.<\/p>\n
    \u00cen exemplul nostru type=NodePort<\/b>, adic\u0103 apelul c\u0103tre serviciul nostru se face prin adresa IP a nodului \u0219i num\u0103rul portului. Aceast\u0103 op\u021biune permite s\u0103 nu folosim nicio solu\u021bie cloud public\u0103, dar necesit\u0103 o serie de pa\u0219i suplimentari. \u00cen primul r\u00e2nd, avem nevoie de un balansator de \u00eenc\u0103rcare propriu, a\u0219a c\u0103 vom implementa \u00een clusterul nostru un balansator de \u00eenc\u0103rcare NGINX.<\/p>\n
    Pasul 6 \u2013 instal\u0103m balansatorul de \u00eenc\u0103rcare<\/h4>\n
    \nMinikube are o serie de func\u021bii de platform\u0103 care faciliteaz\u0103 crearea componentelor necesare pentru accesul extern, cum ar fi controlerele ingress. Minikube vine cu un controler ingress Nginx, iar noi trebuie doar s\u0103-l activ\u0103m \u0219i s\u0103-l configur\u0103m.<\/p>\n
    minikube addons enable ingress\n<\/code><\/pre>\n
    \nAcum, cu o singur\u0103 comand\u0103, voi crea un controler ingress Nginx care va func\u021biona \u00een interiorul clusterului nostru minikube:<\/p>\n
    ingress-nginx-controller-69ccf5d9d8-j5gs9 1\/1 Running 1 33m\n<\/code><\/pre>\n
    <\/p>\n
    Pasul 7 \u2013 configur\u0103m ingress<\/h4>\n
    \nAcum trebuie s\u0103 configur\u0103m controlerul ingress Nginx pentru a interpreta cererile hello-quarkus.<\/p>\n
    \"\u00cemi<\/p>\n
    \"\u00cemi<\/p>\n
    \u0218i, \u00een final, trebuie s\u0103 aplic\u0103m aceast\u0103 configura\u021bie.<\/p>\n
    \"\u00cemi<\/p>\n
    kubectl apply -f ingress.yml\n<\/code><\/pre>\n
    \"\u00cemi<\/p>\n
    Deoarece facem toate acestea pe computerul nostru, ad\u0103ug\u0103m pur \u0219i simplu adresa IP a nodului nostru \u00een fi\u0219ierul \/etc\/hosts pentru a direc\u021biona cererile http c\u0103tre minikube pe balansatorul de \u00eenc\u0103rcare NGINX.<\/p>\n
    192.168.99.100 hello-quarkus.info\n<\/code><\/pre>\n
    \nTotul, acum serviciul nostru minikube este disponibil extern prin controlerul ingress Nginx.<\/p>\n
    \"\u00cemi<\/p>\n
    Ei bine, a fost u\u0219or, nu-i a\u0219a? Sau nu prea?<\/h3>\n
    \"\u00cemi<\/p>\n
    Lansare pe OpenShift (Code Ready Containers)<\/h3>\n
    \nAcum s\u0103 vedem cum se face totul pe Red Hat OpenShift Container Platform (OCP).<\/p>\n
    La fel ca \u00een cazul minikube, alegem schema cu un cluster OpenShift pe un singur nod sub forma Code Ready Containers (CRC). \u00cen trecut, aceasta se numea minishift \u0219i se baza pe proiectul OpenShift Origin, iar acum este CRC \u0219i construit\u0103 pe platforma OpenShift Container de la Red Hat.<\/p>\n
    Aici, ne cerem scuze \u0219i nu ne putem ab\u021bine s\u0103 nu spunem: \u201eOpenShift este minunat!\u201d<\/p>\n
    Ini\u021bial, am g\u00e2ndit s\u0103 scriem c\u0103 dezvoltarea pe OpenShift nu difer\u0103 de dezvoltarea pe Kubernetes. \u0218i, \u00een esen\u021b\u0103, a\u0219a este. Dar \u00een timpul scrierii acestui post ne-am amintit c\u00e2te mi\u0219c\u0103ri suplimentare sunt necesare atunci c\u00e2nd nu ai OpenShift, de aceea repet\u0103m, este minunat. Ne place c\u00e2nd totul este simplu de realizat, iar modul \u00een care se desf\u0103\u0219oar\u0103 at\u00e2t de u\u0219or comparativ cu minikube exemplul nostru pe OpenShift, ne-a motivat s\u0103 scriem acest post.<\/p>\n
    S\u0103 trecem prin proces \u0219i s\u0103 vedem ce va trebui s\u0103 facem.<\/p>\n
    A\u0219adar, \u00een exemplul cu minikube, am \u00eenceput cu Docker... Opri\u021bi, nu mai avem nevoie ca Docker s\u0103 fie instalat pe ma\u0219in\u0103.<\/p>\n
    \u0218i git local nu este necesar.
    \n\u0218i Maven nu este necesar.
    \n\u0218i nu trebuie s\u0103 cre\u0103m manual imaginea containerului.
    \n\u0218i nu trebuie s\u0103 c\u0103ut\u0103m un repository pentru imaginile containerelor.
    \n\u0218i nu trebuie s\u0103 instal\u0103m un ingress controller.
    \n\u0218i nici s\u0103 configur\u0103m ingress nu este necesar.<\/b><\/p>\n
    A\u021bi \u00een\u021beles, da? Pentru a desf\u0103\u0219ura \u0219i a rula aplica\u021bia noastr\u0103 pe OpenShift, nu este nevoie de nimic din cele enumerate mai sus. Iar procesul arat\u0103 astfel.<\/p>\n
    Pasul 1 \u2013 Pornim clusterul nostru OpenShift<\/h4>\n
    \nFolosim Code Ready Containers de la Red Hat, care este practic acela\u0219i lucru cu Minikube, dar cu un cluster OpenShift cu un singur nod complet func\u021bional.<\/p>\n
    crc start\n<\/code><\/pre>\n
    <\/p>\n
    Pasul 2 \u2013 Construim \u0219i desf\u0103\u0219ur\u0103m aplica\u021bia \u00een clusterul OpenShift<\/h4>\n
    \n\u00cen acest pas se manifest\u0103 pe deplin simplificarea \u0219i comoditatea OpenShift. Ca \u00een toate distribu\u021biile Kubernetes, avem multe moduri de a lansa aplica\u021bia \u00een cluster. \u0218i, ca \u0219i \u00een cazul Kubernetes, alegem \u00een mod special cea mai simpl\u0103 op\u021biune.<\/p>\n
    OpenShift a fost \u00eentotdeauna construit ca o platform\u0103 pentru crearea \u0219i desf\u0103\u0219urarea aplica\u021biilor containerizate. Construirea containerelor a fost \u00eentotdeauna o parte esen\u021bial\u0103 a acestei platforme, a\u0219a c\u0103 exist\u0103 o mul\u021bime de resurse Kubernetes suplimentare pentru sarcinile corespunz\u0103toare.<\/p>\n
    Vom folosi procesul Source 2 Image (S2I) al OpenShift, care are mai multe metode diferite pentru a lua sursa noastr\u0103 (cod sau fi\u0219iere binare) \u0219i a o transforma \u00eentr-o imagine de container care ruleaz\u0103 \u00een clusterul OpenShift.<\/p>\n
    Pentru aceasta avem nevoie de dou\u0103 lucruri:<\/p>\n