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

Είμαστε από την εταιρεία fintech Exness, η οποία αναπτύσσει υπηρεσίες για διαδικτυακές συναλλαγές και προϊόντα fintech για B2B και B2C. Η Ε&Α μας έχει πολλές διαφορετικές ομάδες, το τμήμα ανάπτυξης έχει 100+ υπαλλήλους.

Εκπροσωπούμε την ομάδα που είναι υπεύθυνη για την πλατφόρμα συλλογής και εκτέλεσης κώδικα από τους προγραμματιστές μας. Ειδικότερα, είμαστε υπεύθυνοι για τη συλλογή, την αποθήκευση και την αναφορά μετρήσεων, αρχείων καταγραφής και συμβάντων από εφαρμογές. Αυτήν τη στιγμή λειτουργούμε περίπου τρεις χιλιάδες Docker κοντέινερ σε περιβάλλον παραγωγής, διατηρούμε την αποθήκευση μεγάλων δεδομένων χωρητικότητας 50 TB και παρέχουμε αρχιτεκτονικές λύσεις που βασίζονται στην υποδομή μας: Kubernetes, Rancher και διάφορους δημόσιους παρόχους cloud. 

Το κίνητρό μας

Τι καίει; Κανείς δεν μπορεί να απαντήσει. Πού είναι η εστία; Είναι δύσκολο να το καταλάβεις. Πότε πήρε φωτιά; Μπορείτε να το μάθετε, αλλά όχι αμέσως. 

Γιατί μερικά δοχεία στέκονται ενώ άλλα έχουν πέσει; Ποιο κοντέινερ έφταιγε; Εξάλλου, το εξωτερικό των κοντέινερ είναι το ίδιο, αλλά μέσα το καθένα έχει το δικό του Neo.

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

Πράκτορες

Για να καταλάβουμε τι συμβαίνει μέσα, αποφασίσαμε να τοποθετήσουμε πράκτορες απευθείας σε δοχεία.

Αυτοί οι παράγοντες είναι περιοριστικά προγράμματα που διατηρούν τα δοχεία σε τέτοια κατάσταση ώστε να μην σπάνε το ένα το άλλο. Οι πράκτορες είναι τυποποιημένοι και αυτό επιτρέπει μια τυποποιημένη προσέγγιση για την εξυπηρέτηση των εμπορευματοκιβωτίων. 

Στην περίπτωσή μας, οι πράκτορες πρέπει να παρέχουν αρχεία καταγραφής σε τυπική μορφή, με ετικέτα και με στραγγαλισμό. Θα πρέπει επίσης να μας παρέχουν τυποποιημένες μετρήσεις που είναι επεκτάσιμες από την άποψη της επιχειρηματικής εφαρμογής.

Ως πράκτορες νοούνται επίσης βοηθητικά προγράμματα για λειτουργία και συντήρηση που μπορούν να λειτουργήσουν σε διαφορετικά συστήματα ενορχήστρωσης που υποστηρίζουν διαφορετικές εικόνες (Debian, Alpine, Centos, κ.λπ.).

Τέλος, οι πράκτορες πρέπει να υποστηρίζουν απλό CI/CD που περιλαμβάνει αρχεία Docker. Διαφορετικά, το πλοίο θα καταρρεύσει, επειδή τα εμπορευματοκιβώτια θα αρχίσουν να παραδίδονται κατά μήκος «στραβών» σιδηροτροχιών.

Διαδικασία κατασκευής και στόχευση συσκευής εικόνας

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

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

Πώς το χρησιμοποιούμε; Έχουμε ένα Docker Hub που περιέχει ένα κοντέινερ. Το αντικατοπτρίζουμε μέσα στο σύστημά μας για να απαλλαγούμε από εξωτερικές εξαρτήσεις. Το αποτέλεσμα είναι ένα δοχείο με κίτρινο χρώμα. Δημιουργούμε ένα πρότυπο για να εγκαταστήσουμε όλες τις διανομές και τα σενάρια που χρειαζόμαστε στο κοντέινερ. Μετά από αυτό, συναρμολογούμε μια έτοιμη προς χρήση εικόνα: οι προγραμματιστές βάζουν κώδικα και μερικές από τις δικές τους ειδικές εξαρτήσεις σε αυτόν. 

Τι καλό έχει αυτή η προσέγγιση; 

• Πρώτον, πλήρης έλεγχος έκδοσης των εργαλείων κατασκευής - δόμηση κοντέινερ, σεναρίου και εκδόσεων διανομής. 
• Δεύτερον, έχουμε επιτύχει τυποποίηση: δημιουργούμε πρότυπα, ενδιάμεση και έτοιμη προς χρήση εικόνα με τον ίδιο τρόπο. 
• Τρίτον, τα κοντέινερ μας δίνουν φορητότητα. Σήμερα χρησιμοποιούμε το Gitlab και αύριο θα μεταβούμε στο TeamCity ή στο Jenkins και θα μπορούμε να τρέχουμε τα κοντέινερ μας με τον ίδιο τρόπο. 
• Τέταρτον, ελαχιστοποίηση των εξαρτήσεων. Δεν ήταν τυχαίο που βάλαμε κιτ διανομής στο κοντέινερ, γιατί αυτό μας επιτρέπει να αποφεύγουμε τη λήψη τους από το Διαδίκτυο κάθε φορά. 
• Πέμπτον, η ταχύτητα κατασκευής έχει αυξηθεί - η παρουσία τοπικών αντιγράφων εικόνων σάς επιτρέπει να αποφύγετε τη σπατάλη χρόνου κατά τη λήψη, καθώς υπάρχει μια τοπική εικόνα. 

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

Πώς λειτουργεί η διαδικασία κατασκευής μας

Η συναρμολόγηση εκκινείται με μία εντολή, η διαδικασία εκτελείται στην εικόνα (επισημαίνεται με κόκκινο χρώμα). Ο προγραμματιστής έχει ένα αρχείο Docker (επισημασμένο με κίτρινο χρώμα), το αποδίδουμε, αντικαθιστώντας τις μεταβλητές με τιμές. Και στην πορεία προσθέτουμε κεφαλίδες και υποσέλιδα - αυτοί είναι οι αντιπρόσωποί μας. 

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

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

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

 

Για το ίδιο κοντέινερ παίρνουμε διαφορετικά δέντρα διεργασιών στο Docker και στο Kubernetes:

Το ωφέλιμο φορτίο εκτελείται υπό την επίβλεψη του S6. Δώστε προσοχή στον συλλέκτη και τα συμβάντα - αυτοί είναι οι αντιπρόσωποί μας που είναι υπεύθυνοι για τα αρχεία καταγραφής και τις μετρήσεις. Η Kubernetes δεν τα έχει, αλλά ο Docker τα έχει. Γιατί; 

Αν κοιτάξουμε τις προδιαγραφές του "pod" (εφεξής - Kubernetes pod), θα δούμε ότι το κοντέινερ συμβάντων εκτελείται σε ένα pod, το οποίο έχει ένα ξεχωριστό δοχείο συλλογής που εκτελεί τη λειτουργία συλλογής μετρήσεων και αρχείων καταγραφής. Μπορούμε να χρησιμοποιήσουμε τις δυνατότητες του Kubernetes: εκτέλεση κοντέινερ σε ένα pod, σε μια ενιαία διαδικασία ή/και χώρο δικτύου. Στην πραγματικότητα, εισαγάγετε τους πράκτορες σας και εκτελέστε ορισμένες λειτουργίες. Και αν το ίδιο κοντέινερ εκτοξευτεί στο Docker, θα λάβει όλες τις ίδιες δυνατότητες με την έξοδο, δηλαδή θα μπορεί να παραδώσει αρχεία καταγραφής και μετρήσεις, αφού οι πράκτορες θα εκκινηθούν εσωτερικά. 

Μετρήσεις και αρχεία καταγραφής

Η παράδοση μετρήσεων και αρχείων καταγραφής είναι μια πολύπλοκη εργασία. Υπάρχουν πολλές πτυχές στην απόφασή της.
Η υποδομή δημιουργείται για την εκτέλεση του ωφέλιμου φορτίου και όχι για μαζική παράδοση κορμών. Δηλαδή, αυτή η διαδικασία πρέπει να εκτελείται με ελάχιστες απαιτήσεις πόρων κοντέινερ. Προσπαθούμε να βοηθήσουμε τους προγραμματιστές μας: «Αποκτήστε ένα κοντέινερ Docker Hub, εκτελέστε το και μπορούμε να παραδώσουμε τα αρχεία καταγραφής». 

Η δεύτερη πτυχή είναι ο περιορισμός του όγκου των αρχείων καταγραφής. Εάν σημειωθεί αύξηση του όγκου των αρχείων καταγραφής σε πολλά κοντέινερ (η εφαρμογή εξάγει ένα stack-trace σε έναν βρόχο), το φορτίο στη CPU, στα κανάλια επικοινωνίας και στο σύστημα επεξεργασίας αρχείων καταγραφής αυξάνεται και αυτό επηρεάζει τη λειτουργία του κεντρικού υπολογιστή ως ολόκληρα και άλλα δοχεία στον οικοδεσπότη, τότε μερικές φορές αυτό οδηγεί σε "πτώση" του ξενιστή. 

Η τρίτη πτυχή είναι ότι είναι απαραίτητο να υποστηρίζονται όσο το δυνατόν περισσότερες μέθοδοι συλλογής μετρήσεων εκτός του πλαισίου. Από την ανάγνωση αρχείων και τη δημοσκόπηση του Prometheus-endpoint μέχρι τη χρήση πρωτοκόλλων για συγκεκριμένες εφαρμογές.

Και η τελευταία πτυχή είναι η ελαχιστοποίηση της κατανάλωσης πόρων.

Επιλέξαμε μια λύση Go open-source που ονομάζεται Telegraf. Αυτή είναι μια καθολική σύνδεση που υποστηρίζει περισσότερους από 140 τύπους καναλιών εισόδου (πρόσθετα εισόδου) και 30 τύπους καναλιών εξόδου (πρόσθετα εξόδου). Το έχουμε οριστικοποιήσει και τώρα θα σας πούμε πώς το χρησιμοποιούμε χρησιμοποιώντας το Kubernetes ως παράδειγμα. 

Ας υποθέσουμε ότι ένας προγραμματιστής αναπτύσσει ένα φόρτο εργασίας και το Kubernetes λαμβάνει ένα αίτημα για τη δημιουργία ενός pod. Σε αυτό το σημείο, ένα κοντέινερ που ονομάζεται Συλλέκτης δημιουργείται αυτόματα για κάθε pod (χρησιμοποιούμε mutation webhook). Ο συλλέκτης είναι ο αντιπρόσωπός μας. Στην αρχή, αυτό το κοντέινερ διαμορφώνεται ώστε να λειτουργεί με τον Prometheus και το σύστημα συλλογής κορμών.

• Για να το κάνει αυτό, χρησιμοποιεί σχολιασμούς pod, και ανάλογα με το περιεχόμενό του, δημιουργεί, ας πούμε, ένα τελικό σημείο Prometheus. 
• Βάσει των προδιαγραφών pod και των συγκεκριμένων ρυθμίσεων κοντέινερ, αποφασίζει πώς να παραδώσει αρχεία καταγραφής.

Συλλέγουμε αρχεία καταγραφής μέσω του Docker API: οι προγραμματιστές πρέπει απλώς να τα βάλουν στο stdout ή στο stderr και ο Συλλέτης θα το λύσει. Τα αρχεία καταγραφής συλλέγονται σε κομμάτια με κάποια καθυστέρηση για να αποφευχθεί η πιθανή υπερφόρτωση του κεντρικού υπολογιστή. 

Οι μετρήσεις συλλέγονται σε περιπτώσεις φόρτου εργασίας (διαδικασίες) σε κοντέινερ. Όλα επισημαίνονται με ετικέτα: namespace, under, και ούτω καθεξής, και στη συνέχεια μετατρέπονται σε μορφή Prometheus - και γίνονται διαθέσιμα για συλλογή (εκτός από αρχεία καταγραφής). Στέλνουμε επίσης αρχεία καταγραφής, μετρήσεις και συμβάντα στον Kafka και άλλα:

• Τα αρχεία καταγραφής είναι διαθέσιμα στο Graylog (για οπτική ανάλυση).
• Τα αρχεία καταγραφής, οι μετρήσεις, τα συμβάντα αποστέλλονται στο Clickhouse για μακροπρόθεσμη αποθήκευση.

Όλα λειτουργούν ακριβώς το ίδιο στο AWS, μόνο που αντικαθιστούμε το Graylog με το Kafka με το Cloudwatch. Στέλνουμε τα κούτσουρα εκεί και όλα αποδεικνύονται πολύ βολικά: είναι αμέσως σαφές σε ποιο σύμπλεγμα και κοντέινερ ανήκουν. Το ίδιο ισχύει και για το Google Stackdriver. Δηλαδή, το σχέδιό μας λειτουργεί τόσο on-premise με τον Kafka όσο και στο cloud. 

Εάν δεν έχουμε Kubernetes με pods, το σχέδιο είναι λίγο πιο περίπλοκο, αλλά λειτουργεί με τις ίδιες αρχές.

Οι ίδιες διεργασίες εκτελούνται μέσα στο δοχείο, ενορχηστρώνονται χρησιμοποιώντας το S6. Όλες οι ίδιες διαδικασίες εκτελούνται μέσα στο ίδιο δοχείο.

Ως αποτέλεσμα,

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

• Αναπτύξαμε μια τυποποιημένη προσέγγιση για τη συναρμολόγηση εικόνων και βάσει αυτής αναπτύξαμε πρότυπα CI.
• Οι πράκτορες συλλογής δεδομένων είναι οι επεκτάσεις της Telegraf. Τα δοκιμάσαμε καλά στην παραγωγή.
• Χρησιμοποιούμε το webhook μετάλλαξης για την υλοποίηση κοντέινερ με πράκτορες σε λοβούς. 
• Ενσωματωμένο στο οικοσύστημα Kubernetes/Rancher.
• Μπορούμε να εκτελέσουμε τα ίδια κοντέινερ σε διαφορετικά συστήματα ενορχήστρωσης και να έχουμε το αποτέλεσμα που περιμένουμε.
• Δημιουργήθηκε μια εντελώς δυναμική διαμόρφωση διαχείρισης κοντέινερ. 

Συν-συγγραφέας: Ilya Prudnikov

Πηγή: www.habr.com