Модерни апликации на OpenShift, дел 2: оковани градби

Здраво на сите! Ова е втор пост во нашата серија во кој покажуваме како да распоредиме модерни веб-апликации на Red Hat OpenShift.

Во претходниот пост, малку ги допревме можностите на новата S2I (извор-на-слика) градител слика, која е наменета за градење и распоредување на модерни веб-апликации на платформата OpenShift. Тогаш бевме заинтересирани за темата за брзо распоредување на апликацијата, а денес ќе погледнеме како да користиме S2I слика како „чиста“ градежна слика и да ја комбинираме со сродни склопови на OpenShift.

Чиста слика на градител

Како што споменавме во Дел XNUMX, повеќето модерни веб-апликации имаат таканаречена фаза на градење, која обично врши операции како што се транспилација на код, поврзување на повеќе датотеки и минификување. Датотеките добиени како резултат на овие операции - и ова е статичен HTML, JavaScript и CSS - се зачувани во излезната папка. Локацијата на оваа папка обично зависи од тоа кои алатки за градење се користат, а за React ова ќе биде папката ./build (ќе се навратиме на ова подетално подолу).

Извор до слика (S2I)

Во овој пост не ја допираме темата „што е S2I и како да се користи“ (можете да прочитате повеќе за ова тука), но важно е да се биде јасно за двата чекори во овој процес за да се разбере што прави сликата на Web App Builder.

Фаза на склопување

Фазата на склопување е многу слична по природа на она што се случува кога ќе ја стартувате докер build и ќе завршите со нова слика на Docker. Соодветно на тоа, оваа фаза се јавува при започнување на изградба на платформата OpenShift.

Во случај на слика на Web App Builder, таа е одговорна за инсталирање на зависностите на вашата апликација и извршување на изградбата. состави скрипта. Стандардно, сликата на градителот ја користи конструкцијата за изградба на npm, но ова може да се отфрли преку променливата на околината NPM_BUILD.

Како што рековме претходно, локацијата на готовата, веќе изградена апликација зависи од тоа кои алатки ги користите. На пример, во случајот React ова ќе биде папката ./build, а за Angular апликациите ќе биде папката project_name/dist. И, како што веќе беше прикажано во претходниот пост, локацијата на излезниот директориум, кој е стандардно поставен да се гради, може да се отфрли преку променливата на околината OUTPUT_DIR. Па, бидејќи локацијата на излезната папка се разликува од рамка до рамка, едноставно го копирате генерираниот излез во стандардната папка на сликата, имено /opt/apt-root/output. Ова е важно за разбирање на остатокот од овој напис, но сега за сега брзо да ја погледнеме следната фаза - фазата на трчање.

фаза на трчање

Оваа фаза се јавува кога ќе се изврши повик до docker run на новата слика создадена за време на фазата на склопување. Истото се случува и при распоредување на платформата 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 и доаѓа од nodeshift/ubi8-s2i-web-app означена 10.x на Докер центар.

Четвртата е слика 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 вели дека резултатот од оваа градба ќе биде ставен во истата слика на react-web-app-builder што ја видовме малку порано во делот ImageStreams.

Линијата означена со 2 ви кажува од каде да го добиете кодот. Во нашиот случај, ова е складиште за git, а локацијата, ref и папката за контекст се одредуваат според параметрите што веќе ги видовме погоре.

Линијата означена со 3 е она што веќе го видовме во делот за параметри. Ја додава променливата на околината OUTPUT_DIR, која во нашиот пример е build.
Линијата означена со 4 вели да се користи сликата на веб-апликација-градител-траење, која веќе ја видовме во делот ImageStream.

Линијата означена со 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

Значи, втората конфигурација за изградба е 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.

Втората команда едноставно создава нова апликација врз основа на овој шаблон.

Откако ќе работат овие команди, ќе видиме дека имаме две склопови:

И враќајќи се на екранот Преглед, ќе го видиме лансираниот под:

Кликнете на врската и ќе бидеме однесени до нашата апликација, која е стандардната страница на апликацијата React:

Додаток 1 година

За љубителите на Angular исто така имаме пример апликација.

Шемата овде е иста, освен за променливата OUTPUT_DIR.

Додаток 2 година

Во оваа статија го користевме NGINX како веб-сервер, но прилично е лесно да го замените со Apache, само сменете го шаблонот во датотеката Слика NGINX на Апачи слика.

Заклучок

Во првиот дел од оваа серија, покажавме како брзо да се распоредат модерни веб-апликации на платформата OpenShift. Денес погледнавме што прави сликата на веб-апликација и како може да се комбинира со чист веб-сервер како NGINX со помош на оковани конструкции за да се создаде повеќе подготвена за производство на апликација. Во следната и последна статија од оваа серија, ќе покажеме како да стартувате сервер за развој за вашата апликација на OpenShift и да обезбедите синхронизација на локални и оддалечени датотеки.

Содржина на оваа серија написи

• Дел 1: како да распоредите модерни веб-апликации во само неколку чекори;
• Дел 2: Како да се користи нова слика S2I со постоечка слика на серверот HTTP, како што е NGINX, користејќи поврзани склопови на OpenShift за распоредување на производството;
• Дел 3: како да извршите развојен сервер за вашата апликација на платформата OpenShift и да го синхронизирате со локалниот датотечен систем.

Дополнителни ресурси

• Бесплатна е-книга Се распоредува на OpenShift.
• Информации за OpenShift и Kubernetes.

Извор: www.habr.com