Πολλοί άνθρωποι γνωρίζουν και χρησιμοποιούν το Terraform στην καθημερινή τους εργασία, αλλά οι βέλτιστες πρακτικές για αυτό δεν έχουν ακόμη διαμορφωθεί. Κάθε ομάδα πρέπει να εφεύρει τις δικές της προσεγγίσεις και μεθόδους.
Η υποδομή σας ξεκινάει σχεδόν σίγουρα απλά: λίγοι πόροι + λίγοι προγραμματιστές. Με την πάροδο του χρόνου, αναπτύσσεται προς όλες τις κατευθύνσεις. Βρίσκετε τρόπους να ομαδοποιήσετε πόρους σε λειτουργικές μονάδες Terraform, να οργανώσετε τον κώδικα σε φακέλους και τι άλλο μπορεί να πάει στραβά; (διάσημες τελευταίες λέξεις)
Ο χρόνος περνά και νιώθετε ότι η υποδομή σας είναι το νέο σας κατοικίδιο, αλλά γιατί; Ανησυχείτε για ανεξήγητες αλλαγές στην υποδομή, φοβάστε να αγγίξετε την υποδομή και τον κωδικό - ως αποτέλεσμα, καθυστερείτε τη νέα λειτουργικότητα ή μειώνετε την ποιότητα...
Μετά από τρία χρόνια διαχείρισης μιας συλλογής ενοτήτων κοινότητας Terraform για το AWS στο Github και μακροχρόνιας συντήρησης του Terraform στην παραγωγή, ο Anton Babenko είναι έτοιμος να μοιραστεί την εμπειρία του: πώς να γράψετε μονάδες TF ώστε να μην βλάψει στο μέλλον.
Μέχρι το τέλος της ομιλίας, οι συμμετέχοντες θα εξοικειωθούν περισσότερο με τις αρχές διαχείρισης πόρων στο Terraform, τις βέλτιστες πρακτικές που σχετίζονται με τις ενότητες στο Terraform και ορισμένες αρχές συνεχούς ολοκλήρωσης που σχετίζονται με τη διαχείριση υποδομής.
Αποποίηση ευθυνών: Σημειώνω ότι αυτή η έκθεση χρονολογείται από τον Νοέμβριο του 2018 — έχουν ήδη περάσει 2 χρόνια. Η έκδοση του Terraform 0.11 που συζητείται στην αναφορά δεν υποστηρίζεται πλέον. Τα τελευταία 2 χρόνια, έχουν κυκλοφορήσει 2 νέες εκδόσεις, οι οποίες περιέχουν πολλές καινοτομίες, βελτιώσεις και αλλαγές. Δώστε προσοχή σε αυτό και ελέγξτε την τεκμηρίωση.
Βιβλιογραφικές αναφορές:
- +
- — κωδικός και τεκμηρίωση αυτόματης μορφοποίησης
- — γεννήτρια μονάδων Terraform (WIP)
- — Γεννήτρια κώδικα Terraform από οπτικά διαγράμματα (WIP)
- www.terraform-best-practices.com
- (Οι νέες δημοσιεύσεις βρίσκονται στην προσωπική μου ιστοσελίδα www.antonbabenko.com/)
- @antonbabenko - Twitter, και ένα σωρό διαφορετικά Slacks
Το όνομά μου είναι Anton Babenko. Μερικοί από εσάς πιθανότατα χρησιμοποίησαν τον κώδικα που έγραψα. Τώρα θα μιλήσω γι' αυτό με μεγαλύτερη σιγουριά από ποτέ, γιατί έχω πρόσβαση στα στατιστικά στοιχεία.
Εργάζομαι στο Terraform και συμμετέχω ενεργά και συνεισφέρω σε μεγάλο αριθμό έργων ανοιχτού κώδικα που σχετίζονται με το Terraform και το Amazon από το 2015.
Από τότε έχω γράψει αρκετό κώδικα για να τον βάλω με ενδιαφέροντα τρόπο. Και θα προσπαθήσω να σας πω για αυτό τώρα.
Θα μιλήσω για τις περιπλοκές και τις ιδιαιτερότητες της συνεργασίας με την Terraform. Αλλά αυτό δεν είναι πραγματικά το θέμα του HighLoad. Και τώρα θα καταλάβετε γιατί.
Με τον καιρό, άρχισα να γράφω ενότητες Terraform. Οι χρήστες έγραψαν ερωτήσεις, τις ξαναέγραψα. Έπειτα έγραψα διάφορα βοηθητικά προγράμματα για να μορφοποιήσω τον κώδικα χρησιμοποιώντας ένα άγκιστρο pre-commit κ.λπ.
Υπήρχαν πολλά ενδιαφέροντα έργα. Μου αρέσει η δημιουργία κώδικα επειδή μου αρέσει ο υπολογιστής να κάνει όλο και περισσότερη δουλειά για εμένα και τον προγραμματιστή, γι' αυτό αυτήν τη στιγμή εργάζομαι σε μια γεννήτρια κώδικα Terraform από οπτικά διαγράμματα. Ίσως κάποιοι από εσάς τα έχετε δει. Αυτά είναι όμορφα κουτιά με βέλη. Και νομίζω ότι είναι υπέροχο αν μπορείτε να κάνετε κλικ στο κουμπί "Εξαγωγή" και να τα λάβετε όλα ως κωδικό.
Είμαι από την Ουκρανία. Ζω στη Νορβηγία πολλά χρόνια.
Επίσης, πληροφορίες για αυτήν την αναφορά συλλέχθηκαν από άτομα που γνωρίζουν το όνομά μου και με βρίσκουν στα κοινωνικά δίκτυα. Έχω σχεδόν πάντα το ίδιο ψευδώνυμο.
Όπως ανέφερα, είμαι ο κύριος συντηρητής των μονάδων Terraform AWS, που είναι ένα από τα μεγαλύτερα αποθετήρια στο GitHub όπου φιλοξενούμε ενότητες για τις πιο συνηθισμένες εργασίες: VPC, Autoscaling, RDS.
Και αυτό που ακούσατε τώρα είναι το πιο βασικό. Εάν αμφιβάλλετε ότι καταλαβαίνετε τι είναι το Terraform, τότε είναι καλύτερα να αφιερώσετε το χρόνο σας κάπου αλλού. Θα υπάρχουν πολλοί τεχνικοί όροι εδώ. Και δεν δίστασα να δηλώσω ότι το επίπεδο της έκθεσης είναι το υψηλότερο. Αυτό σημαίνει ότι μπορώ να μιλήσω χρησιμοποιώντας όλους τους πιθανούς όρους χωρίς πολλές εξηγήσεις.
Το Terraform εμφανίστηκε το 2014 ως ένα βοηθητικό πρόγραμμα που σας επέτρεπε να γράφετε, να σχεδιάζετε και να διαχειρίζεστε την υποδομή ως κώδικα. Η βασική ιδέα εδώ είναι «η υποδομή ως κώδικας».
Όλη η τεκμηρίωση, όπως είπα, είναι γραμμένη . Ελπίζω ότι οι περισσότεροι άνθρωποι γνωρίζουν για αυτόν τον ιστότοπο και έχουν διαβάσει την τεκμηρίωση. Αν ναι, τότε είστε στο σωστό μέρος.
Έτσι μοιάζει ένα κανονικό αρχείο διαμόρφωσης Terraform, όπου ορίζουμε πρώτα μερικές μεταβλητές.
Σε αυτήν την περίπτωση ορίζουμε "aws_region".
Στη συνέχεια περιγράφουμε ποιους πόρους θέλουμε να δημιουργήσουμε.
Εκτελούμε ορισμένες εντολές, ιδιαίτερα "terraform init" για να φορτώσουμε εξαρτήσεις και παρόχους.
Και εκτελούμε την εντολή «terraform application» για να ελέγξουμε αν η καθορισμένη διαμόρφωση ταιριάζει με τους πόρους που δημιουργήσαμε. Δεδομένου ότι δεν έχουμε δημιουργήσει τίποτα πριν, η Terraform μας προτρέπει να δημιουργήσουμε αυτούς τους πόρους.
Το επιβεβαιώνουμε. Έτσι δημιουργούμε έναν κουβά που ονομάζεται seasnail.
Υπάρχουν επίσης πολλά παρόμοια βοηθητικά προγράμματα. Πολλοί από εσάς που χρησιμοποιείτε το Amazon γνωρίζετε το AWS CloudFormation ή το Google Cloud Deployment Manager ή το Azure Resource Manager. Καθένα από αυτά έχει τη δική του εφαρμογή κάποιου είδους για τη διαχείριση πόρων σε κάθε έναν από αυτούς τους δημόσιους παρόχους cloud. Το Terraform είναι ιδιαίτερα χρήσιμο γιατί σας επιτρέπει να διαχειρίζεστε πάνω από 100 παρόχους. (Περισσότερες λεπτομέρειες )
Οι στόχοι που επιδίωξε η Terraform από την αρχή:
- Το Terraform παρέχει μια ενιαία προβολή των πόρων.
- Σας επιτρέπει να υποστηρίζετε όλες τις σύγχρονες πλατφόρμες.
- Και το Terraform σχεδιάστηκε από την αρχή ως ένα βοηθητικό πρόγραμμα που σας επιτρέπει να αλλάξετε την υποδομή με ασφάλεια και προβλέψιμα.
Το 2014, η λέξη «προβλέψιμο» ακουγόταν πολύ ασυνήθιστη σε αυτό το πλαίσιο.
Το Terraform είναι ένα καθολικό βοηθητικό πρόγραμμα. Εάν έχετε ένα API, τότε μπορείτε να ελέγξετε τα πάντα:
- Μπορείτε να χρησιμοποιήσετε περισσότερους από 120 παρόχους για να διαχειριστείτε όλα όσα θέλετε.
- Για παράδειγμα, μπορείτε να χρησιμοποιήσετε το Terraform για να περιγράψετε την πρόσβαση στα αποθετήρια GitHub.
- Μπορείτε ακόμη να δημιουργήσετε και να κλείσετε σφάλματα στο Jira.
- Μπορείτε να διαχειριστείτε τις μετρήσεις New Relic.
- Μπορείτε ακόμη και να δημιουργήσετε αρχεία στο dropbox αν το θέλετε πραγματικά.
Όλα αυτά επιτυγχάνονται χρησιμοποιώντας παρόχους Terraform, οι οποίοι διαθέτουν ένα ανοιχτό API που μπορεί να περιγραφεί στο Go.
Ας υποθέσουμε ότι αρχίσαμε να χρησιμοποιούμε το Terraform, διαβάσαμε κάποια τεκμηρίωση στον ιστότοπο, παρακολουθήσαμε κάποιο βίντεο και αρχίσαμε να γράφουμε main.tf, όπως έδειξα στις προηγούμενες διαφάνειες.
Και όλα είναι υπέροχα, έχετε ένα αρχείο που δημιουργεί ένα VPC.
Εάν θέλετε να δημιουργήσετε ένα VPC, τότε καθορίζετε περίπου αυτές τις 12 γραμμές. Περιγράψτε σε ποια περιοχή θέλετε να δημιουργήσετε, ποιο cidr_block διευθύνσεων IP να χρησιμοποιήσετε. Αυτό είναι όλο.
Φυσικά, το έργο θα μεγαλώσει σταδιακά.
Και θα προσθέσετε ένα σωρό νέα πράγματα εκεί: πόρους, πηγές δεδομένων, θα ενσωματωθείτε με νέους παρόχους, ξαφνικά θα θέλετε να χρησιμοποιήσετε το Terraform για να διαχειριστείτε τους χρήστες στο λογαριασμό σας στο GitHub κ.λπ. Μπορεί να θέλετε να χρησιμοποιήσετε διαφορετικά Πάροχοι DNS, διασταυρώστε τα πάντα. Το Terraform το κάνει εύκολο.
Ας δούμε το παρακάτω παράδειγμα.
Σταδιακά προσθέτετε internet_gateway επειδή θέλετε πόρους από το VPC σας να έχουν πρόσβαση στο διαδίκτυο. Αυτή είναι μια καλή ιδέα.
Το αποτέλεσμα είναι αυτό το main.tf:
Αυτό είναι το επάνω μέρος του main.tf.
Αυτό είναι το κάτω μέρος του main.tf.
Στη συνέχεια προσθέτετε υποδίκτυο. Μέχρι τη στιγμή που θέλετε να προσθέσετε πύλες NAT, διαδρομές, πίνακες δρομολόγησης και ένα σωρό άλλα υποδίκτυα, δεν θα έχετε 38 γραμμές, αλλά περίπου 200-300 γραμμές.
Δηλαδή, το αρχείο main.tf σταδιακά μεγαλώνει. Και πολύ συχνά οι άνθρωποι βάζουν τα πάντα σε ένα αρχείο. 10-20 Kb εμφανίζονται στο main.tf. Φανταστείτε ότι 10-20 Kb είναι περιεχόμενο κειμένου. Και όλα συνδέονται με τα πάντα. Αυτό γίνεται σταδιακά δύσκολο να δουλέψεις. 10-20 Kb είναι μια καλή περίπτωση χρήστη, μερικές φορές περισσότερο. Και οι άνθρωποι δεν πιστεύουν πάντα ότι αυτό είναι κακό.
Όπως και στον κανονικό προγραμματισμό, δηλαδή όχι στην υποδομή ως κώδικα, έχουμε συνηθίσει να χρησιμοποιούμε ένα σωρό διαφορετικές κλάσεις, πακέτα, ενότητες, ομαδοποιήσεις. Το Terraform σας επιτρέπει να κάνετε σχεδόν το ίδιο πράγμα.
- Ο κώδικας μεγαλώνει.
- Οι εξαρτήσεις μεταξύ των πόρων αυξάνονται επίσης.
Και έχουμε μεγάλη, μεγάλη ανάγκη. Καταλαβαίνουμε ότι δεν μπορούμε να ζήσουμε άλλο έτσι. Ο κώδικάς μας γίνεται τεράστιος. Τα 10-20 Kb, φυσικά, δεν είναι πολύ μεγάλα, αλλά μιλάμε μόνο για τη στοίβα δικτύου, δηλαδή έχετε προσθέσει μόνο πόρους δικτύου. Δεν μιλάμε για Application Load Balancer, Deployment ES cluster, Kubernetes κ.λπ., όπου μπορούν εύκολα να υφίστανται 100 Kb. Εάν τα γράψετε όλα αυτά, πολύ σύντομα θα μάθετε ότι η Terraform παρέχει ενότητες Terraform.
Οι μονάδες Terraform είναι μια αυτόνομη διαμόρφωση Terraform που διαχειρίζεται ως ομάδα. Αυτό είναι το μόνο που χρειάζεται να γνωρίζετε για τις μονάδες Terraform. Δεν είναι καθόλου έξυπνοι, δεν σου επιτρέπουν να κάνεις σύνθετες συνδέσεις ανάλογα με κάτι. Όλα αυτά πέφτουν στους ώμους των προγραμματιστών. Δηλαδή, αυτό είναι απλώς ένα είδος διαμόρφωσης Terraform που έχετε ήδη γράψει. Και μπορείτε απλά να το καλέσετε ως ομάδα.
Προσπαθούμε λοιπόν να καταλάβουμε πώς θα βελτιστοποιήσουμε τον κώδικα των 10-20-30 Kb μας. Σταδιακά συνειδητοποιούμε ότι πρέπει να χρησιμοποιήσουμε κάποιες ενότητες.
Ο πρώτος τύπος λειτουργικών μονάδων που συναντάτε είναι ενότητες πόρων. Δεν καταλαβαίνουν τι αφορά την υποδομή σας, τι αφορά την επιχείρησή σας, πού και ποιες είναι οι συνθήκες. Αυτές είναι ακριβώς οι ενότητες που διαχειρίζομαι εγώ, μαζί με την κοινότητα ανοιχτού κώδικα, και τις οποίες προτείνουμε ως τα αρχικά δομικά στοιχεία για την υποδομή σας.
Ένα παράδειγμα μονάδας πόρων.
Όταν καλούμε μια λειτουργική μονάδα πόρου, καθορίζουμε από ποια διαδρομή θα φορτώσουμε τα περιεχόμενά της.
Υποδεικνύουμε ποια έκδοση θέλουμε να κατεβάσουμε.
Περνάμε ένα σωρό επιχειρήματα εκεί. Αυτό είναι όλο. Αυτό είναι το μόνο που χρειάζεται να γνωρίζουμε όταν χρησιμοποιούμε αυτήν την ενότητα.
Πολλοί πιστεύουν ότι αν χρησιμοποιήσουν την πιο πρόσφατη έκδοση, όλα θα είναι σταθερά. Αλλά όχι. Η υποδομή πρέπει να έχει εκδοθεί· πρέπει να απαντήσουμε ξεκάθαρα σε ποια έκδοση έχει αναπτυχθεί αυτό ή εκείνο το στοιχείο.
Εδώ είναι ο κώδικας που βρίσκεται μέσα σε αυτήν την ενότητα. Μονάδα ομάδας ασφαλείας. Εδώ η κύλιση πηγαίνει στην 640η γραμμή. Η δημιουργία ενός πόρου ασφαλείας-croup στο Amazon σε κάθε δυνατή διαμόρφωση είναι μια πολύ μη τετριμμένη εργασία. Δεν αρκεί απλώς να δημιουργήσετε μια ομάδα ασφαλείας και να της πείτε ποιους κανόνες να της περάσει. Θα ήταν πολύ απλό. Υπάρχουν ένα εκατομμύριο διαφορετικοί περιορισμοί στο Amazon. Για παράδειγμα, εάν χρησιμοποιείτε Τελικό σημείο VPC, λίστα προθεμάτων, διάφορα API και προσπαθεί να τα συνδυάσει όλα αυτά με όλα τα άλλα, τότε η Terraform δεν σας επιτρέπει να το κάνετε αυτό. Και το Amazon API δεν το επιτρέπει ούτε αυτό. Επομένως, πρέπει να κρύψουμε όλη αυτή την τρομερή λογική σε μια ενότητα και να δώσουμε στον χρήστη κωδικό που μοιάζει ακριβώς έτσι.
Ο χρήστης δεν χρειάζεται να ξέρει πώς είναι φτιαγμένο στο εσωτερικό του.
Ο δεύτερος τύπος λειτουργικών μονάδων, που αποτελείται από ενότητες πόρων, λύνει ήδη προβλήματα που ισχύουν περισσότερο για την επιχείρησή σας. Συχνά αυτό είναι ένα μέρος που αποτελεί επέκταση για το Terraform και ορίζει ορισμένες άκαμπτες τιμές για ετικέτες, για εταιρικά πρότυπα. Μπορείτε επίσης να προσθέσετε λειτουργίες εκεί που η Terraform δεν σας επιτρέπει αυτήν τη στιγμή να χρησιμοποιήσετε. Αυτό είναι τώρα. Τώρα η έκδοση 0.11, που πρόκειται να γίνει παρελθόν. Ωστόσο, οι προεπεξεργαστές, το jsonnet, το cookiecutter και ένα σωρό άλλα πράγματα είναι ο βοηθητικός μηχανισμός που πρέπει να χρησιμοποιηθεί για πλήρη εργασία.
Στη συνέχεια θα δείξω μερικά παραδείγματα αυτού.
Η ενότητα υποδομής καλείται με τον ίδιο ακριβώς τρόπο.
Υποδεικνύεται η πηγή από την οποία γίνεται λήψη του περιεχομένου.
Ένα σωρό τιμές μεταβιβάζονται και μεταβιβάζονται σε αυτήν την ενότητα.
Στη συνέχεια, μέσα σε αυτήν την ενότητα, καλούνται μια δέσμη λειτουργικών μονάδων πόρων για τη δημιουργία ενός VPC ή ενός Application Load Balancer ή για τη δημιουργία μιας ομάδας ασφαλείας ή για ένα σύμπλεγμα Elastic Container Service.
Υπάρχουν δύο τύποι ενοτήτων. Αυτό είναι σημαντικό να γίνει κατανοητό, επειδή οι περισσότερες από τις πληροφορίες που έχω ομαδοποιήσει σε αυτήν την αναφορά δεν είναι γραμμένες στην τεκμηρίωση.
Και η τεκμηρίωση στο Terraform αυτή τη στιγμή είναι αρκετά προβληματική γιατί απλώς λέει ότι υπάρχουν αυτές οι δυνατότητες, μπορείτε να τις χρησιμοποιήσετε. Αλλά δεν λέει πώς να χρησιμοποιήσετε αυτές τις δυνατότητες, γιατί είναι καλύτερο να τις χρησιμοποιήσετε. Επομένως, ένας πολύ μεγάλος αριθμός ανθρώπων γράφουν κάτι με το οποίο δεν μπορούν να ζήσουν.
Ας ρίξουμε μια ματιά στο πώς να γράψουμε αυτές τις ενότητες στη συνέχεια. Στη συνέχεια, θα δούμε πώς να τους καλέσετε και πώς να εργαστείτε με τον κωδικό.
Μητρώο Terraform -
Συμβουλή #0 είναι να μην γράφετε ενότητες πόρων. Οι περισσότερες από αυτές τις ενότητες έχουν ήδη γραφτεί για εσάς. Όπως είπα, είναι ανοιχτού κώδικα, δεν περιέχουν καμία από τη λογική της επιχείρησής σας, δεν έχουν κωδικοποιημένες τιμές για διευθύνσεις IP, κωδικούς πρόσβασης κ.λπ. Η ενότητα είναι πολύ ευέλικτη. Και πιθανότατα έχει ήδη γραφτεί. Υπάρχουν πολλές ενότητες για πόρους από το Amazon. Περίπου 650. Και τα περισσότερα είναι καλής ποιότητας.
Σε αυτό το παράδειγμα, κάποιος ήρθε σε εσάς και είπε: «Θέλω να μπορώ να διαχειρίζομαι μια βάση δεδομένων. Δημιουργήστε μια ενότητα για να μπορώ να δημιουργήσω μια βάση δεδομένων." Το άτομο δεν γνωρίζει τις λεπτομέρειες υλοποίησης είτε του Amazon είτε του Terraform. Λέει απλώς: «Θέλω να διαχειριστώ το MSSQL». Δηλαδή, εννοούμε ότι θα καλέσει το module μας, θα περάσει τον τύπο του κινητήρα εκεί και θα υποδείξει τη ζώνη ώρας.
Και ένα άτομο δεν πρέπει να γνωρίζει ότι θα δημιουργήσουμε δύο διαφορετικούς πόρους μέσα σε αυτήν την ενότητα: έναν για MSSQL, τον δεύτερο για οτιδήποτε άλλο, μόνο επειδή στο Terraform 0.11 δεν μπορείτε να καθορίσετε τις τιμές ζώνης ώρας ως προαιρετικές.
Και στην έξοδο από αυτήν την ενότητα, ένα άτομο θα μπορεί απλώς να λάβει μια διεύθυνση. Δεν θα ξέρει από ποια βάση δεδομένων, από ποιο πόρο δημιουργούμε όλα αυτά εσωτερικά. Αυτό είναι ένα πολύ σημαντικό στοιχείο απόκρυψης. Και αυτό δεν ισχύει μόνο για εκείνες τις ενότητες που είναι δημόσιες σε ανοιχτό κώδικα, αλλά και για εκείνες τις ενότητες που θα γράψετε μέσα στα έργα και τις ομάδες σας.
Αυτό είναι το δεύτερο επιχείρημα, το οποίο είναι αρκετά σημαντικό εάν χρησιμοποιείτε το Terraform για λίγο. Έχετε ένα αποθετήριο στο οποίο τοποθετείτε όλες τις μονάδες Terraform για την εταιρεία σας. Και είναι απολύτως φυσιολογικό ότι με την πάροδο του χρόνου αυτό το έργο θα μεγαλώσει σε μέγεθος ενός ή δύο megabyte. Είναι εντάξει.
Αλλά το πρόβλημα είναι πώς η Terraform ονομάζει αυτές τις ενότητες. Για παράδειγμα, εάν καλέσετε μια λειτουργική μονάδα για να δημιουργήσετε κάθε μεμονωμένο χρήστη, το Terraform θα φορτώσει πρώτα ολόκληρο το αποθετήριο και στη συνέχεια θα μεταβεί στον φάκελο όπου βρίσκεται η συγκεκριμένη λειτουργική μονάδα. Με αυτόν τον τρόπο θα κατεβάζετε ένα megabyte κάθε φορά. Εάν διαχειρίζεστε 100 ή 200 χρήστες, τότε θα κάνετε λήψη 100 ή 200 megabyte και, στη συνέχεια, θα μεταβείτε σε αυτόν τον φάκελο. Οπότε φυσικά δεν θέλετε να κατεβάζετε ένα σωρό πράγματα κάθε φορά που πατάτε "Terraform init".
Υπάρχουν δύο λύσεις σε αυτό το πρόβλημα. Το πρώτο είναι να χρησιμοποιήσετε σχετικές διαδρομές. Με αυτόν τον τρόπο υποδεικνύετε στον κωδικό ότι ο φάκελος είναι τοπικός (./). Και πριν ξεκινήσετε οτιδήποτε, κάνετε έναν κλώνο Git αυτού του αποθετηρίου τοπικά. Με αυτόν τον τρόπο το κάνεις μια φορά.
Υπάρχουν, φυσικά, πολλά μειονεκτήματα. Για παράδειγμα, δεν μπορείτε να χρησιμοποιήσετε έκδοση εκδόσεων. Και αυτό μερικές φορές είναι δύσκολο να το ζήσεις.
Δεύτερη λύση. Εάν έχετε πολλές υπομονάδες και έχετε ήδη κάποιο είδος καθιερωμένου αγωγού, τότε υπάρχει το έργο MBT, το οποίο σας επιτρέπει να συλλέξετε πολλά διαφορετικά πακέτα από ένα μονοαποθετήριο και να τα ανεβάσετε στο S3. Αυτός είναι ένας πολύ καλός τρόπος. Έτσι, το αρχείο iam-user-1.0.0.zip θα ζυγίζει μόνο 1 Kb, επειδή ο κώδικας για τη δημιουργία αυτού του πόρου είναι πολύ μικρός. Και θα λειτουργήσει πολύ πιο γρήγορα.
Ας μιλήσουμε για το τι δεν μπορεί να χρησιμοποιηθεί σε ενότητες.
Γιατί είναι αυτό το κακό στις ενότητες; Το χειρότερο πράγμα είναι να υποθέσουμε χρήστη. Ας υποθέσουμε ότι ο χρήστης είναι μια επιλογή ελέγχου ταυτότητας παρόχου που μπορεί να χρησιμοποιηθεί από διαφορετικά άτομα. Για παράδειγμα, όλοι θα αφομοιώσουμε τον ρόλο. Αυτό σημαίνει ότι η Terraform θα αναλάβει αυτόν τον ρόλο. Και μετά με αυτόν τον ρόλο θα εκτελέσει άλλες ενέργειες.
Και το κακό είναι ότι αν στον Vasya αρέσει να συνδέεται στο Amazon με έναν τρόπο, για παράδειγμα, χρησιμοποιώντας την προεπιλεγμένη μεταβλητή περιβάλλοντος, και στον Petya αρέσει να χρησιμοποιεί το κοινόχρηστο κλειδί του, το οποίο έχει σε μυστικό μέρος, τότε δεν μπορείτε να καθορίσετε και τα δύο στο Terraform. Και για να μην υποφέρουν, δεν χρειάζεται να υποδεικνύεται αυτό το μπλοκ στη μονάδα. Αυτό πρέπει να υποδεικνύεται σε υψηλότερο επίπεδο. Δηλαδή, έχουμε μια ενότητα πόρων, μια ενότητα υποδομής και μια σύνθεση από πάνω. Και αυτό πρέπει να υποδεικνύεται κάπου ψηλότερα.
Το δεύτερο κακό είναι ο προμηθευτής. Εδώ το κακό δεν είναι τόσο ασήμαντο, γιατί αν γράφεις κώδικα και σου δουλεύει, τότε μπορεί να σκεφτείς ότι αν λειτουργεί, τότε γιατί να τον αλλάξεις.
Το κακό είναι ότι δεν ελέγχετε πάντα πότε θα ξεκινήσει αυτός ο πάροχος, πρώτα. Και δεύτερον, δεν ελέγχετε τι σημαίνει το aws ec2, δηλαδή μιλάμε για Linux ή Windows τώρα. Επομένως, δεν μπορείτε να γράψετε κάτι που θα λειτουργεί το ίδιο σε διαφορετικά λειτουργικά συστήματα ή για διαφορετικές περιπτώσεις χρηστών.
Το πιο συνηθισμένο παράδειγμα, το οποίο υποδεικνύεται επίσης στην επίσημη τεκμηρίωση, είναι ότι εάν γράψετε aws_instance και καθορίσετε μια δέσμη ορισμάτων, τότε δεν υπάρχει τίποτα κακό με αυτό εάν καθορίσετε τον προμηθευτή "local-exec" εκεί και εκτελέσετε το ansible- βιβλίο παιχνιδιού.
Στην πραγματικότητα, ναι, δεν υπάρχει τίποτα κακό σε αυτό. Αλλά κυριολεκτικά σύντομα θα συνειδητοποιήσετε ότι αυτό το τοπικό-exec δεν υπάρχει, για παράδειγμα, στο launch_configuration.
Και όταν χρησιμοποιείτε το launch_configuration και θέλετε να δημιουργήσετε μια ομάδα αυτόματης κλιμάκωσης από μία παρουσία, τότε στο launch_configuration δεν υπάρχει η έννοια του "προμηθευτή". Υπάρχει η έννοια των «δεδομένων χρήστη».
Επομένως, μια πιο καθολική λύση είναι η χρήση δεδομένων χρήστη. Και θα εκκινηθεί είτε στην ίδια την παρουσία, όταν η παρουσία είναι ενεργοποιημένη, είτε στα ίδια δεδομένα χρήστη, όταν η ομάδα αυτόματης κλιμάκωσης χρησιμοποιεί αυτό το launch_configuration.
Εάν εξακολουθείτε να θέλετε να εκτελέσετε τον προμηθευτή, επειδή είναι ένα κολλητικό στοιχείο, όταν δημιουργείται ένας πόρος, εκείνη τη στιγμή πρέπει να εκτελέσετε τον προμηθευτή σας, την εντολή σας. Υπάρχουν πολλές τέτοιες καταστάσεις.
Και ο πιο σωστός πόρος για αυτό ονομάζεται null_resource. Ο Null_resource είναι ένας εικονικός πόρος που δεν δημιουργείται ποτέ στην πραγματικότητα. Δεν αγγίζει τίποτα, κανένα API, καμία αυτόματη κλιμάκωση. Αλλά σας επιτρέπει να ελέγχετε πότε θα εκτελείτε την εντολή. Σε αυτήν την περίπτωση, η εντολή εκτελείται κατά τη δημιουργία.
Σύνδεσμος
Υπάρχουν πολλά σημάδια. Δεν θα μπω σε όλα τα ζώδια με μεγάλη λεπτομέρεια. Υπάρχει ένα άρθρο σχετικά με αυτό. Αλλά αν έχετε εργαστεί με το Terraform ή έχετε χρησιμοποιήσει ενότητες άλλων ανθρώπων, τότε έχετε συχνά παρατηρήσει ότι πολλές ενότητες, όπως το μεγαλύτερο μέρος του κώδικα σε ανοιχτό κώδικα, γράφονται από άτομα για τις δικές τους ανάγκες. Ένας άντρας το έγραψε και του έλυσε το πρόβλημά του. Το κόλλησα στο GitHub, αφήστε το να ζήσει. Θα ζήσει, αλλά αν δεν υπάρχει τεκμηρίωση και παραδείγματα εκεί, τότε κανείς δεν θα το χρησιμοποιήσει. Και αν δεν υπάρχει λειτουργικότητα που να σας επιτρέπει να λύσετε λίγο περισσότερο από τη συγκεκριμένη εργασία, τότε κανείς δεν θα τη χρησιμοποιήσει. Υπάρχουν τόσοι πολλοί τρόποι για να χάσετε χρήστες.
Εάν θέλετε να γράψετε κάτι ώστε να το χρησιμοποιούν οι άνθρωποι, τότε σας συνιστώ να ακολουθήσετε αυτά τα σημάδια.
Αυτά είναι:
- Τεκμηρίωση και παραδείγματα.
- Πλήρης λειτουργικότητα.
- Λογικές προεπιλογές.
- Καθαρός κώδικας.
- Δοκιμές.
Τα τεστ είναι μια διαφορετική κατάσταση γιατί είναι αρκετά δύσκολο να γραφτούν. Πιστεύω περισσότερο στην τεκμηρίωση και τα παραδείγματα.
Έτσι, εξετάσαμε πώς να γράφουμε ενότητες. Υπάρχουν δύο επιχειρήματα. Το πρώτο, το οποίο είναι και το πιο σημαντικό, είναι να μην γράψετε αν μπορείτε, γιατί πολλοί άνθρωποι έχουν ήδη κάνει αυτές τις εργασίες πριν από εσάς. Και δεύτερον, αν εξακολουθείτε να το αποφασίσετε, προσπαθήστε να μην χρησιμοποιείτε παρόχους σε ενότητες και παρόχους.
Αυτό είναι το γκρι μέρος της τεκμηρίωσης. Μπορεί τώρα να σκέφτεστε: «Κάτι δεν είναι ξεκάθαρο. Μη πεπεισμένος." Αλλά θα δούμε σε έξι μήνες.
Τώρα ας μιλήσουμε για το πώς να καλέσετε αυτές τις μονάδες.
Καταλαβαίνουμε ότι ο κώδικάς μας μεγαλώνει με την πάροδο του χρόνου. Δεν έχουμε πλέον ένα αρχείο, έχουμε ήδη 20 αρχεία. Είναι όλα σε έναν φάκελο. Ή ίσως σε πέντε φακέλους. Ίσως αρχίσουμε να τα αναλύουμε με κάποιο τρόπο ανά περιοχή, κατά κάποια στοιχεία. Τότε καταλαβαίνουμε ότι τώρα έχουμε κάποια βασικά στοιχεία συγχρονισμού και ενορχήστρωσης. Δηλαδή, πρέπει να καταλάβουμε τι πρέπει να κάνουμε αν αλλάξαμε πόρους δικτύου, τι πρέπει να κάνουμε με τους υπόλοιπους πόρους μας, πώς να προκαλέσουμε αυτές τις εξαρτήσεις κ.λπ.
Υπάρχουν δύο άκρα. Το πρώτο άκρο είναι όλα σε ένα. Έχουμε ένα κύριο αρχείο. Προς το παρόν, αυτή ήταν η επίσημη βέλτιστη πρακτική στον ιστότοπο Terraform.
Αλλά τώρα είναι γραμμένο ως καταργημένο και καταργημένο. Με τον καιρό, η κοινότητα Terraform συνειδητοποίησε ότι αυτό απείχε πολύ από την καλύτερη πρακτική, επειδή οι άνθρωποι άρχισαν να χρησιμοποιούν το έργο με διαφορετικούς τρόπους. Και υπάρχουν προβλήματα. Για παράδειγμα, όταν απαριθμούμε όλες τις εξαρτήσεις σε ένα μέρος. Υπάρχουν περιπτώσεις που κάνουμε κλικ στο «Σχέδιο Terraform» και μέχρι να ενημερώσει η Terraform τις καταστάσεις όλων των πόρων, μπορεί να περάσει πολύς χρόνος.
Ο πολύς χρόνος είναι, για παράδειγμα, 5 λεπτά. Για κάποιους αυτό είναι πολύς χρόνος. Έχω δει περιπτώσεις που χρειάστηκαν 15 λεπτά. Το AWS API ξόδεψε 15 λεπτά προσπαθώντας να καταλάβει τι συνέβαινε με την κατάσταση κάθε πόρου. Αυτή είναι μια πολύ μεγάλη περιοχή.
Και, φυσικά, ένα σχετικό πρόβλημα θα εμφανιστεί όταν θέλετε να αλλάξετε κάτι σε ένα μέρος, μετά περιμένετε 15 λεπτά και σας δίνει έναν καμβά με κάποιες αλλαγές. Έφτυσες, έγραψες «Ναι» και κάτι πήγε στραβά. Αυτό είναι ένα πολύ πραγματικό παράδειγμα. Η Terraform δεν προσπαθεί να σας προστατεύσει από προβλήματα. Δηλαδή γράψε ότι θέλεις. Θα υπάρξουν προβλήματα - τα προβλήματά σας. Ενώ το Terraform 0.11 δεν προσπαθεί να σας βοηθήσει με κανέναν τρόπο. Υπάρχουν ορισμένα ενδιαφέροντα μέρη στο 0.12 που σας επιτρέπουν να πείτε: "Βάσια, το θέλεις πραγματικά αυτό, μπορείς να συνέλθεις;"
Ο δεύτερος τρόπος είναι να μειωθεί αυτή η περιοχή, δηλαδή, οι κλήσεις από ένα μέρος μπορεί να είναι λιγότερο συνδεδεμένες από άλλο μέρος.
Το μόνο πρόβλημα είναι ότι πρέπει να γράψετε περισσότερο κώδικα, δηλαδή πρέπει να περιγράψετε μεταβλητές σε μεγάλο αριθμό αρχείων και να τον ενημερώσετε. Σε κάποιους δεν αρέσει. Αυτό είναι φυσιολογικό για μένα. Και μερικοί άνθρωποι σκέφτονται: «Γιατί να το γράψω αυτό σε διαφορετικά μέρη, θα τα βάλω όλα σε ένα μέρος». Αυτό είναι δυνατό, αλλά αυτό είναι το δεύτερο άκρο.
Ποιος έχει όλα αυτά να ζει σε ένα μέρος; Ένα, δύο, τρία άτομα, δηλαδή κάποιος το χρησιμοποιεί.
Και ποιος καλεί ένα συγκεκριμένο στοιχείο, ένα μπλοκ ή μια ενότητα υποδομής; Πέντε έως επτά άτομα. Αυτό είναι ωραίο.
Η πιο συνηθισμένη απάντηση βρίσκεται κάπου στη μέση. Εάν το έργο είναι μεγάλο, τότε θα έχετε συχνά μια κατάσταση όπου καμία λύση δεν είναι κατάλληλη και δεν λειτουργούν όλα εκεί έξω, οπότε καταλήγετε σε ένα μείγμα. Δεν υπάρχει τίποτα κακό σε αυτό, αρκεί να καταλάβετε ότι και τα δύο έχουν πλεονεκτήματα.
Εάν κάτι άλλαξε στη στοίβα VPC και θέλετε να εφαρμόσετε αυτές τις αλλαγές στο EC2, δηλαδή θέλετε να ενημερώσετε την ομάδα αυτόματης κλιμάκωσης επειδή είχατε ένα νέο υποδίκτυο, τότε ονομάζω αυτό το είδος ενορχήστρωσης εξάρτησης. Υπάρχουν κάποιες λύσεις: ποιος χρησιμοποιεί τι;
Μπορώ να προτείνω ποιες λύσεις υπάρχουν. Μπορείτε να χρησιμοποιήσετε το Terraform για να κάνετε τα μαγικά ή μπορείτε να χρησιμοποιήσετε αρχεία makefiles για να χρησιμοποιήσετε το Terraform. Και δείτε αν κάτι έχει αλλάξει εκεί, μπορείτε να το εκκινήσετε εδώ.
Πώς σας φαίνεται αυτή η απόφαση; Πιστεύει κανείς ότι αυτή είναι μια καλή λύση; Βλέπω ένα χαμόγελο, προφανώς έχουν μπει αμφιβολίες.
Φυσικά, μην το δοκιμάσετε στο σπίτι. Το Terraform δεν σχεδιάστηκε ποτέ για να εκτελείται από το Terraform.
Σε μια αναφορά μου είπαν: «Όχι, αυτό δεν θα λειτουργήσει». Το θέμα είναι ότι δεν πρέπει να λειτουργεί. Αν και φαίνεται τόσο εντυπωσιακό όταν μπορείτε να εκκινήσετε το Terraform από το Terraform και μετά το Terraform, δεν πρέπει να το κάνετε αυτό. Το Terraform πρέπει πάντα να ξεκινά πολύ εύκολα.
Εάν χρειάζεστε ενορχήστρωση κλήσεων όταν κάτι έχει αλλάξει σε ένα μέρος, τότε υπάρχει το Terragrunt.
Το Terragrunt είναι ένα βοηθητικό πρόγραμμα, ένα πρόσθετο στο Terraform, που σας επιτρέπει να συντονίζετε και να ενορχηστρώνετε κλήσεις σε μονάδες υποδομής.
Ένα τυπικό αρχείο διαμόρφωσης Terraform μοιάζει με αυτό.
Καθορίζετε ποια συγκεκριμένη ενότητα θέλετε να καλέσετε.
Τι εξαρτήσεις έχει η ενότητα;
Και ποια επιχειρήματα δέχεται αυτή η ενότητα. Αυτά είναι όλα όσα πρέπει να ξέρουμε για το Terragrunt.
Η τεκμηρίωση υπάρχει και υπάρχουν 1 αστέρια στο GitHub. Αλλά στις περισσότερες περιπτώσεις αυτό είναι που πρέπει να γνωρίζετε. Και αυτό είναι πολύ εύκολο να εφαρμοστεί σε εταιρείες που μόλις αρχίζουν να συνεργάζονται με την Terraform.
Άρα η ενορχήστρωση είναι Terragrunt. Υπάρχουν και άλλες επιλογές.
Τώρα ας μιλήσουμε για τον τρόπο εργασίας με τον κώδικα.
Εάν χρειάζεται να προσθέσετε νέες δυνατότητες στον κώδικά σας, στις περισσότερες περιπτώσεις αυτό είναι εύκολο. Γράφετε έναν νέο πόρο, όλα είναι απλά.
Εάν έχετε κάποιο πόρο που δημιουργήσατε εκ των προτέρων, για παράδειγμα, μάθατε για το Terraform αφού ανοίξατε έναν λογαριασμό AWS και θέλετε να χρησιμοποιήσετε τους πόρους που έχετε ήδη, τότε θα ήταν σκόπιμο να επεκτείνετε την ενότητα σας με αυτόν τον τρόπο, ώστε να υποστηρίζει τη χρήση των υπαρχόντων πόρων.
Και υποστήριξε τη δημιουργία νέων πόρων χρησιμοποιώντας τον πόρο μπλοκ.
Στην έξοδο επιστρέφουμε πάντα το αναγνωριστικό εξόδου ανάλογα με το τι χρησιμοποιήθηκε.
Το δεύτερο πολύ σημαντικό πρόβλημα στο Terraform 0.11 είναι η εργασία με λίστες.
Η δυσκολία είναι ότι αν έχουμε μια τέτοια λίστα χρηστών.
Και όταν δημιουργούμε αυτούς τους χρήστες χρησιμοποιώντας πόρο μπλοκ, τότε όλα πάνε καλά. Προχωράμε σε ολόκληρη τη λίστα, δημιουργώντας ένα αρχείο για το καθένα. Ολα ειναι καλά. Και τότε, για παράδειγμα, ο χρήστης3, που βρίσκεται στη μέση, θα πρέπει να αφαιρεθεί από εδώ, τότε όλοι οι πόροι που δημιουργήθηκαν μετά από αυτόν θα αναδημιουργηθούν επειδή το ευρετήριο θα αλλάξει.
Εργασία με λίστες σε ένα κρατικό περιβάλλον. Τι είναι ένα κρατικό περιβάλλον; Αυτή είναι η κατάσταση όπου δημιουργείται μια νέα τιμή όταν δημιουργείται αυτός ο πόρος. Για παράδειγμα, AWS Access Key ή AWS Secret Key, δηλαδή όταν δημιουργούμε έναν χρήστη, λαμβάνουμε ένα νέο Access ή Secret Key. Και κάθε φορά που διαγράφουμε έναν χρήστη, αυτός ο χρήστης θα έχει ένα νέο κλειδί. Αλλά αυτό δεν είναι φενγκ σούι, γιατί ο χρήστης δεν θα θέλει να είναι φίλος μαζί μας αν του δημιουργούμε έναν νέο χρήστη κάθε φορά που κάποιος φεύγει από την ομάδα.
Αυτή είναι η λύση. Αυτός είναι κώδικας γραμμένος σε Jsonnet. Το Jsonnet είναι μια γλώσσα προτύπων από την Google.
Αυτή η εντολή σάς επιτρέπει να αποδεχτείτε αυτό το πρότυπο και ως έξοδο επιστρέφει ένα αρχείο json που έχει δημιουργηθεί σύμφωνα με το πρότυπό σας.
Το πρότυπο μοιάζει με αυτό.
Το Terraform σάς επιτρέπει να εργάζεστε τόσο με το HCL όσο και με το Json με τον ίδιο τρόπο, οπότε αν έχετε τη δυνατότητα να δημιουργήσετε Json, τότε μπορείτε να το βάλετε στο Terraform. Το αρχείο με την επέκταση .tf.json θα ληφθεί με επιτυχία.
Και μετά δουλεύουμε με αυτό ως συνήθως: terraform init, terramorm ισχύει. Και δημιουργούμε δύο χρήστες.
Τώρα δεν φοβόμαστε αν φύγει κάποιος από την ομάδα. Απλώς θα επεξεργαστούμε το αρχείο json. Ο Vasya Pupkin έφυγε, ο Petya Pyatochkin παρέμεινε. Η Petya Pyatochkin δεν θα λάβει νέο κλειδί.
Η ενσωμάτωση του Terraform με άλλα εργαλεία δεν είναι πραγματικά δουλειά της Terraform. Το Terraform δημιουργήθηκε ως πλατφόρμα για τη δημιουργία πόρων και τέλος. Και όλα όσα έρχονται αργότερα δεν είναι μέλημα της Terraform. Και δεν χρειάζεται να το υφάνεις εκεί μέσα. Υπάρχει το Ansible, το οποίο κάνει όλα όσα χρειάζεστε.
Αλλά προκύπτουν καταστάσεις όταν θέλουμε να επεκτείνουμε το Terraform και να καλέσουμε κάποια εντολή αφού έχει ολοκληρωθεί κάτι.
Πρώτος τρόπος. Δημιουργούμε μια έξοδο όπου γράφουμε αυτήν την εντολή.
Στη συνέχεια καλούμε αυτήν την εντολή από την έξοδο shell terraform και καθορίζουμε την τιμή που θέλουμε. Έτσι, η εντολή εκτελείται με όλες τις αντικατεστημένες τιμές. Είναι πολύ άνετο.
Δεύτερος τρόπος. Αυτή είναι η χρήση του null_resource ανάλογα με τις αλλαγές στην υποδομή μας. Μπορούμε να καλέσουμε το ίδιο local-exe μόλις αλλάξει το αναγνωριστικό κάποιου πόρου.
Φυσικά, όλα αυτά είναι ομαλά στα χαρτιά, επειδή η Amazon, όπως και όλοι οι άλλοι δημόσιοι πάροχοι, έχει ένα σωρό δικές της θήκες.
Η πιο συνηθισμένη περίπτωση είναι ότι όταν ανοίγετε έναν λογαριασμό AWS, έχει σημασία ποιες περιοχές χρησιμοποιείτε. Είναι ενεργοποιημένη αυτή η δυνατότητα εκεί; ίσως το άνοιξες μετά τον Δεκέμβριο του 2013. ίσως χρησιμοποιείτε προεπιλογή στο VPC κλπ. Υπάρχουν πολλοί περιορισμοί. Και η Amazon τα σκόρπισε σε όλη την τεκμηρίωση.
Υπάρχουν μερικά πράγματα που συνιστώ να αποφύγετε.
Για να ξεκινήσετε, αποφύγετε όλα τα μη απόρρητα επιχειρήματα εντός του σχεδίου Terraform ή του Terraform CLI. Όλα αυτά μπορούν να τοποθετηθούν είτε σε ένα αρχείο tfvars είτε σε μια μεταβλητή περιβάλλοντος.
Αλλά δεν χρειάζεται να απομνημονεύσετε όλη αυτή τη μαγική εντολή. Terraform plan – var και φεύγουμε. Η πρώτη μεταβλητή είναι var, η δεύτερη μεταβλητή είναι var, η τρίτη, τέταρτη. Η πιο σημαντική αρχή της υποδομής ως κώδικα που χρησιμοποιώ πιο συχνά είναι ότι κοιτάζοντας μόνο τον κώδικα, θα πρέπει να έχω ξεκάθαρη κατανόηση του τι αναπτύσσεται εκεί, σε ποια κατάσταση και με ποιες τιμές. Και έτσι δεν χρειάζεται να διαβάσω την τεκμηρίωση ή να ρωτήσω τον Vasya ποιες παραμέτρους χρησιμοποίησε για να δημιουργήσει το σύμπλεγμα μας. Απλά πρέπει να ανοίξω ένα αρχείο με την επέκταση tfvars, που συχνά ταιριάζει με το περιβάλλον, και να κοιτάξω τα πάντα εκεί.
Επίσης, μην χρησιμοποιείτε ορίσματα στόχου για να μειώσετε το εύρος. Για αυτό είναι πολύ πιο εύκολο να χρησιμοποιήσετε μικρές μονάδες υποδομής.
Επίσης, δεν υπάρχει λόγος περιορισμού και αύξησης του παραλληλισμού. Εάν έχω 150 πόρους και θέλω να αυξήσω τον παραλληλισμό του Amazon από το προεπιλεγμένο 10 σε 100, τότε πιθανότατα κάτι θα πάει στραβά. Ή μπορεί να πάει καλά τώρα, αλλά όταν η Amazon λέει ότι πραγματοποιείτε πάρα πολλές κλήσεις, θα έχετε πρόβλημα.
Η Terraform θα προσπαθήσει να επανεκκινήσει τα περισσότερα από αυτά τα προβλήματα, αλλά δεν θα πετύχετε σχεδόν τίποτα. Το Parallelism=1 είναι ένα σημαντικό πράγμα που πρέπει να χρησιμοποιήσετε εάν συναντήσετε κάποιο σφάλμα μέσα στο API AWS ή μέσα στον πάροχο Terraform. Και μετά πρέπει να καθορίσετε: parallelism=1 και περιμένετε έως ότου η Terraform ολοκληρώσει τη μία κλήση, μετά τη δεύτερη και μετά την τρίτη. Θα τα εκτοξεύσει ένα προς ένα.
Οι άνθρωποι συχνά με ρωτούν, "Γιατί νομίζω ότι οι χώροι εργασίας Terraform είναι κακοί;" Πιστεύω ότι η αρχή της υποδομής ως κώδικα είναι να δούμε τι υποδομή έχει δημιουργηθεί και με ποιες αξίες.
Οι χώροι εργασίας δεν δημιουργήθηκαν από χρήστες. Αυτό δεν σημαίνει ότι οι χρήστες έγραψαν στα ζητήματα του GitHub ότι δεν μπορούμε να ζήσουμε χωρίς χώρους εργασίας Terraform. Όχι έτσι. Η Terraform Enterprise είναι μια εμπορική λύση. Η Terraform από τη HashiCorp αποφάσισε ότι χρειαζόμασταν χώρους εργασίας, οπότε την καταθέσαμε. Θεωρώ ότι είναι πολύ πιο εύκολο να το βάλω σε ξεχωριστό φάκελο. Μετά θα υπάρχουν λίγο περισσότερα αρχεία, αλλά θα είναι πιο ξεκάθαρο.
Πώς να εργαστείτε με τον κωδικό; Στην πραγματικότητα, η εργασία με λίστες είναι ο μόνος πόνος. Και πάρτε το Terraform πιο εύκολα. Αυτό δεν είναι το πράγμα που θα κάνει τα πάντα υπέροχα για εσάς. Δεν χρειάζεται να ρίξετε εκεί όλα όσα αναγράφονται στην τεκμηρίωση.
Το θέμα της έκθεσης γράφτηκε «για το μέλλον». Θα μιλήσω για αυτό πολύ σύντομα. Για το μέλλον, αυτό σημαίνει ότι το 0.12 θα κυκλοφορήσει σύντομα.
Το 0.12 είναι ένα σωρό νέα πράγματα. Εάν προέρχεστε από κανονικό προγραμματισμό, τότε χάνετε όλα τα είδη δυναμικών μπλοκ, βρόχων, σωστών και υπό όρους συγκρίσεων, όπου η αριστερή και η δεξιά πλευρά δεν υπολογίζονται ταυτόχρονα, αλλά ανάλογα με την κατάσταση. Σας λείπει πολύ, οπότε το 0.12 θα σας το λύσει.
Αλλά! Εάν γράφετε λιγότερο και πιο απλά, χρησιμοποιώντας έτοιμες ενότητες και λύσεις τρίτων, τότε δεν θα χρειαστεί να περιμένετε και να ελπίζετε ότι θα έρθει το 0.12 και θα σας φτιάξει τα πάντα.
Ευχαριστώ για την αναφορά! Μιλήσατε για την υποδομή ως κώδικα και είπατε κυριολεκτικά μια λέξη για τις δοκιμές. Χρειάζονται δοκιμές σε ενότητες; Ποιανού ευθύνη είναι αυτή; Πρέπει να το γράψω μόνος μου ή είναι ευθύνη των ενοτήτων;
Η επόμενη χρονιά θα είναι γεμάτη με αναφορές ότι έχουμε αποφασίσει να δοκιμάσουμε τα πάντα. Τι να δοκιμάσετε είναι το μεγαλύτερο ερώτημα. Υπάρχουν πολλές εξαρτήσεις, πολλοί περιορισμοί από διαφορετικούς παρόχους. Όταν εγώ και εσύ μιλάμε και λες: «Χρειάζομαι τεστ», τότε ρωτάω: «Τι θα δοκιμάσεις;» Λέτε ότι θα δοκιμάσετε στην περιοχή σας. Τότε λέω ότι αυτό δεν λειτουργεί στην περιοχή μου. Δηλαδή, δεν θα μπορέσουμε καν να συμφωνήσουμε σε αυτό. Για να μην αναφέρουμε ότι υπάρχουν πολλά τεχνικά προβλήματα. Δηλαδή πώς να γράψετε αυτά τα τεστ ώστε να είναι επαρκή.
Ερευνώ ενεργά αυτό το θέμα, δηλαδή πώς να δημιουργώ αυτόματα δοκιμές με βάση την υποδομή που γράψατε. Δηλαδή, αν γράψατε αυτόν τον κώδικα, τότε πρέπει να τον εκτελέσω, με βάση αυτό μπορώ να δημιουργήσω δοκιμές.
είναι μια από τις πιο συχνά αναφερόμενες βιβλιοθήκες που σας επιτρέπει να γράφετε δοκιμές ενοποίησης για το Terraform. Αυτό είναι ένα από τα βοηθητικά προγράμματα. Προτιμώ τον τύπο DSL, για παράδειγμα, rspec.
Αντώνη, ευχαριστώ για την αναφορά! Το όνομά μου είναι Valery. Να κάνω μια μικρή φιλοσοφική ερώτηση. Υπάρχει, υπό όρους, παροχή, υπάρχει ανάπτυξη. Η παροχή δημιουργεί την υποδομή μου, κατά την ανάπτυξη τη γεμίζουμε με κάτι χρήσιμο, για παράδειγμα, διακομιστές, εφαρμογές κ.λπ. Και πιστεύω ότι το Terraform είναι περισσότερο για παροχή και το Ansible είναι περισσότερο για ανάπτυξη, επειδή το Ansible είναι επίσης για φυσική Η υποδομή σας επιτρέπει να εγκαταστήσετε το nginx, Postgres. Αλλά την ίδια στιγμή, το Ansible φαίνεται να επιτρέπει την παροχή, για παράδειγμα, πόρων της Amazon ή της Google. Αλλά το Terraform σας επιτρέπει επίσης να αναπτύξετε κάποιο λογισμικό χρησιμοποιώντας τις ενότητες του. Από την άποψή σας, υπάρχει κάποιο είδος συνόρων που εκτείνεται μεταξύ Terraform και Ansible, πού και τι είναι καλύτερο να χρησιμοποιήσετε; Ή, για παράδειγμα, πιστεύετε ότι το Ansible είναι ήδη σκουπίδια, θα πρέπει να προσπαθήσετε να χρησιμοποιήσετε το Terraform για τα πάντα;
Καλή ερώτηση, Valery. Πιστεύω ότι η Terraform δεν έχει αλλάξει ως προς τον σκοπό από το 2014. Δημιουργήθηκε για υποδομές και πέθανε για υποδομές. Εξακολουθούσαμε να είχαμε και θα έχουμε ανάγκη για διαχείριση διαμόρφωσης Ansible. Η πρόκληση είναι ότι υπάρχουν δεδομένα χρήστη μέσα στο launch_configuration. Και εκεί τραβάς Ansible, κλπ. Αυτή είναι η τυπική διάκριση που μου αρέσει περισσότερο.
Αν μιλάμε για όμορφες υποδομές, τότε υπάρχουν βοηθητικά προγράμματα όπως το Packer που συλλέγουν αυτήν την εικόνα. Στη συνέχεια, η Terraform χρησιμοποιεί την πηγή δεδομένων για να βρει αυτήν την εικόνα και να ενημερώσει το launch_configuration της. Δηλαδή, με αυτόν τον τρόπο ο αγωγός είναι ότι πρώτα τραβάμε το Tracker και μετά τραβάμε το Terraform. Και αν συμβεί η κατασκευή, τότε εμφανίζεται μια νέα αλλαγή.
Γειά σου! Ευχαριστώ για την αναφορά! Το όνομά μου είναι Misha, εταιρεία RBS. Μπορείτε να καλέσετε το Ansible μέσω του παρόχου όταν δημιουργείτε έναν πόρο. Το Ansible έχει επίσης ένα θέμα που ονομάζεται δυναμικό απόθεμα. Και μπορείτε πρώτα να καλέσετε το Terraform και μετά να καλέσετε το Ansible, το οποίο θα πάρει πόρους από το κράτος και θα το εκτελέσει. Τι καλύτερο;
Οι άνθρωποι χρησιμοποιούν και τα δύο με την ίδια επιτυχία. Μου φαίνεται ότι το δυναμικό απόθεμα στο Ansible είναι ένα βολικό πράγμα, αν δεν μιλάμε για ομάδα αυτόματης κλιμάκωσης. Γιατί στην ομάδα αυτόματης κλιμάκωσης έχουμε ήδη τη δική μας εργαλειοθήκη, η οποία ονομάζεται launch_configuration. Στο launch_configuration καταγράφουμε όλα όσα πρέπει να εκκινηθούν όταν δημιουργούμε έναν νέο πόρο. Επομένως, με την Amazon, η χρήση δυναμικού αποθέματος και η ανάγνωση του αρχείου Terraform ts, κατά τη γνώμη μου, είναι υπερβολική. Και αν χρησιμοποιείτε άλλα εργαλεία όπου δεν υπάρχει η έννοια της "ομάδας αυτόματης κλιμάκωσης", για παράδειγμα, χρησιμοποιείτε το DigitalOcean ή κάποιον άλλο πάροχο όπου δεν υπάρχει ομάδα αυτόματης κλιμάκωσης, τότε εκεί θα πρέπει να τραβήξετε χειροκίνητα το API, να βρείτε διευθύνσεις IP, να δημιουργήσετε ένα δυναμικό αρχείο αποθέματος και το Ansible θα περιπλανηθεί ήδη σε αυτό. Δηλαδή για το Amazon υπάρχει launch_configuration και για οτιδήποτε άλλο υπάρχει δυναμικό inventory.
Πηγή: www.habr.com