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

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

Η θέση σε λειτουργία των νέων διακομιστών ήταν αυστηρά συνδεδεμένη με μια προθεσμία. Και η μετακίνησή του σήμαινε να τεθεί σε κίνδυνο τόσο η αποστολή ενός δισεκατομμυρίου δώρων όσο και η μετανάστευση συστημάτων. Ακόμη και μια ομάδα που αποτελείται από τον Father Frost και τον Άγιο Βασίλη δεν μπορούσε να αλλάξει την ημερομηνία - μπορείτε να μεταφέρετε το σύστημα SAP για διαχείριση αποθήκης μόνο μία φορά το χρόνο. Από τις 31 Δεκεμβρίου έως την 1η Ιανουαρίου, οι τεράστιες αποθήκες του λιανοπωλητή, συνολικά στο μέγεθος 20 γηπέδων ποδοσφαίρου, σταματούν τη δουλειά τους για 15 ώρες. Και αυτή είναι η μόνη χρονική περίοδος για τη μετακίνηση του συστήματος. Δεν είχαμε κανένα περιθώριο λάθους κατά την εισαγωγή των διακομιστών.

Επιτρέψτε μου να είμαι σαφής: η ιστορία μου αντικατοπτρίζει τα εργαλεία και τη διαδικασία διαχείρισης παραμέτρων που χρησιμοποιεί η ομάδα μας.

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

Διαχείριση εγκατάστασης λειτουργικού συστήματος

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

Χρησιμοποιώντας αυτό το σύστημα, λάβαμε τυπικές παρουσίες διακομιστή με λειτουργικό σύστημα κατάλληλο για περαιτέρω αυτοματισμό. Κατά τη διάρκεια της "χύσης" έλαβαν ένα ελάχιστο σύνολο τοπικών χρηστών και δημόσιων κλειδιών SSH, καθώς και μια συνεπή διαμόρφωση λειτουργικού συστήματος. Είχαμε εγγυημένη διαχείριση των διακομιστών μέσω του CMS και ήμασταν σίγουροι ότι δεν υπήρχαν εκπλήξεις «κάτω» σε επίπεδο λειτουργικού συστήματος.

Η "μέγιστη" εργασία για το σύστημα διαχείρισης εγκατάστασης είναι η αυτόματη διαμόρφωση των διακομιστών από το επίπεδο BIOS/υλικολογισμικού στο λειτουργικό σύστημα. Πολλά εδώ εξαρτώνται από τον εξοπλισμό και τις εργασίες εγκατάστασης. Για ετερογενή εξοπλισμό, μπορείτε να εξετάσετε REDFISH API. Εάν όλο το υλικό προέρχεται από έναν προμηθευτή, τότε είναι συχνά πιο βολικό να χρησιμοποιείτε έτοιμα εργαλεία διαχείρισης (για παράδειγμα, HP ILO Amplifier, DELL OpenManage, κ.λπ.).

Για να εγκαταστήσουμε το λειτουργικό σύστημα σε φυσικούς διακομιστές, χρησιμοποιήσαμε το γνωστό Cobbler, το οποίο ορίζει ένα σύνολο προφίλ εγκατάστασης που συμφωνούνται με την υπηρεσία λειτουργίας. Κατά την προσθήκη ενός νέου διακομιστή στην υποδομή, ο μηχανικός συνέδεσε τη διεύθυνση MAC του διακομιστή με το απαιτούμενο προφίλ στο Cobbler. Κατά την εκκίνηση μέσω του δικτύου για πρώτη φορά, ο διακομιστής έλαβε μια προσωρινή διεύθυνση και ένα νέο λειτουργικό σύστημα. Στη συνέχεια μεταφέρθηκε στη διεύθυνση VLAN/IP προορισμού και συνέχισε την εργασία εκεί. Ναι, η αλλαγή του VLAN απαιτεί χρόνο και απαιτεί συντονισμό, αλλά παρέχει πρόσθετη προστασία από τυχαία εγκατάσταση του διακομιστή σε περιβάλλον παραγωγής.

Δημιουργήσαμε εικονικούς διακομιστές βασισμένους σε πρότυπα που προετοιμάστηκαν χρησιμοποιώντας το HashiСorp Packer. Ο λόγος ήταν ο ίδιος: για την αποφυγή πιθανών ανθρώπινων λαθών κατά την εγκατάσταση του λειτουργικού συστήματος. Όμως, σε αντίθεση με τους φυσικούς διακομιστές, το Packer εξαλείφει την ανάγκη για αλλαγές PXE, εκκίνησης δικτύου και VLAN. Αυτό κατέστησε ευκολότερη και απλούστερη τη δημιουργία εικονικών διακομιστών.

Ρύζι. 1. Διαχείριση εγκατάστασης λειτουργικών συστημάτων.

Διαχείριση μυστικών

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

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

• απευθείας στον κώδικα ελέγχου διαμόρφωσης ή σε αρχεία στο αποθετήριο.
• σε εξειδικευμένα εργαλεία διαχείρισης διαμόρφωσης (για παράδειγμα, Ansible Vault).
• σε συστήματα CI/CD (Jenkins/TeamCity/GitLab/κ.λπ.) ή σε συστήματα διαχείρισης διαμόρφωσης (Ansible Tower/Ansible AWX).
• Τα μυστικά μπορούν επίσης να μεταφερθούν "χειροκίνητα". Για παράδειγμα, τοποθετούνται σε μια καθορισμένη θέση και, στη συνέχεια, χρησιμοποιούνται από συστήματα διαχείρισης διαμόρφωσης.
• διάφορους συνδυασμούς των παραπάνω.

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

Χρησιμοποιήσαμε την κεντρική μυστική αποθήκευση HashiCorp Vault. Αυτό μας επέτρεψε:

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

Τώρα ας περάσουμε στο κεντρικό σύστημα ελέγχου ταυτότητας και εξουσιοδότησης. Ήταν δυνατό να γίνει χωρίς αυτό, αλλά η διαχείριση των χρηστών σε πολλά σχετικά συστήματα είναι πολύ μη τετριμμένη. Έχουμε διαμορφώσει τον έλεγχο ταυτότητας και την εξουσιοδότηση μέσω της υπηρεσίας LDAP. Διαφορετικά, το Vault θα έπρεπε να εκδίδει συνεχώς και να παρακολουθεί τα διακριτικά ελέγχου ταυτότητας για τους χρήστες. Και η διαγραφή και η προσθήκη χρηστών θα μετατραπεί σε μια αποστολή "δημιουργούσα/διέγραψα αυτόν τον λογαριασμό χρήστη παντού;"

Προσθέτουμε ένα άλλο επίπεδο στο σύστημά μας: διαχείριση μυστικών και κεντρικός έλεγχος ταυτότητας/εξουσιοδότηση:

Ρύζι. 2. Διαχείριση μυστικών.

Διαχείριση διαμόρφωσης

Φτάσαμε στον πυρήνα - το σύστημα CMS. Στην περίπτωσή μας, αυτός είναι ένας συνδυασμός Ansible και Red Hat Ansible AWX.

Αντί για Ansible, μπορεί να χρησιμοποιηθεί Chef, Puppet, SaltStack. Επιλέξαμε το Ansible με βάση πολλά κριτήρια.

• Πρώτον, είναι η ευελιξία. Ένα σετ έτοιμων μονάδων για έλεγχο ΕΝΤΥΠΩΣΙΑΚΟ. Και αν δεν έχετε αρκετό από αυτό, μπορείτε να κάνετε αναζήτηση στο GitHub και στο Galaxy.
• Δεύτερον, δεν χρειάζεται να εγκαταστήσετε και να υποστηρίξετε πράκτορες σε διαχειριζόμενο εξοπλισμό, να αποδείξετε ότι δεν παρεμβαίνουν στο φορτίο και να επιβεβαιώσετε την απουσία «σελιδοδεικτών».
• Τρίτον, η Ansible έχει χαμηλό εμπόδιο εισόδου. Ένας ικανός μηχανικός θα γράψει ένα βιβλίο εργασίας κυριολεκτικά την πρώτη ημέρα εργασίας με το προϊόν.

Όμως ο Ansible μόνο σε περιβάλλον παραγωγής δεν μας αρκούσε. Διαφορετικά, θα προέκυπταν πολλά προβλήματα με τον περιορισμό της πρόσβασης και τον έλεγχο των ενεργειών των διαχειριστών. Πώς να περιορίσετε την πρόσβαση; Άλλωστε, ήταν απαραίτητο για κάθε τμήμα να διαχειρίζεται (διαβάστε: εκτελέστε το Ansible playbook) το «δικό του» σύνολο διακομιστών. Πώς να επιτρέψετε μόνο σε ορισμένους υπαλλήλους να εκτελούν συγκεκριμένα βιβλία Ansible; Ή πώς να παρακολουθείτε ποιος κυκλοφόρησε το βιβλίο αναπαραγωγής χωρίς να εγκαταστήσετε πολλές τοπικές γνώσεις σε διακομιστές και εξοπλισμό που εκτελεί το Ansible;

Τη μερίδα του λέοντος τέτοιων ζητημάτων επιλύει η Red Hat Πύργος Ansible, ή το ανοιχτού κώδικα upstream έργο του Ansible AWX. Γι' αυτό το προτιμήσαμε για τον πελάτη.

Και μια ακόμη πινελιά στο πορτρέτο του συστήματος CMS μας. Το Ansible playbook θα πρέπει να αποθηκεύεται σε συστήματα διαχείρισης αποθετηρίου κώδικα. Το έχουμε GitLab CE.

Έτσι, οι ίδιες οι διαμορφώσεις διαχειρίζονται από έναν συνδυασμό Ansible/Ansible AWX/GitLab (βλ. Εικ. 3). Φυσικά, το AWX/GitLab είναι ενσωματωμένο με ένα ενιαίο σύστημα ελέγχου ταυτότητας και το Ansible playbook είναι ενσωματωμένο στο HashiCorp Vault. Οι διαμορφώσεις εισέρχονται στο περιβάλλον παραγωγής μόνο μέσω του Ansible AWX, στο οποίο καθορίζονται όλοι οι «κανόνες του παιχνιδιού»: ποιος μπορεί να διαμορφώσει τι, πού να πάρει τον κωδικό διαχείρισης διαμόρφωσης για το CMS κ.λπ.

Ρύζι. 3. Διαχείριση διαμόρφωσης.

Διαχείριση δοκιμών

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

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

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

Η ανάπτυξη κώδικα και η διαχείριση παραμέτρων έχουν γίνει πιο ήρεμες και προβλέψιμες. Για να οργανώσουμε συνεχείς δοκιμές, χρησιμοποιήσαμε το κιτ εργαλείων GitLab CI/CD και πήραμε Ansible Μόριο.

Κάθε φορά που υπάρχει αλλαγή στον κώδικα διαχείρισης διαμόρφωσης, το GitLab CI/CD καλεί το Molecule:

• ελέγχει τη σύνταξη του κώδικα,
• σηκώνει το δοχείο Docker,
• εφαρμόζει τον τροποποιημένο κώδικα στο δημιουργημένο κοντέινερ,
• ελέγχει το ρόλο για ανικανότητα και εκτελεί δοκιμές για αυτόν τον κωδικό (η ευαισθησία εδώ είναι σε επίπεδο ανικανότητας ρόλου, βλ. Εικ. 4).

Παραδώσαμε διαμορφώσεις στο περιβάλλον παραγωγής χρησιμοποιώντας το Ansible AWX. Οι μηχανικοί λειτουργιών εφάρμοσαν αλλαγές διαμόρφωσης μέσω προκαθορισμένων προτύπων. Το AWX «ζήτησε» ανεξάρτητα την πιο πρόσφατη έκδοση του κώδικα από τον κύριο κλάδο του GitLab κάθε φορά που χρησιμοποιήθηκε. Με αυτόν τον τρόπο αποκλείσαμε τη χρήση μη ελεγμένου ή ξεπερασμένου κώδικα στο περιβάλλον παραγωγής. Φυσικά, ο κωδικός εισήλθε στον κύριο κλάδο μόνο μετά από δοκιμή, έλεγχο και έγκριση.

Ρύζι. 4. Αυτόματος έλεγχος ρόλων στο GitLab CI/CD.

Υπάρχει επίσης ένα πρόβλημα που σχετίζεται με τη λειτουργία των συστημάτων παραγωγής. Στην πραγματική ζωή, είναι πολύ δύσκολο να κάνετε αλλαγές στη διαμόρφωση μόνο μέσω του κώδικα CMS. Οι καταστάσεις έκτακτης ανάγκης προκύπτουν όταν ένας μηχανικός πρέπει να αλλάξει τη διαμόρφωση «εδώ και τώρα», χωρίς να περιμένει για επεξεργασία κώδικα, δοκιμή, έγκριση κ.λπ.

Ως αποτέλεσμα, λόγω μη αυτόματων αλλαγών, εμφανίζονται αποκλίσεις στη διαμόρφωση στον ίδιο τύπο εξοπλισμού (για παράδειγμα, οι ρυθμίσεις sysctl διαμορφώνονται διαφορετικά στους κόμβους συμπλέγματος HA). Ή η πραγματική διαμόρφωση στον εξοπλισμό διαφέρει από αυτή που καθορίζεται στον κώδικα CMS.

Επομένως, εκτός από τις συνεχείς δοκιμές, ελέγχουμε τα περιβάλλοντα παραγωγής για αποκλίσεις στις ρυθμίσεις παραμέτρων. Επιλέξαμε την απλούστερη επιλογή: εκτέλεση του κώδικα διαμόρφωσης CMS σε λειτουργία "dry run", δηλαδή χωρίς εφαρμογή αλλαγών, αλλά με ειδοποίηση όλων των αποκλίσεων μεταξύ της προγραμματισμένης και της πραγματικής διαμόρφωσης. Το εφαρμόσαμε με περιοδική εκτέλεση όλων των βιβλίων Ansible με την επιλογή «—check» στους διακομιστές παραγωγής. Όπως πάντα, το Ansible AWX είναι υπεύθυνο για την εκκίνηση και την ενημέρωση του βιβλίου αναπαραγωγής (βλ. Εικ. 5):

Ρύζι. 5. Ελέγχει για αποκλίσεις διαμόρφωσης στο Ansible AWX.

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

Τώρα έχουμε ένα σημαντικό επίπεδο δοκιμής που αποτελείται από Ansible AWX/GitLab/Molecule (Εικόνα 6).

Ρύζι. 6. Διαχείριση δοκιμών.

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

Δεν υπάρχει «μυστική γνώση» στις ρυθμίσεις των διακομιστών και των περιβαλλόντων σήμερα. Όλα τα απαραίτητα χαρακτηριστικά αντικατοπτρίζονται στο βιβλίο παιχνιδιού. Τέρμα η δημιουργικότητα και οι αόριστες οδηγίες:Εγκαταστήστε το όπως το κανονικό Oracle, αλλά πρέπει να καθορίσετε μερικές ρυθμίσεις sysctl και να προσθέσετε χρήστες με το απαιτούμενο UID. Ρωτήστε τα παιδιά που λειτουργούν, ξέρουν».

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

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

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

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

Συγγραφέας: Sergey Artemov, αρχιτέκτονας τμήματος Λύσεις DevOps "Jet Infosystems"

Πηγή: www.habr.com