Γεια σε όλους! Αυτή είναι η δεύτερη ανάρτηση της σειράς μας στην οποία δείχνουμε πώς να αναπτύξουμε σύγχρονες εφαρμογές Ιστού στο Red Hat OpenShift.
Στην προηγούμενη ανάρτηση, θίξαμε ελαφρώς τις δυνατότητες της νέας εικόνας δημιουργίας S2I (source-to-image), η οποία έχει σχεδιαστεί για τη δημιουργία και την ανάπτυξη σύγχρονων διαδικτυακών εφαρμογών στην πλατφόρμα OpenShift. Τότε μας ενδιέφερε το θέμα της γρήγορης ανάπτυξης μιας εφαρμογής και σήμερα θα εξετάσουμε πώς να χρησιμοποιήσουμε μια εικόνα S2I ως "καθαρή" εικόνα δημιουργίας και να τη συνδυάσουμε με σχετικές συναρμολογήσεις OpenShift.
Καθαρή εικόνα οικοδόμου
Όπως αναφέραμε στο Μέρος XNUMX, οι περισσότερες σύγχρονες εφαρμογές Ιστού έχουν ένα λεγόμενο στάδιο κατασκευής, το οποίο συνήθως εκτελεί λειτουργίες όπως μεταγραφή κώδικα, συνένωση πολλαπλών αρχείων και ελαχιστοποίηση. Τα αρχεία που λαμβάνονται ως αποτέλεσμα αυτών των λειτουργιών - και αυτό είναι στατικό HTML, JavaScript και CSS - αποθηκεύονται στον φάκελο εξόδου. Η θέση αυτού του φακέλου συνήθως εξαρτάται από τα εργαλεία κατασκευής που χρησιμοποιούνται και για το React αυτός θα είναι ο φάκελος ./build (θα επανέλθουμε σε αυτό με περισσότερες λεπτομέρειες παρακάτω).
Πηγή σε εικόνα (S2I)
Σε αυτήν την ανάρτηση δεν θίγουμε το θέμα "τι είναι το S2I και πώς να το χρησιμοποιήσετε" (μπορείτε να διαβάσετε περισσότερα για αυτό ), αλλά είναι σημαντικό να είμαστε σαφείς σχετικά με τα δύο βήματα αυτής της διαδικασίας για να κατανοήσουμε τι κάνει μια εικόνα του Web App Builder.
Φάση συναρμολόγησης
Η φάση συναρμολόγησης είναι πολύ παρόμοια στη φύση με αυτό που συμβαίνει όταν εκτελείτε το docker build και καταλήγετε σε μια νέα εικόνα Docker. Αντίστοιχα, αυτό το στάδιο εμφανίζεται κατά την εκκίνηση μιας έκδοσης στην πλατφόρμα OpenShift.
Στην περίπτωση μιας εικόνας του Web App Builder, είναι υπεύθυνο για την εγκατάσταση των εξαρτήσεων της εφαρμογής σας και την εκτέλεση του build. . Από προεπιλογή, η εικόνα του εργαλείου δημιουργίας χρησιμοποιεί τη δομή κατασκευής εκτέλεσης npm, αλλά αυτό μπορεί να παρακαμφθεί μέσω της μεταβλητής περιβάλλοντος NPM_BUILD.
Όπως είπαμε νωρίτερα, η θέση της τελικής, ήδη κατασκευασμένης εφαρμογής εξαρτάται από τα εργαλεία που χρησιμοποιείτε. Για παράδειγμα, στην περίπτωση του React αυτός θα είναι ο φάκελος ./build και για τις εφαρμογές Angular θα είναι ο φάκελος project_name/dist. Και, όπως φαίνεται ήδη στην προηγούμενη ανάρτηση, η θέση του καταλόγου εξόδου, που έχει ρυθμιστεί να δημιουργείται από προεπιλογή, μπορεί να παρακαμφθεί μέσω της μεταβλητής περιβάλλοντος OUTPUT_DIR. Λοιπόν, δεδομένου ότι η θέση του φακέλου εξόδου διαφέρει από πλαίσιο σε πλαίσιο, μπορείτε απλώς να αντιγράψετε την έξοδο που δημιουργείται στον τυπικό φάκελο της εικόνας, δηλαδή /opt/apt-root/output. Αυτό είναι σημαντικό για την κατανόηση του υπόλοιπου αυτού άρθρου, αλλά προς το παρόν ας δούμε γρήγορα το επόμενο στάδιο - τη φάση εκτέλεσης.
φάση εκτέλεσης
Αυτό το στάδιο λαμβάνει χώρα όταν μια κλήση στο docker εκτέλεση πραγματοποιείται στη νέα εικόνα που δημιουργήθηκε κατά το στάδιο της συναρμολόγησης. Το ίδιο συμβαίνει κατά την ανάπτυξη στην πλατφόρμα OpenShift. Προκαθορισμένο χρήσεις για την εξυπηρέτηση στατικού περιεχομένου που βρίσκεται στον παραπάνω τυπικό κατάλογο εξόδου.
Αυτή η μέθοδος είναι καλή για γρήγορη ανάπτυξη εφαρμογών, αλλά γενικά δεν συνιστάται η προβολή στατικού περιεχομένου με αυτόν τον τρόπο. Λοιπόν, καθώς στην πραγματικότητα εξυπηρετούμε μόνο στατικό περιεχόμενο, δεν χρειαζόμαστε το Node.js να είναι εγκατεστημένο στην εικόνα μας - ένας διακομιστής ιστού αρκεί.
Με άλλα λόγια, κατά τη συναρμολόγηση χρειαζόμαστε ένα πράγμα, όταν εκτελούμε χρειαζόμαστε ένα άλλο. Σε αυτήν την περίπτωση, οι αλυσοδεμένες κατασκευές είναι χρήσιμες.
Αλυσοδεμένες κατασκευές
Για αυτό γράφουν στην τεκμηρίωση του OpenShift:
"Δύο συγκροτήματα μπορούν να συνδεθούν μεταξύ τους, με το ένα να δημιουργεί μια μεταγλωττισμένη οντότητα και το άλλο να φιλοξενεί αυτήν την οντότητα σε μια ξεχωριστή εικόνα που χρησιμοποιείται για την εκτέλεση αυτής της οντότητας."
Με άλλα λόγια, μπορούμε να χρησιμοποιήσουμε την εικόνα του Web App Builder για να εκτελέσουμε την κατασκευή μας και, στη συνέχεια, να χρησιμοποιήσουμε την εικόνα του διακομιστή web, το ίδιο NGINX, για να εξυπηρετήσουμε το περιεχόμενό μας.
Έτσι, μπορούμε να χρησιμοποιήσουμε την εικόνα του Web App Builder ως «καθαρό» builder και ταυτόχρονα να έχουμε μια μικρή εικόνα χρόνου εκτέλεσης.
Τώρα ας το δούμε αυτό με ένα συγκεκριμένο παράδειγμα.
Για προπόνηση θα χρησιμοποιήσουμε , που δημιουργήθηκε χρησιμοποιώντας το εργαλείο γραμμής εντολών create-react-app.
Θα μας βοηθήσει να συνδυάσουμε τα πάντα .
Ας δούμε αυτό το αρχείο με περισσότερες λεπτομέρειες και ξεκινήστε με την ενότητα των παραμέτρων.
parameters:
- name: SOURCE_REPOSITORY_URL
description: The source URL for the application
displayName: Source URL
required: true
- name: SOURCE_REPOSITORY_REF
description: The branch name for the application
displayName: Source Branch
value: master
required: true
- name: SOURCE_REPOSITORY_DIR
description: The location within the source repo of the application
displayName: Source Directory
value: .
required: true
- name: OUTPUT_DIR
description: The location of the compiled static files from your web apps builder
displayName: Output Directory
value: build
required: false
Όλα εδώ είναι αρκετά ξεκάθαρα, αλλά αξίζει να δώσετε προσοχή στην παράμετρο OUTPUT_DIR. Για την εφαρμογή React στο παράδειγμά μας, δεν υπάρχει τίποτα ανησυχητικό, καθώς το React χρησιμοποιεί την προεπιλεγμένη τιμή ως φάκελο εξόδου, αλλά στην περίπτωση του Angular ή κάτι άλλο, αυτή η παράμετρος θα πρέπει να αλλάξει όπως απαιτείται.
Τώρα ας ρίξουμε μια ματιά στην ενότητα ImageStreams.
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-builder // 1
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: react-web-app-runtime // 2
spec: {}
- apiVersion: v1
kind: ImageStream
metadata:
name: web-app-builder-runtime // 3
spec:
tags:
- name: latest
from:
kind: DockerImage
name: nodeshift/ubi8-s2i-web-app:10.x
- apiVersion: v1
kind: ImageStream
metadata:
name: nginx-image-runtime // 4
spec:
tags:
- name: latest
from:
kind: DockerImage
name: 'centos/nginx-112-centos7:latest'
Ρίξτε μια ματιά στην τρίτη και τέταρτη εικόνα. Και οι δύο ορίζονται ως εικόνες Docker και μπορείτε να δείτε καθαρά από πού προέρχονται.
Η τρίτη εικόνα είναι web-app-builder και προέρχεται από το nodeshift/ubi8-s2i-web-app με ετικέτα 10.x στο .
Η τέταρτη είναι μια εικόνα NGINX (έκδοση 1.12) με την πιο πρόσφατη ετικέτα .
Ας δούμε τώρα τις δύο πρώτες εικόνες. Είναι και τα δύο άδεια στην αρχή και δημιουργούνται μόνο κατά τη φάση κατασκευής. Η πρώτη εικόνα, το react-web-app-builder, θα είναι το αποτέλεσμα ενός βήματος συναρμολόγησης που θα συνδυάζει την εικόνα web-app-builder-runtime και τον πηγαίο κώδικα μας. Γι' αυτό προσθέσαμε το "-builder" στο όνομα αυτής της εικόνας.
Η δεύτερη εικόνα - react-web-app-runtime - θα είναι το αποτέλεσμα συνδυασμού nginx-image-runtime και ορισμένων αρχείων από την εικόνα react-web-app-builder. Αυτή η εικόνα θα χρησιμοποιηθεί επίσης κατά την ανάπτυξη και θα περιέχει μόνο τον διακομιστή web και στατικό HTML, JavaScript, CSS της εφαρμογής μας.
Ταραγμένος? Τώρα ας ρίξουμε μια ματιά στις διαμορφώσεις κατασκευής και θα γίνει λίγο πιο ξεκάθαρο.
Το πρότυπό μας έχει δύο διαμορφώσεις κατασκευής. Εδώ είναι το πρώτο και είναι αρκετά τυπικό:
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-builder
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-builder:latest // 1
source: // 2
git:
uri: ${SOURCE_REPOSITORY_URL}
ref: ${SOURCE_REPOSITORY_REF}
contextDir: ${SOURCE_REPOSITORY_DIR}
type: Git
strategy:
sourceStrategy:
env:
- name: OUTPUT_DIR // 3
value: ${OUTPUT_DIR}
from:
kind: ImageStreamTag
name: web-app-builder-runtime:latest // 4
incremental: true // 5
type: Source
triggers: // 6
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- imageChange: {}
type: ImageChange
Όπως μπορείτε να δείτε, η γραμμή με την ετικέτα 1 λέει ότι το αποτέλεσμα αυτής της κατασκευής θα τοποθετηθεί στην ίδια εικόνα react-web-app-builder που είδαμε λίγο νωρίτερα στην ενότητα ImageStreams.
Η γραμμή με την ένδειξη 2 σάς λέει από πού να λάβετε τον κωδικό. Στην περίπτωσή μας, αυτό είναι ένα αποθετήριο git και η θέση, η αναφορά και ο φάκελος περιβάλλοντος καθορίζονται από τις παραμέτρους που είδαμε ήδη παραπάνω.
Η γραμμή με την ένδειξη 3 είναι αυτό που είδαμε ήδη στην ενότητα παραμέτρων. Προσθέτει τη μεταβλητή περιβάλλοντος OUTPUT_DIR, η οποία στο παράδειγμά μας είναι build.
Η γραμμή με την ένδειξη 4 λέει ότι χρησιμοποιείται η εικόνα web-app-builder-runtime, την οποία είδαμε ήδη στην ενότητα ImageStream.
Η γραμμή με την ετικέτα 5 λέει ότι θέλουμε να χρησιμοποιήσουμε μια σταδιακή κατασκευή εάν η εικόνα S2I την υποστηρίζει και η εικόνα του Web App Builder το υποστηρίζει. Στην πρώτη εκκίνηση, αφού ολοκληρωθεί το στάδιο της συναρμολόγησης, η εικόνα θα αποθηκεύσει το φάκελο node_modules σε ένα αρχείο αρχειοθέτησης. Στη συνέχεια, σε επόμενες εκτελέσεις, η εικόνα απλώς θα αποσυμπιέσει αυτόν τον φάκελο για να μειωθεί ο χρόνος δημιουργίας.
Και τέλος, η γραμμή με την ένδειξη 6 είναι μόνο μερικά ερεθίσματα για να εκτελείται η έκδοση αυτόματα, χωρίς χειροκίνητη παρέμβαση, όταν κάτι αλλάζει.
Συνολικά, αυτή είναι μια αρκετά τυπική διαμόρφωση κατασκευής.
Τώρα ας ρίξουμε μια ματιά στη δεύτερη διαμόρφωση κατασκευής. Μοιάζει πολύ με το πρώτο, αλλά υπάρχει μια σημαντική διαφορά.
apiVersion: v1
kind: BuildConfig
metadata:
name: react-web-app-runtime
spec:
output:
to:
kind: ImageStreamTag
name: react-web-app-runtime:latest // 1
source: // 2
type: Image
images:
- from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 3
paths:
- sourcePath: /opt/app-root/output/. // 4
destinationDir: . // 5
strategy: // 6
sourceStrategy:
from:
kind: ImageStreamTag
name: nginx-image-runtime:latest
incremental: true
type: Source
triggers:
- github:
secret: ${GITHUB_WEBHOOK_SECRET}
type: GitHub
- type: ConfigChange
- type: ImageChange
imageChange: {}
- type: ImageChange
imageChange:
from:
kind: ImageStreamTag
name: react-web-app-builder:latest // 7
Έτσι, η δεύτερη διαμόρφωση build είναι react-web-app-runtime και ξεκινά αρκετά τυπικά.
Η γραμμή με την ένδειξη 1 δεν είναι κάτι καινούργιο - λέει απλώς ότι το αποτέλεσμα κατασκευής τοποθετείται στην εικόνα react-web-app-runtime.
Η γραμμή με την ένδειξη 2, όπως και στην προηγούμενη διαμόρφωση, υποδεικνύει από πού να λάβετε τον πηγαίο κώδικα. Προσέξτε όμως ότι εδώ λέμε ότι είναι βγαλμένο από την εικόνα. Επιπλέον, από την εικόνα που μόλις δημιουργήσαμε - από το react-web-app-builder (που υποδεικνύεται στη γραμμή με την ένδειξη 3). Τα αρχεία που θέλουμε να χρησιμοποιήσουμε βρίσκονται μέσα στην εικόνα και η θέση τους εκεί έχει οριστεί στη γραμμή με την ένδειξη 4, στην περίπτωσή μας είναι /opt/app-root/output/. Αν θυμάστε, εδώ αποθηκεύονται τα αρχεία που δημιουργούνται με βάση τα αποτελέσματα της δημιουργίας της εφαρμογής μας.
Ο φάκελος προορισμού που καθορίζεται στον όρο με την ετικέτα 5 είναι απλώς ο τρέχων κατάλογος (αυτό, θυμηθείτε, τρέχει μέσα σε κάποιο μαγικό πράγμα που ονομάζεται OpenShift, και όχι στον τοπικό σας υπολογιστή).
Η ενότητα στρατηγικής - γραμμή με την ένδειξη 6 - είναι επίσης παρόμοια με την πρώτη διαμόρφωση κατασκευής. Μόνο που αυτή τη φορά θα χρησιμοποιήσουμε το nginx-image-runtime, το οποίο είδαμε ήδη στην ενότητα ImageStream.
Τέλος, η γραμμή με την ένδειξη 7 είναι ένα τμήμα καναλιών που θα ενεργοποιούν αυτήν την έκδοση κάθε φορά που αλλάζει η εικόνα του react-web-app-builder.
Διαφορετικά, αυτό το πρότυπο περιέχει αρκετά τυπικές ρυθμίσεις παραμέτρων ανάπτυξης, καθώς και πράγματα που σχετίζονται με υπηρεσίες και διαδρομές, αλλά δεν θα υπεισέλθουμε σε τόσες πολλές λεπτομέρειες. Λάβετε υπόψη ότι η εικόνα που θα αναπτυχθεί είναι η εικόνα react-web-app-runtime.
Ανάπτυξη Εφαρμογής
Τώρα λοιπόν που εξετάσαμε το πρότυπο, ας δούμε πώς να το χρησιμοποιήσετε για την ανάπτυξη μιας εφαρμογής.
Μπορούμε να χρησιμοποιήσουμε το εργαλείο πελάτη OpenShift που ονομάζεται oc για να αναπτύξουμε το πρότυπό μας:
$ find . | grep openshiftio | grep application | xargs -n 1 oc apply -f
$ oc new-app --template react-web-app -p SOURCE_REPOSITORY_URL=https://github.com/lholmquist/react-web-app
Η πρώτη εντολή στο παραπάνω στιγμιότυπο οθόνης είναι ένας σκόπιμα μηχανικός τρόπος για να βρείτε ένα πρότυπο./openshiftio/application.yaml.
Η δεύτερη εντολή δημιουργεί απλώς μια νέα εφαρμογή που βασίζεται σε αυτό το πρότυπο.
Αφού λειτουργήσουν αυτές οι εντολές, θα δούμε ότι έχουμε δύο συγκροτήματα:
Και επιστρέφοντας στην οθόνη Επισκόπηση, θα δούμε το εκκινημένο pod:
Κάντε κλικ στον σύνδεσμο και θα μεταφερθούμε στην εφαρμογή μας, η οποία είναι η προεπιλεγμένη σελίδα της εφαρμογής React:
Συμπλήρωμα 1
Για τους λάτρεις της Angular έχουμε επίσης .
Το μοτίβο εδώ είναι το ίδιο, εκτός από τη μεταβλητή OUTPUT_DIR.
Συμπλήρωμα 2
Σε αυτό το άρθρο χρησιμοποιήσαμε το NGINX ως διακομιστή ιστού, αλλά είναι αρκετά εύκολο να το αντικαταστήσουμε με Apache, απλά αλλάξτε το πρότυπο στο αρχείο επί .
Συμπέρασμα
Στο πρώτο μέρος αυτής της σειράς, δείξαμε πώς να αναπτύξετε γρήγορα σύγχρονες εφαρμογές Ιστού στην πλατφόρμα OpenShift. Σήμερα εξετάσαμε τι κάνει μια εικόνα εφαρμογής Ιστού και πώς μπορεί να συνδυαστεί με έναν καθαρό διακομιστή ιστού όπως ο NGINX χρησιμοποιώντας αλυσιδωτές κατασκευές για να δημιουργήσουμε μια πιο έτοιμη έκδοση εφαρμογής. Στο επόμενο και τελευταίο άρθρο αυτής της σειράς, θα δείξουμε πώς να εκτελείτε έναν διακομιστή ανάπτυξης για την εφαρμογή σας στο OpenShift και να διασφαλίσετε τον συγχρονισμό τοπικών και απομακρυσμένων αρχείων.
Περιεχόμενα αυτής της σειράς άρθρων
- Μέρος 1: ;
- Μέρος 2: Πώς να χρησιμοποιήσετε μια νέα εικόνα S2I με μια υπάρχουσα εικόνα διακομιστή HTTP, όπως το NGINX, χρησιμοποιώντας συσχετισμένες συγκροτήσεις OpenShift για ανάπτυξη παραγωγής.
- Μέρος 3: πώς να εκτελέσετε έναν διακομιστή ανάπτυξης για την εφαρμογή σας στην πλατφόρμα OpenShift και να τον συγχρονίσετε με το τοπικό σύστημα αρχείων.
Επιπρόσθετοι πόροι
- Δωρεάν ηλεκτρονικό βιβλίο .
- Πληροφορίες για .
Πηγή: www.habr.com