Здравейте на всички в този блог! С вас е третият пост от серията, в която показваме как да развернете съвременни уеб приложения на Red Hat OpenShift.
В предишните два поста разказахме как да развернете съвременни уеб приложения само за няколко стъпки и как да използвате новия образ S2I заедно с готов образ на HTTP сървър, например, NGINX, с помощта на свързани билдове за организиране на продукционно развертане.
Днес ще ви покажем как да стартирате сървър за разработка на вашето приложение на платформата OpenShift и да го синхронизирате с локалната файлова система, както и ще говорим за това какво е OpenShift Pipelines и как може да се прилага като алтернатива на свързаните билдове.
OpenShift като среда за разработка
Работен процес на разработка
Както вече беше споменато в , стандартният процес на разработка за съвременни уеб приложения е просто нещо като „сървър за разработка“, който следи промените в локалните файлове. Когато те се случат, стартира се сборка на приложението, а след това то се обновява в браузъра.
В повечето съвременни фреймуъркове такъв „сървър за разработка“ е вграден в съответните инструменти за команден ред.
Локален пример
Първо, нека да видим как работи при местно стартиране на приложения. Като пример ще вземем приложението от предишните статии, въпреки че практически същите концепции на работния процес се прилагат и при всички други съвременни фреймуъркове.
И така, за да стартираме „сървър за разработка“ в нашия пример с React, ще въведем следната команда:
$ npm run start
Тогава в прозореца на терминала ще видим нещо подобно:
А нашето приложение ще се отвори в браузъра по подразбиране:
Сега, ако направим промени в файла, приложението трябва да се обнови в браузъра.
Добре, с разработката в локален режим всичко е ясно, а как да постигнем същото на OpenShift?
Сървър за разработка на OpenShift
Ако помните, в , разгледахме така наречената фаза на стартиране на образа S2I и видяхме, че по подразбиране обслужването на нашето уеб приложение се осъществява от модула serve.
Но ако погледнем по-внимателно от примера, в него има променлива на средата $NPM_RUN, която позволява да изпълним и своя команда.
Например, можете да използвате модула nodeshift, за да развернете приложението си:
$ npx nodeshift --deploy.env NPM_RUN="yarn start" --dockerImage=nodeshift/ubi8-s2i-web-app
Забележка: примерът по-горе е даден в съкратен вид, за да илюстрира основната идея.
Тук добавихме към нашето разгръщане променлива на средата NPM_RUN, която казва на етапа на изпълнение, че трябва да стартира командата yarn start, която стартира сървъра за разработка на React в нашия OpenShift pod.
Ако погледнем логовете на работещия 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 Pipelines
След това ще говорим за инструмент като OpenShift Pipelines и как може да се използва като алтернатива на свързаните сборки chained build.
Какво е OpenShift Pipelines
OpenShift Pipelines – облачно ориентирана CI/CD система за непрекъсната интеграция и доставка, предназначена за организиране на конвейери с помощта на Tekton. Tekton е гъвкав Kubernetes-нативен CI/CD фреймворк с отворен код, който автоматизира внедряването на различни платформи (Kubernetes, serverless, виртуални машини и т.н.) чрез абстракция от основния уровень.
За да разберете тази статия, са необходими определени знания по Pipelines, затова ви съветваме първо да се запознаете с .
Настройка на работна среда
За да изпробвате примерите от тази статия, първо трябва да подготвите работна среда:
- Инсталирайте и конфигурирайте OpenShift 4 клъстер. В нашите примери ще използваме CodeReady Containers (CRD), инструкции за инсталация можете да намерите .
- След като клъстерът е готов, трябва да инсталирате Pipeline Operator. Не се страхувайте, това е лесно, инструкции за инсталиране .
- Изтегли (tkn) .
- Стартирайте командния инструмент create-react-app, за да създадете приложение, което след това ще бъде внедрено (това е просто приложение ).
- (Опционално) Клонирайте репозитория, за да стартирате локално примера на приложението с командата npm install и след това npm start.
В репозитория на приложението също ще намерите папка k8s, където ще бъдат YAML файловете за Kubernetes/OpenShift, използвани за внедряване на приложението. Там ще има Tasks, ClusterTasks, Resources и Pipelines, които ще създадем в този .
Действия
Първо, за нашия пример трябва да създадем нов проект в OpenShift клъстера. Нека наречем този проект webapp-pipeline и да го създадем с следната команда:
$ oc new-project webapp-pipeline
След това, това име на проекта ще се появява в кода, така че, ако решите да го наречете по друг начин, не забравяйте да редактирате кода от примерите съответно. Започвайки от тук, ще действаме отдолу нагоре: тоест първо ще създадем всички компоненти на конвейера, а след това самия него.
И така, първо...
Задачи Tasks
Нека създадем две задачи (tasks), които след това ще помогнат за разгръщането на приложението в рамките на нашия конвейер pipeline. Първата задача – apply_manifests_task – отговаря за прилагането на YAML файловете на Kubernetes ресурсите (service, deployment и route), които се намират в папката 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
Забележка: това са локални задачи на текущия ви проект.
Клъстерни задачи Cluster tasks
Клъстерните задачи са по същество същото нещо като обикновените задачи. Тоест, това е повторно използваема колекция от стъпки, които се комбинират по определен начин при стартиране на конкретна задача. Разликата е, че клъстерната задача е достъпна навсякъде в рамките на клъстера. За да видим списъка на клъстерните задачи, които се създават автоматично при добавяне на Pipeline Operator, отново ще използваме командата 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.
Чудите се откъде знаем всичко това? От , просто я копирахме и я адаптирахме за себе си.
И така, сега създаваме кластерна задача 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: Местоположението на директорията за изход на изграждането
default: build
По подразбиране този параметър е равен на build, точно там React поставя сглобеното съдържание. В други фреймворци се използват различни пътища, например, в Ember това е dist. Изходът от нашата първа кластерна задача ще представлява образ, съдържащ сглобените от нас HTML, JavaScript и CSS.
Сглобяваме образ на базата на NGINX
Що се отнася до нашата втора кластерна задача, тя трябва да събира образ на базата на NGINX, използвайки съдържанието на вече сглобеното от нас приложение. Всъщност, това е частта от предишния раздел, където разглеждахме свързани сборки (chained builds).
За това ще създадем кластерна задача 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 указва на конкретен репозиторий и задава клон master (това е опционално, но го записваме за пълнота).
Сега трябва да създадем ресурс за образа, където ще се съхраняват резултатите от изпълнението на задачата 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 Image Registry, конкретно на този, който се намира в пространството на имената webapp-pipeline. Не забравяйте да промените този параметър, ако използвате друго пространство на имената.
И накрая, последният ресурс, от който ще се нуждаем, също ще има тип image и това ще бъде финалният образ на 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
Конвейер pipelinе
Сега, когато имаме всичките необходими компоненти, ще изградим конвейера, като създадем го с командата:
$ 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 виждаме указание за ресурсите, които създадохме по-рано:
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
Тази задача приема входните (git ресурс) и изходните (ресурс built-web-application-image) параметри. Също така ѝ предаваме специален параметър, за да не проверява TLS, тъй като използваме самоподписани сертификати:
ресурси:
входове:
- име: source
ресурс: web-application-repo
изходи:
- име: image
ресурс: built-web-application-image
параметри:
- име: TLSVERIFY
стойност: "false"
Следващата задача е почти същата, само че тук се извиква вече създадената от нас кластерна задача webapp-build-runtime:
име: build-runtime-image
taskRef:
име: webapp-build-runtime
вид: ClusterTask
Както и при предишната задача, ние предаваме ресурс, но сега това е built-web-application-image (изходът от предишната ни задача). И отново задаваме изображението като изход. Тъй като тази задача трябва да се изпълнява след предишната, добавяме полето runAfter:
ресурси:
входове:
- име: image
ресурс: built-web-application-image
изходи:
- име: image
ресурс: runtime-web-application-image
параметри:
- име: TLSVERIFY
стойност: "false"
runAfter:
- build-web-application
Следващите две задачи отговарят за прилагането на YAML файловете на услугата, маршрута и деплоймента, които се намират в каталога k8s на нашето уеб приложение, а също така и за обновяване на този деплоймент при създаване на нови изображения. Тези две кластерни задачи зададохме в началото на статията.
Стартиране на конвейера
И така, всички части на нашия конвейер са създадени и ще го стартираме с следната команда:
$ tkn pipeline start build-and-deploy-react
На този етап командният ред се използва в интерактивен режим и трябва да изберете съответните ресурси в отговор на всеки негов запит: за ресурса git избирате web-application-repo, след това за ресурса на първото изображение – built-web-application-image, и накрая за ресурса на второто изображение – 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}}'
За по-добра визуализация може да видим нашия конвейер в режим на разработчик на уеб конзолата в секцията Pipelines, както е показано на Рис. 1.
Рис.1. Преглед на стартираните конвейери.
Щракването върху стартирания конвейер показва допълнителна информация, както е показано на Рис.2.
Рис. 2. Допълнителна информация за конвейера.
След допълнителната информация може да видите стартираните приложения в изгледа Topology, както е показано на Рис.3.
Рис 3. Стартиран pod.
Щракването върху кръгчето в горния десен ъгъл на иконата отваря нашето приложение, както е показано на Рис.4.
Рис. 4. Стартирано приложение React.
Заключение
И така, показахме как да стартирате OpenShift разработващ сървър за приложението си и как да го синхронизирате с локалната файлова система. Също така разгледахме как да симулираме модела на chained-build с помощта на OpenShift Pipelines. Всички кодове от примерите в тази статия можете да намерите .
Допълнителни ресурси (EN)
- Безплатна електронна книга
- Други статии за на сайта на Red Hat
Анонси на предстоящи уебинари
Започваме серия от петъчни уебинари за нативния опит с Red Hat OpenShift Container Platform и Kubernetes:
Източник: habr.com
