🥇 Συγχώνευση 3 κατευθύνσεων στο werf: ανάπτυξη στο Kubernetes με Helm «σε στεροειδή»

Αυτό που περιμέναμε καιρό (και όχι μόνο εμείς) συνέβη: werf, το βοηθητικό πρόγραμμα ανοιχτού κώδικα για τη δημιουργία εφαρμογών και την παράδοσή τους στο Kubernetes, υποστηρίζει πλέον την εφαρμογή αλλαγών με χρήση ενημερώσεων κώδικα συγχώνευσης 3 κατευθύνσεων! Επιπλέον, είναι δυνατή η υιοθέτηση υπαρχόντων πόρων K8 σε εκδόσεις Helm χωρίς να αναδημιουργηθούν αυτοί οι πόροι.

Αν είναι πολύ κοντό, τότε βάζουμε WERF_THREE_WAY_MERGE=enabled — παίρνουμε ανάπτυξη «όπως στο kubectl apply", συμβατό με τις υπάρχουσες εγκαταστάσεις Helm 2 και ακόμη λίγο περισσότερες.

Αλλά ας ξεκινήσουμε με τη θεωρία: τι ακριβώς είναι οι ενημερώσεις κώδικα συγχώνευσης 3 κατευθύνσεων, πώς οι άνθρωποι βρήκαν την προσέγγιση για τη δημιουργία τους και γιατί είναι σημαντικές σε διαδικασίες CI/CD με υποδομή που βασίζεται στο Kubernetes; Και μετά από αυτό, ας δούμε τι είναι η συγχώνευση 3 κατευθύνσεων στο werf, ποιες λειτουργίες χρησιμοποιούνται από προεπιλογή και πώς να το διαχειριστούμε.

Τι είναι μια ενημερωμένη έκδοση κώδικα συγχώνευσης 3 κατευθύνσεων;

Λοιπόν, ας ξεκινήσουμε με το έργο της διάδοσης των πόρων που περιγράφονται στο YAML manifests στο Kubernetes.

Για να εργαστείτε με πόρους, το Kubernetes API προσφέρει τις ακόλουθες βασικές λειτουργίες: δημιουργία, επιδιόρθωση, αντικατάσταση και διαγραφή. Υποτίθεται ότι με τη βοήθειά τους είναι απαραίτητο να κατασκευαστεί μια βολική συνεχής διάθεση πόρων στο σύμπλεγμα. Πως?

Επιτακτικές εντολές kubectl

Η πρώτη προσέγγιση για τη διαχείριση αντικειμένων στο Kubernetes είναι η χρήση επιτακτικών εντολών kubectl για τη δημιουργία, τροποποίηση και διαγραφή αυτών των αντικειμένων. Με απλά λόγια:

ομάδα kubectl run μπορείτε να εκτελέσετε Deployment ή Job:
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
ομάδα kubectl scale — αλλάξτε τον αριθμό των αντιγράφων:
```
kubectl scale --replicas=3 deployment/mysql
```
κλπ.

Αυτή η προσέγγιση μπορεί να φαίνεται βολική με την πρώτη ματιά. Ωστόσο, υπάρχουν προβλήματα:

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

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

Δημιουργία, λήψη, αντικατάσταση και διαγραφή λειτουργιών

Με πρωτοβάθμια δημιουργία είναι απλό: στείλτε το μανιφέστο στη λειτουργία create kube api και ο πόρος έχει δημιουργηθεί. Η αναπαράσταση YAML της δήλωσης μπορεί να αποθηκευτεί στο Git και να δημιουργηθεί χρησιμοποιώντας την εντολή kubectl create -f manifest.yaml.

С μετακίνηση επίσης απλό: αντικαταστήστε το ίδιο manifest.yaml από το Git στην ομάδα kubectl delete -f manifest.yaml.

Λειτουργία replace σας επιτρέπει να αντικαταστήσετε πλήρως τη διαμόρφωση του πόρου με μια νέα, χωρίς να αναδημιουργήσετε τον πόρο. Αυτό σημαίνει ότι πριν κάνετε μια αλλαγή σε έναν πόρο, είναι λογικό να ρωτήσετε την τρέχουσα έκδοση με τη λειτουργία get, αλλάξτε το και ενημερώστε το με τη λειτουργία replace. Ο apiserver kube είναι ενσωματωμένος αισιόδοξο κλείδωμα και, εάν μετά από χειρουργική επέμβαση get έχει αλλάξει το αντικείμενο και μετά η λειτουργία replace δεν θα περάσει.

Για να αποθηκεύσετε τη διαμόρφωση στο Git και να την ενημερώσετε χρησιμοποιώντας την αντικατάσταση, πρέπει να κάνετε τη λειτουργία get, συγχωνεύστε τη διαμόρφωση από το Git με αυτό που λάβαμε και εκτελέστε replace. Από προεπιλογή, το kubectl σάς επιτρέπει μόνο να χρησιμοποιήσετε την εντολή kubectl replace -f manifest.yamlΌπου manifest.yaml — ένα ήδη πλήρως προετοιμασμένο (στην περίπτωσή μας, συγχωνευμένο) μανιφέστο που πρέπει να εγκατασταθεί. Αποδεικνύεται ότι ο χρήστης πρέπει να εφαρμόσει δηλώσεις συγχώνευσης και αυτό δεν είναι ένα ασήμαντο θέμα...

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

Итого: μπορούμε να δημιουργήσουμε μια συνεχή διάθεση μόνο με χρήση δημιουργίας, αντικατάστασης και διαγραφής, διασφαλίζοντας ότι η διαμόρφωση της υποδομής είναι αποθηκευμένη στο Git μαζί με τον κωδικό και το βολικό CI/CD;

Κατ' αρχήν μπορούμε... Για αυτό θα χρειαστεί να εφαρμόσετε τη λειτουργία συγχώνευσης μανιφέστα και κάποιου είδους δεσμευτικό που:

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

Κατά την ενημέρωση, σημειώστε ότι ο πόρος μπορεί να έχει αλλάξει από τελευταία get και χειριστεί αυτόματα την περίπτωση αισιόδοξου κλειδώματος - κάντε επανειλημμένες προσπάθειες ενημέρωσης.

Ωστόσο, γιατί να εφεύρουμε ξανά τον τροχό όταν ο kube-apiserver προσφέρει έναν άλλο τρόπο ενημέρωσης πόρων: τη λειτουργία patch, που απαλλάσσει τον χρήστη από ορισμένα από τα προβλήματα που περιγράφονται;

Patch

Τώρα φτάνουμε στα μπαλώματα.

Οι ενημερώσεις κώδικα είναι ο κύριος τρόπος εφαρμογής αλλαγών σε υπάρχοντα αντικείμενα στο Kubernetes. Λειτουργία patch δουλεύει κάπως έτσι:

ο χρήστης του kube-apiserver πρέπει να στείλει μια ενημερωμένη έκδοση κώδικα σε μορφή JSON και να καθορίσει το αντικείμενο,
και ο ίδιος ο apiserver θα ασχοληθεί με την τρέχουσα κατάσταση του αντικειμένου και θα το φέρει στην απαιτούμενη μορφή.

Δεν απαιτείται αισιόδοξο κλείδωμα σε αυτή την περίπτωση. Αυτή η λειτουργία είναι περισσότερο δηλωτική παρά αντικατάσταση, αν και στην αρχή μπορεί να φαίνεται το αντίστροφο.

Με αυτόν τον τρόπο:

χρησιμοποιώντας μια λειτουργία create δημιουργούμε ένα αντικείμενο σύμφωνα με το μανιφέστο από το Git,
μέσω delete — διαγραφή εάν το αντικείμενο δεν χρειάζεται πλέον,
μέσω patch — αλλάζουμε το αντικείμενο, φέρνοντάς το στη μορφή που περιγράφεται στο Git.

Ωστόσο, για να γίνει αυτό, πρέπει να δημιουργήσετε σωστό έμπλαστρο!

Πώς λειτουργούν οι ενημερώσεις κώδικα στο Helm 2: Συγχώνευση δύο κατευθύνσεων

Όταν εγκαθιστάτε για πρώτη φορά μια έκδοση, η Helm εκτελεί τη λειτουργία create για πόρους γραφήματος.

Κατά την ενημέρωση μιας έκδοσης Helm για κάθε πόρο:

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

Θα ονομάσουμε αυτό το patch Ενημερωμένη έκδοση κώδικα συγχώνευσης 2 κατευθύνσεων, γιατί στη δημιουργία του εμπλέκονται 2 μανιφέστα:

δήλωση πόρων από την προηγούμενη έκδοση,
δήλωση πόρων από τον τρέχοντα πόρο.

Κατά την αφαίρεση της λειτουργίας delete στο kube ο apiserver καλείται για πόρους που είχαν δηλωθεί στην προηγούμενη έκδοση, αλλά δεν δηλώθηκαν στην τρέχουσα.

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

Απεικόνιση του προβλήματος με ένα παράδειγμα

Στο Git, ένα γράφημα αποθηκεύει μια δήλωση στην οποία το πεδίο image Θέματα ανάπτυξης ubuntu:18.04.
Χρήστης μέσω kubectl edit άλλαξε την τιμή αυτού του πεδίου σε ubuntu:19.04.
Κατά την εκ νέου ανάπτυξη του χάρτη Helm δεν δημιουργεί patch, γιατί το χωράφι image στην προηγούμενη έκδοση της κυκλοφορίας και στο τρέχον διάγραμμα είναι τα ίδια.
Μετά την εκ νέου ανάπτυξη image λείψανα ubuntu:19.04, αν και το γράφημα λέει ubuntu:18.04.

Πήραμε αποσυγχρονισμό και χάσαμε τη δηλωτικότητα.

Τι είναι ένας συγχρονισμένος πόρος;

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

Αποδεικνύεται τόσο γενικό κανόνας συγχρονισμένων πόρων: κατά την κυκλοφορία ενός πόρου, μπορείτε να αλλάξετε ή να διαγράψετε μόνο εκείνα τα πεδία που καθορίζονται ρητά στο μανιφέστο από το Git (ή καθορίστηκαν σε προηγούμενη έκδοση και τώρα έχουν διαγραφεί).

Ενημερωμένη έκδοση κώδικα συγχώνευσης 3 κατευθύνσεων

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

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

Με αυτήν την αρχή δημιουργεί patches kubectl apply:

η τελευταία εφαρμοσμένη έκδοση του μανιφέστου αποθηκεύεται στον σχολιασμό του ίδιου του αντικειμένου,
στόχος - λαμβάνεται από το καθορισμένο αρχείο YAML,
το τρέχον είναι από ένα σύμπλεγμα που τρέχει.

Τώρα που διευθετήσαμε τη θεωρία, ήρθε η ώρα να σας πούμε τι κάναμε στο werf.

Εφαρμογή αλλαγών στο werf

Προηγουμένως, η werf, όπως και το Helm 2, χρησιμοποιούσε μπαλώματα συγχώνευσης δύο κατευθύνσεων.

Επισκευή εμπλάστρου

Προκειμένου να μεταβείτε σε έναν νέο τύπο patches - 3-way-merge - το πρώτο βήμα εισαγάγαμε το λεγόμενο μπαλώματα επισκευής.

Κατά την ανάπτυξη, χρησιμοποιείται μια τυπική ενημέρωση κώδικα αμφίδρομης συγχώνευσης, αλλά το werf δημιουργεί επιπλέον μια ενημέρωση κώδικα που θα συγχρονίζει την πραγματική κατάσταση του πόρου με αυτό που είναι γραμμένο στο Git (μια τέτοια ενημέρωση κώδικα δημιουργείται χρησιμοποιώντας τον ίδιο κανόνα συγχρονισμένου πόρου που περιγράφεται παραπάνω) .

Εάν προκύψει αποσυγχρονισμός, στο τέλος της ανάπτυξης ο χρήστης λαμβάνει μια ΠΡΟΕΙΔΟΠΟΙΗΣΗ με ένα αντίστοιχο μήνυμα και μια ενημερωμένη έκδοση κώδικα που πρέπει να εφαρμοστεί για να φέρει τον πόρο σε μια συγχρονισμένη φόρμα. Αυτή η ενημέρωση κώδικα καταγράφεται επίσης σε ειδικό σχολιασμό werf.io/repair-patch. Υποτίθεται ότι τα χέρια του χρήστη ίδιος θα εφαρμόσει αυτό το έμπλαστρο: το werf δεν θα το εφαρμόσει καθόλου.

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

Ενημερωμένη έκδοση κώδικα συγχώνευσης 3 κατευθύνσεων μόνο για νέες εκδόσεις

Από την 1η Δεκεμβρίου 2019, ξεκινούν οι εκδόσεις beta και alpha του werf από προεπιλογή χρησιμοποιήστε πλήρεις ενημερώσεις κώδικα συγχώνευσης 3 κατευθύνσεων για να εφαρμόσετε αλλαγές μόνο στις νέες εκδόσεις Helm που κυκλοφορούν μέσω του werf. Οι υπάρχουσες εκδόσεις θα συνεχίσουν να χρησιμοποιούν την προσέγγιση 2-way-merge + επιδιόρθωση ενημερώσεων κώδικα.

Αυτός ο τρόπος λειτουργίας μπορεί να ενεργοποιηθεί ρητά με ρύθμιση WERF_THREE_WAY_MERGE_MODE=onlyNewReleases τώρα.

Σημείωση: το χαρακτηριστικό εμφανίστηκε στο werf σε πολλές εκδόσεις: στο κανάλι alpha έγινε έτοιμο με την έκδοση v1.0.5-alpha.19, και στο κανάλι beta - με v1.0.4-beta.20.

Ενημερωμένη έκδοση κώδικα συγχώνευσης 3 κατευθύνσεων για όλες τις εκδόσεις

Από τις 15 Δεκεμβρίου 2019, οι εκδόσεις beta και alpha του werf αρχίζουν να χρησιμοποιούν πλήρεις ενημερώσεις κώδικα συγχώνευσης 3 κατευθύνσεων από προεπιλογή για την εφαρμογή αλλαγών σε όλες τις εκδόσεις.

Αυτός ο τρόπος λειτουργίας μπορεί να ενεργοποιηθεί ρητά με ρύθμιση WERF_THREE_WAY_MERGE_MODE=enabled τώρα.

Τι να κάνετε με την αυτόματη κλιμάκωση πόρων;

Υπάρχουν 2 τύποι αυτόματης κλιμάκωσης στο Kubernetes: HPA (οριζόντια) και VPA (κάθετη).

Το Horizontal επιλέγει αυτόματα τον αριθμό των αντιγράφων, κάθετη - τον αριθμό των πόρων. Τόσο ο αριθμός των αντιγράφων όσο και οι απαιτήσεις πόρων καθορίζονται στη δήλωση πόρων (δείτε Δήλωση πόρων). spec.replicas ή spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и άλλοι).

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

Υπάρχουν δύο λύσεις στο πρόβλημα. Αρχικά, είναι καλύτερο να αποφύγετε τον ρητό καθορισμό τιμών αυτόματης κλίμακας στο μανιφέστο γραφήματος. Εάν αυτή η επιλογή δεν είναι κατάλληλη για κάποιο λόγο (για παράδειγμα, επειδή είναι βολικό να ορίσετε αρχικά όρια πόρων και τον αριθμό των αντιγράφων στο γράφημα), τότε η werf προσφέρει τους ακόλουθους σχολιασμούς:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Εάν υπάρχει ένας τέτοιος σχολιασμός, το werf δεν θα επαναφέρει τις αντίστοιχες τιμές σε κάθε ανάπτυξη, αλλά θα τις ορίσει μόνο όταν δημιουργηθεί αρχικά ο πόρος.

Για περισσότερες λεπτομέρειες, ανατρέξτε στην τεκμηρίωση του έργου για ΗΡΑ и VPA.

Απαγορεύστε τη χρήση ενημερωμένης έκδοσης κώδικα συγχώνευσης 3 κατευθύνσεων

Ο χρήστης μπορεί επί του παρόντος να απαγορεύσει τη χρήση νέων ενημερώσεων κώδικα στο werf χρησιμοποιώντας μια μεταβλητή περιβάλλοντος WERF_THREE_WAY_MERGE_MODE=disabled. Ωστόσο, ξεκινώντας Από την 1η Μαρτίου 2020, αυτή η απαγόρευση δεν θα ισχύει πλέον. και θα είναι δυνατή μόνο η χρήση ενημερώσεων κώδικα συγχώνευσης 3 κατευθύνσεων.

Υιοθέτηση πόρων στο werf

Η κυριαρχία της μεθόδου εφαρμογής αλλαγών με ενημερώσεις κώδικα συγχώνευσης 3 κατευθύνσεων μας επέτρεψε να εφαρμόσουμε αμέσως μια τέτοια δυνατότητα όπως η υιοθέτηση πόρων που υπάρχουν στο σύμπλεγμα στην έκδοση Helm.

Το Helm 2 έχει ένα πρόβλημα: δεν μπορείτε να προσθέσετε έναν πόρο σε δηλώσεις γραφήματος που υπάρχει ήδη στο σύμπλεγμα χωρίς να δημιουργήσετε ξανά αυτόν τον πόρο από την αρχή (βλ. #6031, #3275). Διδάξαμε στους Werf να αποδέχονται υπάρχοντες πόρους για απελευθέρωση. Για να το κάνετε αυτό, πρέπει να εγκαταστήσετε έναν σχολιασμό στην τρέχουσα έκδοση του πόρου από το σύμπλεγμα που εκτελείται (για παράδειγμα, χρησιμοποιώντας kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

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

Σημείωση: ρύθμιση WERF_THREE_WAY_MERGE_MODE δεν επηρεάζει την υιοθέτηση πόρων - στην περίπτωση υιοθέτησης, χρησιμοποιείται πάντα μια ενημερωμένη έκδοση κώδικα συγχώνευσης 3 κατευθύνσεων.

Λεπτομέρειες - μέσα τεκμηρίωση.

Συμπεράσματα και μελλοντικά σχέδια

Ελπίζω ότι μετά από αυτό το άρθρο έχει γίνει πιο σαφές τι είναι οι ενημερώσεις κώδικα 3-way-merge και γιατί ήρθαν σε αυτές. Από πρακτική άποψη της ανάπτυξης του έργου werf, η εφαρμογή τους ήταν ένα ακόμη βήμα προς τη βελτίωση της ανάπτυξης που μοιάζει με το Helm. Τώρα μπορείτε να ξεχάσετε τα προβλήματα με το συγχρονισμό διαμόρφωσης, τα οποία προέκυψαν συχνά κατά τη χρήση του Helm 2. Ταυτόχρονα, μια νέα χρήσιμη δυνατότητα υιοθέτησης πόρων Kubernetes που έχετε ήδη κατεβάσει προστέθηκε στην κυκλοφορία του Helm.

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

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

Τιμόνι 3

Άξιο ιδιαίτερης σημείωσης απελευθερώθηκε μόλις τις προάλλες μια νέα κύρια έκδοση του Helm - v3 - η οποία χρησιμοποιεί επίσης ενημερώσεις κώδικα συγχώνευσης 3 κατευθύνσεων και απαλλάσσεται από το Tiller. Η νέα έκδοση του Helm απαιτεί μεταναστεύσεις υπάρχουσες εγκαταστάσεις για να τις μετατρέψετε στη νέα μορφή αποθήκευσης έκδοσης.

Η Werf, από την πλευρά της, αυτή τη στιγμή έχει απαλλαγεί από τη χρήση του Tiller, άλλαξε σε συγχώνευση 3 κατευθύνσεων και πρόσθεσε πολύ περισσότερο, ενώ παραμένει συμβατό με τις υπάρχουσες εγκαταστάσεις Helm 2 (δεν χρειάζεται να εκτελεστούν σενάρια μετεγκατάστασης). Επομένως, μέχρι το werf να αλλάξει στο Helm 3, οι χρήστες του werf δεν χάνουν τα κύρια πλεονεκτήματα του Helm 3 έναντι του Helm 2 (τα έχει και η werf).

Ωστόσο, η μετάβαση του werf στη βάση κωδικών Helm 3 είναι αναπόφευκτη και θα συμβεί στο εγγύς μέλλον. Πιθανώς αυτό θα είναι werf 1.1 ή werf 1.2 (προς το παρόν, η κύρια έκδοση του werf είναι 1.0· για περισσότερες πληροφορίες σχετικά με τη συσκευή έκδοσης werf, βλ. εδώ). Σε αυτό το διάστημα, το Helm 3 θα έχει χρόνο να σταθεροποιηθεί.

PS

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

Μια σειρά σημειώσεων σχετικά με τις καινοτομίες στο werf:
«werf - το εργαλείο μας για CI / CD στο Kubernetes (επισκόπηση και αναφορά βίντεο)"?
«Δημιουργία και ανάπτυξη παρόμοιων μικρουπηρεσιών με το werf και το GitLab CI"?
«Παρουσιάζοντας το Helm 3».

Πηγή: www.habr.com

3-way merge to werf: ανάπτυξη στο Kubernetes με Helm "σε στεροειδή"