Το Terraform είναι ένα πολύ ισχυρό εργαλείο (αν όχι το ισχυρότερο που υπάρχει αυτή τη στιγμή) και ένα από τα πιο συχνά χρησιμοποιούμενα εργαλεία που επιτρέπουν τη διαχείριση της υποδομής ως κώδικα. Επιτρέπει στους προγραμματιστές να κάνουν πολλά πράγματα και δεν τους περιορίζει στο να κάνουν πράγματα με τρόπους που θα είναι δύσκολο να υποστηριχθούν ή να ενσωματωθούν.

Ορισμένες πληροφορίες που περιγράφονται σε αυτό το βιβλίο μπορεί να μην φαίνονται ως οι βέλτιστες πρακτικές. Το γνωρίζω αυτό και για να βοηθήσω τους αναγνώστες να διαχωρίσουν ποιες είναι οι καθιερωμένες βέλτιστες πρακτικές και ποιος είναι απλώς ένας άλλος δογματικός τρόπος να γίνονται τα πράγματα, χρησιμοποιώ μερικές φορές υποδείξεις για να δώσω κάποιο πλαίσιο και εικονίδια για να προσδιορίσω το επίπεδο ωριμότητας σε κάθε υποενότητα που σχετίζεται με τις βέλτιστες πρακτικές.

Το βιβλίο ξεκίνησε στην ηλιόλουστη Μαδρίτη το 2018 και είναι διαθέσιμο δωρεάν στην διεύθυνση https://www.terraform-best-practices.com/.

Λίγα χρόνια αργότερα έχει ενημερωθεί με περισσότερες πραγματικές βέλτιστες πρακτικές που είναι διαθέσιμες με το Terraform 1.0. Τελικά, αυτό το βιβλίο θα πρέπει να περιέχει τις περισσότερες από τις αδιαμφισβήτητες βέλτιστες πρακτικές και συστάσεις για τους χρήστες του Terraform.

Χορηγοί

Please contact me if you want to become a sponsor.

Μεταφράσεις

Επικοινωνήστε μαζί μου αν θέλετε να βοηθήσετε στη μετάφραση αυτού του βιβλίου σε άλλες γλώσσες.

Συνεισφορές

Θέλω πάντα να λαμβάνω σχόλια και να ενημερώνω αυτό το βιβλίο καθώς η κοινότητα ωριμάζει και νέες ιδέες εφαρμόζονται και επαληθεύονται με την πάροδο του χρόνου.

Αν ενδιαφέρεστε για συγκεκριμένα θέματα, παρακαλώ ανοίξτε ένα θέμα ή κάντε 'thumb up' σε ένα θέμα που θέλετε να καλυφθεί. Αν αισθάνεστε ότι έχετε περιεχόμενο και θέλετε να συνεισφέρετε, γράψτε ένα προσχέδιο και υποβάλετε ένα pull request (μην ανησυχείτε για τη συγγραφή καλού κειμένου σε αυτό το σημείο!).\

Συγγραφείς

Αυτό το βιβλίο συντηρείται από τον Anton Babenko με τη βοήθεια διαφόρων συνεργατών και μεταφραστών.\

Άδεια

Το έργο αυτό διατίθεται με άδεια Apache 2 License. Δείτε το LICENSE για πλήρεις λεπτομέρειες.

Οι συγγραφείς και οι συντελεστές αυτού του περιεχομένου δεν μπορούν να εγγυηθούν την εγκυρότητα των πληροφοριών που βρίσκονται εδώ. Βεβαιωθείτε ότι κατανοείτε ότι οι πληροφορίες που παρέχονται εδώ παρέχονται δωρεάν και ότι δεν δημιουργείται κανενός είδους συμφωνία ή σύμβαση μεταξύ εσάς και οποιουδήποτε προσώπου που σχετίζεται με αυτό το περιεχόμενο ή το έργο. Οι συγγραφείς και οι συντελεστές δεν αναλαμβάνουν και αποποιούνται με το παρόν κάθε ευθύνη έναντι οποιουδήποτε μέρους για οποιαδήποτε απώλεια, ζημία ή διαταραχή που προκαλείται από λάθη ή παραλείψεις στις πληροφορίες που περιέχονται στο παρόν περιεχόμενο, σχετίζονται με αυτό ή συνδέονται με αυτό, είτε τα εν λόγω λάθη ή παραλείψεις οφείλονται σε αμέλεια, ατύχημα ή οποιαδήποτε άλλη αιτία.

Copyright © 2018-2023 Anton Babenko.

Τα παρακάτω είναι τα άρθρα αυτής της ενότητας:

- Λίστα ανθρώπων που εργάζονται πολύ ενεργά με το Terraform και μπορούν να σας πουν πολλά (αν τους ρωτήσετε).

- Επιμελημένος κατάλογος πηγών σχετικά με το Terraform της HashiCorp.

- Το κανάλι "Η εβδομαδιαία δόση σας από το Terraform" στο YouTube από τον Anton Babenko. Ζωντανές ροές με κριτικές, συνεντεύξεις, ερωταπαντήσεις, ζωντανό coding και λίγο hacking με την Terraform.

- Εβδομαδιαίο ενημερωτικό δελτίο για το Terraform. Διάφορα νέα στον κόσμο του Terraform (έργα, ανακοινώσεις, συζητήσεις) από τον Anton Babenko.

Πηγή: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraform

Αυτό το παράδειγμα περιέχει κώδικα ως παράδειγμα δόμησης των ρυθμίσεων Terraform για μια μεσαίου μεγέθους υποδομή που χρησιμοποιεί:

• 2 λογαριασμούς AWS

• 2 ξεχωριστά περιβάλλοντα (prod και stage που δεν διαμοιράζονται τίποτα). Κάθε περιβάλλον ζει σε ξεχωριστό λογαριασμό AWS

• Κάθε περιβάλλον χρησιμοποιεί διαφορετική έκδοση της έτοιμης μονάδας υποδομής (alb) που προέρχεται από το Terraform registry

• Κάθε περιβάλλον χρησιμοποιεί την ίδια έκδοση μιας εσωτερικής μονάδας modules/network, καθώς προέρχεται από έναν τοπικό κατάλογο.

Πηγή: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

Αυτό το παράδειγμα περιέχει κώδικα ως παράδειγμα δόμησης των ρυθμίσεων του Terraform για μια υποδομή μικρού μεγέθους, όπου δεν χρησιμοποιούνται εξωτερικές εξαρτήσεις.

Υπάρχει επίσης ένα εργαστήριο για άτομα που θέλουν να εφαρμόσουν στην πράξη κάποια από τα πράγματα που περιγράφονται σε αυτόν τον οδηγό.

Το περιεχόμενο βρίσκεται εδώ -

Χρησιμοποιήστε locals για να καθορίσετε ρητές εξαρτήσεις μεταξύ πόρων

Χρήσιμος τρόπος για να δώσετε μια υπόδειξη στην Terraform ότι κάποιοι πόροι πρέπει να διαγραφούν πριν, ακόμη και όταν δεν υπάρχει άμεση εξάρτηση στις ρυθμίσεις της Terraform.

https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf

Terraform 0.12 - Απαιτούμενα εναντίον Προαιρετικών ορισμάτων

1. Το Απαιτούμενο όρισμα index_document πρέπει να οριστεί, αν το var.website δεν είναι ένα κενό map.

2. Το προαιρετικό όρισμα error_document μπορεί να παραληφθεί.

variable "website" {
  type    = map(string)
  default = {}
}

resource "aws_s3_bucket" "this" {
  # omitted...

  dynamic "website" {
    for_each = length(keys(var.website)) == 0 ? [] : [var.website]

    content {
      index_document = website.value.index_document
      error_document = lookup(website.value, "error_document", null)
    }
  }
}

website = {
  index_document = "index.html"
}

Εγχειρίδιο

Αυτόματα παραγόμενο εγχειρίδιο

Το pre-commit είναι ένα framework για τη διαχείριση και τη συντήρηση πολυγλωσσικών pre-commit hooks. Είναι γραμμένο σε Python και είναι ένα ισχυρό εργαλείο για να κάνετε κάτι αυτόματα στο μηχάνημα ενός προγραμματιστή πριν ο κώδικας γίνει commit σε ένα git repository. Κανονικά, χρησιμοποιείται για την εκτέλεση linters και τη μορφοποίηση κώδικα (βλ. υποστηριζόμενα hooks).

Με τις ρυθμίσεις Terraform το pre-commit μπορεί να χρησιμοποιηθεί για τη μορφοποίηση και την επικύρωση κώδικα, καθώς και για την ενημέρωση τoυ εγχειριδίου.

Ελέγξτε το pre-commit-terraform repository για να εξοικειωθείτε με αυτό, καθώς και υπάρχοντα repositories (π.χ. terraform-aws-vpc) όπου αυτό χρησιμοποιείται ήδη.

terraform-docs

Το terraform-docs είναι ένα εργαλείο που κάνει τη δημιουργία εγχειριδίου από τις μονάδες Terraform σε διάφορες output μορφές . Μπορείτε να το εκτελέσετε χειροκίνητα (χωρίς pre-commit hooks) ή να χρησιμοποιήσετε pre-commit-terraform hooks για να ενημερώνεται αυτόματα το εγχειρίδιο.

@todo: Εκδόσεις εγγράφων μονάδων, έκδοση, ενέργειες GH

Πόροι

1. αρχική σελίδα του pre-commit framework

2. Συλλογή git hooks για τhn Terraform που μπορούν να χρησιμοποιηθούν με το pre-commit framework

3. Blog του Dean Wilson: pre-commit hooks και terraform - ένα δίχτυ ασφαλείας για τα repositories σας

Η επίσημη τεκμηρίωση του Terraform περιγράφει όλες τις πτυχές της διαμόρφωσης με λεπτομέρειες. Διαβάστε την προσεκτικά για να κατανοήσετε το υπόλοιπο αυτής της ενότητας.

Αυτή η ενότητα περιγράφει βασικές έννοιες που χρησιμοποιούνται μέσα στο βιβλίο.

Πόρος

Ως πόρος λογίζεται ένα aws_vpc, ένα aws_db_instance κλπ. Ένας πόρος ανήκει σε έναν πάροχο, δέχεται ορίσματα, εξάγει χαρακτηριστικά και έχει κύκλο ζωής. Ένας πόρος μπορεί να δημιουργηθεί, να ανακτηθεί, να ενημερωθεί και να διαγραφεί.

Μονάδα (module) πόρων

Η μονάδα πόρων είναι μια συλλογή συνδεδεμένων πόρων οι οποίοι εκτελούν από κοινού την κοινή ενέργεια (π.χ. η μονάδα AWS VPC Terraform δημιουργεί VPC, subnets, NAT gateway κλπ.). Εξαρτάται από τη διαμόρφωση του παρόχου, η οποία μπορεί να οριστεί σε αυτήν ή σε δομές υψηλότερου επιπέδου (π.χ. στη μονάδα υποδομής).

Μονάδα υποδομής

Μια μονάδα υποδομής είναι μια συλλογή από μονάδες πόρων, οι οποίες μπορεί να μην συνδέονται λογικά, αλλά στην τρέχουσα κατάσταση/έργο/ρύθμιση εξυπηρετούν τον ίδιο σκοπό. Καθορίζει τη διαμόρφωση για τους παρόχους, η οποία μεταβιβάζεται στις μεταγενέστερες μονάδες πόρων και στους πόρους. Συνήθως περιορίζεται να δουλεύει σε μία οντότητα ανά λογικό διαχωριστή (π.χ. AWS Region, Google Project).

Για παράδειγμα, η μονάδα terraform-aws-atlantis χρησιμοποιεί μονάδες πόρων όπως οι terraform-aws-vpc και terraform-aws-security-group για τη διαχείριση της υποδομής που απαιτείται για τη εκτέλεση Atlantis σε AWS Fargate.

Ένα άλλο παράδειγμα είναι η μονάδα terraform-aws-cloudquery όπου πολλαπλές μονάδες terraform-aws-modules χρησιμοποιούνται μαζί για τη διαχείριση της υποδομής καθώς και η χρήση πόρων Docker για τη δημιουργία, την προώθηση και την ανάπτυξη Docker images. Όλα σε ένα σύνολο.

Σύνθεση

Η σύνθεση είναι μια συλλογή μονάδων υποδομής, η οποία μπορεί να εκτείνεται σε διάφορες λογικά διαχωρισμένες περιοχές (π.χ. AWS regions, αρκετοί λογαριασμοί AWS). Η σύνθεση χρησιμοποιείται για να περιγράψει την πλήρη υποδομή που απαιτείται για ολόκληρο τον οργανισμό ή το έργο.

Μια σύνθεση αποτελείται από μονάδες υποδομής, οι οποίες αποτελούνται από μονάδες πόρων, οι οποίες υλοποιούν μεμονωμένους πόρους.

Πηγή δεδομένων

Η πηγή δεδομένων εκτελεί μια λειτουργία μόνο για ανάγνωση και εξαρτάται από τη διαμόρφωση του παρόχου, χρησιμοποιείται σε μια μονάδα πόρων και μια μονάδα υποδομής.

Η πηγή δεδομένων terraform_remote_state λειτουργεί ως «συγκολλητική ουσία» για μονάδες και συνθέσεις υψηλότερου επιπέδου.

Η εξωτερική πηγή δεδομένων επιτρέπει σε ένα εξωτερικό πρόγραμμα να ενεργεί ως πηγή δεδομένων, εκθέτοντας αυθαίρετα δεδομένα για χρήση αλλού στην διαμόρφωση του Terraform. Ακολουθεί ένα παράδειγμα από τη μονάδα terraform-aws-lambda όπου το όνομα αρχείου υπολογίζεται με την κλήση ενός εξωτερικού Python script.

Η πηγή δεδομένων http πραγματοποιεί μια κλήση HTTP GET στη δεδομένη διεύθυνση URL και εξάγει πληροφορίες σχετικά με την απόκριση, η οποία είναι συχνά χρήσιμη για τη λήψη πληροφοριών από endpoints όπου δεν υπάρχει εγγενής πάροχος Terraform.

Απομακρυσμένη κατάσταση

Οι μονάδες υποδομής και οι συνθέσεις θα πρέπει να διατηρούν την Terraform κατάστασή τους σε μια απομακρυσμένη τοποθεσία όπου μπορεί να ανακτηθεί από άλλους με ελεγχόμενο τρόπο (π.χ. προσδιορισμός ACL, versioning, logging).

Πάροχος, παροχέας, κλπ.

Οι πάροχοι, οι παροχείς και μερικοί άλλοι όροι περιγράφονται πολύ καλά στo επίσημo εγχειρίδιο και δεν έχει νόημα να τα επαναλάβουμε εδώ. Κατά τη γνώμη μου, έχουν ελάχιστη σχέση με τη συγγραφή καλών μονάδων Terraform.

Γιατί είναι τόσο δύσκολο;

Ενώ οι μεμονωμένοι πόροι μοιάζουν με άτομα σε επίπεδο υποδομής, οι μονάδες πόρων μοιάζουν με μόρια (που αποτελούνται από άτομα). Μια μονάδα είναι η μικρότερη εκδοχή οντότητας που μπορεί να διαμοιραστεί. Έχει έναν ακριβή κατάλογο ορισμάτων, υλοποιεί τη βασική λογική μιας τέτοιας μονάδας για να κάνει την απαιτούμενη λειτουργία. π.χ., η μονάδα terraform-aws-security-group δημιουργεί τους πόρους aws_security_group και aws_security_group_rule με βάση τo input. Αυτή η μονάδα πόρων από μόνη της μπορεί να χρησιμοποιηθεί μαζί με άλλες μονάδες για τη δημιουργία της μονάδας υποδομής.

Η πρόσβαση σε δεδομένα μεταξύ των μορίων (μονάδες πόρων και μονάδες υποδομής) πραγματοποιείται χρησιμοποιώντας τα output και τις πηγές δεδομένων των μονάδων.

Η πρόσβαση μεταξύ συνθέσεων πραγματοποιείται συχνά με τη χρήση απομακρυσμένων πηγών δεδομένων κατάστασης. Υπάρχουν πολλοί τρόποι διαμοιρασμού δεδομένων μεταξύ συνθέσεων.

Όταν τοποθετούμε τις έννοιες που περιγράφονται παραπάνω σε ψευδοσχέσεις μπορεί να μοιάζει ως εξής:

composition-1 {
  infrastructure-module-1 {
    data-source-1 => d1

    resource-module-1 {
      data-source-2 => d2
      resource-1 (d1, d2)
      resource-2 (d2)
    }

    resource-module-2 {
      data-source-3 => d3
      resource-3 (d1, d3)
      resource-4 (d3)
    }
  }
}

Γενικές συμβάσεις

1. Χρησιμοποιήστε _ (υπογράμμιση) αντί για - (παύλα) παντού (σε ονόματα πόρων, ονόματα πηγών δεδομένων, ονόματα μεταβλητών, εξόδους κλπ.).

2. Προτιμήστε να χρησιμοποιείτε πεζά γράμματα και αριθμούς (παρόλο που υποστηρίζεται το UTF-8).

Ορίσματα πηγής πόρων και δεδομένων

1. Μην επαναλαμβάνετε τον τύπο του πόρου στο όνομα του πόρου (ούτε μερικώς ούτε πλήρως):

`resource "aws_route_table" "public" {}`

`resource "aws_route_table" "public_route_table" {}`

`resource "aws_route_table" "public_aws_route_table" {}`

1. Το όνομα του πόρου θα πρέπει να ονομάζεται this εάν δεν υπάρχει πιο περιγραφικό και γενικό όνομα ή εάν η μονάδα πόρων δημιουργεί έναν μόνο πόρο αυτού του τύπου (π.χ. στη μονάδα AWS VPC υπάρχει ένας μόνο πόρος τύπου aws_nat_gateway και πολλαπλοί πόροι τύπου aws_route_table, οπότε το aws_nat_gateway θα πρέπει να ονομάζεται this και το aws_route_table θα πρέπει να έχει πιο περιγραφικά ονόματα - όπως private, public, database).

2. Χρησιμοποιείτε πάντα ουσιαστικά στον ενικό αριθμό για τα ονόματα.

3. Χρησιμοποιήστε - μέσα σε τιμές ορισμάτων και σε σημεία όπου η τιμή θα είναι εκτεθειμένη σε άνθρωπο (π.χ. μέσα στο όνομα DNS του RDS instance).

4. Συμπεριλάβετε το όρισμα count / for_each μέσα σε μπλοκ πόρων ή πηγής δεδομένων ως το πρώτο όρισμα στην κορυφή και διαχωρίστε το με νέα γραμμή μετά από αυτό.

5. Συμπεριλάβετε το όρισμα tags, εάν υποστηρίζεται από τον πόρο, ως το τελευταίο πραγματικό όρισμα, ακολουθούμενο από τα depends_on και lifecycle, εάν είναι απαραίτητο. Όλα αυτά θα πρέπει να διαχωρίζονται με μία κενή γραμμή.

6. Όταν χρησιμοποιείτε συνθήκες/conditions σε ένα argument count / for_each προτιμήστε boolean τιμές αντί να χρησιμοποιείτε length ή άλλες εκφράσεις.

Παραδείγματα κώδικα πόρου

Χρήση του count / for_each

resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "private" {
  for_each = toset(["one", "two"])

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

Τοποθέτηση ετικετών/tags

resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}

Συνθήκες σε count

resource "aws_nat_gateway" "that" {    # Best
  count = var.create_public_subnets ? 1 : 0
}

resource "aws_nat_gateway" "this" {    # Good
  count = length(var.public_subnets) > 0 ? 1 : 0
}

Μεταβλητές

1. Μην ανακαλύπτετε ξανά τον τροχό στις μονάδες πόρων: χρησιμοποιήστε το όνομα/name, την περιγραφή/description και την προεπιλεγμένη/default τιμή για τις μεταβλητές όπως ορίζονται στην ενότητα «Αναφορά ορίσματος» για τον πόρο με τον οποίο εργάζεστε.

2. Η υποστήριξη για επικύρωση σε μεταβλητές είναι μάλλον περιορισμένη (π.χ. δεν μπορεί να έχει πρόσβαση σε άλλες μεταβλητές ή να κάνει αναζητήσεις). Προγραμματίστε αναλόγως, διότι σε πολλές περιπτώσεις αυτή η λειτουργία είναι άχρηστη.

3. Χρησιμοποιήστε τον πληθυντικό αριθμό στο όνομα μιας μεταβλητής όταν ο τύπος είναι list(...) ή map(...).

4. Ταξινομήστε τα κλειδιά σε ένα μπλοκ μεταβλητών ως εξής: περιγραφή/description , τύπος/type, προεπιλογή/default, επικύρωση/validation.

5. Περιλαμβάνετε πάντα περιγραφή/description σε όλες τις μεταβλητές ακόμα και αν νομίζετε ότι είναι προφανές (θα σας χρειαστεί στο μέλλον).

6. Προτιμήστε τη χρήση απλών τύπων (number, string, list(...), map(...), any) έναντι ειδικών τύπων όπως object() εκτός αν χρειάζεται να έχετε αυστηρούς περιορισμούς σε κάθε κλειδί.

7. Χρησιμοποιήστε συγκεκριμένους τύπους όπως map(map(string)) αν όλα τα στοιχεία του map έχουν τον ίδιο τύπο (π.χ. string) ή μπορούν να μετατραπούν σε αυτόν (π.χ. ο τύπος number μπορεί να μετατραπεί σε string).

8. Χρησιμοποιήστε τύπο any για να απενεργοποιήσετε την επικύρωση τύπου ξεκινώντας από ένα συγκεκριμένο βάθος ή όταν πρέπει να υποστηρίζονται πολλαπλοί τύποι.

9. Η τιμή {} είναι μερικές φορές ένα map αλλά μερικές φορές ένα αντικείμενο. Χρησιμοποιήστε το tomap(....) για να φτιάξετε ένα map επειδή δεν υπάρχει τρόπος να φτιάξετε ένα αντικείμενο.

Outputs

Κάντε τα outputs συνεπή και κατανοητά εκτός του πεδίου εφαρμογής της (όταν ένας χρήστης χρησιμοποιεί μια μονάδα θα πρέπει να είναι προφανές τι τύπο και τι ιδιότητα έχει η τιμή που επιστρέφει).

1. Το όνομα του output θα πρέπει να περιγράφει την ιδιότητα που περιέχει και να είναι λιγότερο «ελεύθερο» από ό,τι θα θέλατε κανονικά.

2. Μια καλή δομή για το όνομα του output μοιάζει με {name}_{type}_{attribute} , όπου:

   1. {name} είναι ένα όνομα πόρου ή πηγής δεδομένων χωρίς πρόθεμα παρόχου. Το {name} για το aws_subnet είναι το subnet, για το aws_vpc είναι το vpc.

   2. {type} είναι ο τύπος μιας πηγής πόρων.

   3. {attribute} είναι ένα χαρακτηριστικό που επιστρέφεται από το output

   4. Δείτε παραδείγματα.

3. Εάν το output επιστρέφει μια τιμή με συναρτήσεις παρεμβολής/interpolation functions και πολλαπλούς πόρους, τα {name} και {type} εκεί θα πρέπει να είναι όσο το δυνατόν πιο γενικά (το this ως πρόθεμα θα πρέπει να παραλείπεται). Δείτε παράδειγμα.

4. Αν η επιστρεφόμενη τιμή είναι μια λίστα θα πρέπει να έχει όνομα στον πληθυντικό. Δείτε παράδειγμα.

5. Πάντα να περιλαμβάνετε περιγραφή/description για όλα τα outputs ακόμα και αν νομίζετε ότι είναι προφανής.

6. Αποφύγετε να ορίσετε ευαίσθητο/sensitive όρισμα εκτός αν ελέγχετε πλήρως τη χρήση αυτού του output σε όλα τα σημεία σε όλες τις μονάδες.

7. Προτιμήστε την try() (διαθέσιμη από το Terraform 0.13) έναντι της element(concat(...)) (παλαιότερη προσέγγιση για την έκδοση πριν την 0.13)

Παραδείγματα κώδικαoutput

Επιστρέψτε το πολύ ένα ID τoυ security group

output "security_group_id" {
  description = "The ID of the security group"
  value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
}

Όταν υπάρχουν πολλαπλοί πόροι του ίδιου τύπου, το this θα πρέπει να παραλείπεται στο όνομα τoυ output:

output "this_security_group_id" {
  description = "The ID of the security group"
  value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
}

Χρησιμοποιήστε όνομα πληθυντικού αν η τιμή που επιστρέφει είναι λίστα

output "rds_cluster_instance_endpoints" {
  description = "A list of all cluster instance endpoints"
  value       = aws_rds_cluster_instance.this.*.endpoint
}

Οι ερωτήσεις που σχετίζονται με τη δομή του κώδικα της Terraform είναι μακράν οι πιο συχνές στην κοινότητα. Όλοι σκέφτηκαν επίσης κάποια στιγμή για την καλύτερη δομή κώδικα για το έργο.

Πώς προτείνεται να δομώ τις Terraform ρυθμίσεις μου;

Αυτή είναι μία από τις ερωτήσεις όπου υπάρχουν πολλές πιθανές λύσεις και είναι πολύ δύσκολο να δώσουμε γενικές οδηγίες, οπότε ας ξεκινήσουμε με την κατανόηση του τι αντιμετωπίζουμε.

• Ποια είναι η πολυπλοκότητα του έργου σας;

  • Αριθμός σχετικών πόρων

  • Αριθμός παρόχων Terraform (βλ. σημείωση παρακάτω σχετικά με τους "λογικούς παρόχους")

• Πόσο συχνά αλλάζει η υποδομή σας;

  • Από μία φορά το μήνα/εβδομάδα/ημέρα

  • Μέχρι συνεχώς (κάθε φορά που υπάρχει ένα νέο commit)

• Εναύσματα αλλαγής κώδικα; Αφήνετε τον CI server να ενημερώνει το repository όταν κατασκευάζεται ένα νέο artifact;

  • Μόνο οι προγραμματιστές μπορούν να κάνουν push στο repository υποδομής

  • Όλοι μπορούν να προτείνουν μια αλλαγή σε ο,τιδήποτε ανοίγοντας ένα PR (συμπεριλαμβανομένων των αυτοματοποιημένων εργασιών που εκτελούνται στον CI server)

• Ποια πλατφόρμα ανάπτυξης ή υπηρεσία ανάπτυξης χρησιμοποιείτε;

  • Το AWS CodeDeploy, το Kubernetes ή το OpenShift απαιτούν μια ελαφρώς διαφορετική προσέγγιση

• Πώς ομαδοποιούνται τα περιβάλλοντα;

  • Ανά περιβάλλον, περιοχή, έργο

Ξεκινώντας με τη δόμηση των ρυθμίσεων της Terraform

Η τοποθέτηση όλου του κώδικα στο main.tf είναι μια καλή ιδέα όταν ξεκινάτε ή όταν γράφετε ένα παράδειγμα κώδικα. Σε όλες τις άλλες περιπτώσεις θα είναι καλύτερα να έχετε διάφορα αρχεία χωρισμένα λογικά όπως αυτό:

• main.tf - κλήση μονάδων, τοπικών μονάδων και πηγών δεδομένων για τη δημιουργία όλων των πόρων

• variables.tf - περιέχει δηλώσεις των μεταβλητών που χρησιμοποιούνται στο main.tf

• outputs.tf - περιέχει τα outpus από τους πόρους που δημιουργήθηκαν στο main.tf

• versions.tf - περιέχει απαιτήσεις versioning για το Terraform και τους παρόχους

Το terraform.tfvars δεν πρέπει να χρησιμοποιείται πουθενά αλλού εκτός από τη σύνθεση

Πώς να σκεφτείτε τη δομή ρυθμίσεων του Terraform;

Κοινές συστάσεις για τη δόμηση του κώδικα

• Είναι ευκολότερο και γρηγορότερο να εργάζεστε με μικρότερο αριθμό πόρων

  • Το terraform plan και το terraform apply πραγματοποιούν και τα δύο κλήσεις cloud API για να επαληθεύσουν την κατάσταση των πόρων

  • Εάν έχετε ολόκληρη την υποδομή σας σε μία μόνο σύνθεση αυτό μπορεί να πάρει αρκετό χρόνο

• Η ακτίνα επίδρασης (σε περίπτωση παραβίασης της ασφάλειας) είναι μικρότερη με λιγότερους πόρους

  • Η απομόνωση μη συνδεδεμένων πόρων μεταξύ τους με την τοποθέτησή τους σε ξεχωριστές συνθέσεις μειώνει τον κίνδυνο αν κάτι πάει στραβά

• Ξεκινήστε το έργο σας χρησιμοποιώντας απομακρυσμένη κατάσταση επειδή:

  • Ο φορητός σας υπολογιστής δεν είναι κατάλληλο μέρος για την «πηγή αλήθειας» της υποδομής σας

  • Η διαχείριση ενός αρχείου tfstate στο git είναι εφιάλτης

  • Αργότερα, όταν τα επίπεδα υποδομής αρχίσουν να αυξάνονται προς πολλές κατευθύνσεις (αριθμός εξαρτήσεων ή πόρων) θα είναι ευκολότερο να κρατήσετε τα πράγματα υπό έλεγχο

• Εφαρμόστε μια συνεπή δομή και σύμβαση ονομασίας:

  • Όπως και ο διαδικαστικός κώδικας, ο κώδικας Terraform θα πρέπει να γράφεται πρώτα για να τον διαβάζουν οι άνθρωποι, η συνέπεια θα βοηθήσει όταν θα γίνουν αλλαγές σε έξι μήνες από τώρα.

  • Είναι δυνατή η μετακίνηση πόρων στο αρχείο κατάστασης Terraform, αλλά μπορεί να είναι πιο δύσκολο να γίνει αν έχετε ασυνεπή δομή και ονοματοδοσία

• Διατηρήστε τις ενότητες πόρων όσο το δυνατόν πιο απλές

• Μην γράφετε hardcoded τιμές που μπορούν να περάσουν ως μεταβλητές ή να ανακαλυφθούν με τη χρήση πηγών δεδομένων

• Χρησιμοποιήστε τις πηγές δεδομένων και το terraform_remote_state ειδικά ως "συγκολλητικό υλικό" μεταξύ των μονάδων υποδομής εντός της σύνθεσης

Σε αυτό το βιβλίο τα παραδείγματα έργων ομαδοποιούνται ανάλογα με την πολυπλοκότητα - από μικρές έως πολύ μεγάλες υποδομές. Αυτός ο διαχωρισμός δεν είναι αυστηρός, οπότε ελέγξτε και άλλες δομές.

Ενορχήστρωση μονάδων υποδομής και συνθέσεων

Η ύπαρξη μιας μικρής υποδομής σημαίνει ότι υπάρχει μικρός αριθμός εξαρτήσεων και λίγοι πόροι. Καθώς το έργο μεγαλώνει, γίνεται εμφανής η ανάγκη για την αλυσιδωτή εκτέλεση των ρυθμίσεων του Terraform, τη σύνδεση διαφορετικών μονάδων υποδομής και τη μεταβίβαση τιμών εντός μιας σύνθεσης.

Υπάρχουν τουλάχιστον 5 διακριτές ομάδες λύσεων ενορχήστρωσης που χρησιμοποιούν οι προγραμματιστές:

1. Μόνο Terraform. Πολύ απλό, οι προγραμματιστές πρέπει να γνωρίζουν μόνο το Terraform για να κάνουν τη δουλειά τους.

2. Terragrunt. Καθαρό εργαλείο ενορχήστρωσης το οποίο μπορεί να χρησιμοποιηθεί για την ενορχήστρωση ολόκληρης της υποδομής καθώς και για το χειρισμό των εξαρτήσεων. Το Terragrunt λειτουργεί με ενότητες υποδομής και συνθέσεις εγγενώς, οπότε μειώνει την επανάληψη του κώδικα.

3. Εσωτερικά scripts. Συχνά αυτό συμβαίνει ως σημείο εκκίνησης προς την ενορχήστρωση και πριν την ανακάλυψη του Terragrunt.

4. Ansible ή παρόμοιο εργαλείο αυτοματοποίησης γενικού σκοπού. Συνήθως χρησιμοποιείται όταν το Terraform υιοθετείται μετά το Ansible ή όταν χρησιμοποιείται ενεργά το Ansible UI.

5. Crossplane και άλλες λύσεις εμπνευσμένες από το Kubernetes. Μερικές φορές έχει νόημα να αξιοποιήσετε το οικοσύστημα Kubernetes και να χρησιμοποιήσετε μια λειτουργία βρόχου «συμφιλίωσης» για να επιτύχετε την επιθυμητή κατάσταση των ρυθμίσεων του Terraform σας. Δείτε το βίντεο Crossplane vs Terraform για περισσότερες πληροφορίες.

Έχοντας αυτό κατά νου, αυτό το βιβλίο εξετάζει τις δύο πρώτες από αυτές τις δομές έργων, το Terraform only και το Terragrunt.

Δείτε παραδείγματα δομών κώδικα για Terraform ή Terragrunt στο επόμενο κεφάλαιο.

Δομές κώδικα Terraform

Δομές κώδικα Terragrunt

Πηγή: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

Αυτό το παράδειγμα περιέχει κώδικα ως παράδειγμα δόμησης των ρυθμίσεων της Terraform για μια υποδομή μεγάλου μεγέθους που χρησιμοποιεί:

• 2 λογαριασμούς AWS

• 2 regions

• 2 ξεχωριστά περιβάλλοντα (prod και stage που δεν διαμοιράζονται τίποτα). Κάθε περιβάλλον ζει σε ξεχωριστό λογαριασμό AWS και καλύπτει πόρους μεταξύ 2 regions

• Κάθε περιβάλλον χρησιμοποιεί διαφορετική έκδοση της έτοιμης μονάδας υποδομής (alb) που προέρχεται από το Terraform Registry.

• Κάθε περιβάλλον χρησιμοποιεί την ίδια έκδοση μιας εσωτερικής μονάδας modules/network, καθώς προέρχεται από έναν τοπικό κατάλογο.

Ποια είναι τα εργαλεία που πρέπει να γνωρίζω και να εξετάσω τη χρήση τους;

• Terragrunt - Εργαλείο ενορχήστρωσης

• tflint - Linter κώδικα

• tfenv - Διαχειριστής έκδοσης

• Atlantis - Αυτοματοποίηση αιτημάτων pull

• pre-commit-terraform - Συλλογή git hooks για την Terraform που μπορούν να χρησιμοποιηθούν με το pre-commit framework

• Infracost - Εκτιμήσεις κόστους cloud για την Terraform σε pull requests. Λειτουργεί επίσης με την Terragrunt, το Atlantis και το pre-commit-terraform.

Ποιες είναι οι λύσεις για την «κόλαση των εξαρτήσεων» με τις ενότητες;

Οι εκδόσεις των μονάδων πόρων και υποδομών θα πρέπει να προσδιορίζονται. Οι πάροχοι θα πρέπει να διαμορφώνονται εκτός των μονάδων, αλλά μόνο στη σύνθεση. Η έκδοση των παρόχων και του Terraform μπορεί επίσης να κλειδωθεί.

Δεν υπάρχει κύριο εργαλείο διαχείρισης εξαρτήσεων, αλλά υπάρχουν ορισμένες συμβουλές για να γίνουν οι προδιαγραφές εξαρτήσεων λιγότερο προβληματικές. Για παράδειγμα, το Dependabot μπορεί να χρησιμοποιηθεί για την αυτοματοποίηση των ενημερώσεων των εξαρτήσεων. Το Dependabot δημιουργεί pull requests για να διατηρείτε τις εξαρτήσεις σας ασφαλείς και ενημερωμένες. Το Dependabot υποστηρίζει ρυθμίσεις Terraform.