είναι το βοηθητικό πρόγραμμα ανοιχτού κώδικα GitOps CLI για τη δημιουργία και την παράδοση εφαρμογών στο Kubernetes. Οπως υποσχέθηκα, σηματοδότησε την αρχή της προσθήκης νέων χαρακτηριστικών στο werf και της αναθεώρησης των παραδοσιακών προσεγγίσεων. Τώρα είμαστε στην ευχάριστη θέση να παρουσιάσουμε την έκδοση v1.1, η οποία είναι ένα μεγάλο βήμα στην ανάπτυξη και ένα θεμέλιο για το μέλλον συλλέκτης werf. Η έκδοση είναι προς το παρόν διαθέσιμη στο .
Η βάση της κυκλοφορίας είναι η νέα αρχιτεκτονική της αποθήκευσης σκηνής και η βελτιστοποίηση της δουλειάς και των δύο συλλεκτών (για Stapel και Dockerfile). Η νέα αρχιτεκτονική αποθήκευσης ανοίγει τη δυνατότητα υλοποίησης κατανεμημένων συγκροτημάτων από πολλαπλούς κεντρικούς υπολογιστές και παράλληλων συγκροτημάτων στον ίδιο κεντρικό υπολογιστή.
Η βελτιστοποίηση της εργασίας περιλαμβάνει την απαλλαγή από περιττούς υπολογισμούς στο στάδιο του υπολογισμού των υπογραφών σταδίων και την αλλαγή των μηχανισμών για τον υπολογισμό των αθροισμάτων ελέγχου αρχείων ώστε να είναι πιο αποτελεσματικοί. Αυτή η βελτιστοποίηση μειώνει τον μέσο χρόνο κατασκευής έργων με χρήση του werf. Και idle builds, όταν όλα τα στάδια υπάρχουν στην κρυφή μνήμη στάδια-αποθήκευση, είναι τώρα πολύ γρήγορα. Στις περισσότερες περιπτώσεις, η επανεκκίνηση της κατασκευής θα διαρκέσει λιγότερο από 1 δευτερόλεπτο! Αυτό ισχύει επίσης για τις διαδικασίες επαλήθευσης σταδίων στη διαδικασία της εργασίας των ομάδων. werf deploy и werf run.
Επίσης σε αυτήν την έκδοση, εμφανίστηκε μια στρατηγική για την προσθήκη ετικετών σε εικόνες ανά περιεχόμενο - ετικέτες βάσει περιεχομένου, το οποίο είναι πλέον ενεργοποιημένο από προεπιλογή και το μόνο που προτείνεται.
Ας ρίξουμε μια πιο προσεκτική ματιά στις βασικές καινοτομίες στο werf v1.1 και, ταυτόχρονα, ας σας πούμε για τα σχέδια για το μέλλον.
Τι έχει αλλάξει στο werf v1.1;
Νέα μορφή ονομασίας σταδίων και αλγόριθμος για την επιλογή σταδίων από την κρυφή μνήμη
Νέος κανόνας δημιουργίας σκηνικών ονομάτων. Τώρα κάθε έκδοση σταδίου δημιουργεί ένα μοναδικό όνομα σταδίου, το οποίο αποτελείται από 2 μέρη: μια υπογραφή (όπως ήταν στην έκδοση 1.0) συν ένα μοναδικό προσωρινό αναγνωριστικό.
Για παράδειγμα, το όνομα της εικόνας πλήρους σκηνής μπορεί να μοιάζει με αυτό:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
ή γενικά:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Εδώ:
-
SIGNATUREείναι μια υπογραφή σκηνής, η οποία αντιπροσωπεύει το αναγνωριστικό του περιεχομένου σκηνής και εξαρτάται από το ιστορικό των επεξεργασιών στο Git που οδήγησαν σε αυτό το περιεχόμενο. -
TIMESTAMP_MILLISECείναι ένα εγγυημένο μοναδικό αναγνωριστικό εικόνας που δημιουργείται τη στιγμή που δημιουργείται μια νέα εικόνα.
Ο αλγόριθμος για την επιλογή σταδίων από τη μνήμη cache βασίζεται στον έλεγχο της σχέσης των δεσμεύσεων Git:
- Ο Werf υπολογίζει την υπογραφή ενός συγκεκριμένου σταδίου.
- В στάδια-αποθήκευση Μπορεί να υπάρχουν πολλά στάδια για μια δεδομένη υπογραφή. Ο Werf επιλέγει όλα τα στάδια που ταιριάζουν με την υπογραφή.
- Εάν το τρέχον στάδιο είναι συνδεδεμένο με το Git (git-archive, προσαρμοσμένο στάδιο με ενημερώσεις κώδικα Git:
install,beforeSetup,setup; ή git-latest-patch), τότε η werf επιλέγει μόνο εκείνα τα στάδια που σχετίζονται με μια δέσμευση που είναι πρόγονος της τρέχουσας δέσμευσης (για την οποία ονομάζεται η κατασκευή). - Από τα υπόλοιπα κατάλληλα στάδια, επιλέγεται ένα - το παλαιότερο κατά την ημερομηνία δημιουργίας.
Ένα στάδιο για διαφορετικούς κλάδους Git μπορεί να έχει την ίδια υπογραφή. Αλλά το werf θα αποτρέψει τη χρήση της κρυφής μνήμης που σχετίζεται με διαφορετικούς κλάδους μεταξύ αυτών των διακλαδώσεων, ακόμα κι αν οι υπογραφές ταιριάζουν.
.
Νέος αλγόριθμος δημιουργίας και αποθήκευσης σταδίων στην αποθήκευση σταδίων
Εάν, κατά την επιλογή σταδίων από την κρυφή μνήμη, το werf δεν βρει κατάλληλο στάδιο, τότε ξεκινά η διαδικασία συναρμολόγησης ενός νέου σταδίου.
Σημειώστε ότι πολλές διεργασίες (σε έναν ή περισσότερους κεντρικούς υπολογιστές) μπορούν να ξεκινήσουν τη δημιουργία του ίδιου σταδίου περίπου την ίδια στιγμή. Ο Werf χρησιμοποιεί έναν αισιόδοξο αλγόριθμο αποκλεισμού στάδια-αποθήκευση τη στιγμή της αποθήκευσης της πρόσφατα συλλεγμένης εικόνας στάδια-αποθήκευση. Με αυτόν τον τρόπο, όταν το νέο στάδιο κατασκευής είναι έτοιμο, το werf μπλοκ στάδια-αποθήκευση και αποθηκεύει μια πρόσφατα συλλεγμένη εικόνα εκεί μόνο εάν δεν υπάρχει πλέον κατάλληλη εικόνα (με υπογραφή και άλλες παραμέτρους - δείτε τον νέο αλγόριθμο για την επιλογή σταδίων από την κρυφή μνήμη).
Μια πρόσφατα συναρμολογημένη εικόνα είναι εγγυημένη ότι έχει ένα μοναδικό αναγνωριστικό από TIMESTAMP_MILLISEC (δείτε τη νέα μορφή ονομασίας σταδίου). Σε περίπτωση που σε στάδια-αποθήκευση θα βρεθεί μια κατάλληλη εικόνα, η werf θα απορρίψει την πρόσφατα μεταγλωττισμένη εικόνα και θα χρησιμοποιήσει την εικόνα από την κρυφή μνήμη.
Με άλλα λόγια: η πρώτη διαδικασία για την ολοκλήρωση της δημιουργίας της εικόνας (η πιο γρήγορη) θα έχει το δικαίωμα να την αποθηκεύσει σε στάδια-αποθήκευση (και τότε είναι αυτή η μοναδική εικόνα που θα χρησιμοποιηθεί για όλες τις εκδόσεις). Μια αργή διαδικασία κατασκευής δεν θα εμποδίσει ποτέ μια ταχύτερη διαδικασία να αποθηκεύσει τα αποτελέσματα κατασκευής του τρέχοντος σταδίου και να προχωρήσει στην επόμενη έκδοση.
.
Βελτιωμένη απόδοση του προγράμματος δημιουργίας Dockerfile
Προς το παρόν, ο αγωγός των σταδίων για μια εικόνα που δημιουργήθηκε από ένα αρχείο Docker αποτελείται από ένα στάδιο - dockerfile. Κατά τον υπολογισμό της υπογραφής, υπολογίζεται το άθροισμα ελέγχου των αρχείων context, το οποίο θα χρησιμοποιηθεί κατά τη συναρμολόγηση. Πριν από αυτή τη βελτίωση, ο werf περιηγήθηκε αναδρομικά σε όλα τα αρχεία και έλαβε ένα άθροισμα ελέγχου αθροίζοντας το περιβάλλον και τη λειτουργία κάθε αρχείου. Ξεκινώντας με την έκδοση 1.1, η werf μπορεί να χρησιμοποιήσει υπολογισμένα αθροίσματα ελέγχου που είναι αποθηκευμένα σε ένα αποθετήριο Git.
Ο αλγόριθμος βασίζεται σε . Ο αλγόριθμος λαμβάνει υπόψη τις εγγραφές στο .dockerignore και διασχίζει το δέντρο αρχείων αναδρομικά μόνο όταν είναι απαραίτητο. Έτσι, έχουμε αποσυνδεθεί από την ανάγνωση του συστήματος αρχείων και την εξάρτηση του αλγορίθμου από το μέγεθος context δεν είναι σημαντική.
Ο αλγόριθμος ελέγχει επίσης αρχεία που δεν έχουν εντοπιστεί και, εάν είναι απαραίτητο, τα λαμβάνει υπόψη στο άθροισμα ελέγχου.
Βελτιωμένη απόδοση κατά την εισαγωγή αρχείων
Οι εκδόσεις του werf v1.1 χρησιμοποιούν διακομιστή rsync όταν . Προηγουμένως, η εισαγωγή γινόταν σε δύο βήματα χρησιμοποιώντας μια προσάρτηση καταλόγου από το κεντρικό σύστημα.
Η απόδοση εισαγωγής στο macOS δεν περιορίζεται πλέον από τους όγκους του Docker και οι εισαγωγές ολοκληρώνονται στον ίδιο χρόνο με το Linux και τα Windows.
Προσθήκη ετικετών βάσει περιεχομένου
Το Werf v1.1 υποστηρίζει τη λεγόμενη προσθήκη ετικετών από περιεχόμενο εικόνας - ετικέτες βάσει περιεχομένου. Οι ετικέτες των εικόνων Docker που προκύπτουν εξαρτώνται από το περιεχόμενο αυτών των εικόνων.
Κατά την εκτέλεση της εντολής werf publish --tags-by-stages-signature ή werf ci-env --tagging-strategy=stages-signature δημοσιευμένες εικόνες του λεγόμενου σκηνική υπογραφή εικόνα. Κάθε εικόνα επισημαίνεται με τη δική της υπογραφή των σταδίων αυτής της εικόνας, η οποία υπολογίζεται σύμφωνα με τους ίδιους κανόνες με την κανονική υπογραφή κάθε σταδίου ξεχωριστά, αλλά είναι ένα γενικό αναγνωριστικό της εικόνας.
Η υπογραφή των σταδίων της εικόνας εξαρτάται από:
- το περιεχόμενο αυτής της εικόνας·
- ιστορικά των αλλαγών του Git που οδήγησαν σε αυτό το περιεχόμενο.
Ένα αποθετήριο Git έχει πάντα εικονικές δεσμεύσεις που δεν αλλάζουν τα περιεχόμενα των αρχείων εικόνας. Για παράδειγμα, δεσμεύσεις μόνο με σχόλια ή δεσμεύσεις συγχώνευσης ή δεσμεύσεις που αλλάζουν εκείνα τα αρχεία στο Git που δεν θα εισαχθούν στην εικόνα.
Όταν χρησιμοποιείτε ετικέτες βάσει περιεχομένου, επιλύονται τα προβλήματα των περιττών επανεκκινήσεων των ομάδων εφαρμογών στο Kubernetes λόγω αλλαγών στο όνομα της εικόνας, ακόμη και αν τα περιεχόμενα της εικόνας δεν έχουν αλλάξει. Παρεμπιπτόντως, αυτός είναι ένας από τους λόγους που εμποδίζει την αποθήκευση πολλών μικροϋπηρεσιών μιας εφαρμογής σε ένα μόνο αποθετήριο Git.
Επίσης, η προσθήκη ετικετών βάσει περιεχομένου είναι μια πιο αξιόπιστη μέθοδος προσθήκης ετικετών από την προσθήκη ετικετών σε κλάδους Git, επειδή το περιεχόμενο των εικόνων που προκύπτουν δεν εξαρτάται από τη σειρά με την οποία εκτελούνται οι αγωγοί στο σύστημα CI για τη συναρμολόγηση πολλαπλών δεσμεύσεων του ίδιου κλάδου.
Είναι σημαντικό: από τώρα στάδια-υπογραφή - Είναι η μόνη προτεινόμενη στρατηγική προσθήκης ετικετών. Θα χρησιμοποιηθεί από προεπιλογή στην εντολή werf ci-env (εκτός αν ορίσετε ρητά διαφορετικό σχήμα προσθήκης ετικετών).
. Μια ξεχωριστή δημοσίευση θα αφιερωθεί επίσης σε αυτό το χαρακτηριστικό. ΕΠΙΚΑΙΡΟΠΟΙΗΜΕΝΟ (3 Απριλίου): Άρθρο με λεπτομέρειες .
Επίπεδα καταγραφής
Ο χρήστης έχει πλέον την ευκαιρία να ελέγξει την έξοδο, να ορίσει το επίπεδο καταγραφής και να εργαστεί με πληροφορίες εντοπισμού σφαλμάτων. Προστέθηκαν επιλογές --log-quiet, --log-verbose, --log-debug.
Από προεπιλογή, η έξοδος περιέχει τις ελάχιστες πληροφορίες:
Όταν χρησιμοποιείτε αναλυτική έξοδο (--log-verbose) μπορείτε να δείτε πώς λειτουργεί το werf:
Λεπτομερής έξοδος (--log-debug), εκτός από τις πληροφορίες εντοπισμού σφαλμάτων werf, περιέχει επίσης αρχεία καταγραφής χρησιμοποιημένων βιβλιοθηκών. Για παράδειγμα, μπορείτε να δείτε πώς συμβαίνει η αλληλεπίδραση με το Μητρώο Docker και επίσης να καταγράψετε τα μέρη όπου δαπανάται σημαντικός χρόνος:
Μελλοντικά σχέδια
Προσοχή! Οι επιλογές που περιγράφονται παρακάτω επισημαίνονται v1.1 θα είναι διαθέσιμα σε αυτήν την έκδοση, πολλά από αυτά στο εγγύς μέλλον. Οι ενημερώσεις θα έρχονται μέσω αυτόματων ενημερώσεων . Αυτά τα χαρακτηριστικά δεν επηρεάζουν το σταθερό μέρος των λειτουργιών v1.1· η εμφάνισή τους δεν απαιτεί χειροκίνητη παρέμβαση χρήστη σε υπάρχουσες διαμορφώσεις.
Πλήρης υποστήριξη για διάφορες υλοποιήσεις μητρώου Docker (ΝΕΟ)
- Έκδοση: v1.1
- Ημερομηνίες: Μάρτιος
Ο στόχος είναι ο χρήστης να χρησιμοποιεί μια προσαρμοσμένη υλοποίηση χωρίς περιορισμούς όταν χρησιμοποιεί το werf.
Επί του παρόντος, έχουμε εντοπίσει το ακόλουθο σύνολο λύσεων για τις οποίες θα εγγυηθούμε την πλήρη υποστήριξη:
- Προεπιλογή (βιβλιοθήκη/μητρώο)*,
- AWS ECR
- Γαλανός*,
- Docker Hub
- GCR*,
- Πακέτα GitHub
- Μητρώο GitLab*,
- Λιμάνι*,
- Αποβάθρα.
Οι λύσεις που επί του παρόντος υποστηρίζονται πλήρως από το werf σημειώνονται με αστερίσκο. Για άλλους υπάρχει υποστήριξη, αλλά με περιορισμούς.
Δύο βασικά προβλήματα μπορούν να εντοπιστούν:
- Ορισμένες λύσεις δεν υποστηρίζουν την αφαίρεση ετικετών χρησιμοποιώντας το Docker Registry API, εμποδίζοντας τους χρήστες να χρησιμοποιήσουν την αυτόματη εκκαθάριση του werf. Αυτό ισχύει για τα πακέτα AWS ECR, Docker Hub και GitHub.
- Ορισμένες λύσεις δεν υποστηρίζουν τα λεγόμενα ένθετα αποθετήρια (Docker Hub, GitHub Packages και Quay), αλλά ο χρήστης πρέπει να τα δημιουργήσει με μη αυτόματο τρόπο χρησιμοποιώντας το UI ή το API (AWS ECR).
Θα λύσουμε αυτά και άλλα προβλήματα χρησιμοποιώντας εγγενή API των λύσεων. Αυτή η εργασία περιλαμβάνει επίσης την κάλυψη του πλήρους κύκλου της λειτουργίας werf με δοκιμές για καθένα από αυτά.
Κατανεμημένη κατασκευή εικόνας (↑)
- Έκδοση: v1.2 v1.1 (η προτεραιότητα για την εφαρμογή αυτής της δυνατότητας έχει αυξηθεί)
- Ημερομηνίες: Μάρτιος-Απρίλιος Μάρτιος
Προς το παρόν, τα werf v1.0 και v1.1 μπορούν να χρησιμοποιηθούν μόνο σε έναν αποκλειστικό κεντρικό υπολογιστή για λειτουργίες δημιουργίας και δημοσίευσης εικόνων και ανάπτυξης της εφαρμογής στο Kubernetes.
Για να ανοίξουν οι δυνατότητες κατανεμημένης εργασίας του werf, όταν η δημιουργία και η ανάπτυξη εφαρμογών στο Kubernetes εκκινούνται σε πολλούς αυθαίρετους κεντρικούς υπολογιστές και αυτοί οι κεντρικοί υπολογιστές δεν αποθηκεύουν την κατάστασή τους μεταξύ των builds (προσωρινοί δρομείς), απαιτείται η werf να εφαρμόσει τη δυνατότητα χρήσης το Docker Registry ως κατάστημα σκηνής.
Παλαιότερα, όταν το έργο werf ονομαζόταν ακόμα dapp, είχε μια τέτοια ευκαιρία. Ωστόσο, αντιμετωπίσαμε μια σειρά ζητημάτων που πρέπει να ληφθούν υπόψη κατά την εφαρμογή αυτής της λειτουργικότητας στο werf.
Σημείωση. Αυτή η δυνατότητα δεν απαιτεί από τον συλλέκτη να εργάζεται μέσα σε pods Kubernetes, επειδή Για να το κάνετε αυτό, πρέπει να απαλλαγείτε από την εξάρτηση από τον τοπικό διακομιστή Docker (στο Kubernetes pod δεν υπάρχει πρόσβαση στον τοπικό διακομιστή Docker, επειδή η ίδια η διαδικασία εκτελείται σε ένα κοντέινερ και το werf δεν υποστηρίζει και δεν θα υποστηρίζει εργασία με τον διακομιστή Docker μέσω του δικτύου). Η υποστήριξη για την εκτέλεση του Kubernetes θα υλοποιηθεί ξεχωριστά.
Επίσημη υποστήριξη για το GitHub Actions (ΝΕΟ)
- Έκδοση: v1.1
- Ημερομηνίες: Μάρτιος
Περιλαμβάνει τεκμηρίωση werf (ενότητες αναφορά и καθοδηγήσει), καθώς και το επίσημο GitHub Action για εργασία με το werf.
Επιπλέον, θα επιτρέψει στον werf να εργαστεί σε εφήμερους δρομείς.
Η μηχανική της αλληλεπίδρασης του χρήστη με το σύστημα CI θα βασίζεται στην τοποθέτηση ετικετών σε αιτήματα έλξης για την έναρξη ορισμένων ενεργειών για τη δημιουργία/διάθεση της εφαρμογής.
Τοπική ανάπτυξη και ανάπτυξη εφαρμογών με werf (↓)
- Έκδοση: v1.1
- Ημερομηνίες: Ιανουάριος-Φεβρουάριος Απρίλιος
Ο κύριος στόχος είναι να επιτευχθεί μια ενιαία ενοποιημένη διαμόρφωση για την ανάπτυξη εφαρμογών τόσο σε τοπικό όσο και σε παραγωγή, χωρίς περίπλοκες ενέργειες, εκτός συσκευασίας.
Το werf απαιτείται επίσης να έχει έναν τρόπο λειτουργίας στον οποίο θα είναι βολικό να επεξεργαστείτε τον κώδικα της εφαρμογής και να λαμβάνετε αμέσως σχόλια από την εκτελούμενη εφαρμογή για εντοπισμό σφαλμάτων.
Νέος αλγόριθμος καθαρισμού (ΝΕΟ)
- Έκδοση: v1.1
- Ημερομηνίες: Απρίλιος
Στην τρέχουσα έκδοση του werf v1.1 στη διαδικασία cleanup Δεν υπάρχει πρόβλεψη για καθαρισμό εικόνων για το σχήμα ετικετών που βασίζεται σε περιεχόμενο - αυτές οι εικόνες θα συσσωρεύονται.
Επίσης, η τρέχουσα έκδοση του werf (v1.0 και v1.1) χρησιμοποιεί διαφορετικές πολιτικές εκκαθάρισης για εικόνες που δημοσιεύονται στα σχήματα προσθήκης ετικετών: Git branch, Git tag ή Git commit.
Εφευρέθηκε ένας νέος αλγόριθμος για τον καθαρισμό εικόνων που βασίζεται στο ιστορικό των δεσμεύσεων στο Git, ενοποιημένος για όλα τα σχήματα προσθήκης ετικετών:
- Διατηρήστε όχι περισσότερες από N1 εικόνες που σχετίζονται με τις πιο πρόσφατες δεσμεύσεις N2 για κάθε git HEAD (κλαδιά και ετικέτες).
- Αποθηκεύστε όχι περισσότερες από εικόνες σταδίου N1 που σχετίζονται με τις πιο πρόσφατες δεσμεύσεις N2 για κάθε git HEAD (κλαδιά και ετικέτες).
- Αποθηκεύστε όλες τις εικόνες που χρησιμοποιούνται σε οποιουσδήποτε πόρους συμπλέγματος Kubernetes (όλα τα περιβάλλοντα kube του αρχείου διαμόρφωσης και οι χώροι ονομάτων σαρώνονται, μπορείτε να περιορίσετε αυτήν τη συμπεριφορά με ειδικές επιλογές).
- Αποθηκεύστε όλες τις εικόνες που χρησιμοποιούνται σε μανιφέστα διαμόρφωσης πόρων που είναι αποθηκευμένες στις εκδόσεις Helm.
- Μια εικόνα μπορεί να διαγραφεί εάν δεν συσχετίζεται με κανένα HEAD από το git (για παράδειγμα, επειδή το ίδιο το αντίστοιχο HEAD διαγράφηκε) και δεν χρησιμοποιείται σε καμία δήλωση στο σύμπλεγμα Kubernetes και στις εκδόσεις Helm.
Κτίριο παράλληλης εικόνας (↓)
- Έκδοση: v1.1
- Ημερομηνίες: Ιανουάριος-Φεβρουάριος Απρίλιος*
Η τρέχουσα έκδοση του werf συλλέγει τις εικόνες και τα αντικείμενα που περιγράφονται στο werf.yaml, διαδοχικά. Είναι απαραίτητο να παραλληλιστεί η διαδικασία συναρμολόγησης ανεξάρτητων σταδίων εικόνων και αντικειμένων, καθώς και η παροχή βολικών και ενημερωτικών αποτελεσμάτων.
* Σημείωση: η προθεσμία έχει μετατοπιστεί λόγω αυξημένης προτεραιότητας για την υλοποίηση κατανεμημένης συναρμολόγησης, η οποία θα προσθέσει περισσότερες δυνατότητες οριζόντιας κλίμακας, καθώς και τη χρήση του werf με τις ενέργειες GitHub. Η παράλληλη συναρμολόγηση είναι το επόμενο βήμα βελτιστοποίησης, παρέχοντας κάθετη επεκτασιμότητα κατά τη συναρμολόγηση ενός έργου.
Μετάβαση στο Helm 3 (↓)
- Έκδοση: v1.2
- Ημερομηνίες: Φεβρουάριος-Μάρτιος Μάιος*
Περιλαμβάνει μετεγκατάσταση σε νέα βάση κώδικα και έναν αποδεδειγμένο, βολικό τρόπο μετεγκατάστασης υπαρχουσών εγκαταστάσεων.
* Σημείωση: η μετάβαση στο Helm 3 δεν θα προσθέσει σημαντικά χαρακτηριστικά στο werf, επειδή όλα τα βασικά χαρακτηριστικά του Helm 3 (συγχώνευση 3 κατευθύνσεων και χωρίς φρέζα) έχουν ήδη εφαρμοστεί στο werf. Επιπλέον, η werf έχει πέραν αυτών που υποδεικνύονται. Ωστόσο, αυτή η μετάβαση παραμένει στα σχέδιά μας και θα υλοποιηθεί.
Jsonnet για την περιγραφή της διαμόρφωσης Kubernetes (↓)
- Έκδοση: v1.2
- Ημερομηνίες: Ιανουάριος-Φεβρουάριος Απρίλιος-Μάιος
Το Werf θα υποστηρίζει περιγραφές διαμόρφωσης για το Kubernetes σε μορφή Jsonnet. Ταυτόχρονα, το werf θα παραμείνει συμβατό με το Helm και θα υπάρχει δυνατότητα επιλογής μορφής περιγραφής.
Ο λόγος είναι ότι τα πρότυπα Go, σύμφωνα με πολλούς ανθρώπους, έχουν υψηλό εμπόδιο εισόδου και η κατανόηση του κώδικα αυτών των προτύπων υποφέρει επίσης.
Εξετάζεται επίσης η δυνατότητα εισαγωγής άλλων συστημάτων περιγραφής διαμόρφωσης Kubernetes (για παράδειγμα, Kustomize).
Εργασία στο Kubernetes (↓)
- Έκδοση: v1.2
- Ημερομηνίες: Απρίλιος-Μάιος Μάιος-Ιούνιος
Στόχος: Βεβαιωθείτε ότι δημιουργούνται εικόνες και ότι η εφαρμογή παραδίδεται με χρήση δρομέων στο Kubernetes. Εκείνοι. Νέες εικόνες μπορούν να δημιουργηθούν, να δημοσιευτούν, να καθαριστούν και να αναπτυχθούν απευθείας από τα pods Kubernetes.
Για να εφαρμόσετε αυτή τη δυνατότητα, πρέπει πρώτα να είστε σε θέση να δημιουργήσετε κατανεμημένες εικόνες (βλέπε σημείο παραπάνω).
Απαιτεί επίσης υποστήριξη για τον τρόπο λειτουργίας του δημιουργού χωρίς διακομιστή Docker (δηλαδή έκδοση ή build σε userspace τύπου Kaniko).
Το Werf θα υποστηρίξει τη δημιουργία στο Kubernetes όχι μόνο με το Dockerfile, αλλά και με το Stapel builder του με σταδιακές ανακατασκευές και το Ansible.
Ένα βήμα προς την ανοιχτή ανάπτυξη
Αγαπάμε την κοινότητά μας (, ) και θέλουμε όλο και περισσότεροι άνθρωποι να βοηθήσουν να κάνουμε το werf καλύτερο, να κατανοήσουμε την κατεύθυνση προς την οποία κινούμαστε και να συμμετάσχουν στην ανάπτυξη.
Πολύ πρόσφατα αποφασίστηκε η μετάβαση σε προκειμένου να αποκαλυφθεί η διαδικασία εργασίας της ομάδας μας. Τώρα μπορείτε να δείτε τα άμεσα σχέδια, καθώς και τις τρέχουσες εργασίες στους παρακάτω τομείς:
- ;
- ;
- ;
- .
Έχει γίνει πολλή δουλειά με θέματα:
- Αφαιρέθηκαν άσχετα.
- Τα υπάρχοντα φέρονται σε ενιαία μορφή, με επαρκή αριθμό λεπτομερειών και λεπτομερειών.
- Προστέθηκαν νέα θέματα με ιδέες και προτάσεις.
Πώς να ενεργοποιήσετε την έκδοση v1.1
Η έκδοση είναι προς το παρόν διαθέσιμη στο (σε κανάλια σταθερός и βράχος-στερεός Ωστόσο, οι εκδόσεις θα εμφανιστούν καθώς συμβαίνει σταθεροποίηση ea η ίδια είναι ήδη αρκετά σταθερή για χρήση, γιατί πέρασε από τα κανάλια άλφα и βήτα). Ενεργοποιήθηκε με τον εξής τρόπο:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Συμπέρασμα
Η νέα αρχιτεκτονική αποθήκευσης σταδίων και οι βελτιστοποιήσεις builder για τους κατασκευαστές Stapel και Dockerfile ανοίγουν τη δυνατότητα υλοποίησης κατανεμημένων και παράλληλων builds στο werf. Αυτές οι λειτουργίες θα εμφανιστούν σύντομα στην ίδια έκδοση v1.1 και θα γίνουν αυτόματα διαθέσιμες μέσω του μηχανισμού αυτόματης ενημέρωσης (για χρήστες ).
Σε αυτήν την έκδοση, έχει προστεθεί μια στρατηγική προσθήκης ετικετών που βασίζεται σε περιεχόμενο εικόνας - ετικέτες βάσει περιεχομένου, η οποία έχει γίνει η προεπιλεγμένη στρατηγική. Το κύριο αρχείο καταγραφής εντολών έχει επίσης επεξεργαστεί εκ νέου: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Το επόμενο σημαντικό βήμα είναι η προσθήκη κατανεμημένων συγκροτημάτων. Οι κατανεμημένες εκδόσεις έχουν γίνει υψηλότερη προτεραιότητα από τις παράλληλες εκδόσεις από την έκδοση 1.0, επειδή προσθέτουν περισσότερη αξία στο werf: κάθετη κλιμάκωση των builders και υποστήριξη για εφήμερα builders σε διάφορα συστήματα CI/CD, καθώς και δυνατότητα επίσημης υποστήριξης για GitHub Actions . Ως εκ τούτου, οι προθεσμίες υλοποίησης για παράλληλες συνελεύσεις μετατοπίστηκαν. Ωστόσο, εργαζόμαστε για να εφαρμόσουμε και τις δύο δυνατότητες το συντομότερο δυνατό.
Ακολουθήστε τα νέα! Και μην ξεχάσετε να μας επισκεφτείτε στο για να δημιουργήσετε ένα θέμα, να βρείτε ένα υπάρχον και να προσθέσετε ένα συν, να δημιουργήσετε ένα PR ή απλά να παρακολουθήσετε την εξέλιξη του έργου.
PS
Διαβάστε επίσης στο blog μας:
- «»
- «"?
- Μια σειρά σημειώσεων σχετικά με τις καινοτομίες στο werf:
- «"?
- «"?
- «"?
- «».
Πηγή: www.habr.com