Αυτό το άρθρο είναι το έκτο της σειράς «Πώς να πάρετε τον έλεγχο της υποδομής δικτύου σας». Μπορείτε να βρείτε τα περιεχόμενα όλων των άρθρων της σειράς και τους συνδέσμους .
Έχοντας αφήσει πίσω μου αρκετά θέματα, αποφάσισα να ξεκινήσω ένα νέο κεφάλαιο.
Θα επανέλθω στην ασφάλεια λίγο αργότερα. Εδώ θέλω να συζητήσω μια απλή αλλά αποτελεσματική προσέγγιση, η οποία είμαι βέβαιος ότι, με τη μια ή την άλλη μορφή, μπορεί να είναι χρήσιμη σε πολλούς. Αυτή είναι περισσότερο μια σύντομη ιστορία για το πώς ο αυτοματισμός μπορεί να αλλάξει τη ζωή ενός μηχανικού. Θα μιλήσουμε για τη χρήση προτύπων. Στο τέλος υπάρχει μια λίστα με τα έργα μου όπου μπορείτε να δείτε πώς λειτουργούν όλα όσα περιγράφονται εδώ.
DevOps για το δίκτυο
Δημιουργία διαμόρφωσης με ένα σενάριο, χρήση GIT για τον έλεγχο των αλλαγών στην υποδομή IT, απομακρυσμένη "φόρτωση" - αυτές οι ιδέες έρχονται πρώτα όταν σκέφτεστε την τεχνική υλοποίηση της προσέγγισης DevOps. Τα πλεονεκτήματα είναι προφανή. Όμως, δυστυχώς, υπάρχουν και μειονεκτήματα.
Όταν πριν από περισσότερα από 5 χρόνια, οι προγραμματιστές μας ήρθαν σε εμάς, οι δικτυακοί, με αυτές τις προτάσεις, δεν ήμασταν ευχαριστημένοι.
Πρέπει να πω ότι κληρονομήσαμε ένα αρκετά ετερόκλητο δίκτυο, που αποτελείται από εξοπλισμό από περίπου 10 διαφορετικούς προμηθευτές. Ήταν βολικό να ρυθμίσουμε κάποια πράγματα μέσω του αγαπημένου μας cli, αλλά σε άλλα προτιμήσαμε να χρησιμοποιήσουμε το GUI. Επιπλέον, η μακρά εργασία σε «ζωντανό» εξοπλισμό μας έχει διδάξει να ελέγχουμε σε πραγματικό χρόνο. Για παράδειγμα, όταν κάνω αλλαγές, νιώθω πολύ πιο άνετα να δουλεύω απευθείας μέσω του cli. Με αυτόν τον τρόπο μπορώ να δω γρήγορα ότι κάτι πήγε στραβά και να επαναφέρω τις αλλαγές. Όλα αυτά ήταν σε κάποια αντίφαση με τις ιδέες τους.
Προκύπτουν επίσης άλλα ερωτήματα, για παράδειγμα, η διεπαφή μπορεί να αλλάξει ελαφρώς από έκδοση σε έκδοση του λογισμικού. Αυτό θα προκαλέσει τελικά το σενάριό σας να δημιουργήσει το λάθος "config". Δεν θα ήθελα να χρησιμοποιήσω την παραγωγή για «τρέξιμο».
Ή, πώς να καταλάβετε ότι οι εντολές διαμόρφωσης εφαρμόστηκαν σωστά και τι να κάνετε σε περίπτωση σφάλματος;
Δεν θέλω να πω ότι όλα αυτά τα ζητήματα είναι άλυτα. Απλώς λέγοντας "Α" πιθανώς έχει νόημα να πούμε και "Β" και αν θέλετε να χρησιμοποιήσετε τις ίδιες διαδικασίες για τον έλεγχο των αλλαγών όπως στην ανάπτυξη, τότε πρέπει να έχετε περιβάλλοντα προγραμματισμού και σκηνής εκτός από την παραγωγή. Τότε αυτή η προσέγγιση φαίνεται ολοκληρωμένη. Πόσο όμως θα κοστίσει;
Αλλά υπάρχει μια κατάσταση όπου τα μειονεκτήματα πρακτικά ισοπεδώνονται και παραμένουν μόνο τα πλεονεκτήματα. Μιλάω για σχεδιαστικές εργασίες.
Σχέδιο
Τα τελευταία δύο χρόνια συμμετέχω σε ένα έργο για την κατασκευή ενός κέντρου δεδομένων για έναν μεγάλο πάροχο. Είμαι υπεύθυνος για το F5 και το Palo Alto σε αυτό το έργο. Από την πλευρά της Cisco, πρόκειται για «εξοπλισμό τρίτου μέρους».
Για μένα προσωπικά, υπάρχουν δύο διακριτά στάδια σε αυτό το έργο.
Πρώτο στάδιο
Τον πρώτο χρόνο ήμουν ατελείωτα απασχολημένος, δούλευα νύχτες και Σαββατοκύριακα. Δεν μπορούσα να σηκώσω το κεφάλι μου. Η πίεση από τη διοίκηση και τον πελάτη ήταν ισχυρή και συνεχής. Σε μια συνεχή ρουτίνα, δεν μπορούσα καν να προσπαθήσω να βελτιστοποιήσω τη διαδικασία. Δεν ήταν μόνο και όχι τόσο η διαμόρφωση του εξοπλισμού όσο η προετοιμασία της τεκμηρίωσης σχεδιασμού.
Οι πρώτες δοκιμές άρχισαν και θα ήμουν έκπληκτος με το πόσα μικρά λάθη και ανακρίβειες έγιναν. Φυσικά, όλα λειτουργούσαν, αλλά έλειπε ένα γράμμα στο όνομα, έλειπε μια γραμμή στην εντολή... Οι δοκιμές συνεχίζονταν και συνεχίζονταν και ήμουν ήδη σε μια συνεχή, καθημερινή μάχη με λάθη, δοκιμές και τεκμηρίωση .
Αυτό συνεχίστηκε για ένα χρόνο. Το έργο, απ' όσο καταλαβαίνω, δεν ήταν εύκολο για όλους, αλλά σταδιακά ο πελάτης γινόταν όλο και πιο ικανοποιημένος και αυτό κατέστησε δυνατή την πρόσληψη επιπλέον μηχανικών που ήταν σε θέση να αναλάβουν οι ίδιοι μέρος της ρουτίνας.
Τώρα μπορούσαμε να κοιτάξουμε λίγο γύρω μας.
Και αυτή ήταν η αρχή του δεύτερου σταδίου.
Δεύτερο στάδιο
Αποφάσισα να αυτοματοποιήσω τη διαδικασία.
Αυτό που κατάλαβα από την επικοινωνία μου με τους προγραμματιστές εκείνη την εποχή (και πρέπει να αποτίσουμε φόρο τιμής, είχαμε μια δυνατή ομάδα) είναι ότι η μορφή κειμένου, αν και με την πρώτη ματιά φαίνεται σαν κάτι από τον κόσμο του λειτουργικού συστήματος DOS, έχει έναν αριθμό πολύτιμων ιδιοκτησιών.
Έτσι, για παράδειγμα, η μορφή κειμένου θα είναι χρήσιμη εάν θέλετε να επωφεληθείτε πλήρως από το GIT και όλα τα παράγωγά του. Και ήθελα.
Λοιπόν, φαίνεται ότι μπορείτε απλώς να αποθηκεύσετε μια διαμόρφωση ή μια λίστα εντολών, αλλά η πραγματοποίηση αλλαγών είναι αρκετά ενοχλητική. Επιπλέον, υπάρχει μια άλλη σημαντική εργασία κατά τη διάρκεια του σχεδιασμού. Θα πρέπει να έχετε τεκμηρίωση που να περιγράφει το σχέδιό σας ως σύνολο (Σχεδίαση χαμηλού επιπέδου) και τη συγκεκριμένη υλοποίηση (Σχέδιο υλοποίησης δικτύου). Και σε αυτή την περίπτωση, η χρήση προτύπων μοιάζει πολύ κατάλληλη επιλογή.
Έτσι, όταν χρησιμοποιείτε YAML και Jinja2, ένα αρχείο YAML με παραμέτρους διαμόρφωσης όπως διευθύνσεις IP, αριθμοί BGP AS, ... εκπληρώνει τέλεια τον ρόλο του NIP, ενώ τα πρότυπα Jinja2 περιλαμβάνουν σύνταξη που αντιστοιχεί στο σχέδιο, δηλαδή είναι ουσιαστικά ένα αντανάκλαση της LLD.
Χρειάστηκαν δύο μέρες για να μάθουν YAML και Jinja2. Μερικά καλά παραδείγματα αρκούν για να καταλάβετε πώς λειτουργεί αυτό. Στη συνέχεια χρειάστηκαν περίπου δύο εβδομάδες για να δημιουργήσουμε όλα τα πρότυπα που ταιριάζουν με το σχέδιό μας: μια εβδομάδα για το Palo Alto και άλλη μια εβδομάδα για το F5. Όλα αυτά δημοσιεύτηκαν στο εταιρικό githab.
Τώρα η διαδικασία αλλαγής φαινόταν ως εξής:
- άλλαξε το αρχείο YAML
- δημιούργησε ένα αρχείο διαμόρφωσης χρησιμοποιώντας ένα πρότυπο (Jinja2)
- αποθηκευμένο σε απομακρυσμένο αποθετήριο
- ανέβασε τη διαμόρφωση που δημιουργήθηκε στον εξοπλισμό
- Είδα ένα λάθος
- άλλαξε το αρχείο YAML ή το πρότυπο Jinja2
- δημιούργησε ένα αρχείο διαμόρφωσης χρησιμοποιώντας ένα πρότυπο (Jinja2)
- ...
Είναι σαφές ότι στην αρχή ξοδεύτηκε πολύς χρόνος για επεξεργασίες, αλλά μετά από μια ή δύο εβδομάδες αυτό έγινε μάλλον σπάνιο.
Μια καλή δοκιμή και ευκαιρία για τον εντοπισμό σφαλμάτων σε όλα ήταν η επιθυμία του πελάτη να αλλάξει τη σύμβαση ονομασίας. Όσοι δούλεψαν με το F5 καταλαβαίνουν την πικρία της κατάστασης. Αλλά για μένα ήταν όλα πολύ απλά. Άλλαξα τα ονόματα στο αρχείο YAML, διέγραψα ολόκληρη τη διαμόρφωση από τον εξοπλισμό, δημιούργησα ένα νέο και το ανέβασα. Όλα, συμπεριλαμβανομένων των διορθώσεων σφαλμάτων, χρειάστηκαν 4 ημέρες: δύο ημέρες για κάθε τεχνολογία. Μετά από αυτό, ήμουν έτοιμος για το επόμενο στάδιο, δηλαδή τη δημιουργία των κέντρων δεδομένων DEV και Staging.
Dev και Staging
Το σκηνικό στην πραγματικότητα αντιγράφει πλήρως την παραγωγή. Το Dev είναι ένα βαριά απογυμνωμένο αντίγραφο που έχει δημιουργηθεί κυρίως σε εικονικό υλικό. Μια ιδανική κατάσταση για μια νέα προσέγγιση. Αν απομονώσω τον χρόνο που αφιέρωσα από τη συνολική διαδικασία, τότε νομίζω ότι η εργασία δεν κράτησε περισσότερο από 2 εβδομάδες. Ο κύριος χρόνος είναι η αναμονή της άλλης πλευράς και η αναζήτηση προβλημάτων μαζί. Η εφαρμογή του τρίτου μέρους πέρασε σχεδόν απαρατήρητη από άλλους. Υπήρχε ακόμη χρόνος να μάθω κάτι και να γράψω μερικά άρθρα στο Habré :)
Για να συνοψίσουμε
Λοιπόν, τι έχω στην κατώτατη γραμμή;
- Το μόνο που έχω να κάνω για να αλλάξω τη διαμόρφωση είναι να αλλάξω ένα απλό, σαφώς δομημένο αρχείο YAML με παραμέτρους διαμόρφωσης. Δεν αλλάζω ποτέ το σενάριο python και πολύ σπάνια (μόνο αν υπάρχει σφάλμα) αλλάζω το Jinja2 heatlate
- Από την άποψη της τεκμηρίωσης, αυτή είναι μια σχεδόν ιδανική κατάσταση. Αλλάζετε την τεκμηρίωση (τα αρχεία YAML χρησιμεύουν ως NIP) και ανεβάζετε αυτήν τη διαμόρφωση στον εξοπλισμό. Με αυτόν τον τρόπο η τεκμηρίωσή σας είναι πάντα ενημερωμένη
Όλα αυτά οδήγησαν στο γεγονός ότι
- το ποσοστό σφάλματος έχει πέσει σχεδόν στο 0
- Το 90 τοις εκατό της ρουτίνας έχει φύγει
- η ταχύτητα υλοποίησης έχει αυξηθεί σημαντικά
PAY, F5Y, ACY
Είπα ότι μερικά παραδείγματα είναι αρκετά για να καταλάβουμε πώς λειτουργεί.
Εδώ είναι μια σύντομη (και φυσικά τροποποιημένη) εκδοχή αυτού που δημιουργήθηκε κατά τη διάρκεια της δουλειάς μου.
= ανάπτυξη Palo Aαπό Yaml = Palo Alto από το Yaml
= ανάπτυξη F5 από Yaml = F5 από Yaml (προσεχώς)
= ανάπτυξη ACεγώ από Yaml = F5 από Yaml
Θα προσθέσω λίγα λόγια για το ACY (δεν πρέπει να συγχέεται με το ACI).
Όσοι έχουν δουλέψει με την ACI ξέρουν ότι αυτό το θαύμα (και με την καλή έννοια) σίγουρα δεν δημιουργήθηκε από δικτυωτές :). Ξεχάστε όλα όσα ξέρατε για το δίκτυο - δεν θα σας φανεί χρήσιμο!
Είναι λίγο υπερβολικό, αλλά μεταφέρει χονδρικά την αίσθηση που βιώνω συνεχώς, τα τελευταία 3 χρόνια, δουλεύοντας με την ACI.
Και σε αυτήν την περίπτωση, το ACY δεν είναι μόνο μια ευκαιρία να δημιουργήσετε μια διαδικασία ελέγχου αλλαγών (η οποία είναι ιδιαίτερα σημαντική στην περίπτωση του ACI, επειδή υποτίθεται ότι είναι το κεντρικό και πιο κρίσιμο μέρος του κέντρου δεδομένων σας), αλλά σας δίνει επίσης μια φιλική προς το χρήστη διεπαφή για τη δημιουργία διαμόρφωσης.
Οι μηχανικοί σε αυτό το έργο χρησιμοποιούν το Excel για να ρυθμίσουν το ACI αντί του YAML για τους ίδιους ακριβώς σκοπούς. Υπάρχουν, φυσικά, πλεονεκτήματα στη χρήση του Excel:
- το NIP σας σε ένα αρχείο
- όμορφα σημάδια που είναι ευχάριστα να δει ο πελάτης
- μπορείτε να χρησιμοποιήσετε κάποια εργαλεία excel
Αλλά υπάρχει ένα μείον, και κατά τη γνώμη μου υπερτερεί των πλεονεκτημάτων. Ο έλεγχος των αλλαγών και ο συντονισμός της ομαδικής εργασίας γίνεται πολύ πιο δύσκολος.
Το ACY είναι στην πραγματικότητα μια εφαρμογή των ίδιων προσεγγίσεων που χρησιμοποίησα για το τρίτο μέρος για τη διαμόρφωση του ACI.
Πηγή: www.habr.com