Γεια σε όλους σε αυτό το blog! Αυτή είναι η τρίτη ανάρτηση μιας σειράς στην οποία δείχνουμε πώς να αναπτύξουμε σύγχρονες εφαρμογές Ιστού στο Red Hat OpenShift.
Στις δύο προηγούμενες αναρτήσεις, δείξαμε πώς να αναπτύξετε σύγχρονες εφαρμογές Ιστού σε λίγα μόλις βήματα και πώς να χρησιμοποιήσετε μια νέα εικόνα S2I μαζί με μια εικόνα διακομιστή HTTP εκτός ράφι, όπως το NGINX, χρησιμοποιώντας αλυσιδωμένες κατασκευές για να ενορχηστρώσει αναπτύξεις παραγωγής .
Σήμερα θα δείξουμε πώς να εκτελείτε έναν διακομιστή ανάπτυξης για την εφαρμογή σας στην πλατφόρμα OpenShift και να τον συγχρονίσετε με το τοπικό σύστημα αρχείων, και επίσης θα μιλήσουμε για το τι είναι οι OpenShift Pipelines και πώς μπορούν να χρησιμοποιηθούν ως εναλλακτική λύση σε συνδεδεμένες συγκροτήσεις.
Το OpenShift ως περιβάλλον ανάπτυξης
Ροή εργασιών ανάπτυξης
Όπως ήδη αναφέρθηκε στο , η τυπική διαδικασία ανάπτυξης για σύγχρονες εφαρμογές Ιστού είναι απλώς κάποιο είδος «διακομιστή ανάπτυξης» που παρακολουθεί τις αλλαγές σε τοπικά αρχεία. Όταν εμφανιστούν, ενεργοποιείται η κατασκευή της εφαρμογής και στη συνέχεια ενημερώνεται στο πρόγραμμα περιήγησης.
Στα περισσότερα σύγχρονα πλαίσια, ένας τέτοιος «διακομιστής ανάπτυξης» είναι ενσωματωμένος στα αντίστοιχα εργαλεία γραμμής εντολών.
Τοπικό παράδειγμα
Αρχικά, ας δούμε πώς λειτουργεί αυτό κατά την εκτέλεση εφαρμογών τοπικά. Ας πάρουμε την εφαρμογή ως παράδειγμα από προηγούμενα άρθρα, αν και ισχύουν σχεδόν οι ίδιες έννοιες ροής εργασιών σε όλα τα άλλα σύγχρονα πλαίσια.
Έτσι, για να ξεκινήσουμε τον "διακομιστή dev" στο παράδειγμα του React, θα εισαγάγουμε την ακόλουθη εντολή:
$ npm run start
Στη συνέχεια, στο παράθυρο τερματικού θα δούμε κάτι σαν αυτό:
Και η εφαρμογή μας θα ανοίξει στο προεπιλεγμένο πρόγραμμα περιήγησης:
Τώρα, εάν κάνουμε αλλαγές στο αρχείο, η εφαρμογή θα πρέπει να ενημερώνεται στο πρόγραμμα περιήγησης.
Εντάξει, όλα είναι ξεκάθαρα με την ανάπτυξη σε τοπική λειτουργία, αλλά πώς να πετύχετε το ίδιο στο OpenShift;
Διακομιστής ανάπτυξης στο OpenShift
Αν θυμάστε, σε , εξετάσαμε τη λεγόμενη φάση εκτέλεσης της εικόνας S2I και είδαμε ότι από προεπιλογή, η μονάδα εξυπηρέτησης είναι υπεύθυνη για την εξυπηρέτηση της εφαρμογής web μας.
Ωστόσο, αν ρίξετε μια πιο προσεκτική ματιά από αυτό το παράδειγμα, περιέχει τη μεταβλητή περιβάλλοντος $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 και πώς μπορεί να χρησιμοποιηθεί ως εναλλακτική λύση στις αλυσοδεμένες κατασκευές.
Τι είναι το OpenShift Pipelines
Το OpenShift Pipelines είναι ένα σύστημα συνεχούς ολοκλήρωσης και παράδοσης CI/CD εγγενές στο cloud, σχεδιασμένο για την οργάνωση αγωγών χρησιμοποιώντας το Tekton. Το Tekton είναι ένα ευέλικτο πλαίσιο CI/CD εγγενούς Kubernetes ανοιχτού κώδικα που σας επιτρέπει να αυτοματοποιείτε την ανάπτυξη σε διάφορες πλατφόρμες (Kubernetes, χωρίς διακομιστή, εικονικές μηχανές κ.λπ.) αφαιρώντας από το υποκείμενο επίπεδο.
Η κατανόηση αυτού του άρθρου απαιτεί κάποια γνώση των Pipelines, γι' αυτό σας συνιστούμε να διαβάσετε πρώτα .
Ρύθμιση του εργασιακού σας περιβάλλοντος
Για να παίξετε με τα παραδείγματα σε αυτό το άρθρο, πρέπει πρώτα να προετοιμάσετε το περιβάλλον εργασίας σας:
- Εγκαταστήστε και διαμορφώστε ένα σύμπλεγμα OpenShift 4. Τα παραδείγματά μας χρησιμοποιούν CodeReady Containers (CRD) για αυτό, οδηγίες εγκατάστασης για το οποίο μπορείτε να βρείτε .
- Αφού το σύμπλεγμα είναι έτοιμο, πρέπει να εγκαταστήσετε το Pipeline Operator σε αυτό. Μην φοβάστε, είναι εύκολο, οδηγίες εγκατάστασης .
- Λήψη (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 – είναι υπεύθυνη για την ενημέρωση μιας ήδη αναπτυγμένης εικόνας σε αυτήν που δημιουργήθηκε από το pipeline μας.
Μην ανησυχείτε αν δεν είναι ακόμα πολύ ξεκάθαρο. Στην πραγματικότητα, αυτές οι εργασίες είναι κάτι σαν βοηθητικά προγράμματα και θα τις δούμε λεπτομερέστερα λίγο αργότερα. Προς το παρόν, ας τα δημιουργήσουμε:
$ 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, θα χρησιμοποιήσουμε ξανά την εντολή 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: 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 στην ενότητα παραμέτρων οδηγεί σε ένα συγκεκριμένο αποθετήριο και καθορίζει τον κύριο κλάδο (αυτό είναι προαιρετικό, αλλά το γράφουμε για πληρότητα).
Τώρα πρέπει να δημιουργήσουμε έναν πόρο για την εικόνα όπου θα αποθηκευτούν τα αποτελέσματα της εργασίας 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, συγκεκριμένα σε αυτό που βρίσκεται στον χώρο ονομάτων της εφαρμογής web-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.
Για να δημιουργήσουμε όλους αυτούς τους πόρους ταυτόχρονα, χρησιμοποιούμε την εντολή δημιουργία:
$ 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
Όπως και με την προηγούμενη εργασία, περνάμε σε έναν πόρο, αλλά τώρα είναι ενσωματωμένος web-application-image (η έξοδος της προηγούμενης εργασίας μας). Και ως έξοδο ορίσαμε ξανά την εικόνα. Δεδομένου ότι αυτή η εργασία πρέπει να εκτελεστεί μετά την προηγούμενη, προσθέτουμε το πεδίο 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 -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. Εκτοξεύτηκε λοβό.
Κάνοντας κλικ στον κύκλο στην επάνω δεξιά γωνία του εικονιδίου ανοίγει η εφαρμογή μας, όπως φαίνεται στην Εικ. 4.
Ρύζι. 4. Εκτέλεση της εφαρμογής React.
Συμπέρασμα
Έτσι, δείξαμε πώς να εκτελέσετε έναν διακομιστή ανάπτυξης για την εφαρμογή σας στο OpenShift και να τον συγχρονίσετε με το τοπικό σύστημα αρχείων. Εξετάσαμε επίσης τον τρόπο προσομοίωσης ενός προτύπου chained-build χρησιμοποιώντας OpenShift Pipelines. Μπορείτε να βρείτε όλα τα παραδείγματα κωδικών από αυτό το άρθρο .
Πρόσθετοι πόροι (EN)
- Δωρεάν ηλεκτρονικό βιβλίο
- Άλλα άρθρα σχετικά με στον ιστότοπο της Red Hat
Ανακοινώσεις προσεχών διαδικτυακών σεμιναρίων
Ξεκινάμε μια σειρά διαδικτυακών σεμιναρίων της Παρασκευής σχετικά με την εγγενή εμπειρία χρησιμοποιώντας το Red Hat OpenShift Container Platform και το Kubernetes:
Πηγή: www.habr.com