Η καλύτερη αρχιτεκτονική με το Docker και τον Kubernetes - μύθος ή πραγματικότητα;

Πώς άλλαξε ο κόσμος της ανάπτυξης λογισμικού στην εποχή των Docker και Kubernetes; Είναι δυνατόν να δημιουργηθεί μια αρχιτεκτονική μια και για πάντα χρησιμοποιώντας αυτές τις τεχνολογίες; Είναι δυνατή η ενοποίηση των διαδικασιών ανάπτυξης και ολοκλήρωσης όταν τα πάντα είναι "συσκευασμένα" σε δοχεία; Ποιες είναι οι απαιτήσεις για τέτοιες αποφάσεις; Ποιους περιορισμούς θέτουν σε λειτουργία; Θα κάνουν τη ζωή των προγραμματιστών ευκολότερη ή, αντίθετα, θα προσθέσουν περιττές επιπλοκές σε αυτό;

Ήρθε η ώρα να ρίξουμε φως σε αυτές τις (και κάποιες άλλες) ερωτήσεις! (Στο κείμενο και στις πρωτότυπες εικόνες.)

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

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

Από την πραγματική ζωή στις ροές εργασίας ανάπτυξης

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

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

Η συνεχής ολοκλήρωση και η παράδοση μοιάζουν με μια εξοικονόμηση ζωής στον κόσμο της ανάπτυξης λογισμικού. Τι μπορεί να είναι πιο απλό από όλα αυτά; Έχετε μια ιδέα, έχετε τον κωδικό, έτσι πηγαίνετε για αυτό! Θα ήταν άψογο, αν όχι για ένα μικρό πρόβλημα - η διαδικασία ολοκλήρωσης και παράδοσης είναι μάλλον δύσκολο να επισημοποιηθεί ξεχωριστά από την τεχνολογία και τις επιχειρηματικές διαδικασίες που είναι συγκεκριμένες για την εταιρεία σας.

Ωστόσο, παρά τη φαινομενική πολυπλοκότητα του έργου, η ζωή συνεχώς ρίχνει σε εξαιρετικές ιδέες που μας φέρνουν (καλά, ο ίδιος σίγουρα) λίγο πιο κοντά στην οικοδόμηση ενός άψογου μηχανισμού που μπορεί να είναι χρήσιμος σχεδόν σε κάθε περίσταση. Το πιο πρόσφατο βήμα για έναν τέτοιο μηχανισμό για εμένα ήταν ο Docker και ο Kubernetes, των οποίων το επίπεδο αφαίρεσης και η ιδεολογική προσέγγιση με έκαναν να σκεφτώ ότι το 80% των ζητημάτων μπορεί τώρα να λυθεί χρησιμοποιώντας πρακτικά τις ίδιες μεθόδους.

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

Τι σημαίνουν όλα αυτά και πώς ακριβώς επιλύει το Docker τα προβλήματα της ροής εργασίας ανάπτυξης; Ας δούμε μια απλή διαδικασία, η οποία είναι επίσης αρκετή για την πλειονότητα των εργασιακών περιβαλλόντων:

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

Δημιουργία περιβάλλοντος ανάπτυξης

Ένα έργο θα πρέπει να περιέχει ένα αρχείο docker-compose.yml, το οποίο μπορεί να σας αποτρέψει από το να σκεφτείτε τι και πώς πρέπει να κάνετε για να εκτελέσετε την εφαρμογή / υπηρεσία στο τοπικό μηχάνημα. Μια απλή εντολή δημιουργίας docker θα πρέπει να ξεκινήσει την εφαρμογή σας με όλες τις εξαρτήσεις της, να συμπληρώσει την βάση δεδομένων με τα φωτιστικά στοιχεία, να φορτώσει τον τοπικό κώδικα μέσα στο κοντέινερ, να ενεργοποιήσει τον εντοπισμό κώδικα για σύνταξη και να αρχίσει να ανταποκρίνεται στην αναμενόμενη θύρα. Ακόμη και κατά τη δημιουργία μιας νέας υπηρεσίας, δεν χρειάζεται να ανησυχείτε για το πώς να ξεκινήσετε, πού να κάνετε αλλαγές ή ποια πλαίσια να χρησιμοποιήσετε. Όλα αυτά πρέπει να περιγράφονται εκ των προτέρων στις τυποποιημένες οδηγίες και να υπαγορεύονται από τα πρότυπα υπηρεσιών για διαφορετικές ρυθμίσεις: frontend, backend και worker.

Αυτοματοποιημένες δοκιμές

Όλα όσα θέλετε να μάθετε για το "μαύρο κουτί" (περισσότερα για το γιατί καλώ το δοχείο αυτό θα ακολουθήσει αργότερα στο κείμενο) είναι ότι όλα είναι καλά μέσα σε αυτό. Ναι ή όχι. 1 ή 0. Έχοντας ένα πεπερασμένο αριθμό εντολών που μπορούν να εκτελεστούν μέσα στο δοχείο και το docker-compose.yml που περιγράφει όλες τις εξαρτήσεις του, μπορείτε εύκολα να αυτοματοποιήσετε και να ενοποιήσετε τις δοκιμές χωρίς να εστιάσετε υπερβολικά στις λεπτομέρειες εφαρμογής.

Για παράδειγμα, όπως αυτό!

Εδώ η δοκιμή σημαίνει όχι μόνο και όχι τόσο δοκιμές μονάδων, αλλά και λειτουργικές δοκιμές, δοκιμές ενσωμάτωσης, δοκιμές (στυλ κώδικα) και επανάληψη, έλεγχος για παρωχημένες εξαρτήσεις, παραβίαση των αδειών χρήσης πακέτων και πολλά άλλα. Το σημείο είναι όλα αυτά πρέπει να εγκλωβίζονται μέσα στην εικόνα Docker σας.

Παράδοση συστημάτων

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

Εδώ είναι ο αλγόριθμος που μου φαίνεται αρκετά αποτελεσματικός στην επίλυση αυτού του προβλήματος:

  1. Συλλέξτε εικόνες από όλα τα Dockerfiles (για παράδειγμα, όπως αυτό)
  2. Χρησιμοποιώντας ένα μετα-έργο, παραδώστε αυτές τις εικόνες στα Kubernetes μέσω API Kube. Η εκκίνηση μιας παράδοσης συνήθως απαιτεί αρκετές παραμέτρους εισόδου:
  • Το τελικό σημείο API του Kube
  • ένα "μυστικό" αντικείμενο που ποικίλει για διαφορετικά περιβάλλοντα (τοπικό / εκθετήριο / στάδιο / παραγωγή)
  • τα ονόματα των συστημάτων που εμφανίζονται και τις ετικέτες των εικόνων Docker για αυτά τα συστήματα (που ελήφθησαν στο προηγούμενο βήμα)
Ως παράδειγμα ενός μετα-έργου που περιλαμβάνει όλα τα συστήματα και τις υπηρεσίες (με άλλα λόγια ένα έργο που περιγράφει τον τρόπο διαμόρφωσης του οικοσυστήματος και τον τρόπο με τον οποίο παραδίδονται οι ενημερώσεις), προτιμώ να χρησιμοποιώ τα εγχειρίδια Ansoft με αυτήν την ενότητα για ενσωμάτωση με το Kube API. Ωστόσο, οι εξελιγμένοι αυτοματισμοί μπορούν να αναφερθούν σε άλλες επιλογές και θα σταθώ αργότερα στις δικές μου επιλογές. Ωστόσο, πρέπει να σκεφτείτε έναν κεντρικό / ενοποιημένο τρόπο διαχείρισης της αρχιτεκτονικής. Έχοντας ένα θα σας επιτρέψει άνετα και ομοιόμορφα να διαχειριστείτε όλες τις υπηρεσίες / συστήματα και να εξουδετερώσετε τυχόν επιπλοκές που μπορεί να σας ρίξει η επερχόμενη ζούγκλα τεχνολογιών και συστημάτων που εκτελούν παρόμοιες λειτουργίες.

Συνήθως απαιτείται εγκατάσταση του περιβάλλοντος σε:

  • "ShowRoom" - για μερικούς χειροκίνητους ελέγχους ή εντοπισμό σφαλμάτων του συστήματος
  • "Σταδιοποίηση" - για σχεδόν ζωντανά περιβάλλοντα και ενοποιήσεις με εξωτερικά συστήματα (συνήθως βρίσκονται στο DMZ σε αντίθεση με το ShowRoom)
  • "Παραγωγή" - το πραγματικό περιβάλλον για τον τελικό χρήστη

Συνέχεια στην ολοκλήρωση και την παράδοση

Εάν έχετε έναν ενοποιημένο τρόπο δοκιμής εικόνων Docker - ή "μαύρων κουτιών" - μπορείτε να υποθέσετε ότι τα αποτελέσματα τέτοιων δοκιμών θα σας επιτρέψουν την ομαλή (και με καθαρή συνείδηση) να ενσωματώσετε το χαρακτηριστικό κλάδο στους ανάντη ή κύριους κλάδους του git σας αποθήκη.

Ίσως, ο μόνος διακόπτης της συμφωνίας εδώ είναι η ακολουθία της ολοκλήρωσης και της παράδοσης. Όταν δεν υπάρχουν κυκλοφορίες, πώς εμποδίζετε μια "κούρσα" σε ένα σύστημα με ένα σύνολο παράλληλων χαρακτηριστικών κλάδων;

Επομένως, αυτή η διαδικασία πρέπει να ξεκινήσει μόνο όταν δεν υπάρχει ανταγωνισμός, αλλιώς η "κατάσταση του αγώνα" θα συνεχίσει να στοιχειώνει το μυαλό σας:

  1. Προσπαθήστε να ενημερώσετε το κλάδο λειτουργιών προς τα ανάντη (git rebase / merge)
  2. Δημιουργία εικόνων από τα Dockerfiles
  3. Δοκιμάστε όλες τις ενσωματωμένες εικόνες
  4. Ξεκινήστε και περιμένετε έως ότου παραδοθούν τα συστήματα με τις εικόνες από το βήμα 2
  5. Εάν το προηγούμενο βήμα απέτυχε, επαναφέρετε το οικοσύστημα στην προηγούμενη κατάσταση
  6. Συγκεντρώστε το χαρακτηριστικό-υποκατάστημα inupstream και στείλτε το στο αποθετήριο

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

Μπορείτε να χρησιμοποιήσετε αυτήν τη διαδικασία για να εργαστείτε με περισσότερα από ένα αποθετήρια. Απλά κάντε κάθε βήμα για όλα τα αποθετήρια ταυτόχρονα (βήμα 1 για repos Α και Β, βήμα 2 για repos Α και Β κ.ο.κ.), αντί να κάνετε ολόκληρη τη διαδικασία επανειλημμένα για κάθε μεμονωμένο αποθετήριο (βήματα 1-6 για repo A , τα βήματα 1-6 για repo B κ.λπ.).

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

Συστήματα ανακύκλωσης

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

  • Μια υπηρεσία θα πρέπει να είναι σε θέση να ρυθμίσει το περιβάλλον της, καθώς και αλλαγές στο rollback. Για παράδειγμα, μετανάστευση βάσεων δεδομένων, σχήμα RabbitMQ και ούτω καθεξής.
  • Αν δεν είναι δυνατή η επαναφορά του περιβάλλοντος, η υπηρεσία πρέπει να είναι πολυμορφική και να υποστηρίζει τόσο την παλιά όσο και τη νέα έκδοση του κώδικα. Για παράδειγμα: οι μετακινήσεις βάσεων δεδομένων δεν πρέπει να διαταράσσουν τις παλιές εκδόσεις της υπηρεσίας (συνήθως 2 ή 3 προηγούμενες εκδόσεις)
  • Επιστροφή στη συμβατότητα οποιασδήποτε ενημέρωσης υπηρεσίας. Συνήθως, αυτό είναι συμβατότητα API, μορφές μηνυμάτων και ούτω καθεξής.
Είναι αρκετά απλό να καταργηθούν οι καταστάσεις σε ένα σύμπλεγμα Kubernetes (εκτελέστε την ανάπτυξη του kubectl ανακαλέσει την ανάπτυξη / κάποια ανάπτυξη και Kubernetes θα επαναφέρει το προηγούμενο "στιγμιότυπο"), αλλά για να λειτουργήσει αυτό, το μετα-έργο σας θα πρέπει να περιέχει πληροφορίες σχετικά με αυτό το στιγμιότυπο. Οι πιο περίπλοκοι αλγόριθμοι επαναφοράς των αποδόσεων αποθαρρύνονται, αν και μερικές φορές είναι απαραίτητοι.

Εδώ μπορείτε να ενεργοποιήσετε τον μηχανισμό επαναφοράς:

  • Υψηλό ποσοστό σφαλμάτων εφαρμογής μετά την απελευθέρωση
  • Σήματα από τα βασικά σημεία παρακολούθησης
  • Αποτυχημένες δοκιμές καπνού
  • Χειροκίνητη λειτουργία - ανθρώπινος παράγοντας

Εξασφάλιση της ασφάλειας και του ελέγχου των πληροφοριών

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

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

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

Από τις ροές εργασιών ανάπτυξης έως την αρχιτεκτονική

Πρέπει να ληφθεί σοβαρά υπόψη η προσπάθεια οικοδόμησης στενής ολοκλήρωσης μεταξύ των ροών εργασίας ανάπτυξης και του οικοσυστήματος. Η προσθήκη μιας απαίτησης για μια τέτοια ενσωμάτωση στο παραδοσιακό σύνολο απαιτήσεων σε μια αρχιτεκτονική (ευελιξία, κλιμάκωση, διαθεσιμότητα, αξιοπιστία, προστασία από απειλές κλπ.) Μπορεί να αυξήσει σημαντικά την αξία του αρχιτεκτονικού πλαισίου σας. Είναι τόσο κρίσιμη μια πτυχή που έχει οδηγήσει στην εμφάνιση μιας έννοιας "DevOps" (Ανάπτυξη Λειτουργίας), η οποία είναι ένα λογικό βήμα προς την ολική αυτοματοποίηση και βελτιστοποίηση της υποδομής. Ωστόσο, με μια καλά σχεδιασμένη αρχιτεκτονική και αξιόπιστα υποσυστήματα, οι εργασίες DevOps μπορούν να ελαχιστοποιηθούν.

Αρχιτεκτονική μικρο-υπηρεσιών

Δεν χρειάζεται να βρεθούν λεπτομέρειες για τα οφέλη μιας αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες - SOA, συμπεριλαμβανομένου του γιατί οι υπηρεσίες θα πρέπει να είναι "μικρο". Θα σας πω μόνο ότι αν αποφασίσετε να χρησιμοποιήσετε το Docker και τον Kubernetes, τότε κατά πάσα πιθανότητα καταλαβαίνετε (και αποδέχεστε) ότι είναι δύσκολο και ακόμη ιδεολογικά λάθος να έχετε μια μονολιθική αρχιτεκτονική. Σχεδιασμένο για να διεξάγει μια ενιαία διαδικασία και να εργάζεται με επιμονή, το Docker μας αναγκάζει να σκεφτούμε μέσα στο πλαίσιο του DDD (Domain-Driven Development). Στο Docker, ο συσκευασμένος κώδικας αντιμετωπίζεται ως ένα μαύρο κουτί με ορισμένες εκτεθειμένες θύρες.

Κρίσιμα στοιχεία και λύσεις του οικοσυστήματος

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

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

Υπηρεσία ταυτότητας

Ως συνήθως, όλα ξεκινούν με πρόσβαση - σε διακομιστές, εικονικές μηχανές, εφαρμογές, ταχυδρομείο γραφείου και ούτω καθεξής. Εάν είστε ή θέλετε να είστε πελάτης μιας από τις μεγαλύτερες πλατφόρμες επιχειρήσεων (IBM, Google, Microsoft), το ζήτημα πρόσβασης θα αντιμετωπιστεί από μία από τις υπηρεσίες του πωλητή. Ωστόσο, εάν θέλετε να έχετε τη δική σας λύση, η διαχείριση γίνεται μόνο από εσάς και μέσα στον προϋπολογισμό σας;

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

Αυτόματη παροχή υπηρεσιών

Παρόλο που ο Kubernetes απαιτεί να έχει μόνο χούφτα εξαρτήματα σε φυσικά μηχανήματα / cloud VM (docker, kubelet, kube proxy, cluster κλπ), θα πρέπει να αυτοματοποιήσετε την προσθήκη νέων μηχανών και διαχείρισης συμπλεγμάτων. Εδώ είναι μερικοί απλοί τρόποι να το κάνετε:

  • KOPS - αυτό το εργαλείο σάς επιτρέπει να εγκαταστήσετε ένα σύμπλεγμα σε έναν από τους δύο προμηθευτές νέφους - AWS ή GCE
  • Teraform - αυτό σας επιτρέπει να διαχειριστείτε την υποδομή για οποιοδήποτε περιβάλλον και ακολουθείτε την ιδεολογία του IAC (Infrastructure as Code)
  • Ανούσιο - ευέλικτο εργαλείο για αυτοματοποίηση οποιουδήποτε είδους
Προσωπικά, προτιμώ την τρίτη επιλογή (με μια μικρή μονάδα ολοκλήρωσης Kubernetes), καθώς μου επιτρέπει να δουλεύω με διακομιστές και αντικείμενα k8s και να πραγματοποιώ οποιοδήποτε είδος αυτοματισμού. Ωστόσο, τίποτα δεν σας εμποδίζει να χρησιμοποιήσετε το Teraform και την μονάδα Kubernetes. Το KOPS δεν λειτουργεί καλά με το "γυμνό μέταλλο", αλλά εξακολουθεί να είναι ένα εξαιρετικό εργαλείο για χρήση με το AWS / GCE!

Git αποθετήριο και μια παρακολούθηση εργασιών

Περιττό να πούμε ότι για να εξασφαλιστεί η πλήρης εργασία των προγραμματιστών και άλλων σχετικών ρόλων, πρέπει να έχετε ένα μέρος για συζητήσεις ομαδικής εργασίας και αποθήκευσης κώδικα. Θα ήμουν δύσκολο να προσδιορίσω ποια υπηρεσία είναι η καλύτερη για αυτό, αλλά το προσωπικό μου χρυσό πρότυπο για την παρακολούθηση εργασιών είναι το redmine (δωρεάν) ή το Jira (πληρωμένο), και για το αποθετήριο κώδικα - το "παλιό σχολείο" [gerrit] ( https://www.gerritcodereview.com/) (δωρεάν) ή bitbucket (πληρωμή).

Αξίζει να δοθεί προσοχή στις δύο πιο συνεπείς (αν και εμπορικές) στοίβες για συνεργατική εργασία σε ένα εταιρικό περιβάλλον: Atlassian και Jetbrains. Μπορείτε να χρησιμοποιήσετε οποιαδήποτε από αυτές μια αυτόνομη λύση ή να συνδυάσετε διάφορα στοιχεία και των δύο.

Για να αξιοποιήσετε στο έπακρο ένα συνδυασμό ενός tracker και ενός αποθετηρίου, σκεφτείτε τη στρατηγική ενσωμάτωσής τους. Για παράδειγμα, μερικές συμβουλές για την εξασφάλιση της ακεραιότητας του κώδικα και των συναφών εργασιών (φυσικά μπορείτε να επιλέξετε τη δική σας προσέγγιση):

  • Η δυνατότητα "ώθησης" σε ένα απομακρυσμένο αποθετήριο θα πρέπει να ενεργοποιείται μόνο εάν ένα υποκατάστημα στο οποίο κάποιος προσπαθεί να πιέσει έχει τον αντίστοιχο αριθμό εργασίας (TASK-1 / feature-34)
  • Οποιοδήποτε υποκατάστημα πρέπει να είναι διαθέσιμο για συγχώνευση μόνο μετά από έναν ορισμένο αριθμό θετικών επανεξετάσεων κώδικα
  • Οποιοδήποτε υποκατάστημα πρέπει να αποκλειστεί και να απενεργοποιηθεί για μελλοντικές ενημερώσεις, εάν η αντίστοιχη εργασία δεν είναι "σε εξέλιξη" ή παρόμοια κατάσταση
  • Τα βήματα που προορίζονται για αυτοματοποίηση δεν πρέπει να είναι άμεσα διαθέσιμα στους προγραμματιστές
  • Μόνο εξουσιοδοτημένοι προγραμματιστές πρέπει να είναι σε θέση να τροποποιήσουν άμεσα τον κύριο κλάδο - οτιδήποτε άλλο ελέγχεται από ένα ρομπότ αυτοματισμού
  • Ένα υποκατάστημα δεν θα πρέπει να είναι διαθέσιμο για συγχώνευση εάν η αντίστοιχη εργασία είναι σε οποιαδήποτε κατάσταση διαφορετική από την "For Delivery" ή παρόμοια

Μητρώο Docker

Ιδιαίτερη προσοχή πρέπει να δοθεί σε ένα σύστημα διαχείρισης εικόνας Docker, καθώς είναι εξαιρετικά σημαντικό για την αποθήκευση και την παροχή υπηρεσιών. Επιπλέον, αυτό το σύστημα πρέπει να υποστηρίζει την πρόσβαση για χρήστες και ομάδες χρηστών, να μπορεί να διαγράφει παλιές και περιττές εικόνες, να παρέχει ένα GUI και ένα RESTful API.

Μπορείτε να χρησιμοποιήσετε μια λύση cloud (για παράδειγμα, hub.docker.com) ή μια ιδιωτικά φιλοξενούμενη υπηρεσία, η οποία μπορεί να εγκατασταθεί ακόμη και μέσα στο σύμπλεγμα σας Kubernetes. Το Vmware Harbor, τοποθετημένο ως εταιρική λύση για το Docker Registry, αποτελεί καλό παράδειγμα του τελευταίου. Χειρότερη περίπτωση, μπορείτε να χρησιμοποιήσετε ακόμη και το καλό παλιό μητρώο Docker εάν απλά θέλετε να αποθηκεύσετε εικόνες και δεν χρειάζεστε σε ένα πολύπλοκο σύστημα.

CI / CD και σύστημα παροχής υπηρεσιών

Κανένα από τα στοιχεία που συζητήσαμε νωρίτερα (git repo, task tracker, meta project με Ansible Playbooks, εξωτερικές εξαρτήσεις) μπορεί να λειτουργεί ξεχωριστά το ένα ως προς το άλλο, σαν να αναστέλλεται σε κενό. Αυτό που τους συνδέει είναι η συνεχής υπηρεσία ολοκλήρωσης και παράδοσης.

CI - συνεχές CD ενσωμάτωσης - συνεχής παράδοση

Η υπηρεσία πρέπει να είναι αρκετά απλή και να στερείται οποιασδήποτε λογικής σχετικής με την παράδοση ή διαμόρφωση των συστημάτων. Το μόνο που πρέπει να κάνει μια υπηρεσία CI / CD είναι να αντιδρά σε γεγονότα από τον έξω κόσμο (αλλαγές στο χώρο αποθήκευσης git, μετακίνηση εργασιών γύρω από τον εντοπισμό εργασιών) και να ξεκινήσει τις ενέργειες που περιγράφονται στο έργο meta. Επιπλέον, το servicecis σημείο ελέγχου όλων των αποθετηρίων και ένα εργαλείο για τη διαχείριση τους (συγχώνευση υποκαταστήματος, ενημερώσεις από upstream / master).

Έχω χρησιμοποιήσει ιστορικά ένα αρκετά ισχυρό αλλά πολύ απλό εργαλείο από το Jetbrains - TeamCity, αλλά δεν βλέπω κανένα πρόβλημα εάν αποφασίσετε να δοκιμάσετε κάτι άλλο, για παράδειγμα, το ελεύθερο Jenkins.

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

  • Αυτόματη δοκιμή υπηρεσίας - τυπικά, για ένα μοναδικό αποθετήριο, όταν έχει αλλάξει μια κατάσταση κλάδου ή όταν η κατάσταση έχει αλλάξει σε "Περιμένοντας τις αυτόματες δοκιμές" (ή παρόμοιες)
  • Παράδοση υπηρεσιών - συνήθως, από ένα μετα-έργο και για μια σειρά υπηρεσιών (αριθμός χώρων αποθήκευσης, αντίστοιχα), όταν η κατάσταση έχει αλλάξει σε "Αναμονή για Showroom" ή "Αναμονή παράδοσης" για QA και ανάπτυξη περιβάλλοντος παραγωγής
  • Ανακύκλωση - κατά κανόνα, από ένα μετα-έργο και για ένα συγκεκριμένο τμήμα μίας υπηρεσίας ή μιας ολόκληρης υπηρεσίας, που ενεργοποιείται από ένα εξωτερικό γεγονός ή σε περίπτωση ανεπιτυχής παράδοσης
  • Αφαίρεση υπηρεσίας - αυτό είναι απαραίτητο για την πλήρη απομάκρυνση ολόκληρου του οικοσυστήματος από ένα περιβάλλον δοκιμής (showroom), όταν η κατάσταση In QA έχει λήξει ή το περιβάλλον δεν χρειάζεται πλέον
  • Ο δημιουργός εικόνων (η βοηθητική διαδικασία) - μπορεί να ενσωματωθεί στη διαδικασία παροχής υπηρεσιών ή να χρησιμοποιηθεί ανεξάρτητα για να μεταγλωττίσει τις εικόνες Docker και να τις στείλει στο Docker Registry. Συχνά χειρίζεται εικόνες που χρησιμοποιούνται ευρέως (DB, γενικές υπηρεσίες ή υπηρεσίες που δεν απαιτούν συχνές αλλαγές)

Σύστημα συλλογής και ανάλυσης αρχείων καταγραφής

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

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

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

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

Σύστημα ανίχνευσης

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

Η Opentracing και η Zipkin αντιμετωπίζουν αυτό το καθήκον για τις περισσότερες σύγχρονες γλώσσες προγραμματισμού και χωρίς να προσθέτουν επιπλέον βάρος μετά την οργάνωση του κώδικα. Φυσικά, όλα τα δεδομένα που συλλέγονται πρέπει να αποθηκεύονται σε κατάλληλο μέρος, το οποίο χρησιμοποιείται ως ένα από τα συστατικά.

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

Παρακολούθηση και προειδοποίηση

Ο Prometheus έχει γίνει το de facto πρότυπο στα σύγχρονα συστήματα και, το πιο σημαντικό, υποστηρίζεται σε Kubernetes σχεδόν έξω από το κουτί. Μπορείτε να ανατρέξετε στην επίσημη τεκμηρίωση του Kubernetes για να μάθετε περισσότερα σχετικά με την παρακολούθηση και την προειδοποίηση.

Η παρακολούθηση είναι ένα από τα λίγα βοηθητικά συστήματα που πρέπει να εγκατασταθούν μέσα σε ένα σύμπλεγμα. Και το σύμπλεγμα είναι μια οντότητα που υπόκειται σε παρακολούθηση. Αλλά η παρακολούθηση ενός συστήματος παρακολούθησης (χάρη στην ταυτολογία) μπορεί να πραγματοποιηθεί μόνο από το εξωτερικό (για παράδειγμα, από το ίδιο περιβάλλον "στάσης"). Σε αυτή την περίπτωση, ο διασταυρούμενος έλεγχος είναι χρήσιμος ως βολική λύση για οποιοδήποτε κατανεμημένο περιβάλλον, το οποίο δεν θα περιπλέξει την αρχιτεκτονική του πολύ ενοποιημένου οικοσυστήματος σας.

Το σύνολο της παρακολούθησης χωρίζεται σε τρία απολύτως λογικά απομονωμένα επίπεδα. Εδώ πιστεύω ότι είναι τα πιο σημαντικά παραδείγματα σημείων παρακολούθησης σε κάθε επίπεδο:

  • Φυσικό επίπεδο: - Πόροι δικτύου και διαθεσιμότητα τους - Δίσκοι (i / o, διαθέσιμος χώρος) - Βασικοί πόροι των μεμονωμένων κόμβων (CPU, RAM, LA)
  • Επίπεδο συμπλέγματος: - Διαθεσιμότητα των κύριων συστημάτων συμπλέγματος σε κάθε κόμβο (kubelet, kubeAPI, DNS κ.λπ. κ.λπ.) - Ο αριθμός των ελεύθερων πόρων και η ομοιόμορφη κατανομή τους - Παρακολούθηση της επιτρεπόμενης και πραγματικής κατανάλωσης πόρων από τις υπηρεσίες - Επαναφόρτωση λοβούς
  • Επίπεδο υπηρεσίας: - Οποιοδήποτε είδος παρακολούθησης εφαρμογών - Από το περιεχόμενο της βάσης δεδομένων σε μια συχνότητα κλήσεων API - Αριθμός σφαλμάτων HTTP στην πύλη API - Μέγεθος των ουρών και η χρήση των εργαζομένων - Πολλαπλές μετρήσεις για τη βάση δεδομένων (καθυστέρηση αναπαραγωγής, χρόνος και αριθμός συναλλαγών, αργές αιτήσεις και άλλα) - Ανάλυση σφαλμάτων για μη-HTTP διαδικασίες - Παρακολούθηση των αιτημάτων που αποστέλλονται στο σύστημα καταγραφής (μπορείτε να μετατρέψετε τυχόν αιτήματα σε μετρήσεις)

Όσον αφορά τις ειδοποιήσεις ειδοποιήσεων σε κάθε επίπεδο, θα ήθελα να συστήσω τη χρήση μιας από τις αμέτρητες εξωτερικές υπηρεσίες που μπορούν να στέλνουν ειδοποιήσεις σε μηνύματα ηλεκτρονικού ταχυδρομείου, SMS ή να πραγματοποιούν κλήσεις σε έναν αριθμό κινητού τηλεφώνου. Θα αναφερθώ επίσης σε ένα άλλο σύστημα - το OpsGenie - το οποίο έχει στενή συνεργασία με τον υπεύθυνο προειδοποίησης του Προμηθέα.

Το OpsGenie είναι ένα ευέλικτο εργαλείο για την ειδοποίηση, το οποίο βοηθά στην αντιμετώπιση κλιμάκωσης, καθυστερημένου χρόνου, επιλογής καναλιού ειδοποίησης και πολλά άλλα. Είναι επίσης εύκολο να διανέμετε ειδοποιήσεις μεταξύ των ομάδων. Για παράδειγμα, διαφορετικά επίπεδα παρακολούθησης θα πρέπει να αποστέλλουν ειδοποιήσεις σε διαφορετικές ομάδες / τμήματα: φυσικά - Infra + Devops, cluster - Devops, εφαρμογές - κάθε μία σε μια σχετική ομάδα.

API gateway και Single Sign-on

Για να χειριστείτε εργασίες όπως εξουσιοδότηση, έλεγχο ταυτότητας, εγγραφή χρηστών (εξωτερικοί χρήστες-πελάτες της εταιρείας) και άλλα είδη ελέγχου πρόσβασης, θα χρειαστείτε μια εξαιρετικά αξιόπιστη υπηρεσία που μπορεί να διατηρήσει μια ευέλικτη ενσωμάτωση με την πύλη API σας. Δεν υπάρχει κακή χρήση της ίδιας λύσης όπως για την υπηρεσία "Ταυτότητα", ωστόσο μπορεί να θέλετε να διαχωρίσετε τους δύο πόρους για να επιτύχετε διαφορετικό επίπεδο διαθεσιμότητας και αξιοπιστίας.

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

Ας εξετάσουμε τον καταλληλότερο τρόπο ενσωμάτωσης με την πύλη API, επομένως με όλα τα μάρκες οικοσυστήματός σας. Αυτή η μέθοδος είναι καλή και για τα τρία σενάρια πρόσβασης: από το UI, από την υπηρεσία μέχρι την υπηρεσία, και από ένα εξωτερικό σύστημα. Στη συνέχεια, το καθήκον λήψης ενός κουπονιού (με βάση τον κωδικό πρόσβασης και τον κωδικό πρόσβασης) ανήκει στον ίδιο τον χρήστη ή στον υπεύθυνο ανάπτυξης υπηρεσιών. Έχει επίσης νόημα να γίνει διάκριση μεταξύ της διάρκειας ζωής των μαρκών που χρησιμοποιούνται στο UI (συντομότερο TTL) και σε άλλες περιπτώσεις (μακρύτερο και προσαρμοσμένο TTL).

Ακολουθούν ορισμένα από τα προβλήματα που επιλύει η πύλη API:

  • Πρόσβαση στις υπηρεσίες του οικοσυστήματος από έξω και εντός (οι υπηρεσίες δεν επικοινωνούν άμεσα μεταξύ τους)
  • Ενσωμάτωση με μια υπηρεσία Single Sign-on: - Μετασχηματισμός μαρκών και προσάρτηση αιτημάτων HTTPS με κεφαλίδες που περιέχουν δεδομένα ταυτότητας χρήστη (ταυτότητα, ρόλους, άλλες λεπτομέρειες) για την αιτούμενη υπηρεσία - Ενεργοποίηση / απενεργοποίηση ελέγχου πρόσβασης στην αιτούμενη υπηρεσία με βάση τους ρόλους από την Υπηρεσία ενιαίας σύνδεσης
  • Ένα σημείο παρακολούθησης για την επισκεψιμότητα HTTP
  • Συνδυάζοντας την τεκμηρίωση API από διάφορες υπηρεσίες (για παράδειγμα, συνδυάζοντας τα αρχεία json / yml του Swagger
  • Δυνατότητα διαχείρισης δρομολόγησης για ολόκληρο το οικοσύστημα με βάση τους τομείς και ζητούμενα URI
  • Μονό σημείο πρόσβασης για εξωτερική κίνηση και ολοκλήρωση με τον παροχέα πρόσβασης

Διαύλου συμβάντων και διαύλου ενοποίησης επιχειρήσεων / υπηρεσίας

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

Ως λεωφορείο εκδηλώσεων, μπορείτε να χρησιμοποιήσετε οποιοδήποτε σύστημα που μπορεί να λειτουργήσει έναν λεγόμενο μεσίτη: RabbitMQ, Kafka, ActiveMQ και άλλα. Γενικά, η υψηλή διαθεσιμότητα και η συνοχή των δεδομένων είναι κρίσιμα για τις μικρο υπηρεσίες, αλλά θα πρέπει να θυσιάσετε κάτι για να επιτευχθεί σωστή διανομή και ομαδοποίηση του λεωφορείου, λόγω του θεώρηματος της ΚΓΠ.

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

Υπάρχουν δεκάδες λόγοι για τη χρήση της προσέγγισης "Enterprise Integration / Service Bus", η οποία στοχεύει στη μείωση της πολυπλοκότητας μιας αρχιτεκτονικής προσανατολισμένης στις υπηρεσίες. Ακολουθούν μερικοί από αυτούς τους λόγους:

  • Συσσωμάτωση πολλαπλών μηνυμάτων
  • Διαχωρισμός ενός γεγονότος σε διάφορα γεγονότα
  • Σύγχρονη / συναλλακτική ανάλυση της απόκρισης του συστήματος σε ένα συμβάν
  • Συντονισμός διεπαφών, ο οποίος είναι ιδιαίτερα σημαντικός για την ολοκλήρωση με εξωτερικά συστήματα
  • Προηγμένη λογική της δρομολόγησης συμβάντων
  • Πολλαπλή ενοποίηση με τις ίδιες υπηρεσίες (από έξω και μέσα)
  • Μη κλιμακούμενη συγκέντρωση του δίαυλου δεδομένων
Ως λογισμικό ανοιχτού κώδικα για ένα δίαυλο ενοποίησης επιχειρήσεων, ίσως θελήσετε να εξετάσετε το Apache ServiceMix, το οποίο περιλαμβάνει πολλά στοιχεία απαραίτητα για το σχεδιασμό και την ανάπτυξη αυτού του είδους SOA.

Βάσεις δεδομένων και άλλες κρατικές υπηρεσίες

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

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

Με βάση την εμπειρία μου και την κατάσταση της αγοράς, μπορώ να διακρίνω τις ακόλουθες ομάδες κρατικών υπηρεσιών μαζί με παραδείγματα των καταλληλότερων λύσεων Docker για κάθε μία από αυτές:

  • Συστήματα διαχείρισης βάσεων δεδομένων - Η PostDock είναι μια απλή και αξιόπιστη λύση για PostgreSQL μέσα σε οποιοδήποτε περιβάλλον Docker
  • Μετονομασία ουρών / μηνυμάτων - Το RabbitMQ είναι ένα κλασικό λογισμικό για την κατασκευή ενός συστήματος ουράς μηνυμάτων και τη δρομολόγηση των μηνυμάτων. Η παράμετρος cluster_formation στη διαμόρφωση του RabbitMQ είναι απαραίτητη για μια ρύθμιση συμπλέγματος
  • Υπηρεσίες προσωρινής αποθήκευσης - το redis θεωρείται μία από τις πιο αξιόπιστες και ευέλικτες λύσεις κρυφής μνήμης δεδομένων
  • Πλήρης αναζήτηση κειμένου - η στοίβα Elasticsearch που ήδη ανέφερα παραπάνω, αρχικά χρησιμοποιημένη για αναζήτηση πλήρους κειμένου, αλλά εξίσου καλή για την αποθήκευση κορμών και για κάθε είδους εργασία με μεγάλα ποσά δεδομένων κειμένου
  • Υπηρεσίες αποθήκευσης αρχείων - μια γενικευμένη ομάδα υπηρεσιών για οποιοδήποτε τύπο αποθήκευσης και παράδοσης αρχείων (ftp, sftp κ.ο.κ.)

Κάτοπτρα εξαρτήσεων

Εάν δεν έχετε εντοπίσει ακόμα μια κατάσταση όπου τα πακέτα ή οι εξαρτήσεις που χρειάζεστε έχουν αφαιρεθεί ή έχουν γίνει προσωρινά μη διαθέσιμα από δημόσιο διακομιστή, μην πιστεύετε ότι αυτό δεν θα συμβεί ποτέ. Για να αποφύγετε τυχόν ανεπιθύμητη διαθεσιμότητα και να παρέχετε ασφάλεια στα εσωτερικά συστήματα, βεβαιωθείτε ότι ούτε η κατασκευή ούτε η παράδοση των υπηρεσιών σας απαιτούν σύνδεση στο Internet. Ρυθμίστε την αντιστοίχιση και αντιγραφή όλων των εξαρτήσεων στο εσωτερικό δίκτυο: Εικόνες Docker, πακέτα rpm, αποθετήρια πόρων, modules python / go / js / php.

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

Από την αρχιτεκτονική στην πραγματική ζωή

Όπως αυτό ή όχι, αργά ή γρήγορα ολόκληρη η αρχιτεκτονική σας θα είναι καταδικασμένη σε αποτυχία. Πάντα συμβαίνει: οι τεχνολογίες καθίστανται ξεπερασμένες γρήγορα (1-5 χρόνια), μέθοδοι και προσεγγίσεις - λίγο αργότερα (5-10 χρόνια), αρχές σχεδιασμού και βασικές αρχές - περιστασιακά (10-20 χρόνια), αλλά αναπόφευκτα.

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

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

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

Επιστρέφοντας στο ερώτημα από τον τίτλο, "είναι δυνατόν να οικοδομήσουμε μια καλύτερη αρχιτεκτονική;" Όχι όχι "για μια και για πάντα", αλλά φροντίστε να το προσπαθήσετε και σε κάποιο σημείο, "για μικρό χρονικό διάστημα", εσείς θα πετύχει σίγουρα!

ΥΣΤΕΡΟΓΡΑΦΟ:

Το αρχικό άρθρο γράφτηκε στα ρωσικά, χάρη στον συνάδελφό μου στη Λαδάδα Σεργκέι Ροντέν, για μια φοβερή βοήθεια στη μετάφραση του!