Παρουσιάζοντας το Helm 3

Παρουσιάζοντας το Helm 3

Σημείωση. μετάφρ.: Η 16η Μαΐου του τρέχοντος έτους σηματοδοτεί ένα σημαντικό ορόσημο στην ανάπτυξη του διαχειριστή πακέτων για την Kubernetes - Helm. Την ημέρα αυτή, παρουσιάστηκε η πρώτη έκδοση alpha της μελλοντικής μεγάλης έκδοσης του έργου - 3.0. Η κυκλοφορία του θα φέρει σημαντικές και πολυαναμενόμενες αλλαγές στο Helm, για το οποίο πολλοί στην κοινότητα των Kubernetes έχουν μεγάλες ελπίδες. Εμείς είμαστε ένα από αυτά, αφού χρησιμοποιούμε ενεργά το Helm για την ανάπτυξη εφαρμογών: το έχουμε ενσωματώσει στο εργαλείο μας για την υλοποίηση CI/CD werf και κατά καιρούς κάνουμε τη συμβολή μας στην ανάπτυξη της ανάντη. Αυτή η μετάφραση συνδυάζει 7 σημειώσεις από το επίσημο blog Helm, οι οποίες είναι αφιερωμένες στην πρώτη άλφα κυκλοφορία του Helm 3 και μιλούν για την ιστορία του έργου και τα κύρια χαρακτηριστικά του Helm 3. Ο συγγραφέας τους είναι ο Matt "bacongobbler" Fisher, υπάλληλος της Microsoft και ένας από τους βασικούς συντηρητές του Helm.

Στις 15 Οκτωβρίου 2015 γεννήθηκε το έργο που είναι πλέον γνωστό ως Helm. Μόλις ένα χρόνο μετά την ίδρυσή της, η κοινότητα Helm εντάχθηκε στην Kubernetes, ενώ εργαζόταν ενεργά στο Helm 2. Τον Ιούνιο του 2018, η Helm εντάχθηκε στο CNCF ως αναπτυσσόμενο (επώαση) έργο. Γρήγορα προς τα εμπρός στο παρόν, και η πρώτη άλφα κυκλοφορία του νέου Helm 3 είναι καθ' οδόν. (αυτή η έκδοση έχει ήδη πραγματοποιηθεί στα μέσα Μαΐου - περίπου. μετάφρ.).

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

Περίληψη:

  • την ιστορία της δημιουργίας του Helm.
  • ένα τρυφερό αντίο στον Τίλερ.
  • αποθετήρια γραφημάτων?
  • διαχείριση απελευθέρωσης?
  • αλλαγές στις εξαρτήσεις του γραφήματος.
  • διαγράμματα βιβλιοθήκης?
  • τι έπεται?

Η ιστορία του Helm

Γέννηση

Το Helm 1 ξεκίνησε ως έργο ανοιχτού κώδικα που δημιουργήθηκε από την Deis. Ήμασταν μια μικρή startup απορροφάται Η Microsoft την άνοιξη του 2017. Το άλλο μας έργο Ανοιχτού Κώδικα, που ονομαζόταν επίσης Deis, είχε ένα εργαλείο deisctl, το οποίο χρησιμοποιήθηκε (μεταξύ άλλων) για την εγκατάσταση και λειτουργία της πλατφόρμας Deis στο Συστάδα στόλου. Εκείνη την εποχή, ο Fleet ήταν μια από τις πρώτες πλατφόρμες ενορχήστρωσης εμπορευματοκιβωτίων.

Στα μέσα του 2015, αποφασίσαμε να αλλάξουμε πορεία και μετακινήσαμε το Deis (τότε μετονομάστηκε σε Deis Workflow) από το Fleet στο Kubernetes. Ένα από τα πρώτα που επανασχεδιάστηκε ήταν το εργαλείο εγκατάστασης. deisctl. Το χρησιμοποιήσαμε για να εγκαταστήσουμε και να διαχειριστούμε τη ροή εργασίας Deis στο σύμπλεγμα Fleet.

Το Helm 1 δημιουργήθηκε σύμφωνα με την εικόνα διάσημων διαχειριστών πακέτων όπως το Homebrew, το apt και το yum. Ο κύριος στόχος του ήταν να απλοποιήσει εργασίες όπως η συσκευασία και η εγκατάσταση εφαρμογών στο Kubernetes. Το Helm παρουσιάστηκε επίσημα το 2015 στο συνέδριο KubeCon στο Σαν Φρανσίσκο.

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

* Σημείωση. μετάφρ.: Από την πρώτη έκδοση του Helm, η σύνταξη YAML επιλέχθηκε για την περιγραφή των πόρων Kubernetes και τα πρότυπα Jinja και τα σενάρια Python υποστηρίχθηκαν κατά τη σύνταξη διαμορφώσεων. Γράψαμε περισσότερα για αυτό και τη δομή της πρώτης έκδοσης του Helm γενικά στο κεφάλαιο "A Brief History of Helm" αυτό το υλικό.

Για παράδειγμα, για να αντικαταστήσετε ένα πεδίο σε ένα αρχείο YAML, έπρεπε να προσθέσετε την ακόλουθη κατασκευή στο μανιφέστο:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Είναι υπέροχο που υπάρχουν κινητήρες προτύπων σήμερα, έτσι δεν είναι;

Για πολλούς λόγους, αυτό το πρώιμο πρόγραμμα εγκατάστασης του Kubernetes απαιτούσε μια σκληρά κωδικοποιημένη λίστα αρχείων δήλωσης και εκτελούσε μόνο μια μικρή, σταθερή ακολουθία συμβάντων. Ήταν τόσο δύσκολο στη χρήση που η ομάδα Ε&Α της Deis Workflow δυσκολεύτηκε πολύ όταν προσπάθησε να μεταφέρει το προϊόν της σε αυτήν την πλατφόρμα - ωστόσο, οι σπόροι της ιδέας είχαν ήδη σπαρθεί. Η πρώτη μας απόπειρα ήταν μια εξαιρετική ευκαιρία μάθησης: συνειδητοποιήσαμε ότι ήμασταν πραγματικά παθιασμένοι με τη δημιουργία ρεαλιστικών εργαλείων που λύνουν καθημερινά προβλήματα για τους χρήστες μας.

Με βάση την εμπειρία από λάθη του παρελθόντος, αρχίσαμε να αναπτύσσουμε το Helm 2.

Φτιάχνοντας το τιμόνι 2

Στα τέλη του 2015, η ομάδα της Google επικοινώνησε μαζί μας. Δούλευαν σε ένα παρόμοιο εργαλείο για την Kubernetes. Το Deployment Manager για το Kubernetes ήταν μια θύρα ενός υπάρχοντος εργαλείου που χρησιμοποιήθηκε για την πλατφόρμα Google Cloud. «Θα θέλαμε», ρώτησαν, «να περάσουμε μερικές μέρες συζητώντας τις ομοιότητες και τις διαφορές;»

Τον Ιανουάριο του 2016, οι ομάδες Helm και Deployment Manager συναντήθηκαν στο Σιάτλ για να ανταλλάξουν ιδέες. Οι διαπραγματεύσεις τελείωσαν με ένα φιλόδοξο σχέδιο: να συνδυαστούν και τα δύο έργα για τη δημιουργία του Helm 2. Μαζί με τον Deis και την Google, τα παιδιά από SkippBox (τώρα μέρος του Bitnami - περίπου μετάφρ.), και ξεκινήσαμε να δουλεύουμε στο Helm 2.

Θέλαμε να διατηρήσουμε την ευκολία χρήσης του Helm, αλλά προσθέστε τα εξής:

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

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

Από την κυκλοφορία του Helm 2 το 2016, η Kubernetes έχει λάβει αρκετές σημαντικές καινοτομίες. Προστέθηκε έλεγχος πρόσβασης βάσει ρόλων (RBAC), το οποίο αντικατέστησε τελικά τον έλεγχο πρόσβασης βάσει χαρακτηριστικών (ABAC). Εισήχθησαν νέοι τύποι πόρων (οι αναπτύξεις ήταν ακόμα σε beta εκείνη την εποχή). Εφευρέθηκαν προσαρμοσμένοι ορισμοί πόρων (αρχικά ονομαζόμενοι πόροι τρίτων ή TPR). Και το πιο σημαντικό, έχει προκύψει ένα σύνολο βέλτιστων πρακτικών.

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

Ένα τρυφερό αντίο στον Τίλερ

Κατά την ανάπτυξη του Helm 2, παρουσιάσαμε το Tiller ως μέρος της ενσωμάτωσής μας με το Deployment Manager της Google. Ο Tiller έπαιξε σημαντικό ρόλο για τις ομάδες που εργάζονταν σε ένα κοινό σύμπλεγμα: επέτρεψε σε διαφορετικούς ειδικούς που χειρίζονταν την υποδομή να αλληλεπιδρούν με το ίδιο σύνολο εκδόσεων.

Δεδομένου ότι ο έλεγχος πρόσβασης βάσει ρόλων (RBAC) ήταν ενεργοποιημένος από προεπιλογή στο Kubernetes 1.6, η εργασία με τον Tiller στην παραγωγή έγινε πιο δύσκολη. Λόγω του τεράστιου αριθμού πιθανών πολιτικών ασφαλείας, η θέση μας ήταν να προσφέρουμε μια επιτρεπτή διαμόρφωση από προεπιλογή. Αυτό επέτρεψε στους αρχάριους να πειραματιστούν με το Helm και το Kubernetes χωρίς να χρειάζεται να βουτήξουν πρώτα στις ρυθμίσεις ασφαλείας. Δυστυχώς, αυτή η ρύθμιση παραμέτρων άδειας θα μπορούσε να προσδώσει στον χρήστη ένα πολύ ευρύ φάσμα αδειών που δεν χρειαζόταν. Οι μηχανικοί DevOps και SRE έπρεπε να μάθουν πρόσθετα λειτουργικά βήματα κατά την εγκατάσταση του Tiller σε ένα σύμπλεγμα πολλαπλών ενοικιαστών.

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

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

Με την αποχώρηση του Tiller, το μοντέλο ασφαλείας του Helm έχει απλοποιηθεί ριζικά. Το Helm 3 υποστηρίζει πλέον όλες τις σύγχρονες μεθόδους ασφάλειας, ταυτότητας και εξουσιοδότησης του τρέχοντος Kubernetes. Οι άδειες για το τιμόνι καθορίζονται χρησιμοποιώντας αρχείο kubeconfig. Οι διαχειριστές συμπλέγματος μπορούν να περιορίσουν τα δικαιώματα χρήστη σε οποιοδήποτε επίπεδο ευαισθησίας. Οι εκδόσεις εξακολουθούν να αποθηκεύονται στο σύμπλεγμα και η υπόλοιπη λειτουργικότητα του Helm παραμένει ανέπαφη.

Αποθετήρια γραφημάτων

Σε υψηλό επίπεδο, ένα αποθετήριο γραφημάτων είναι ένα μέρος όπου τα γραφήματα μπορούν να αποθηκευτούν και να μοιραστούν. Ο πελάτης Helm συσκευάζει και στέλνει τα γραφήματα στο αποθετήριο. Με απλά λόγια, ένα αποθετήριο γραφημάτων είναι ένας πρωτόγονος διακομιστής HTTP με ένα αρχείο index.yaml και μερικά συσκευασμένα γραφήματα.

Αν και υπάρχουν ορισμένα πλεονεκτήματα στο Charts Repository API που πληροί τις περισσότερες βασικές απαιτήσεις αποθήκευσης, υπάρχουν επίσης μερικά μειονεκτήματα:

  • Τα αποθετήρια γραφημάτων δεν είναι συμβατά με τις περισσότερες εφαρμογές ασφαλείας που απαιτούνται σε περιβάλλον παραγωγής. Η ύπαρξη ενός τυπικού API για έλεγχο ταυτότητας και εξουσιοδότηση είναι εξαιρετικά σημαντική στα σενάρια παραγωγής.
  • Τα εργαλεία προέλευσης του γραφήματος Helm, που χρησιμοποιούνται για την υπογραφή, την επαλήθευση της ακεραιότητας και της προέλευσης ενός γραφήματος, αποτελούν προαιρετικό μέρος της διαδικασίας δημοσίευσης του χάρτη.
  • Σε σενάρια πολλών χρηστών, το ίδιο γράφημα μπορεί να μεταφορτωθεί από άλλο χρήστη, διπλασιάζοντας τον χώρο που απαιτείται για την αποθήκευση του ίδιου περιεχομένου. Έχουν αναπτυχθεί πιο έξυπνα αποθετήρια για την επίλυση αυτού του προβλήματος, αλλά δεν αποτελούν μέρος της επίσημης προδιαγραφής.
  • Η χρήση ενός ενιαίου αρχείου ευρετηρίου για αναζήτηση, αποθήκευση μεταδεδομένων και ανάκτηση γραφημάτων έχει καταστήσει δύσκολη την ανάπτυξη ασφαλών υλοποιήσεων πολλών χρηστών.

Σχέδιο Docker Distribution (γνωστό και ως Docker Registry v2) είναι ο διάδοχος του Docker Registry και ουσιαστικά λειτουργεί ως ένα σύνολο εργαλείων για τη συσκευασία, την αποστολή, την αποθήκευση και την παράδοση εικόνων Docker. Πολλές μεγάλες υπηρεσίες cloud προσφέρουν προϊόντα που βασίζονται στη διανομή. Χάρη σε αυτήν την αυξημένη προσοχή, το έργο Distribution έχει επωφεληθεί από βελτιώσεις ετών, βέλτιστων πρακτικών ασφάλειας και δοκιμών πεδίου που το έχουν καταστήσει έναν από τους πιο επιτυχημένους αφανείς ήρωες του κόσμου του Open Source.

Γνωρίζατε όμως ότι το Distribution Project σχεδιάστηκε για τη διανομή οποιασδήποτε μορφής περιεχομένου, όχι μόνο εικόνων κοντέινερ;

Χάρη στις προσπάθειες Άνοιγμα πρωτοβουλίας κοντέινερ (ή OCI), τα γραφήματα τιμόνι μπορούν να τοποθετηθούν σε οποιαδήποτε περίπτωση διανομής. Προς το παρόν, αυτή η διαδικασία είναι πειραματική. Η υποστήριξη σύνδεσης και άλλες λειτουργίες που απαιτούνται για ένα πλήρες Helm 3 είναι ένα έργο σε εξέλιξη, αλλά είμαστε ενθουσιασμένοι που μαθαίνουμε από τις ανακαλύψεις που έχουν κάνει οι ομάδες OCI και Distribution όλα αυτά τα χρόνια. Και μέσω της καθοδήγησης και της καθοδήγησής τους, μαθαίνουμε πώς είναι να λειτουργείς μια άκρως διαθέσιμη υπηρεσία σε κλίμακα.

Μια πιο λεπτομερής περιγραφή ορισμένων επερχόμενων αλλαγών στα αποθετήρια γραφημάτων Helm είναι διαθέσιμη по ссылке.

Διαχείριση απελευθέρωσης

Στο Helm 3, η κατάσταση εφαρμογής παρακολουθείται μέσα στο σύμπλεγμα από ένα ζεύγος αντικειμένων:

  • απελευθέρωση αντικειμένου - αντιπροσωπεύει ένα παράδειγμα εφαρμογής.
  • μυστική έκδοση έκδοσης - αντιπροσωπεύει την επιθυμητή κατάσταση της εφαρμογής σε μια συγκεκριμένη χρονική στιγμή (για παράδειγμα, την κυκλοφορία μιας νέας έκδοσης).

Πρόκληση helm install δημιουργεί ένα αντικείμενο έκδοσης και μυστικό έκδοσης. Κλήση helm upgrade απαιτεί ένα αντικείμενο απελευθέρωσης (το οποίο μπορεί να αλλάξει) και δημιουργεί ένα νέο μυστικό έκδοσης έκδοσης που περιέχει τις νέες τιμές και μια προετοιμασμένη δήλωση.

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

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

Στο Helm 2, οι αναθεωρήσεις ήταν εξαιρετικά συνεπείς. Κλήση helm install δημιουργήθηκε v1, η επακόλουθη ενημέρωση (αναβάθμιση) - v2 και ούτω καθεξής. Το μυστικό έκδοσης και έκδοσης έχουν συμπτυχθεί σε ένα μεμονωμένο αντικείμενο γνωστό ως αναθεώρηση. Οι αναθεωρήσεις αποθηκεύτηκαν στον ίδιο χώρο ονομάτων με το Tiller, πράγμα που σήμαινε ότι κάθε κυκλοφορία ήταν "παγκόσμια" όσον αφορά τον χώρο ονομάτων. Ως αποτέλεσμα, θα μπορούσε να χρησιμοποιηθεί μόνο μία παρουσία του ονόματος.

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

Μετά την εγκατάλειψη του Tiller, το Helm 3 αποθηκεύει δεδομένα στον ίδιο χώρο ονομάτων με την κυκλοφορία. Αυτή η αλλαγή σάς επιτρέπει να εγκαταστήσετε ένα γράφημα με το ίδιο όνομα έκδοσης σε διαφορετικό χώρο ονομάτων και τα δεδομένα αποθηκεύονται μεταξύ ενημερώσεων συμπλέγματος/επανεκκινήσεων σε κ.λπ. Για παράδειγμα, μπορείτε να εγκαταστήσετε το WordPress στον χώρο ονομάτων "foo" και στη συνέχεια στον χώρο ονομάτων "bar" και και οι δύο εκδόσεις μπορούν να ονομαστούν "wordpress".

Αλλαγές στις εξαρτήσεις γραφημάτων

Συσκευασμένα γραφήματα (με χρήση helm package) για χρήση με Helm 2 μπορεί να εγκατασταθεί με Helm 3, ωστόσο η ροή εργασιών ανάπτυξης γραφήματος έχει αναθεωρηθεί πλήρως, επομένως πρέπει να γίνουν ορισμένες αλλαγές για να συνεχιστεί η ανάπτυξη γραφήματος με το Helm 3. Συγκεκριμένα, το σύστημα διαχείρισης εξαρτήσεων γραφήματος έχει αλλάξει.

Το σύστημα διαχείρισης εξαρτήσεων του γραφήματος έχει μετακινηθεί από requirements.yaml и requirements.lock επί Chart.yaml и Chart.lock. Αυτό σημαίνει ότι τα γραφήματα που χρησιμοποίησαν την εντολή helm dependency, απαιτούν ορισμένες ρυθμίσεις για να λειτουργήσει στο Helm 3.

Ας δούμε ένα παράδειγμα. Ας προσθέσουμε μια εξάρτηση στο γράφημα στο Helm 2 και ας δούμε τι αλλάζει όταν μετακινούμαστε στο Helm 3.

Στο τιμόνι 2 requirements.yaml έμοιαζε έτσι:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Στο Helm 3, η ίδια εξάρτηση θα αντικατοπτρίζεται και στο δικό σας Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Τα γραφήματα εξακολουθούν να λαμβάνονται και να τοποθετούνται στον κατάλογο charts/, άρα υποδιαγράμματα (υποδιαγράμματα), που βρίσκεται στον κατάλογο charts/, θα συνεχίσει να λειτουργεί χωρίς αλλαγές.

Παρουσιάζοντας τα γραφήματα της βιβλιοθήκης

Το Helm 3 υποστηρίζει μια κατηγορία γραφημάτων που ονομάζονται διαγράμματα βιβλιοθήκης (διάγραμμα βιβλιοθήκης). Αυτό το γράφημα χρησιμοποιείται από άλλα γραφήματα, αλλά δεν δημιουργεί τεχνουργήματα κυκλοφορίας από μόνο του. Τα πρότυπα γραφημάτων βιβλιοθήκης μπορούν να δηλώνουν μόνο στοιχεία define. Άλλο περιεχόμενο απλώς αγνοείται. Αυτό επιτρέπει στους χρήστες να επαναχρησιμοποιούν και να μοιράζονται αποσπάσματα κώδικα που μπορούν να χρησιμοποιηθούν σε πολλά γραφήματα, αποφεύγοντας έτσι την αντιγραφή και τηρώντας την αρχή DRY.

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

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

Ποιο είναι το επόμενο;

Το Helm 3.0.0-alpha.1 είναι το θεμέλιο πάνω στο οποίο αρχίζουμε να χτίζουμε μια νέα έκδοση του Helm. Στο άρθρο περιέγραψα μερικά ενδιαφέροντα χαρακτηριστικά του Helm 3. Πολλά από αυτά βρίσκονται ακόμα στα αρχικά στάδια ανάπτυξης και αυτό είναι φυσιολογικό. Ο σκοπός μιας έκδοσης alpha είναι να δοκιμάσει την ιδέα, να συγκεντρώσει σχόλια από τους πρώτους χρήστες και να επιβεβαιώσει τις υποθέσεις μας.

Μόλις κυκλοφορήσει η άλφα έκδοση (θυμηθείτε ότι αυτό είναι έχει ήδη συμβεί - περίπου μετάφρ.), θα αρχίσουμε να δεχόμαστε patches για το Helm 3 από την κοινότητα. Πρέπει να δημιουργήσετε μια ισχυρή βάση που να επιτρέπει την ανάπτυξη και την υιοθέτηση νέων λειτουργιών και στους χρήστες να αισθάνονται ότι συμμετέχουν στη διαδικασία ανοίγοντας εισιτήρια και κάνοντας διορθώσεις.

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

Αν νιώθετε ότι μας έλειψε κάτι, θα θέλαμε να ακούσουμε τις σκέψεις σας!

Λάβετε μέρος στη συζήτηση στο δικό μας Χαλαρά κανάλια:

  • #helm-users για ερωτήσεις και απλή επικοινωνία με την κοινότητα.
  • #helm-dev για να συζητήσετε αιτήματα έλξης, κώδικα και σφάλματα.

Μπορείτε επίσης να συνομιλήσετε στις εβδομαδιαίες δημόσιες κλήσεις προγραμματιστών μας την Πέμπτη στις 19:30 MSK. Οι συναντήσεις είναι αφιερωμένες στη συζήτηση θεμάτων πάνω στα οποία εργάζονται βασικοί προγραμματιστές και η κοινότητα, καθώς και θέματα συζήτησης για την εβδομάδα. Οποιοσδήποτε μπορεί να συμμετάσχει και να λάβει μέρος στη συνάντηση. Διατίθεται σύνδεσμος στο κανάλι Slack #helm-dev.

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

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

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο