Εάν η υποδομή πληροφορικής σας αναπτύσσεται πολύ γρήγορα, αργά ή γρήγορα θα βρεθείτε αντιμέτωποι με μια επιλογή: να αυξήσετε γραμμικά τους ανθρώπινους πόρους για να την υποστηρίξετε ή να ξεκινήσετε την αυτοματοποίηση. Μέχρι κάποιο σημείο, ζούσαμε στο πρώτο παράδειγμα, και μετά ξεκίνησε η μακρά πορεία προς την Υποδομή ως Κώδικας.
Φυσικά, η NSPK δεν είναι startup, αλλά μια τέτοια ατμόσφαιρα βασίλευε στην εταιρεία τα πρώτα χρόνια της ύπαρξής της και ήταν πολύ ενδιαφέροντα χρόνια. Το όνομά μου είναι , Υποστηρίζω υποδομή Linux με υψηλές απαιτήσεις διαθεσιμότητας για πάνω από 10 χρόνια. Εντάχθηκε στην ομάδα NSPK τον Ιανουάριο του 2016 και, δυστυχώς, δεν είδε την αρχή της ύπαρξης της εταιρείας, αλλά ήρθε σε ένα στάδιο μεγάλων αλλαγών.
Σε γενικές γραμμές, μπορούμε να πούμε ότι η ομάδα μας προμηθεύει 2 προϊόντα για την εταιρεία. Το πρώτο είναι οι υποδομές. Η αλληλογραφία θα πρέπει να λειτουργεί, το DNS θα πρέπει να λειτουργεί και οι ελεγκτές τομέα θα πρέπει να σας επιτρέπουν να εισέλθετε σε διακομιστές που δεν πρέπει να κολλήσουν. Το τοπίο πληροφορικής της εταιρείας είναι τεράστιο! Αυτά είναι κρίσιμα συστήματα business&mission, οι απαιτήσεις διαθεσιμότητας για ορισμένα είναι 99,999. Το δεύτερο προϊόν είναι οι ίδιοι οι διακομιστές, φυσικοί και εικονικοί. Τα υπάρχοντα πρέπει να παρακολουθούνται και τα νέα πρέπει να παραδίδονται τακτικά σε πελάτες από πολλά τμήματα. Σε αυτό το άρθρο θέλω να εστιάσω στο πώς αναπτύξαμε την υποδομή που είναι υπεύθυνη για τον κύκλο ζωής του διακομιστή.
Ξεκινώντας από ένα ταξίδι
Στην αρχή του ταξιδιού μας, η στοίβα τεχνολογίας μας έμοιαζε ως εξής:
OS CentOS 7
FreeIPA Domain Controllers
Αυτοματισμός - Ansible(+Tower), Cobbler
Όλα αυτά εντοπίστηκαν σε 3 τομείς, κατανεμημένους σε πολλά κέντρα δεδομένων. Σε ένα κέντρο δεδομένων υπάρχουν συστήματα γραφείου και περιοχές δοκιμών, στο υπόλοιπο υπάρχει PROD.
Η δημιουργία διακομιστών σε ένα σημείο έμοιαζε με αυτό:
Στο πρότυπο VM, το CentOS είναι ελάχιστο και το απαιτούμενο ελάχιστο είναι όπως το σωστό /etc/resolv.conf, τα υπόλοιπα προέρχονται από το Ansible.
CMDB - Excel.
Εάν ο διακομιστής είναι φυσικός, τότε αντί να αντιγράψετε την εικονική μηχανή, το λειτουργικό σύστημα εγκαταστάθηκε σε αυτό χρησιμοποιώντας το Cobbler - οι διευθύνσεις MAC του διακομιστή προορισμού προστίθενται στη διαμόρφωση Cobbler, ο διακομιστής λαμβάνει μια διεύθυνση IP μέσω DHCP και, στη συνέχεια, το λειτουργικό σύστημα προστίθεται.
Αρχικά προσπαθήσαμε να κάνουμε κάποιο είδος διαχείρισης παραμέτρων στο Cobbler. Αλλά με την πάροδο του χρόνου, αυτό άρχισε να δημιουργεί προβλήματα με τη φορητότητα των διαμορφώσεων τόσο σε άλλα κέντρα δεδομένων όσο και στον κώδικα Ansible για την προετοιμασία των VM.
Εκείνη την εποχή, πολλοί από εμάς αντιλαμβανόταν το Ansible ως μια βολική επέκταση του Bash και δεν τσιγκουνεύαμε τα σχέδια που χρησιμοποιούν το κέλυφος και το sed. Συνολικά Bashsible. Αυτό οδήγησε τελικά στο γεγονός ότι εάν το βιβλίο αναπαραγωγής για κάποιο λόγο δεν λειτουργούσε στον διακομιστή, ήταν ευκολότερο να διαγράψετε τον διακομιστή, να διορθώσετε το βιβλίο αναπαραγωγής και να τον εκτελέσετε ξανά. Δεν υπήρχε ουσιαστικά καμία έκδοση σεναρίων, καμία φορητότητα των διαμορφώσεων.
Για παράδειγμα, θέλαμε να αλλάξουμε κάποιες ρυθμίσεις σε όλους τους διακομιστές:
- Αλλάζουμε τη διαμόρφωση σε υπάρχοντες διακομιστές στο λογικό τμήμα/κέντρο δεδομένων. Μερικές φορές όχι σε μία μέρα - οι απαιτήσεις προσβασιμότητας και ο νόμος των μεγάλων αριθμών δεν επιτρέπουν την εφαρμογή όλων των αλλαγών ταυτόχρονα. Και ορισμένες αλλαγές είναι δυνητικά καταστροφικές και απαιτούν επανεκκίνηση κάτι - από υπηρεσίες μέχρι το ίδιο το λειτουργικό σύστημα.
- Διορθώνοντας το στο Ansible
- Το φτιάχνουμε στο Cobbler
- Επαναλάβετε Ν φορές για κάθε λογικό τμήμα/κέντρο δεδομένων
Για να γίνουν όλες οι αλλαγές ομαλά, ήταν απαραίτητο να ληφθούν υπόψη πολλοί παράγοντες και οι αλλαγές συμβαίνουν συνεχώς.
- Ανακατασκευή κωδικού, αρχείων διαμόρφωσης
- Αλλαγή εσωτερικών βέλτιστων πρακτικών
- Αλλαγές με βάση τα αποτελέσματα της ανάλυσης περιστατικών/ατυχημάτων
- Αλλαγή των προτύπων ασφάλειας, τόσο εσωτερικά όσο και εξωτερικά. Για παράδειγμα, το PCI DSS ενημερώνεται με νέες απαιτήσεις κάθε χρόνο
Ανάπτυξη υποδομών και αρχή του ταξιδιού
Ο αριθμός των διακομιστών/λογικών τομέων/κέντρων δεδομένων αυξήθηκε και μαζί τους ο αριθμός των σφαλμάτων στις διαμορφώσεις. Κάποια στιγμή, καταλήξαμε σε τρεις κατευθύνσεις στις οποίες πρέπει να αναπτυχθεί η διαχείριση διαμόρφωσης:
- Αυτοματοποίηση. Το ανθρώπινο λάθος σε επαναλαμβανόμενες λειτουργίες θα πρέπει να αποφεύγεται όσο το δυνατόν περισσότερο.
- Επαναληψιμότητα. Είναι πολύ πιο εύκολο να διαχειριστείτε την υποδομή όταν είναι προβλέψιμη. Η διαμόρφωση των διακομιστών και των εργαλείων για την προετοιμασία τους θα πρέπει να είναι η ίδια παντού. Αυτό είναι επίσης σημαντικό για τις ομάδες προϊόντων - μετά τη δοκιμή, η εφαρμογή πρέπει να είναι εγγυημένη ότι θα καταλήξει σε ένα περιβάλλον παραγωγής που έχει διαμορφωθεί παρόμοια με το περιβάλλον δοκιμής.
- Απλότητα και διαφάνεια στην πραγματοποίηση αλλαγών στη διαχείριση διαμόρφωσης.
Απομένει να προσθέσουμε μερικά εργαλεία.
Επιλέξαμε το GitLab CE ως αποθετήριο κώδικα, κυρίως για τις ενσωματωμένες μονάδες CI/CD.
Vault of Secrets - Hashicorp Vault, incl. για το μεγάλο API.
Δοκιμή διαμορφώσεων και ρόλων - Molecule+Testinfra. Οι δοκιμές πάνε πολύ πιο γρήγορα εάν συνδέεστε σε ανώμαλο μιτογόνο. Ταυτόχρονα, αρχίσαμε να γράφουμε το δικό μας CMDB και ενορχηστρωτή για αυτόματη ανάπτυξη (στην εικόνα πάνω από το Cobbler), αλλά αυτή είναι μια εντελώς διαφορετική ιστορία, την οποία θα πει ο συνάδελφός μου και ο κύριος προγραμματιστής αυτών των συστημάτων στο μέλλον.
Η επιλογή μας:
Μόριο + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Ίδια ανάπτυξη)
Φρουτόπιτα
Δρομέας Gitlab + GitLab
Hashicorp Vault
Παρεμπιπτόντως, σχετικά με τους σημαντικούς ρόλους. Στην αρχή υπήρχε μόνο ένας, αλλά μετά από πολλές ανακατασκευές υπήρχαν 17. Συνιστώ ανεπιφύλακτα να σπάσετε το μονόλιθο σε ανίκανους ρόλους, οι οποίοι στη συνέχεια μπορούν να εκκινηθούν ξεχωριστά· επιπλέον, μπορείτε να προσθέσετε ετικέτες. Χωρίσαμε τους ρόλους κατά λειτουργικότητα - δίκτυο, καταγραφή, πακέτα, υλικό, μόριο κ.λπ. Σε γενικές γραμμές, ακολουθήσαμε την παρακάτω στρατηγική. Δεν επιμένω ότι αυτή είναι η μόνη αλήθεια, αλλά λειτούργησε για εμάς.
- Η αντιγραφή διακομιστών από τη «χρυσή εικόνα» είναι κακό!Το κύριο μειονέκτημα είναι ότι δεν γνωρίζετε ακριβώς σε ποια κατάσταση βρίσκονται οι εικόνες τώρα και ότι όλες οι αλλαγές θα έρθουν σε όλες τις εικόνες σε όλα τα αγροκτήματα εικονικοποίησης.
- Χρησιμοποιήστε τα προεπιλεγμένα αρχεία διαμόρφωσης στο ελάχιστο και συμφωνήστε με άλλα τμήματα ότι είστε υπεύθυνοι για τα κύρια αρχεία συστήματος, για παράδειγμα:
- Αφήστε το /etc/sysctl.conf κενό, οι ρυθμίσεις θα πρέπει να είναι μόνο στο /etc/sysctl.d/. Η προεπιλογή σας σε ένα αρχείο, προσαρμοσμένη για την εφαρμογή σε άλλο.
- Χρησιμοποιήστε αρχεία παράκαμψης για να επεξεργαστείτε μονάδες συστήματος.
- Δημιουργήστε πρότυπο όλες τις ρυθμίσεις παραμέτρων και συμπεριλάβετέ τις εξ ολοκλήρου· εάν είναι δυνατόν, όχι sed ή τα ανάλογά του στα βιβλία αναπαραγωγής
- Ανακατασκευή του κώδικα συστήματος διαχείρισης διαμόρφωσης:
- Χωρίστε τις εργασίες σε λογικές οντότητες και ξαναγράψτε το μονόλιθο σε ρόλους
- Χρησιμοποίησε λιντεράκια! Ansible-lint, yaml-lint κ.λπ
- Αλλάξτε την προσέγγισή σας! Κανένας μπαμπούκος. Είναι απαραίτητο να περιγράψουμε την κατάσταση του συστήματος
- Για όλους τους ρόλους του Ansible πρέπει να γράφετε τεστ σε μόριο και να δημιουργείτε αναφορές μία φορά την ημέρα.
- Στην περίπτωσή μας, μετά την προετοιμασία των δοκιμών (από τα οποία είναι περισσότερα από 100), βρέθηκαν περίπου 70000 λάθη. Χρειάστηκαν αρκετοί μήνες για να το διορθώσουν.
Η εφαρμογή μας
Έτσι, οι ρόλοι του ansible ήταν έτοιμοι, διαμορφωμένοι και ελεγμένοι με λίντερ. Και ακόμη και τα gits ανεβαίνουν παντού. Αλλά το ζήτημα της αξιόπιστης παράδοσης κώδικα σε διαφορετικά τμήματα παρέμεινε ανοιχτό. Αποφασίσαμε να συγχρονιστούμε με σενάρια. Φαίνεται ότι:
Μετά την άφιξη της αλλαγής, εκκινείται το CI, δημιουργείται ένας δοκιμαστικός διακομιστής, οι ρόλοι παρουσιάζονται και ελέγχονται από το μόριο. Εάν όλα είναι εντάξει, ο κωδικός πηγαίνει στον κλάδο παραγωγής. Αλλά δεν εφαρμόζουμε νέο κώδικα σε υπάρχοντες διακομιστές στο μηχάνημα. Αυτό είναι ένα είδος πώματος που είναι απαραίτητο για την υψηλή διαθεσιμότητα των συστημάτων μας. Και όταν η υποδομή γίνεται τεράστια, ο νόμος των μεγάλων αριθμών μπαίνει στο παιχνίδι - ακόμα κι αν είστε σίγουροι ότι η αλλαγή είναι ακίνδυνη, μπορεί να οδηγήσει σε τρομερές συνέπειες.
Υπάρχουν επίσης πολλές επιλογές για τη δημιουργία διακομιστών. Καταλήξαμε να επιλέξουμε προσαρμοσμένα σενάρια Python. Και για CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Σε αυτό έχουμε φτάσει, το σύστημα συνεχίζει να ζει και να αναπτύσσεται.
- 17 Αδύνατοι ρόλοι για τη ρύθμιση του διακομιστή. Κάθε ένας από τους ρόλους έχει σχεδιαστεί για να επιλύει μια ξεχωριστή λογική εργασία (καταγραφή, έλεγχος, εξουσιοδότηση χρήστη, παρακολούθηση, κ.λπ.).
- Δοκιμή ρόλων. Molecule + TestInfra.
- Ίδια ανάπτυξη: CMDB + Ενορχηστρωτής.
- Ο χρόνος δημιουργίας διακομιστή είναι ~30 λεπτά, αυτοματοποιημένος και πρακτικά ανεξάρτητος από την ουρά εργασιών.
- Η ίδια κατάσταση/ονομασία της υποδομής σε όλα τα τμήματα - βιβλία παιχνιδιού, αποθετήρια, στοιχεία εικονικοποίησης.
- Καθημερινός έλεγχος της κατάστασης του διακομιστή με δημιουργία αναφορών για αποκλίσεις με το πρότυπο.
Ελπίζω η ιστορία μου να είναι χρήσιμη σε όσους βρίσκονται στην αρχή του ταξιδιού τους. Τι στοίβα αυτοματισμού χρησιμοποιείτε;
Πηγή: www.habr.com