Σημείωση. μετάφρ.: Μετά από πρόσφατη δημοσίευση σχετικά με τις μεθόδους έλξης και ώθησης στο GitOps, είδαμε ενδιαφέρον για αυτό το μοντέλο γενικά, αλλά υπήρχαν πολύ λίγες δημοσιεύσεις στη ρωσική γλώσσα σχετικά με αυτό το θέμα (απλά δεν υπάρχουν στο Habré). Ως εκ τούτου, είμαστε στην ευχάριστη θέση να προσφέρουμε στην προσοχή σας μια μετάφραση ενός άλλου άρθρου - αν και σχεδόν πριν από ένα χρόνο! — από την Weaveworks, ο επικεφαλής της οποίας επινόησε τον όρο "GitOps". Το κείμενο εξηγεί την ουσία της προσέγγισης και τις βασικές διαφορές από τις υπάρχουσες.
Πριν από ένα χρόνο δημοσιεύσαμε . Τότε, μοιραστήκαμε τον τρόπο με τον οποίο η ομάδα της Weaveworks κυκλοφόρησε ένα SaaS εξ ολοκλήρου βασισμένο στο Kubernetes και αναπτύξαμε ένα σύνολο συνταγογραφικών βέλτιστων πρακτικών για την ανάπτυξη, τη διαχείριση και την παρακολούθηση σε ένα εγγενές περιβάλλον cloud.
Το άρθρο αποδείχθηκε δημοφιλές. Άλλοι άνθρωποι άρχισαν να μιλούν για το GitOps και άρχισαν να δημοσιεύουν νέα εργαλεία για , , , , και ούτω καθεξής. Εμφανίστηκε στην ιστοσελίδα μας δημοσιεύσεις και περιπτώσεις χρήσης GitOps. Αλλά μερικοί άνθρωποι εξακολουθούν να έχουν ερωτήσεις. Σε τι διαφέρει το μοντέλο από το παραδοσιακό; και συνεχής παράδοση ()? Είναι απαραίτητο να χρησιμοποιήσετε το Kubernetes;
Σύντομα συνειδητοποιήσαμε ότι χρειαζόταν μια νέα περιγραφή, που να προσφέρει:
- Ένας μεγάλος αριθμός παραδειγμάτων και ιστοριών.
- Συγκεκριμένος ορισμός του GitOps.
- Σύγκριση με την παραδοσιακή συνεχή παράδοση.
Σε αυτό το άρθρο προσπαθήσαμε να καλύψουμε όλα αυτά τα θέματα. Παρέχει μια ενημερωμένη εισαγωγή στο GitOps και μια προοπτική προγραμματιστή και CI/CD. Εστιάζουμε κυρίως στο Kubernetes, αν και το μοντέλο μπορεί να γενικευτεί.
Γνωρίστε το GitOps
Φανταστείτε την Αλίκη. Διαχειρίζεται την Οικογενειακή Ασφάλιση, η οποία προσφέρει ασφάλιση υγείας, αυτοκινήτου, σπιτιού και ταξιδιού σε άτομα που είναι πολύ απασχολημένα για να καταλάβουν οι ίδιοι τις λεπτομέρειες των συμβολαίων. Η επιχείρησή της ξεκίνησε ως δευτερεύον έργο όταν η Alice εργαζόταν σε μια τράπεζα ως επιστήμονας δεδομένων. Μια μέρα συνειδητοποίησε ότι μπορούσε να χρησιμοποιήσει προηγμένους αλγόριθμους υπολογιστών για να αναλύσει πιο αποτελεσματικά τα δεδομένα και να διαμορφώσει πακέτα ασφάλισης. Οι επενδυτές χρηματοδότησαν το έργο και τώρα η εταιρεία της φέρνει περισσότερα από 20 εκατομμύρια δολάρια ετησίως και αναπτύσσεται ραγδαία. Αυτή τη στιγμή απασχολεί 180 άτομα σε διάφορες θέσεις. Αυτό περιλαμβάνει μια ομάδα τεχνολογίας που αναπτύσσει, συντηρεί τον ιστότοπο, τη βάση δεδομένων και αναλύει τη βάση πελατών. Επικεφαλής της ομάδας των 60 ατόμων είναι ο Bob, ο τεχνικός διευθυντής της εταιρείας.
Η ομάδα του Bob αναπτύσσει συστήματα παραγωγής στο cloud. Οι βασικές τους εφαρμογές τρέχουν στο GKE, εκμεταλλευόμενοι το Kubernetes στο Google Cloud. Επιπλέον, χρησιμοποιούν διάφορα εργαλεία δεδομένων και ανάλυσης στην εργασία τους.
Η Family Insurance δεν είχε σκοπό να χρησιμοποιήσει κοντέινερ, αλλά παγιδεύτηκε στον ενθουσιασμό του Docker. Η εταιρεία σύντομα ανακάλυψε ότι το GKE διευκόλυνε την ανάπτυξη συμπλεγμάτων για τη δοκιμή νέων χαρακτηριστικών. Τα Jenkins for CI και Quay προστέθηκαν για την οργάνωση του μητρώου κοντέινερ, γράφτηκαν σενάρια για τον Jenkins που ώθησαν νέα κοντέινερ και διαμορφώσεις στο GKE.
Έχει περάσει λίγος καιρός. Η Alice και ο Bob ήταν απογοητευμένοι με την απόδοση της προσέγγισης που επέλεξαν και τον αντίκτυπό της στην επιχείρηση. Η εισαγωγή των εμπορευματοκιβωτίων δεν βελτίωσε την παραγωγικότητα όσο ήλπιζε η ομάδα. Μερικές φορές οι αναπτύξεις έσπασαν και δεν ήταν σαφές εάν έφταιγαν οι αλλαγές στον κώδικα. Αποδείχθηκε επίσης δύσκολο να παρακολουθήσετε τις αλλαγές διαμόρφωσης. Συχνά ήταν απαραίτητο να δημιουργηθεί ένα νέο σύμπλεγμα και να μετακινηθούν εφαρμογές σε αυτό, καθώς αυτός ήταν ο ευκολότερος τρόπος για να εξαλειφθεί το χάος που είχε γίνει το σύστημα. Η Alice φοβόταν ότι η κατάσταση θα χειροτέρευε καθώς αναπτυσσόταν η εφαρμογή (επιπλέον, ένα νέο έργο βασισμένο στη μηχανική μάθηση ετοιμαζόταν). Ο Μπομπ είχε αυτοματοποιήσει το μεγαλύτερο μέρος της εργασίας και δεν καταλάβαινε γιατί ο αγωγός ήταν ακόμα ασταθής, δεν κλιμακώθηκε καλά και χρειαζόταν χειροκίνητη παρέμβαση περιοδικά;
Στη συνέχεια έμαθαν για το GitOps. Αυτή η απόφαση αποδείχθηκε ότι ήταν ακριβώς αυτό που χρειάζονταν για να προχωρήσουν με σιγουριά.
Η Alice και ο Bob άκουγαν για το Git, το DevOps και την υποδομή ως ροές εργασίας κώδικα εδώ και χρόνια. Αυτό που είναι μοναδικό για το GitOps είναι ότι φέρνει ένα σύνολο βέλτιστων πρακτικών—τόσο οριστικές όσο και κανονιστικές—για την εφαρμογή αυτών των ιδεών στο πλαίσιο του Kubernetes. Αυτό το θέμα , συμπεριλαμβανομένου σε .
Η Family Insurance αποφασίζει να εφαρμόσει το GitOps. Η εταιρεία διαθέτει πλέον ένα αυτοματοποιημένο μοντέλο λειτουργίας που είναι συμβατό με Kubernetes και συνδυασμούς ταχύτητα με σταθερότηταγιατι αυτοι:
- διαπίστωσε ότι η παραγωγικότητα της ομάδας διπλασιάστηκε χωρίς να τρελαθεί κανείς.
- σταμάτησε να προβάλλει σενάρια. Αντίθετα, μπορούν τώρα να επικεντρωθούν σε νέα χαρακτηριστικά και να βελτιώσουν τις μεθόδους μηχανικής - για παράδειγμα, εισάγοντας την κυκλοφορία καναρινιών και βελτιώνοντας τις δοκιμές.
- Έχουμε βελτιώσει τη διαδικασία ανάπτυξης, έτσι ώστε σπάνια να χαλάει.
- είχε την ευκαιρία να αποκαταστήσει τις αναπτύξεις μετά από μερικές αποτυχίες χωρίς χειροκίνητη παρέμβαση.
- αγορασμένο μεταχειρισμένοоΜεγαλύτερη εμπιστοσύνη στα συστήματα παράδοσης. Η Alice και ο Bob ανακάλυψαν ότι μπορούσαν να χωρίσουν την ομάδα σε ομάδες microservice που λειτουργούσαν παράλληλα.
- μπορεί να κάνει 30-50 αλλαγές στο έργο κάθε μέρα μέσα από τις προσπάθειες κάθε ομάδας και να δοκιμάσει νέες τεχνικές.
- είναι εύκολο να προσελκύσετε νέους προγραμματιστές στο έργο, οι οποίοι έχουν την ευκαιρία να πραγματοποιήσουν ενημερώσεις στην παραγωγή χρησιμοποιώντας αιτήματα έλξης μέσα σε λίγες ώρες.
- περάστε εύκολα τον έλεγχο στο πλαίσιο του SOC2 (για τη συμμόρφωση των παρόχων υπηρεσιών με τις απαιτήσεις για ασφαλή διαχείριση δεδομένων· διαβάστε περισσότερα, για παράδειγμα, - περίπου μετάφρ.).
Τι συνέβη?
Το GitOps είναι δύο πράγματα:
- Λειτουργικό μοντέλο για Kubernetes και cloud native. Παρέχει ένα σύνολο βέλτιστων πρακτικών για την ανάπτυξη, διαχείριση και παρακολούθηση συμπλεγμάτων και εφαρμογών με εμπορευματοκιβώτια. Κομψός ορισμός στη μορφή από :
- Η διαδρομή για τη δημιουργία ενός περιβάλλοντος διαχείρισης εφαρμογών με επίκεντρο προγραμματιστές. Εφαρμόζουμε τη ροή εργασίας Git τόσο στις λειτουργίες όσο και στην ανάπτυξη. Λάβετε υπόψη ότι δεν πρόκειται μόνο για το Git push, αλλά για την οργάνωση ολόκληρου του συνόλου των εργαλείων CI/CD και UI/UX.
Λίγα λόγια για το Git
Εάν δεν είστε εξοικειωμένοι με τα συστήματα ελέγχου έκδοσης και τη ροή εργασιών που βασίζονται στο Git, συνιστούμε ανεπιφύλακτα να μάθετε για αυτά. Η εργασία με υποκαταστήματα και τα αιτήματα έλξης μπορεί να φαίνεται σαν μαύρη μαγεία στην αρχή, αλλά τα οφέλη αξίζουν τον κόπο. Εδώ να ξεκινήσω.
Πώς λειτουργεί το Kubernetes
Στην ιστορία μας, η Alice και ο Bob στράφηκαν στο GitOps αφού δούλεψαν για λίγο με την Kubernetes. Πράγματι, το GitOps συνδέεται στενά με το Kubernetes - είναι ένα λειτουργικό μοντέλο για υποδομές και εφαρμογές που βασίζονται στο Kubernetes.
Τι δίνει το Kubernetes στους χρήστες;
Εδώ είναι μερικά κύρια χαρακτηριστικά:
- Στο μοντέλο Kubernetes, τα πάντα μπορούν να περιγραφούν σε δηλωτική μορφή.
- Ο διακομιστής API Kubernetes λαμβάνει αυτήν τη δήλωση ως είσοδο και, στη συνέχεια, προσπαθεί συνεχώς να φέρει το σύμπλεγμα στην κατάσταση που περιγράφεται στη δήλωση.
- Οι δηλώσεις επαρκούν για να περιγράψουν και να διαχειριστούν μια μεγάλη ποικιλία φόρτου εργασίας—«εφαρμογές».
- Ως αποτέλεσμα, αλλαγές στην εφαρμογή και το σύμπλεγμα συμβαίνουν λόγω:
- αλλαγές στις εικόνες κοντέινερ.
- αλλαγές στις δηλωτικές προδιαγραφές·
- σφάλματα στο περιβάλλον - για παράδειγμα, σφάλματα κοντέινερ.
Οι μεγάλες δυνατότητες σύγκλισης του Kubernetes
Όταν ένας διαχειριστής κάνει αλλαγές διαμόρφωσης, ο ενορχηστρωτής Kubernetes θα τις εφαρμόσει στο σύμπλεγμα, εφόσον η κατάστασή του είναι δεν θα πλησιάσει τη νέα διαμόρφωση. Αυτό το μοντέλο λειτουργεί για οποιονδήποτε πόρο του Kubernetes και είναι επεκτάσιμο με Προσαρμοσμένους ορισμούς πόρων (CRD). Επομένως, οι αναπτύξεις Kubernetes έχουν τις ακόλουθες υπέροχες ιδιότητες:
- Αυτοματοποίηση: Οι ενημερώσεις Kubernetes παρέχουν έναν μηχανισμό για την αυτοματοποίηση της διαδικασίας εφαρμογής αλλαγών με χάρη και έγκαιρο τρόπο.
- Σύγκλιση: Η Kubernetes θα συνεχίσει να επιχειρεί ενημερώσεις μέχρι να πετύχει.
- Ανικανότητα: Επανειλημμένες εφαρμογές σύγκλισης οδηγούν στο ίδιο αποτέλεσμα.
- Αιτιοκρατία: Όταν οι πόροι είναι επαρκείς, η κατάσταση του ενημερωμένου συμπλέγματος εξαρτάται μόνο από την επιθυμητή κατάσταση.
Πώς λειτουργεί το GitOps
Έχουμε μάθει αρκετά για το Kubernetes για να εξηγήσουμε πώς λειτουργεί το GitOps.
Ας επιστρέψουμε στις ομάδες μικροϋπηρεσιών της Family Insurance. Τι πρέπει να κάνουν συνήθως; Κοιτάξτε την παρακάτω λίστα (αν κάποια στοιχεία σε αυτήν φαίνονται περίεργα ή άγνωστα, παρακαλούμε να σταματήσετε την κριτική και μείνετε μαζί μας). Αυτά είναι απλώς παραδείγματα ροών εργασίας που βασίζονται στο Jenkins. Υπάρχουν πολλές άλλες διαδικασίες κατά την εργασία με άλλα εργαλεία.
Το κύριο πράγμα είναι ότι βλέπουμε ότι κάθε ενημέρωση τελειώνει με αλλαγές στα αρχεία διαμόρφωσης και στα αποθετήρια του Git. Αυτές οι αλλαγές στο Git αναγκάζουν τον "τελεστή GitOps" να ενημερώσει το σύμπλεγμα:
1.Διαδικασία εργασίας:Jenkins build - master κλαδί».
Λίστα εργασιών:
- Ο Jenkins ωθεί τις εικόνες με ετικέτα στο Quay.
- Ο Jenkins ωθεί τα γραφήματα διαμόρφωσης και Helm στον κύριο κάδο αποθήκευσης.
- Η συνάρτηση cloud αντιγράφει τις ρυθμίσεις παραμέτρων και τα γραφήματα από τον κύριο κάδο αποθήκευσης στο κύριο αποθετήριο Git.
- Ο χειριστής GitOps ενημερώνει το σύμπλεγμα.
2. Jenkins build - απελευθέρωση ή κλάδος επείγουσας επιδιόρθωσης:
- Ο Jenkins σπρώχνει εικόνες χωρίς ετικέτα στο Quay.
- Ο Jenkins ωθεί τα διαγράμματα διαμόρφωσης και Helm στον κάδο αποθήκευσης σταδιοποίησης.
- Η συνάρτηση cloud αντιγράφει τις ρυθμίσεις παραμέτρων και τα γραφήματα από τον κάδο αποθήκευσης σταδίου στο αποθετήριο Git σταδίου.
- Ο χειριστής GitOps ενημερώνει το σύμπλεγμα.
3. Jenkins build - ανάπτυξη ή χαρακτηριστικό κλάδο:
- Ο Jenkins σπρώχνει εικόνες χωρίς ετικέτα στο Quay.
- Ο Jenkins ωθεί τα διαγράμματα διαμόρφωσης και Helm στον κάδο αποθήκευσης ανάπτυξης.
- Η συνάρτηση cloud αντιγράφει τις ρυθμίσεις παραμέτρων και τα γραφήματα από τον κάδο αποθήκευσης ανάπτυξης στο αποθετήριο ανάπτυξης Git.
- Ο χειριστής GitOps ενημερώνει το σύμπλεγμα.
4. Προσθήκη νέου πελάτη:
- Ο διαχειριστής ή ο διαχειριστής (LCM/ops) καλεί το Gradle για να αναπτύξει και να διαμορφώσει αρχικά τους εξισορροπητές φόρτου δικτύου (NLB).
- Το LCM/ops δεσμεύει μια νέα διαμόρφωση για να προετοιμάσει την ανάπτυξη για ενημερώσεις.
- Ο χειριστής GitOps ενημερώνει το σύμπλεγμα.
Σύντομη περιγραφή του GitOps
- Περιγράψτε την επιθυμητή κατάσταση ολόκληρου του συστήματος χρησιμοποιώντας δηλωτικές προδιαγραφές για κάθε περιβάλλον (στην ιστορία μας, η ομάδα του Bob ορίζει ολόκληρη τη διαμόρφωση του συστήματος στο Git).
- Το αποθετήριο Git είναι η μοναδική πηγή αλήθειας σχετικά με την επιθυμητή κατάσταση ολόκληρου του συστήματος.
- Όλες οι αλλαγές στην επιθυμητή κατάσταση γίνονται μέσω δεσμεύσεων στο Git.
- Όλες οι επιθυμητές παράμετροι συμπλέγματος είναι επίσης παρατηρήσιμες στο ίδιο το σύμπλεγμα. Με αυτόν τον τρόπο μπορούμε να προσδιορίσουμε αν συμπίπτουν (συγκλίνουν, συγκλίνει) ή διαφέρουν (αποκλίνουν, αποκλίνω) επιθυμητές και παρατηρούμενες καταστάσεις.
- Εάν η επιθυμητή και η παρατηρούμενη κατάσταση διαφέρουν, τότε:
- Υπάρχει ένας μηχανισμός σύγκλισης που αργά ή γρήγορα συγχρονίζει αυτόματα τον στόχο και τις παρατηρούμενες καταστάσεις. Μέσα στο σύμπλεγμα, το Kubernetes το κάνει αυτό.
- Η διαδικασία ξεκινά αμέσως με μια ειδοποίηση «δεσμευμένη αλλαγή».
- Μετά από κάποια χρονική περίοδο με δυνατότητα ρύθμισης, μπορεί να σταλεί μια ειδοποίηση "διαφορά", εάν οι καταστάσεις είναι διαφορετικές.
- Με αυτόν τον τρόπο, όλες οι δεσμεύσεις στο Git προκαλούν επαληθεύσιμες και ανεπαρκείς ενημερώσεις στο σύμπλεγμα.
- Η επαναφορά είναι η σύγκλιση σε μια προηγουμένως επιθυμητή κατάσταση.
- Η σύγκλιση είναι οριστική. Η εμφάνισή του υποδεικνύεται από:
- Δεν υπάρχουν ειδοποιήσεις διαφορών για ορισμένο χρονικό διάστημα.
- "συγκλίνουσα" ειδοποίηση (π.χ. webhook, συμβάν επιστροφής Git).
Τι είναι η απόκλιση;
Ας το επαναλάβουμε ξανά: Όλες οι επιθυμητές ιδιότητες του συμπλέγματος πρέπει να είναι παρατηρήσιμες στο ίδιο το σύμπλεγμα.
Μερικά παραδείγματα απόκλισης:
- Αλλαγή στο αρχείο διαμόρφωσης λόγω συγχώνευσης κλάδων στο Git.
- Μια αλλαγή στο αρχείο διαμόρφωσης λόγω μιας δέσμευσης Git που έγινε από τον πελάτη GUI.
- Πολλαπλές αλλαγές στην επιθυμητή κατάσταση λόγω PR στο Git που ακολουθούνται από τη δημιουργία της εικόνας του κοντέινερ και τις αλλαγές διαμόρφωσης.
- Αλλαγή στην κατάσταση του συμπλέγματος λόγω σφάλματος, σύγκρουσης πόρων με αποτέλεσμα "κακή συμπεριφορά" ή απλώς τυχαία απόκλιση από την αρχική κατάσταση.
Ποιος είναι ο μηχανισμός σύγκλισης;
Μερικά παραδείγματα:
- Για δοχεία και συστάδες, ο μηχανισμός σύγκλισης παρέχεται από την Kubernetes.
- Ο ίδιος μηχανισμός μπορεί να χρησιμοποιηθεί για τη διαχείριση εφαρμογών και σχεδίων που βασίζονται στο Kubernetes (όπως το Istio και το Kubeflow).
- Παρέχει έναν μηχανισμό για τη διαχείριση της λειτουργικής αλληλεπίδρασης μεταξύ του Kubernetes, των αποθετηρίων εικόνας και του Git , που είναι μέρος .
- Για τις βασικές μηχανές, ο μηχανισμός σύγκλισης πρέπει να είναι δηλωτικός και αυτόνομος. Από τη δική μας εμπειρία μπορούμε να το πούμε αυτό πλησιέστερα σε αυτόν τον ορισμό, αλλά εξακολουθεί να απαιτεί ανθρώπινο έλεγχο. Υπό αυτή την έννοια, το GitOps επεκτείνει την παράδοση της Infrastructure ως Code.
Το GitOps συνδυάζει το Git με την εξαιρετική μηχανή σύγκλισης του Kubernetes για να παρέχει ένα μοντέλο για εκμετάλλευση.
Το GitOps μας επιτρέπει να πούμε: Μόνο εκείνα τα συστήματα που μπορούν να περιγραφούν και να παρατηρηθούν μπορούν να αυτοματοποιηθούν και να ελεγχθούν.
Το GitOps προορίζεται για ολόκληρη την εγγενή στοίβα του cloud (για παράδειγμα, Terraform, κ.λπ.)
Το GitOps δεν είναι μόνο το Kubernetes. Θέλουμε ολόκληρο το σύστημα να οδηγείται δηλωτικά και να χρησιμοποιεί τη σύγκλιση. Με τον όρο ολόκληρο το σύστημα εννοούμε μια συλλογή περιβαλλόντων που λειτουργούν με Kubernetes - για παράδειγμα, "dev cluster 1", "production" κ.λπ. Κάθε περιβάλλον περιλαμβάνει μηχανές, συμπλέγματα, εφαρμογές, καθώς και διεπαφές για εξωτερικές υπηρεσίες που παρέχουν δεδομένα, παρακολούθηση και κτλ.
Παρατηρήστε πόσο σημαντικό είναι το Terraform για το πρόβλημα του bootstrapping σε αυτήν την περίπτωση. Το Kubernetes πρέπει να αναπτυχθεί κάπου και η χρήση του Terraform σημαίνει ότι μπορούμε να εφαρμόσουμε τις ίδιες ροές εργασίας GitOps για να δημιουργήσουμε το επίπεδο ελέγχου που στηρίζει το Kubernetes και τις εφαρμογές. Αυτή είναι μια χρήσιμη βέλτιστη πρακτική.
Υπάρχει μεγάλη έμφαση στην εφαρμογή των εννοιών του GitOps σε επίπεδα πάνω από το Kubernetes. Προς το παρόν, υπάρχουν λύσεις τύπου GitOps για Istio, Helm, Ksonnet, OpenFaaS και Kubeflow, καθώς και, για παράδειγμα, για Pulumi, οι οποίες δημιουργούν ένα επίπεδο για την ανάπτυξη εφαρμογών για το cloud native.
Kubernetes CI/CD: σύγκριση GitOps με άλλες προσεγγίσεις
Όπως αναφέρθηκε, το GitOps είναι δύο πράγματα:
- Το μοντέλο λειτουργίας για Kubernetes και cloud native περιγράφεται παραπάνω.
- Η διαδρομή προς ένα περιβάλλον διαχείρισης εφαρμογών με επίκεντρο προγραμματιστές.
Για πολλούς, το GitOps είναι κατά κύριο λόγο μια ροή εργασίας που βασίζεται σε ώθηση Git. Μας αρέσει και αυτός. Αλλά δεν είναι μόνο αυτό: ας δούμε τώρα τους αγωγούς CI/CD.
Το GitOps επιτρέπει τη συνεχή ανάπτυξη (CD) για το Kubernetes
Το GitOps προσφέρει έναν μηχανισμό συνεχούς ανάπτυξης που εξαλείφει την ανάγκη για ξεχωριστά «συστήματα διαχείρισης ανάπτυξης». Η Kubernetes κάνει όλη τη δουλειά για εσάς.
- Η ενημέρωση της εφαρμογής απαιτεί ενημέρωση στο Git. Αυτή είναι μια ενημέρωση συναλλαγών στην επιθυμητή κατάσταση. Στη συνέχεια, η "ανάπτυξη" γίνεται εντός του συμπλέγματος από την ίδια την Kubernetes με βάση την ενημερωμένη περιγραφή.
- Λόγω της φύσης του τρόπου λειτουργίας του Kubernetes, αυτές οι ενημερώσεις συγκλίνουν. Αυτό παρέχει έναν μηχανισμό για συνεχή ανάπτυξη στον οποίο όλες οι ενημερώσεις είναι ατομικές.
- Σημείωση: προσφέρει έναν τελεστή GitOps που ενσωματώνει το Git και το Kubernetes και επιτρέπει την εκτέλεση του CD με τη συμφωνία της επιθυμητής και της τρέχουσας κατάστασης του συμπλέγματος.
Χωρίς kubectl και σενάρια
Θα πρέπει να αποφύγετε τη χρήση του Kubectl για να ενημερώσετε το σύμπλεγμα σας και ιδιαίτερα να αποφύγετε τη χρήση σεναρίων για την ομαδοποίηση εντολών kubectl. Αντίθετα, με τη διοχέτευση GitOps, ένας χρήστης μπορεί να ενημερώσει το σύμπλεγμα Kubernetes μέσω Git.
Τα οφέλη περιλαμβάνουν:
- σωστά. Μια ομάδα ενημερώσεων μπορεί να εφαρμοστεί, να συγκλίνει και τελικά να επικυρωθεί, φέρνοντάς μας πιο κοντά στον στόχο της ατομικής ανάπτυξης. Αντίθετα, η χρήση σεναρίων δεν παρέχει καμία εγγύηση σύγκλισης (περισσότερα για αυτό παρακάτω).
- Ασφάλεια. Kelsey Hightower: «Περιορίστε την πρόσβαση στο σύμπλεγμα Kubernetes στα εργαλεία αυτοματισμού και στους διαχειριστές που είναι υπεύθυνοι για τον εντοπισμό σφαλμάτων ή τη διατήρησή του». δείτε επίσης σχετικά με την ασφάλεια και τη συμμόρφωση με τις τεχνικές προδιαγραφές, καθώς και κλέβοντας διαπιστευτήρια από ένα απρόσεκτα γραμμένο σενάριο Τζένκινς.
- Εμπειρία χρήστη. Το Kubectl εκθέτει τη μηχανική του μοντέλου αντικειμένων Kubernetes, τα οποία είναι αρκετά περίπλοκα. Στην ιδανική περίπτωση, οι χρήστες θα πρέπει να αλληλεπιδρούν με το σύστημα σε υψηλότερο επίπεδο αφαίρεσης. Εδώ θα αναφερθώ ξανά στον Kelsey και θα προτείνω να το παρακολουθήσετε .
Διαφορά μεταξύ CI και CD
Το GitOps βελτιώνει τα υπάρχοντα μοντέλα CI/CD.
Ένας σύγχρονος διακομιστής CI είναι ένα εργαλείο ενορχήστρωσης. Συγκεκριμένα, είναι ένα εργαλείο για την ενορχήστρωση αγωγών CI. Αυτά περιλαμβάνουν τη δημιουργία, τη δοκιμή, τη συγχώνευση με τον κορμό κ.λπ. Οι διακομιστές CI αυτοματοποιούν τη διαχείριση πολύπλοκων αγωγών πολλαπλών βημάτων. Ένας κοινός πειρασμός είναι να γράψετε ένα σενάριο ενημερώσεων του Kubernetes και να το εκτελέσετε ως μέρος ενός αγωγού για να προωθήσετε αλλαγές στο σύμπλεγμα. Πράγματι, αυτό κάνουν πολλοί ειδικοί. Ωστόσο, αυτό δεν είναι το βέλτιστο, και να γιατί.
Το CI θα πρέπει να χρησιμοποιείται για την προώθηση ενημερώσεων στον κορμό και το σύμπλεγμα Kubernetes θα πρέπει να αλλάξει μόνο του με βάση αυτές τις ενημερώσεις για τη διαχείριση του CD εσωτερικά. Το λέμε , σε αντίθεση με το μοντέλο CI push. Το CD είναι μέρος ενορχήστρωση χρόνου εκτέλεσης.
Γιατί οι διακομιστές CI δεν πρέπει να κάνουν CD μέσω άμεσων ενημερώσεων στο Kubernetes
Μην χρησιμοποιείτε διακομιστή CI για να ενορχηστρώνετε άμεσες ενημερώσεις στο Kubernetes ως σύνολο εργασιών CI. Αυτό είναι το αντί-μοτίβο για το οποίο μιλάμε στο blog σας.
Ας επιστρέψουμε στην Αλίκη και τον Μπομπ.
Τι προβλήματα αντιμετώπισαν; Ο διακομιστής CI του Bob εφαρμόζει τις αλλαγές στο σύμπλεγμα, αλλά εάν διακοπεί κατά τη διαδικασία, ο Bob δεν θα γνωρίζει σε ποια κατάσταση βρίσκεται (ή θα έπρεπε να βρίσκεται) το σύμπλεγμα ή πώς να το διορθώσει. Το ίδιο ισχύει και σε περίπτωση επιτυχίας.
Ας υποθέσουμε ότι η ομάδα του Μπομπ δημιούργησε μια νέα εικόνα και στη συνέχεια επιδιορθώνει τις αναπτύξεις της για να αναπτύξει την εικόνα (όλα από τον αγωγό CI).
Εάν η εικόνα δημιουργείται κανονικά, αλλά ο αγωγός αποτύχει, η ομάδα θα πρέπει να καταλάβει:
- Έχει κυκλοφορήσει η ενημέρωση;
- Ξεκινάμε μια νέα κατασκευή; Αυτό θα οδηγήσει σε περιττές παρενέργειες - με τη δυνατότητα να έχουμε δύο build της ίδιας αμετάβλητης εικόνας;
- Πρέπει να περιμένουμε την επόμενη ενημέρωση πριν εκτελέσουμε την έκδοση;
- Τι ακριβώς πήγε στραβά; Ποια βήματα πρέπει να επαναληφθούν (και ποια είναι ασφαλή να επαναληφθούν);
Η δημιουργία μιας ροής εργασίας που βασίζεται στο Git δεν εγγυάται ότι η ομάδα του Bob δεν θα αντιμετωπίσει αυτά τα προβλήματα. Μπορούν ακόμα να κάνουν λάθος με την ώθηση δέσμευσης, την ετικέτα ή κάποια άλλη παράμετρο. Ωστόσο, αυτή η προσέγγιση είναι ακόμα πολύ πιο κοντά σε μια ρητή προσέγγιση όλα ή τίποτα.
Συνοψίζοντας, εδώ είναι γιατί οι διακομιστές CI δεν πρέπει να ασχολούνται με CD:
- Τα σενάρια ενημέρωσης δεν είναι πάντα ντετερμινιστικά. Είναι εύκολο να κάνεις λάθη σε αυτά.
- Οι διακομιστές CI δεν συγκλίνουν στο μοντέλο δηλωτικού συμπλέγματος.
- Είναι δύσκολο να εγγυηθεί κανείς την ανικανότητα. Οι χρήστες πρέπει να κατανοήσουν τη βαθιά σημασιολογία του συστήματος.
- Είναι πιο δύσκολο να συνέλθεις από μια μερική αποτυχία.
Σημείωση σχετικά με το Helm: Εάν θέλετε να χρησιμοποιήσετε το Helm, συνιστούμε να το συνδυάσετε με έναν τελεστή GitOps, όπως π.χ. . Αυτό θα βοηθήσει στη διασφάλιση της σύγκλισης. Το τιμόνι δεν είναι ούτε ντετερμινιστικό ούτε ατομικό.
Το GitOps ως ο καλύτερος τρόπος για την υλοποίηση της Συνεχούς Παράδοσης για το Kubernetes
Η ομάδα της Alice και του Bob εφαρμόζει το GitOps και ανακαλύπτει ότι έχει γίνει πολύ πιο εύκολο να δουλεύεις με προϊόντα λογισμικού, να διατηρείς υψηλή απόδοση και σταθερότητα. Ας τελειώσουμε αυτό το άρθρο με μια απεικόνιση που δείχνει πώς μοιάζει η νέα τους προσέγγιση. Λάβετε υπόψη ότι μιλάμε κυρίως για εφαρμογές και υπηρεσίες, αλλά το GitOps μπορεί να χρησιμοποιηθεί για τη διαχείριση μιας ολόκληρης πλατφόρμας.
Λειτουργικό μοντέλο για Kubernetes
Δείτε το παρακάτω διάγραμμα. Παρουσιάζει το Git και το αποθετήριο εικόνων του κοντέινερ ως κοινόχρηστους πόρους για δύο ενορχηστρωμένους κύκλους ζωής:
- Μια συνεχής διοχέτευση ενοποίησης που διαβάζει και γράφει αρχεία στο Git και μπορεί να ενημερώσει ένα αποθετήριο εικόνων κοντέινερ.
- Ένας αγωγός Runtime GitOps που συνδυάζει την ανάπτυξη με τη διαχείριση και την παρατηρησιμότητα. Διαβάζει και γράφει αρχεία στο Git και μπορεί να κατεβάσει εικόνες κοντέινερ.
Ποια είναι τα κύρια ευρήματα;
- Διαχωρισμός ανησυχιών: Λάβετε υπόψη ότι και οι δύο αγωγοί μπορούν να επικοινωνούν μόνο με ενημέρωση του Git ή του αποθετηρίου εικόνων. Με άλλα λόγια, υπάρχει ένα τείχος προστασίας μεταξύ του CI και του περιβάλλοντος χρόνου εκτέλεσης. Το ονομάζουμε "τείχος προστασίας του αμετάβλητου" (τείχος προστασίας αμετάβλητο), αφού όλες οι ενημερώσεις αποθετηρίου δημιουργούν νέες εκδόσεις. Για περισσότερες πληροφορίες σχετικά με αυτό το θέμα, ανατρέξτε στις διαφάνειες 72-87 .
- Μπορείτε να χρησιμοποιήσετε οποιονδήποτε διακομιστή CI και Git: Το GitOps λειτουργεί με οποιοδήποτε στοιχείο. Μπορείτε να συνεχίσετε να χρησιμοποιείτε τους αγαπημένους σας διακομιστές CI και Git, αποθετήρια εικόνων και δοκιμαστικές σουίτες. Σχεδόν όλα τα άλλα εργαλεία Συνεχούς Παράδοσης στην αγορά απαιτούν τον δικό τους διακομιστή CI/Git ή χώρο αποθήκευσης εικόνων. Αυτό μπορεί να γίνει περιοριστικός παράγοντας στην ανάπτυξη του cloud native. Με το GitOps, μπορείτε να χρησιμοποιήσετε γνωστά εργαλεία.
- Οι εκδηλώσεις ως εργαλείο ολοκλήρωσης: Μόλις ενημερωθούν τα δεδομένα στο Git, το Weave Flux (ή ο τελεστής Weave Cloud) ειδοποιεί το χρόνο εκτέλεσης. Κάθε φορά που το Kubernetes δέχεται ένα σύνολο αλλαγών, το Git ενημερώνεται. Αυτό παρέχει ένα απλό μοντέλο ενοποίησης για την οργάνωση ροών εργασίας για GitOps, όπως φαίνεται παρακάτω.
Συμπέρασμα
Το GitOps παρέχει τις ισχυρές εγγυήσεις ενημέρωσης που απαιτούνται από κάθε σύγχρονο εργαλείο CI/CD:
- αυτοματοποίηση;
- σύγκλιση;
- ανικανότητα?
- αιτιοκρατία.
Αυτό είναι σημαντικό γιατί προσφέρει ένα λειτουργικό μοντέλο για εγγενείς προγραμματιστές cloud.
- Τα παραδοσιακά εργαλεία για τη διαχείριση και την παρακολούθηση συστημάτων συνδέονται με ομάδες επιχειρήσεων που λειτουργούν σε ένα runbook (ένα σύνολο διαδικασιών και λειτουργιών ρουτίνας - περίπου μετάφρ.), που συνδέεται με μια συγκεκριμένη ανάπτυξη.
- Στην εγγενή διαχείριση του cloud, τα εργαλεία παρατηρητικότητας είναι ο καλύτερος τρόπος μέτρησης των αποτελεσμάτων των αναπτύξεων, έτσι ώστε η ομάδα ανάπτυξης να μπορεί να ανταποκρίνεται γρήγορα.
Φανταστείτε πολλά clusters διάσπαρτα σε διαφορετικά σύννεφα και πολλές υπηρεσίες με τις δικές τους ομάδες και σχέδια ανάπτυξης. Το GitOps προσφέρει ένα αμετάβλητο σε κλίμακα μοντέλο για τη διαχείριση όλης αυτής της αφθονίας.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Γνωρίζατε για το GitOps πριν εμφανιστούν αυτές οι δύο μεταφράσεις στο Habré;
-
Ναι, τα ήξερα όλα
-
Μόνο επιφανειακά
-
Όχι
Ψήφισαν 35 χρήστες. 10 χρήστες απείχαν.
Πηγή: www.habr.com