{"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, 2. osa: seotud kogumid chained builds","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

\"Kaasaegsed
\n
\nEelmisel postitusel puudutasime veidi uue S2I (source-to-image) builder-ima v\u00f5imalusi, mis on m\u00f5eldud kaasaegsete veebirakenduste kogumiseks ja juurutamiseks OpenShift platvormil. Sel korral keskendume kiire juurutamise teemale, kuid t\u00e4na vaatame, kuidas kasutada S2I-ima \u201apuhta\u2018 builder-ima ja \u00fchendada seda seotud OpenShifti kogumitega.
\n<\/a><\/noindex><\/p>\n

Puhas builder-ima<\/h3>\n

\nKuidas mainisime esimeses osas, on enamikul kaasaegsetest veebirakendustest nn kogumisetapp, kus tavaliselt viiakse l\u00e4bi sellised toimingud nagu koodi transpileerimine, mitme faili \u00fchendamine ja minifikatsioon. Neid toiminguid tulemusena saadud failid \u2013 need on staatiline HTML, JavaScript ja CSS \u2013 paigutatakse v\u00e4ljundkausta. Selle kausta asukoht s\u00f5ltub tavaliselt kasutatavatest kogumist\u00f6\u00f6riistadest ja Reacti puhul on see kaust .\/build (t\u00e4iendame seda teemat allpool).<\/p>\n

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

\nSelles postituses me ei k\u00e4sitle teemat \u201emis on S2I ja kuidas seda kasutada\u201c (selle kohta saab rohkem lugeda siin<\/a><\/noindex>), kuid on oluline selgelt m\u00f5ista selle protsessi kahte etappi, et m\u00f5ista, mida teeb Web App Builder'i ima.<\/p>\n

Kogumise etapp (assemble phase)<\/h4>\n

\nKogumise etapp on oma olemuselt v\u00e4ga sarnane sellele, mis juhtub, kui k\u00e4ivitate docker build'i ja saate tulemuseks uue Docker-i ima. Seet\u00f5ttu toimub see etapp OpenShift platvormil kogumise k\u00e4ivitamisel.<\/p>\n

Web App Builder'i ima puhul vastutab teie rakenduse s\u00f5ltuvuste installimise ja kogumise k\u00e4ivitamise eest assemble script<\/a><\/noindex>. Vaikimisi kasutab builder-ima konstruktsiooni npm run build, kuid seda saab \u00fcletada keskkonnamuutujaga NPM_BUILD.<\/p>\n

Nagu varem mainitud, s\u00f5ltub valminud, juba kokku pandud rakenduse asukoht kasutatavadest t\u00f6\u00f6riistadest. N\u00e4iteks Reacti puhul on see kaust .\/build, Angulari rakenduste puhul aga kaust project_name\/dist. Ja nagu eelmises postituses n\u00e4idatud, saab v\u00e4ljundikausta asukohta, mis on vaikimisi m\u00e4\u00e4ratud kui build, \u00fcle kirjutada keskkonnamuutuja OUTPUT_DIR kaudu. Kuna v\u00e4ljundikausta asukoht erineb raamistikust raamistikku, kopeerite lihtsalt genereeritud v\u00e4ljundi standardkausta kujunduses, nimelt \/opt\/apt-root\/output. See on oluline edasise osa m\u00f5istmiseks, aga vahepeal vaatame kiirelt j\u00e4rgmist etappi \u2013 k\u00e4ivitamine (run phase).<\/p>\n

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

\nSee etapp tekib, kui uue kujundi, mis on loodud assambleerimise etapis, kutsutakse v\u00e4lja docker run. See toimub ka avamisel OpenShift platvormil. Vaikimisi k\u00e4ivitusskripti<\/a><\/noindex> kasutab serve moodul<\/a><\/noindex> staatilise sisu teenindamiseks, mis asub \u00fclaltoodud standardse v\u00e4ljundikausta.<\/p>\n

See meetod on hea rakenduste kiireks juurutamiseks, kuid tegelikult ei ole soovitatav staatilist sisu sellisel moel teenindada. Kuna me teenindame ainult staatilist sisu, ei ole meie kujunduses sisalduv Node.js vajalik \u2013 piisab veebiserverist.<\/p>\n

Teisis\u00f5nu, kogumisel on meil \u00fcks, k\u00e4ivitamisel aga teine. Sellises olukorras tulevad kasuks seotud kogumid (chained builds).<\/p>\n

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

\nSiin on, mida \u00f6eldakse seotud kogumite (chained builds)<\/a><\/noindex> OpenShift dokumentatsioonis:<\/p>\n

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

\nTeisis\u00f5nu, me v\u00f5ime kasutada Web App Builder'i kujundit, et k\u00e4ivitada meie kogumine, ja seej\u00e4rel kasutada veebiserveri kujundit, n\u00e4iteks NGINX-i, et teenindada meie sisu.<\/p>\n

Seega saame kasutada Web App Builder'i kujundit kui \u201epuhast\u201c builder'it ja samal ajal omada v\u00e4ikese suurusega runtime kujundit.<\/p>\n

N\u00fc\u00fcd k\u00e4sitleme seda konkreetses n\u00e4ites.<\/p>\n

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

Koguda k\u00f5ik kokku aitab meil OpenShift'i mallifail<\/a><\/noindex>.<\/p>\n

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

parameetrid:\n  - nimi: SOURCE_REPOSITORY_URL\n    kirjeldus: Rakenduse allika URL\n    kuvamisnimi: Allika URL\n    n\u00f5utav: t\u00f5ene\n  - nimi: SOURCE_REPOSITORY_REF\n    kirjeldus: Rakenduse haru nimi\n    kuvamisnimi: Allika haru\n    v\u00e4\u00e4rtus: master\n    n\u00f5utav: t\u00f5ene\n  - nimi: SOURCE_REPOSITORY_DIR\n    kirjeldus: Rakenduse asukoht allika repositooriumis\n    kuvamisnimi: Allika kaust\n    v\u00e4\u00e4rtus: .\n    n\u00f5utav: t\u00f5ene\n  - nimi: OUTPUT_DIR\n    kirjeldus: Koht kompileeritud staatiliste failide jaoks teie veebirakenduse koosturi seest\n    kuvamisnimi: V\u00e4ljundi kaust\n    v\u00e4\u00e4rtus: build\n    n\u00f5utav: vale\n<\/code><\/pre>\n
\nSiin on k\u00f5ik \u00fcsna arusaadav, kuid v\u00e4\u00e4rtus OUTPUT_DIR parameetrit tuleks t\u00e4helepanelikult vaadata. Meie n\u00e4ites React-rakenduse puhul ei pea me muretsema, kuna React kasutab v\u00e4ljundikaustana vaikimisi v\u00e4\u00e4rtust, kuid Angulari v\u00f5i muu puhul tuleb see parameeter vastavalt muuta.<\/p>\n
N\u00fc\u00fcd vaatame ImageStream-ide jaotust.<\/p>\n
- apiVersioon: v1\n  liik: ImageStream\n  metadata:\n    nimi: react-web-app-builder  \/\/ 1 \n  spec: {}\n- apiVersioon: v1\n  liik: ImageStream\n  metadata:\n    nimi: react-web-app-runtime  \/\/ 2 \n  spec: {}\n- apiVersioon: v1\n  liik: ImageStream\n  metadata:\n    nimi: web-app-builder-runtime \/\/ 3\n  spec:\n    sildid:\n    - nimi: latest\n      from:\n        liik: DockerImage\n        nimi: nodeshift\/ubi8-s2i-web-app:10.x\n- apiVersioon: v1\n  liik: ImageStream\n  metadata:\n    nimi: nginx-image-runtime \/\/ 4\n  spec:\n    sildid:\n    - nimi: latest\n      from:\n        liik: DockerImage\n        nimi: 'centos\/nginx-112-centos7:latest'\n<\/code><\/pre>\n
\nVaadake kolmandat ja neljandat pilti. Need on m\u00f5lemad m\u00e4\u00e4ratletud kui Docker-pildid ja on selgelt n\u00e4ha, kust nad p\u00e4rinevad.<\/p>\n
Kolmas pilt on web-app-builder ja see p\u00e4rineb nodeshift\/ubi8-s2i-web-app koos sildiga 10.x Docker hub<\/a><\/noindex>.<\/p>\n
Neljandaks on NGINX (versioon 1.12) pilt koos sildiga latest Docker hub<\/a><\/noindex>.<\/p>\n
N\u00fc\u00fcd vaatame kahte esimest pilti. Need on m\u00f5lemad alguses t\u00fchjad ja luuakse ainult koostamisetapis (build phase). Esimene pilt \u2013 react-web-app-builder \u2013 saab olema koosseisu tulemuseks, mis \u00fchendab web-app-builder-runtime pildi ja meie l\u00e4htekoodi. Seet\u00f5ttu lisasime sellele pildile nime l\u00f5ppu \u201e-builder\u201d.<\/p>\n
Teine pilt \u2013 react-web-app-runtime \u2013 saab olema nginx-image-runtime ja m\u00f5ne faili \u00fchendamise tulemus react-web-app-builder pildist. See pilt kasutatakse samuti juurutamisel ja sisaldab ainult veebiserverit ning meie rakenduse staatilist HTML-i, JavaScripti ja CSS-i.<\/p>\n
J\u00e4rsk? Vaatame n\u00fc\u00fcd koostamiskonfiguratsioone ja see muutub veidi selgemaks.<\/p>\n
Meie mallel on kaks koostamiskonfiguratsiooni. Siin on neist esimene ja see on \u00fcsna tavaline:<\/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
\nKuidas n\u00e4eme, et 1. m\u00e4rgiga rida \u00fctleb, et selle kompileerimise tulemus paigutatakse just sellesse pildi react-web-app-builder, mida me varem n\u00e4gime ImageStreamide jagu.<\/p>\n
2. m\u00e4rgiga rida \u00fctleb, kust koodi v\u00f5tta. Meie puhul on see git-repositoorium ning asukoht, ref ja kontekstikaust on m\u00e4\u00e4ratletud parameetritega, mida oleme juba varem n\u00e4inud.<\/p>\n
3. m\u00e4rgiga rida \u2013 see on see, mida me oleme juba n\u00e4inud parameetrite sektsioonis. See lisab keskkonnamuutuja OUTPUT_DIR, mis meie n\u00e4ites on v\u00f5rdundus build.
\n4. m\u00e4rgiga rida \u00fctleb kasutada pilti web-app-builder-runtime, mida me oleme juba n\u00e4inud ImageStreamide sektsioonis.<\/p>\n
5. m\u00e4rgiga rida \u00fctleb, et me tahame kasutada inkrementaalset kompileerimist, kui S2I-pilt seda toetab, ja Web App Builder toetab. Esimese k\u00e4ivitamise ajal, p\u00e4rast kokkupanekufaasi l\u00f5petamist, salvestab pilt node_modules kausta arhivifaili. Seej\u00e4rel j\u00e4rgmisel k\u00e4ivitamisel dekompresseerib pilt lihtsalt selle kausta, et l\u00fchendada ehituskestvust.<\/p>\n
Ja l\u00f5puks, 6. m\u00e4rgiga rida \u2013 see on lihtsalt m\u00f5ned triggarid, et kompileerimist saaks automaatselt alustada, ilma k\u00e4sitsi sekkumiseta, kui midagi muutub.<\/p>\n
\u00dches\u00f5naga, see on \u00fcsna tavaline kompileerimise konfiguratsioon.<\/p>\n
N\u00fc\u00fcd vaatame teist kompileerimiskonfiguratsiooni. See on v\u00e4ga sarnane esimesele, kuid 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\\\/.\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 et, teine konfiguratsioon on react-web-app-runtime ja see algab \u00fcsna tavap\u00e4raselt.<\/p>\n
M\u00e4rgi 1 real pole midagi uut \u2013 see \u00fctleb lihtsalt, et koostamise tulemus pannakse react-web-app-runtime pildile.<\/p>\n
M\u00e4rgi 2 real, nagu ka eelnevas konfiguratsioonis, n\u00e4idatakse, kust l\u00e4htekood v\u00f5tta. Kuid p\u00f6\u00f6rake t\u00e4helepanu, et siin \u00f6eldakse, et see v\u00f5etakse pildist. Ja see pilt, millest me just r\u00e4\u00e4kisime, on react-web-app-builder (mille oleme n\u00e4idanud m\u00e4rgi 3 real). Failid, mida soovime kasutada, asuvad pildi sees ja nende asukoht seal m\u00e4\u00e4ratakse m\u00e4rgi 4 real, meie puhul on see \\\/opt\\\/app-root\\\/output\\\/. Kui m\u00e4letate, just sinna pannakse failid, mis genereeritakse meie rakenduse koostamisprotsessi tulemusena.<\/p>\n
M\u00e4rgi 5 real m\u00e4\u00e4ratud sihtkaust on lihtsalt praegune kataloog (k\u00f5ik see, meenutame, t\u00f6\u00f6tab mingisugustes maagilistes asjades nimega OpenShift, mitte teie kohalikel arvutitel).<\/p>\n
Jaotises strategy \u2013 m\u00e4rgi 6 real \u2013 on samuti sarnane esimesele koostamise konfiguratsioonile. Ainult seekord kavatseme kasutada nginx-image-runtime'i, mida oleme juba n\u00e4inud ImageStreami jaotises.<\/p>\n
L\u00f5puks, m\u00e4rgi 7 real on see triggereid sektsioon, mis aktiveerib selle koostamise iga kord, kui react-web-app-builder pilt muutub.<\/p>\n
Muus osas sisaldab see mall \u00fcsna tavap\u00e4rast juurutamise konfiguratsiooni ning ka asju, mis puudutavad 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 vaatame mallile peale, kuidas seda rakenduse juurutamiseks kasutada.<\/p>\n
Saame kasutada OpenShifti kliendit\u00f6\u00f6riista nimega oc, et juurutada meie malli:<\/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
\nEespool oleval ekraanipildil on esimene k\u00e4sk tahtlikult inseneritehniline viis mallide leidmiseks.\\\/openshiftio\\\/application.yaml.<\/p>\n
Teine k\u00e4sk loob lihtsalt uue rakenduse selle malli alusel.<\/p>\n
P\u00e4rast nende k\u00e4skude t\u00f6\u00f6tlemist n\u00e4eme, et meil on kaks koostamist:<\/p>\n
\"Kaasaegsed<\/p>\n
Ja tagasi \u00fclevaate ekraanile n\u00e4eme, et pod on k\u00e4ivitatud:<\/p>\n
\"Kaasaegsed<\/p>\n
Klikkige lingil ja j\u00f5uame meie rakendusse, mis on vaikimisi React Appi leht:<\/p>\n
\"Kaasaegsed<\/p>\n
Lisa 1<\/h3>\n
\nAngulari armastajatele on meil samuti rakenduse n\u00e4idis<\/a><\/noindex>.<\/p>\n
Mall siin on sama, v\u00e4lja arvatud muutuja OUTPUT_DIR.<\/p>\n
Lisaosa 2<\/h3>\n
\nSelles artiklis kasutasime veebiserverina NGINX-i, kuid selle saab \u00fcsna lihtsalt asendada Apache'iga, kui lihtsalt muudate mallifailis. NGINX-i pilt<\/a><\/noindex> . Tundub, et Apache'i pilt<\/a><\/noindex>.<\/p>\n
Kokkuv\u00f5te<\/h3>\n
\nSelle seeria esimeses osas n\u00e4itasime, kuidas kiiresti k\u00e4ivitada kaasaegseid veebirakendusi OpenShift'i platvormil. T\u00e4na vaatleme, mis teeb Web App'i pildi ja kuidas seda saab kombineerida puhta veebiserveri, n\u00e4iteks NGINX-iga, kasutades seotud kogumisi (chained build), et korraldada tootmisoludele sobilikumat rakenduste kogumist. Seeria j\u00e4rgmises ja viimases artiklis n\u00e4itame, kuidas k\u00e4ivitada OpenShift'is arendusserver oma rakendusele ja tagada lokaalsete ja kaugfailide s\u00fcnkroniseerimine.<\/p>\n
Selle seeria artiklite sisu<\/h3>\n
<\/p>\n