Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Οι ερωτήσεις που σχετίζονται με τη δομή του κώδικα της Terraform είναι μακράν οι πιο συχνές στην κοινότητα. Όλοι σκέφτηκαν επίσης κάποια στιγμή για την καλύτερη δομή κώδικα για το έργο.
Αυτή είναι μία από τις ερωτήσεις όπου υπάρχουν πολλές πιθανές λύσεις και είναι πολύ δύσκολο να δώσουμε γενικές οδηγίες, οπότε ας ξεκινήσουμε με την κατανόηση του τι αντιμετωπίζουμε.
Ποια είναι η πολυπλοκότητα του έργου σας;
Αριθμός σχετικών πόρων
Αριθμός παρόχων Terraform (βλ. σημείωση παρακάτω σχετικά με τους "λογικούς παρόχους")
Πόσο συχνά αλλάζει η υποδομή σας;
Από μία φορά το μήνα/εβδομάδα/ημέρα
Μέχρι συνεχώς (κάθε φορά που υπάρχει ένα νέο commit)
Εναύσματα αλλαγής κώδικα; Αφήνετε τον CI server να ενημερώνει το repository όταν κατασκευάζεται ένα νέο artifact;
Μόνο οι προγραμματιστές μπορούν να κάνουν push στο repository υποδομής
Όλοι μπορούν να προτείνουν μια αλλαγή σε ο,τιδήποτε ανοίγοντας ένα PR (συμπεριλαμβανομένων των αυτοματοποιημένων εργασιών που εκτελούνται στον CI server)
Ποια πλατφόρμα ανάπτυξης ή υπηρεσία ανάπτυξης χρησιμοποιείτε;
Το AWS CodeDeploy, το Kubernetes ή το OpenShift απαιτούν μια ελαφρώς διαφορετική προσέγγιση
Πώς ομαδοποιούνται τα περιβάλλοντα;
Ανά περιβάλλον, περιοχή, έργο
Η τοποθέτηση όλου του κώδικα στο main.tf
είναι μια καλή ιδέα όταν ξεκινάτε ή όταν γράφετε ένα παράδειγμα κώδικα. Σε όλες τις άλλες περιπτώσεις θα είναι καλύτερα να έχετε διάφορα αρχεία χωρισμένα λογικά όπως αυτό:
main.tf
- κλήση μονάδων, τοπικών μονάδων και πηγών δεδομένων για τη δημιουργία όλων των πόρων
variables.tf
- περιέχει δηλώσεις των μεταβλητών που χρησιμοποιούνται στο main.tf
outputs.tf
- περιέχει τα outpus από τους πόρους που δημιουργήθηκαν στο main.tf
versions.tf
- περιέχει απαιτήσεις versioning για το Terraform και τους παρόχους
Το terraform.tfvars
δεν πρέπει να χρησιμοποιείται πουθενά αλλού εκτός από τη σύνθεση
Βεβαιωθείτε ότι έχετε κατανοήσει τις βασικές έννοιες - μονάδα πόρου, μονάδα υποδομής και σύνθεση, όπως χρησιμοποιούνται στα παρακάτω παραδείγματα.
Είναι ευκολότερο και γρηγορότερο να εργάζεστε με μικρότερο αριθμό πόρων
Το terraform plan
και το terraform apply
πραγματοποιούν και τα δύο κλήσεις cloud API για να επαληθεύσουν την κατάσταση των πόρων
Εάν έχετε ολόκληρη την υποδομή σας σε μία μόνο σύνθεση αυτό μπορεί να πάρει αρκετό χρόνο
Η ακτίνα επίδρασης (σε περίπτωση παραβίασης της ασφάλειας) είναι μικρότερη με λιγότερους πόρους
Η απομόνωση μη συνδεδεμένων πόρων μεταξύ τους με την τοποθέτησή τους σε ξεχωριστές συνθέσεις μειώνει τον κίνδυνο αν κάτι πάει στραβά
Ξεκινήστε το έργο σας χρησιμοποιώντας απομακρυσμένη κατάσταση επειδή:
Ο φορητός σας υπολογιστής δεν είναι κατάλληλο μέρος για την «πηγή αλήθειας» της υποδομής σας
Η διαχείριση ενός αρχείου tfstate
στο git είναι εφιάλτης
Αργότερα, όταν τα επίπεδα υποδομής αρχίσουν να αυξάνονται προς πολλές κατευθύνσεις (αριθμός εξαρτήσεων ή πόρων) θα είναι ευκολότερο να κρατήσετε τα πράγματα υπό έλεγχο
Εφαρμόστε μια συνεπή δομή και σύμβαση ονομασίας:
Όπως και ο διαδικαστικός κώδικας, ο κώδικας Terraform θα πρέπει να γράφεται πρώτα για να τον διαβάζουν οι άνθρωποι, η συνέπεια θα βοηθήσει όταν θα γίνουν αλλαγές σε έξι μήνες από τώρα.
Είναι δυνατή η μετακίνηση πόρων στο αρχείο κατάστασης Terraform, αλλά μπορεί να είναι πιο δύσκολο να γίνει αν έχετε ασυνεπή δομή και ονοματοδοσία
Διατηρήστε τις ενότητες πόρων όσο το δυνατόν πιο απλές
Μην γράφετε hardcoded τιμές που μπορούν να περάσουν ως μεταβλητές ή να ανακαλυφθούν με τη χρήση πηγών δεδομένων
Χρησιμοποιήστε τις πηγές δεδομένων και το terraform_remote_state
ειδικά ως "συγκολλητικό υλικό" μεταξύ των μονάδων υποδομής εντός της σύνθεσης
Σε αυτό το βιβλίο τα παραδείγματα έργων ομαδοποιούνται ανάλογα με την πολυπλοκότητα - από μικρές έως πολύ μεγάλες υποδομές. Αυτός ο διαχωρισμός δεν είναι αυστηρός, οπότε ελέγξτε και άλλες δομές.
Η ύπαρξη μιας μικρής υποδομής σημαίνει ότι υπάρχει μικρός αριθμός εξαρτήσεων και λίγοι πόροι. Καθώς το έργο μεγαλώνει, γίνεται εμφανής η ανάγκη για την αλυσιδωτή εκτέλεση των ρυθμίσεων του Terraform, τη σύνδεση διαφορετικών μονάδων υποδομής και τη μεταβίβαση τιμών εντός μιας σύνθεσης.
Υπάρχουν τουλάχιστον 5 διακριτές ομάδες λύσεων ενορχήστρωσης που χρησιμοποιούν οι προγραμματιστές:
Μόνο Terraform. Πολύ απλό, οι προγραμματιστές πρέπει να γνωρίζουν μόνο το Terraform για να κάνουν τη δουλειά τους.
Terragrunt. Καθαρό εργαλείο ενορχήστρωσης το οποίο μπορεί να χρησιμοποιηθεί για την ενορχήστρωση ολόκληρης της υποδομής καθώς και για το χειρισμό των εξαρτήσεων. Το Terragrunt λειτουργεί με ενότητες υποδομής και συνθέσεις εγγενώς, οπότε μειώνει την επανάληψη του κώδικα.
Εσωτερικά scripts. Συχνά αυτό συμβαίνει ως σημείο εκκίνησης προς την ενορχήστρωση και πριν την ανακάλυψη του Terragrunt.
Ansible ή παρόμοιο εργαλείο αυτοματοποίησης γενικού σκοπού. Συνήθως χρησιμοποιείται όταν το Terraform υιοθετείται μετά το Ansible ή όταν χρησιμοποιείται ενεργά το Ansible UI.
Crossplane και άλλες λύσεις εμπνευσμένες από το Kubernetes. Μερικές φορές έχει νόημα να αξιοποιήσετε το οικοσύστημα Kubernetes και να χρησιμοποιήσετε μια λειτουργία βρόχου «συμφιλίωσης» για να επιτύχετε την επιθυμητή κατάσταση των ρυθμίσεων του Terraform σας. Δείτε το βίντεο Crossplane vs Terraform για περισσότερες πληροφορίες.
Έχοντας αυτό κατά νου, αυτό το βιβλίο εξετάζει τις δύο πρώτες από αυτές τις δομές έργων, το Terraform only και το Terragrunt.
Δείτε παραδείγματα δομών κώδικα για Terraform ή Terragrunt στο επόμενο κεφάλαιο.
Αυτό το παράδειγμα περιέχει κώδικα ως παράδειγμα δόμησης των ρυθμίσεων Terraform για μια μεσαίου μεγέθους υποδομή που χρησιμοποιεί:
2 λογαριασμούς AWS
2 ξεχωριστά περιβάλλοντα (prod
και stage
που δεν διαμοιράζονται τίποτα). Κάθε περιβάλλον ζει σε ξεχωριστό λογαριασμό AWS
Κάθε περιβάλλον χρησιμοποιεί την ίδια έκδοση μιας εσωτερικής μονάδας modules/network
, καθώς προέρχεται από έναν τοπικό κατάλογο.
Ιδανικό για έργα όπου η υποδομή διαχωρίζεται λογικά (ξεχωριστοί λογαριασμοί AWS)
Καλό όταν δεν υπάρχει ανάγκη τροποποίησης πόρων που διαμοιράζονται μεταξύ λογαριασμών AWS (ένα περιβάλλον = ένας λογαριασμός AWS = ένα αρχείο κατάστασης)
Καλό όταν δεν υπάρχει ανάγκη ενορχήστρωσης των αλλαγών μεταξύ των περιβαλλόντων
Καλό όταν οι πόροι υποδομής είναι διαφορετικοί ανά περιβάλλον επίτηδες και δεν μπορούν να γενικευτούν (π.χ. κάποιοι πόροι απουσιάζουν από ένα περιβάλλον ή από ορισμένες περιοχές)
Καθώς το έργο μεγαλώνει, θα είναι πιο δύσκολο να διατηρούνται αυτά τα περιβάλλοντα ενημερωμένα μεταξύ τους. Εξετάστε το ενδεχόμενο χρήσης μονάδων υποδομής (έτοιμων ή εσωτερικών) για επαναλαμβανόμενες εργασίες.
Το παρόν έγγραφο αποτελεί μια προσπάθεια συστηματικής περιγραφής των βέλτιστων πρακτικών χρήσης του Terraform και παροχής συστάσεων για τα συχνότερα προβλήματα που αντιμετωπίζουν οι χρήστες του.
Ορισμένες πληροφορίες που περιγράφονται σε αυτό το βιβλίο μπορεί να μην φαίνονται ως οι βέλτιστες πρακτικές. Το γνωρίζω αυτό και για να βοηθήσω τους αναγνώστες να διαχωρίσουν ποιες είναι οι καθιερωμένες βέλτιστες πρακτικές και ποιος είναι απλώς ένας άλλος δογματικός τρόπος να γίνονται τα πράγματα, χρησιμοποιώ μερικές φορές υποδείξεις για να δώσω κάποιο πλαίσιο και εικονίδια για να προσδιορίσω το επίπεδο ωριμότητας σε κάθε υποενότητα που σχετίζεται με τις βέλτιστες πρακτικές.
Λίγα χρόνια αργότερα έχει ενημερωθεί με περισσότερες πραγματικές βέλτιστες πρακτικές που είναι διαθέσιμες με το Terraform 1.0. Τελικά, αυτό το βιβλίο θα πρέπει να περιέχει τις περισσότερες από τις αδιαμφισβήτητες βέλτιστες πρακτικές και συστάσεις για τους χρήστες του Terraform.
Επικοινωνήστε μαζί μου αν θέλετε να βοηθήσετε στη μετάφραση αυτού του βιβλίου σε άλλες γλώσσες.
Θέλω πάντα να λαμβάνω σχόλια και να ενημερώνω αυτό το βιβλίο καθώς η κοινότητα ωριμάζει και νέες ιδέες εφαρμόζονται και επαληθεύονται με την πάροδο του χρόνου.
Το έργο αυτό διατίθεται με άδεια Apache 2 License. Δείτε το LICENSE για πλήρεις λεπτομέρειες.
Οι συγγραφείς και οι συντελεστές αυτού του περιεχομένου δεν μπορούν να εγγυηθούν την εγκυρότητα των πληροφοριών που βρίσκονται εδώ. Βεβαιωθείτε ότι κατανοείτε ότι οι πληροφορίες που παρέχονται εδώ παρέχονται δωρεάν και ότι δεν δημιουργείται κανενός είδους συμφωνία ή σύμβαση μεταξύ εσάς και οποιουδήποτε προσώπου που σχετίζεται με αυτό το περιεχόμενο ή το έργο. Οι συγγραφείς και οι συντελεστές δεν αναλαμβάνουν και αποποιούνται με το παρόν κάθε ευθύνη έναντι οποιουδήποτε μέρους για οποιαδήποτε απώλεια, ζημία ή διαταραχή που προκαλείται από λάθη ή παραλείψεις στις πληροφορίες που περιέχονται στο παρόν περιεχόμενο, σχετίζονται με αυτό ή συνδέονται με αυτό, είτε τα εν λόγω λάθη ή παραλείψεις οφείλονται σε αμέλεια, ατύχημα ή οποιαδήποτε άλλη αιτία.
Copyright © 2018-2023 Anton Babenko.
Αυτό το παράδειγμα περιέχει κώδικα ως παράδειγμα δόμησης των ρυθμίσεων του Terraform για μια υποδομή μικρού μεγέθους, όπου δεν χρησιμοποιούνται εξωτερικές εξαρτήσεις.
Ιδανικό για να ξεκινήσετε και να αναδιαμορφώσετε καθώς προχωράτε
Ιδανικό για μικρές ενότητες πόρων
Καλό για μικρό αριθμό πόρων (λιγότερους από 20-30)
Το ενιαίο αρχείο κατάστασης για όλους τους πόρους μπορεί να κάνει τη διαδικασία εργασίας με το Terraform αργή αν ο αριθμός των πόρων αυξάνεται (εξετάστε το ενδεχόμενο να χρησιμοποιήσετε ένα όρισμα -target
για να περιορίσετε τον αριθμό των πόρων)
Δεν θα πρέπει να υπάρχει κανένας λόγος να μην ακολουθείτε τουλάχιστον αυτές τις συμβάσεις :)
Προσέξτε ότι οι πραγματικοί πόροι του cloud συχνά έχουν περιορισμούς στα επιτρεπόμενα ονόματα. Ορισμένοι πόροι, για παράδειγμα, δεν μπορούν να περιέχουν παύλες, ενώ ορισμένοι πρέπει να είναι γραμμένοι με κεφαλαία γράμματα. Οι συμβάσεις σε αυτό το βιβλίο αναφέρονται στα ίδια τα ονόματα του Terraform.
Χρησιμοποιήστε _
(υπογράμμιση) αντί για -
(παύλα) παντού (σε ονόματα πόρων, ονόματα πηγών δεδομένων, ονόματα μεταβλητών, εξόδους κλπ.).
Προτιμήστε να χρησιμοποιείτε πεζά γράμματα και αριθμούς (παρόλο που υποστηρίζεται το UTF-8).
Μην επαναλαμβάνετε τον τύπο του πόρου στο όνομα του πόρου (ούτε μερικώς ούτε πλήρως):
Χρησιμοποιείτε πάντα ουσιαστικά στον ενικό αριθμό για τα ονόματα.
Χρησιμοποιήστε -
μέσα σε τιμές ορισμάτων και σε σημεία όπου η τιμή θα είναι εκτεθειμένη σε άνθρωπο (π.χ. μέσα στο όνομα DNS του RDS instance).
Συμπεριλάβετε το όρισμα count
/ for_each
μέσα σε μπλοκ πόρων ή πηγής δεδομένων ως το πρώτο όρισμα στην κορυφή και διαχωρίστε το με νέα γραμμή μετά από αυτό.
Συμπεριλάβετε το όρισμα tags
, εάν υποστηρίζεται από τον πόρο, ως το τελευταίο πραγματικό όρισμα, ακολουθούμενο από τα depends_on
και lifecycle
, εάν είναι απαραίτητο. Όλα αυτά θα πρέπει να διαχωρίζονται με μία κενή γραμμή.
Όταν χρησιμοποιείτε συνθήκες/conditions σε ένα argument count
/ for_each
προτιμήστε boolean τιμές αντί να χρησιμοποιείτε length
ή άλλες εκφράσεις.
πόρου
count
/ for_each
ετικετών
/tags
count