Η αναπαράσταση της υποδομής ως κώδικα σε επαναλαμβανόμενη μορφή κειμένου είναι μια απλή βέλτιστη πρακτική για συστήματα που δεν απαιτούν ενασχόληση με ποντίκια. Αυτή η πρακτική έχει όνομα - , και μέχρι στιγμής υπάρχουν δύο δημοφιλή εργαλεία για την εφαρμογή του, ειδικά στο AWS: и .
Σύγκριση εμπειρίας με Terraform και CloudFormation
Πριν έρθει στο (Aka ) Δούλεψα και χρησιμοποίησε το Terraform για τρία χρόνια. Στο νέο μέρος, χρησιμοποίησα επίσης την Terraform με όλη μου τη δύναμη και, στη συνέχεια, η εταιρεία ώθησε τη μετάβαση σε οτιδήποτε α λα Amazon, συμπεριλαμβανομένου του CloudFormation. Έχω αναπτύξει επιμελώς βέλτιστες πρακτικές και για τα δύο, και έχω χρησιμοποιήσει και τα δύο εργαλεία σε πολύ περίπλοκες ροές εργασίας σε επίπεδο οργανισμού. Αργότερα, αφού ζύγισα προσεκτικά τις συνέπειες της μετάβασης από το Terraform στο CloudFormation, πείστηκα ότι το Terraform ήταν ίσως η καλύτερη επιλογή για τον οργανισμό.
Terraform Horrible
Λογισμικό beta
Η Terraform δεν έχει καν κυκλοφορήσει ακόμη την έκδοση 1.0, που είναι ένας καλός λόγος για να μην τη χρησιμοποιήσετε. Έχει αλλάξει πολύ από τότε που το δοκίμασα για πρώτη φορά, αλλά τότε terraform apply συχνά χάλασε μετά από πολλές ενημερώσεις ή απλά μετά από μερικά χρόνια χρήσης. Θα έλεγα ότι «όλα είναι διαφορετικά τώρα», αλλά... αυτό φαίνεται να λένε όλοι, όχι; Υπάρχουν αλλαγές που δεν είναι συμβατές με τις προηγούμενες εκδόσεις, αν και είναι κατάλληλες, και φαίνεται ότι η σύνταξη και οι αφαιρέσεις των καταστημάτων πόρων είναι τώρα αυτό που χρειαζόμαστε. Το όργανο φαίνεται να έχει βελτιωθεί πραγματικά, αλλά... :-0
Από την άλλη πλευρά, το AWS έχει κάνει καλή δουλειά διατηρώντας τη συμβατότητα προς τα πίσω. Αυτό συμβαίνει πιθανώς επειδή οι υπηρεσίες τους συχνά ελέγχονται διεξοδικά εντός του οργανισμού και μόνο τότε, μετονομάζονται, δημοσιεύονται. Επομένως, το "προσπάθησαν σκληρά" είναι μια υποτίμηση. Η διατήρηση της συμβατότητας προς τα πίσω με τα API για ένα σύστημα τόσο ποικίλο και πολύπλοκο όσο το AWS είναι απίστευτα δύσκολο. Όποιος χρειάστηκε να διατηρήσει δημόσια API που χρησιμοποιούνται τόσο ευρέως όσο και αν είναι, θα πρέπει να καταλάβει πόσο δύσκολο είναι να το κάνει για τόσα πολλά χρόνια. Αλλά η συμπεριφορά του CloudFormation, στη μνήμη μου, δεν έχει αλλάξει ποτέ με τα χρόνια.
Γνωρίστε το πόδι... είναι σφαίρα
Από όσο γνωρίζω, διαγράψτε τον πόρο ξένος Η στοίβα CloudFormation από τη στοίβα CF δεν είναι δυνατή. Το ίδιο ισχύει και με την Terraform. Σας επιτρέπει να εισάγετε υπάρχοντες πόρους στη στοίβα σας. Η λειτουργία μπορεί να ειπωθεί ότι είναι εκπληκτική, αλλά με τη μεγάλη δύναμη έρχεται μεγάλη ευθύνη. Απλώς πρέπει να προσθέσετε έναν πόρο στη στοίβα και ενώ εργάζεστε με τη στοίβα σας, δεν μπορείτε να διαγράψετε ή να αλλάξετε αυτόν τον πόρο. Μια μέρα απέτυχε. Μια μέρα στο Twitch, κάποιος εισήγαγε κατά λάθος την ομάδα ασφαλείας AWS κάποιου άλλου στη δική του στοίβα Terraform, χωρίς να αντέχει κανένα κακό. Έβαλα αρκετές εντολές και... η ομάδα ασφαλείας (μαζί με την εισερχόμενη κίνηση) εξαφανίστηκε.
Terraform Great
Ανάκτηση από ημιτελείς καταστάσεις
Μερικές φορές το CloudFormation αποτυγχάνει να μεταβεί πλήρως από τη μια κατάσταση στην άλλη. Παράλληλα, θα προσπαθήσει να επιστρέψει στο προηγούμενο. Είναι κρίμα που αυτό δεν είναι πάντα εφικτό. Μπορεί να είναι πολύ τρομακτικό να διορθώσετε ό,τι συνέβη αργότερα - ποτέ δεν ξέρετε αν το CloudFormation θα χαρεί που το χακάρουν - ακόμα και μόνο για να το διορθώσετε. Είτε θα μπορέσει να επιστρέψει στην προηγούμενη κατάσταση είτε όχι, δεν ξέρει πραγματικά πώς να καθορίσει και, από προεπιλογή, μένει για ώρες περιμένοντας ένα θαύμα.
Το Terraform, από την άλλη πλευρά, τείνει να ανακάμπτει από αποτυχημένες μεταβάσεις πολύ πιο χαριτωμένα και προσφέρει προηγμένα εργαλεία εντοπισμού σφαλμάτων.
Σαφέστερες αλλαγές στην κατάσταση του εγγράφου
«Εντάξει, load balancer, αλλάζεις. Αλλά πως?"
— ανήσυχος μηχανικός, έτοιμος να πατήσει το κουμπί «αποδοχή».
Μερικές φορές χρειάζεται να κάνω κάποιους χειρισμούς με το load balancer στη στοίβα CloudFormation, όπως να προσθέσω έναν αριθμό θύρας ή να αλλάξω μια ομάδα ασφαλείας. Το ClouFormation εμφανίζει κακές αλλαγές. Εγώ, στις καρφίτσες και τις βελόνες, τσεκάρω το αρχείο yaml δέκα φορές για να βεβαιωθώ ότι δεν έχω σβήσει τίποτα απαραίτητο και ότι δεν έχω προσθέσει τίποτα περιττό.
Η Terraform είναι πολύ πιο διαφανής από αυτή την άποψη. Μερικές φορές είναι ακόμη και πολύ διαφανής (διαβάστε: ενοχλητικός). Ευτυχώς, η πιο πρόσφατη έκδοση περιλαμβάνει βελτιωμένη εμφάνιση αλλαγών, ώστε να μπορείτε πλέον να βλέπετε ακριβώς τι αλλάζει.
Ευκαμψία
Γράψτε το λογισμικό προς τα πίσω.
Για να το θέσουμε ωμά, το πιο σημαντικό χαρακτηριστικό του μακρόβιου λογισμικού είναι η ικανότητα προσαρμογής στις αλλαγές. Γράψτε οποιοδήποτε λογισμικό προς τα πίσω. Τις περισσότερες φορές έκανα λάθη παίρνοντας μια «απλή» υπηρεσία και μετά άρχισα να γεμίζω τα πάντα σε μια στοίβα CloudFormation ή Terraform. Και φυσικά, μήνες αργότερα αποκαλύφθηκε ότι τα είχα καταλάβει όλα λάθος και η υπηρεσία στην πραγματικότητα δεν ήταν απλή! Και τώρα πρέπει με κάποιο τρόπο να σπάσω μια μεγάλη στοίβα σε μικρά εξαρτήματα. Όταν εργάζεστε με το CloudFormation, αυτό μπορεί να γίνει μόνο αν αναδημιουργήσετε πρώτα την υπάρχουσα στοίβα και δεν το κάνω με τις βάσεις δεδομένων μου. Το Terraform, από την άλλη, κατέστησε δυνατή την ανατομή της στοίβας και τη διάσπασή της σε πιο κατανοητά μικρότερα μέρη.
Ενότητες στο git
Η κοινή χρήση κώδικα Terraform σε πολλές στοίβες είναι πολύ πιο εύκολη από την κοινή χρήση κώδικα CloudFormation. Με το Terraform, μπορείτε να βάλετε τον κώδικά σας σε ένα αποθετήριο git και να αποκτήσετε πρόσβαση σε αυτόν χρησιμοποιώντας τον έλεγχο σημασιολογικής έκδοσης. Οποιοσδήποτε έχει πρόσβαση σε αυτό το αποθετήριο μπορεί να χρησιμοποιήσει ξανά τον κοινόχρηστο κώδικα. Το αντίστοιχο του CloudFormation είναι το S3, αλλά δεν έχει τα ίδια πλεονεκτήματα και δεν υπάρχει λόγος να εγκαταλείψουμε καθόλου το git υπέρ του S3.
Η οργάνωση μεγάλωσε και η ικανότητα να μοιράζονται κοινές στοίβες έφτασε σε κρίσιμο επίπεδο. Το Terraform το κάνει όλο αυτό εύκολο και φυσικό, ενώ το CloudFormation θα σας κάνει να πηδήξετε μέσα από κρίκους προτού μπορέσετε να πετύχετε κάτι τέτοιο.
Λειτουργίες ως κωδικός
«Ας το γράψουμε σενάριο και εντάξει».
— ένας μηχανικός 3 χρόνια πριν εφεύρει το ποδήλατο Terraform.
Όταν πρόκειται για ανάπτυξη λογισμικού, το Go ή ένα πρόγραμμα Java δεν είναι απλώς κώδικας.
Κωδικός ως Κώδικας
Υπάρχει και η υποδομή στην οποία λειτουργεί.
Υποδομή ως Κώδικας
Αλλά από πού είναι; Πώς να το παρακολουθήσετε; Πού μένει ο κωδικός σας; Χρειάζονται οι προγραμματιστές άδεια πρόσβασης;
Λειτουργίες ως Κώδικας
Το να είσαι προγραμματιστής λογισμικού δεν σημαίνει μόνο να γράφεις κώδικα.
Το AWS δεν είναι το μόνο: πιθανότατα χρησιμοποιείτε άλλους παρόχους. SignalFx, PagerDuty ή Github. Ίσως έχετε έναν εσωτερικό διακομιστή Jenkins για CI/CD ή έναν εσωτερικό πίνακα εργαλείων Grafana για παρακολούθηση. Το Infra as Code επιλέγεται για διαφορετικούς λόγους και ο καθένας είναι εξίσου σημαντικός για οτιδήποτε σχετίζεται με το λογισμικό.
Όταν εργαζόμουν στο Twitch, επιταχύναμε τις υπηρεσίες εντός των μικτών ενσωματωμένων συστημάτων και συστημάτων AWS της Amazon. Δημιουργήσαμε και υποστηρίξαμε πολλές μικροϋπηρεσίες, αυξάνοντας το λειτουργικό κόστος. Οι συζητήσεις έγιναν κάπως έτσι:
- Я: Γαμώτο, είναι πολλές χειρονομίες για overclock μίας microservice. Θα πρέπει να χρησιμοποιήσω αυτά τα σκουπίδια για να δημιουργήσω έναν λογαριασμό AWS (πήγαμε σε 2 λογαριασμούς microservice), μετά αυτό για τη ρύθμιση ειδοποιήσεων, αυτό για αποθήκη κωδικών και αυτό για λίστα email και μετά αυτό...
- Οδηγω: Ας το κάνουμε σενάριο και εντάξει.
- Я: Εντάξει, αλλά το ίδιο το σενάριο θα αλλάξει. Θα χρειαστούμε έναν τρόπο για να ελέγξουμε ότι όλα αυτά τα ενσωματωμένα gizmos του Amazon είναι ενημερωμένα.
- Οδηγω: Ακούγεται καλό. Και θα γράψουμε ένα σενάριο για αυτό.
- Я: Εξαιρετική! Και το σενάριο πιθανότατα θα χρειαστεί ακόμα να ορίσει παραμέτρους. Θα τα δεχτεί;
- Οδηγω: Ας πάρει όπου πάει!
- Я: Η διαδικασία ενδέχεται να αλλάξει και η συμβατότητα προς τα πίσω θα χαθεί. Θα απαιτηθεί κάποιο είδος σημασιολογικού ελέγχου έκδοσης.
- Οδηγω: Υπέροχη ιδέα!
- Я: Τα εργαλεία μπορούν να αλλάξουν χειροκίνητα, μέσα στη διεπαφή χρήστη. Θα χρειαστούμε έναν τρόπο να το ελέγξουμε και να το διορθώσουμε.
…3 χρόνια μετά:
- Οδηγω: Και πήραμε terraform.
Το ηθικό δίδαγμα της ιστορίας είναι: ακόμα κι αν εσύ με κεφάλι σε όλα Amazon, εξακολουθείτε να χρησιμοποιείτε κάτι που δεν προέρχεται από το AWS και αυτές οι υπηρεσίες έχουν μια κατάσταση που χρησιμοποιεί μια γλώσσα διαμόρφωσης για να διατηρεί αυτή την κατάσταση συγχρονισμένη.
CloudFormation lambda vs git modules terraform
Το lambda είναι η λύση του CloudFormation στο πρόβλημα προσαρμοσμένης λογικής. Με λάμδα μπορείς ή . Αυτή η προσέγγιση εισάγει πρόσθετες πολυπλοκότητες που δεν υπάρχουν στη σημασιολογική έκδοση των ενοτήτων git της Terraform. Για μένα, το πιο πιεστικό πρόβλημα ήταν η διαχείριση των δικαιωμάτων για όλα αυτά τα λάμδα χρηστών (και αυτοί είναι δεκάδες λογαριασμοί AWS). Ένα άλλο σημαντικό πρόβλημα ήταν το πρόβλημα «τι ήρθε πρώτο, το κοτόπουλο ή το αυγό;»: σχετιζόταν με τον κώδικα λάμδα. Αυτή η ίδια η λειτουργία είναι υποδομή και κώδικας και η ίδια χρειάζεται παρακολούθηση και ενημερώσεις. Το τελευταίο καρφί στο φέρετρο ήταν η δυσκολία στη σημασιολογική ενημέρωση των αλλαγών του κώδικα λάμδα. έπρεπε επίσης να βεβαιωθούμε ότι οι ενέργειες στοίβας χωρίς άμεση εντολή δεν άλλαζαν μεταξύ των εκτελέσεων.
Θυμάμαι κάποτε ήθελα να δημιουργήσω μια ανάπτυξη καναρινιού για το περιβάλλον Elastic Beanstalk με ένα κλασικό load balancer. Το πιο εύκολο πράγμα που πρέπει να κάνετε θα ήταν να κάνετε μια δεύτερη ανάπτυξη για το EB δίπλα στο περιβάλλον παραγωγής, πηγαίνοντάς το ένα βήμα παραπέρα: συνδυάζοντας την ομάδα ανάπτυξης καναρινιών αυτόματης κλιμάκωσης με την ανάπτυξη LB στο περιβάλλον παραγωγής. Και αφού χρησιμοποιεί Terraform , αυτό θα απαιτήσει 4 επιπλέον γραμμές κώδικα στο Terraform. Όταν ρώτησα αν υπήρχε μια συγκρίσιμη λύση στο CloudFormation, μου υπέδειξαν ένα ολόκληρο αποθετήριο git με μια διοχέτευση ανάπτυξης και τα πάντα, όλα για χάρη κάτι που θα μπορούσαν να κάνουν οι φτωχές 4 γραμμές κώδικα Terraform.
Ανιχνεύει καλύτερα το drift
Βεβαιωθείτε ότι η πραγματικότητα ταιριάζει με τις προσδοκίες.
είναι μια πολύ ισχυρή λειτουργία ως χαρακτηριστικό κώδικα, επειδή βοηθά να διασφαλιστεί ότι η πραγματικότητα ταιριάζει με τις προσδοκίες. Είναι διαθέσιμο τόσο με το CloudFormation όσο και με το Terraform. Αλλά καθώς η στοίβα παραγωγής μεγάλωνε, η αναζήτηση για drift στο CloudFormation παρήγαγε όλο και περισσότερες ψευδείς ανιχνεύσεις.
Με το Terraform έχετε πολύ πιο προηγμένους γάντζους κύκλου ζωής για ανίχνευση μετατόπισης. Για παράδειγμα, εισάγετε την εντολή απευθείας στον ορισμό εργασιών ECS, εάν θέλετε να αγνοήσετε τις αλλαγές σε έναν συγκεκριμένο ορισμό εργασίας χωρίς να αγνοήσετε αλλαγές σε ολόκληρη την ανάπτυξη του ECS.
Το CDK και το μέλλον του CloudFormation
Το CloudFormation είναι δύσκολο να διαχειριστεί σε μεγάλες κλίμακες μεταξύ υποδομών. Πολλές από αυτές τις δυσκολίες αναγνωρίζονται και το εργαλείο χρειάζεται πράγματα όπως , ένα πλαίσιο για τον ορισμό της υποδομής cloud σε κώδικα και την εκτέλεση του μέσω του AWS CloudFormation. Θα είναι ενδιαφέρον να δούμε τι επιφυλάσσει το μέλλον για το aws-cdk, αλλά θα δυσκολευτεί πολύ να ανταγωνιστεί τα άλλα δυνατά σημεία της Terraform. για να ενημερωθεί το CloudFormation, θα απαιτηθούν καθολικές αλλαγές.
Για να μην απογοητεύσει η Terraform
Αυτό είναι «η υποδομή ως κώδικας» και όχι «ως κείμενο».
Η πρώτη μου εντύπωση για το Terraform ήταν μάλλον κακή. Νομίζω ότι απλά δεν κατάλαβα την προσέγγιση. Σχεδόν όλοι οι μηχανικοί το αντιλαμβάνονται ακούσια ως μια μορφή κειμένου που πρέπει να μετατραπεί στην επιθυμητή υποδομή. ΜΗΝ ΤΟ ΚΑΝΕΤΕ ΕΤΣΙ.
Οι αλήθειες της καλής ανάπτυξης λογισμικού ισχύουν και για την Terraform.
Έχω δει πολλές πρακτικές που υιοθετούνται για τη δημιουργία καλού κώδικα να αγνοούνται στο Terraform. Έχεις σπουδάσει χρόνια για να γίνεις καλός προγραμματιστής. Μην εγκαταλείπετε αυτήν την εμπειρία μόνο και μόνο επειδή εργάζεστε με την Terraform. Οι αλήθειες της καλής ανάπτυξης λογισμικού ισχύουν για την Terraform.
Πώς μπορεί να μην τεκμηριωθεί ο κωδικός;
Έχω δει τεράστιες στοίβες Terraform χωρίς καμία απολύτως τεκμηρίωση. Πώς μπορείτε να γράψετε κώδικα σε σελίδες - χωρίς απολύτως καμία τεκμηρίωση; Προσθέστε τεκμηρίωση που σας εξηγεί κώδικας Terraform (έμφαση στη λέξη "κώδικας"), γιατί αυτή η ενότητα είναι τόσο σημαντική και τι κάνετε.
Πώς μπορούμε να αναπτύξουμε υπηρεσίες που κάποτε ήταν μια μεγάλη συνάρτηση main();
Έχω δει πολύ περίπλοκες στοίβες Terraform να παρουσιάζονται ως ενιαία μονάδα. Γιατί δεν αναπτύσσουμε λογισμικό με αυτόν τον τρόπο; Γιατί χωρίζουμε τις μεγάλες συναρτήσεις σε μικρότερες; Οι ίδιες απαντήσεις ισχύουν και για το Terraform. Εάν η μονάδα σας είναι πολύ μεγάλη, πρέπει να τη χωρίσετε σε μικρότερες ενότητες.
Η εταιρεία σας δεν χρησιμοποιεί βιβλιοθήκες;
Έχω δει πώς οι μηχανικοί, γυρίζοντας ένα νέο έργο χρησιμοποιώντας το Terraform, αντιγράφουν ανόητα τεράστια κομμάτια από άλλα έργα στα δικά τους και μετά τα εργάζονταν μέχρι να αρχίσει να λειτουργεί. Θα εργαζόσασταν έτσι με τον «combat» κωδικό στην εταιρεία σας; Δεν χρησιμοποιούμε μόνο βιβλιοθήκες. Ναί, αλλά πού είμαστε χωρίς κοινές βιβλιοθήκες κατ' αρχήν;!
Δεν χρησιμοποιείς PEP8 ή gofmt;
Οι περισσότερες γλώσσες έχουν ένα τυπικό, αποδεκτό σχήμα μορφοποίησης. Στην Python αυτό είναι το PEP8. Στο Go - gofmt. Το Terraform έχει το δικό του: terraform fmt. Απολαύστε το για την υγεία σας!
Θα χρησιμοποιήσετε το React χωρίς να γνωρίζετε JavaScript;
Τα Terraform modules μπορούν να απλοποιήσουν κάποιο μέρος της πολύπλοκης υποδομής που δημιουργείτε, αλλά αυτό δεν σημαίνει ότι δεν μπορείτε να το τσιμπήσετε καθόλου. Θέλετε να χρησιμοποιήσετε σωστά το Terraform χωρίς να κατανοήσετε τους πόρους; Είστε καταδικασμένοι: ο χρόνος θα περάσει και δεν θα κυριαρχήσετε ποτέ στο Terraform.
Κωδικοποιείτε με singletons ή dependency injection;
Η ένεση εξάρτησης είναι μια αναγνωρισμένη βέλτιστη πρακτική για την ανάπτυξη λογισμικού και προτιμάται από τα singleton. Πώς είναι αυτό χρήσιμο στο Terraform; Έχω δει μονάδες Terraform που εξαρτώνται από την απομακρυσμένη κατάσταση. Αντί να γράφετε λειτουργικές μονάδες που ανακτούν απομακρυσμένη κατάσταση, γράψτε μια λειτουργική μονάδα που λαμβάνει παραμέτρους. Και μετά περάστε αυτές τις παραμέτρους στη μονάδα.
Οι βιβλιοθήκες σας κάνουν δέκα πράγματα καλά ή ένα πράγμα σπουδαίο;
Οι βιβλιοθήκες που λειτουργούν καλύτερα είναι αυτές που εστιάζουν σε μια εργασία που κάνουν πολύ καλά. Αντί να γράφετε μεγάλες ενότητες Terraform που προσπαθούν να κάνουν τα πάντα ταυτόχρονα, δημιουργήστε μέρη τους που κάνουν ένα πράγμα καλά. Και μετά συνδυάστε τα όσο χρειάζεται.
Πώς κάνετε αλλαγές σε βιβλιοθήκες χωρίς συμβατότητα προς τα πίσω;
Μια κοινή μονάδα Terraform, όπως μια κανονική βιβλιοθήκη, πρέπει να επικοινωνεί με κάποιο τρόπο τις αλλαγές στους χρήστες χωρίς να είναι συμβατή προς τα πίσω. Είναι ενοχλητικό όταν αυτές οι αλλαγές συμβαίνουν σε βιβλιοθήκες και είναι εξίσου ενοχλητικό όταν γίνονται αλλαγές μη συμβατές με το παρελθόν σε μονάδες Terraform. Συνιστάται η χρήση ετικετών git και semver όταν χρησιμοποιείτε μονάδες Terraform.
Η υπηρεσία παραγωγής σας εκτελείται στον φορητό υπολογιστή σας ή σε ένα κέντρο δεδομένων;
Το Hashicorp έχει εργαλεία όπως για να τρέξετε το terraform σας. Αυτές οι κεντρικές υπηρεσίες καθιστούν εύκολη τη διαχείριση, τον έλεγχο και την έγκριση αλλαγών εδάφους.
Δεν γράφεις τεστ;
Οι μηχανικοί αναγνωρίζουν ότι ο κώδικας πρέπει να ελεγχθεί, αλλά οι ίδιοι συχνά ξεχνούν τη δοκιμή όταν εργάζονται με το Terraform. Για τις υποδομές, αυτό είναι γεμάτο με ύπουλες στιγμές. Η συμβουλή μου είναι να "δοκιμάζετε" ή να "δημιουργείτε παραδείγματα" στοίβες χρησιμοποιώντας μονάδες που μπορούν να αναπτυχθούν σωστά για δοκιμή κατά τη διάρκεια CI/CD.
Terraform και μικροϋπηρεσίες
Η ζωή και ο θάνατος των εταιρειών μικροϋπηρεσιών εξαρτάται από την ταχύτητα, την καινοτομία και τη διακοπή των νέων εργασιών microservice.
Η πιο κοινή αρνητική πτυχή που σχετίζεται με τις αρχιτεκτονικές μικροϋπηρεσιών, και η οποία δεν μπορεί να εξαλειφθεί, σχετίζεται με την εργασία και όχι με τον κώδικα. Εάν πιστεύετε ότι το Terraform είναι απλώς ένας τρόπος για να αυτοματοποιήσετε μόνο την πλευρά της υποδομής μιας αρχιτεκτονικής μικροϋπηρεσιών, τότε χάνετε τα πραγματικά οφέλη του συστήματος. Τώρα είναι ήδη .
Πηγή: www.habr.com