Προσέγγιση IaC (Infrastructure as Code) δεν αποτελείται μόνο από τον κώδικα που είναι αποθηκευμένος στο αποθετήριο, αλλά και από τα άτομα και τις διαδικασίες που περιβάλλουν αυτόν τον κώδικα. Είναι δυνατή η επαναχρησιμοποίηση προσεγγίσεων από την ανάπτυξη λογισμικού έως τη διαχείριση και την περιγραφή υποδομής; Θα ήταν καλή ιδέα να έχετε κατά νου αυτή την ιδέα ενώ διαβάζετε το άρθρο.
Αυτή είναι μια μεταγραφή μου επί .
Διαφάνειες και βίντεο
- Ξηρό τρέξιμο 2019-04-24
Η υποδομή ως ιστορία bash
Ας υποθέσουμε ότι έρχεστε σε ένα νέο έργο και σας λένε: «έχουμε Υποδομή ως Κώδικας". Στην πραγματικότητα αποδεικνύεται Η υποδομή ως ιστορία bash ή για παράδειγμα Τεκμηρίωση ως ιστορία bash. Αυτή είναι μια πολύ πραγματική κατάσταση, για παράδειγμα, μια παρόμοια περίπτωση περιέγραψε ο Denis Lysenko σε μια ομιλία του , είπε πώς απέκτησαν μια συνεκτική υποδομή για το έργο από την ιστορία του bash.
Με κάποια επιθυμία, μπορούμε να το πούμε αυτό Η υποδομή ως ιστορία bash αυτό είναι σαν κώδικας:
- αναπαραγωγιμότητα: Μπορείτε να πάρετε το ιστορικό bash, να εκτελέσετε τις εντολές από εκεί και ίσως, παρεμπιπτόντως, να λάβετε μια λειτουργική διαμόρφωση ως έξοδο.
- εκδόσεις: ξέρετε ποιοι μπήκαν και τι έκαναν, και πάλι, δεν είναι γεγονός ότι αυτό θα σας οδηγήσει σε μια λειτουργική διαμόρφωση στην έξοδο.
- Ιστορία: η ιστορία του ποιος έκανε τι. μόνο που δεν θα μπορείτε να το χρησιμοποιήσετε εάν χάσετε τον διακομιστή.
Τι πρέπει να κάνω;
Υποδομή ως Κώδικας
Ακόμη και μια τέτοια περίεργη περίπτωση όπως Η υποδομή ως ιστορία bash μπορείτε να το τραβήξετε από τα αυτιά Υποδομή ως Κώδικας, αλλά όταν θέλουμε να κάνουμε κάτι πιο περίπλοκο από τον παλιό καλό διακομιστή LAMP, θα καταλήξουμε στο συμπέρασμα ότι αυτός ο κώδικας πρέπει με κάποιο τρόπο να τροποποιηθεί, να αλλάξει, να βελτιωθεί. Στη συνέχεια θα θέλαμε να εξετάσουμε τους παραλληλισμούς μεταξύ τους Υποδομή ως Κώδικας και ανάπτυξη λογισμικού.
ΞΗΡΟΣ
Σε ένα έργο ανάπτυξης συστήματος αποθήκευσης, υπήρχε μια δευτερεύουσα εργασία : κυκλοφορούμε μια νέα έκδοση - πρέπει να κυκλοφορήσει για περαιτέρω δοκιμή. Η εργασία είναι εξαιρετικά απλή:
- συνδεθείτε εδώ μέσω ssh και εκτελέστε την εντολή.
- αντιγράψτε το αρχείο εκεί.
- διορθώστε τις ρυθμίσεις εδώ.
- ξεκινήστε την υπηρεσία εκεί
- ...
- ΚΕΡΔΟΣ!
Για την περιγραφόμενη λογική, το bash είναι υπεραρκετό, ειδικά στα αρχικά στάδια του έργου, όταν μόλις ξεκινά. Αυτό , αλλά με την πάροδο του χρόνου υπάρχουν αιτήματα για ανάπτυξη κάτι παρόμοιο, αλλά ελαφρώς διαφορετικό. Το πρώτο πράγμα που έρχεται στο μυαλό είναι το copy-paste. Και τώρα έχουμε ήδη δύο πολύ παρόμοια σενάρια που κάνουν σχεδόν το ίδιο πράγμα. Με την πάροδο του χρόνου, ο αριθμός των σεναρίων μεγάλωσε και βρεθήκαμε αντιμέτωποι με το γεγονός ότι υπάρχει μια συγκεκριμένη επιχειρηματική λογική για την ανάπτυξη μιας εγκατάστασης που πρέπει να συγχρονιστεί μεταξύ διαφορετικών σεναρίων, αυτό είναι αρκετά περίπλοκο.
Αποδεικνύεται ότι υπάρχει μια τέτοια πρακτική όπως το DRY (Do not Repeat Yourself). Η ιδέα είναι να επαναχρησιμοποιηθεί ο υπάρχων κώδικας. Ακούγεται απλό, αλλά δεν καταλήξαμε σε αυτό αμέσως. Στην περίπτωσή μας, ήταν μια μπανάλ ιδέα: ο διαχωρισμός των ρυθμίσεων από τα σενάρια. Εκείνοι. επιχειρηματική λογική του τρόπου με τον οποίο η εγκατάσταση αναπτύσσεται χωριστά, διαμορφώνει ξεχωριστά.
SOLID για CFM
Με τον καιρό το έργο μεγάλωσε και ήταν η εμφάνιση του Ansible. Ο κύριος λόγος για την εμφάνισή του είναι ότι υπάρχει τεχνογνωσία στην ομάδα και ότι το bash δεν έχει σχεδιαστεί για πολύπλοκη λογική. Ο Ansible άρχισε επίσης να περιέχει πολύπλοκη λογική. Για να αποφευχθεί η μετατροπή της πολύπλοκης λογικής σε χάος, υπάρχουν αρχές για την οργάνωση κώδικα στην ανάπτυξη λογισμικού ΣΤΕΡΕΟΣ Επίσης, για παράδειγμα, ο Grigory Petrov στην έκθεση «Γιατί ένας ειδικός πληροφορικής χρειάζεται μια προσωπική επωνυμία» έθεσε το ερώτημα ότι ένα άτομο έχει σχεδιαστεί με τέτοιο τρόπο ώστε να είναι ευκολότερο γι 'αυτόν να συνεργαστεί με ορισμένες κοινωνικές οντότητες, στην ανάπτυξη λογισμικού. είναι αντικείμενα. Αν συνδυάσουμε αυτές τις δύο ιδέες και συνεχίσουμε να τις αναπτύσσουμε, θα παρατηρήσουμε ότι μπορούμε επίσης να χρησιμοποιήσουμε ΣΤΕΡΕΟΣ για να διευκολυνθεί η διατήρηση και τροποποίηση αυτής της λογικής στο μέλλον.
Η Αρχή της Ενιαίας Ευθύνης
Κάθε τάξη εκτελεί μόνο μία εργασία.
Δεν χρειάζεται να ανακατεύετε κώδικα και να κάνετε μονολιθικά θεϊκά τέρατα σπαγγέτι. Η υποδομή θα πρέπει να αποτελείται από απλά τούβλα. Αποδεικνύεται ότι αν χωρίσετε το βιβλίο παιχνιδιού Ansible σε μικρά κομμάτια, διαβάσετε ρόλους Ansible, τότε είναι πιο εύκολο να διατηρηθούν.
Η αρχή του ανοιχτού κλειστού
Αρχή ανοιχτού/κλειστού.
- Open to extension: σημαίνει ότι η συμπεριφορά μιας οντότητας μπορεί να επεκταθεί δημιουργώντας νέους τύπους οντοτήτων.
- Κλειστό για αλλαγή: Ως αποτέλεσμα της επέκτασης της συμπεριφοράς μιας οντότητας, δεν πρέπει να γίνονται αλλαγές στον κώδικα που χρησιμοποιεί αυτές τις οντότητες.
Αρχικά, αναπτύξαμε τη δοκιμαστική υποδομή σε εικονικές μηχανές, αλλά λόγω του γεγονότος ότι η επιχειρηματική λογική της ανάπτυξης ήταν ξεχωριστή από την υλοποίηση, προσθέσαμε το roll out στο baremetall χωρίς κανένα πρόβλημα.
Η αρχή της αντικατάστασης Liskov
Η αρχή της αντικατάστασης της Barbara Liskov. τα αντικείμενα σε ένα πρόγραμμα πρέπει να μπορούν να αντικατασταθούν με παρουσίες των υποτύπων τους χωρίς αλλαγή της σωστής εκτέλεσης του προγράμματος
Αν το δεις ευρύτερα, δεν είναι χαρακτηριστικό κάποιου συγκεκριμένου έργου που μπορεί να εφαρμοστεί εκεί ΣΤΕΡΕΟΣ, γενικά αφορά το CFM, για παράδειγμα, σε ένα άλλο έργο είναι απαραίτητο να αναπτυχθεί μια εφαρμογή Java σε κουτί πάνω από διάφορα Java, διακομιστές εφαρμογών, βάσεις δεδομένων, λειτουργικό σύστημα κ.λπ. Χρησιμοποιώντας αυτό το παράδειγμα, θα εξετάσω περαιτέρω αρχές ΣΤΕΡΕΟΣ
Στην περίπτωσή μας, υπάρχει συμφωνία εντός της ομάδας υποδομής ότι εάν έχουμε εγκαταστήσει το ρόλο imbjava ή oraclejava, τότε έχουμε ένα εκτελέσιμο δυαδικό αρχείο java. Αυτό είναι απαραίτητο γιατί Οι ανοδικοί ρόλοι εξαρτώνται από αυτήν τη συμπεριφορά· περιμένουν java. Ταυτόχρονα, αυτό μας επιτρέπει να αντικαταστήσουμε μια υλοποίηση/έκδοση java με μια άλλη χωρίς να αλλάξουμε τη λογική ανάπτυξης της εφαρμογής.
Το πρόβλημα εδώ έγκειται στο γεγονός ότι είναι αδύνατο να εφαρμοστεί αυτό στο Ansible, με αποτέλεσμα να εμφανίζονται κάποιες συμφωνίες εντός της ομάδας.
Η αρχή του διαχωρισμού διεπαφής
Αρχή διαχωρισμού διεπαφής: «Πολλές διεπαφές ειδικά για πελάτες είναι καλύτερες από μία διεπαφή γενικής χρήσης.
Αρχικά, προσπαθήσαμε να βάλουμε όλη τη μεταβλητότητα της ανάπτυξης εφαρμογών σε ένα Ansible playbook, αλλά ήταν δύσκολο να υποστηριχθεί και η προσέγγιση όταν έχουμε μια εξωτερική διεπαφή καθορίζεται (ο πελάτης αναμένει τη θύρα 443), τότε μια υποδομή μπορεί να συναρμολογηθεί από μεμονωμένα τούβλα για μια συγκεκριμένη υλοποίηση.
Η αρχή της αντιστροφής της εξάρτησης
Η αρχή της αντιστροφής της εξάρτησης. Οι ενότητες σε υψηλότερα επίπεδα δεν πρέπει να εξαρτώνται από ενότητες σε χαμηλότερα επίπεδα. Και οι δύο τύποι ενοτήτων πρέπει να εξαρτώνται από αφαιρέσεις. Οι αφαιρέσεις δεν πρέπει να εξαρτώνται από λεπτομέρειες. Οι λεπτομέρειες πρέπει να εξαρτώνται από αφαιρέσεις.
Εδώ το παράδειγμα θα βασίζεται σε ένα αντί-μοτίβο.
- Ένας από τους πελάτες είχε ιδιωτικό σύννεφο.
- Παραγγείλαμε εικονικές μηχανές μέσα στο cloud.
- Ωστόσο, λόγω της φύσης του cloud, η ανάπτυξη εφαρμογών συνδέθηκε με τον hypervisor στον οποίο βρισκόταν το VM.
Εκείνοι. Η λογική ανάπτυξης εφαρμογών υψηλού επιπέδου έρεε με εξαρτήσεις σε χαμηλότερα επίπεδα του hypervisor, και αυτό σήμαινε προβλήματα κατά την επαναχρησιμοποίηση αυτής της λογικής. Μην το κάνετε με αυτόν τον τρόπο.
Αλληλεπίδραση
Η υποδομή ως κώδικας δεν αφορά μόνο τον κώδικα, αλλά και τη σχέση μεταξύ κώδικα και ανθρώπων, με τις αλληλεπιδράσεις μεταξύ των προγραμματιστών υποδομής.
Συντελεστής λεωφορείου
Ας υποθέσουμε ότι έχετε τη Vasya στο έργο σας. Η Βάσια ξέρει τα πάντα για την υποδομή σας, τι θα συμβεί αν η Βάσια εξαφανιστεί ξαφνικά; Αυτή είναι μια πολύ πραγματική κατάσταση, γιατί θα μπορούσε να χτυπηθεί από ένα λεωφορείο. Συμβαίνει μερικές φορές. Εάν συμβεί αυτό και η γνώση σχετικά με τον κώδικα, τη δομή του, τον τρόπο λειτουργίας του, τις εμφανίσεις και τους κωδικούς πρόσβασης δεν διανεμηθεί στην ομάδα, τότε μπορεί να αντιμετωπίσετε μια σειρά από δυσάρεστες καταστάσεις. Για να ελαχιστοποιήσετε αυτούς τους κινδύνους και να διανείμετε τη γνώση μέσα στην ομάδα, μπορείτε να χρησιμοποιήσετε διάφορες προσεγγίσεις
Pair Devopsing
Δεν είναι σαν , ότι οι διαχειριστές έπιναν μπύρα, άλλαξαν κωδικούς πρόσβασης και ένα ανάλογο προγραμματισμού ζεύγους. Εκείνοι. δύο μηχανικοί κάθονται σε έναν υπολογιστή, ένα πληκτρολόγιο και αρχίζουν να ρυθμίζουν την υποδομή σας μαζί: στήνουν έναν διακομιστή, γράφουν έναν ρόλο Ansible κ.λπ. Ακούγεται ωραίο, αλλά δεν λειτούργησε για εμάς. Όμως ειδικές περιπτώσεις αυτής της πρακτικής λειτούργησαν. Έρχεται ένας νέος υπάλληλος, ο μέντοράς του αναλαμβάνει ένα πραγματικό έργο μαζί του, εργάζεται και μεταφέρει γνώση.
Μια άλλη ειδική περίπτωση είναι μια κλήση περιστατικού. Κατά τη διάρκεια ενός προβλήματος, συγκεντρώνεται μια ομάδα από τους εφημερεύοντες και τους εμπλεκόμενους, ορίζεται ένας αρχηγός, ο οποίος μοιράζεται την οθόνη του και εκφράζει το τρένο της σκέψης. Άλλοι συμμετέχοντες ακολουθούν τις σκέψεις του αρχηγού, κατασκοπεύουν κόλπα από την κονσόλα, ελέγχουν ότι δεν έχουν χάσει μια γραμμή στο αρχείο καταγραφής και μαθαίνουν νέα πράγματα για το σύστημα. Αυτή η προσέγγιση λειτούργησε τις περισσότερες φορές.
Επανεξέταση κώδικα
Υποκειμενικά, ήταν πιο αποτελεσματικό να διαδοθεί η γνώση σχετικά με την υποδομή και τον τρόπο λειτουργίας της χρησιμοποιώντας την αναθεώρηση κώδικα:
- Η υποδομή περιγράφεται με κώδικα στο αποθετήριο.
- Οι αλλαγές συμβαίνουν σε ξεχωριστό κλάδο.
- Κατά τη διάρκεια ενός αιτήματος συγχώνευσης, μπορείτε να δείτε το δέλτα των αλλαγών στην υποδομή.
Το αποκορύφωμα εδώ ήταν ότι οι κριτές επιλέχθηκαν ένας προς έναν, σύμφωνα με ένα χρονοδιάγραμμα, δηλ. με κάποιο βαθμό πιθανότητας θα σκαρφαλώσετε σε μια νέα υποδομή.
Στυλ Κώδικα
Με τον καιρό, άρχισαν να εμφανίζονται καβγάδες κατά τη διάρκεια των κριτικών, γιατί... Οι κριτικοί είχαν το δικό τους στυλ και η εναλλαγή των κριτικών τα στοίβαξε με διαφορετικά στυλ: 2 κενά ή 4, camelCase ή snake_case. Δεν ήταν δυνατό να εφαρμοστεί αυτό αμέσως.
- Η πρώτη ιδέα ήταν να προτείνουμε τη χρήση λίτερων, στο κάτω κάτω, όλοι είναι μηχανικοί, όλοι είναι έξυπνοι. Αλλά διαφορετικοί επεξεργαστές, OS, δεν είναι βολικοί
- Αυτό εξελίχθηκε σε ένα ρομπότ που έγραφε χαλαρά για κάθε προβληματική δέσμευση και προσάρτησε την έξοδο λίντερ. Αλλά στις περισσότερες περιπτώσεις υπήρχαν πιο σημαντικά πράγματα να γίνουν και ο κώδικας παρέμενε απροσδιόριστος.
Πράσινο Build Master
Ο χρόνος περνά και καταλήξαμε στο συμπέρασμα ότι οι δεσμεύσεις που δεν περνούν ορισμένες δοκιμές δεν μπορούν να επιτραπούν στον κύριο. Voila! Εφεύραμε το Green Build Master, το οποίο έχει εξασκηθεί στην ανάπτυξη λογισμικού για μεγάλο χρονικό διάστημα:
- Η ανάπτυξη βρίσκεται σε εξέλιξη σε ξεχωριστό κλάδο.
- Εκτελούνται δοκιμές σε αυτό το νήμα.
- Εάν οι δοκιμές αποτύχουν, ο κωδικός δεν θα μπει στο master.
Η λήψη αυτής της απόφασης ήταν πολύ επώδυνη, γιατί... προκάλεσε πολλές διαμάχες, αλλά άξιζε τον κόπο, γιατί... Οι κριτικές άρχισαν να λαμβάνουν αιτήματα για συγχωνεύσεις χωρίς διαφορές στο στυλ και με την πάροδο του χρόνου ο αριθμός των προβληματικών περιοχών άρχισε να μειώνεται.
Δοκιμή IaC
Εκτός από τον έλεγχο στυλ, μπορείτε να χρησιμοποιήσετε άλλα πράγματα, για παράδειγμα, για να ελέγξετε ότι η υποδομή σας μπορεί πραγματικά να αναπτυχθεί. Ή ελέγξτε ότι οι αλλαγές στην υποδομή δεν θα οδηγήσουν σε απώλεια χρημάτων. Γιατί μπορεί να χρειαστεί αυτό; Η ερώτηση είναι περίπλοκη και φιλοσοφική, είναι καλύτερα να απαντήσετε με μια ιστορία ότι κατά κάποιο τρόπο υπήρχε ένας αυτόματος κλιμακωτής κλίμακας στο Powershell που δεν έλεγχε τις οριακές συνθήκες => δημιουργήθηκαν περισσότερα εικονικά μηχανήματα από όσα χρειαζόταν => ο πελάτης ξόδεψε περισσότερα χρήματα από ό,τι είχε προγραμματιστεί. Αυτό δεν είναι πολύ ευχάριστο, αλλά θα ήταν πολύ πιθανό να εντοπιστεί αυτό το σφάλμα σε προηγούμενα στάδια.
Θα μπορούσε κανείς να ρωτήσει, γιατί να κάνουμε τις σύνθετες υποδομές ακόμη πιο περίπλοκες; Οι δοκιμές για την υποδομή, όπως και για τον κώδικα, δεν αφορούν την απλοποίηση, αλλά τη γνώση του τρόπου λειτουργίας της υποδομής σας.
IaC Testing Pyramid
Δοκιμή IaC: Στατική Ανάλυση
Εάν αναπτύξετε ολόκληρη την υποδομή ταυτόχρονα και ελέγξετε ότι λειτουργεί, μπορεί να διαπιστώσετε ότι χρειάζεται πολύς χρόνος και απαιτεί πολύ χρόνο. Επομένως, η βάση πρέπει να είναι κάτι που λειτουργεί γρήγορα, υπάρχει πολύ και καλύπτει πολλά πρωτόγονα μέρη.
Το Bash είναι δύσκολο
Ας δούμε ένα ασήμαντο παράδειγμα. επιλέξτε όλα τα αρχεία στον τρέχοντα κατάλογο και αντιγράψτε σε άλλη θέση. Το πρώτο πράγμα που μου έρχεται στο μυαλό:
for i in * ; do
cp $i /some/path/$i.bak
doneΤι γίνεται αν υπάρχει κενό στο όνομα του αρχείου; Λοιπόν, εντάξει, είμαστε έξυπνοι, ξέρουμε πώς να χρησιμοποιούμε εισαγωγικά:
for i in * ; do cp "$i" "/some/path/$i.bak" ; doneΜπράβο? Οχι! Τι γίνεται αν δεν υπάρχει τίποτα στον κατάλογο, π.χ. Το globbing δεν θα λειτουργήσει.
find . -type f -exec mv -v {} dst/{}.bak ;Μπράβο τώρα; Όχι... Ξεχάσατε τι μπορεί να υπάρχει στο όνομα του αρχείου n.
touch x
mv x "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dirΕργαλεία στατικής ανάλυσης
Το πρόβλημα από το προηγούμενο βήμα θα μπορούσε να εντοπιστεί όταν ξεχάσαμε τα εισαγωγικά, για αυτό υπάρχουν πολλές θεραπείες στη φύση , σε γενικές γραμμές υπάρχουν πολλά από αυτά, και πιθανότατα μπορείτε να βρείτε ένα linter για τη στοίβα σας κάτω από το IDE σας.
Γλώσσα
Εργαλείο
βίαιο χτύπημα
Ruby
Πύθων
αδύνατο
Δοκιμές IaC: Δοκιμές μονάδων
Όπως είδαμε από το προηγούμενο παράδειγμα, τα linters δεν είναι παντοδύναμα και δεν μπορούν να επισημάνουν όλες τις προβληματικές περιοχές. Επιπλέον, κατ' αναλογία με τις δοκιμές στην ανάπτυξη λογισμικού, μπορούμε να ανακαλέσουμε δοκιμές μονάδων. Αυτό που μου έρχεται αμέσως στο μυαλό είναι , , , . Τι να κάνουμε όμως με τους ansible, τον σεφ, τον saltstack και άλλους σαν αυτούς;
Στην αρχή μιλήσαμε για ΣΤΕΡΕΟΣ και ότι η υποδομή μας θα πρέπει να αποτελείται από μικρά τούβλα. Ήρθε η ώρα τους.
- Η υποδομή χωρίζεται σε μικρά τούβλα, για παράδειγμα, ρόλους Ansible.
- Αναπτύσσεται κάποιο είδος περιβάλλοντος, είτε πρόκειται για docker είτε για VM.
- Εφαρμόζουμε τον ρόλο μας στο Ansible σε αυτό το περιβάλλον δοκιμής.
- Ελέγχουμε ότι όλα λειτούργησαν όπως περιμέναμε (εκτελούμε δοκιμές).
- Αποφασίζουμε εντάξει ή όχι εντάξει.
IaC Testing: Unit Testing tools
Ερώτηση, τι είναι τα τεστ για το CFM; Μπορείτε απλά να εκτελέσετε το σενάριο ή μπορείτε να χρησιμοποιήσετε έτοιμες λύσεις για αυτό:
CFM
Εργαλείο
Πιθανό
Chef
Chef
αλυκή
Παράδειγμα για το testinfra, έλεγχος των χρηστών test1, test2 υπάρχουν και είναι σε ομάδα sshusers:
def test_default_users(host):
users = ['test1', 'test2' ]
for login in users:
assert host.user(login).exists
assert 'sshusers' in host.user(login).groupsΤι να επιλέξω; Το ερώτημα είναι περίπλοκο και διφορούμενο, εδώ είναι ένα παράδειγμα αλλαγών σε έργα στο github για το 2018-2019:
Πλαίσια δοκιμών IaC
Τίθεται το ερώτημα: πώς να τα συνδυάσουμε όλα μαζί και να τα λανσάρουμε; Μπορώ εάν υπάρχει επαρκής αριθμός μηχανικών. Ή μπορείτε να πάρετε έτοιμες λύσεις, αν και δεν υπάρχουν πάρα πολλές από αυτές:
CFM
Εργαλείο
Πιθανό
Chef
Terraform
Παράδειγμα αλλαγών σε έργα στο github για το 2018-2019:
Μόριο vs. Δοκιμαστική κουζίνα
Αρχικά εμείς :
- Δημιουργήστε παράλληλα ένα VM.
- Εφαρμογή ρόλων Ansible.
- Εκτελέστε επιθεώρηση.
Για 25-35 ρόλους δούλεψε 40-70 λεπτά, που ήταν πολύ.
Το επόμενο βήμα ήταν η μετάβαση σε jenkins/docker/ansible/molecule. Ιδιολογικά όλα είναι ίδια
- Lint playbooks.
- Παρατάξτε τους ρόλους.
- Δοχείο εκτόξευσης
- Εφαρμογή ρόλων Ansible.
- Εκτελέστε το testinfra.
- Ελέγξτε την ανικανότητα.
Το λιντάζ για 40 ρόλους και οι δοκιμές για μια ντουζίνα άρχισαν να διαρκούν περίπου 15 λεπτά.
Το τι θα επιλέξετε εξαρτάται από πολλούς παράγοντες, όπως η στοίβα που χρησιμοποιείται, η τεχνογνωσία στην ομάδα κ.λπ. εδώ ο καθένας αποφασίζει μόνος του πώς να κλείσει την ερώτηση δοκιμής μονάδας
Δοκιμές IaC: Δοκιμές ενσωμάτωσης
Το επόμενο βήμα στην πυραμίδα δοκιμών υποδομής θα είναι οι δοκιμές ολοκλήρωσης. Είναι παρόμοια με τις δοκιμές μονάδας:
- Η υποδομή χωρίζεται σε μικρά τούβλα, για παράδειγμα ρόλους Ansible.
- Αναπτύσσεται κάποιο είδος περιβάλλοντος, είτε πρόκειται για docker είτε για VM.
- Για αυτό το περιβάλλον δοκιμής ισχύει σύνολο από Αδύνατοι ρόλοι.
- Ελέγχουμε ότι όλα λειτούργησαν όπως περιμέναμε (εκτελούμε δοκιμές).
- Αποφασίζουμε εντάξει ή όχι εντάξει.
Σε γενικές γραμμές, δεν ελέγχουμε την απόδοση ενός μεμονωμένου στοιχείου του συστήματος όπως στις δοκιμές μονάδας, ελέγχουμε πώς έχει ρυθμιστεί ο διακομιστής στο σύνολό του.
IaC Testing: End to End Testing
Στην κορυφή της πυραμίδας μας υποδέχονται δοκιμές End to End. Εκείνοι. Δεν ελέγχουμε την απόδοση ενός ξεχωριστού διακομιστή, ενός ξεχωριστού σεναρίου ή ενός ξεχωριστού τούβλου της υποδομής μας. Ελέγχουμε ότι πολλοί διακομιστές συνδέονται μεταξύ τους, η υποδομή μας λειτουργεί όπως περιμένουμε. Δυστυχώς, δεν έχω δει ποτέ έτοιμες λύσεις σε κουτί, μάλλον γιατί... Η υποδομή είναι συχνά μοναδική και δύσκολο να διαμορφωθεί και να δημιουργηθεί ένα πλαίσιο για δοκιμή. Ως αποτέλεσμα, ο καθένας δημιουργεί τις δικές του λύσεις. Υπάρχει ζήτηση, αλλά απάντηση δεν υπάρχει. Ως εκ τούτου, θα σας πω τι υπάρχει για να ωθήσω τους άλλους να κάνουν υγιείς σκέψεις ή να τρίψουν τη μύτη μου στο γεγονός ότι όλα είχαν εφευρεθεί πολύ πριν από εμάς.
Ένα έργο με πλούσια ιστορία. Χρησιμοποιείται σε μεγάλους οργανισμούς και πιθανώς ο καθένας από εσάς έχει έμμεσα διασταυρωθεί μαζί του. Η εφαρμογή υποστηρίζει πολλές βάσεις δεδομένων, ενσωματώσεις κ.λπ. Το να γνωρίζεις πώς μπορεί να μοιάζει η υποδομή είναι πολλά αρχεία που συνθέτουν docker και γνωρίζεις ποιες δοκιμές πρέπει να εκτελεστούν σε ποιο περιβάλλον είναι το Jenkins.
Αυτό το σχέδιο λειτούργησε για αρκετό καιρό, έως ότου εντός του πλαισίου δεν προσπαθήσαμε να το μεταφέρουμε στο Openshift. Τα κοντέινερ παραμένουν ίδια, αλλά το περιβάλλον εκτόξευσης έχει αλλάξει (γεια σας DRY ξανά).
Η ερευνητική ιδέα προχώρησε παραπέρα και στο openshift βρήκαν ένα τέτοιο πράγμα όπως το APB (Ansible Playbook Bundle), το οποίο σας επιτρέπει να συσκευάσετε γνώσεις σχετικά με τον τρόπο ανάπτυξης της υποδομής σε ένα κοντέινερ. Εκείνοι. υπάρχει ένα επαναλαμβανόμενο, ελεγχόμενο σημείο γνώσης σχετικά με τον τρόπο ανάπτυξης της υποδομής.
Όλα αυτά ακούγονταν καλά μέχρι που συναντήσαμε μια ετερογενή υποδομή: χρειαζόμασταν τα Windows για δοκιμές. Ως αποτέλεσμα, η γνώση του τι, πού, πώς να αναπτύξετε και να δοκιμάσετε είναι στα jenkins.
Συμπέρασμα
Η υποδομή όπως είναι ο Κώδικας
- Κωδικός στο αποθετήριο.
- Ανθρώπινη αλληλεπίδραση.
- Δοκιμές υποδομής.
ΣΥΝΔΕΣΜΟΙ
- Ξηρό τρέξιμο 2019-04-24
- &
Πηγή: www.habr.com