GitOps: Σύγκριση μεθόδων έλξης και ώθησης

Σημείωση. μετάφρ.: Στην κοινότητα Kubernetes, μια τάση που ονομάζεται GitOps κερδίζει προφανή δημοτικότητα, όπως έχουμε δει προσωπικά, επίσκεψη KubeCon Europe 2019. Αυτός ο όρος ήταν σχετικά πρόσφατος εφευρέθηκε από τον επικεφαλής της Weaveworks - Alexis Richardson - και σημαίνει τη χρήση εργαλείων οικείων στους προγραμματιστές (κυρίως Git, εξ ου και το όνομα) για την επίλυση λειτουργικών προβλημάτων. Συγκεκριμένα, μιλάμε για τη λειτουργία του Kubernetes με την αποθήκευση των διαμορφώσεών του στο Git και την αυτόματη εισαγωγή αλλαγών στο σύμπλεγμα. Ο Matthias Jg μιλά για δύο προσεγγίσεις σε αυτήν την κυκλοφορία σε αυτό το άρθρο.

Πέρυσι, (στην πραγματικότητα, επίσημα αυτό συνέβη τον Αύγουστο του 2017 - περίπου μετάφρ.) Υπάρχει μια νέα προσέγγιση για την ανάπτυξη εφαρμογών στο Kubernetes. Ονομάζεται GitOps και βασίζεται στη βασική ιδέα ότι οι εκδόσεις ανάπτυξης παρακολουθούνται στο ασφαλές περιβάλλον ενός αποθετηρίου Git.

Τα κύρια πλεονεκτήματα αυτής της προσέγγισης είναι τα εξής::

1. Εκδόσεις ανάπτυξης και ιστορικό αλλαγών. Η κατάσταση ολόκληρου του συμπλέγματος αποθηκεύεται σε ένα αποθετήριο Git και οι αναπτύξεις ενημερώνονται μόνο μέσω δεσμεύσεων. Επιπλέον, όλες οι αλλαγές μπορούν να παρακολουθηθούν χρησιμοποιώντας το ιστορικό δέσμευσης.
2. Επαναφορά χρησιμοποιώντας γνωστές εντολές Git... Πεδιάδα git reset σας επιτρέπει να επαναφέρετε τις αλλαγές στις αναπτύξεις. οι προηγούμενες καταστάσεις είναι πάντα διαθέσιμες.
3. Έλεγχος ετοιμότητας πρόσβασης. Συνήθως, ένα σύστημα Git περιέχει πολλά ευαίσθητα δεδομένα, επομένως οι περισσότερες εταιρείες δίνουν ιδιαίτερη προσοχή στην προστασία τους. Αντίστοιχα, αυτή η προστασία ισχύει και για λειτουργίες με αναπτύξεις.
4. Πολιτικές για αναπτύξεις. Τα περισσότερα συστήματα Git υποστηρίζουν εγγενώς πολιτικές ανά κλάδο — για παράδειγμα, μόνο τα αιτήματα έλξης μπορούν να ενημερώσουν το κύριο και οι αλλαγές πρέπει να ελέγχονται και να γίνονται αποδεκτές από άλλο μέλος της ομάδας. Όπως και με τον έλεγχο πρόσβασης, οι ίδιες πολιτικές ισχύουν για τις ενημερώσεις ανάπτυξης.

Όπως μπορείτε να δείτε, υπάρχουν πολλά οφέλη από τη μέθοδο GitOps. Τον τελευταίο χρόνο, δύο προσεγγίσεις έχουν αποκτήσει ιδιαίτερη δημοτικότητα. Το ένα βασίζεται στην ώθηση, το άλλο βασίζεται στην έλξη. Πριν τα δούμε, ας δούμε πρώτα πώς μοιάζουν οι τυπικές αναπτύξεις Kubernetes.

Μέθοδοι Ανάπτυξης

Τα τελευταία χρόνια, διάφορες μέθοδοι και εργαλεία για την ανάπτυξη έχουν καθιερωθεί στο Kubernetes:

1. Βασίζεται σε εγγενή πρότυπα Kubernetes/Προσαρμογή. Αυτός είναι ο ευκολότερος τρόπος για να αναπτύξετε εφαρμογές στο Kubernetes. Ο προγραμματιστής δημιουργεί τα βασικά αρχεία YAML και τα εφαρμόζει. Για να απαλλαγούμε από τη συνεχή επανεγγραφή των ίδιων προτύπων, αναπτύχθηκε το Kustomize (μετατρέπει τα πρότυπα Kubernetes σε ενότητες). Σημείωση. μετάφρ.: Το Kustomize έχει ενσωματωθεί στο kubectl με κυκλοφορία του Kubernetes 1.14.
2. Χάρτες τιμόνι. Τα γραφήματα πηδαλίου σάς επιτρέπουν να δημιουργείτε σύνολα προτύπων, κοντέινερ εκκίνησης, πλαϊνά καρέ κ.λπ., τα οποία χρησιμοποιούνται για την ανάπτυξη εφαρμογών με πιο ευέλικτες επιλογές προσαρμογής από ό,τι σε μια προσέγγιση που βασίζεται σε πρότυπα. Αυτή η μέθοδος βασίζεται σε πρότυπα αρχεία YAML. Η Helm τα γεμίζει με διάφορες παραμέτρους και στη συνέχεια τις στέλνει στο Tiller, ένα στοιχείο συμπλέγματος που τις αναπτύσσει στο σύμπλεγμα και επιτρέπει ενημερώσεις και επαναλήψεις. Το σημαντικό είναι ότι η Helm ουσιαστικά απλώς εισάγει τις επιθυμητές τιμές στα πρότυπα και στη συνέχεια τις εφαρμόζει με τον ίδιο τρόπο όπως γίνεται στην παραδοσιακή προσέγγιση (διαβάστε περισσότερα για το πώς λειτουργεί όλο αυτό και πώς μπορείτε να το χρησιμοποιήσετε στο δικό μας άρθρο του Helm - περίπου μετάφρ.). Υπάρχει μια μεγάλη ποικιλία από έτοιμα διαγράμματα Helm που καλύπτουν ένα ευρύ φάσμα εργασιών.
3. Εναλλακτικά Εργαλεία. Υπάρχουν πολλά εναλλακτικά εργαλεία. Αυτό που έχουν όλοι είναι ότι μετατρέπουν ορισμένα αρχεία προτύπων σε αρχεία YAML αναγνώσιμα από το Kubernetes και στη συνέχεια τα χρησιμοποιούν.

Στην εργασία μας, χρησιμοποιούμε συνεχώς γραφήματα Helm για σημαντικά εργαλεία (καθώς έχουν πολλά πράγματα ήδη έτοιμα, κάτι που κάνει τη ζωή πολύ πιο εύκολη) και «αγνά» αρχεία YAML Kubernetes για την ανάπτυξη των δικών μας εφαρμογών.

Pull & Push

Σε μια από τις πρόσφατες αναρτήσεις μου στο blog, παρουσίασα το εργαλείο Ροή ύφανσης, που σας επιτρέπει να δεσμεύετε πρότυπα στο αποθετήριο Git και να ενημερώνετε την ανάπτυξη μετά από κάθε δέσμευση ή ώθηση του κοντέινερ. Η εμπειρία μου δείχνει ότι αυτό το εργαλείο είναι ένα από τα κύρια για την προώθηση της προσέγγισης έλξης, επομένως θα αναφέρομαι συχνά σε αυτό. Αν θέλετε να μάθετε περισσότερα για το πώς να το χρησιμοποιήσετε, εδώ σύνδεσμος προς το άρθρο.

Προσοχή! Όλα τα οφέλη από τη χρήση του GitOps παραμένουν ίδια και για τις δύο προσεγγίσεις.

Προσέγγιση βάσει έλξης

Η προσέγγιση έλξης βασίζεται στο γεγονός ότι όλες οι αλλαγές εφαρμόζονται μέσα από το σύμπλεγμα. Υπάρχει ένας χειριστής μέσα στο σύμπλεγμα που ελέγχει τακτικά τα συσχετισμένα αποθετήρια του Git και του Docker Registry. Εάν προκύψουν αλλαγές σε αυτά, η κατάσταση του συμπλέγματος ενημερώνεται εσωτερικά. Αυτή η διαδικασία θεωρείται γενικά πολύ ασφαλής, καθώς κανένας εξωτερικός πελάτης δεν έχει πρόσβαση στα δικαιώματα διαχειριστή συμπλέγματος.

Πλεονεκτήματα:

1. Κανένας εξωτερικός πελάτης δεν έχει δικαιώματα να κάνει αλλαγές στο σύμπλεγμα· όλες οι ενημερώσεις κυκλοφορούν από μέσα.
2. Ορισμένα εργαλεία σάς επιτρέπουν επίσης να συγχρονίζετε ενημερώσεις γραφήματος Helm και να τις συνδέετε με το σύμπλεγμα.
3. Το Docker Registry μπορεί να σαρωθεί για νέες εκδόσεις. Εάν είναι διαθέσιμη μια νέα εικόνα, το αποθετήριο και η ανάπτυξη του Git ενημερώνονται στη νέα έκδοση.
4. Τα εργαλεία έλξης μπορούν να διανεμηθούν σε διαφορετικούς χώρους ονομάτων με διαφορετικά αποθετήρια και δικαιώματα Git. Χάρη σε αυτό, μπορεί να χρησιμοποιηθεί ένα μοντέλο πολλαπλών μισθώσεων. Για παράδειγμα, η ομάδα Α μπορεί να χρησιμοποιήσει τον χώρο ονομάτων Α, η ομάδα Β μπορεί να χρησιμοποιήσει τον χώρο ονομάτων Β και η ομάδα υποδομής μπορεί να χρησιμοποιήσει τον παγκόσμιο χώρο.
5. Κατά κανόνα, τα εργαλεία είναι πολύ ελαφριά.
6. Συνδυάζεται με εργαλεία όπως χειριστή Bitnami σφραγισμένα μυστικά, τα μυστικά μπορούν να αποθηκευτούν κρυπτογραφημένα σε ένα αποθετήριο Git και να ανακτηθούν μέσα στο σύμπλεγμα.
7. Δεν υπάρχει σύνδεση με αγωγούς CD, καθώς οι αναπτύξεις πραγματοποιούνται εντός του συμπλέγματος.

Μειονεκτήματα:

1. Η διαχείριση των μυστικών ανάπτυξης από χάρτες Helm είναι πιο δύσκολη από τα κανονικά, αφού πρώτα πρέπει να δημιουργηθούν με τη μορφή, ας πούμε, σφραγισμένα μυστικά, μετά να αποκρυπτογραφηθούν από έναν εσωτερικό χειριστή και μόνο μετά από αυτό να γίνουν διαθέσιμα στο εργαλείο έλξης. Στη συνέχεια, μπορείτε να εκτελέσετε την κυκλοφορία στο Helm με τις τιμές στα ήδη αναπτυγμένα μυστικά. Ο ευκολότερος τρόπος είναι να δημιουργήσετε ένα μυστικό με όλες τις τιμές Helm που χρησιμοποιούνται για την ανάπτυξη, να το αποκρυπτογραφήσετε και να το δεσμεύσετε στο Git.
2. Όταν ακολουθείτε μια προσέγγιση έλξης, δένεστε με εργαλεία έλξης. Αυτό περιορίζει τη δυνατότητα προσαρμογής της διαδικασίας ανάπτυξης σε ένα σύμπλεγμα. Για παράδειγμα, το Kustomize περιπλέκεται από το γεγονός ότι πρέπει να εκτελεστεί πριν δεσμευτούν τα τελικά πρότυπα στο Git. Δεν λέω ότι δεν μπορείτε να χρησιμοποιήσετε αυτόνομα εργαλεία, αλλά είναι πιο δύσκολο να ενσωματωθούν στη διαδικασία ανάπτυξης.

Προσέγγιση που βασίζεται στην ώθηση

Στην προσέγγιση push, ένα εξωτερικό σύστημα (κυρίως αγωγοί CD) εκκινεί αναπτύξεις στο σύμπλεγμα μετά από μια δέσμευση στο αποθετήριο Git ή εάν η προηγούμενη διοχέτευση CI είναι επιτυχής. Σε αυτή την προσέγγιση, το σύστημα έχει πρόσβαση στο σύμπλεγμα.

Πλεονεκτήματα:

1. Η ασφάλεια καθορίζεται από το αποθετήριο Git και τη διοχέτευση κατασκευής.
2. Η ανάπτυξη διαγραμμάτων Helm είναι ευκολότερη και υποστηρίζει πρόσθετα Helm.
3. Τα μυστικά είναι ευκολότερα στη διαχείριση, επειδή τα μυστικά μπορούν να χρησιμοποιηθούν σε αγωγούς και μπορούν επίσης να αποθηκευτούν κρυπτογραφημένα στο Git (ανάλογα με τις προτιμήσεις του χρήστη).
4. Δεν υπάρχει σύνδεση με ένα συγκεκριμένο εργαλείο, αφού μπορεί να χρησιμοποιηθεί οποιοσδήποτε τύπος.
5. Οι ενημερώσεις έκδοσης κοντέινερ μπορούν να ξεκινήσουν από το build pipeline.

Μειονεκτήματα:

1. Τα δεδομένα πρόσβασης συμπλέγματος βρίσκονται μέσα στο σύστημα κατασκευής.
2. Η ενημέρωση των κοντέινερ ανάπτυξης είναι ακόμα πιο εύκολη με μια διαδικασία έλξης.
3. Μεγάλη εξάρτηση από το σύστημα CD, καθώς οι αγωγοί που χρειαζόμαστε μπορεί να έχουν γραφτεί αρχικά για τους Gitlab Runners και στη συνέχεια η ομάδα αποφασίζει να μετακομίσει στο Azure DevOps ή στο Jenkins... και θα πρέπει να μεταφέρει μεγάλο αριθμό σωλήνων κατασκευής.

Αποτελέσματα: Σπρώξιμο ή τράβηγμα;

Όπως συμβαίνει συνήθως, κάθε προσέγγιση έχει τα υπέρ και τα κατά της. Ορισμένες εργασίες είναι πιο εύκολο να επιτευχθούν με ένα και πιο δύσκολα με ένα άλλο. Στην αρχή έκανα αναπτύξεις με μη αυτόματο τρόπο, αλλά αφού έπεσα πάνω σε μερικά άρθρα σχετικά με το Weave Flux, αποφάσισα να εφαρμόσω διαδικασίες GitOps για όλα τα έργα. Για τα βασικά πρότυπα αυτό ήταν εύκολο, αλλά μετά άρχισα να αντιμετωπίζω δυσκολίες με τα Helm charts. Εκείνη την εποχή, το Weave Flux πρόσφερε μόνο μια στοιχειώδη έκδοση του Helm Chart Operator, αλλά ακόμα και τώρα ορισμένες εργασίες είναι πιο δύσκολες λόγω της ανάγκης να δημιουργήσετε χειροκίνητα μυστικά και να τα εφαρμόσετε. Θα μπορούσατε να υποστηρίξετε ότι η προσέγγιση έλξης είναι πολύ πιο ασφαλής επειδή τα διαπιστευτήρια του συμπλέγματος δεν είναι προσβάσιμα εκτός του συμπλέγματος, καθιστώντας το τόσο πιο ασφαλές που αξίζει την επιπλέον προσπάθεια.

Μετά από σκέψη, κατέληξα στο απροσδόκητο συμπέρασμα ότι δεν είναι έτσι. Αν μιλάμε για στοιχεία που απαιτούν μέγιστη προστασία, αυτή η λίστα θα περιλαμβάνει μυστική αποθήκευση, συστήματα CI/CD και αποθετήρια Git. Οι πληροφορίες στο εσωτερικό τους είναι πολύ ευάλωτες και χρειάζονται μέγιστη προστασία. Επιπλέον, εάν κάποιος μπει στο αποθετήριο Git σας και μπορεί να προωθήσει τον κώδικα εκεί, μπορεί να αναπτύξει ό,τι θέλει (είτε είναι pull είτε push) και να διεισδύσει στα συστήματα του συμπλέγματος. Έτσι, τα πιο σημαντικά στοιχεία που πρέπει να προστατεύονται είναι το αποθετήριο Git και τα συστήματα CI/CD και όχι τα διαπιστευτήρια συμπλέγματος. Εάν διαθέτετε καλά διαμορφωμένες πολιτικές και ελέγχους ασφαλείας για αυτούς τους τύπους συστημάτων και τα διαπιστευτήρια συμπλέγματος εξάγονται μόνο σε αγωγούς ως μυστικά, η προστιθέμενη ασφάλεια μιας προσέγγισης έλξης μπορεί να μην είναι τόσο πολύτιμη όσο αρχικά πιστευόταν.

Επομένως, εάν η προσέγγιση έλξης είναι πιο εντάσεως εργασίας και δεν παρέχει όφελος ασφάλειας, δεν είναι λογικό να χρησιμοποιείται μόνο η προσέγγιση ώθησης; Αλλά κάποιος μπορεί να υποστηρίξει ότι στην προσέγγιση ώθησης είστε πολύ συνδεδεμένοι με το σύστημα CD και, ίσως, είναι καλύτερο να μην το κάνετε αυτό, ώστε να είναι ευκολότερο να πραγματοποιήσετε μετεγκαταστάσεις στο μέλλον.

Κατά τη γνώμη μου (όπως πάντα), θα πρέπει να χρησιμοποιήσετε αυτό που είναι πιο κατάλληλο για μια συγκεκριμένη περίπτωση ή συνδυασμό. Προσωπικά, χρησιμοποιώ και τις δύο προσεγγίσεις: Weave Flux για αναπτύξεις που βασίζονται σε έλξη που περιλαμβάνουν κυρίως τις δικές μας υπηρεσίες και μια προσέγγιση push με Helm και πρόσθετα, που διευκολύνει την εφαρμογή γραφημάτων Helm στο σύμπλεγμα και σας επιτρέπει να δημιουργείτε μυστικά απρόσκοπτα. Νομίζω ότι δεν θα υπάρξει ποτέ μια ενιαία λύση κατάλληλη για όλες τις περιπτώσεις, γιατί υπάρχουν πάντα πολλές αποχρώσεις και εξαρτώνται από τη συγκεκριμένη εφαρμογή. Τούτου λεχθέντος, συνιστώ ανεπιφύλακτα το GitOps - κάνει τη ζωή πολύ πιο εύκολη και βελτιώνει την ασφάλεια.

Ελπίζω ότι η εμπειρία μου σε αυτό το θέμα θα σας βοηθήσει να αποφασίσετε ποια μέθοδος είναι καταλληλότερη για τον τύπο της ανάπτυξής σας και θα χαρώ να ακούσω τη γνώμη σας.

Υ.Γ Σημείωση από τον μεταφραστή

Το μειονέκτημα του μοντέλου έλξης είναι ότι είναι δύσκολο να τεθούν rendered manifests στο Git, αλλά δεν υπάρχει κανένα μειονέκτημα ότι η διοχέτευση CD στο μοντέλο έλξης ζει χωριστά από το rollout και ουσιαστικά γίνεται μια γραμμή κατηγορίας Συνεχής Εφαρμογή. Ως εκ τούτου, θα απαιτηθεί ακόμη μεγαλύτερη προσπάθεια για τη συλλογή της κατάστασής τους από όλες τις αναπτύξεις και την παροχή πρόσβασης στα αρχεία καταγραφής/κατάσταση, κατά προτίμηση με αναφορά στο σύστημα CD.

Υπό αυτή την έννοια, το μοντέλο ώθησης μας επιτρέπει να παρέχουμε τουλάχιστον κάποιες εγγυήσεις για την ανάπτυξη, επειδή η διάρκεια ζωής του αγωγού μπορεί να γίνει ίση με τη διάρκεια ζωής του rollout.

Δοκιμάσαμε και τα δύο μοντέλα και καταλήξαμε στα ίδια συμπεράσματα με τον συγγραφέα του άρθρου:

1. Το μοντέλο έλξης είναι κατάλληλο για να οργανώνουμε ενημερώσεις στοιχείων συστήματος σε μεγάλο αριθμό συμπλεγμάτων (βλ. άρθρο σχετικά με τον χειριστή πρόσθετων).
2. Το μοντέλο ώθησης που βασίζεται στο GitLab CI είναι κατάλληλο για την ανάπτυξη εφαρμογών που χρησιμοποιούν διαγράμματα Helm. Ταυτόχρονα, η ανάπτυξη των αναπτύξεων εντός αγωγών παρακολουθείται χρησιμοποιώντας το εργαλείο werf. Παρεμπιπτόντως, στο πλαίσιο αυτού του έργου μας, ακούσαμε το συνεχές «GitOps» όταν συζητούσαμε τα πιεστικά προβλήματα των μηχανικών DevOps στο περίπτερό μας στο KubeCon Europe'19.

PPS από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

• «Συμβουλές και κόλπα Kubernetes: μεταφορά πόρων που εκτελούνται σε ένα σύμπλεγμα στη διαχείριση Helm 2"?
• «Παρουσιάζουμε το kubedog, μια βιβλιοθήκη για την παρακολούθηση πόρων Kubernetes"?
• «Επέκταση και συμπλήρωση του Kubernetes (αναθεώρηση και αναφορά βίντεο)"?
• «Συμβουλές για τη δημιουργία προσαρμοσμένων ροών εργασίας στο GitLab CI».

Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. Συνδεθείτε, Σας παρακαλούμε.

Χρησιμοποιείτε GitOps;

• Ναι, προσέγγιση έλξης

• Ναι, σπρώξτε

• Ναι, τράβηξε + σπρώξε

• Ναι, κάτι άλλο

• Όχι

Ψήφισαν 30 χρήστες. 10 χρήστες απείχαν.

Πηγή: www.habr.com