Αυτή είναι μια μεταγραφή της ομιλίας и .
Αυτή είναι η ιστορία ενός έργου που χρησιμοποίησε ένα αυτογραμμένο σύστημα διαχείρισης διαμόρφωσης και γιατί η μετάβαση στο Ansible χρειάστηκε 18 μήνες.
Ημέρα Αρ. -ХХХ: Πριν την έναρξη
Αρχικά, η υποδομή αποτελούνταν από πολλούς ξεχωριστούς κεντρικούς υπολογιστές που εκτελούσαν το Hyper-V. Η δημιουργία μιας εικονικής μηχανής απαιτούσε πολλά βήματα: τοποθέτηση των δίσκων στη σωστή θέση, εγγραφή DNS, κράτηση DHCP, τοποθέτηση της διαμόρφωσης VM στο αποθετήριο git. Αυτή η διαδικασία ήταν μερικώς μηχανοποιημένη, αλλά για παράδειγμα, τα VM διανεμήθηκαν μεταξύ των κεντρικών υπολογιστών με το χέρι. Αλλά, για παράδειγμα, οι προγραμματιστές θα μπορούσαν να διορθώσουν τη διαμόρφωση VM στο git και να την εφαρμόσουν επανεκκινώντας το VM.
Λύση διαχείρισης προσαρμοσμένης διαμόρφωσης
Η αρχική ιδέα, υποψιάζομαι, επινοήθηκε ως IaC: πολλά εικονικά μηχανήματα χωρίς πολιτεία που μηδενίζουν την κατάστασή τους κατά την επανεκκίνηση. Τι ήταν η διαχείριση διαμόρφωσης VM; Σχηματικά φαίνεται απλό:
- Ένα στατικό MAC καρφώθηκε για το VM.
- Ένα ISO με CoreOS και ένας δίσκος εκκίνησης συνδέθηκαν στο VM.
- Το CoreOS εκκινεί το σενάριο προσαρμογής κατεβάζοντάς το από τον διακομιστή WEB με βάση την IP του.
- Το σενάριο πραγματοποιεί λήψη της διαμόρφωσης VM μέσω SCP με βάση τη διεύθυνση IP.
- Ξεκινούν το footcloth των αρχείων μονάδας systemd και το footcloth των σεναρίων bash.
Αυτή η λύση είχε πολλά προφανή προβλήματα:
- Το CoreOS ISO έχει καταργηθεί.
- Πολλές σύνθετες αυτοματοποιημένες ενέργειες και μαγεία κατά τη μετεγκατάσταση/δημιουργία VM.
- Δυσκολία με την ενημέρωση και όταν χρειάζεται μια συγκεκριμένη έκδοση λογισμικού. Ακόμα πιο διασκεδαστικό με τα modules του πυρήνα.
- Τα VM δεν αποκτήθηκαν έτσι χωρίς δεδομένα, δηλ. Τα VM εμφανίστηκαν με έναν δίσκο με προσαρτημένα πρόσθετα δεδομένα χρήστη.
- Κάποιος κατέστρεφε συνεχώς τις εξαρτήσεις της μονάδας του συστήματος και το CoreOS παγώνει κατά την επανεκκίνηση. Ήταν δύσκολο να το πιάσεις αυτό χρησιμοποιώντας τα διαθέσιμα εργαλεία στο CoreOS.
- Διαχείριση μυστικών.
- Δεν υπήρχε CM. Υπήρχαν διαμορφώσεις bash και YML για το CoreOS.
Για να εφαρμόσετε τη διαμόρφωση VM, πρέπει να την επανεκκινήσετε, αλλά ενδέχεται να μην γίνει επανεκκίνηση. Φαίνεται σαν ένα προφανές πρόβλημα, αλλά δεν υπάρχουν μόνιμοι δίσκοι - δεν υπάρχει πουθενά αποθήκευση αρχείων καταγραφής. Λοιπόν, εντάξει, ας προσπαθήσουμε να προσθέσουμε την επιλογή φόρτωσης του πυρήνα έτσι ώστε να σταλούν τα αρχεία καταγραφής. Αλλά όχι, πόσο περίπλοκα είναι όλα.
Ημέρα #0: Αναγνωρίστε το πρόβλημα
Ήταν η συνήθης υποδομή ανάπτυξης: jenkins, δοκιμαστικά περιβάλλοντα, παρακολούθηση, μητρώο. Το CoreOS σχεδιάστηκε για τη φιλοξενία συμπλεγμάτων k8s, δηλ. το πρόβλημα ήταν πώς χρησιμοποιήθηκε το CoreOS. Το πρώτο βήμα ήταν η επιλογή μιας στοίβας. Καταλήξαμε στο:
- CentOS ως κατανομή βάσης, επειδή Αυτή είναι η πλησιέστερη διανομή σε περιβάλλοντα παραγωγής.
- Πιθανό για διαχείριση διαμόρφωσης, επειδή έγινε εκτενής εξέταση.
- Jenkins ως πλαίσιο για την αυτοματοποίηση των υφιστάμενων διαδικασιών, επειδή έχει ήδη χρησιμοποιηθεί ενεργά για διαδικασίες ανάπτυξης
- Hyper-V ως πλατφόρμα εικονικοποίησης. Υπάρχουν διάφοροι λόγοι που ξεπερνούν το εύρος της ιστορίας, αλλά με λίγα λόγια - δεν μπορούμε να χρησιμοποιήσουμε τα σύννεφα, πρέπει να χρησιμοποιήσουμε το δικό μας υλικό.
Ημέρα Νο 30: Διόρθωση υφιστάμενων συμφωνιών - Συμφωνίες ως Κώδικας
Όταν η στοίβα ήταν καθαρή, άρχισαν οι προετοιμασίες για τη μετακόμιση. Διόρθωση υφιστάμενων συμφωνιών με τη μορφή κώδικα (Συμφωνίες ως Κώδικας!). Μετάβαση χειρωνακτική εργασία -> μηχανοποίηση -> αυτοματοποίηση.
1. Διαμόρφωση εικονικών μηχανών
Ο Ansible κάνει εξαιρετική δουλειά σε αυτό. Με ελάχιστες κινήσεις του σώματος μπορείτε να πάρετε τον έλεγχο των διαμορφώσεων VM:
- Δημιουργήστε ένα αποθετήριο git.
- Βάζουμε τη λίστα με τα VM στο απόθεμα, τις διαμορφώσεις στα playbooks και τους ρόλους.
- Δημιουργούμε ένα ειδικό jenkins slave από το οποίο μπορείτε να εκτελέσετε το Ansible.
- Δημιουργούμε μια εργασία και διαμορφώνουμε τον Jenkins.
Η πρώτη διαδικασία είναι έτοιμη. Οι συμφωνίες είναι σταθερές.
2. Δημιουργήστε νέο VM
Όλα εδώ δεν ήταν πολύ βολικά. Δεν είναι πολύ βολικό να δημιουργείτε VM σε Hyper-V από Linux. Μία από τις προσπάθειες μηχανοποίησης αυτής της διαδικασίας ήταν:
- Το Ansbile συνδέεται μέσω WinRM στον κεντρικό υπολογιστή των Windows.
- Το Ansible εκτελεί ένα σενάριο powershell.
- Το σενάριο Powershell δημιουργεί ένα νέο VM.
- Χρησιμοποιώντας Hyper-V/ScVMM, κατά τη δημιουργία ενός VM στο λειτουργικό σύστημα επισκέπτη, διαμορφώνεται το όνομα κεντρικού υπολογιστή.
- Κατά την ενημέρωση της μίσθωσης DHCP, το VM στέλνει το όνομα κεντρικού υπολογιστή του.
- Η τυπική ενσωμάτωση ddns & dhcp στην πλευρά του ελεγκτή τομέα διαμορφώνει την εγγραφή DNS.
- Μπορείτε να προσθέσετε ένα VM στο απόθεμά σας και να το διαμορφώσετε με το Ansible.
3.Δημιουργήστε πρότυπο VM
Δεν επινόησαν τίποτα εδώ - πήραν ένα συσκευαστή.
- Προσθέστε το Packer, kickstart config στο αποθετήριο git.
- Ρύθμιση ενός ειδικού jenkins slave με hyper-v και Packer.
- Δημιουργούμε μια εργασία και διαμορφώνουμε τον Jenkins.
Πώς λειτουργεί αυτός ο σύνδεσμος:
- Ο Packer δημιουργεί ένα κενό VM και λαμβάνει το ISO.
- Όταν εκκινεί το VM, ο Packer εισάγει την εντολή στο bootloader για χρήση του αρχείου μας kickstart από δισκέτα ή http.
- Το Anaconda εκκινείται με τις παραμέτρους μας και έχει ολοκληρωθεί η αρχική διαμόρφωση του λειτουργικού συστήματος.
- Ο Packer περιμένει να γίνει διαθέσιμο το VM.
- Ο συσκευαστής μέσα στο VM εκτελείται σε τοπική λειτουργία.
- Το Ansible χρησιμοποιεί ακριβώς τους ίδιους ρόλους που λειτουργεί στο βήμα #1.
- Το Packer εξάγει το πρότυπο VM.
Ημέρα #75: Επαναφέρετε τη συμφωνία χωρίς να σπάσετε = Test ansible + Testkitchen
Η καταγραφή συμβάσεων σε κώδικα μπορεί να μην είναι αρκετή. Άλλωστε, αν στα μέσα και έξω της διαδικασίας θέλεις να αλλάξεις κάτι, μπορείς να σπάσεις κάτι. Επομένως, στην περίπτωση της υποδομής, εμφανίζεται η δοκιμή αυτής ακριβώς της υποδομής. Για να συγχρονίσουμε τη γνώση μέσα στην ομάδα, αρχίσαμε να δοκιμάζουμε ρόλους του Ansible. Δεν θα μπω σε βάθος γιατί… υπάρχει ένα άρθρο που περιγράφει τα γεγονότα εκείνη τη στιγμή (σπόιλερ αυτή δεν ήταν η τελική έκδοση και αργότερα όλα έγιναν πιο περίπλοκα ).
Ημέρα #130: Ίσως το CentOS+ansible δεν χρειάζεται; ίσως openshift;
Πρέπει να καταλάβουμε ότι η διαδικασία εισαγωγής των υποδομών δεν ήταν η μοναδική και υπήρχαν παράπλευρα υποέργα. Για παράδειγμα, ήρθε ένα αίτημα να ξεκινήσει η εφαρμογή μας σε openshift και αυτό είχε ως αποτέλεσμα την έρευνα για περισσότερο από μία εβδομάδα που επιβράδυνε τη διαδικασία μετακίνησης. Το αποτέλεσμα αποδείχθηκε ότι το openshift δεν καλύπτει όλες τις ανάγκες· χρειάζεστε πραγματικό υλικό ή τουλάχιστον τη δυνατότητα να παίξετε με τον πυρήνα.
Ημέρα #170: Το Openshift δεν είναι κατάλληλο, ας πάρουμε μια ευκαιρία με το Windows Azure Pack;
Το Hyper-V δεν είναι πολύ φιλικό, το SCVMM δεν το κάνει πολύ καλύτερο. Αλλά υπάρχει κάτι όπως το Windows Azure Pack, το οποίο είναι ένα πρόσθετο στο SCVMM και μιμείται το Azure. Αλλά στην πραγματικότητα, το προϊόν φαίνεται εγκαταλελειμμένο: η τεκμηρίωση έχει κατεστραμμένους συνδέσμους και είναι πολύ αραιή. Αλλά ως μέρος της μελέτης των επιλογών για την απλούστευση της ζωής του σύννεφου μας, το εξέτασαν επίσης.
Ημέρα #250: Το πακέτο Windows Azure δεν είναι πολύ καλό. Παραμένουμε στο SCVMM
Το Windows Azure Pack φαινόταν πολλά υποσχόμενο, αλλά αποφασίστηκε να μην εισαχθεί το WAP με την πολυπλοκότητά του στο σύστημα για λόγους περιττών λειτουργιών και παρέμεινε στο SCVMM.
Ημέρα #360: Τρώγοντας τον ελέφαντα κομμάτι-κομμάτι
Μόλις ένα χρόνο αργότερα η πλατφόρμα για τη μετακόμιση ήταν έτοιμη και η διαδικασία μετακόμισης ξεκίνησε. Για το σκοπό αυτό, ορίστηκε μια εργασία SMART. Ελέγξαμε όλα τα VM και αρχίσαμε να βρίσκουμε τη διαμόρφωση μία προς μία, να την περιγράφουμε στο Ansible και να την καλύπτουμε με δοκιμές.
Ημέρα #450: Τι είδους σύστημα αποκτήσατε;
Η ίδια η διαδικασία δεν είναι ενδιαφέρουσα. Είναι ρουτίνα, μπορεί να σημειωθεί ότι οι περισσότερες διαμορφώσεις ήταν σχετικά απλές ή ισόμορφες και σύμφωνα με την αρχή Pareto, το 80% των διαμορφώσεων VM απαιτούσαν το 20% του χρόνου. Με την ίδια αρχή, το 80% του χρόνου αφιερώθηκε στην προετοιμασία της μετακόμισης και μόνο το 20% στην ίδια την κίνηση.
Ημέρα #540: Τελικός
Τι έγινε σε 18 μήνες;
- Οι συμφωνίες έγιναν κώδικας.
- Χειρωνακτική εργασία -> Μηχανοποίηση -> Αυτοματοποίηση.
Links
Πηγή: www.habr.com