Οι εφαρμογές "Cloud native" ή απλά "cloud" δημιουργούνται ειδικά για να λειτουργούν σε υποδομές cloud. Συνήθως κατασκευάζονται ως ένα σύνολο από χαλαρά συζευγμένες μικροϋπηρεσίες συσκευασμένες σε κοντέινερ, τα οποία με τη σειρά τους διαχειρίζονται από μια πλατφόρμα cloud. Τέτοιες εφαρμογές προετοιμάζονται για βλάβες από προεπιλογή, πράγμα που σημαίνει ότι λειτουργούν αξιόπιστα και κλιμακώνονται ακόμη και σε περίπτωση σοβαρών αστοχιών σε επίπεδο υποδομής. Η άλλη όψη του νομίσματος είναι τα σύνολα περιορισμών (συμβάσεων) που η πλατφόρμα cloud επιβάλλει στις εφαρμογές κοντέινερ για να μπορεί να τις διαχειρίζεται αυτόματα.
Αν και έχουν πλήρη επίγνωση της ανάγκης και της σημασίας της μετάβασης σε εφαρμογές που βασίζονται στο cloud, πολλοί οργανισμοί εξακολουθούν να μην γνωρίζουν από πού να ξεκινήσουν. Σε αυτήν την ανάρτηση, θα εξετάσουμε μια σειρά από αρχές που, εάν ακολουθούνται κατά την ανάπτυξη εφαρμογών με εμπορευματοκιβώτια, θα σας επιτρέψουν να συνειδητοποιήσετε τις δυνατότητες των πλατφορμών cloud και να επιτύχετε αξιόπιστη λειτουργία και κλιμάκωση των εφαρμογών ακόμη και σε περίπτωση σοβαρών αστοχιών στην υποδομή πληροφορικής επίπεδο. Ο απώτερος στόχος των αρχών που περιγράφονται εδώ είναι να μάθετε πώς να δημιουργείτε εφαρμογές που μπορούν να διαχειρίζονται αυτόματα από πλατφόρμες cloud όπως το Kubernetes.
Αρχές σχεδίασης λογισμικού
Στον κόσμο του προγραμματισμού, οι αρχές αναφέρονται σε αρκετά γενικούς κανόνες που πρέπει να τηρούνται κατά την ανάπτυξη λογισμικού. Μπορούν να χρησιμοποιηθούν κατά την εργασία με οποιαδήποτε γλώσσα προγραμματισμού. Κάθε αρχή έχει τους δικούς της στόχους, τα εργαλεία για την επίτευξη των οποίων είναι συνήθως πρότυπα και πρακτικές. Υπάρχουν επίσης ορισμένες θεμελιώδεις αρχές για τη δημιουργία λογισμικού υψηλής ποιότητας, από το οποίο προέρχονται όλα τα άλλα. Ακολουθούν μερικά παραδείγματα θεμελιωδών αρχών:
- (Κρατήστε το απλό, ανόητο) - μην το περιπλέκετε.
- (Μην επαναλαμβάνεσαι) – μην επαναλαμβάνεις τον εαυτό σου.
- (Δεν θα το χρειαστείτε) - μην δημιουργήσετε κάτι που δεν χρειάζεται αμέσως.
- Διαχωρισμός ανησυχιών – επιμερισμός ευθυνών.
Όπως μπορείτε να δείτε, αυτές οι αρχές δεν θέτουν συγκεκριμένους κανόνες, αλλά ανήκουν στην κατηγορία των λεγόμενων σκέψεων κοινής λογικής που βασίζονται στην πρακτική εμπειρία, την οποία μοιράζονται πολλοί προγραμματιστές και στην οποία αναφέρονται τακτικά.
Επιπλέον, υπάρχει – Ένα σύνολο από τις πέντε πρώτες αρχές του αντικειμενοστρεφούς προγραμματισμού και σχεδίασης, που διατυπώθηκαν από τον Robert Martin. Το SOLID περιλαμβάνει ευρείες, ανοιχτού τύπου, συμπληρωματικές αρχές που -όταν εφαρμόζονται από κοινού- βοηθούν στη δημιουργία καλύτερων συστημάτων λογισμικού και στην καλύτερη διατήρησή τους μακροπρόθεσμα.
Οι αρχές SOLID ανήκουν στο πεδίο του OOP και διατυπώνονται στη γλώσσα εννοιών και εννοιών όπως κλάσεις, διεπαφές και κληρονομικότητα. Κατ' αναλογία, οι αρχές ανάπτυξης μπορούν επίσης να διαμορφωθούν για εφαρμογές cloud, μόνο που το βασικό στοιχείο εδώ δεν θα είναι μια κλάση, αλλά ένα κοντέινερ. Ακολουθώντας αυτές τις αρχές, μπορείτε να δημιουργήσετε εφαρμογές με κοντέινερ που ανταποκρίνονται καλύτερα στους στόχους και τους στόχους πλατφορμών cloud όπως το Kubernetes.
Cloud-native containers: η προσέγγιση Red Hat
Σήμερα, σχεδόν κάθε εφαρμογή μπορεί να συσκευαστεί σχετικά εύκολα σε δοχεία. Αλλά για να αυτοματοποιηθούν αποτελεσματικά και να ενορχηστρωθούν οι εφαρμογές σε μια πλατφόρμα cloud όπως το Kubernetes, απαιτείται πρόσθετη προσπάθεια.
Η βάση για τις ιδέες που περιγράφονται παρακάτω ήταν η μεθοδολογία και πολλές άλλες εργασίες σχετικά με διάφορες πτυχές της κατασκευής εφαρμογών Ιστού, από τη διαχείριση πηγαίου κώδικα έως τα μοντέλα κλιμάκωσης. Οι αρχές που περιγράφονται ισχύουν μόνο για την ανάπτυξη εφαρμογών με εμπορευματοκιβώτια που είναι χτισμένες πάνω σε μικροϋπηρεσίες και έχουν σχεδιαστεί για πλατφόρμες cloud όπως η Kubernetes. Το βασικό στοιχείο στη συζήτησή μας είναι η εικόνα του κοντέινερ και ο χρόνος εκτέλεσης του κοντέινερ είναι η πλατφόρμα ενορχήστρωσης κοντέινερ. Ο στόχος των προτεινόμενων αρχών είναι να δημιουργηθούν δοχεία για τα οποία οι εργασίες προγραμματισμού, κλιμάκωσης και παρακολούθησης μπορούν να αυτοματοποιηθούν στις περισσότερες πλατφόρμες ενορχήστρωσης. Οι αρχές δεν παρουσιάζονται με ιδιαίτερη σειρά.
Αρχή Ενιαίας Μέριμνας (SCP)
Αυτή η αρχή είναι από πολλές απόψεις παρόμοια με την Αρχή της Ενιαίας Ευθύνης. ), το οποίο είναι μέρος του συνόλου SOLID και δηλώνει ότι κάθε αντικείμενο πρέπει να έχει μία ευθύνη και ότι η ευθύνη πρέπει να είναι πλήρως ενσωματωμένη σε μια κλάση. Το νόημα του SRP είναι ότι κάθε ευθύνη είναι λόγος αλλαγής και μια τάξη πρέπει να έχει έναν και μόνο λόγο αλλαγής.
Στο SCP, χρησιμοποιούμε τη λέξη «ανησυχία» αντί για τη λέξη «ευθύνη» για να υποδείξουμε το υψηλότερο επίπεδο αφαίρεσης και τον ευρύτερο σκοπό ενός κοντέινερ σε σύγκριση με μια κλάση OOP. Και αν ο στόχος του SRP είναι να έχει μόνο έναν λόγο αλλαγής, τότε πίσω από το SCP βρίσκεται η επιθυμία να επεκταθεί η δυνατότητα επαναχρησιμοποίησης και αντικατάστασης εμπορευματοκιβωτίων. Ακολουθώντας το SRP και δημιουργώντας ένα κοντέινερ που λύνει ένα μεμονωμένο πρόβλημα και το κάνει με λειτουργικά ολοκληρωμένο τρόπο, αυξάνετε τις πιθανότητες επαναχρησιμοποίησης αυτής της εικόνας κοντέινερ σε διαφορετικά περιβάλλοντα εφαρμογής.
Η αρχή SCP δηλώνει ότι κάθε κοντέινερ πρέπει να λύνει ένα μόνο πρόβλημα και να το κάνει καλά. Επιπλέον, το SCP στον κόσμο των εμπορευματοκιβωτίων είναι πιο εύκολο να επιτευχθεί από το SRP στον κόσμο του OOP, καθώς τα κοντέινερ συνήθως εκτελούν μια ενιαία διαδικασία και τις περισσότερες φορές αυτή η διαδικασία επιλύει μια μεμονωμένη εργασία.
Εάν κάποια μικρουπηρεσία κοντέινερ πρέπει να λύσει πολλά προβλήματα ταυτόχρονα, τότε μπορεί να χωριστεί σε κοντέινερ μίας εργασίας και να συνδυαστεί σε ένα pod (μια μονάδα ανάπτυξης πλατφόρμας κοντέινερ) χρησιμοποιώντας πρότυπα πλαισίων και κοντέινερ εκκίνησης. Επιπλέον, το SCP καθιστά εύκολη την αντικατάσταση ενός παλιού κοντέινερ (όπως ένας διακομιστής ιστού ή ένας μεσίτης μηνυμάτων) με ένα νέο που λύνει το ίδιο πρόβλημα αλλά έχει διευρυμένη λειτουργικότητα ή κλιμάκωση καλύτερα.
Αρχή υψηλής παρατηρησιμότητας (HOP)
Όταν τα κοντέινερ χρησιμοποιούνται ως ενοποιημένος τρόπος συσκευασίας και εκτέλεσης εφαρμογών, οι ίδιες οι εφαρμογές αντιμετωπίζονται ως μαύρο κουτί. Ωστόσο, εάν πρόκειται για κοντέινερ cloud, τότε πρέπει να παρέχουν ειδικά API στο χρόνο εκτέλεσης για την παρακολούθηση της υγείας των κοντέινερ και, εάν είναι απαραίτητο, να λάβουν τα κατάλληλα μέτρα. Χωρίς αυτό, δεν θα είναι δυνατή η ενοποίηση της αυτοματοποίησης της ενημέρωσης κοντέινερ και της διαχείρισης του κύκλου ζωής τους, κάτι που, με τη σειρά του, θα επιδεινώσει τη σταθερότητα και τη χρηστικότητα του συστήματος λογισμικού.
Στην πράξη, μια εφαρμογή σε εμπορευματοκιβώτια θα πρέπει, τουλάχιστον, να διαθέτει API για διάφορους τύπους ελέγχων υγείας: τεστ ζωντάνιας και δοκιμές ετοιμότητας. Εάν μια εφαρμογή ισχυρίζεται ότι κάνει περισσότερα, πρέπει να παρέχει άλλα μέσα παρακολούθησης της κατάστασής της. Για παράδειγμα, καταγραφή σημαντικών συμβάντων μέσω STDERR και STDOUT για συνάθροιση αρχείων καταγραφής χρησιμοποιώντας Fluentd, Logstash και άλλα παρόμοια εργαλεία. Καθώς και ενσωμάτωση με βιβλιοθήκες συλλογής ανίχνευσης και μετρήσεων, όπως OpenTracing, Prometheus κ.λπ.
Γενικά, η εφαρμογή μπορεί ακόμα να αντιμετωπίζεται ως μαύρο κουτί, αλλά πρέπει να της παρέχονται όλα τα API που χρειάζεται η πλατφόρμα για να την παρακολουθεί και να τη διαχειρίζεται με τον καλύτερο δυνατό τρόπο.
Αρχή συμμόρφωσης κύκλου ζωής (LCP)
Το LCP είναι το αντίθετο του HOP. Ενώ το HOP δηλώνει ότι το κοντέινερ πρέπει να εκθέτει τα API ανάγνωσης στην πλατφόρμα, το LCP απαιτεί από την εφαρμογή να μπορεί να δέχεται πληροφορίες από την πλατφόρμα. Επιπλέον, το δοχείο όχι μόνο πρέπει να δέχεται γεγονότα, αλλά και να προσαρμόζεται, με άλλα λόγια, να αντιδρά σε αυτά. Εξ ου και το όνομα της αρχής, η οποία μπορεί να θεωρηθεί ως απαίτηση για την παροχή στην πλατφόρμα με API γραφής.
Οι πλατφόρμες έχουν διαφορετικούς τύπους συμβάντων που βοηθούν στη διαχείριση του κύκλου ζωής ενός κοντέινερ. Αλλά εναπόκειται στην ίδια την εφαρμογή να αποφασίσει ποιον από αυτούς θα αντιληφθεί και πώς θα αντιδράσει.
Είναι σαφές ότι ορισμένα γεγονότα είναι πιο σημαντικά από άλλα. Για παράδειγμα, εάν μια εφαρμογή δεν ανέχεται καλά σφάλματα, πρέπει να δέχεται μηνύματα σήμα: τερματίστε (SIGTERM) και να ξεκινήσει τη ρουτίνα τερματισμού της όσο το δυνατόν γρηγορότερα για να πιάσει το σήμα: kill (SIGKILL) που έρχεται μετά το SIGTERM.
Επιπλέον, συμβάντα όπως το PostStart και το PreStop μπορεί να είναι σημαντικά για τον κύκλο ζωής μιας εφαρμογής. Για παράδειγμα, μετά την εκκίνηση μιας εφαρμογής, μπορεί να χρειαστεί λίγος χρόνος προθέρμανσης για να μπορέσει να ανταποκριθεί σε αιτήματα. Ή η εφαρμογή πρέπει να απελευθερώσει πόρους με κάποιον ειδικό τρόπο κατά τον τερματισμό της λειτουργίας.
Η αρχή της αμετάβλητης εικόνας (IIP)
Είναι γενικά αποδεκτό ότι οι εφαρμογές με κοντέινερ θα πρέπει να παραμένουν αμετάβλητες μετά την κατασκευή, ακόμα κι αν εκτελούνται σε διαφορετικά περιβάλλοντα. Αυτό απαιτεί την ανάγκη να εξωτερικεύσουμε την αποθήκευση δεδομένων κατά το χρόνο εκτέλεσης (με άλλα λόγια, να χρησιμοποιήσουμε εξωτερικά εργαλεία για αυτό) και να βασιστούμε σε εξωτερικές, ειδικές για το χρόνο εκτέλεσης διαμορφώσεις, αντί να τροποποιήσουμε ή να δημιουργήσουμε μοναδικά κοντέινερ για κάθε περιβάλλον. Μετά από οποιεσδήποτε αλλαγές στην εφαρμογή, η εικόνα του κοντέινερ πρέπει να ξαναδημιουργηθεί και να αναπτυχθεί σε όλα τα περιβάλλοντα που χρησιμοποιούνται. Παρεμπιπτόντως, κατά τη διαχείριση συστημάτων πληροφορικής, χρησιμοποιείται μια παρόμοια αρχή, γνωστή ως η αρχή της αμετάβλητότητας των διακομιστών και της υποδομής.
Ο στόχος του IIP είναι να αποτρέψει τη δημιουργία ξεχωριστών εικόνων κοντέινερ για διαφορετικά περιβάλλοντα χρόνου εκτέλεσης και να χρησιμοποιήσει την ίδια εικόνα παντού μαζί με την κατάλληλη διαμόρφωση για συγκεκριμένο περιβάλλον. Η τήρηση αυτής της αρχής σάς επιτρέπει να εφαρμόζετε τόσο σημαντικές πρακτικές από την άποψη της αυτοματοποίησης των συστημάτων cloud, όπως η επαναφορά και η επαναφορά των ενημερώσεων εφαρμογών.
Process Disposability Principle (PDP)
Ένα από τα πιο σημαντικά χαρακτηριστικά ενός κοντέινερ είναι το εφήμερό του: ένα παράδειγμα ενός κοντέινερ είναι εύκολο να δημιουργηθεί και να καταστραφεί εύκολα, επομένως μπορεί εύκολα να αντικατασταθεί με ένα άλλο παράδειγμα ανά πάσα στιγμή. Μπορεί να υπάρχουν πολλοί λόγοι για μια τέτοια αντικατάσταση: αποτυχία ενός τεστ λειτουργικότητας, κλιμάκωση της εφαρμογής, μεταφορά σε άλλο κεντρικό υπολογιστή, εξάντληση πόρων πλατφόρμας ή άλλες καταστάσεις.
Κατά συνέπεια, οι εφαρμογές με κοντέινερ πρέπει να διατηρούν την κατάστασή τους χρησιμοποιώντας κάποια εξωτερικά μέσα ή να χρησιμοποιούν εσωτερικά κατανεμημένα σχήματα με πλεονασμό για αυτό. Επιπλέον, η εφαρμογή πρέπει να ξεκινά γρήγορα και να τερματίζεται γρήγορα και να είναι προετοιμασμένη για ξαφνική θανατηφόρα βλάβη υλικού.
Μια πρακτική που βοηθά στην εφαρμογή αυτής της αρχής είναι να διατηρείτε τα δοχεία μικρά. Τα περιβάλλοντα cloud μπορούν να επιλέξουν αυτόματα έναν κεντρικό υπολογιστή στον οποίο θα εκκινήσει μια παρουσία κοντέινερ, επομένως όσο μικρότερο είναι το κοντέινερ, τόσο πιο γρήγορα θα ξεκινήσει - απλώς θα αντιγραφεί στον κεντρικό υπολογιστή-στόχο μέσω του δικτύου πιο γρήγορα.
Αρχή αυτοσυγκράτησης (S-CP)
Σύμφωνα με αυτή την αρχή, στο στάδιο της συναρμολόγησης, όλα τα απαραίτητα εξαρτήματα περιλαμβάνονται στο δοχείο. Το κοντέινερ πρέπει να κατασκευαστεί με την υπόθεση ότι το σύστημα έχει μόνο έναν καθαρό πυρήνα Linux, επομένως όλες οι απαραίτητες πρόσθετες βιβλιοθήκες θα πρέπει να τοποθετηθούν στο ίδιο το κοντέινερ. Θα πρέπει επίσης να περιέχει στοιχεία όπως το χρόνο εκτέλεσης για την αντίστοιχη γλώσσα προγραμματισμού, την πλατφόρμα εφαρμογής (εάν είναι απαραίτητο) και άλλες εξαρτήσεις που θα απαιτηθούν ενώ εκτελείται η εφαρμογή κοντέινερ.
Γίνονται εξαιρέσεις για διαμορφώσεις που διαφέρουν από περιβάλλον σε περιβάλλον και πρέπει να παρέχονται κατά το χρόνο εκτέλεσης, για παράδειγμα μέσω ενός Kubernetes ConfigMap.
Μια εφαρμογή μπορεί να περιλαμβάνει πολλά στοιχεία σε εμπορευματοκιβώτια, για παράδειγμα, ένα ξεχωριστό κοντέινερ DBMS μέσα σε μια εφαρμογή ιστού με κοντέινερ. Σύμφωνα με την αρχή S-CP, αυτά τα κοντέινερ δεν πρέπει να συνδυάζονται σε ένα, αλλά θα πρέπει να γίνονται έτσι ώστε το κοντέινερ DBMS να περιέχει όλα τα απαραίτητα για τη λειτουργία της βάσης δεδομένων και το κοντέινερ της εφαρμογής Ιστού περιέχει όλα τα απαραίτητα για τη λειτουργία του ιστού εφαρμογή, ο ίδιος διακομιστής web . Ως αποτέλεσμα, κατά το χρόνο εκτέλεσης, το κοντέινερ της εφαρμογής Ιστού θα εξαρτάται από το κοντέινερ DBMS και θα έχει πρόσβαση σε αυτό όπως απαιτείται.
Runtime Confinement Principle (RCP)
Η αρχή S-CP καθορίζει πώς πρέπει να κατασκευαστεί το κοντέινερ και τι πρέπει να περιέχει το δυαδικό αρχείο εικόνας. Αλλά ένα κοντέινερ δεν είναι απλώς ένα «μαύρο κουτί» που έχει μόνο ένα χαρακτηριστικό - το μέγεθος αρχείου. Κατά την εκτέλεση, το κοντέινερ παίρνει άλλες διαστάσεις: την ποσότητα της μνήμης που χρησιμοποιείται, τον χρόνο της CPU και άλλους πόρους του συστήματος.
Και εδώ είναι χρήσιμη η αρχή RCP, σύμφωνα με την οποία το κοντέινερ πρέπει να αποκεφαλίσει τις απαιτήσεις του για πόρους συστήματος και να τις μεταφέρει στην πλατφόρμα. Με τα προφίλ πόρων κάθε κοντέινερ (πόσο πόρους CPU, μνήμη, δίκτυο και δίσκου χρειάζεται), η πλατφόρμα μπορεί να εκτελέσει βέλτιστα προγραμματισμό και αυτόματη κλιμάκωση, να διαχειριστεί τη χωρητικότητα IT και να διατηρήσει τα επίπεδα SLA για κοντέινερ.
Εκτός από την ικανοποίηση των απαιτήσεων πόρων του κοντέινερ, είναι επίσης σημαντικό η εφαρμογή να μην υπερβαίνει τα δικά της όρια. Διαφορετικά, όταν παρουσιάζεται έλλειψη πόρων, η πλατφόρμα είναι πιο πιθανό να τον συμπεριλάβει στη λίστα των εφαρμογών που πρέπει να τερματιστούν ή να μετεγκατασταθούν.
Όταν μιλάμε για το να είμαστε πρώτα στο cloud, μιλάμε για τον τρόπο που εργαζόμαστε.
Παραπάνω, διαμορφώσαμε μια σειρά από γενικές αρχές που θέτουν τη μεθοδολογική βάση για τη δημιουργία εφαρμογών κοντέινερ υψηλής ποιότητας για περιβάλλοντα cloud.
Σημειώστε ότι εκτός από αυτές τις γενικές αρχές, θα χρειαστείτε επίσης πρόσθετες προηγμένες μεθόδους και τεχνικές για την εργασία με δοχεία. Επιπλέον, έχουμε μερικές σύντομες συστάσεις που είναι πιο συγκεκριμένες και θα πρέπει να εφαρμόζονται (ή να μην εφαρμόζονται) ανάλογα με την κατάσταση:
- Προσπαθήστε να μειώσετε το μέγεθος των εικόνων: διαγράψτε προσωρινά αρχεία και μην εγκαταστήσετε περιττά πακέτα - όσο μικρότερο είναι το μέγεθος του κοντέινερ, τόσο πιο γρήγορα συναρμολογείται και αντιγράφεται στον κεντρικό υπολογιστή-στόχο μέσω του δικτύου.
- Εστιάστε σε αυθαίρετα User-ID: μην χρησιμοποιείτε την εντολή sudo ή οποιοδήποτε ειδικό userid για την εκκίνηση των κοντέινερ σας.
- Επισήμανση σημαντικών θυρών: Μπορείτε να ορίσετε αριθμούς θυρών κατά το χρόνο εκτέλεσης, αλλά είναι καλύτερο να τους καθορίσετε χρησιμοποιώντας την εντολή EXPOSE - θα διευκολύνει άλλα άτομα και προγράμματα να χρησιμοποιούν τις εικόνες σας.
- Αποθήκευση μόνιμων δεδομένων σε τόμους: Τα δεδομένα που θα πρέπει να παραμείνουν μετά την καταστροφή του κοντέινερ θα πρέπει να εγγραφούν σε τόμους.
- Γράψτε μεταδεδομένα εικόνας: οι ετικέτες, οι ετικέτες και οι σχολιασμοί κάνουν τις εικόνες πιο εύχρηστες - άλλοι προγραμματιστές θα σας ευχαριστήσουν.
- Συγχρονισμός κεντρικού υπολογιστή και εικόνων: Ορισμένες εφαρμογές σε κοντέινερ απαιτούν το συγχρονισμό του κοντέινερ με τον κεντρικό υπολογιστή σε ορισμένα χαρακτηριστικά, όπως η ταυτότητα χρόνου ή μηχανής.
- Συμπερασματικά, μοιραζόμαστε πρότυπα και βέλτιστες πρακτικές που θα σας βοηθήσουν να εφαρμόσετε πιο αποτελεσματικά τις αρχές που αναφέρονται παραπάνω:
11 Ιουνίου στις 11.00:XNUMX
Τι θα μάθετε:
- Immutable Red Hat Enterprise Linux CoreOS
- Πλέγμα υπηρεσίας OpenShift
- Πλαίσιο χειριστή
- Knative πλαίσιο
Πηγή: www.habr.com