🥇OpenShift-тегі заманауи қолданбалар, 2-бөлім: тізбектелген құрылымдар

Бәріңе сәлем! Бұл Red Hat OpenShift жүйесінде заманауи веб-қосымшаларды қалай орналастыру керектігін көрсететін сериямыздың екінші жазбасы.

Алдыңғы мақалада біз OpenShift платформасында заманауи веб-қосымшаларды құруға және орналастыруға арналған жаңа S2I (көзден суретке) құрастырушы кескінінің мүмкіндіктеріне аздап тоқталған болатынбыз. Содан кейін бізді қолданбаны жылдам орналастыру тақырыбы қызықтырды және бүгін біз S2I кескінін «таза» құрастырушы кескіні ретінде қалай пайдалану керектігін және оны қатысты OpenShift жинақтарымен біріктіруді қарастырамыз.

Таза құрастырушы кескіні

XNUMX-бөлімде атап өткеніміздей, қазіргі заманғы веб-қосымшалардың көпшілігінде әдетте код транспиляциясы, бірнеше файлды біріктіру және кішірейту сияқты операцияларды орындайтын құрастыру кезеңі бар. Осы операциялардың нәтижесінде алынған файлдар - бұл тұрақты HTML, JavaScript және CSS - шығыс қалтасында сақталады. Бұл қалтаның орны әдетте қандай құрастыру құралдарының пайдаланылып жатқанына байланысты, ал React үшін бұл ./build қалтасы болады (бұл туралы төменде толығырақ қайталаймыз).

Дереккөзден кескінге (S2I)

Бұл постта біз «S2I дегеніміз не және оны қалай пайдалану керек» тақырыбын қозғамаймыз (бұл туралы толығырақ оқуға болады) осында), бірақ Web App Builder кескінінің не істейтінін түсіну үшін осы процестің екі қадамы туралы түсінікті болу маңызды.

Құрастыру кезеңі

Құрастыру кезеңі докер құрастыруын іске қосқанда және жаңа Docker кескінімен аяқталғанда болатын жағдайға табиғаты бойынша өте ұқсас. Тиісінше, бұл кезең OpenShift платформасында құрастыруды бастаған кезде орын алады.

Web App Builder кескіні жағдайында ол қолданбаның тәуелділіктерін орнатуға және құрастыруды іске қосуға жауапты. сценарийді құрастыру. Әдепкі бойынша, құрастырушы кескіні npm іске қосу құрастыру құрылымын пайдаланады, бірақ оны NPM_BUILD ортасының айнымалы мәні арқылы қайта анықтауға болады.

Жоғарыда айтқанымыздай, дайын, қазірдің өзінде салынған қолданбаның орны қандай құралдарды пайдаланатыныңызға байланысты. Мысалы, React жағдайында бұл ./build қалтасы болады, ал бұрыштық қолданбалар үшін жоба_аты/дист қалтасы болады. Алдыңғы жазбада көрсетілгендей, әдепкі бойынша құрастыруға орнатылған шығыс каталогының орнын OUTPUT_DIR ортасының айнымалы мәні арқылы қайта анықтауға болады. Шығару қалтасының орны әр жақтау үшін әр түрлі болғандықтан, сіз жасалған нәтижені суреттегі стандартты қалтаға көшіре аласыз, атап айтқанда /opt/apt-root/output. Бұл мақаланың қалған бөлігін түсіну үшін маңызды, бірақ әзірге келесі кезеңді - жүгіру кезеңін жылдам қарастырайық.

жүгіру кезеңі

Бұл кезең құрастыру кезеңінде жасалған жаңа кескінде докерді іске қосуға шақыру жасалған кезде орын алады. OpenShift платформасында орналастыру кезінде де солай болады. Әдепкі сценарийді іске қосыңыз пайдаланады қызмет ету модулі жоғарыдағы стандартты шығыс каталогында орналасқан статикалық мазмұнға қызмет көрсету.

Бұл әдіс қолданбаларды жылдам орналастыру үшін жақсы, бірақ әдетте бұл жолмен статикалық мазмұнға қызмет көрсету ұсынылмайды. Шындығында біз тек статикалық мазмұнға қызмет көрсететіндіктен, кескінімізге Node.js орнатудың қажеті жоқ - веб-сервер жеткілікті.

Басқаша айтқанда, құрастыру кезінде бізге бір нәрсе керек, орындау кезінде бізге басқа. Бұл жағдайда тізбектелген құрылымдар пайдалы болады.

Тізбектелген құрылыстар

Бұл туралы олар жазады тізбектелген құрылыстар OpenShift құжаттамасында:

«Екі жинақты бір-бірімен байланыстыруға болады, олардың бірі құрастырылған нысанды жасайды, ал екіншісі сол нысанды іске қосу үшін пайдаланылатын бөлек кескінде орналастырады».

Басқаша айтқанда, біз құрастыруды іске қосу үшін Web App Builder кескінін пайдалана аламыз, содан кейін мазмұнымызға қызмет көрсету үшін веб-сервер кескінін, сол 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 және ол 8.x тегтері бар nodeshift/ubi2-s10i-web-app қолданбасынан келеді Докер хабы.

Төртінші - соңғы тегі қосылған NGINX кескіні (1.12 нұсқасы). Докер хабы.

Енді алғашқы екі суретке назар аударайық. Олардың екеуі де басында бос және тек құрастыру кезеңінде жасалады. Бірінші сурет, react-web-app-builder, веб-бағдарлама-құрастырушы-орындау уақыты кескіні мен бастапқы кодты біріктіретін құрастыру қадамының нәтижесі болады. Сондықтан біз бұл суреттің атына «-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 белгісі бар жол осы құрастырудың нәтижесі ImageStreams бөлімінде сәл бұрын көрген сол реакциялық веб-бағдарлама құрастырушы кескінінде орналастырылатынын айтады.

2 деп белгіленген жол кодты қайдан алуға болатынын көрсетеді. Біздің жағдайда бұл git репозиторийі және орналасқан жері, сілтемесі және мәтінмәндік қалта біз жоғарыда көрген параметрлермен анықталады.

3 деп белгіленген жолды біз параметрлер бөлімінде көрдік. Ол OUTPUT_DIR ортасының айнымалы мәнін қосады, ол біздің мысалда құрастырылады.
4 деп белгіленген жол біз ImageStream бөлімінде көрген web-app-builder-орындау уақыты кескінін пайдалану керектігін айтады.

5 деп белгіленген жол S2I кескіні оны қолдаса және Web App Builder кескіні қолдаса, қосымша құрастыруды пайдаланғымыз келетінін айтады. Бірінші іске қосуда, құрастыру кезеңі аяқталғаннан кейін кескін node_modules қалтасын мұрағаттық файлға сақтайды. Содан кейін, келесі іске қосуларда кескін құрастыру уақытын азайту үшін осы қалтаны жай ғана ашады.

Соңында, 6 деп белгіленген жол - бұл бірдеңе өзгерген кезде қолмен араласусыз құрастыруды автоматты түрде іске қосу үшін бірнеше триггерлер.

Жалпы, бұл өте стандартты құрастыру конфигурациясы.

Енді екінші құрастыру конфигурациясын қарастырайық. Бұл біріншіге өте ұқсас, бірақ бір маңызды айырмашылық бар.

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

Сонымен, екінші құрастыру конфигурациясы реакция-веб-бағдарламаны орындау уақыты болып табылады және ол өте стандартты болып басталады.

1 деп белгіленген жол жаңалық емес - ол жай ғана құрастыру нәтижесі react-web-app-runtime кескініне енгізілгенін айтады.

Алдыңғы конфигурациядағыдай 2 деп белгіленген жол бастапқы кодты қайдан алу керектігін көрсетеді. Бірақ байқасаңыз, бұл жерде суреттен алынғанын айтып отырмыз. Сонымен қатар, біз жаңадан жасаған кескіннен - react-web-app-builder-тен (3-ші жолда көрсетілген). Біз пайдаланғымыз келетін файлдар кескіннің ішінде және олардың орны 4 деп белгіленген жолда орнатылған, біздің жағдайда бұл /opt/app-root/output/. Естеріңізде болса, бұл жерде біздің қолданбаны құру нәтижелері бойынша жасалған файлдар сақталады.

5 белгісі бар терминде көрсетілген мақсатты қалта жай ғана ағымдағы каталог болып табылады (мұның бәрі жергілікті компьютерде емес, OpenShift деп аталатын сиқырлы нәрсенің ішінде жұмыс істейтінін есте сақтаңыз).

Стратегия бөлімі – 6 деп белгіленген жол да бірінші құрастыру конфигурациясына ұқсас. Тек осы жолы біз ImageStream бөлімінде көрген nginx-image-runtime функциясын қолданамыз.

Соңында, 7 деп белгіленген жол реакция веб-бағдарлама құрастырушы кескіні өзгерген сайын осы құрастыруды белсендіретін триггерлер бөлімі болып табылады.

Әйтпесе, бұл үлгіде жеткілікті стандартты орналастыру конфигурациясы, сондай-ақ қызметтер мен маршруттарға қатысты нәрселер бар, бірақ біз бұл туралы тым көп егжей-тегжейлі қарастырмаймыз. Орналастырылатын кескін реакциялық веб-бағдарламаның орындалу уақыты кескіні екенін ескеріңіз.

Қолданбаны орналастыру

Енді біз үлгіні қараған соң, оны қолданбаны орналастыру үшін қалай пайдалану керектігін көрейік.

Үлгімізді орналастыру үшін oc деп аталатын OpenShift клиент құралын пайдалана аламыз:

$ 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.

Екінші пәрмен осы үлгіге негізделген жаңа қолданбаны жасайды.

Осы командалар жұмыс істегеннен кейін бізде екі ассамблея бар екенін көреміз:

Шолу экранына оралсақ, біз іске қосылған подкастты көреміз:

Сілтемені басыңыз, сонда біз қолданбамызға өтеміз, ол әдепкі React қолданбасы беті:

Қосымша 1

Бұрыштық әуесқойлар үшін бізде де бар мысал қолданбасы.

Мұндағы үлгі OUTPUT_DIR айнымалысын қоспағанда, бірдей.

Қосымша 2

Бұл мақалада біз NGINX-ті веб-сервер ретінде қолдандық, бірақ оны Apache-мен ауыстыру өте оңай, файлдағы үлгіні өзгерту жеткілікті. NGINX кескіні туралы Apache кескіні.

қорытынды

Осы серияның бірінші бөлігінде біз OpenShift платформасында заманауи веб-қосымшаларды қалай жылдам орналастыру керектігін көрсеттік. Бүгін біз Web App кескінінің не істейтінін және оны NGINX сияқты таза веб-сервермен қалай біріктіруге болатынын, өндіріске дайын қосымшалар құрастыруын жасау үшін тізбектелген құрастырмаларды қолданып қарастырдық. Осы сериядағы келесі және соңғы мақалада біз OpenShift бағдарламасында қолданбаңыз үшін әзірлеу серверін қалай іске қосу керектігін және жергілікті және қашықтағы файлдарды синхрондауды қамтамасыз етуді көрсетеміз.

Осы мақалалар топтамасының мазмұны

1 бөлімі: бірнеше қадамда заманауи веб-қосымшаларды қалай орналастыруға болады;
2-бөлім: NGINX сияқты бұрыннан бар HTTP сервер кескінімен жаңа S2I кескінін өндірісті орналастыру үшін байланысты OpenShift жинақтарын пайдалану жолы;
3-бөлім: OpenShift платформасында қолданбаға арналған әзірлеу серверін іске қосу және оны жергілікті файлдық жүйемен синхрондау.

Қосымша ресурстар

Тегін электронды кітап OpenShift қолданбасына орналастыру.
туралы ақпарат OpenShift және Kubernetes.

Ақпарат көзі: www.habr.com

OpenShift-тегі заманауи қолданбалар, 2-бөлім: тізбектелген құрылымдар