Εμείς στην True Engineering έχουμε δημιουργήσει μια διαδικασία για συνεχή παράδοση ενημερώσεων στους διακομιστές πελατών και θέλουμε να μοιραστούμε αυτήν την εμπειρία.
Αρχικά, αναπτύξαμε ένα διαδικτυακό σύστημα για τον πελάτη και το αναπτύξαμε στο δικό μας σύμπλεγμα Kubernetes. Τώρα η λύση υψηλού φορτίου μας έχει μεταφερθεί στην πλατφόρμα του πελάτη, για την οποία έχουμε δημιουργήσει μια πλήρως αυτόματη διαδικασία συνεχούς ανάπτυξης. Χάρη σε αυτό, επιταχύναμε το χρόνο για την αγορά - την παράδοση αλλαγών στο περιβάλλον του προϊόντος.
Σε αυτό το άρθρο θα μιλήσουμε για όλα τα στάδια της διαδικασίας συνεχούς ανάπτυξης (CD) ή της παράδοσης ενημερώσεων στην πλατφόρμα του πελάτη:
- Πώς ξεκινά αυτή η διαδικασία;
- συγχρονισμός με το αποθετήριο Git του πελάτη,
- συναρμολόγηση του backend και του frontend,
- αυτόματη ανάπτυξη εφαρμογών σε δοκιμαστικό περιβάλλον,
- αυτόματη ανάπτυξη στο Prod.
Θα μοιραστούμε τις λεπτομέρειες ρύθμισης στην πορεία.
1. Ξεκινήστε το CD
Η συνεχής ανάπτυξη ξεκινά με τον προγραμματιστή να προωθεί αλλαγές στον κλάδο έκδοσης του αποθετηρίου Git.
Η εφαρμογή μας εκτελείται σε αρχιτεκτονική microservice και όλα τα στοιχεία της αποθηκεύονται σε ένα αποθετήριο. Χάρη σε αυτό, συλλέγονται και εγκαθίστανται όλες οι μικροϋπηρεσίες, ακόμα κι αν έχει αλλάξει μία από αυτές.
Οργανώσαμε την εργασία μέσω ενός αποθετηρίου για διάφορους λόγους:
- Ευκολία ανάπτυξης - η εφαρμογή αναπτύσσεται ενεργά, ώστε να μπορείτε να εργαστείτε με όλο τον κώδικα ταυτόχρονα.
- Ένας ενιαίος αγωγός CI/CD που εγγυάται ότι η εφαρμογή ως ενιαίο σύστημα περνάει όλες τις δοκιμές και παραδίδεται στο περιβάλλον παραγωγής του πελάτη.
- Εξαλείφουμε τη σύγχυση στις εκδόσεις - δεν χρειάζεται να αποθηκεύσουμε έναν χάρτη των εκδόσεων microservice και να περιγράψουμε τη διαμόρφωσή του για κάθε microservice σε σενάρια Helm.
2. Συγχρονισμός με το αποθετήριο Git του πηγαίου κώδικα του πελάτη
Οι αλλαγές που γίνονται συγχρονίζονται αυτόματα με το αποθετήριο Git του πελάτη. Εκεί διαμορφώνεται η διάταξη της εφαρμογής, η οποία εκκινείται μετά την ενημέρωση του κλάδου και την ανάπτυξη στη συνέχεια. Και οι δύο διαδικασίες προέρχονται από το περιβάλλον τους από ένα αποθετήριο Git.
Δεν μπορούμε να συνεργαστούμε απευθείας με το αποθετήριο του πελάτη γιατί χρειαζόμαστε τα δικά μας περιβάλλοντα για ανάπτυξη και δοκιμή. Χρησιμοποιούμε το αποθετήριο Git για αυτούς τους σκοπούς - είναι συγχρονισμένο με το αποθετήριο Git τους. Μόλις ένας προγραμματιστής δημοσιεύει αλλαγές στον κατάλληλο κλάδο του αποθετηρίου μας, το GitLab προωθεί αμέσως αυτές τις αλλαγές στον πελάτη.
Μετά από αυτό πρέπει να κάνετε τη συναρμολόγηση. Αποτελείται από διάφορα στάδια: συναρμολόγηση backend και frontend, δοκιμή και παράδοση στην παραγωγή.
3. Συναρμολόγηση του backend και του frontend
Η δημιουργία του backend και του frontend είναι δύο παράλληλες εργασίες που εκτελούνται στο σύστημα GitLab Runner. Η αρχική του διαμόρφωση συναρμολόγησης βρίσκεται στο ίδιο αποθετήριο.
.
Το GitLab Runner παίρνει τον κώδικα από το απαιτούμενο αποθετήριο, τον συναρμολογεί με την εντολή δημιουργίας εφαρμογής Java και τον στέλνει στο μητρώο Docker. Εδώ συναρμολογούμε το backend και το frontend, λαμβάνουμε εικόνες Docker, τις οποίες τοποθετούμε σε ένα αποθετήριο στην πλευρά του πελάτη. Για τη διαχείριση εικόνων Docker χρησιμοποιούμε .
Συγχρονίζουμε τις εκδόσεις των εικόνων μας με την έκδοση που θα δημοσιευτεί στο Docker. Για ομαλή λειτουργία έχουμε κάνει αρκετές ρυθμίσεις:
1. Τα δοχεία δεν ανακατασκευάζονται μεταξύ του περιβάλλοντος δοκιμής και του περιβάλλοντος παραγωγής. Κάναμε παραμετροποιήσεις ώστε το ίδιο κοντέινερ να μπορεί να λειτουργεί με όλες τις ρυθμίσεις, τις μεταβλητές περιβάλλοντος και τις υπηρεσίες τόσο στο περιβάλλον δοκιμής όσο και στην παραγωγή χωρίς ανακατασκευή.
2. Για να ενημερώσετε μια εφαρμογή μέσω Helm, πρέπει να καθορίσετε την έκδοσή της. Δημιουργούμε το backend, το frontend και ενημερώνουμε την εφαρμογή - αυτές είναι τρεις διαφορετικές εργασίες, επομένως είναι σημαντικό να χρησιμοποιείτε την ίδια έκδοση της εφαρμογής παντού. Για αυτήν την εργασία, χρησιμοποιούμε δεδομένα από το ιστορικό Git, καθώς η διαμόρφωση του συμπλέγματος K8S και οι εφαρμογές μας βρίσκονται στο ίδιο αποθετήριο Git.
Λαμβάνουμε την έκδοση της εφαρμογής από τα αποτελέσματα εκτέλεσης εντολών
git describe --tags --abbrev=7.
4. Αυτόματη ανάπτυξη όλων των αλλαγών στο περιβάλλον δοκιμής (UAT)
Το επόμενο βήμα σε αυτό το σενάριο έκδοσης είναι η αυτόματη ενημέρωση του συμπλέγματος K8S. Αυτό συμβαίνει με την προϋπόθεση ότι ολόκληρη η εφαρμογή έχει κατασκευαστεί και όλα τα τεχνουργήματα έχουν δημοσιευτεί στο Μητρώο Docker. Μετά από αυτό, ξεκινά η ενημέρωση περιβάλλοντος δοκιμής.
Ξεκινά η χρήση της ενημέρωσης συμπλέγματος . Εάν, ως αποτέλεσμα, κάτι δεν πήγε σύμφωνα με το σχέδιο, η Helm θα επαναφέρει αυτόματα και ανεξάρτητα όλες τις αλλαγές της. Η δουλειά του δεν χρειάζεται να ελέγχεται.
Παρέχουμε τη διαμόρφωση του συμπλέγματος K8S μαζί με τη συναρμολόγηση. Επομένως, το επόμενο βήμα είναι να το ενημερώσετε: configMaps, αναπτύξεις, υπηρεσίες, μυστικά και οποιεσδήποτε άλλες διαμορφώσεις K8S έχουμε αλλάξει.
Στη συνέχεια, η Helm εκτελεί μια ενημέρωση RollOut της ίδιας της εφαρμογής στο περιβάλλον δοκιμής. Πριν από την ανάπτυξη της εφαρμογής στην παραγωγή. Αυτό γίνεται έτσι ώστε οι χρήστες να μπορούν να δοκιμάσουν με μη αυτόματο τρόπο τις επιχειρηματικές δυνατότητες που εισάγουμε στο περιβάλλον δοκιμής.
5. Αυτόματη ανάπτυξη όλων των αλλαγών στο Prod
Για να αναπτύξετε μια ενημέρωση στο περιβάλλον παραγωγής, πρέπει απλώς να κάνετε κλικ σε ένα κουμπί στο GitLab - και τα κοντέινερ παραδίδονται αμέσως στο περιβάλλον παραγωγής.
Η ίδια εφαρμογή μπορεί να λειτουργήσει σε διαφορετικά περιβάλλοντα - δοκιμή και παραγωγή - χωρίς ανακατασκευή. Χρησιμοποιούμε τα ίδια τεχνουργήματα χωρίς να αλλάξουμε τίποτα στην εφαρμογή και ορίζουμε τις παραμέτρους εξωτερικά.
Η ευέλικτη παραμετροποίηση των ρυθμίσεων της εφαρμογής εξαρτάται από το περιβάλλον στο οποίο θα εκτελεστεί η εφαρμογή. Έχουμε μετακινήσει όλες τις ρυθμίσεις περιβάλλοντος εξωτερικά: όλα παραμετροποιούνται μέσω της διαμόρφωσης K8S και των παραμέτρων Helm. Όταν η Helm αναπτύσσει ένα συγκρότημα στο περιβάλλον δοκιμής, οι ρυθμίσεις δοκιμής εφαρμόζονται σε αυτό και οι ρυθμίσεις προϊόντος εφαρμόζονται στο περιβάλλον παραγωγής.
Το πιο δύσκολο ήταν να παραμετροποιηθούν όλες οι χρησιμοποιούμενες υπηρεσίες και οι μεταβλητές που εξαρτώνται από το περιβάλλον και να μεταφραστούν σε μεταβλητές περιβάλλοντος και περιγραφή-διαμορφώσεις παραμέτρων περιβάλλοντος για το Helm.
Οι ρυθμίσεις της εφαρμογής χρησιμοποιούν μεταβλητές περιβάλλοντος. Οι τιμές τους ορίζονται σε κοντέινερ χρησιμοποιώντας το K8S configmap, το οποίο διαμορφώνεται χρησιμοποιώντας πρότυπα Go. Για παράδειγμα, ο ορισμός μιας μεταβλητής περιβάλλοντος στο όνομα τομέα μπορεί να γίνει ως εξής:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – αυτή η μεταβλητή αποθηκεύει το όνομα του περιβάλλοντος (prod, stage, UAT).
.Values.app.properties.app_external_domain – σε αυτή τη μεταβλητή ορίζουμε τον επιθυμητό τομέα στο αρχείο .Values.yaml
Κατά την ενημέρωση μιας εφαρμογής, το Helm δημιουργεί ένα αρχείο configmap.yaml από πρότυπα και συμπληρώνει την τιμή APP_EXTERNAL_DOMAIN με την επιθυμητή τιμή ανάλογα με το περιβάλλον στο οποίο ξεκινά η ενημέρωση της εφαρμογής. Αυτή η μεταβλητή έχει ήδη οριστεί στο κοντέινερ. Μπορεί να προσπελαστεί από την εφαρμογή, επομένως κάθε περιβάλλον εφαρμογής θα έχει διαφορετική τιμή για αυτήν τη μεταβλητή.
Σχετικά πρόσφατα, η υποστήριξη K8S εμφανίστηκε στο Spring Cloud, συμπεριλαμβανομένης της εργασίας με configMaps: . Ενώ το έργο αναπτύσσεται ενεργά και αλλάζει ριζικά, δεν μπορούμε να το χρησιμοποιήσουμε στην παραγωγή. Αλλά παρακολουθούμε ενεργά την κατάστασή του και το χρησιμοποιούμε σε διαμορφώσεις DEV. Μόλις σταθεροποιηθεί, θα μεταβούμε από τη χρήση μεταβλητών περιβάλλοντος σε αυτό.
Σε συνολικά
Έτσι, η Συνεχής Ανάπτυξη έχει ρυθμιστεί και λειτουργεί. Όλες οι ενημερώσεις πραγματοποιούνται με ένα πάτημα πλήκτρου. Η παράδοση των αλλαγών στο περιβάλλον του προϊόντος είναι αυτόματη. Και, κυρίως, οι ενημερώσεις δεν σταματούν το σύστημα.
Μελλοντικά σχέδια: αυτόματη μετεγκατάσταση βάσεων δεδομένων
Σκεφτήκαμε την αναβάθμιση της βάσης δεδομένων και τη δυνατότητα επαναφοράς αυτών των αλλαγών. Εξάλλου, δύο διαφορετικές εκδόσεις της εφαρμογής εκτελούνται ταυτόχρονα: η παλιά εκτελείται και η νέα είναι σε λειτουργία. Και θα απενεργοποιήσουμε την παλιά μόνο όταν είμαστε σίγουροι ότι η νέα έκδοση λειτουργεί. Η μετεγκατάσταση της βάσης δεδομένων θα πρέπει να σας επιτρέπει να εργάζεστε και με τις δύο εκδόσεις της εφαρμογής.
Επομένως, δεν μπορούμε απλώς να αλλάξουμε το όνομα της στήλης ή άλλα δεδομένα. Μπορούμε όμως να δημιουργήσουμε μια νέα στήλη, να αντιγράψουμε δεδομένα από την παλιά στήλη σε αυτήν και να γράψουμε κανόνες που, κατά την ενημέρωση των δεδομένων, θα την αντιγράψουν και θα ενημερώσουν ταυτόχρονα σε μια άλλη στήλη. Και μετά την επιτυχή ανάπτυξη της νέας έκδοσης της εφαρμογής, μετά την περίοδο υποστήριξης μετά την εκκίνηση, θα μπορούμε να διαγράψουμε την παλιά στήλη και το έναυσμα που έχει καταστεί περιττό.
Εάν η νέα έκδοση της εφαρμογής δεν λειτουργεί σωστά, μπορούμε να επιστρέψουμε στην προηγούμενη έκδοση, συμπεριλαμβανομένης της προηγούμενης έκδοσης της βάσης δεδομένων. Εν ολίγοις, οι αλλαγές μας θα σας επιτρέψουν να εργάζεστε ταυτόχρονα με πολλές εκδόσεις της εφαρμογής.
Σκοπεύουμε να αυτοματοποιήσουμε τη μετεγκατάσταση της βάσης δεδομένων μέσω της εργασίας K8S, ενσωματώνοντάς την στη διαδικασία του CD. Και σίγουρα θα μοιραστούμε αυτήν την εμπειρία στο Habré.
Πηγή: www.habr.com