🥇Ժամանակակից հավելվածներ OpenShift-ում, մաս 2. շղթայված շինություններ

Բարեւ բոլորին! Սա մեր շարքի երկրորդ գրառումն է, որտեղ մենք ցույց ենք տալիս, թե ինչպես կարելի է տեղադրել ժամանակակից վեբ հավելվածներ Red Hat OpenShift-ում:

Նախորդ գրառման մեջ մենք մի փոքր անդրադարձանք նոր S2I (աղբյուր-պատկեր) կառուցապատող պատկերի հնարավորություններին, որը նախատեսված է OpenShift հարթակում ժամանակակից վեբ հավելվածներ ստեղծելու և տեղակայելու համար։ Այնուհետև մեզ հետաքրքրում էր հավելվածի արագ տեղակայման թեման, և այսօր մենք կանդրադառնանք, թե ինչպես օգտագործել S2I պատկերը որպես «մաքուր» շինարարական պատկեր և համատեղել այն հարակից OpenShift հավաքների հետ:

Մաքուր շինարարի պատկեր

Ինչպես նշեցինք Մաս XNUMX-ում, ժամանակակից վեբ հավելվածների մեծամասնությունն ունեն այսպես կոչված կառուցման փուլ, որը սովորաբար կատարում է այնպիսի գործողություններ, ինչպիսիք են կոդի փոխարկումը, բազմաթիվ ֆայլերի միացումը և փոքրացումը: Այս գործողությունների արդյունքում ստացված ֆայլերը, որոնք ստատիկ HTML, JavaScript և CSS են, պահվում են ելքային թղթապանակում: Այս թղթապանակի գտնվելու վայրը սովորաբար կախված է նրանից, թե ինչ build գործիքներ են օգտագործվում, և React-ի համար սա կլինի ./build թղթապանակը (այս մասին ավելի մանրամասն կանդրադառնանք ստորև):

Աղբյուր-պատկեր (S2I)

Այս գրառման մեջ մենք չենք անդրադառնում «ինչ է S2I և ինչպես օգտագործել այն» թեմային (այս մասին կարող եք կարդալ ավելին. այստեղ), բայց կարևոր է հստակ լինել այս գործընթացի երկու քայլերի մասին՝ հասկանալու համար, թե ինչ է անում Web App Builder պատկերը:

Մոնտաժման փուլ

Հավաքման փուլն իր բնույթով շատ նման է այն ամենին, ինչ տեղի է ունենում, երբ դուք գործարկում եք docker build-ը և ավարտվում է նոր Docker պատկերով: Համապատասխանաբար, այս փուլը տեղի է ունենում OpenShift հարթակի վրա build սկսելու ժամանակ:

Web App Builder պատկերի դեպքում այն պատասխանատու է ձեր հավելվածի կախվածությունները տեղադրելու և build-ը գործարկելու համար: հավաքել սցենար. Լռելյայնորեն, builder պատկերն օգտագործում է npm run build կառուցումը, բայց դա կարող է վերացվել NPM_BUILD միջավայրի փոփոխականի միջոցով:

Ինչպես ավելի վաղ ասացինք, պատրաստի, արդեն կառուցված հավելվածի գտնվելու վայրը կախված է նրանից, թե ինչ գործիքներ եք օգտագործում: Օրինակ, React-ի դեպքում սա կլինի ./build թղթապանակը, իսկ Angular հավելվածների համար՝ project_name/dist թղթապանակը։ Եվ, ինչպես արդեն ցույց է տրվել նախորդ գրառման մեջ, ելքային գրացուցակի գտնվելու վայրը, որը նախատեսված է լռելյայն կառուցման համար, կարող է վերացվել OUTPUT_DIR միջավայրի փոփոխականի միջոցով: Դե, քանի որ ելքային թղթապանակի գտնվելու վայրը տարբերվում է շրջանակներից շրջանակ, դուք պարզապես պատճենում եք ստացված ելքը պատկերի ստանդարտ թղթապանակում, այն է՝ /opt/apt-root/output: Սա կարևոր է այս հոդվածի մնացած մասը հասկանալու համար, բայց առայժմ եկեք արագ նայենք հաջորդ փուլին՝ վազքի փուլին:

գործարկման փուլ

Այս փուլը տեղի է ունենում, երբ զանգը դեպի docker run կատարվում է նոր պատկերի վրա, որը ստեղծվել է հավաքման փուլում: Նույնը տեղի է ունենում OpenShift հարթակում տեղակայելիս: Կանխադրված գործարկել սցենարը օգտագործում ծառայելու մոդուլ սպասարկելու ստատիկ բովանդակություն, որը գտնվում է վերը նշված ստանդարտ ելքային գրացուցակում:

Այս մեթոդը լավ է հավելվածների արագ տեղակայման համար, բայց սովորաբար խորհուրդ չի տրվում ստատիկ բովանդակություն մատուցել այս կերպ: Դե, քանի որ իրականում մենք սպասարկում ենք միայն ստատիկ բովանդակություն, մեզ պետք չէ, որ Node.js-ը տեղադրվի մեր պատկերի ներսում. բավական է վեբ սերվերը:

Այսինքն՝ հավաքելիս մի բան է պետք, կատարելիս՝ մեկ այլ բան։ Այս իրավիճակում շղթայված շինությունները հարմար են:

Շղթայված շինություններ

Ահա թե ինչի մասին են գրում շղթայված շինություններ OpenShift փաստաթղթերում.

«Երկու հավաքույթներ կարող են կապված լինել միմյանց հետ, որոնցից մեկը ստեղծում է կազմված էություն, իսկ մյուսը հյուրընկալում է այդ միավորը առանձին պատկերով, որն օգտագործվում է այդ կազմակերպությունը գործարկելու համար»:

Այլ կերպ ասած, մենք կարող ենք օգտագործել Web App Builder պատկերը մեր build-ը գործարկելու համար, իսկ հետո օգտագործել վեբ սերվերի պատկերը, նույն NGINX-ը, մեր բովանդակությունը սպասարկելու համար:

Այսպիսով, մենք կարող ենք օգտագործել Web App Builder-ի պատկերը որպես «մաքուր» շինարար և միևնույն ժամանակ ունենալ գործարկման փոքր պատկեր:

Հիմա եկեք սրան նայենք կոնկրետ օրինակով։

Վերապատրաստման համար մենք կօգտագործենք պարզ React հավելված, ստեղծվել է create-react-app հրամանի տող գործիքի միջոցով։

Դա մեզ կօգնի ամեն ինչ միասին հավաքել OpenShift կաղապարի ֆայլ.

Եկեք նայենք այս ֆայլին ավելի մանրամասն և սկսենք պարամետրերի բաժնից:

parameters:
  - name: SOURCE_REPOSITORY_URL
    description: The source URL for the application
    displayName: Source URL
    required: true
  - name: SOURCE_REPOSITORY_REF
    description: The branch name for the application
    displayName: Source Branch
    value: master
    required: true
  - name: SOURCE_REPOSITORY_DIR
    description: The location within the source repo of the application
    displayName: Source Directory
    value: .
    required: true
  - name: OUTPUT_DIR
    description: The location of the compiled static files from your web apps builder
    displayName: Output Directory
    value: build
    required: false

Այստեղ ամեն ինչ բավականին պարզ է, բայց արժե ուշադրություն դարձնել OUTPUT_DIR պարամետրին: Մեր օրինակում React հավելվածի համար անհանգստանալու ոչինչ չկա, քանի որ React-ն օգտագործում է լռելյայն արժեքը որպես ելքային թղթապանակ, բայց Angular-ի կամ այլ բանի դեպքում այս պարամետրը անհրաժեշտության դեպքում պետք է փոխվի:

Հիմա եկեք տեսնենք ImageStreams բաժինը:

- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-builder  // 1 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: react-web-app-runtime  // 2 
  spec: {}
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: web-app-builder-runtime // 3
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
  kind: ImageStream
  metadata:
    name: nginx-image-runtime // 4
  spec:
    tags:
    - name: latest
      from:
        kind: DockerImage
        name: 'centos/nginx-112-centos7:latest'

Նայեք երրորդ և չորրորդ պատկերներին: Նրանք երկուսն էլ սահմանվում են որպես Docker պատկերներ, և դուք կարող եք հստակ տեսնել, թե որտեղից են դրանք գալիս:

Երրորդ պատկերը web-app-builder-ն է և այն գալիս է nodeshift/ubi8-s2i-web-app-ից, որը հատկորոշված է 10.x-ով: Docker հանգույց.

Չորրորդը NGINX պատկերն է (տարբերակ 1.12)՝ վերջին պիտակով Docker հանգույց.

Հիմա եկեք նայենք առաջին երկու պատկերներին: Նրանք երկուսն էլ սկզբում դատարկ են և ստեղծվում են միայն կառուցման փուլում: Առաջին պատկերը՝ react-web-app-builder, կլինի հավաքման քայլի արդյունք, որը կմիավորի web-app-builder-runtime պատկերը և մեր սկզբնական կոդը: Այդ իսկ պատճառով այս պատկերի անվանմանը ավելացրել ենք «-builder»:

Երկրորդ պատկերը՝ react-web-app-runtime, կլինի nginx-image-runtime-ի և react-web-app-builder պատկերից որոշ ֆայլերի համակցման արդյունք: Այս պատկերը կօգտագործվի նաև տեղակայման ժամանակ և կպարունակի միայն մեր հավելվածի վեբ սերվերը և ստատիկ HTML, JavaScript, CSS:

Շփոթված. Հիմա եկեք նայենք կառուցման կոնֆիգուրացիաներին, և այն մի փոքր ավելի պարզ կդառնա:

Մեր ձևանմուշն ունի երկու կառուցման կոնֆիգուրացիա: Ահա առաջինը, և այն բավականին ստանդարտ է.

  apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-builder
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-builder:latest // 1
    source:   // 2 
      git:
        uri: ${SOURCE_REPOSITORY_URL}
        ref: ${SOURCE_REPOSITORY_REF}
      contextDir: ${SOURCE_REPOSITORY_DIR}
      type: Git
    strategy:
      sourceStrategy:
        env:
          - name: OUTPUT_DIR // 3 
            value: ${OUTPUT_DIR}
        from:
          kind: ImageStreamTag
          name: web-app-builder-runtime:latest // 4
        incremental: true // 5
      type: Source
    triggers: // 6
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - imageChange: {}
      type: ImageChange

Ինչպես տեսնում եք, 1 պիտակով տողը ասում է, որ այս կառուցման արդյունքը կտեղադրվի նույն react-web-app-builder պատկերում, որը մենք տեսանք մի փոքր ավելի վաղ ImageStreams բաժնում:

2 պիտակավորված տողը ձեզ ասում է, թե որտեղից ստանալ կոդը: Մեր դեպքում սա git պահոց է, և գտնվելու վայրը, ref և համատեքստային թղթապանակը որոշվում են այն պարամետրերով, որոնք մենք արդեն տեսանք վերևում:

3 պիտակավորված տողը այն է, ինչ մենք արդեն տեսանք պարամետրերի բաժնում: Այն ավելացնում է OUTPUT_DIR միջավայրի փոփոխականը, որը մեր օրինակում build է:
4 պիտակավորված տողում ասվում է, որ օգտագործվի web-app-builder-runtime պատկերը, որը մենք արդեն տեսել ենք ImageStream բաժնում:

5 պիտակավորված տողում ասվում է, որ մենք ցանկանում ենք օգտագործել աստիճանական կառուցում, եթե S2I պատկերն աջակցում է դրան, իսկ Web App Builder պատկերը: Առաջին գործարկման ժամանակ, հավաքման փուլի ավարտից հետո, պատկերը կպահի node_modules պանակը արխիվային ֆայլում: Այնուհետև, հետագա գործարկումների ժամանակ, պատկերը պարզապես կբացի այս թղթապանակը՝ կառուցման ժամանակը նվազեցնելու համար:

Եվ վերջապես, 6 պիտակավորված գիծը ընդամենը մի քանի գործարկիչ է, որպեսզի build-ը գործարկվի ավտոմատ կերպով, առանց ձեռքի միջամտության, երբ ինչ-որ բան փոխվի:

Ընդհանուր առմամբ, սա բավականին ստանդարտ կառուցվածքի կոնֆիգուրացիա է:

Հիմա եկեք նայենք երկրորդ կառուցման կոնֆիգուրացիան: Այն շատ նման է առաջինին, բայց կա մեկ կարևոր տարբերություն.

apiVersion: v1
  kind: BuildConfig
  metadata:
    name: react-web-app-runtime
  spec:
    output:
      to:
        kind: ImageStreamTag
        name: react-web-app-runtime:latest // 1
    source: // 2
      type: Image
      images:                              
        - from:
            kind: ImageStreamTag
            name: react-web-app-builder:latest // 3
          paths:
            - sourcePath: /opt/app-root/output/.  // 4
              destinationDir: .  // 5
             
    strategy: // 6
      sourceStrategy:
        from:
          kind: ImageStreamTag
          name: nginx-image-runtime:latest
        incremental: true
      type: Source
    triggers:
    - github:
        secret: ${GITHUB_WEBHOOK_SECRET}
      type: GitHub
    - type: ConfigChange
    - type: ImageChange
      imageChange: {}
    - type: ImageChange
      imageChange:
        from:
          kind: ImageStreamTag
          name: react-web-app-builder:latest // 7

Այսպիսով, կառուցման երկրորդ կոնֆիգուրացիան react-web-app-runtime է, և այն սկսվում է բավականին ստանդարտ:

1 պիտակավորված տողը նորություն չէ. այն պարզապես ասում է, որ կառուցման արդյունքը դրվում է react-web-app-runtime պատկերի մեջ:

2 պիտակավորված տողը, ինչպես նախորդ կազմաձևում, ցույց է տալիս, թե որտեղից կարելի է ստանալ սկզբնական կոդը: Բայց ուշադրություն դարձրեք, որ այստեղ մենք ասում ենք, որ այն վերցված է պատկերից։ Ավելին, մեր նոր ստեղծած պատկերից՝ react-web-app-builder-ից (նշված է 3-րդ պիտակով): Այն ֆայլերը, որոնք մենք ցանկանում ենք օգտագործել, պատկերի ներսում են, և դրանց գտնվելու վայրը դրված է 4 պիտակով տողում, մեր դեպքում դա /opt/app-root/output/ է: Եթե հիշում եք, այստեղ են պահվում մեր հավելվածի կառուցման արդյունքների հիման վրա ստեղծված ֆայլերը:

5-րդ պիտակով տերմինում նշված նպատակակետ թղթապանակը պարզապես ընթացիկ գրացուցակն է (այս ամենը, հիշեք, աշխատում է մի կախարդական բանի ներսում, որը կոչվում է OpenShift, և ոչ ձեր տեղական համակարգչում):

Ռազմավարության բաժինը՝ 6 պիտակավորված տողը, նույնպես նման է առաջին կառուցման կազմաձևին: Միայն այս անգամ մենք պատրաստվում ենք օգտագործել nginx-image-runtime, որն արդեն տեսել ենք ImageStream բաժնում։

Վերջապես, 7 պիտակավորված տողը գործարկիչների մի հատված է, որը կակտիվացնի այս կառուցումը ամեն անգամ, երբ փոխվում է react-web-app-builder պատկերը:

Հակառակ դեպքում, այս ձևանմուշը պարունակում է բավականին ստանդարտ տեղակայման կոնֆիգուրացիա, ինչպես նաև այնպիսի բաներ, որոնք վերաբերում են ծառայություններին և երթուղիներին, բայց մենք չենք խորանա այդքան շատ մանրամասների մեջ: Խնդրում ենք նկատի ունենալ, որ պատկերը, որը կտեղակայվի, react-web-app-runtime պատկերն է:

Հավելվածի տեղակայում

Այսպիսով, հիմա, երբ մենք նայեցինք ձևանմուշին, եկեք տեսնենք, թե ինչպես օգտագործել այն հավելվածը տեղակայելու համար:

Մենք կարող ենք օգտագործել OpenShift հաճախորդի գործիքը, որը կոչվում է oc՝ մեր ձևանմուշը տեղակայելու համար.

$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f

$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app

Վերևի սքրինշոթի առաջին հրամանը ձևանմուշ գտնելու միտումնավոր ինժեներական միջոց է:/openshiftio/application.yaml:

Երկրորդ հրամանը պարզապես ստեղծում է նոր հավելված այս կաղապարի հիման վրա։

Այս հրամանների աշխատելուց հետո մենք կտեսնենք, որ մենք ունենք երկու հավաքույթ.

Եվ վերադառնալով Overview էկրանին, մենք կտեսնենք գործարկված pod.

Սեղմեք հղմանը և մենք կտեղափոխվենք մեր հավելված, որը լռելյայն React հավելվածի էջն է.

Լրացում 1 թ

Angular-ի սիրահարների համար ունենք նաև օրինակ դիմում.

Այստեղ օրինաչափությունը նույնն է, բացառությամբ OUTPUT_DIR փոփոխականի:

Լրացում 2 թ

Այս հոդվածում մենք օգտագործեցինք NGINX-ը որպես վեբ սերվեր, բայց այն փոխարինելը Apache-ով բավականին հեշտ է, պարզապես փոխեք ձևանմուշը ֆայլում: NGINX պատկեր մասին Apache պատկեր.

Ամփոփում

Այս շարքի առաջին մասում մենք ցույց տվեցինք, թե ինչպես արագ տեղակայել ժամանակակից վեբ հավելվածները OpenShift հարթակում: Այսօր մենք նայեցինք, թե ինչ է անում վեբ հավելվածի պատկերը և ինչպես այն կարող է համակցվել մաքուր վեբ սերվերի հետ, ինչպիսին է NGINX-ը, օգտագործելով շղթայված կառուցվածքներ՝ ստեղծելու համար ավելի պատրաստի հավելվածի կառուցվածք: Այս շարքի հաջորդ և վերջին հոդվածում մենք ցույց կտանք, թե ինչպես աշխատեցնել զարգացման սերվեր ձեր հավելվածի համար OpenShift-ում և ապահովել տեղական և հեռավոր ֆայլերի համաժամացումը:

Այս հոդվածաշարի բովանդակությունը

1 մասը: ինչպես տեղադրել ժամանակակից վեբ հավելվածներ ընդամենը մի քանի քայլով;
Մաս 2. Ինչպես օգտագործել նոր S2I պատկերը գոյություն ունեցող HTTP սերվերի պատկերով, ինչպիսին է NGINX-ը, օգտագործելով հարակից OpenShift հավաքները արտադրության տեղակայման համար;
Մաս 3. ինչպես գործարկել զարգացման սերվեր ձեր հավելվածի համար OpenShift հարթակում և համաժամացնել այն տեղական ֆայլային համակարգի հետ:

Լրացուցիչ ռեսուրսներ

Անվճար էլեկտրոնային գիրք Տեղադրում OpenShift-ում.
Տեղեկություններ OpenShift և Kubernetes.

Source: www.habr.com

Ժամանակակից հավելվածներ OpenShift-ում, մաս 2. շղթայված կառուցումներ