{"id":90874,"date":"2020-08-07T01:42:20","date_gmt":"2020-08-06T23:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds"},"modified":"2020-08-07T01:42:20","modified_gmt":"2020-08-06T23:42:20","slug":"sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Nowoczesne aplikacje na OpenShift, cz\u0119\u015b\u0107 2: powi\u0105zane kompilacje chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107 wszystkim! Oto drugi wpis z naszej serii, w kt\u00f3rej pokazujemy, jak wdra\u017ca\u0107 nowoczesne aplikacje internetowe na Red Hat OpenShift. <\/p>\n

\"Nowoczesne
\n
\nW poprzednim po\u015bcie nieco om\u00f3wili\u015bmy mo\u017cliwo\u015bci nowego obrazu buildera S2I (source-to-image), kt\u00f3ry jest przeznaczony do budowania i wdra\u017cania nowoczesnych aplikacji internetowych na platformie OpenShift. Wtedy interesowa\u0142 nas temat szybkiego wdra\u017cania aplikacji, a dzisiaj przyjrzymy si\u0119, jak u\u017cywa\u0107 obrazu S2I jako \u201eczystego\u201d obrazu buildera i \u0142\u0105czy\u0107 go z powi\u0105zanymi kompilacjami OpenShift.
\n<\/a><\/noindex><\/p>\n

Czysty obraz buildera<\/h3>\n

\nJak wspomnieli\u015bmy w pierwszej cz\u0119\u015bci, wi\u0119kszo\u015b\u0107 nowoczesnych aplikacji internetowych ma tak zwany etap budowy, na kt\u00f3rym zazwyczaj przeprowadza si\u0119 takie operacje jak transpilejsja kodu, konkatenacja kilku plik\u00f3w oraz minifikacja. Pliki powsta\u0142e w wyniku tych operacji \u2013 a wi\u0119c statyczny HTML, JavaScript i CSS \u2013 s\u0105 umieszczane w folderze output. Miejsce tego folderu zazwyczaj zale\u017cy od tego, jakie narz\u0119dzia budowania s\u0105 u\u017cywane, a dla React b\u0119dzie to folder . \/build (wr\u00f3cimy do tego tematu dok\u0142adniej poni\u017cej).<\/p>\n

Source-to-Image (S2I)<\/h4>\n

\nW tym po\u015bcie w og\u00f3le nie poruszamy tematu \u201eczym jest S2I i jak go u\u017cywa\u0107\u201d (wi\u0119cej na ten temat mo\u017cna przeczyta\u0107 tutaj<\/a><\/noindex>), ale wa\u017cne jest, aby wyra\u017anie rozumie\u0107 dwa etapy tego procesu, aby zrozumie\u0107, co w\u0142a\u015bciwie robi obraz Web App Builder.<\/p>\n

Etap assemblacji (assemble phase)<\/h4>\n

\nEtap assemblacji jest w gruncie rzeczy bardzo podobny do tego, co dzieje si\u0119, gdy uruchamiasz docker build i w wyniku tego otrzymujesz nowy obraz Docker. Odpowiednio, ten etap ma miejsce przy uruchomieniu budowy na platformie OpenShift.<\/p>\n

W przypadku obrazu Web App Builder za instalacj\u0119 zale\u017cno\u015bci Twojej aplikacji i uruchomienie budowy odpowiada skrypt assemble<\/a><\/noindex>. Domy\u015blnie obraz buildera u\u017cywa konstrukcji npm run build, ale mo\u017cna j\u0105 nadpisa\u0107 za pomoc\u0105 zmiennej \u015brodowiskowej NPM_BUILD.<\/p>\n

Jak m\u00f3wili\u015bmy wcze\u015bniej, lokalizacja gotowej, ju\u017c zbudowanej aplikacji zale\u017cy od u\u017cywanych narz\u0119dzi. Na przyk\u0142ad, w przypadku React b\u0119dzie to folder. \/build, a dla aplikacji Angular \u2013 folder project_name \/dist. I, jak ju\u017c pokazano w poprzednim wpisie, lokalizacj\u0119 katalogu wyj\u015bciowego, kt\u00f3ry domy\u015blnie jest ustawiony jako build, mo\u017cna nadpisa\u0107 przez zmienn\u0105 \u015brodowiskow\u0105 OUTPUT_DIR. Poniewa\u017c lokalizacja katalogu wyj\u015bciowego r\u00f3\u017cni si\u0119 w zale\u017cno\u015bci od frameworka, po prostu kopiujesz wygenerowane wyj\u015bcie do standardowego folderu w obrazie, a mianowicie do \/opt \/apt-root \/output. To jest wa\u017cne dla zrozumienia dalszej cz\u0119\u015bci tego artyku\u0142u, a teraz szybko przejd\u017amy do nast\u0119pnego etapu \u2013 fazy uruchomienia (run phase).<\/p>\n

Faza uruchomienia (run phase)<\/h4>\n

\nTen etap zachodzi, gdy dla nowego obrazu, stworzonego w etapie sk\u0142adania, wywo\u0142ywane jest docker run. Dzieje si\u0119 to tak\u017ce podczas wdra\u017cania na platformie OpenShift. Domy\u015blnie skryptowi uruchamiaj\u0105cemu (run script)<\/a><\/noindex> u\u017cywa modu\u0142 serve<\/a><\/noindex> do obs\u0142ugi statycznych tre\u015bci znajduj\u0105cych si\u0119 w wcze\u015bniej wspomnianym standardowym katalogu wyj\u015bciowym.<\/p>\n

Ta metoda jest dobra do szybkiego wdra\u017cania aplikacji, ale w rzeczywisto\u015bci nie zaleca si\u0119 obs\u0142ugi statycznych tre\u015bci w ten spos\u00f3b. Poniewa\u017c w rzeczywisto\u015bci obs\u0142ugujemy tylko statyczne tre\u015bci, zainstalowany w obrazie Node.js nie jest potrzebny \u2013 wystarczy serwer WWW.<\/p>\n

M\u00f3wi\u0105c inaczej, podczas budowy potrzebujemy czego\u015b innego, a podczas wykonywania czego\u015b innego. W takiej sytuacji przydadz\u0105 si\u0119 powi\u0105zane budowy (chained builds).<\/p>\n

Powi\u0105zane budowy (chained builds)<\/h3>\n

\nOto, co m\u00f3wi si\u0119 o powi\u0105zanych budowach<\/a><\/noindex> w dokumentacji OpenShift:<\/p>\n

\u201eDwie budowy mo\u017cna powi\u0105za\u0107 ze sob\u0105, przy czym jedna z nich generuje skompilowany byt, a druga umieszcza ten byt w osobnym obrazie, kt\u00f3ry jest u\u017cywany do uruchomienia tego bytu.\u201d\n<\/p><\/blockquote>\n

\nInnymi s\u0142owy, mo\u017cemy wykorzysta\u0107 obraz Web App Builder do uruchomienia naszej budowy, a nast\u0119pnie u\u017cy\u0107 obrazu serwera WWW, tego samego NGINX, aby obs\u0142ugiwa\u0107 nasz\u0105 tre\u015b\u0107.<\/p>\n

W ten spos\u00f3b mo\u017cemy stosowa\u0107 obraz Web App Builder jako 'czysty' builder i jednocze\u015bnie mie\u0107 ma\u0142y obraz runtime.<\/p>\n

Teraz om\u00f3wmy to na konkretnym przyk\u0142adzie.<\/p>\n

Do \u0107wicze\u0144 u\u017cyjemy prostej aplikacji React<\/a><\/noindex>, stworzonej za pomoc\u0105 narz\u0119dzia wiersza polece\u0144 create-react-app.<\/p>\n

Zebra\u0107 wszystko w ca\u0142o\u015b\u0107 pomo\u017ce nam szablon pliku OpenShift<\/a><\/noindex>.<\/p>\n

Przyjrzyjmy si\u0119 bli\u017cej temu plikowi, zaczynaj\u0105c od sekcji parametr\u00f3w.<\/p>\n

parametry:\n  - nazwa: SOURCE_REPOSITORY_URL\n    opis: Adres URL \u017ar\u00f3d\u0142owego dla aplikacji\n    displayName: Adres URL \u017ar\u00f3d\u0142owy\n    wymagane: prawda\n  - nazwa: SOURCE_REPOSITORY_REF\n    opis: Nazwa ga\u0142\u0119zi dla aplikacji\n    displayName: Ga\u0142\u0105\u017a \u017ar\u00f3d\u0142owa\n    warto\u015b\u0107: master\n    wymagane: prawda\n  - nazwa: SOURCE_REPOSITORY_DIR\n    opis: Lokalizacja w repozytorium \u017ar\u00f3d\u0142owym aplikacji\n    displayName: Katalog \u017ar\u00f3d\u0142owy\n    warto\u015b\u0107: .\n    wymagane: prawda\n  - nazwa: OUTPUT_DIR\n    opis: Lokalizacja skompilowanych plik\u00f3w statycznych z Twojego narz\u0119dzia do tworzenia aplikacji internetowych\n    displayName: Katalog wyj\u015bciowy\n    warto\u015b\u0107: build\n    wymagane: fa\u0142sz\n<\/code><\/pre>\n
\nTutaj wszystko jest do\u015b\u0107 jasne, ale warto zwr\u00f3ci\u0107 uwag\u0119 na parametr OUTPUT_DIR. W przypadku aplikacji React z naszego przyk\u0142adu nie ma si\u0119 czym martwi\u0107, poniewa\u017c React u\u017cywa domy\u015blnego ustawienia jako katalogu wyj\u015bciowego, ale w przypadku Angulara lub innych framework\u00f3w ten parametr b\u0119dzie trzeba dostosowa\u0107.<\/p>\n
Teraz przyjrzyjmy si\u0119 sekcji ImageStream.<\/p>\n
- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: web-app-builder-runtime \/\/ 3\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersion: v1\n  kind: ImageStream\n  metadata:\n    name: nginx-image-runtime \/\/ 4\n  spec:\n    tags:\n    - name: latest\n      from:\n        kind: DockerImage\n        name: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nSp\u00f3jrz na trzeci i czwarty obraz. Oba zosta\u0142y zdefiniowane jako obrazy Docker i wida\u0107 wyra\u017anie, sk\u0105d pochodz\u0105.<\/p>\n
Trzeci obraz to web-app-builder, kt\u00f3ry pochodzi z nodeshift\/ubi8-s2i-web-app z tagiem 10.x na Docker hub<\/a><\/noindex>.<\/p>\n
Czwarty obraz to obraz NGINX (wersja 1.12) z tagiem latest na Docker hub<\/a><\/noindex>.<\/p>\n
Teraz popatrzmy na dwa pierwsze obrazy. Oba zaczynaj\u0105 jako puste i s\u0105 tworzone dopiero w fazie budowy. Pierwszy obraz \u2013 react-web-app-builder \u2013 b\u0119dzie wynikiem etapu \u0142\u0105czenia, kt\u00f3ry po\u0142\u0105czy obraz web-app-builder-runtime z naszym kodem \u017ar\u00f3d\u0142owym. Dlatego dodali\u015bmy do nazwy tego obrazu \u201e-builder\u201d.<\/p>\n
Drugi obraz \u2013 react-web-app-runtime \u2013 b\u0119dzie wynikiem po\u0142\u0105czenia nginx-image-runtime oraz pewnych plik\u00f3w z obrazu react-web-app-builder. Obraz ten r\u00f3wnie\u017c b\u0119dzie u\u017cywany podczas wdro\u017cenia i b\u0119dzie zawiera\u0142 tylko serwer WWW oraz statyczny HTML, JavaScript, CSS naszej aplikacji.<\/p>\n
Zawi\u0142e? Sp\u00f3jrzmy teraz na konfiguracje budowy, aby sta\u0142o si\u0119 to troch\u0119 ja\u015bniejsze.<\/p>\n
W naszym szablonie znajduje si\u0119 dwie konfiguracje budowy. Oto pierwsza z nich, kt\u00f3ra jest do\u015b\u0107 standardowa:<\/p>\n
  apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-builder\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-builder:latest \n    source:   \n      git:\n        uri: ${SOURCE_REPOSITORY_URL}\n        ref: ${SOURCE_REPOSITORY_REF}\n      contextDir: ${SOURCE_REPOSITORY_DIR}\n      type: Git\n    strategy:\n      sourceStrategy:\n        env:\n          - name: OUTPUT_DIR \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \n        incremental: true \n      type: Source\n    triggers: \n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nJak widzimy, linia z etykiet\u0105 1 m\u00f3wi, \u017ce wynik tej budowy zostanie umieszczony w obrazie react-web-app-builder, kt\u00f3ry wcze\u015bniej widzieli\u015bmy w sekcji ImageStream.<\/p>\n
Linia z etykiet\u0105 2 m\u00f3wi, sk\u0105d bra\u0107 kod. W naszym przypadku jest to repozytorium git, a lokalizacja, ref i folder kontekstowy s\u0105 okre\u015blone przez parametry, kt\u00f3re ju\u017c widzieli\u015bmy powy\u017cej.<\/p>\n
Linia z etykiet\u0105 3 \u2013 to ju\u017c widzieli\u015bmy w sekcji parametr\u00f3w. Dodaje zmienn\u0105 \u015brodowiskow\u0105 OUTPUT_DIR, kt\u00f3ra w naszym przyk\u0142adzie ma warto\u015b\u0107 build.
\nLinia z etykiet\u0105 4 m\u00f3wi, aby u\u017cywa\u0107 obrazu web-app-builder-runtime, kt\u00f3ry ju\u017c widzieli\u015bmy w sekcji ImageStream.<\/p>\n
Linia z etykiet\u0105 5 m\u00f3wi, \u017ce chcemy korzysta\u0107 z inkrementalnej budowy, je\u017celi obraz S2I to wspiera, a obraz Web App Builder \u2013 wspiera. Przy pierwszym uruchomieniu, po zako\u0144czeniu etapu kompilacji, obraz zachowa folder node_modules w archiwum. Nast\u0119pnie przy kolejnych uruchomieniach obraz po prostu rozpakowuje ten folder, aby skr\u00f3ci\u0107 czas budowy.<\/p>\n
I w ko\u0144cu, linia z etykiet\u0105 6 \u2013 to tylko kilka wyzwalaczy, aby budowa uruchamia\u0142a si\u0119 automatycznie, bez r\u0119cznej interwencji, gdy cokolwiek si\u0119 zmienia.<\/p>\n
Og\u00f3lnie rzecz bior\u0105c, to do\u015b\u0107 standardowa konfiguracja budowy.<\/p>\n
Teraz przyjrzyjmy si\u0119 drugiej konfiguracji budowy. Jest ona bardzo podobna do pierwszej, ale istnieje jedna wa\u017cna r\u00f3\u017cnica.<\/p>\n
apiVersion: v1\n  kind: BuildConfig\n  metadata:\n    name: react-web-app-runtime\n  spec:\n    output:\n      to:\n        kind: ImageStreamTag\n        name: react-web-app-runtime:latest \n    source:\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \n          paths:\n            - sourcePath: \/opt\/app-root\/output\/.  \n              destinationDir: .  \n    strategy: \n      sourceStrategy:\n        from:\n          kind: ImageStreamTag\n          name: nginx-image-runtime:latest\n        incremental: true\n      type: Source\n    triggers:\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - type: ImageChange\n      imageChange: {}\n    - type: ImageChange\n      imageChange:\n        from:\n          kind: ImageStreamTag\n          name: react-web-app-builder:latest\n<\/code><\/pre>\n
\nWi\u0119c druga konfiguracja kompilacji \u2013 react-web-app-runtime, rozpoczyna si\u0119 do\u015b\u0107 standardowo.<\/p>\n
W linii oznaczonej jako 1 nie ma nic nowego \u2013 po prostu informuje, \u017ce wynik kompilacji jest umieszczany w obrazie react-web-app-runtime.<\/p>\n
Linia oznaczona jako 2, jak w poprzedniej konfiguracji, wskazuje, sk\u0105d pobra\u0107 kod \u017ar\u00f3d\u0142owy. Zauwa\u017ccie jednak, \u017ce m\u00f3wimy, i\u017c pochodzi z obrazu. A dok\u0142adniej z obrazu, kt\u00f3ry w\u0142a\u015bnie stworzyli\u015bmy \u2013 z react-web-app-builder (wskazany w linii oznaczonej jako 3). Pliki, kt\u00f3re chcemy u\u017cy\u0107, znajduj\u0105 si\u0119 wewn\u0105trz obrazu, a ich lokalizacja jest okre\u015blona w linii oznaczonej jako 4, w naszym przypadku to \/opt\/app-root\/output\/. Je\u015bli pami\u0119tacie, tam w\u0142a\u015bnie trafiaj\u0105 pliki generowane w wyniku kompilacji naszej aplikacji.<\/p>\n
Folder docelowy, okre\u015blony w linii oznaczonej jako 5 \u2013 to po prostu bie\u017c\u0105cy katalog (wszystko to, przypomnijmy, kr\u0119ci si\u0119 wewn\u0105trz pewnej magicznej rzeczy o nazwie OpenShift, a nie na waszym lokalnym komputerze).<\/p>\n
Sekcja strategy \u2013 linia oznaczona jako 6 \u2013 r\u00f3wnie\u017c przypomina pierwsz\u0105 konfiguracj\u0119 kompilacji. Tylko tym razem zamierzamy u\u017cy\u0107 nginx-image-runtime, kt\u00f3ry ju\u017c widzieli\u015bmy w sekcji ImageStream.<\/p>\n
Wreszcie linia oznaczona jako 7 \u2013 to sekcja trigger\u00f3w, kt\u00f3ra aktywuje t\u0119 kompilacj\u0119 za ka\u017cdym razem, gdy zmienia si\u0119 obraz react-web-app-builder.<\/p>\n
Poza tym, szablon ten zawiera ca\u0142kiem standardow\u0105 konfiguracj\u0119 wdro\u017cenia, a tak\u017ce rzeczy odnosz\u0105ce si\u0119 do us\u0142ug i tras, ale nie b\u0119dziemy si\u0119 w to zag\u0142\u0119bia\u0107. Zauwa\u017ccie, \u017ce obraz, kt\u00f3ry b\u0119dzie wdra\u017cany \u2013 to obraz react-web-app-runtime.<\/p>\n
Rozw\u00f3j aplikacji<\/h3>\n
\nZatem, po tym jak przyjrzeli\u015bmy si\u0119 szablonowi, zobaczmy, jak go u\u017cy\u0107 do wdro\u017cenia aplikacji.<\/p>\n
Mo\u017cemy u\u017cy\u0107 narz\u0119dzia klienckiego OpenShift o nazwie oc, aby wdro\u017cy\u0107 nasz szablon:<\/p>\n
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f\n\n$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https:\/\/github.com\/lholmquist\/react-web-app\n<\/code><\/pre>\n
\nPierwsza komenda na zrzucie powy\u017cej \u2013 to celowo in\u017cynierski spos\u00f3b na znalezienie szablonu .\/openshiftio\/application.yaml.<\/p>\n
Druga komenda po prostu tworzy now\u0105 aplikacj\u0119 na podstawie tego szablonu.<\/p>\n
Po tym, jak te komendy zostan\u0105 wykonane, zobaczymy, \u017ce mamy dwie kompilacje:<\/p>\n
\"Nowoczesne<\/p>\n
A wracaj\u0105c do ekranu Overview, zobaczymy uruchomiony kontener:<\/p>\n
\"Nowoczesne<\/p>\n
Klikni\u0119cie w link \u2013 przeprowadzi nas do naszej aplikacji, kt\u00f3ra jest domy\u015bln\u0105 stron\u0105 aplikacji React App:<\/p>\n
\"Nowoczesne<\/p>\n
Dodatek 1<\/h3>\n
\nDla mi\u0142o\u015bnik\u00f3w Angular r\u00f3wnie\u017c mamy przyk\u0142ad aplikacji<\/a><\/noindex>.<\/p>\n
Szablon jest taki sam, z wyj\u0105tkiem zmiennej OUTPUT_DIR.<\/p>\n
Dodatek 2<\/h3>\n
\nW tym artykule u\u017cyli\u015bmy NGINX jako serwera WWW, ale mo\u017cna go \u0142atwo zamieni\u0107 na Apache, po prostu zmieniaj\u0105c plik szablonu. obraz NGINX<\/a><\/noindex> na obraz Apache<\/a><\/noindex>.<\/p>\n
Podsumowanie<\/h3>\n
\nW pierwszej cz\u0119\u015bci tej serii pokazali\u015bmy, jak szybko wdra\u017ca\u0107 nowoczesne aplikacje webowe na platformie OpenShift. Dzi\u015b przyjrzeli\u015bmy si\u0119, co robi obraz aplikacji webowej i jak mo\u017cna go po\u0142\u0105czy\u0107 z czystym serwerem WWW typu NGINX za pomoc\u0105 powi\u0105zanych bud\u00f3w (chained build), aby zorganizowa\u0107 bardziej odpowiedni\u0105 do warunk\u00f3w produkcyjnych budow\u0119 aplikacji. W nast\u0119pnej, ko\u0144cowej cz\u0119\u015bci tej serii poka\u017cemy, jak uruchomi\u0107 na OpenShift serwer deweloperski dla swojej aplikacji i zapewni\u0107 synchronizacj\u0119 plik\u00f3w lokalnych i zdalnych.<\/p>\n
Spis tre\u015bci tej serii artyku\u0142\u00f3w<\/h3>\n
<\/p>\n