ansible devops codestyle
Γεια σου! Το όνομά μου είναι Εργάζομαι ως μηχανικός στο τμήμα αυτοματισμού διαδικασιών ανάπτυξης. Κάθε μέρα, νέες εκδόσεις εφαρμογών κυκλοφορούν σε εκατοντάδες διακομιστές καμπάνιας. Και σε αυτό το άρθρο, μοιράζομαι την εμπειρία μου από τη χρήση του Ansible για αυτούς τους σκοπούς.
Αυτός ο οδηγός προσφέρει έναν τρόπο οργάνωσης μεταβλητών σε μια ανάπτυξη. Αυτός ο οδηγός έχει σχεδιαστεί για όσους χρησιμοποιούν ήδη ρόλους στα βιβλία τους και διαβάζουν αλλά αντιμετωπίζει παρόμοια προβλήματα:
- Έχοντας βρει μια μεταβλητή στον κώδικα, είναι αδύνατο να καταλάβουμε αμέσως για τι ευθύνεται.
- Υπάρχουν αρκετοί ρόλοι και οι μεταβλητές πρέπει να συσχετιστούν με μία τιμή, αλλά δεν λειτουργεί.
- Δυσκολεύεστε να εξηγήσετε σε άλλους πώς λειτουργεί η λογική των μεταβλητών στα βιβλία σας
Αντιμετωπίσαμε αυτά τα προβλήματα σε έργα στην εταιρεία μας, με αποτέλεσμα να καταλήξουμε στους κανόνες για τη μορφοποίηση μεταβλητών στα βιβλία μας, που σε κάποιο βαθμό έλυσαν αυτά τα προβλήματα.
Μεταβλητές σε ρόλους
Ένας ρόλος είναι ένα ξεχωριστό αντικείμενο συστήματος ανάπτυξης. Όπως κάθε αντικείμενο του συστήματος, πρέπει να έχει μια διεπαφή για την αλληλεπίδραση με το υπόλοιπο σύστημα. Οι μεταβλητές ρόλου είναι μια τέτοια διεπαφή.
Πάρτε, για παράδειγμα, τον ρόλο api, το οποίο εγκαθιστά μια εφαρμογή Java στον διακομιστή. Τι μεταβλητές έχει;
Οι μεταβλητές ρόλου μπορούν να χωριστούν σε 2 τύπους ανά τύπο:
1. Свойства
a) независимые от среды
б) зависимые от среды
2. Связи
a) слушатели
б) запросы внутри системы
в) запросы в среду
Μεταβλητές ιδιότητες είναι μεταβλητές που καθορίζουν τη συμπεριφορά ενός ρόλου.
Μεταβλητές ερωτήματος είναι μεταβλητές των οποίων η τιμή χρησιμοποιείται για τον προσδιορισμό πόρων εκτός του ρόλου.
Μεταβλητοί ακροατές είναι μεταβλητές των οποίων η τιμή χρησιμοποιείται για τον σχηματισμό μεταβλητών ερωτήματος.
Από την άλλη πλευρά, τα 1a, 2a, 2b είναι μεταβλητές που δεν εξαρτώνται από το περιβάλλον (σίδερο, εξωτερικούς πόρους κ.λπ.) και μπορούν να συμπληρωθούν με προεπιλεγμένες τιμές στον προεπιλεγμένο ρόλο. Ωστόσο, μεταβλητές όπως 1.b και 2.c δεν μπορούν να συμπληρωθούν με άλλες τιμές εκτός από το «παράδειγμα», καθώς θα αλλάζουν από στάση σε βάση ανάλογα με το περιβάλλον.
στυλ κώδικα
- Το όνομα της μεταβλητής πρέπει να ξεκινά με το όνομα του ρόλου. Αυτό θα διευκολύνει στο μέλλον να καταλάβουμε από ποιον ρόλο προέρχεται η μεταβλητή και για τι είναι υπεύθυνη.
- Όταν χρησιμοποιείτε μεταβλητές σε ρόλους, πρέπει να φροντίζετε να ακολουθείτε την αρχή της ενθυλάκωσης και να χρησιμοποιείτε μεταβλητές που ορίζονται είτε στον ίδιο τον ρόλο είτε στους ρόλους από τους οποίους εξαρτάται ο τρέχων.
-
Αποφύγετε τη χρήση λεξικών για μεταβλητές. Το Ansible δεν σας επιτρέπει να παρακάμπτετε εύκολα μεμονωμένες τιμές σε ένα λεξικό.
Ένα παράδειγμα κακής μεταβλητής:
myrole_user: login: admin password: adminΕδώ, το login είναι η διάμεση μεταβλητή και ο κωδικός είναι η εξαρτημένη μεταβλητή. Αλλά
Εφόσον συνδυάζονται σε ένα λεξικό, θα πρέπει να το προσδιορίσετε πλήρως
Πάντα. Το οποίο είναι πολύ άβολο. Καλύτερα με αυτόν τον τρόπο:myrole_user_login: admin myrole_user_password: admin
Μεταβλητές στα βιβλία ανάπτυξης ανάπτυξης
Κατά τη σύνταξη ενός βιβλίου αναπαραγωγής ανάπτυξης (στο εξής θα αναφέρεται ως playbook), τηρούμε τον κανόνα ότι πρέπει να τοποθετείται σε ξεχωριστό αποθετήριο. Ακριβώς όπως οι ρόλοι: ο καθένας στο δικό του αποθετήριο git. Αυτό σας επιτρέπει να συνειδητοποιήσετε ότι οι ρόλοι και το βιβλίο παιχνιδιού είναι διαφορετικά ανεξάρτητα αντικείμενα του συστήματος ανάπτυξης και οι αλλαγές σε ένα αντικείμενο δεν πρέπει να επηρεάζουν τη λειτουργία του άλλου. Αυτό επιτυγχάνεται αλλάζοντας τις προεπιλεγμένες τιμές των μεταβλητών.
Κατά τη σύνταξη ενός βιβλίου παιχνιδιού, για να συνοψίσουμε, είναι δυνατή η παράκαμψη των προεπιλεγμένων τιμών των μεταβλητών ρόλου σε δύο μέρη: στις μεταβλητές του βιβλίου παιχνιδιού και στις μεταβλητές αποθέματος.
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ └── myapi.yml # Файл переменных свойств группы myapi
└── inventories #
└── prod # Каталог окружения prod
├── prod.ini # Инвентори файл
└── group_vars # Каталог для переменных инвентори
└── myapi #
├── vars.yml # Средозависимые переменные группы myapi
└── vault.yml # Секреты (всегда средозависимы) ** -
Η διαφορά είναι ότι οι μεταβλητές του playbook χρησιμοποιούνται πάντα κατά την κλήση βιβλίων που βρίσκονται στο ίδιο επίπεδο με αυτό. Αυτό σημαίνει ότι αυτές οι μεταβλητές είναι εξαιρετικές για την αλλαγή των προεπιλεγμένων τιμών των μεταβλητών που δεν εξαρτώνται από το περιβάλλον. Αντίθετα, οι μεταβλητές αποθέματος θα χρησιμοποιούνται μόνο για ένα συγκεκριμένο περιβάλλον, το οποίο είναι ιδανικό για μεταβλητές που σχετίζονται με το περιβάλλον.
Είναι σημαντικό να σημειωθεί ότι η προτεραιότητα μεταβλητών δεν θα σας επιτρέψει να επαναπροσδιορίσετε τις μεταβλητές πρώτα στις μεταβλητές του βιβλίου παιχνιδιού και στη συνέχεια ξεχωριστά στο ίδιο απόθεμα.
Αυτό σημαίνει ότι ήδη σε αυτό το στάδιο πρέπει να αποφασίσετε εάν η μεταβλητή εξαρτάται από το περιβάλλον ή όχι και να την τοποθετήσετε στη σωστή θέση.
Για παράδειγμα, σε ένα έργο, η μεταβλητή που ήταν υπεύθυνη για την ενεργοποίηση του SSL ήταν εξαρτώμενη από το περιβάλλον για μεγάλο χρονικό διάστημα, καθώς δεν μπορούσαμε να ενεργοποιήσουμε το SSL για λόγους που δεν ελέγχουμε σε ένα από τα περίπτερα. Αφού επιλύσαμε αυτό το ζήτημα, έγινε μεσαίο ανεξάρτητο και μεταφέρθηκε στις μεταβλητές του βιβλίου αναπαραγωγής.
Μεταβλητές Ιδιότητας για Ομάδες
Ας επεκτείνουμε το μοντέλο μας στο Σχήμα 1 προσθέτοντας 2 ομάδες διακομιστών με διαφορετική εφαρμογή Java, αλλά με διαφορετικές ρυθμίσεις.
Φανταστείτε πώς θα είναι το playbook σε αυτήν την περίπτωση:
- hosts: myapi
roles:
- api
- hosts: bbauth
roles:
- auth
- hosts: ghauth
roles:
- authΈχουμε τρεις ομάδες στο playbook, επομένως συνιστάται να δημιουργήσετε τόσα αρχεία ομάδας σε μεταβλητές αποθέματος group_vars και μεταβλητές βιβλίου αναπαραγωγής ταυτόχρονα. Ένα αρχείο ομάδας σε αυτήν την περίπτωση είναι η περιγραφή ενός στοιχείου της εφαρμογής σας στο βιβλίο αναπαραγωγής. Όταν ανοίγετε το αρχείο ομάδας στις μεταβλητές του playbook, βλέπετε αμέσως όλες τις διαφορές από την προεπιλεγμένη συμπεριφορά των ρόλων που έχουν εκχωρηθεί στην ομάδα. Στις μεταβλητές αποθέματος: διαφορές στη συμπεριφορά της ομάδας από περίπτερο σε θάλαμο.
Στυλ Κώδικα
- Προσπαθήστε να μην χρησιμοποιήσετε καθόλου μεταβλητές host_vars, καθώς δεν περιγράφουν το σύστημα, αλλά μόνο μια ειδική περίπτωση, η οποία μακροπρόθεσμα θα οδηγήσει σε ερωτήσεις: "Γιατί αυτός ο κεντρικός υπολογιστής διαφέρει από τους υπόλοιπους;", Η απάντηση στην οποία είναι δεν είναι πάντα εύκολο να βρεθεί.
Σύνδεση μεταβλητών
Ωστόσο, πρόκειται για μεταβλητές ιδιοτήτων, αλλά τι γίνεται με τις μεταβλητές συνδέσμου;
Η διαφορά τους είναι ότι πρέπει να έχουν την ίδια αξία σε διαφορετικές ομάδες.
Στην αρχή υπήρχε χρησιμοποιήστε μια τερατώδη κατασκευή της φόρμας:
hostvars[groups['bbauth'][0]]['auth_bind_port'], αλλά εγκαταλείφθηκε αμέσως
γιατί έχει ελαττώματα. Πρώτον, ο όγκος. Δεύτερον, η εξάρτηση από έναν συγκεκριμένο οικοδεσπότη στην ομάδα. Τρίτον, είναι απαραίτητο να συλλέξουμε στοιχεία από όλους τους κεντρικούς υπολογιστές πριν από την έναρξη της ανάπτυξης, εάν δεν θέλουμε να λάβουμε ένα απροσδιόριστο σφάλμα μεταβλητής.
Ως αποτέλεσμα, αποφασίστηκε η χρήση μεταβλητών συνδέσμων.
Σύνδεση μεταβλητών είναι μεταβλητές που ανήκουν στο playbook και χρειάζονται για τη σύνδεση αντικειμένων συστήματος.
Οι μεταβλητές συνδέσμου συμπληρώνονται σε γενικές μεταβλητές συστήματος group_vars/all/vars και σχηματίζονται αφαιρώντας όλες τις μεταβλητές ακροατή από κάθε ομάδα και προσθέτοντας το όνομα της ομάδας από την οποία αφαιρέθηκε ο ακροατής στην αρχή της μεταβλητής.
Έτσι διασφαλίζεται η ομοιομορφία και η μη διασταύρωση των ονομάτων.
Ας προσπαθήσουμε να δεσμεύσουμε μεταβλητές από το παραπάνω παράδειγμα:
Φανταστείτε ότι έχουμε μεταβλητές που εξαρτώνται η μία από την άλλη:
# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"
# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"Ας το βάλουμε σε κοινές μεταβλητές group_vars/all/vars όλους τους ακροατές και προσθέστε το όνομα της ομάδας στο όνομα:
# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"
# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"
# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"
# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"Τώρα, αλλάζοντας την τιμή του συνδέσμου, θα είμαστε σίγουροι ότι το αίτημα θα πάει στην ίδια θύρα.
Στυλ Κώδικα
- Δεδομένου ότι οι ρόλοι και οι ομάδες είναι διαφορετικά αντικείμενα στο σύστημα, πρέπει να έχετε διαφορετικά ονόματα για αυτά, τότε οι μεταβλητές συνδέσμου θα δείξουν με ακρίβεια ότι ανήκουν σε μια συγκεκριμένη ομάδα διακομιστών και όχι σε έναν ρόλο στο σύστημα.
Αρχεία περιβάλλοντος
Οι ρόλοι μπορούν να χρησιμοποιούν αρχεία που διαφέρουν από περιβάλλον σε περιβάλλον.
Τα πιστοποιητικά SSL είναι ένα παράδειγμα τέτοιων αρχείων. Αποθηκεύστε τα ως κείμενο
σε μια μεταβλητή δεν είναι πολύ βολικό. Αλλά είναι βολικό να αποθηκεύσετε τη διαδρομή προς αυτά μέσα σε μια μεταβλητή.
Για παράδειγμα, χρησιμοποιούμε τη μεταβλητή api_ssl_key_file: "/path/to/file".
Δεδομένου ότι είναι προφανές ότι το πιστοποιητικό κλειδιού θα αλλάζει από περιβάλλον σε περιβάλλον, αυτή είναι μια μεταβλητή που εξαρτάται από το περιβάλλον, πράγμα που σημαίνει ότι πρέπει να βρίσκεται στο αρχείο
group_vars/myapi/vars απόθεμα μεταβλητών και περιέχει την τιμή «για παράδειγμα».
Ο πιο βολικός τρόπος σε αυτήν την περίπτωση είναι να τοποθετήσετε το αρχείο κλειδιού στο χώρο αποθήκευσης του βιβλίου αναπαραγωγής κατά μήκος της διαδρομής
files/prod/certs/myapi.key, τότε η τιμή της μεταβλητής θα είναι:
api_ssl_key_file: "prod/certs/myapi.key". Η ευκολία έγκειται στο γεγονός ότι τα άτομα που είναι υπεύθυνα για την ανάπτυξη του συστήματος σε μια συγκεκριμένη βάση έχουν επίσης τη δική τους ειδική θέση στο αποθετήριο για την αποθήκευση των αρχείων τους. Ταυτόχρονα, παραμένει δυνατός ο καθορισμός της απόλυτης διαδρομής προς το πιστοποιητικό στον διακομιστή, σε περίπτωση που τα πιστοποιητικά παρέχονται από άλλο σύστημα.
Πολλαπλές βάσεις σε ένα περιβάλλον
Συχνά υπάρχει ανάγκη ανάπτυξης πολλών σχεδόν πανομοιότυπων στάσεων στο ίδιο περιβάλλον με ελάχιστες διαφορές. Σε αυτήν την περίπτωση, διαιρούμε τις μεταβλητές που εξαρτώνται από το περιβάλλον σε αυτές που δεν αλλάζουν σε αυτό το περιβάλλον και σε αυτές που αλλάζουν. Και βγάζουμε το τελευταίο απευθείας στα ίδια τα αρχεία απογραφής. Μετά από αυτόν τον χειρισμό, καθίσταται δυνατή η δημιουργία άλλου αποθέματος απευθείας στον κατάλογο περιβάλλοντος.
Θα επαναχρησιμοποιήσει το απόθεμα group_vars και θα μπορεί επίσης να επαναπροσδιορίσει ορισμένες μεταβλητές απευθείας για τον εαυτό του.
Η τελική δομή καταλόγου για το έργο ανάπτυξης:
mydeploy # Каталог деплоя
├── deploy.yml # Плейбук деплоя
├── files # Каталог для файлов деплоя
│ ├── prod # Католог для средозависимых файлов стенда prod
│ │ └── certs #
│ │ └── myapi.key #
│ └── test1 # Каталог для средозависимых файлов стенда test1
├── group_vars # Каталог переменных плейбука
│ ├── all.yml # Файл для переменных связи всей системы
│ ├── myapi.yml # Файл переменных свойств группы myapi
│ ├── bbauth.yml #
│ └── ghauth.yml #
└── inventories #
├── prod # Каталог окружения prod
│ ├── group_vars # Каталог для переменных инвентори
│ │ ├── myapi #
│ │ │ ├── vars.yml # Средозависимые переменные группы myapi
│ │ │ └── vault.yml # Секреты (всегда средозависимы)
│ │ ├── bbauth #
│ │ │ ├── vars.yml #
│ │ │ └── vault.yml #
│ │ └── ghauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── prod.ini # Инвентори стенда prod
└── test # Каталог окружения test
├── group_vars #
│ ├── myapi #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ ├── bbauth #
│ │ ├── vars.yml #
│ │ └── vault.yml #
│ └── ghauth #
│ ├── vars.yml #
│ └── vault.yml #
├── test1.ini # Инвентори стенда test1 в среде test
└── test2.ini # Инвентори стенда test2 в среде testΑνακεφαλαίωση
Μετά την οργάνωση των μεταβλητών σύμφωνα με το άρθρο: κάθε αρχείο με μεταβλητές είναι υπεύθυνο για μια συγκεκριμένη εργασία. Και δεδομένου ότι το αρχείο έχει ορισμένες εργασίες, κατέστη δυνατή η ανάθεση ενός ατόμου υπεύθυνου για την ορθότητα κάθε αρχείου. Για παράδειγμα, ο προγραμματιστής της ανάπτυξης συστήματος γίνεται υπεύθυνος για τη σωστή συμπλήρωση των μεταβλητών του playbook, ενώ ο διαχειριστής, του οποίου η στάση περιγράφεται στο απόθεμα, είναι άμεσα υπεύθυνος για τη συμπλήρωση του αποθέματος των μεταβλητών.
Οι ρόλοι έγιναν μια αυτόνομη μονάδα ανάπτυξης με τη δική τους διεπαφή, επιτρέποντας στον προγραμματιστή ρόλων να αναπτύξει χαρακτηριστικά αντί να προσαρμόσει τον ρόλο ώστε να ταιριάζει στο σύστημα. Αυτό το ζήτημα ίσχυε ιδιαίτερα για κοινούς ρόλους για όλα τα συστήματα σε μια καμπάνια.
Οι διαχειριστές συστήματος δεν χρειάζεται πλέον να κατανοούν τον κώδικα ανάπτυξης. Το μόνο που απαιτείται από αυτούς για μια επιτυχημένη ανάπτυξη είναι να συμπληρώσουν τα αρχεία των μεταβλητών περιβάλλοντος.
Λογοτεχνία
Συγγραφέας
Καλιούζνι Ντένις Αλεξάντροβιτς
Πηγή: www.habr.com