Съвременни приложения на OpenShift, част 3: OpenShift като среда за разработка и конвейери на OpenShift

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

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

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

OpenShift като среда за разработка

работен процес за разработка

Както вече беше посочено в първи пост, типичният процес на разработка на съвременни уеб приложения е просто „сървър за разработка“, който проследява промените в локалните файлове. Когато се случат, компилацията на приложението се задейства и след това се актуализира в браузъра.

В повечето съвременни рамки такъв "сървър за разработка" е вграден в съответните инструменти на командния ред.

Местен пример

Първо, нека видим как работи в случай на стартиране на приложения локално. Да вземем за пример приложение. Реагират от предишни статии, въпреки че почти същите концепции на работния процес се прилагат за всички други съвременни рамки.
И така, за да стартираме „сървъра за разработка“ в нашия пример за React, ще напишем следната команда:

$ npm run start

След това в прозореца на терминала ще видим нещо подобно:

И нашето приложение ще се отвори в браузъра по подразбиране:

Сега, ако направим промени във файла, приложението трябва да се обнови в браузъра.

Добре, с разработката в локален режим всичко е ясно, но как да постигнем същото на OpenShift?

Сървър за разработка на OpenShift

Ако си спомняте в предишен пост, анализирахме така наречената фаза на изпълнение (фаза на изпълнение) на изображението S2I и видяхме, че по подразбиране нашето уеб приложение се обслужва от модула за обслужване.

Въпреки това, ако се вгледате по-отблизо стартирайте скрипт от този пример, тогава той има променливата на средата $NPM_RUN, която ви позволява да изпълните своя собствена команда.

Например, можем да използваме модула nodeshift, за да внедрим нашето приложение:

$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app

Забележка: Примерът по-горе е съкратен, за да илюстрира общата идея.

Тук добавихме променливата на средата NPM_RUN към нашето разгръщане, която казва на средата за изпълнение да изпълни командата за стартиране на yarn, която стартира сървъра за разработка на React в нашия OpenShift pod.

Ако погледнете дневника на работеща капсула, тогава ще има нещо подобно:

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

Синхронизиране на отдалечен и локален код

За щастие, nodeshift може лесно да помогне при синхронизирането и можете да използвате командата watch, за да проследявате промените.

След като изпълним командата за разгръщане на сървъра за разработка за нашето приложение, можем безопасно да използваме тази команда:

$ npx nodeshift watch

В резултат на това ще бъде направена връзка с работещия pod, който създадохме малко по-рано, синхронизирането на нашите локални файлове с отдалечения клъстер ще бъде активирано и файловете в нашата локална система ще започнат да се наблюдават за промени.

Следователно, ако сега актуализираме файла src/App.js, системата ще реагира на тези промени, ще ги копира в отдалечения клъстер и ще стартира сървъра за разработка, който след това ще актуализира нашето приложение в браузъра.

За да завършим картината, нека покажем как изглеждат тези команди в тяхната цялост:

$ npx nodeshift --strictSSL=false --dockerImage=nodeshift/ubi8-s2i-web-app --build.env YARN_ENABLED=true --expose --deploy.env NPM_RUN="yarn start" --deploy.port 3000

$ npx nodeshift watch --strictSSL=false

Командата watch е абстракция върху командата oc rsync, можете да научите повече за това как работи тук.

Това беше пример за React, но абсолютно същият метод може да се използва с други рамки, просто задайте променливата на средата NPM_RUN според нуждите.
 

Openshift тръбопроводи

След това ще говорим за инструмент като OpenShift Pipelines и как може да се използва като алтернатива на верижните компилации.

Какво е OpenShift Pipelines

OpenShift Pipelines е базирана на облак CI/CD непрекъсната интеграция и система за доставка за тръбопроводи, използващи Tekton. Tekton е гъвкава CI/CD рамка с отворен код на Kubernetes, която автоматизира внедряването в множество платформи (Kubernetes, без сървър, виртуални машини и т.н.), като се абстрахира от основния слой.

Разбирането на тази статия изисква известно познаване на тръбопроводите, така че силно ви съветваме първо да прочетете официален учебник.

Настройка на работната среда

За да си поиграете с примерите в тази статия, първо трябва да настроите работна среда:

1. Инсталирайте и конфигурирайте клъстер OpenShift 4. Нашите примери използват CodeReady Containers (CRD) за това, инструкциите за инсталиране за които можете да намерите тук.
2. След като клъстерът е готов, трябва да инсталирате Pipeline Operator върху него. Не се страхувайте, лесно е, инструкции за инсталиране тук.
3. Изтегляне Tekton CLI (tkn) тук.
4. Стартирайте инструмента за команден ред create-react-app, за да създадете приложение, което след това ще бъде внедрено (това е просто приложение Реагират).
5. (По избор) Клонирайте хранилището, за да стартирате примерното приложение локално с npm install и след това npm start.

Хранилището на приложения също ще има папка k8s, която ще съдържа Kubernetes/OpenShift YAML, използвани за внедряване на приложението. Ще има Tasks, ClusterTasks, Resources и Pipelines, които ще създадем в това хранилища.

Захващам се

Първата стъпка за нашия пример е да създадете нов проект в клъстера OpenShift. Нека наименуваме този проект webapp-pipeline и го създадем със следната команда:

$ oc new-project webapp-pipeline

По-късно това име на проекта ще се появи в кода, така че ако решите да го кръстите по друг начин, не забравяйте да редактирате съответно кода от примерите. Започвайки от тази точка, ще преминем не отгоре надолу, а отдолу нагоре: тоест първо ще създадем всички компоненти на конвейера и едва след това самия него.

И така, на първо място…

Задачи

Нека създадем няколко задачи (задачи), които след това ще помогнат за внедряването на приложението в рамките на нашия тръбопровод. Първата задача, apply_manifests_task, отговаря за прилагането на YAML на онези ресурси на Kubernetes (услуга, внедряване и маршрут), които се намират в папката k8s на нашето приложение. Втората задача - update_deployment_task - отговаря за актуализирането на вече внедрено изображение до създаденото от нашия конвейер.

Не се притеснявайте, ако все още не е много ясно. Всъщност тези задачи са нещо като помощни програми и ще ги разгледаме по-подробно малко по-късно. Засега нека просто ги създадем:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/update_deployment_task.yaml
$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/tasks/apply_manifests_task.yaml

След това, като използвате командата tkn CLI, проверете дали задачите са създадени:

$ tkn task ls

NAME                AGE
apply-manifests     1 minute ago
update-deployment   1 minute ago

Забележка: Това са локални задачи за текущия ви проект.

Клъстерни задачи

Клъстерните задачи са основно същите като обикновените задачи. Тоест, това е повторно използваема колекция от стъпки, които се комбинират по един или друг начин, когато се стартира определена задача. Разликата е, че клъстерната задача е достъпна навсякъде в клъстера. За да видите списъка с клъстерни задачи, които се създават автоматично, когато се добави оператор на конвейер, използвайте отново командата tkn CLI:

$ tkn clustertask ls

NAME                       AGE
buildah                    1 day ago
buildah-v0-10-0            1 day ago
jib-maven                  1 day ago
kn                         1 day ago
maven                      1 day ago
openshift-client           1 day ago
openshift-client-v0-10-0   1 day ago
s2i                        1 day ago
s2i-go                     1 day ago
s2i-go-v0-10-0             1 day ago
s2i-java-11                1 day ago
s2i-java-11-v0-10-0        1 day ago
s2i-java-8                 1 day ago
s2i-java-8-v0-10-0         1 day ago
s2i-nodejs                 1 day ago
s2i-nodejs-v0-10-0         1 day ago
s2i-perl                   1 day ago
s2i-perl-v0-10-0           1 day ago
s2i-php                    1 day ago
s2i-php-v0-10-0            1 day ago
s2i-python-3               1 day ago
s2i-python-3-v0-10-0       1 day ago
s2i-ruby                   1 day ago
s2i-ruby-v0-10-0           1 day ago
s2i-v0-10-0                1 day ago

Сега нека създадем две клъстерни задачи. Първият ще генерира S2I изображение и ще го изпрати до вътрешния регистър на OpenShift; второто е да изградим нашето базирано на NGINX изображение, използвайки приложението, което вече сме създали като съдържание.

Създайте и изпратете изображение

Когато създаваме първата задача, ще повторим това, което вече направихме в предишната статия за свързаните сборки. Спомнете си, че използвахме S2I изображението (ubi8-s2i-web-app), за да „изградим“ нашето приложение и завършихме с изображение, съхранено във вътрешния регистър на OpenShift. Сега ще използваме това изображение на S2I уеб приложение, за да създадем DockerFile за нашето приложение и след това ще използваме Buildah, за да изградим и изпратим полученото изображение към вътрешния регистър на OpenShift, тъй като това е точно това, което OpenShift прави, когато разгръщате вашите приложения с помощта на NodeShift.

Откъде знаем всичко това, питате вие? от официална версия на официалния Node.js, ние просто го копирахме и го завършихме за себе си.

И така, сега създаваме задачата на клъстера s2i-web-app:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/s2i-web-app-task.yaml

Няма да анализираме това подробно, а само да се спрем на параметъра OUTPUT_DIR:

params:
      - name: OUTPUT_DIR
        description: The location of the build output directory
        default: build

По подразбиране този параметър е build, където React поставя изграденото съдържание. Други рамки използват различни пътища, например в Ember това е dist. Резултатът от нашата първа клъстерна задача ще бъде изображение, съдържащо HTML, JavaScript и CSS, които сме събрали.

Ние изграждаме изображение, базирано на NGINX

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

За да направим това, ние - точно както малко по-горе - създаваме клъстерна задача на webapp-build-runtime:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/clustertasks/webapp-build-runtime-task.yaml

Ако погледнете кода за тези клъстерни задачи, можете да видите, че той не посочва Git хранилището, с което работим, или имената на изображенията, които създаваме. Ние само определяме какво точно предаваме на Git или някакво изображение, където искаме да изведем крайното изображение. Ето защо тези клъстерирани задачи могат да се използват повторно при работа с други приложения.

И след това грациозно преминаваме към следващата точка ...

Ресурсы

Така че, тъй като, както току-що казахме, клъстерните задачи трябва да бъдат възможно най-общи, трябва да създадем ресурси, които ще се използват във входа (Git хранилище) и изхода (крайни изображения). Първият ресурс, от който се нуждаем, е Git, където се намира нашето приложение, нещо подобно:

# This resource is the location of the git repo with the web application source
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: web-application-repo
spec:
  type: git
  params:
    - name: url
      value: https://github.com/nodeshift-starters/react-pipeline-example
    - name: revision
      value: master

Тук PipelineResource е от тип git. Url ключът в секцията params сочи към конкретно хранилище и задава главния клон (това не е задължително, но го пишем за пълнота).

Сега трябва да създадем ресурс за изображението, където ще бъдат запазени резултатите от задачата на s2i-web-app, това се прави по следния начин:

# This resource is the result of running "npm run build",  the resulting built files will be located in /opt/app-root/output
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: built-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-application:latest

Тук PipelineResource е от тип image и стойността на url параметъра сочи към вътрешния регистър на изображенията на OpenShift, по-специално този в пространството на имената на webapp-pipeline. Не забравяйте да промените тази настройка, ако използвате различно пространство от имена.

И накрая, последният ресурс, от който се нуждаем, също ще бъде от тип изображение и това ще бъде окончателното изображение на NGINX, което след това ще бъде използвано по време на внедряването:

# This resource is the image that will be just the static html, css, js files being run with nginx
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: runtime-web-application-image
spec:
  type: image
  params:
    - name: url
      value: image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtime-web-application:latest

Отново имайте предвид, че този ресурс съхранява изображението във вътрешния регистър на OpenShift в пространството на имената на webapp-pipeline.

За да създадем всички тези ресурси наведнъж, използваме командата create:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/resources/resource.yaml

За да сте сигурни, че ресурсите са създадени, можете да направите следното:

$ tkn resource ls

тръбопровод

Сега, след като имаме всички необходими компоненти, ще сглобим конвейер от тях, като го създадем със следната команда:

$ oc create -f https://raw.githubusercontent.com/nodeshift/webapp-pipeline-tutorial/master/pipelines/build-and-deploy-react.yaml

Но преди да изпълним тази команда, нека да разгледаме тези компоненти. Първото е името:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: build-and-deploy-react

След това в секцията със спецификации виждаме индикация за ресурсите, които създадохме по-рано:

spec:
  resources:
    - name: web-application-repo
      type: git
    - name: built-web-application-image
      type: image
    - name: runtime-web-application-image
      type: image

След това създаваме задачи за изпълнение на нашия конвейер. На първо място, той трябва да изпълни задачата s2i-web-app, която вече сме създали:

tasks:
    - name: build-web-application
      taskRef:
        name: s2i-web-app
        kind: ClusterTask

Тази задача приема входни (gir ресурс) и изходни (built-web-application-image resource) параметри. Ние също му предаваме специален параметър, така че да не проверява TLS, тъй като използваме самоподписани сертификати:

resources:
        inputs:
          - name: source
            resource: web-application-repo
        outputs:
          - name: image
            resource: built-web-application-image
      params:
        - name: TLSVERIFY
          value: "false"

Следващата задача е почти същата, само клъстерната задача на webapp-build-runtime, която вече създадохме, се извиква тук:

name: build-runtime-image
    taskRef:
      name: webapp-build-runtime
      kind: ClusterTask

Както при предишната задача, ние предаваме ресурс, но сега той е вградено изображение на уеб приложение (изходът от предишната ни задача). И като заключение отново задаваме изображението. Тъй като тази задача трябва да се изпълни след предишната, добавяме полето runAfter:

resources:
        inputs:
          - name: image
            resource: built-web-application-image
        outputs:
          - name: image
            resource: runtime-web-application-image
        params:
        - name: TLSVERIFY
          value: "false"
      runAfter:
        - build-web-application

Следващите две задачи отговарят за прилагането на услугата, маршрута и YAML файловете за разполагане, които се намират в директорията k8s на нашето уеб приложение, и за актуализирането на това внедряване, когато се създават нови изображения. Поставихме тези две задачи на клъстера в началото на статията.

Изпълнение на тръбопровода

И така, всички части на нашия тръбопровод са създадени и ще го стартираме със следната команда:

$ tkn pipeline start build-and-deploy-react

В този момент командният ред се използва интерактивно и подходящите ресурси трябва да бъдат избрани в отговор на всяка от неговите заявки: за git ресурса изберете web-application-repo, след това за първия ресурс за изображение вградено уеб-приложение- изображение и накрая за втори ресурс за изображение –изображение на web-приложение по време на изпълнение:

? Choose the git resource to use for web-application-repo: web-application-repo (https://github.com/nodeshift-starters/react-pipeline-example)
? Choose the image resource to use for built-web-application-image: built-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/built-web-
application:latest)
? Choose the image resource to use for runtime-web-application-image: runtime-web-application-image (image-registry.openshift-image-registry.svc:5000/webapp-pipeline/runtim
e-web-application:latest)
Pipelinerun started: build-and-deploy-react-run-4xwsr

Сега проверете състоянието на тръбопровода със следната команда:

$ tkn pipeline logs -f

След като тръбопроводът стартира и приложението бъде разгърнато, направете запитване към публикувания маршрут със следната команда:

$ oc get route react-pipeline-example --template='http://{{.spec.host}}'

За по-голяма видимост можете да видите нашия тръбопровод в режима за разработчици на уеб конзолата в секцията Тръбопроводикакто е показано на фиг. 1.

Фиг. 1. Преглед на работещи тръбопроводи.

Щракването върху работещ тръбопровод показва допълнителни подробности, както е показано на фигура 2.

Ориз. 2. Допълнителна информация за конвейера.

След повече подробности можете да видите работещите приложения в изгледа топология, както е показано на фиг.3.

Фиг. 3. Течаща капсула.

Щракването върху кръга в горния десен ъгъл на иконата отваря нашето приложение, както е показано на фигура 4.

Ориз. 4. Работещо приложение React.

Заключение

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

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

• Безплатна електронна книга „Разработка на OpenShift: Ръководство за нетърпеливите“
• Изграждане на контейнеризирани Node.js приложения с помощта на Runtimes на приложения Red Hat OpenShift и Istio
• Отстраняване на грешки в приложения Node.js на OpenShift с Chrome DevTools
• Три команди за овладяване на Express на OpenShift от нулата
• Обявяване на публичната версия на Node.js като част от Runtimes на приложението Red Hat OpenShift
• Мониторинг на Node.js приложения на OpenShift с Prometheus
• Повече за OpenShift и Kubernetes на уебсайта на Red Hat

Съобщения за предстоящи уебинари

Започваме поредица от петъчни уебинари за естественото изживяване при използването на Red Hat OpenShift Container Platform и Kubernetes:

• 28 август, уебинар Emperor „Operator“: Оператори в OpenShift и Kubernetes
• 11 септември, DeploymentConfig срещу Deployment – ​​специфична за OpenShift магия за изграждане и внедряване на приложения
• 25 септември, Red Hat OpenShift и Machine API
• 9 октомври Как да се справим с внезапното увеличаване на обема на работа
• 23 октомври, Embedded Jenkins, Pipeline-builds, Tekton на Red Hat OpenShift Container Platform

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