Σημείωση. μετάφραση: Αυτή η περιήγηση από την Weaveworks παρουσιάζει τις πιο δημοφιλείς στρατηγικές διάθεσης εφαρμογών και πώς μπορείτε να εφαρμόσετε τις πιο προηγμένες με τον τελεστή Flagger Kubernetes. Είναι γραμμένο σε απλή γλώσσα και περιέχει οπτικά διαγράμματα που επιτρέπουν ακόμη και σε αρχάριους μηχανικούς να κατανοήσουν το ζήτημα.
Διάγραμμα λαμβάνεται από στρατηγικές διάθεσης που έγιναν στο Container Solutions
Μία από τις μεγαλύτερες προκλήσεις στην ανάπτυξη εγγενών εφαρμογών cloud σήμερα είναι η ταχύτητα ανάπτυξης. Με μια προσέγγιση microservice, οι προγραμματιστές εργάζονται ήδη και σχεδιάζουν πλήρως αρθρωτές εφαρμογές, επιτρέποντας σε διαφορετικές ομάδες να γράφουν κώδικα και να κάνουν αλλαγές στην εφαρμογή ταυτόχρονα.
Οι συντομότερες και πιο συχνές αναπτύξεις έχουν τα ακόλουθα πλεονεκτήματα:
- Μειωμένος χρόνος για την αγορά.
- Οι νέες λειτουργίες φτάνουν στους χρήστες πιο γρήγορα.
- Τα σχόλια των χρηστών φτάνουν στην ομάδα ανάπτυξης πιο γρήγορα. Αυτό σημαίνει ότι η ομάδα μπορεί να προσθέσει λειτουργίες και να διορθώσει προβλήματα πιο γρήγορα.
- Το ηθικό των προγραμματιστών αυξάνεται: η εργασία με περισσότερες δυνατότητες στην ανάπτυξη είναι πιο διασκεδαστική.
Αλλά καθώς αυξάνεται η συχνότητα των εκδόσεων, αυξάνονται και οι πιθανότητες να επηρεαστεί αρνητικά η αξιοπιστία της εφαρμογής ή η εμπειρία χρήστη. Αυτός είναι ο λόγος για τον οποίο είναι σημαντικό για τις επιχειρήσεις και τις ομάδες DevOps να δημιουργούν διαδικασίες και να διαχειρίζονται στρατηγικές ανάπτυξης με τρόπο που ελαχιστοποιεί τον κίνδυνο για το προϊόν και τους χρήστες. (Για να μάθετε περισσότερα σχετικά με την αυτοματοποίηση του αγωγού CI/CD, βλ .)
Σε αυτήν την ανάρτηση, θα συζητήσουμε διάφορες στρατηγικές ανάπτυξης Kubernetes, συμπεριλαμβανομένων κυλιόμενων αναπτύξεων και πιο προηγμένων μεθόδων, όπως η διάθεση καναρινιών και οι παραλλαγές τους.
Στρατηγικές ανάπτυξης
Υπάρχουν διάφοροι τύποι στρατηγικών ανάπτυξης που μπορούν να χρησιμοποιηθούν ανάλογα με τον σκοπό. Για παράδειγμα, μπορεί να χρειαστεί να κάνετε αλλαγές σε κάποιο περιβάλλον για περαιτέρω δοκιμή ή σε ένα υποσύνολο χρηστών/πελατών ή μπορεί να χρειαστεί να κάνετε περιορισμένες δοκιμές στους χρήστες πριν δημιουργήσετε μια λειτουργία δημόσιο.
Κυλιόμενο (σταδιακή, κυλιόμενη ανάπτυξη)
Αυτή είναι η τυπική στρατηγική ανάπτυξης για το Kubernetes. Σταδιακά, ένα προς ένα, αντικαθιστά τα pods με την παλιά έκδοση της εφαρμογής με pods με τη νέα έκδοση - χωρίς χρόνο διακοπής λειτουργίας του cluster.
Το Kubernetes περιμένει να είναι έτοιμα τα νέα pods (ελέγχοντάς τα με ) πριν προχωρήσετε στο τύλιγμα των παλιών. Εάν παρουσιαστεί πρόβλημα, μια τέτοια κυλιόμενη ενημέρωση μπορεί να ματαιωθεί χωρίς να σταματήσει ολόκληρο το σύμπλεγμα. Στο αρχείο τύπου ανάπτυξης YAML, η νέα εικόνα αντικαθιστά την παλιά εικόνα:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Οι παράμετροι της ενημερωμένης έκδοσης μπορούν να καθοριστούν στο αρχείο δήλωσης:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Αναδημιουργία (επαναδημιουργία)
Σε αυτόν τον απλούστερο τύπο ανάπτυξης, τα παλιά λοβοί σκοτώνονται ταυτόχρονα και αντικαθίστανται με νέα:
Το αντίστοιχο μανιφέστο μοιάζει κάπως έτσι:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Μπλε/Πράσινο (μπλε-πράσινες αναπτύξεις)
Η μπλε-πράσινη στρατηγική ανάπτυξης (μερικές φορές αναφέρεται και ως κόκκινο / μαύρο, δηλαδή κόκκινο-μαύρο) περιλαμβάνει την ταυτόχρονη ανάπτυξη της παλιάς (πράσινης) και της νέας (μπλε) έκδοσης της εφαρμογής. Μόλις φιλοξενηθούν και οι δύο εκδόσεις, η πράσινη είναι διαθέσιμη στον γενικό χρήστη, ενώ η μπλε είναι διαθέσιμη για την ομάδα QA για αυτοματοποίηση των δοκιμών μέσω μιας ξεχωριστής υπηρεσίας ή απευθείας προώθησης θύρας:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Αφού ελεγχθεί και εγκριθεί για κυκλοφορία η μπλε (νέα) έκδοση, η υπηρεσία αλλάζει σε αυτήν και η πράσινη (παλιά) ελαχιστοποιείται:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Κανάρια (αναπτύξεις καναρινιών)
Τα καναρίνια είναι παρόμοια με τα μπλε-πράσινα, αλλά καλύτερα ελεγχόμενα και χρησιμοποιημένα βήμα προς βήμα προσέγγιση. Πολλές διαφορετικές στρατηγικές εμπίπτουν σε αυτήν την κατηγορία, συμπεριλαμβανομένων των κρυφών εκτοξεύσεων και των δοκιμών A/B.
Αυτή η στρατηγική χρησιμοποιείται όταν χρειάζεται να δοκιμαστεί κάποια νέα λειτουργικότητα, συνήθως στο backend της εφαρμογής. Η ουσία της προσέγγισης είναι να δημιουργηθούν δύο σχεδόν πανομοιότυποι διακομιστές: ο ένας εξυπηρετεί σχεδόν όλους τους χρήστες και ο άλλος, με νέες δυνατότητες, εξυπηρετεί μόνο μια μικρή υποομάδα χρηστών, μετά την οποία συγκρίνονται τα αποτελέσματα της εργασίας τους. Εάν όλα πάνε χωρίς σφάλματα, η νέα έκδοση διατίθεται σταδιακά σε ολόκληρη την υποδομή.
Αν και αυτή η στρατηγική μπορεί να εφαρμοστεί αποκλειστικά με τη χρήση του Kubernetes, αντικαθιστώντας τα παλιά pods με νέα, είναι πολύ πιο βολικό και πιο εύκολο να χρησιμοποιήσετε ένα πλέγμα υπηρεσιών όπως το Istio.
Για παράδειγμα, μπορεί να έχετε δύο διαφορετικές εκδηλώσεις Git: ένα κανονικό με ετικέτα 0.1.0 και ένα καναρίνι με ετικέτα 0.2.0. Αλλάζοντας τα βάρη στο μανιφέστο Istio Virtual Gateway, μπορείτε να ελέγξετε την κατανομή της κυκλοφορίας μεταξύ αυτών των δύο αναπτύξεων:
Μπορείτε να βρείτε έναν βήμα προς βήμα οδηγό για την εφαρμογή καναρινιών με το Istio . (Σημείωση. μετάφρ.: Μεταφράσαμε επίσης υλικό για την κυκλοφορία καναρινιών στο Ίστιο .)
Αναπτύξεις Canary με το Weaveworks Flagger
επιτρέπει τον εύκολο και αποτελεσματικό έλεγχο των καναρινιών.
Το Flagger αυτοματοποιεί την εργασία μαζί τους. Χρησιμοποιεί Istio ή AWS App Mesh για τη δρομολόγηση και εναλλαγή της κυκλοφορίας και μετρήσεις Prometheus για την ανάλυση των αποτελεσμάτων. Επιπλέον, η ανάλυση των αναπτύξεων καναρινιών μπορεί να συμπληρωθεί με webhooks για τη διεξαγωγή δοκιμών αποδοχής, δοκιμών φορτίου και οποιουδήποτε άλλου είδους ελέγχων.
Με βάση την ανάπτυξη του Kubernetes και, εάν είναι απαραίτητο, των pods κλιμάκωσης (HPA), το Flagger δημιουργεί σύνολα αντικειμένων (αναπτύξεις Kubernetes, υπηρεσίες ClusterIP και εικονικές υπηρεσίες Istio ή App Mesh) για να αναλύσει και να εφαρμόσει αναπτύξεις καναρινιών:
Εφαρμογή βρόχου ελέγχου (βρόχος ελέγχου)Το Flagger αλλάζει σταδιακά την επισκεψιμότητα στον διακομιστή καναρίνι ενώ μετράει βασικές μετρήσεις απόδοσης, όπως το ποσοστό επιτυχίας αιτημάτων HTTP, τη μέση διάρκεια αιτήματος και την υγεία του pod. Με βάση την ανάλυση των KPI (Key Performance Indicators), το τμήμα καναρίνι είτε μεγαλώνει είτε συρρικνώνεται και τα αποτελέσματα της ανάλυσης δημοσιεύονται στο Slack. Μια περιγραφή και επίδειξη αυτής της διαδικασίας μπορεί να βρεθεί στο υλικό .
Σκοτεινές (κρυφές) ή A/B αναπτύξεις
Η ανάπτυξη Stealth είναι μια άλλη παραλλαγή της στρατηγικής των καναρινιών (με την οποία, παρεμπιπτόντως, ο Flagger μπορεί επίσης να συνεργαστεί). Η διαφορά μεταξύ των αναπτύξεων stealth και των καναρινιών είναι ότι οι αναπτύξεις stealth αφορούν το μπροστινό μέρος και όχι το backend όπως οι αναπτύξεις καναρινιών.
Ένα άλλο όνομα για αυτές τις αναπτύξεις είναι A/B testing. Αντί να ανοίγει η πρόσβαση σε μια νέα δυνατότητα σε όλους τους χρήστες, προσφέρεται μόνο σε ένα περιορισμένο μέρος αυτών. Συνήθως, αυτοί οι χρήστες δεν γνωρίζουν ότι είναι πρωτοπόροι δοκιμαστές (εξ ου και ο όρος "αθόρυβη ανάπτυξη").
Με διακόπτες λειτουργίας (εναλλαγές λειτουργίας) και άλλα εργαλεία, μπορείτε να παρακολουθείτε τον τρόπο με τον οποίο οι χρήστες αλληλεπιδρούν με μια νέα λειτουργία, αν είναι εθισμένοι σε αυτήν ή βρίσκουν σύγχυση στη νέα διεπαφή χρήστη και άλλους τύπους μετρήσεων.
Αναπτύξεις Flagger και A/B
Εκτός από τη σταθμισμένη δρομολόγηση, το Flagger μπορεί επίσης να δρομολογήσει την κυκλοφορία στον διακομιστή καναρίνι με βάση τις παραμέτρους HTTP. Η δοκιμή A/B μπορεί να χρησιμοποιήσει κεφαλίδες ή cookie HTTP για να ανακατευθύνει ένα συγκεκριμένο τμήμα χρηστών. Αυτό είναι ιδιαίτερα αποτελεσματικό στην περίπτωση εφαρμογών διεπαφής που απαιτούν τη σύνδεση της συνεδρίας στον διακομιστή. (συγγένεια συνεδρίας). Περισσότερες πληροφορίες μπορείτε να βρείτε στην τεκμηρίωση του Flagger.
Ο συγγραφέας είναι ευγνώμων , μηχανικός της Weaveworks (και δημιουργός του Flagger), για όλα αυτά τα καταπληκτικά σχέδια ανάπτυξης.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «"?
- «».
Πηγή: www.habr.com