🥇Ετικέτες βάσει περιεχομένου στον συλλέκτη werf: γιατί και πώς λειτουργεί;

werf είναι το βοηθητικό πρόγραμμα ανοιχτού κώδικα GitOps CLI για τη δημιουργία και την παράδοση εφαρμογών στο Kubernetes. ΣΕ έκδοση v1.1 μια νέα δυνατότητα εισήχθη στη συλλογή εικόνων: προσθήκη ετικετών σε εικόνες ανά περιεχόμενο ή ετικέτες βάσει περιεχομένου. Μέχρι τώρα, το τυπικό σχήμα ετικετών στο werf περιελάμβανε την προσθήκη ετικετών σε εικόνες Docker με ετικέτα Git, κλάδο Git ή δέσμευση Git. Αλλά όλα αυτά τα σχήματα έχουν μειονεκτήματα που επιλύονται πλήρως με τη νέα στρατηγική προσθήκης ετικετών. Λεπτομέρειες σχετικά με αυτό και γιατί είναι τόσο καλό είναι κάτω από το κόψιμο.

Κυκλοφορεί ένα σύνολο μικροϋπηρεσιών από ένα αποθετήριο Git

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

Υπάρχουν περιπτώσεις όπου οι υπηρεσίες είναι πραγματικά ανεξάρτητες και δεν σχετίζονται με μία μόνο εφαρμογή. Σε αυτή την περίπτωση, θα βρίσκονται σε ξεχωριστά έργα και η αποδέσμευσή τους θα πραγματοποιηθεί μέσω ξεχωριστών διαδικασιών CI/CD σε κάθε ένα από τα έργα.

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

Προσθήκη ετικετών ανά κλάδο Git και ετικέτα Git

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

Όταν δημιουργείται μια νέα ετικέτα Git - για παράδειγμα, όταν κυκλοφορεί μια νέα έκδοση - θα δημιουργηθεί μια νέα ετικέτα Docker για όλες τις εικόνες έργου στο Μητρώο Docker:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Αυτά τα νέα ονόματα εικόνων περνούν μέσω των προτύπων Helm στη διαμόρφωση Kubernetes. Κατά την έναρξη της ανάπτυξης με την εντολή werf deploy το πεδίο ενημερώνεται image στο Kubernetes ο πόρος εμφανίζεται και επανεκκινεί τους αντίστοιχους πόρους λόγω του αλλαγμένου ονόματος εικόνας.

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

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

Προσθήκη ετικετών από το Git commit

Το werf έχει επίσης μια στρατηγική προσθήκης ετικετών που σχετίζεται με τις δεσμεύσεις Git.

Το Git-commit είναι ένα αναγνωριστικό για τα περιεχόμενα ενός αποθετηρίου Git και εξαρτάται από το ιστορικό επεξεργασίας αρχείων στο αποθετήριο Git, επομένως φαίνεται λογικό να χρησιμοποιείται για την προσθήκη ετικετών σε εικόνες στο Μητρώο Docker.

Ωστόσο, η προσθήκη ετικετών από τη δέσμευση Git έχει τα ίδια μειονεκτήματα με την προσθήκη ετικετών από κλάδους Git ή ετικέτες Git:

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

Η προσθήκη ετικετών στο όνομα κλάδου Git δεν αντικατοπτρίζει την έκδοση εικόνας

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

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

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

Επιπλέον, με διαδοχικές ωθήσεις σε έναν κλάδο με σύντομο χρονικό διάστημα μεταξύ τους, η παλιά δέσμευση μπορεί να μεταγλωττιστεί αργότερα από τη νεότερη: η παλιά έκδοση της εικόνας θα αντικαταστήσει τη νέα χρησιμοποιώντας την ετικέτα διακλάδωσης Git. Τέτοια προβλήματα μπορούν να λυθούν με ένα σύστημα CI/CD (για παράδειγμα, στο GitLab CI η διοχέτευση του τελευταίου εκκινείται για μια σειρά από δεσμεύσεις). Ωστόσο, δεν το υποστηρίζουν όλα τα συστήματα και πρέπει να υπάρχει πιο αξιόπιστος τρόπος για να αποφευχθεί ένα τέτοιο θεμελιώδες πρόβλημα.

Τι είναι η προσθήκη ετικετών βάσει περιεχομένου;

Λοιπόν, τι είναι η προσθήκη ετικετών βάσει περιεχομένου - προσθήκη ετικετών σε εικόνες ανά περιεχόμενο.

Για τη δημιουργία ετικετών Docker, δεν χρησιμοποιούνται τα πρωτόγονα Git (Git branch, Git tag...), αλλά ένα άθροισμα ελέγχου που σχετίζεται με:

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

Μια τέτοια ετικέτα αναγνώρισης είναι η λεγόμενη υπογραφή σκηνής εικόνας.

Κάθε εικόνα αποτελείται από ένα σύνολο σταδίων: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch και τα λοιπά. Κάθε στάδιο έχει ένα αναγνωριστικό που αντικατοπτρίζει το περιεχόμενό του − σκηνική υπογραφή (σκηνική υπογραφή).

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

Για κάθε εικόνα από τη διαμόρφωση werf.yaml Στη γενική περίπτωση, θα υπάρχει η δική του υπογραφή και, κατά συνέπεια, μια ετικέτα Docker.

Η υπογραφή σκηνής λύνει όλα αυτά τα προβλήματα:

Ανθεκτικό σε κενές δεσμεύσεις Git.
Το Resistant to Git δεσμεύει ότι αλλάζει αρχεία που δεν σχετίζονται με την εικόνα.
Δεν οδηγεί στο πρόβλημα της αναθεώρησης της τρέχουσας έκδοσης της εικόνας κατά την επανεκκίνηση των εκδόσεων για παλιές δεσμεύσεις Git ενός κλάδου.

Αυτή είναι πλέον η προτεινόμενη στρατηγική προσθήκης ετικετών και είναι η προεπιλογή στο werf για όλα τα συστήματα CI.

Πώς να ενεργοποιήσετε και να χρησιμοποιήσετε στο werf

Η εντολή έχει πλέον αντίστοιχη επιλογή werf publish: --tag-by-stages-signature=true|false

Σε ένα σύστημα CI, η στρατηγική προσθήκης ετικετών καθορίζεται από την εντολή werf ci-env. Προηγουμένως, η παράμετρος είχε καθοριστεί για αυτό werf ci-env --tagging-strategy=tag-or-branch. Τώρα, αν διευκρινίσετε werf ci-env --tagging-strategy=stages-signature ή μην καθορίσετε αυτήν την επιλογή, η werf θα χρησιμοποιήσει τη στρατηγική προσθήκης ετικετών από προεπιλογή stages-signature. Ομάδα werf ci-env θα ορίσει αυτόματα τις απαραίτητες σημαίες για την εντολή werf build-and-publish (ή werf publish), επομένως δεν χρειάζεται να καθοριστούν πρόσθετες επιλογές για αυτές τις εντολές.

Για παράδειγμα, η εντολή:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

...μπορεί να δημιουργήσει τις παρακάτω εικόνες:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

Εδώ 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d - αυτή είναι μια υπογραφή των σταδίων της εικόνας backendΚαι f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - υπογραφή σταδίων εικόνας frontend.

Όταν χρησιμοποιείτε ειδικές λειτουργίες werf_container_image и werf_container_env Δεν χρειάζεται να αλλάξετε τίποτα στα πρότυπα Helm: αυτές οι λειτουργίες θα δημιουργήσουν αυτόματα τα σωστά ονόματα εικόνων.

Παράδειγμα διαμόρφωσης σε ένα σύστημα CI:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

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

Σε συνολικά

Νέα επιλογή werf publish --tag-by-stages-signature=true|false.
Νέα τιμή επιλογής werf ci-env --tagging-strategy=stages-signature|tag-or-branch (αν δεν έχει καθοριστεί, η προεπιλογή θα είναι stages-signature).
Εάν χρησιμοποιούσατε προηγουμένως τις επιλογές προσθήκης ετικετών για τις δεσμεύσεις Git (WERF_TAG_GIT_COMMIT ή επιλογή werf publish --tag-git-commit COMMIT), στη συνέχεια, φροντίστε να μεταβείτε στη στρατηγική προσθήκης ετικετών στάδια-υπογραφή.
Είναι καλύτερα να αλλάξετε αμέσως νέα έργα στο νέο σχήμα ετικετών.
Κατά τη μεταφορά στο werf 1.1, συνιστάται η εναλλαγή των παλαιών έργων στο νέο σχήμα ετικετών, αλλά το παλιό ετικέτα-ή-υποκατάστημα εξακολουθεί να υποστηρίζεται.

Η προσθήκη ετικετών βάσει περιεχομένου επιλύει όλα τα προβλήματα που καλύπτονται στο άρθρο:

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

Χρησιμοποιησετο! Και μην ξεχάσετε να μας επισκεφτείτε στο GitHubγια να δημιουργήσετε ένα θέμα ή να βρείτε ένα υπάρχον, προσθέστε ένα συν, δημιουργήστε ένα PR ή απλά παρακολουθήστε την εξέλιξη του έργου.

PS

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

Πηγή: www.habr.com

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