{"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\/et\/blog\/administrirovanie\/sovremennye-prilozheniya-na-openshift-chast-2-svyazannye-sborki-chained-builds","title":{"rendered":"Kaasaegsed rakendused OpenShiftis, osa 2: seotud kogumid chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere k\u00f5igile! Siin on meie teise postituse seeria, kus n\u00e4itame, kuidas juurutada t\u00e4nap\u00e4evaseid veebirakendusi Red Hat OpenShiftis. <\/p>\n

\"Kaasaegsed
\n
\nEelnevas postituses k\u00e4sitlesime veidi uue S2I (source-to-image) builder-pildi v\u00f5imalusi, mis on m\u00f5eldud t\u00e4nap\u00e4evaste veebirakenduste kogumiseks ja juurutamiseks OpenShifti platvormil. Toona huvitusime rakenduse kiirest juurutamisest, t\u00e4na vaatame aga, kuidas kasutada S2I pilti \u201epuhta\u201d builder-pildina ja kombineerida seda seotud OpenShift'i kogumistega.
\n<\/a><\/noindex><\/p>\n

Puhas builder-pilt<\/h3>\n

\nKuidas me esimeses osas mainisime, on enamikul t\u00e4nap\u00e4evastest veebirakendustest nii-\u00f6elda kogumise etapp, kus tavaliselt teostatakse selliseid toiminguid nagu koodi transpileerimine, mitme faili \u00fchendamine ja minimeerimine. Saadud failid \u2013 staatiline HTML, JavaScript ja CSS \u2013 paigutatakse v\u00e4ljundkausta. Selle kausta asukoht s\u00f5ltub tavaliselt sellest, milliseid kogumise t\u00f6\u00f6riistu kasutatakse, ja React'i puhul on see kaust .\/build (naaseme selle k\u00fcsimuse juurde l\u00e4hemal ajal).<\/p>\n

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

\nSelles postituses ei k\u00e4sitleme teemat \"mis on S2I ja kuidas seda kasutada\" (lisaks sellele saab lugeda siit<\/a><\/noindex>), kuid on oluline selgelt m\u00f5ista kahte etappi, et m\u00f5ista, mida Web App Builderi pilt teeb.<\/p>\n

Kokkuv\u00f5tte etapp (assemble phase)<\/h4>\n

\nKokkuv\u00f5tte etapp on oma olemuselt v\u00e4ga sarnane sellele, mis juhtub, kui k\u00e4ivitate docker build ja saate uue Docker-pildi. Seega tekib see etapp OpenShift platvormil kokkupaneku k\u00e4ivitamisel.<\/p>\n

Web App Builderi pildi puhul vastutab teie rakenduse s\u00f5ltuvuste installimise ja kokkupaneku k\u00e4ivitamise eest assemble script<\/a><\/noindex>. Vaikimisi kasutab builder-pilt npm run build k\u00e4su, kuid seda saab \u00fcmber m\u00e4\u00e4rata keskkonnamuutuja NPM_BUILD kaudu.<\/p>\n

Nagu varem mainitud, s\u00f5ltub valmis, juba kokku pandud rakenduse asukoht kasutatavatest t\u00f6\u00f6riistadest. N\u00e4iteks Reacti puhul asub see kaustas .\/build, Angulari rakenduste puhul aga kaustas project_name\/dist. Ja nagu eelmisel postitusel n\u00e4idatud, saab vaikimisi m\u00e4\u00e4ratud output-katalooge, mis on build, \u00fcle kirjutada keskkonnamuutujaga OUTPUT_DIR. Kuna output-kausta asukoht s\u00f5ltub raamistikust, kopeerite lihtsalt genereeritud v\u00e4ljundi standardkausta, see on \/opt\/apt-root\/output. See on oluline arusaamiseks k\u00e4esoleva artikli j\u00e4rgnevast osast, aga n\u00fc\u00fcd vaatame kiirelt j\u00e4rgmise etapi \u2013 k\u00e4ivitamise (run phase) \u2013 \u00fcle.<\/p>\n

K\u00e4ivitamise etapp (run phase)<\/h4>\n

\nSee etapp algab, kui uue pildi jaoks, mis loodi assamblee etapis, tehakse docker run k\u00e4sk. See toimub samuti OpenShift platvormil juurutamisel. Vaikimisi k\u00e4ivitusskript<\/a><\/noindex> kasutab teenindusmoodul<\/a><\/noindex> statilise sisu teenindamiseks, mis asub eespool nimetatud standardse output-katalooge.<\/p>\n

See meetod sobib rakenduste kiireks juurutamiseks, kuid tegelikult ei soovitata staatilise sisu sellisel viisil teenindada. Kuna me tegelikult teenindame ainult staatilist sisu, pole meie Node.js pildi sees installimine vajalik \u2013 piisab veebiserverist.<\/p>\n

Teisis\u00f5nu, ehitamisel vajame \u00fchte ja t\u00e4itmisel \u2013 teist. Sellises olukorras tulevad kasuks seotud ehitused (chained builds).<\/p>\n

Seotud ehitused (chained builds)<\/h3>\n

\nSiin on, mida kirjutatakse chained builds<\/a><\/noindex> OpenShift'i dokumentatsioonis:<\/p>\n

\u201eKaks ehitust saab omavahel siduda, kusjuures \u00fcks neist genereerib kompileeritud \u00fcksuse ja teine paigutab selle \u00fcksuse eraldi pildile, mida kasutatakse selle \u00fcksuse k\u00e4itamiseks.\u201d\n<\/p><\/blockquote>\n

\nTeiste s\u00f5nadega, me saame kasutada Web App Builder pildil meie ehituse k\u00e4itamiseks ja seej\u00e4rel kasutada veebiserveri pilti, n\u00e4iteks NGINX-i, et teenindada meie sisu.<\/p>\n

Nii saame rakendada Web App Builder pilti kui \"puhtat\" builder'it ja omada samal ajal v\u00e4ikese suurusega k\u00e4ituspilti.<\/p>\n

N\u00fc\u00fcd vaatame seda konkreetse n\u00e4ite p\u00f5hjal.<\/p>\n

Treeninguks kasutame lihtsat React rakendust<\/a><\/noindex>, loodud k\u00e4surea t\u00f6\u00f6riista create-react-app abil.<\/p>\n

Kogume k\u00f5ik kokku meie abiga OpenShift'i mallifail<\/a><\/noindex>.<\/p>\n

Vaatame seda faili l\u00e4hemalt ja alustame parameetrite osast.<\/p>\n

parameters:\n  - name: SOURCE_REPOSITORY_URL\n    description: Rakenduse allika URL\n    displayName: Allika URL\n    required: true\n  - name: SOURCE_REPOSITORY_REF\n    description: Rakenduse haru nimi\n    displayName: Allika haru\n    value: master\n    required: true\n  - name: SOURCE_REPOSITORY_DIR\n    description: Rakenduse asukoht allika repos\n    displayName: Allika kataloog\n    value: .\n    required: true\n  - name: OUTPUT_DIR\n    description: Koostatud staatiliste failide asukoht teie veebirakenduste koostajana\n    displayName: V\u00e4ljund kataloog\n    value: build\n    required: false\n<\/code><\/pre>\n
\nSiin on k\u00f5ik \u00fcsna selge, kuid tasub t\u00e4helepanu p\u00f6\u00f6rata parameetrile OUTPUT_DIR. Meie n\u00e4ite React-rakenduse puhul ei pea muretsema, kuna React kasutab v\u00e4ljundikaustana vaikev\u00e4\u00e4rtust, kuid Angulari v\u00f5i millegi muu puhul tuleb see parameeter vastavalt muuta.<\/p>\n
N\u00fc\u00fcd vaatame ImageStreamide sektsiooni.<\/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
\nVaata kolmandat ja neljandat pilti. Need on m\u00f5lemad m\u00e4\u00e4ratletud kui Docker-pildid ja on selgelt n\u00e4htav, kust need tulevad.<\/p>\n
Kolmas pilt on web-app-builder ja see p\u00e4rineb nodeshift\/ubi8-s2i-web-app versiooniga 10.x. Docker hub<\/a><\/noindex>.<\/p>\n
Neljas on NGINX pilt (versioon 1.12) versiooniga latest. Docker hub<\/a><\/noindex>.<\/p>\n
N\u00fc\u00fcd vaatame kahte esimest pilti. Need on m\u00f5lemad alguses t\u00fchjad ja luuakse ainult ehitusetapis (build phase). Esimene pilt \u2013 react-web-app-builder \u2013 saab olema assemblimise etapi tulemus, mis liidab web-app-builder-runtime pildi ja meie l\u00e4htekoodi. Just seet\u00f5ttu olime selle pildi nime kirjutanud \"-builder\".<\/p>\n
Teine pilt \u2013 react-web-app-runtime \u2013 on nginx-image-runtime'i ja m\u00f5nede failide kombinatsioon, mis p\u00e4rinevad react-web-app-builder pildist. See pilt kasutatakse samuti juurutamisel ning see sisaldab ainult meie rakenduse veebiserverit ja staatilist HTML-i, JavaScripti ja CSS-i.<\/p>\n
Kas see on keeruline? Vaatame n\u00fc\u00fcd ehituskonfiguratsioone, siis saab veidi arusaadavamaks.<\/p>\n
Meie mallis on kaks ehituskonfiguratsiooni. Siin on neist esimene, mis on \u00fcsna standartne:<\/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 \/\/ 1\n    source:   \/\/ 2 \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 \/\/ 3 \n            value: ${OUTPUT_DIR}\n        from:\n          kind: ImageStreamTag\n          name: web-app-builder-runtime:latest \/\/ 4\n        incremental: true \/\/ 5\n      type: Source\n    triggers: \/\/ 6\n    - github:\n        secret: ${GITHUB_WEBHOOK_SECRET}\n      type: GitHub\n    - type: ConfigChange\n    - imageChange: {}\n      type: ImageChange\n<\/code><\/pre>\n
\nNagu n\u00e4ha, \u00fctleb m\u00e4rgistuse 1 rida, et selle ehituse tulemus paigutatakse just sellesse react-web-app-builder pilti, mida me varem ImageStreamide jaotises n\u00e4gime.<\/p>\n
M\u00e4rgitud rida 2 \u00fctleb, kust koodi v\u00f5tta. Meie puhul on see git-repositoorium, samas kui asukoht, ref ja konteksti kaust on m\u00e4\u00e4ratud parameetritega, mida oleme juba varem n\u00e4inud.<\/p>\n
M\u00e4rgitud rida 3 \u2013 see on see, mida oleme juba n\u00e4inud jaotises parameetrid. See lisab keskkonnamuutuja OUTPUT_DIR, mis meie n\u00e4ites on igual to build.
\nM\u00e4rgitud rida 4 \u00fctleb kasutada pilti web-app-builder-runtime, mida me oleme juba n\u00e4inud jaotises ImageStream.<\/p>\n
M\u00e4rgitud rida 5 \u00fctleb, et soovime kasutada inkrementeerimist, kui S2I-pilt seda toetab, ja Web App Builder \u2013 toetab. Esmase k\u00e4ivitamise ajal, p\u00e4rast koostamisfaasi l\u00f5petamist, salvestab pilt kausta node_modules arhiivifaili. Siis j\u00e4rgmistel k\u00e4ivitustel lihtsalt dekompresseerib pilt selle kausta, et v\u00e4hendada koostamise kestust.<\/p>\n
Ja l\u00f5puks, m\u00e4rgitud rida 6 \u2013 see on lihtsalt m\u00f5ned k\u00e4ivitajad, et koostamine algaks automaatselt, ilma k\u00e4sitsemise sekkumiseta, kui midagi muutub.<\/p>\n
\u00dcldiselt on see \u00fcsna standardne koostamisconfig.<\/p>\n
N\u00fc\u00fcd vaatame teist koostamisseadet. See on v\u00e4ga sarnane esimesele, kuid seal on \u00fcks oluline erinevus.<\/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 \/\/ 1\n    source: \/\/ 2\n      type: Image\n      images:                              \n        - from:\n            kind: ImageStreamTag\n            name: react-web-app-builder:latest \/\/ 3\n          paths:\n            - sourcePath: \/opt\/app-root\/output\/.  \/\/ 4\n              destinationDir: .  \/\/ 5\n             \n    strategy: \/\/ 6\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 \/\/ 7\n<\/code><\/pre>\n
\nNii, teine kogumiskonfiguratsioon on react-web-app-runtime, ja see algab \u00fcsna standardina.<\/p>\n
M\u00e4rgil 1 ei ole midagi uut \u2013 see \u00fctleb lihtsalt, et kogumise tulemus salvestatakse react-web-app-runtime pildile.<\/p>\n
M\u00e4rgisest 2 rida, nagu ka eelnevas konfiguratsioonis, n\u00e4itab, kust l\u00e4htekoodi v\u00f5tta. Kuid pidage meeles, et siin r\u00e4\u00e4gime, et see v\u00f5etakse pildist. Ja just sellest pildist, mille me just loome \u2013 react-web-app-builder (mille oleme m\u00e4\u00e4ranud m\u00e4rgis 3). Failid, mida soovime kasutada, asuvad pildi sees ja nende asukoht seal on m\u00e4\u00e4ratud m\u00e4rgis 4, meie puhul see on \/opt\/app-root\/output\/. Kui m\u00e4letate, siis just sinna laaditakse failid, mis genereeritakse meie rakenduse kogumise tulemuste p\u00f5hjal.<\/p>\n
Sihtkaust, mille m\u00e4\u00e4rasime m\u00e4rgis 5 \u2013 on lihtsalt praegune kataloog (k\u00f5ik see, meenutame, k\u00e4ib mingisuguse maagilise asja nimega OpenShift sees, mitte teie kohalikus arvutis).<\/p>\n
Jaotises strategy \u2013 rida, millel on m\u00e4rgis 6 \u2013 n\u00e4eb samuti v\u00e4lja nagu esimene kogumiskonfiguratsioon. Ainult seekord kavandame kasutada nginx-image-runtime'i, mida oleme juba n\u00e4inud jaos ImageStream.<\/p>\n
L\u00f5puks, rida, millel on m\u00e4rgis 7 \u2013 on k\u00e4ivitajate jaotis, mis aktiveerib selle kogumise igal korral, kui react-web-app-builder pilt muutub.<\/p>\n
Tegu on muidu \u00fcsna standardse juurutamissektori konfiguratsiooniga ning h\u00f5lmab ka teenuseid ja marsruute, kuid me ei s\u00fcvene sellesse. Pange t\u00e4hele, et juurutatav pilt on react-web-app-runtime.<\/p>\n
Rakenduse juurutamine<\/h3>\n
\nNii et p\u00e4rast seda, kui oleme vaadanud \u0161ablooni, vaatame, kuidas seda rakenduse juurutamiseks kasutada.<\/p>\n
Me kasutame OpenShift'i kliendi t\u00f6\u00f6riista nimega oc, et juurutada meie \u0161abloon:<\/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
\nEsimene k\u00e4sk \u00fclaltoodud ekraanil on ekslikult inseneritehniline viis \u0161ablooni leidmiseks .\/openshiftio\/application.yaml.<\/p>\n
Teine k\u00e4sk loob lihtsalt uue rakenduse selle \u0161ablooni p\u00f5hjal.<\/p>\n
P\u00e4rast nende k\u00e4skude t\u00e4itmist n\u00e4eme, et meil on kaks koostamist:<\/p>\n
\"Kaasaegsed<\/p>\n
Ja tagasip\u00f6\u00f6rdudes Overview ekraanile, n\u00e4eme jooksva pod'i:<\/p>\n
\"Kaasaegsed<\/p>\n
Linki kl\u00f5psates j\u00f5uame meie rakendusele, mis on vaikes\u00e4ttega React App leht:<\/p>\n
\"Kaasaegsed<\/p>\n
T\u00e4iend 1<\/h3>\n
\nAngulari f\u00e4nnide jaoks on meil ka rakenduse n\u00e4idis<\/a><\/noindex>.<\/p>\n
Mall on sama, v\u00e4lja arvatud muutuja OUTPUT_DIR.<\/p>\n
Lisa 2<\/h3>\n
\nSelles artiklis kasutasime veebiserverina NGINX-i, kuid selle saab h\u00f5lpsasti asendada Apache'iga, lihtsalt muutes mallifailis. NGINX-i pilt<\/a><\/noindex> j\u00e4rgnevaga Apache'i pilt<\/a><\/noindex>.<\/p>\n
Kokkuv\u00f5te<\/h3>\n
\nSelle seeria esimeses osas n\u00e4itasime, kuidas kiiresti juurutada kaasaegseid veebirakendusi OpenShift platvormil. T\u00e4na vaatame, mida teeb Veebirakenduse pilt ja kuidas seda saab \u00fchendada puhta veebiserveriga nagu NGINX, kasutades seotud ehitusi (chained build), et korraldada rakenduste ehitus rohkem tootmistingimustele sobivalt. Seeria j\u00e4rgmises, viimases artiklis n\u00e4itame, kuidas OpenShiftis k\u00e4ivitada arendusserver oma rakenduse jaoks ja tagada kohapealsete ja eemalsete failide s\u00fcnkroonimine.<\/p>\n
Selle seeria artiklite sisu<\/h3>\n
<\/p>\n