Модерни приложения на OpenShift, част 2: верижни компилации

Здравейте всички! Това е втората публикация от нашата поредица, в която показваме как да разположим модерни уеб приложения на Red Hat OpenShift.

В предишната публикация засегнахме леко възможностите на новия S2I (source-to-image) строителен образ, който е предназначен за изграждане и внедряване на модерни уеб приложения на платформата OpenShift. Тогава се заинтересувахме от темата за бързо внедряване на приложение и днес ще разгледаме как да използваме S2I изображение като „чисто“ изображение на компилатор и да го комбинираме със свързани сглобки OpenShift.

Изчистено изображение на строителя

Както споменахме в част XNUMX, повечето съвременни уеб приложения имат така наречения етап на изграждане, който обикновено изпълнява операции като транспилация на код, конкатенация на множество файлове и минимизиране. Файловете, получени в резултат на тези операции - а това е статичен HTML, JavaScript и CSS - се съхраняват в изходната папка. Местоположението на тази папка обикновено зависи от това какви инструменти за изграждане се използват, а за React това ще бъде папката ./build (ще се върнем към това по-подробно по-долу).

Източник към изображение (S2I)

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

Фаза на сглобяване

Фазата на сглобяване е много подобна по природа на това, което се случва, когато стартирате компилация на docker и завършите с ново изображение на Docker. Съответно този етап възниква при стартиране на компилация на платформата OpenShift.

В случай на изображение на Web App Builder, то е отговорно за инсталирането на зависимостите на вашето приложение и изпълнението на компилацията. сглобяване на скрипт. По подразбиране изображението на компилатора използва конструкцията за изграждане на npm run, но това може да бъде заменено чрез променливата на средата 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 като „чист“ 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, ще бъде резултат от стъпка на асемблиране, която ще комбинира изображението по време на изпълнение на 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 хранилище и местоположението, реф и контекстната папка се определят от параметрите, които вече видяхме по-горе.

Редът, обозначен с 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 и започва доста стандартно.

Редът, означен с 1, не е нищо ново - той просто казва, че резултатът от компилацията се поставя в изображението за изпълнение на web-приложението.

Редът с етикет 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.

Внедряване на приложение

Така че сега, след като разгледахме шаблона, нека видим как да го използваме за внедряване на приложение.

Можем да използваме клиентския инструмент 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 App по подразбиране:

Допълнение 1г

За любителите на Angular също имаме примерно приложение.

Моделът тук е същият, с изключение на променливата OUTPUT_DIR.

Допълнение 2г

В тази статия използвахме NGINX като уеб сървър, но е доста лесно да го замените с Apache, просто сменете шаблона във файла Изображение на NGINX на Изображение на Apache.

Заключение

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

Съдържание на тази поредица от статии

• Част 1: как да разположите модерни уеб приложения само с няколко стъпки;
• Част 2: Как да използвате ново S2I изображение със съществуващо изображение на HTTP сървър, като например NGINX, като използвате асоциирани модули OpenShift за производствено внедряване;
• Част 3: как да стартирате сървър за разработка за вашето приложение на платформата OpenShift и да го синхронизирате с локалната файлова система.

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

• Безплатна електронна книга Внедряване в OpenShift.
• Информация за OpenShift и Kubernetes.

Източник: www.habr.com