Το θέμα ενός μονοαποθετηρίου έχει συζητηθεί περισσότερες από μία φορές και, κατά κανόνα, προκαλεί πολύ ενεργή διαμάχη. Με τη δημιουργία Ως εργαλείο ανοιχτού κώδικα που έχει σχεδιαστεί για τη βελτίωση της διαδικασίας δημιουργίας κώδικα εφαρμογής από εικόνες Git σε Docker (και στη συνέχεια παράδοσή τους στο Kubernetes), δεν σκεφτόμαστε πολύ ποια επιλογή είναι η καλύτερη. Για εμάς είναι πρωταρχικό να παρέχουμε όλα τα απαραίτητα για τους υποστηρικτές διαφορετικών απόψεων (αν αυτό δεν έρχεται σε αντίθεση με την κοινή λογική, φυσικά).
Η πρόσφατη υποστήριξη mono-repo της werf είναι ένα καλό παράδειγμα αυτού. Αλλά πρώτα, ας καταλάβουμε πώς αυτή η υποστήριξη σχετίζεται γενικά με τη χρήση του werf και τι σχέση έχει το Μητρώο Docker με αυτό ...
Θέματα
Ας φανταστούμε μια τέτοια κατάσταση. Η εταιρεία διαθέτει πολλές ομάδες ανάπτυξης που εργάζονται σε ανεξάρτητα έργα. Οι περισσότερες εφαρμογές τρέχουν στο Kubernetes και ως εκ τούτου είναι κοντέινερ. Για να αποθηκεύσετε κοντέινερ, εικόνες, χρειάζεστε ένα μητρώο (μητρώο). Ως τέτοιο μητρώο, η εταιρεία χρησιμοποιεί το Docker Hub με έναν μόνο λογαριασμό COMPANY. Παρόμοια με τα περισσότερα συστήματα αποθήκευσης πηγαίου κώδικα, Το Docker Hub δεν επιτρέπει την ένθετη ιεραρχία του αποθετηρίου, όπως COMPANY/PROJECT/IMAGE. Σε αυτήν την περίπτωση… πώς μπορείτε να αποθηκεύσετε μη μονολιθικές εφαρμογές στο μητρώο με αυτόν τον περιορισμό χωρίς να δημιουργήσετε ξεχωριστό λογαριασμό για κάθε έργο;
Ίσως, η περιγραφόμενη κατάσταση είναι γνωστή σε κάποιον από πρώτο χέρι, αλλά ας εξετάσουμε το ζήτημα της οργάνωσης της αποθήκευσης εφαρμογών γενικά, δηλ. χωρίς αναφορά στο παραπάνω παράδειγμα και στο Docker Hub.
Λύσεις
Εάν η αίτηση μονολιθικός, έρχεται σε μία εικόνα, τότε δεν υπάρχουν ερωτήσεις και απλώς αποθηκεύουμε τις εικόνες στο μητρώο κοντέινερ του έργου.
Όταν μια εφαρμογή παρουσιάζεται ως πολλαπλά στοιχεία, μικροϋπηρεσίες, τότε απαιτείται μια συγκεκριμένη προσέγγιση. Στο παράδειγμα μιας τυπικής εφαρμογής Ιστού που αποτελείται από δύο εικόνες: frontend и backend - οι πιθανές επιλογές είναι:
- Αποθηκεύστε τις εικόνες σε ξεχωριστά ένθετα αποθετήρια:
- Αποθηκεύστε τα πάντα σε ένα αποθετήριο και θεωρήστε το όνομα της εικόνας στην ετικέτα, για παράδειγμα, ως εξής:
NB: Στην πραγματικότητα, υπάρχει μια άλλη επιλογή με αποθήκευση σε διαφορετικά αποθετήρια, PROJECT-frontend и PROJECT-backend, αλλά δεν θα το εξετάσουμε λόγω της πολυπλοκότητας της υποστήριξης, της οργάνωσης και της διανομής δικαιωμάτων μεταξύ των χρηστών.
υποστήριξη
Αρχικά, το werf περιορίστηκε σε ένθετα αποθετήρια - ευτυχώς, τα περισσότερα μητρώα υποστηρίζουν αυτήν τη δυνατότητα. Ξεκινώντας από την έκδοση , πρόσθεσε εργασία με μητρώα στα οποία η ένθεση δεν υποστηρίζεται, και το Docker Hub είναι ένα από αυτά. Από εκείνο το σημείο και μετά, ο χρήστης έχει την επιλογή του τρόπου αποθήκευσης των εικόνων της εφαρμογής.
Η υλοποίηση είναι διαθέσιμη στην επιλογή --images-repo-mode=multirepo|monorepo (Προκαθορισμένο multirepo, δηλ. αποθήκευση σε ένθετα αποθετήρια). Καθορίζει τα μοτίβα με τα οποία αποθηκεύονται οι εικόνες στο μητρώο. Αρκεί να επιλέξετε την επιθυμητή λειτουργία όταν χρησιμοποιείτε τις βασικές εντολές και όλα τα άλλα θα παραμείνουν αμετάβλητα.
Επειδή οι περισσότερες επιλογές werf μπορούν να οριστούν μεταβλητές περιβάλλοντος, στα συστήματα CI/CD, η λειτουργία αποθήκευσης είναι συνήθως εύκολο να ρυθμιστεί συνολικά για ολόκληρο το έργο. Για παράδειγμα, στην περίπτωση του GitLab απλώς προσθέστε μια μεταβλητή περιβάλλοντος στις ρυθμίσεις του έργου: Ρυθμίσεις -> CI / CD -> Μεταβλητές: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Αν μιλάμε για δημοσίευση εικόνων και διάθεση εφαρμογών (μπορείτε να διαβάσετε λεπτομερώς για αυτές τις διαδικασίες στα σχετικά άρθρα τεκμηρίωσης: и ), τότε η λειτουργία καθορίζει αποκλειστικά το πρότυπο με το οποίο μπορείτε να εργαστείτε με την εικόνα.
Ο διάβολος βρίσκεται στις λεπτομέρειες
Η διαφορά και η κύρια δυσκολία κατά την προσθήκη μιας νέας μεθόδου αποθήκευσης είναι στη διαδικασία καθαρισμού του μητρώου (για τα χαρακτηριστικά εκκαθάρισης που υποστηρίζονται από το werf, βλ ).
Κατά τον καθαρισμό, η werf λαμβάνει υπόψη τις εικόνες που χρησιμοποιούνται στα συμπλέγματα Kubernetes, καθώς και τις πολιτικές που έχουν διαμορφωθεί από τον χρήστη. Οι πολιτικές βασίζονται στη διαίρεση των ετικετών σε στρατηγικές. Στρατηγικές που υποστηρίζονται αυτήν τη στιγμή:
- 3 στρατηγικές που συνδέονται με Git primitives όπως tag, branch και commit.
- 1 στρατηγική για αυθαίρετες προσαρμοσμένες ετικέτες.
Αποθηκεύουμε πληροφορίες σχετικά με τη στρατηγική της ετικέτας κατά τη δημοσίευση της εικόνας στις ετικέτες της τελικής εικόνας. Το ίδιο το νόημα είναι το λεγόμενο μετα-ετικέτα - Απαιτείται η εφαρμογή ορισμένων από τις πολιτικές. Για παράδειγμα, όταν διαγράφετε έναν κλάδο ή μια ετικέτα από ένα αποθετήριο Git, είναι λογικό να διαγράψετε σχετικές αχρησιμοποίητος εικόνες από το μητρώο, το οποίο καλύπτεται από μέρος των πολιτικών μας.
Όταν αποθηκεύεται σε ένα αποθετήριο (monorepo), στην ετικέτα εικόνας, εκτός από τη μετα-ετικέτα, μπορεί επίσης να αποθηκευτεί το όνομα της εικόνας: PROJECT:frontend-META-TAG. Για να τα διαχωρίσουμε, δεν εισαγάγαμε κάποιο συγκεκριμένο διαχωριστικό, αλλά απλώς προσθέσαμε την απαραίτητη τιμή στην ετικέτα της τελικής εικόνας κατά τη δημοσίευση.
NB: Εάν ενδιαφέρεστε να δείτε όλα όσα περιγράφονται στον πηγαίο κώδικα της werf, τότε το σημείο εκκίνησης μπορεί να είναι .
Σε αυτό το άρθρο, δεν θα δώσουμε περισσότερη προσοχή στα προβλήματα και την αιτιολόγηση της προσέγγισής μας: σχετικά με τις στρατηγικές επισήμανσης, την αποθήκευση δεδομένων σε ετικέτες και τη διαδικασία δημοσίευσης στο σύνολό της - όλα αυτά περιγράφονται λεπτομερώς σε μια πρόσφατη αναφορά του Ντμίτρι Στολιάροφ:».
Συνοψίζοντας
Η έλλειψη υποστήριξης για μη ένθετα μητρώα δεν ήταν παράγοντας αποκλεισμού για εμάς ή τους γνωστούς σε εμάς χρήστες werf - τελικά, μπορείτε πάντα να δημιουργήσετε ένα ξεχωριστό μητρώο εικόνων (ή να μεταβείτε σε ένα υπό όρους Μητρώο κοντέινερ στο Google Cloud) ... Ωστόσο, Η κατάργηση ενός τέτοιου περιορισμού φαινόταν λογική προκειμένου το εργαλείο να είναι πιο βολικό στην ευρύτερη κοινότητα DevOps. Εφαρμόζοντάς το, αντιμετωπίσαμε την κύρια δυσκολία στην επανεπεξεργασία του μηχανισμού εκκαθάρισης του μητρώου κοντέινερ. Τώρα που όλα είναι έτοιμα, είναι ωραίο να συνειδητοποιούμε ότι έχει γίνει πιο εύκολο για κάποιον και εμείς (ως κύριοι προγραμματιστές του έργου) δεν θα έχουμε αξιοσημείωτες δυσκολίες στην περαιτέρω υποστήριξη αυτής της δυνατότητας.
Μείνετε μαζί μας και πολύ σύντομα θα σας πούμε για άλλες καινοτομίες στο !
PS
Διαβάστε επίσης στο blog μας:
- «"?
- «».
Πηγή: www.habr.com