🥇Модерни апликации на OpenShift, дел 3: OpenShift како развојна средина и OpenShift Pipelines

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

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

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

OpenShift како развојна средина

Работен тек на развој

Како што е веќе наведено во првиот пост, типичниот процес на развој за модерни веб-апликации е едноставно некој вид „развојен сервер“ кој ги следи промените во локалните датотеки. Кога ќе се појават, се активира изградбата на апликацијата и потоа се ажурира на прелистувачот.

Во повеќето модерни рамки, таков „сервер за развој“ е вграден во соодветните алатки на командната линија.

Локален пример

Прво, да видиме како ова функционира кога се извршуваат апликациите локално. Да ја земеме апликацијата како пример Реагираат од претходните написи, иако речиси истите концепти на работниот тек се применуваат во сите други модерни рамки.
Значи, за да го стартуваме „dev server“ во нашиот пример 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 подлога.

Ако го погледнете дневникот на трчање, ќе изгледа вака:

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

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

За среќа, nodeshift лесно може да помогне при синхронизацијата и можете да ја користите командата часовник за следење на промените.

Значи, откако ќе ја извршиме командата за распоредување на развојниот сервер за нашата апликација, можеме безбедно да ја користиме следнава команда:

$ npx nodeshift watch

Како резултат на тоа, ќе се направи врска со подлогата што работи малку порано, ќе се активира синхронизацијата на нашите локални датотеки со далечинскиот кластер и датотеките на нашиот локален систем ќе почнат да се следат за промени.

Затоа, ако сега ја ажурираме датотеката 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

Командата часовник е апстракција на врвот на командата oc rsync, можете да дознаете повеќе за тоа како функционира тука.

Ова беше пример за React, но истиот метод може да се користи и со други рамки, само поставете ја променливата на околината NPM_RUN како што е потребно.

Openshift цевководи

Следно, ќе зборуваме за алатка како OpenShift Pipelines и како таа може да се користи како алтернатива на окованите конструкции.

Што се OpenShift Pipelines

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

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

Поставување на вашата работна средина

За да си поиграте со примерите во оваа статија, прво треба да ја подготвите вашата работна средина:

Инсталирајте и конфигурирајте кластер OpenShift 4. Нашите примери користат CodeReady Containers (CRD) за ова, инструкции за инсталација за кои може да се најдат тука.
Откако кластерот е подготвен, треба да го инсталирате операторот на цевководи на него. Не плашете се, лесно е, инструкции за инсталација тука.
Превземи Tekton CLI (tkn) тука.
Извршете ја алатката за командна линија create-react-app за да креирате апликација која потоа ќе ја распоредите (ова е едноставна апликација Реагираат).
(Изборно) Клонирајте го складиштето за да ја извршите апликацијата пример локално со npm инсталација и потоа стартување npm.

Складиштето на апликации ќе има и папка 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-веб-апликации:

$ 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. УРЛ-клучот во делот парами укажува на одредено складиште и ја одредува главната гранка (ова е опционално, но ние го пишуваме заради комплетноста).

Сега треба да создадеме ресурс за сликата каде што ќе се зачуваат резултатите од задачата 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 е од типот слика, а вредноста на параметарот 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 во именскиот простор на веб-апликацијата.

За да ги создадеме сите овие ресурси одеднаш, ја користиме командата за создавање:

$ 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 ресурс) и излезни (изградена веб-апликација-ресурс за слика) параметри. Исто така, му пренесуваме посебен параметар за да не го потврди 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, изберете веб-апликација-репо, потоа за првиот ресурс со слика, вградена веб-апликација -слика, и конечно, за ресурс на втора слика -runtime-web-application-image:

? 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. Сите примери на кодови од овој напис може да се најдат тука.

Дополнителни ресурси (EN)

Бесплатна е-книга „Развој на OpenShift: водич за нетрпеливите“
Градење на контејнер-центрични апликации Node.js користејќи Red Hat OpenShift Application Runtimes и Istio
Дебагирање на апликациите Node.js на OpenShift со помош на Chrome DevTools
Три команди за совладување на Express на OpenShift од нула
Најава за општо достапната верзија на Node.js како дел од Red Hat OpenShift Application Runtimes
Следење на апликациите на Node.js на OpenShift со Prometheus
Други статии на OpenShift и Kubernetes на веб-страницата на Red Hat

Најави за претстојните вебинари

Започнуваме серија вебинари во петок за мајчин искуство со користење на Red Hat OpenShift Container Platform и Kubernetes:

Извор: www.habr.com

Модерни апликации на OpenShift, дел 3: OpenShift како развојна средина и OpenShift Pipelines