🥇თანამედროვე აპლიკაციები OpenShift-ზე, ნაწილი 3: OpenShift როგორც განვითარების გარემო და OpenShift Pipelines

გამარჯობა ყველას ამ ბლოგზე! ეს არის სერიის მესამე პოსტი, რომელშიც ჩვენ ვაჩვენებთ, თუ როგორ უნდა განვათავსოთ თანამედროვე ვებ აპლიკაციები Red Hat OpenShift-ზე.

წინა ორ პოსტში, ჩვენ ვაჩვენეთ, თუ როგორ უნდა განვათავსოთ თანამედროვე ვებ აპლიკაციები სულ რამდენიმე ნაბიჯში და როგორ გამოვიყენოთ ახალი S2I სურათი, თაროზე არსებული HTTP სერვერის სურათთან ერთად, როგორიცაა NGINX, ჯაჭვური კონსტრუქციების გამოყენებით წარმოების განლაგების ორკესტრირებისთვის. .

დღეს ჩვენ გაჩვენებთ, თუ როგორ უნდა გაუშვათ განვითარების სერვერი თქვენი აპლიკაციისთვის OpenShift პლატფორმაზე და სინქრონიზაცია მოახდინოთ ადგილობრივ ფაილურ სისტემასთან, ასევე ვისაუბროთ იმაზე, თუ რა არის OpenShift Pipelines და როგორ შეიძლება მათი გამოყენება, როგორც ალტერნატივა დაკავშირებული შეკრებებისთვის.

OpenShift, როგორც განვითარების გარემო

განვითარების სამუშაო პროცესი

როგორც უკვე აღინიშნა პირველი პოსტი, თანამედროვე ვებ აპლიკაციების განვითარების ტიპიური პროცესი არის უბრალოდ ერთგვარი „განვითარების სერვერი“, რომელიც აკონტროლებს ადგილობრივ ფაილებში ცვლილებებს. როდესაც ისინი წარმოიქმნება, აპლიკაციის აშენება ამოქმედდება და შემდეგ განახლდება ბრაუზერში.

უმეტეს თანამედროვე ჩარჩოებში, ასეთი "განვითარების სერვერი" ჩაშენებულია ბრძანების ხაზის შესაბამის ინსტრუმენტებში.

ადგილობრივი მაგალითი

ჯერ ვნახოთ, როგორ მუშაობს ეს აპლიკაციების ლოკალურად გაშვებისას. მაგალითი ავიღოთ აპლიკაცია რეაგირებას წინა სტატიებიდან, თუმცა სამუშაო პროცესის თითქმის იგივე კონცეფციები გამოიყენება ყველა სხვა თანამედროვე ჩარჩოში.
ასე რომ, ჩვენს React მაგალითში "dev სერვერის" დასაწყებად, ჩვენ შევიყვანთ შემდეგ ბრძანებას:

$ 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 გარემოს ცვლადი ჩვენს განლაგებას, რომელიც ეუბნება გაშვების დროს გაუშვას ნართის დაწყების ბრძანება, რომელიც იწყებს React განვითარების სერვერს ჩვენს OpenShift პოდში.

თუ გადახედავთ გაშვებული ჯიშის ჟურნალს, ის ასე გამოიყურება:

რა თქმა უნდა, ეს ყველაფერი არაფერი იქნება მანამ, სანამ არ შევძლებთ ლოკალური კოდის სინქრონიზაციას კოდთან, რომელიც ასევე კონტროლდება ცვლილებებისთვის, მაგრამ ცხოვრობს დისტანციურ სერვერზე.

დისტანციური და ადგილობრივი კოდის სინქრონიზაცია

საბედნიეროდ, nodeshift ადვილად დაგეხმარებათ სინქრონიზაციაში და შეგიძლიათ გამოიყენოთ watch ბრძანება ცვლილებების თვალყურის დევნებისთვის.

ასე რომ, მას შემდეგ რაც ჩვენ შევასრულებთ ბრძანებას ჩვენი აპლიკაციისთვის განვითარების სერვერის განსათავსებლად, ჩვენ შეგვიძლია უსაფრთხოდ გამოვიყენოთ შემდეგი ბრძანება:

$ 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

Watch ბრძანება არის აბსტრაქცია oc rsync ბრძანების თავზე, შეგიძლიათ გაიგოთ მეტი მისი მუშაობის შესახებ აქ.

ეს იყო მაგალითი React-ისთვის, მაგრამ ზუსტად იგივე მეთოდის გამოყენება შესაძლებელია სხვა ფრეიმიკებთან, უბრალოდ დააყენეთ NPM_RUN გარემოს ცვლადი საჭიროებისამებრ.

Openshift მილსადენები

შემდეგ ვისაუბრებთ ისეთ ინსტრუმენტზე, როგორიცაა OpenShift Pipelines და როგორ შეიძლება მისი გამოყენება ჯაჭვური კონსტრუქციების ალტერნატივად.

რა არის OpenShift მილსადენები

OpenShift Pipelines არის ღრუბლოვანი CI/CD უწყვეტი ინტეგრაციისა და მიწოდების სისტემა, რომელიც შექმნილია მილსადენების ორგანიზებისთვის Tekton-ის გამოყენებით. Tekton არის მოქნილი ღია კოდის Kubernetes-ის მშობლიური CI/CD ჩარჩო, რომელიც საშუალებას გაძლევთ ავტომატიზირდეთ განლაგება სხვადასხვა პლატფორმებზე (Kubernetes, სერვერების გარეშე, ვირტუალური მანქანები და ა.შ.) ფუძემდებლური ფენიდან აბსტრაქციის გზით.

ამ სტატიის გასაგებად საჭიროა მილსადენების გარკვეული ცოდნა, ამიტომ გირჩევთ, ჯერ წაიკითხოთ ოფიციალური სახელმძღვანელო.

თქვენი სამუშაო გარემოს დაყენება

ამ სტატიაში მოცემული მაგალითებით სათამაშოდ, ჯერ უნდა მოამზადოთ თქვენი სამუშაო გარემო:

დააინსტალირეთ და დააკონფიგურირეთ OpenShift 4 კლასტერი. ჩვენი მაგალითები ამისთვის იყენებს CodeReady Containers (CRD), რომლის ინსტალაციის ინსტრუქციები შეგიძლიათ ნახოთ. აქ.
მას შემდეგ, რაც კლასტერი მზად იქნება, თქვენ უნდა დააინსტალიროთ მასზე მილსადენის ოპერატორი. არ შეგეშინდეთ, ეს მარტივია, ინსტალაციის ინსტრუქციები აქ.
გადმოწერა Tekton CLI (tkn) აქ.
გაუშვით create-react-app ბრძანების ხაზის ხელსაწყო, რომ შექმნათ აპლიკაცია, რომელსაც შემდეგ განათავსებთ (ეს არის მარტივი აპლიკაცია რეაგირებას).
(არასავალდებულო) კლონირეთ საცავი, რომ ნიმუშის აპლიკაცია ადგილობრივად გაუშვათ npm ინსტალაციის და შემდეგ npm გაშვებით.

აპლიკაციის საცავს ასევე ექნება k8s საქაღალდე, რომელიც შეიცავს Kubernetes/OpenShift YAML-ებს, რომლებიც გამოიყენება აპლიკაციის განსათავსებლად. იქნება Tasks, ClusterTasks, რესურსები და მილსადენები, რომლებსაც ჩვენ შევქმნით ამაში საცავები.

Დავიწყოთ

პირველი ნაბიჯი ჩვენი მაგალითისთვის არის ახალი პროექტის შექმნა OpenShift კლასტერში. მოდით ვუწოდოთ ამ პროექტს webapp-pipeline და შევქმნათ იგი შემდეგი ბრძანებით:

$ oc new-project webapp-pipeline

პროექტის სახელი მოგვიანებით გამოჩნდება კოდში, ასე რომ, თუ გადაწყვეტთ მას სხვა სახელი დაარქვათ, არ დაგავიწყდეთ, რომ შეცვალოთ მაგალითის კოდი შესაბამისად. ამ პუნქტიდან დაწყებული, ჩვენ არ გადავალთ ზემოდან ქვევით, არამედ ქვემოდან ზევით: ანუ ჯერ შევქმნით კონვეიერის ყველა კომპონენტს და მხოლოდ ამის შემდეგ თავად კონვეიერს.

ასე რომ, პირველ რიგში...

Დავალებები

მოდით შევქმნათ რამდენიმე დავალება, რომელიც შემდეგ დაეხმარება აპლიკაციის განთავსებას ჩვენს მილსადენში. პირველი ამოცანა - apply_manifests_task - პასუხისმგებელია Kubernetes-ის იმ რესურსების YAML-ის გამოყენებაზე (მომსახურება, განლაგება და მარშრუტი), რომლებიც განთავსებულია ჩვენი აპლიკაციის 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

შენიშვნა: ეს არის ადგილობრივი ამოცანები თქვენი მიმდინარე პროექტისთვის.

კლასტერული ამოცანები

კლასტერული ამოცანები ძირითადად იგივეა, რაც მარტივი ამოცანები. ანუ, ეს არის ნაბიჯების მრავალჯერადი გამოყენება, რომლებიც ამა თუ იმ გზით გაერთიანებულია კონკრეტული ამოცანის შესრულებისას. განსხვავება ისაა, რომ კლასტერული დავალება ხელმისაწვდომია ყველგან კლასტერის შიგნით. კლასტერული ამოცანების სიის სანახავად, რომლებიც ავტომატურად იქმნება 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-ის გამოყენებით. .

საიდან ვიცოდით ეს ყველაფერი, გეკითხებით? დან ოფიციალური 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-ში ის დაშორებულია. ჩვენი პირველი კლასტერული ამოცანის გამომავალი იქნება სურათი, რომელიც შეიცავს ჩვენ მიერ შეგროვებულ 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 გასაღები მიუთითებს კონკრეტულ საცავზე და მიუთითებს მთავარ ფილიალს (ეს არჩევითია, მაგრამ ჩვენ ვწერთ სისრულისთვის).

ახლა ჩვენ უნდა შევქმნათ რესურსი სურათისთვის, სადაც შეინახება 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 Image Registry-ზე, კონკრეტულად მასზე, რომელიც მდებარეობს 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 სახელების სივრცეში.

ყველა ამ რესურსის ერთდროულად შესაქმნელად, ჩვენ ვიყენებთ შექმნის ბრძანებას:

$ 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 რესურსისთვის აირჩიეთ ვებ-აპლიკაცია-რეპო, შემდეგ პირველი გამოსახულების რესურსისთვის, ჩაშენებული ვებ-აპლიკაცია. -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}}'

უფრო დიდი ვიზუალიზაციისთვის, შეგიძლიათ ნახოთ ჩვენი მილსადენი განყოფილებაში ვებ კონსოლის დეველოპერის რეჟიმში მილსადენები, როგორც ნაჩვენებია ნახ. 1.

ნახ.1. გაშვებული მილსადენების მიმოხილვა.

გაშვებულ მილსადენზე დაწკაპუნება აჩვენებს დამატებით დეტალებს, როგორც ეს ნაჩვენებია სურათზე 2.

ბრინჯი. 2. დამატებითი ინფორმაცია მილსადენის შესახებ.

დამატებითი ინფორმაციის შემდეგ, თქვენ შეგიძლიათ ნახოთ გაშვებული აპლიკაციები ხედში ტოპოლოგია, როგორც ნაჩვენებია ნახ.3.

ნახ 3. გაშვებული pod.

ხატის ზედა მარჯვენა კუთხეში წრეზე დაწკაპუნებით იხსნება ჩვენი აპლიკაცია, როგორც ეს ნაჩვენებია 4-ზე.

ბრინჯი. 4. გაშვებული React აპლიკაცია.

დასკვნა

ასე რომ, ჩვენ ვაჩვენეთ, თუ როგორ უნდა გაუშვათ განვითარების სერვერი თქვენი აპლიკაციისთვის OpenShift-ზე და სინქრონიზაცია მოახდინოთ ადგილობრივ ფაილურ სისტემასთან. ჩვენ ასევე განვიხილეთ, თუ როგორ უნდა მოვახდინოთ ჯაჭვური აშენების შაბლონის სიმულაცია OpenShift Pipelines-ის გამოყენებით. ამ სტატიის ყველა მაგალითის კოდი შეგიძლიათ იხილოთ აქ.

დამატებითი რესურსები (EN)

მომავალი ვებინარების ანონსები

ჩვენ ვიწყებთ პარასკევს ვებინარების სერიას მშობლიური გამოცდილების შესახებ Red Hat OpenShift Container Platform-ისა და Kubernetes-ის გამოყენებით:

წყარო: www.habr.com

თანამედროვე აპლიკაციები OpenShift-ზე, ნაწილი 3: OpenShift როგორც განვითარების გარემო და OpenShift Pipelines