Γεια σε όλους! Με λένε Πάβελ Αγκαλέτσκι. Εργάζομαι ως επικεφαλής ομάδας σε μια ομάδα που αναπτύσσει το σύστημα παράδοσης Lamoda. Το 2018, μίλησα στο συνέδριο HighLoad++ και σήμερα θα ήθελα να παρουσιάσω μια μεταγραφή της έκθεσής μου.

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

Ανάπτυξη εφαρμογών σε VM

Ας ξεκινήσουμε με το γεγονός ότι πριν από 3 χρόνια όλα τα συστήματα και οι υπηρεσίες της εταιρείας είχαν αναπτυχθεί σε κανονικούς εικονικούς διακομιστές. Τεχνικά, οργανώθηκε με τέτοιο τρόπο ώστε όλος ο κώδικας για τα συστήματά μας να αποθηκεύεται και να συναρμολογείται χρησιμοποιώντας εργαλεία αυτόματης συναρμολόγησης, χρησιμοποιώντας jenkins. Χρησιμοποιώντας το Ansible, μεταδόθηκε από το σύστημα ελέγχου εκδόσεων μας σε εικονικούς διακομιστές. Επιπλέον, κάθε σύστημα που διέθετε η εταιρεία μας είχε αναπτυχθεί σε τουλάχιστον 2 διακομιστές: ο ένας από αυτούς στο κεφάλι, ο δεύτερος στην ουρά. Αυτά τα δύο συστήματα ήταν απολύτως πανομοιότυπα μεταξύ τους σε όλες τις ρυθμίσεις, την ισχύ, τη διαμόρφωση κ.λπ. Η μόνη διαφορά μεταξύ τους ήταν ότι το head λάμβανε κίνηση χρηστών, ενώ το tail δεν έλαβε ποτέ κίνηση χρηστών.

Σε τι ήταν;

Όταν αναπτύξαμε νέες εκδόσεις της εφαρμογής μας, θέλαμε να διασφαλίσουμε μια απρόσκοπτη διάθεση, δηλαδή, χωρίς αισθητές συνέπειες για τους χρήστες. Αυτό επιτεύχθηκε λόγω του γεγονότος ότι η επόμενη μεταγλωττισμένη έκδοση με χρήση του Ansible κυκλοφόρησε στην ουρά. Εκεί, τα άτομα που συμμετείχαν στην ανάπτυξη μπορούσαν να ελέγξουν και να βεβαιωθούν ότι όλα ήταν εντάξει: όλες οι μετρήσεις, οι ενότητες και οι εφαρμογές λειτουργούσαν. ξεκινούν τα απαραίτητα σενάρια. Μόνο αφού βεβαιώθηκαν ότι όλα ήταν εντάξει, άλλαξε η κίνηση. Άρχισε να πηγαίνει στον διακομιστή που ήταν προηγουμένως ουρά. Και αυτό που προηγουμένως ήταν η κεφαλή παρέμεινε χωρίς κίνηση χρηστών, ενώ είχε ακόμα την προηγούμενη έκδοση της εφαρμογής μας σε αυτό.

Έτσι ήταν απρόσκοπτη για τους χρήστες. Γιατί η εναλλαγή είναι στιγμιαία, αφού απλά αλλάζει τον εξισορροπητή. Μπορείτε πολύ εύκολα να επιστρέψετε στην προηγούμενη έκδοση απλά αλλάζοντας τον εξισορροπητή. Θα μπορούσαμε επίσης να επαληθεύσουμε ότι η εφαρμογή ήταν σε θέση να παράγει ακόμη και πριν λάβει επισκεψιμότητα από χρήστες, κάτι που ήταν αρκετά βολικό.

Τι πλεονεκτήματα είδαμε σε όλο αυτό;

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

Αλλά είδαμε και αρκετές ελλείψεις σε όλο αυτό:

1. Εκτός από το περιβάλλον παραγωγής, το περιβάλλον ανάπτυξης, υπάρχουν και άλλα περιβάλλοντα. Για παράδειγμα, qa και προπαραγωγή. Εκείνη την εποχή είχαμε πολλούς διακομιστές και περίπου 60 υπηρεσίες. Για το λόγο αυτό ήταν απαραίτητο για κάθε υπηρεσία, διατηρήστε την πιο πρόσφατη έκδοση για αυτήν εικονική μηχανή. Επιπλέον, εάν θέλετε να ενημερώσετε τις βιβλιοθήκες ή να εγκαταστήσετε νέες εξαρτήσεις, πρέπει να το κάνετε αυτό σε όλα τα περιβάλλοντα. Χρειάστηκε επίσης να συγχρονίσετε την ώρα που πρόκειται να αναπτύξετε την επόμενη νέα έκδοση της εφαρμογής σας με την ώρα που το devops εκτελεί τις απαραίτητες ρυθμίσεις περιβάλλοντος. Σε αυτήν την περίπτωση, είναι εύκολο να έρθουμε σε μια κατάσταση όπου το περιβάλλον μας θα είναι κάπως διαφορετικό σε όλα τα περιβάλλοντα ταυτόχρονα. Για παράδειγμα, σε ένα περιβάλλον QA θα υπάρχουν κάποιες εκδόσεις βιβλιοθηκών, και σε ένα περιβάλλον παραγωγής θα υπάρχουν διαφορετικές, που θα οδηγήσουν σε προβλήματα.
2. Δυσκολία ενημέρωσης εξαρτήσεων η αίτησή σου. Δεν εξαρτάται από εσάς, αλλά από την άλλη ομάδα. Δηλαδή, από την ομάδα devops που συντηρεί τους διακομιστές. Πρέπει να τους δώσετε μια κατάλληλη εργασία και μια περιγραφή του τι θέλετε να κάνετε.
3. Τότε θέλαμε να χωρίσουμε τα μεγάλα μεγάλα μονόπετρα που είχαμε σε ξεχωριστές μικρές υπηρεσίες, αφού καταλάβαμε ότι θα είναι όλο και περισσότερα. Εκείνη την εποχή, είχαμε ήδη περισσότερα από 100. Για κάθε νέα υπηρεσία, ήταν απαραίτητο να δημιουργηθεί μια ξεχωριστή νέα εικονική μηχανή, η οποία επίσης έπρεπε να συντηρηθεί και να αναπτυχθεί. Επιπλέον, δεν χρειάζεστε ένα αυτοκίνητο, αλλά τουλάχιστον δύο. Σε όλα αυτά προστίθεται το περιβάλλον QA. Αυτό προκαλεί προβλήματα και σας δυσκολεύει να δημιουργήσετε και να εκτελέσετε νέα συστήματα. πολύπλοκη, δαπανηρή και χρονοβόρα διαδικασία.

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

Σκεφτήκαμε για πολύ καιρό ποιο θα μπορούσαμε να πάρουμε. Το γεγονός είναι ότι εκείνη την εποχή αυτή η στοίβα ανάπτυξης σε κανονικούς εικονικούς διακομιστές ήταν κάπως ξεπερασμένη, καθώς δεν είχαν τις πιο πρόσφατες εκδόσεις λειτουργικών συστημάτων. Κάποια στιγμή, υπήρχε ακόμη και το FreeBSD, το οποίο δεν ήταν πολύ βολικό για υποστήριξη. Καταλάβαμε ότι έπρεπε να μεταφερθούμε στο docker το συντομότερο δυνατό. Οι προγραμματιστές μας εξέτασαν την υπάρχουσα εμπειρία τους με διαφορετικές λύσεις και επέλεξαν ένα σύστημα όπως το Nomad.

Μετάβαση στο Nomad

Το Nomad είναι προϊόν της HashiCorp. Είναι επίσης γνωστοί για τις άλλες λύσεις τους:

"Πρόξενος" είναι ένα εργαλείο για την ανακάλυψη υπηρεσιών.

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

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

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

Τι χρειάζεστε για να αναπτύξετε το σύστημά σας στο Nomad;

1. Πρώτα απ 'όλα χρειάζεστε εικόνα αποβάθρας η αίτησή σου. Πρέπει να το δημιουργήσετε και να το τοποθετήσετε στο αποθετήριο εικόνων docker. Στην περίπτωσή μας, αυτό είναι ένα τεχνητό - ένα σύστημα που σας επιτρέπει να ωθήσετε διάφορα τεχνουργήματα διαφορετικών τύπων σε αυτό. Μπορεί να αποθηκεύσει αρχεία, εικόνες docker, πακέτα PHP συνθέτη, πακέτα NPM και ούτω καθεξής.
2. Επίσης απαιτείται αρχείο ρυθμίσεων, το οποίο θα πει στο Nomad τι, πού και σε ποια ποσότητα θέλετε να αναπτύξετε.

Όταν μιλάμε για το Nomad, χρησιμοποιεί τη γλώσσα HCL ως μορφή αρχείου πληροφοριών, που σημαίνει Γλώσσα διαμόρφωσης HashiCorp. Αυτό είναι ένα υπερσύνολο του Yaml που σας επιτρέπει να περιγράψετε την υπηρεσία σας με όρους Nomad.

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

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

Ως εκ τούτου, αποφασίσαμε ότι θα ήταν βολικό για εμάς να αποθηκεύσουμε όλα τα αρχεία ρυθμίσεων για ανάπτυξη σε ένα κοινό αποθετήριο. Με αυτόν τον τρόπο ήταν ορατά: ήταν εύκολο να διατηρηθούν και μπορούσαμε να δούμε τι συστήματα είχαμε. Εάν είναι απαραίτητο, είναι επίσης εύκολο να ενημερώσετε ή να αλλάξετε κάτι. Η προσθήκη ενός νέου συστήματος δεν είναι επίσης δύσκολη - απλά πρέπει να δημιουργήσετε ένα αρχείο διαμόρφωσης μέσα στον νέο κατάλογο. Μέσα σε αυτό υπάρχουν τα ακόλουθα αρχεία: service.hcl, το οποίο περιέχει μια περιγραφή της υπηρεσίας μας, και ορισμένα αρχεία env που επιτρέπουν τη διαμόρφωση αυτής της υπηρεσίας, που αναπτύσσεται στην παραγωγή.

Ωστόσο, ορισμένα από τα συστήματά μας αναπτύσσονται στην παραγωγή όχι σε ένα αντίγραφο, αλλά σε πολλά ταυτόχρονα. Ως εκ τούτου, αποφασίσαμε ότι θα ήταν βολικό για εμάς να αποθηκεύσουμε όχι τις ρυθμίσεις παραμέτρων στην καθαρή τους μορφή, αλλά στην πρότυπή τους μορφή. Και επιλέξαμε jinja 2. Σε αυτή τη μορφή, αποθηκεύουμε τόσο τις ρυθμίσεις παραμέτρων της ίδιας της υπηρεσίας όσο και τα αρχεία env που απαιτούνται για αυτήν.

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

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

Για παράδειγμα, θέλετε να αναπτύξετε την υπηρεσία σας στην προπαραγωγή και την παραγωγή. Ας πούμε ότι στην προπαραγωγή δεν θέλετε να εκτελείτε σενάρια cron, αλλά απλώς θέλετε να δείτε την υπηρεσία σε έναν ξεχωριστό τομέα για να βεβαιωθείτε ότι λειτουργεί. Για όποιον αναπτύσσει την υπηρεσία, η διαδικασία φαίνεται πολύ απλή και διαφανής. Το μόνο που χρειάζεται να κάνετε είναι να εκτελέσετε το αρχείο deploy.sh, να καθορίσετε ποια υπηρεσία θέλετε να αναπτύξετε και σε ποιον στόχο. Για παράδειγμα, θέλετε να αναπτύξετε ένα συγκεκριμένο σύστημα στη Ρωσία, τη Λευκορωσία ή το Καζακστάν. Για να το κάνετε αυτό, απλώς αλλάξτε μία από τις παραμέτρους και θα έχετε το σωστό αρχείο ρυθμίσεων.

Όταν η υπηρεσία Nomad έχει ήδη αναπτυχθεί στο σύμπλεγμα σας, μοιάζει με αυτό.

Πρώτον, χρειάζεστε κάποιο είδος εξισορροπητή έξω, το οποίο θα λαμβάνει όλη την κίνηση των χρηστών. Θα συνεργαστεί με το Consul και θα μάθει από αυτό πού, σε ποιον κόμβο, σε ποια διεύθυνση IP βρίσκεται μια συγκεκριμένη υπηρεσία που αντιστοιχεί σε ένα συγκεκριμένο όνομα τομέα. Οι υπηρεσίες στο Consul προέρχονται από το ίδιο το Nomad. Δεδομένου ότι πρόκειται για προϊόντα της ίδιας εταιρείας, σχετίζονται αρκετά μεταξύ τους. Μπορούμε να πούμε ότι το Nomad out of the box μπορεί να καταχωρήσει όλες τις υπηρεσίες που εκτοξεύτηκαν σε αυτό μέσα στο Consul.

Μόλις το πρόγραμμα εξισορρόπησης φορτίου της διεπαφής σας γνωρίζει σε ποια υπηρεσία να στείλει την κυκλοφορία, το προωθεί στο κατάλληλο κοντέινερ ή σε πολλά κοντέινερ που ταιριάζουν με την εφαρμογή σας. Φυσικά, είναι επίσης απαραίτητο να σκεφτούμε την ασφάλεια. Παρόλο που όλες οι υπηρεσίες εκτελούνται στις ίδιες εικονικές μηχανές σε κοντέινερ, αυτό συνήθως απαιτεί την αποτροπή της δωρεάν πρόσβασης από οποιαδήποτε υπηρεσία σε οποιαδήποτε άλλη. Αυτό το πετύχαμε μέσω της κατάτμησης. Κάθε υπηρεσία κυκλοφόρησε στο δικό της εικονικό δίκτυο, στο οποίο είχαν καθοριστεί κανόνες δρομολόγησης και κανόνες για την άδεια/άρνηση πρόσβασης σε άλλα συστήματα και υπηρεσίες. Θα μπορούσαν να βρίσκονται τόσο μέσα σε αυτό το σύμπλεγμα όσο και έξω από αυτό. Για παράδειγμα, εάν θέλετε να αποτρέψετε τη σύνδεση μιας υπηρεσίας σε μια συγκεκριμένη βάση δεδομένων, αυτό μπορεί να γίνει μέσω τμηματοποίησης σε επίπεδο δικτύου. Δηλαδή, ακόμη και κατά λάθος, δεν μπορείτε να συνδεθείτε κατά λάθος από το περιβάλλον δοκιμής στη βάση δεδομένων παραγωγής σας.

Πόσο μας κόστισε η μετάβαση σε ανθρώπινο δυναμικό;

Η μετάβαση ολόκληρης της εταιρείας στο Nomad κράτησε περίπου 5-6 μήνες. Κινηθήκαμε ανά υπηρεσία, αλλά με αρκετά γρήγορους ρυθμούς. Κάθε ομάδα έπρεπε να δημιουργήσει τα δικά της κοντέινερ για τις υπηρεσίες.

Έχουμε υιοθετήσει μια τέτοια προσέγγιση ώστε κάθε ομάδα να είναι υπεύθυνη για τις εικόνες docker των συστημάτων της ανεξάρτητα. Τα DevOps παρέχουν τη γενική υποδομή που είναι απαραίτητη για την ανάπτυξη, δηλαδή υποστήριξη για το ίδιο το σύμπλεγμα, υποστήριξη για το σύστημα CI και ούτω καθεξής. Και εκείνη την εποχή, μεταφέραμε περισσότερα από 60 συστήματα στο Nomad, τα οποία ανήλθαν σε περίπου 2 χιλιάδες εμπορευματοκιβώτια.

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

Λόγοι εγκατάλειψης του Nomad

Ποια πλεονεκτήματα αποκτήσαμε μεταβαίνοντας στην ανάπτυξη χρησιμοποιώντας το Nomad και το docker, μεταξύ άλλων;

1. Εμείς παρείχε ίσους όρους για όλα τα περιβάλλοντα. Στην ανάπτυξη, περιβάλλον QA, προπαραγωγή, παραγωγή, χρησιμοποιούνται οι ίδιες εικόνες κοντέινερ, με τις ίδιες εξαρτήσεις. Συνεπώς, δεν έχετε σχεδόν καμία πιθανότητα ότι αυτό που θα καταλήξει στην παραγωγή δεν είναι αυτό που δοκιμάσατε προηγουμένως τοπικά ή στο περιβάλλον δοκιμής σας.
2. Βρήκαμε επίσης ότι είναι αρκετό εύκολο να προσθέσετε μια νέα υπηρεσία. Από άποψη ανάπτυξης, κάθε νέο σύστημα ξεκινά πολύ απλά. Απλώς μεταβείτε στο αποθετήριο που αποθηκεύει τις ρυθμίσεις παραμέτρων, προσθέστε μια άλλη διαμόρφωση για το σύστημά σας εκεί και είστε έτοιμοι. Μπορείτε να αναπτύξετε το σύστημά σας στην παραγωγή χωρίς καμία πρόσθετη προσπάθεια από την devops.
3. Όλα αρχεία ρυθμίσεων σε ένα κοινό αποθετήριο αποδείχθηκε ότι ήταν υπό εξέταση. Την εποχή που αναπτύξαμε τα συστήματά μας χρησιμοποιώντας εικονικούς διακομιστές, χρησιμοποιούσαμε το Ansible, στον οποίο οι ρυθμίσεις παραμέτρων βρίσκονταν στο ίδιο αποθετήριο. Ωστόσο, για τους περισσότερους προγραμματιστές ήταν λίγο πιο δύσκολο να το δουλέψουν. Εδώ ο όγκος των ρυθμίσεων και του κώδικα που πρέπει να προσθέσετε για να αναπτύξετε την υπηρεσία έχει γίνει πολύ μικρότερος. Επιπλέον, είναι πολύ εύκολο για τους devop να το διορθώσουν ή να το αλλάξουν. Σε περίπτωση μετάβασης, για παράδειγμα, σε μια νέα έκδοση του Nomad, μπορούν να πάρουν και να ενημερώσουν μαζικά όλα τα λειτουργικά αρχεία που βρίσκονται στο ίδιο μέρος.

Συναντήσαμε όμως και αρκετά μειονεκτήματα:

Αποδείχθηκε ότι εμείς δεν μπόρεσαν να επιτύχουν απρόσκοπτες αναπτύξεις στην περίπτωση του Nomad. Κατά την κυκλοφορία κοντέινερ υπό διαφορετικές συνθήκες, θα μπορούσε να αποδειχθεί ότι λειτουργεί και το Nomad το αντιλήφθηκε ως ένα κοντέινερ έτοιμο να δεχθεί κίνηση. Αυτό συνέβη πριν καν η εφαρμογή μέσα σε αυτήν είχε την ευκαιρία να ξεκινήσει. Για το λόγο αυτό, το σύστημα άρχισε να παράγει 500 σφάλματα για σύντομο χρονικό διάστημα, επειδή η κίνηση άρχισε να πηγαίνει σε ένα κοντέινερ που δεν ήταν ακόμη έτοιμο να το δεχτεί.

Συναντήσαμε μερικά από τους βάλτους. Το πιο σημαντικό σφάλμα είναι ότι το Nomad δεν χειρίζεται πολύ καλά ένα μεγάλο σύμπλεγμα εάν έχετε πολλά συστήματα και κοντέινερ. Όταν θέλετε να βγάλετε έναν από τους διακομιστές που περιλαμβάνονται στο σύμπλεγμα Nomad για συντήρηση, υπάρχει μια αρκετά μεγάλη πιθανότητα το σύμπλεγμα να μην αισθάνεται πολύ καλά και να καταρρεύσει. Ορισμένα κοντέινερ μπορεί, για παράδειγμα, να πέσουν και να μην ανέβουν - αυτό θα σας κοστίσει πολύ αργότερα, εάν όλα τα συστήματα παραγωγής σας βρίσκονται σε ένα σύμπλεγμα που διαχειρίζεται το Nomad.

Έτσι αποφασίσαμε να σκεφτούμε πού να πάμε μετά. Σε εκείνο το σημείο, συνειδητοποιήσαμε πολύ περισσότερο τι θέλαμε να πετύχουμε. Δηλαδή: θέλουμε αξιοπιστία, λίγο περισσότερες λειτουργίες από αυτές που παρέχει το Nomad και ένα πιο ώριμο, πιο σταθερό σύστημα.

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

Μετάβαση στο Kubernetes

Θα σας πω λίγα λόγια για τις βασικές έννοιες των Kubernetes και πώς διαφέρουν από το Nomad.

Πρώτα απ 'όλα, η πιο βασική έννοια στο Kubernetes είναι η έννοια του pod. Τσόφλι είναι μια ομάδα από ένα ή περισσότερα κοντέινερ που λειτουργούν πάντα μαζί. Και λειτουργούν πάντα σαν να είναι αυστηρά σε μια εικονική μηχανή. Είναι προσβάσιμα μεταξύ τους μέσω IP 127.0.0.1 σε διαφορετικές θύρες.

Ας υποθέσουμε ότι έχετε μια εφαρμογή PHP που αποτελείται από nginx και php-fpm - το κλασικό σχήμα. Πιθανότατα, θα θέλετε να διατηρείτε τα δοχεία nginx και php-fpm μαζί ανά πάσα στιγμή. Το Kubernetes σάς επιτρέπει να το πετύχετε αυτό περιγράφοντάς τα ως ένα κοινό pod. Αυτό ακριβώς δεν μπορούσαμε να πετύχουμε με το Nomad.

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

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

Και η τέταρτη βασική έννοια είναι Είσοδος. Αυτή είναι μια υπηρεσία που εκτελείται σε ένα σύμπλεγμα Kubernetes. Λειτουργεί ως εξωτερικός εξισορροπητής φορτίου που αναλαμβάνει όλα τα αιτήματα. Χρησιμοποιώντας το Kubernetes API, το Ingress μπορεί να καθορίσει πού θα σταλούν αυτά τα αιτήματα. Επιπλέον, το κάνει αυτό πολύ ευέλικτα. Μπορείτε να πείτε ότι όλα τα αιτήματα σε αυτόν τον κεντρικό υπολογιστή και τη συγκεκριμένη διεύθυνση URL αποστέλλονται σε αυτήν την υπηρεσία. Και αυτά τα αιτήματα που έρχονται σε αυτόν τον κεντρικό υπολογιστή και σε άλλη διεύθυνση URL αποστέλλονται σε άλλη υπηρεσία.

Το πιο ωραίο από τη σκοπιά κάποιου που αναπτύσσει μια εφαρμογή είναι ότι μπορείτε να τα διαχειριστείτε όλα μόνοι σας. Ρυθμίζοντας τη διαμόρφωση Ingress, μπορείτε να στείλετε όλη την επισκεψιμότητα που έρχεται σε ένα τέτοιο API σε ξεχωριστά κοντέινερ γραμμένα, για παράδειγμα, στο Go. Αλλά αυτή η επισκεψιμότητα, που έρχεται στον ίδιο τομέα, αλλά σε διαφορετική διεύθυνση URL, θα πρέπει να σταλεί σε κοντέινερ γραμμένα σε PHP, όπου υπάρχει πολλή λογική, αλλά δεν είναι πολύ γρήγορα.

Αν συγκρίνουμε όλες αυτές τις έννοιες με το Nomad, μπορούμε να πούμε ότι οι τρεις πρώτες έννοιες είναι όλες μαζί Service. Και το τελευταίο concept απουσιάζει στο ίδιο το Nomad. Χρησιμοποιήσαμε έναν εξωτερικό εξισορροπητή ως έχει: θα μπορούσε να είναι haproxy, nginx, nginx+ και ούτω καθεξής. Στην περίπτωση ενός κύβου, δεν χρειάζεται να εισαγάγετε αυτήν την πρόσθετη έννοια ξεχωριστά. Ωστόσο, αν κοιτάξετε το Ingress εσωτερικά, είναι είτε nginx, haproxy ή traefik, αλλά κάπως ενσωματωμένο στο Kubernetes.

Όλες οι έννοιες που περιέγραψα είναι, στην πραγματικότητα, πόροι που υπάρχουν μέσα σε ένα σύμπλεγμα Kubernetes. Για την περιγραφή τους στον κύβο, χρησιμοποιείται μια μορφή yaml, η οποία είναι πιο ευανάγνωστη και οικεία από τα αρχεία HCL στην περίπτωση του Nomad. Αλλά δομικά περιγράφουν το ίδιο πράγμα στην περίπτωση, για παράδειγμα, του pod. Λένε - θέλω να αναπτύξω τάδε λοβούς εκεί, με τάδε εικόνες, σε τάδε ποσότητες.

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

Βασικές έννοιες στο Helm

Το τιμόνι είναι διαχειριστής πακέτων για την Kubernetes. Είναι πολύ παρόμοιο με το πώς λειτουργούν οι διαχειριστές πακέτων στις γλώσσες προγραμματισμού. Σας επιτρέπουν να αποθηκεύσετε μια υπηρεσία που αποτελείται, για παράδειγμα, από ανάπτυξη nginx, ανάπτυξη php-fpm, config for Ingress, configmaps (αυτή είναι μια οντότητα που σας επιτρέπει να ορίσετε env και άλλες παραμέτρους για το σύστημά σας) με τη μορφή που ονομάζονται διαγράμματα. Ταυτόχρονα Helm τρέχει στην κορυφή του Kubernetes. Δηλαδή, αυτό δεν είναι κάποιο είδος συστήματος που στέκεται στην άκρη, αλλά απλώς μια άλλη υπηρεσία που ξεκίνησε μέσα στον κύβο. Αλληλεπιδράτε μαζί του μέσω του API του μέσω μιας εντολής κονσόλας. Η ευκολία και η ομορφιά του είναι ότι ακόμα κι αν σπάσει το τιμόνι ή το αφαιρέσετε από το σύμπλεγμα, οι υπηρεσίες σας δεν θα εξαφανιστούν, αφού το τιμόνι ουσιαστικά χρησιμεύει μόνο για την εκκίνηση του συστήματος. Η ίδια η Kubernetes είναι τότε υπεύθυνη για την απόδοση και την κατάσταση των υπηρεσιών.

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

Ο Helm προσθέτει μερικές ακόμη έννοιες για εμάς.

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

Αξίες είναι οι μεταβλητές που θέλετε να χρησιμοποιήσετε για να δημιουργήσετε τις ρυθμίσεις σας από πρότυπα.

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

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

Στην πράξη, αποφασίσαμε να κάνουμε τα πράγματα λίγο διαφορετικά από ό,τι κάναμε με το Nomad. Εάν στο Nomad τόσο οι ρυθμίσεις ανάπτυξης όσο και οι n-μεταβλητές που χρειάζονταν για την ανάπτυξη της υπηρεσίας μας ήταν αποθηκευμένες σε ένα αποθετήριο, εδώ αποφασίσαμε να τις χωρίσουμε σε δύο ξεχωριστά αποθετήρια. Το αποθετήριο "deploy" αποθηκεύει μόνο n-μεταβλητές που απαιτούνται για την ανάπτυξη και το αποθετήριο "τιμόνι" αποθηκεύει ρυθμίσεις παραμέτρων ή γραφήματα.

Τι μας έδωσε αυτό;

Παρά το γεγονός ότι δεν αποθηκεύουμε πραγματικά ευαίσθητα δεδομένα στα ίδια τα αρχεία διαμόρφωσης. Για παράδειγμα, κωδικοί πρόσβασης σε βάσεις δεδομένων. Αποθηκεύονται ως μυστικά στο Kubernetes, αλλά παρόλα αυτά, υπάρχουν ακόμα ορισμένα πράγματα στα οποία δεν θέλουμε να δώσουμε σε όλους πρόσβαση. Επομένως, η πρόσβαση στο αποθετήριο "deploy" είναι πιο περιορισμένη και το αποθετήριο "helm" περιέχει απλώς μια περιγραφή της υπηρεσίας. Για το λόγο αυτό, μπορεί να προσπελαστεί με ασφάλεια από ένα ευρύτερο φάσμα ατόμων.

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

Μέσα σε κάθε αποθετήριο, αφήσαμε μια διαίρεση σε ξεχωριστούς καταλόγους για κάθε υπηρεσία. Δηλαδή, μέσα σε κάθε κατάλογο υπάρχουν πρότυπα που σχετίζονται με το αντίστοιχο γράφημα και περιγράφουν τους πόρους που πρέπει να αναπτυχθούν για την εκκίνηση του συστήματός μας. Αφήσαμε μόνο env στο αποθετήριο "deploy". Σε αυτήν την περίπτωση, δεν χρησιμοποιήσαμε πρότυπο χρησιμοποιώντας jinja, επειδή το ίδιο το τιμόνι παρέχει πρότυπο εκτός συσκευασίας - αυτή είναι μια από τις κύριες λειτουργίες του.

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

Ευρήματα

Η υπηρεσία Kubernetes φαίνεται να είναι πιο περίπλοκη από το Nomad.

Εδώ η εξερχόμενη κίνηση έρχεται στο Ingress. Αυτός είναι μόνο ο μπροστινός ελεγκτής, ο οποίος αναλαμβάνει όλα τα αιτήματα και στη συνέχεια τα στέλνει στις υπηρεσίες που αντιστοιχούν στα δεδομένα αιτήματος. Τα καθορίζει με βάση τις ρυθμίσεις παραμέτρων που αποτελούν μέρος της περιγραφής της εφαρμογής σας στο τιμόνι και τις οποίες οι προγραμματιστές ορίζουν μόνοι τους. Η υπηρεσία στέλνει αιτήματα στα pods της, δηλαδή σε συγκεκριμένα κοντέινερ, εξισορροπώντας την εισερχόμενη κίνηση μεταξύ όλων των κοντέινερ που ανήκουν σε αυτήν την υπηρεσία. Και, φυσικά, δεν πρέπει να ξεχνάμε ότι δεν πρέπει να πάμε πουθενά από την ασφάλεια σε επίπεδο δικτύου. Επομένως, η τμηματοποίηση λειτουργεί σε ένα σύμπλεγμα Kubernetes, το οποίο βασίζεται στην προσθήκη ετικετών. Όλες οι υπηρεσίες έχουν συγκεκριμένες ετικέτες στις οποίες συσχετίζονται τα δικαιώματα πρόσβασης των υπηρεσιών σε ορισμένους εξωτερικούς/εσωτερικούς πόρους εντός ή εκτός του συμπλέγματος.

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

Ένα παράδειγμα τέτοιας χρήσης είναι ο Prometheus, ο οποίος εκτελείται μέσα στο σύμπλεγμα Kubernetes. Για να αρχίσει να συλλέγει μετρήσεις από μια συγκεκριμένη υπηρεσία, πρέπει να προσθέσουμε έναν επιπλέον τύπο πόρου, το λεγόμενο service monitor, στην περιγραφή της υπηρεσίας. Ο Prometheus, λόγω του γεγονότος ότι μπορεί να διαβάσει έναν προσαρμοσμένο τύπο πόρων κατά την εκκίνηση στο Kubernetes, ξεκινά αυτόματα τη συλλογή μετρήσεων από το νέο σύστημα. Είναι αρκετά βολικό.

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

Πηγή: www.habr.com