Η εταιρεία μας βρίσκεται στη διαδικασία ενσωμάτωσης μιας ομάδας SRE. Μπήκα σε όλη αυτή την ιστορία από την πλευρά της ανάπτυξης. Στη διαδικασία, κατέληξα σε σκέψεις και ιδέες που θέλω να μοιραστώ με άλλους προγραμματιστές. Σε αυτό το άρθρο προβληματισμού μιλάω για το τι συμβαίνει, πώς συμβαίνει και πώς ο καθένας μπορεί να συνεχίσει να ζει με αυτό.
Συνέχεια μιας σειράς άρθρων που γράφτηκαν με βάση ομιλίες στην εσωτερική μας εκδήλωση :
2. Η υποδομή ως κωδικός. (Είστε εδώ)
3. Δημιουργία συμβολαίων Typescript με χρήση μοντέλων C#. (Σε εξέλιξη...)
4. Εισαγωγή στον αλγόριθμο συναίνεσης Raft. (Σε εξέλιξη...)
...
Αποφασίσαμε να δημιουργήσουμε μια ομάδα SRE, υλοποιώντας τις ιδέες . Προσέλαβαν προγραμματιστές από τους δικούς τους προγραμματιστές και τους έστειλαν να εκπαιδεύονται για αρκετούς μήνες.
Η ομάδα είχε τα ακόλουθα προπονητικά καθήκοντα:
- Περιγράψτε την υποδομή μας, η οποία είναι ως επί το πλείστον σε Microsoft Azure με τη μορφή κώδικα (Terraform και οτιδήποτε τριγύρω).
- Διδάξτε στους προγραμματιστές πώς να εργάζονται με την υποδομή.
- Προετοιμάστε τους προγραμματιστές για το καθήκον.
Εισάγουμε την έννοια της Υποδομής ως κώδικα
Στο συνηθισμένο μοντέλο του κόσμου (κλασική διοίκηση), η γνώση για τις υποδομές βρίσκεται σε δύο μέρη:
- Ή με τη μορφή γνώσης στα κεφάλια των ειδικών.
- Ή αυτές οι πληροφορίες βρίσκονται σε ορισμένες γραφομηχανές, μερικές από τις οποίες είναι γνωστές στους ειδικούς. Αλλά δεν είναι γεγονός ότι ένας ξένος (σε περίπτωση που ολόκληρη η ομάδα μας πεθάνει ξαφνικά) θα είναι σε θέση να καταλάβει τι λειτουργεί και πώς λειτουργεί. Μπορεί να υπάρχουν πολλές πληροφορίες για ένα μηχάνημα: αξεσουάρ, cronjobs, intimidated (βλ. ) δίσκο και απλώς μια ατελείωτη λίστα με το τι μπορεί να συμβεί. Είναι δύσκολο να καταλάβει κανείς τι πραγματικά συμβαίνει.
Και στις δύο περιπτώσεις, βρισκόμαστε παγιδευμένοι στο να γίνουμε εξαρτημένοι:
- ή από ένα άτομο που είναι θνητό, υποκείμενο σε ασθένεια, ερωτευμένο, εναλλαγές της διάθεσης και απλά κοινές απολύσεις.
- ή από μηχάνημα που λειτουργεί σωματικά, το οποίο επίσης πέφτει, κλέβεται και παρουσιάζει εκπλήξεις και ενοχλήσεις.
Είναι αυτονόητο ότι ιδανικά όλα θα πρέπει να μεταφράζονται σε κώδικα αναγνώσιμο από τον άνθρωπο, συντηρήσιμο, καλογραμμένο.
Έτσι, η υποδομή ως κώδικας (Incfastructure as Code - IaC) είναι μια περιγραφή ολόκληρης της υπάρχουσας υποδομής με τη μορφή κώδικα, καθώς και των σχετικών εργαλείων για την εργασία με αυτήν και την υλοποίηση πραγματικής υποδομής από αυτήν.
Γιατί να μεταφράσουμε τα πάντα σε κώδικα;Οι άνθρωποι δεν είναι μηχανές. Δεν μπορούν να θυμηθούν τα πάντα. Η αντίδραση ενός ανθρώπου και μιας μηχανής είναι διαφορετική. Οτιδήποτε αυτοματοποιημένο είναι δυνητικά πιο γρήγορο από οτιδήποτε γίνεται από έναν άνθρωπο. Το πιο σημαντικό πράγμα είναι μια ενιαία πηγή αλήθειας.
Από πού προέρχονται οι νέοι μηχανικοί SRE;Έτσι, αποφασίσαμε να προσλάβουμε νέους μηχανικούς SRE, αλλά από πού να τους προμηθευτούμε; Κάντε κράτηση με σωστές απαντήσεις () μας λέει: από τους προγραμματιστές. Εξάλλου, δουλεύουν με τον κώδικα και πετυχαίνεις την ιδανική κατάσταση.
Ψάξαμε πολύ για πολύ καιρό για αυτούς στην αγορά προσωπικού εκτός της εταιρείας μας. Αλλά πρέπει να παραδεχτούμε ότι δεν βρήκαμε κανέναν που να ταιριάζει στα αιτήματά μας. Έπρεπε να ψάξω ανάμεσα στους δικούς μου ανθρώπους.
Προβλήματα Υποδομή ως κωδικός
Τώρα ας δούμε παραδείγματα για το πώς η υποδομή μπορεί να κωδικοποιηθεί σε κώδικα. Ο κώδικας είναι καλογραμμένος, υψηλής ποιότητας, με σχόλια και εσοχές.
Παράδειγμα κώδικα από την Terraforma.
Παράδειγμα κώδικα από την Ansible.
Κύριοι, αν ήταν τόσο απλό! Είμαστε στον πραγματικό κόσμο και είναι πάντα έτοιμο να σας εκπλήξει, να σας παρουσιάσει εκπλήξεις και προβλήματα. Δεν μπορώ χωρίς αυτούς και εδώ.
1. Το πρώτο πρόβλημα είναι ότι στις περισσότερες περιπτώσεις το IaC είναι κάποιο είδος dsl.
Και το DSL, με τη σειρά του, είναι μια περιγραφή της δομής. Πιο συγκεκριμένα, τι πρέπει να έχετε: Json, Yaml, τροποποιήσεις από κάποιες μεγάλες εταιρείες που έφτιαξαν το δικό τους dsl (το HCL χρησιμοποιείται στο terraform).
Το πρόβλημα είναι ότι μπορεί εύκολα να μην περιέχει τόσο γνωστά πράγματα όπως:
- μεταβλητές?
- συνθήκες;
- κάπου δεν υπάρχουν σχόλια, για παράδειγμα, στο Json, από προεπιλογή δεν παρέχονται.
- λειτουργίες?
- και δεν μιλώ καν για πράγματα υψηλού επιπέδου όπως τάξεις, κληρονομιά και όλα αυτά.
2. Το δεύτερο πρόβλημα με έναν τέτοιο κώδικα είναι ότι τις περισσότερες φορές πρόκειται για ένα ετερογενές περιβάλλον. Συνήθως κάθεσαι και δουλεύεις με C#, δηλ. με μια γλώσσα, μια στοίβα, ένα οικοσύστημα. Και εδώ έχετε μια τεράστια ποικιλία τεχνολογιών.
Είναι μια πολύ πραγματική κατάσταση όταν το bash με python εκκινεί κάποια διαδικασία στην οποία εισάγεται το Json. Το αναλύεις και μετά κάποια άλλη γεννήτρια παράγει άλλα 30 αρχεία. Για όλα αυτά, λαμβάνονται μεταβλητές εισόδου από το Azure Key Vault, οι οποίες συγκεντρώνονται από ένα πρόσθετο για το drone.io γραμμένο στο Go και αυτές οι μεταβλητές περνούν από το yaml, το οποίο δημιουργήθηκε ως αποτέλεσμα της δημιουργίας από τη μηχανή προτύπου jsonnet. Είναι αρκετά δύσκολο να έχετε αυστηρά καλά περιγραφόμενο κώδικα όταν έχετε ένα τόσο διαφορετικό περιβάλλον.
Η παραδοσιακή ανάπτυξη στο πλαίσιο μιας εργασίας συνοδεύεται από μία γλώσσα. Εδώ δουλεύουμε με μεγάλο αριθμό γλωσσών.
3. Το τρίτο πρόβλημα είναι ο συντονισμός. Έχουμε συνηθίσει σε cool editors (Ms Visual Studio, Jetbrains Rider) που κάνουν τα πάντα για εμάς. Κι αν είμαστε χαζοί, θα πουν ότι κάνουμε λάθος. Φαίνεται φυσιολογικό και φυσικό.
Αλλά κάπου εκεί κοντά υπάρχει το VSCode, στο οποίο υπάρχουν μερικά πρόσθετα που κατά κάποιο τρόπο είναι εγκατεστημένα, υποστηρίζονται ή δεν υποστηρίζονται. Βγήκαν νέες εκδόσεις και δεν υποστηρίζονταν. Μια απλή μετάβαση στην υλοποίηση μιας συνάρτησης (ακόμα κι αν υπάρχει) γίνεται ένα σύνθετο και μη τετριμμένο πρόβλημα. Μια απλή μετονομασία μιας μεταβλητής είναι μια επανάληψη σε ένα έργο δώδεκα αρχείων. Θα είστε τυχεροί αν τοποθετήσει αυτό που χρειάζεστε. Φυσικά, υπάρχει οπίσθιος φωτισμός εδώ κι εκεί, υπάρχει αυτόματη συμπλήρωση, κάπου υπάρχει μορφοποίηση (αν και δεν μου λειτούργησε σε terraform στα Windows).
Τη στιγμή της συγγραφής αυτής δεν έχουν κυκλοφορήσει ακόμα για να υποστηρίζουν την έκδοση 0.12, αν και έχει κυκλοφορήσει εδώ και 3 μήνες.
Ήρθε η ώρα να ξεχάσουμε...
- Αποσφαλμάτωση.
- Εργαλείο ανακατασκευής.
- Αυτόματη συμπλήρωση.
- Ανίχνευση σφαλμάτων κατά τη μεταγλώττιση.
Είναι αστείο, αλλά αυτό αυξάνει επίσης τον χρόνο ανάπτυξης και αυξάνει τον αριθμό των σφαλμάτων που αναπόφευκτα συμβαίνουν.
Το χειρότερο είναι ότι αναγκαζόμαστε να μην σκεφτόμαστε πώς να σχεδιάσουμε, να οργανώσουμε αρχεία σε φακέλους, να αποσυνθέσουμε, να κάνουμε τον κώδικα διατηρήσιμο, αναγνώσιμο και ούτω καθεξής, αλλά πώς μπορώ να γράψω σωστά αυτήν την εντολή, επειδή κατά κάποιο τρόπο την έγραψα λάθος .
Ως αρχάριος, προσπαθείτε να μάθετε terraforms και το IDE δεν σας βοηθά καθόλου. Όταν υπάρχει τεκμηρίωση, μπείτε και δείτε. Αλλά αν μπαίνατε σε μια νέα γλώσσα προγραμματισμού, το IDE θα σας έλεγε ότι υπάρχει τέτοιος τύπος, αλλά δεν υπάρχει τέτοιο πράγμα. Τουλάχιστον σε επίπεδο int ή string. Αυτό είναι συχνά χρήσιμο.
Τι γίνεται με τις δοκιμές;
Ρωτάτε: «Τι γίνεται με τα τεστ, κύριοι προγραμματιστές;» Οι σοβαροί τύποι δοκιμάζουν τα πάντα στην παραγωγή, και είναι δύσκολο. Ακολουθεί ένα παράδειγμα δοκιμής μονάδας για μια ενότητα terraform από τον ιστότοπο .
Έχουν καλή τεκμηρίωση. Πάντα μου άρεσε η Microsoft για την προσέγγισή της στην τεκμηρίωση και την εκπαίδευση. Αλλά δεν χρειάζεται να είσαι ο θείος Μπομπ για να καταλάβεις ότι αυτός δεν είναι τέλειος κώδικας. Σημειώστε την επικύρωση στα δεξιά.
Το πρόβλημα με μια δοκιμή μονάδας είναι ότι εσείς και εγώ μπορούμε να ελέγξουμε την ορθότητα της εξόδου Json. Έριξα σε 5 παραμέτρους και μου έδωσαν ένα ποδήλατο Json με 2000 γραμμές. Μπορώ να αναλύσω τι συμβαίνει εδώ, να επικυρώσω το αποτέλεσμα της δοκιμής...
Είναι δύσκολο να αναλύσεις το Json στο Go. Και πρέπει να γράψετε στο Go, γιατί το terraform in Go είναι μια καλή πρακτική για δοκιμές στη γλώσσα στην οποία γράφετε. Η οργάνωση του ίδιου του κώδικα είναι πολύ αδύναμη. Ταυτόχρονα, αυτή είναι η καλύτερη βιβλιοθήκη για δοκιμές.
Η ίδια η Microsoft γράφει τα modules της, δοκιμάζοντας τα με αυτόν τον τρόπο. Φυσικά είναι ανοιχτού κώδικα. Ό,τι σου λέω μπορείς να έρθεις να το φτιάξεις. Μπορώ να καθίσω και να διορθώσω τα πάντα σε μια εβδομάδα, πρόσθετα κώδικα VS ανοιχτού κώδικα, terraforms, να φτιάξω ένα πρόσθετο για τον αναβάτη. Ίσως γράψετε μερικούς αναλυτές, προσθέστε linters, συνεισφέρετε μια βιβλιοθήκη για δοκιμή. Μπορώ να κάνω τα πάντα. Αλλά δεν είναι αυτό που έπρεπε να κάνω.
Βέλτιστες πρακτικές Υποδομή ως κώδικας
Ας προχωρήσουμε. Εάν δεν υπάρχουν δοκιμές στο IaC, το IDE και ο συντονισμός είναι κακοί, τότε θα πρέπει τουλάχιστον να υπάρχουν βέλτιστες πρακτικές. Μόλις πήγα στο Google Analytics και συνέκρινα δύο ερωτήματα αναζήτησης: τις βέλτιστες πρακτικές Terraform και τις βέλτιστες πρακτικές c#.
Τι βλέπουμε; Οι αδίστακτες στατιστικές δεν είναι υπέρ μας. Η ποσότητα του υλικού είναι η ίδια. Στην ανάπτυξη της C#, είμαστε απλά γεμάτοι με υλικά, έχουμε σούπερ βέλτιστες πρακτικές, υπάρχουν βιβλία γραμμένα από ειδικούς, καθώς και βιβλία γραμμένα σε βιβλία από άλλους ειδικούς που επικρίνουν αυτά τα βιβλία. Μια θάλασσα επίσημης τεκμηρίωσης, άρθρων, εκπαιδευτικών μαθημάτων και τώρα και ανάπτυξης ανοιχτού κώδικα.
Όσον αφορά το αίτημα IaC: εδώ προσπαθείτε να συλλέξετε πληροφορίες λίγο-λίγο από αναφορές highload ή HashiConf, από επίσημη τεκμηρίωση και πολλά ζητήματα στο Github. Πώς να διανείμετε αυτές τις ενότητες γενικά, τι να τις κάνετε; Φαίνεται ότι αυτό είναι ένα πραγματικό πρόβλημα... Υπάρχει μια κοινότητα, κύριοι, όπου για οποιαδήποτε ερώτηση θα σας δοθούν 10 σχόλια στο Github. Αλλά δεν είναι ακριβώς.
Δυστυχώς, αυτή τη στιγμή, οι ειδικοί μόλις αρχίζουν να εμφανίζονται. Είναι πολύ λίγοι μέχρι στιγμής. Και η ίδια η κοινότητα κάνει παρέα στο στοιχειώδες επίπεδο.
Πού πάνε όλα αυτά και τι να κάνουμε
Μπορείτε να αφήσετε τα πάντα και να επιστρέψετε στο C#, στον κόσμο του αναβάτη. Αλλά όχι. Γιατί να κάνετε τον κόπο να το κάνετε αυτό αν δεν μπορείτε να βρείτε μια λύση. Παρακάτω παρουσιάζω τα υποκειμενικά μου συμπεράσματα. Μπορείτε να διαφωνήσετε μαζί μου στα σχόλια, θα είναι ενδιαφέρον.
Προσωπικά, στοιχηματίζω σε μερικά πράγματα:
- Η ανάπτυξη σε αυτόν τον τομέα γίνεται πολύ γρήγορα. Ακολουθεί ένα πρόγραμμα αιτημάτων για DevOps.
Το θέμα μπορεί να είναι διαφημιστική εκστρατεία, αλλά το ίδιο το γεγονός ότι η σφαίρα μεγαλώνει δίνει κάποια ελπίδα.Αν κάτι μεγαλώσει τόσο γρήγορα, τότε σίγουρα θα εμφανιστούν έξυπνοι άνθρωποι που θα σας πουν τι να κάνετε και τι να μην κάνετε. Η αύξηση της δημοτικότητας οδηγεί στο γεγονός ότι ίσως κάποιος θα έχει χρόνο να προσθέσει επιτέλους ένα πρόσθετο στο jsonnet για vscode, το οποίο θα σας επιτρέψει να προχωρήσετε στην υλοποίηση της συνάρτησης, αντί να την αναζητήσετε μέσω ctrl+shift+f. Καθώς τα πράγματα εξελίσσονται, εμφανίζονται περισσότερα υλικά. Η κυκλοφορία ενός βιβλίου από την Google σχετικά με το SRE είναι ένα εξαιρετικό παράδειγμα αυτού.
- Υπάρχουν ανεπτυγμένες τεχνικές και πρακτικές στη συμβατική ανάπτυξη που μπορούμε να εφαρμόσουμε με επιτυχία εδώ. Ναι, υπάρχουν αποχρώσεις με τις δοκιμές και το ετερογενές περιβάλλον, τα ανεπαρκή εργαλεία, αλλά έχει συσσωρευτεί ένας τεράστιος αριθμός πρακτικών που μπορεί να είναι χρήσιμες και χρήσιμες.
Ένα ασήμαντο παράδειγμα: συνεργασία μέσω προγραμματισμού ζευγών. Βοηθάει πολύ να το καταλάβω. Όταν έχεις έναν γείτονα κοντά που προσπαθεί επίσης να καταλάβει κάτι, μαζί θα καταλάβετε καλύτερα.
Η κατανόηση του τρόπου με τον οποίο γίνεται η αναδιαμόρφωση βοηθά στην πραγματοποίησή της ακόμη και σε μια τέτοια κατάσταση. Δηλαδή, δεν μπορείτε να αλλάξετε τα πάντα ταυτόχρονα, αλλά να αλλάξετε την ονομασία, μετά να αλλάξετε την τοποθεσία, μετά μπορείτε να επισημάνετε κάποιο μέρος, ω, αλλά δεν υπάρχουν αρκετά σχόλια εδώ.
Συμπέρασμα
Παρά το γεγονός ότι ο συλλογισμός μου μπορεί να φαίνεται απαισιόδοξος, κοιτάζω το μέλλον με ελπίδα και ειλικρινά ελπίζω ότι όλα θα πάνε καλά για εμάς (και για εσάς).
Το δεύτερο μέρος του άρθρου ετοιμάζεται στη συνέχεια. Σε αυτό, θα μιλήσω για το πώς προσπαθήσαμε να χρησιμοποιήσουμε ευέλικτες πρακτικές ανάπτυξης για να βελτιώσουμε τη διαδικασία μάθησης και να εργαστούμε με υποδομές.
Πηγή: www.habr.com