ოფიციალური Terraform დოკუმენტაცია აღწერს კონფიგურაციის ყველა ასპექტს დეტალებში. გაეცანით ყურადღებით რათა ადვილად გაიგოთ შემდეგი თემები.

ეს სექცია შეიცავს ძირითად ცნებებს რომლებიც გამოიყენება წიგნში.

რესურსი (Resource)

Resource(რესურსი) არის aws_vpc, aws_db_instanceდა ა.შ. ყოველი რესურსი მიეკუთვნება განსაზღვრულ პროვაიდერს, ენიჭება არგუმენტები, აბრუნებს ატრიბუტებს (შემდეგში outputs) და გააჩნია სასიცოცხლო ციკლი(lifecycle). რესურსი შეიძლება შეიქმნას, მოძიებულ იქნას, განახლდეს ან წაიშალოს.

მოდულის რესურსი (Resource module)

Resource module არის ერთმანეთთანფ დაკავშირებული რესურსების ერთობლიობა რომელიც ჯამურად ქმნის მოქმედებას (მაგ.: AWS VPC Terrafor მოდული ქმნის VPC, subnets, NAT gateway და ა.შ.). ეს დამოკიდებულია პროვაიდერის კონფიფურაციაზე, შესაძლოა თუ არა ეს რესურსები განსაზღვრულ იქნას მოდულის ფარგლებში ან უფრო მაღალი დონის სტრუქტურაში (მაგ.: ინფრასტრუქტურის მოდულში).

ინფრასტრქუტურის მოდული (Infrastructure module)

ინფრასტუქტურის მოდული არის რესურსების ერთობლიობა, რომლებიც შეიძლება ლოგიკურად ერთმანეთთად კავშირში არ იყვნენ, თუმცა კონკრეტული შემთხვევაში/პროქტში/კონფიგურაციაში ერთსა და იმავე საქმეს ემსახურებოდნენ. ის აღწერს კონფიგურაციას პროვაიდერისთვის, რომელიც შემდეგ გადაეცემა ქვედა დონის მოდულის რესურსებსა და რესურსებს. როგორც წესი ის შემოიფარგლება მხოლოდ ერთ ერთეულში თითოეული ლოგიკურ პროცესორზე (მაგ: AWS Region, Google Project).

მაგალითად, terraform-aws-atlantis მოდული იყენებას ისეთ რესურსებს როგორებიცაა terraform-aws-vpc და terraform-aws-security-group რათა მართოს ინფრასტრუქტურა რომელიც საჭიროა Atlantis-ის გასაშვებად AWS Fargate-ზე.

კიდევ ერთი მაგალითი გახლავთ terraform-aws-cloudquery მოდული, სადაც რამოდენიმე terraform-aws-modules მოდული გამოიყენება ერთდროულად რომ მართონ ინფრასტრუქტურა ისეთივე წარმატებით როგორც მაგალითად Docker-ის რესურსები გამოიყენება build, push, და deploy ოპერაციებისთვის.

კომპოზიცია (Composition)

კომპოზიცია არის ინფრასტრუქტურის მოდულების ერთობლიობა, რომლებიც შეიძლება მოიცავდეს ლოგიკურად გაყოფილ ზონებს (მაგ.: AWS Regions, several AWS accounts). კომპოზიცია გამოიყენება სრული ინფრასტრუქტურის აღსაწერად მთელი ორგინაზაციისთვის ან პროქტისთვის.

კომპოზიცია შედგება ინფრასტრუქტურის მოდულებისგან, რომელიც შედგება რესურსის მოდულებისგან, რომელიც შედგება ინდივიდუალური რესურსებისგან.

მონაცემთა წყარო (Data source)

მონაცემთა წყარო ასრულებს read-only ოპერაციას და დამოკიდებულია პროვაიდერის კონფიგურაციაზე, ის გამოიყენება რესურსის და ინფრასტრუქტურის მოდულებში.

მონაცემთა წყარო terraform_remote_state ასრულებს დამაკავშირებელ ფუნქციას ზედა დონის მოდულებსა და კომპოზიციებს შორის.

External მონაცემთა წყარო გარე პროგრამებს აძლევს საშუალებას შეასრულონ მონაცემთა წყაროს როლი, მოწოდებული ინფორმაცია კი გამოიყენოთ Terraform კონფიგურაციაში. მაგალითი terraform-aws-lambda module-დან სადაც ფაილის სახელი (filename) გენერირდება გამოძახებული Python script-ის გამოყენებით.

http მონაცემთა წყარო აკეთებს HTTP GET მოთხოვნას მოცემულ URL-ზე და ახორციელებს ინფორმაციის ექსპორტს პასუხის შესახებ, რომელიც ხშირად სასარგებლოა ინფორმაციის მისაღებად ბოლო წერტილებიდან, სადაც Terraform-ის ადგილობრივი პროვაიდერი არ არსებობს.

Remote state

ინფრასტრუქტურული მოდულები და კომპიზიციები უნდა ინახავდნენ Terraform state-ს მოშორებულ(Remote) ადგილას რაც სხვა Terraform-ის მომხმარებლებს მისცემს საშუალებას ჰქონდეთ წვდომა და შეძლონ გუნდური/კონტროლირებადი მუშაობა (მაგ. მიუთითე ACL, versioning, logging).

Provider, provisioner, etc

Providers, provisioners, და სხვა ტერმინები არის ძალიან კარგად აღწერილი ოფიციალურად დოკუმენტაციაში. ჩემი აზრით არ არის აუცილებლობა აქვს ამ აღწერის აქ გამეორებას და მათ ნაკლები საერთო აქვთ Terraform-ის კარგ მოდულების წერასთან.

რატომ ასე რთულად?

როდესაც ცაკლეული რესურსები ჰგვანან ატომებს ინფრასტრუქტურაში, რესურსის მოდულები არიან მოლეკულები (ატომებისგან შემდგარი). მოდული არის ყველაზე პატარა ვერსიონირებადი და გაზიარებადი ერთეული. მას გააჩნია არგუმენტების ზუსტი სია, მას აქვს არგუმენტების ზუსტი სია, განახორციელოს ძირითადი ლოგიკა ასეთი ერთეულისთვის საჭირო ფუნქციის შესასრულებლად. მაგალითად terraform-aws-security-group მოდული ქმნის aws_security_group და aws_security_group_rule რესურსებს input-ზე დაფუძნებით. ეს რესურს მოდული თავისთავად შესაძლოა გამოიყენოთ სხვა მოდულთან ერთობლიობაში ახალი ინფრასტრუქტურის მოდულის შესაქმნელად.

მოლეკულებს (რესურს და ინფრასტრუქტურის) შორის მონაცემთა გაცვლა ხორციელდება მოდულების, Outputs-ების და მონაცემთა წყაროების მეშვეობით.

კომპოზიციებს შორის წვდომა ხშირად ხორციელდება remote state მონაცემთა წყაროების მეშვეობით. არსებობს მონაცემთა გაზიარების სხვადასხვა გზები.

ზემოაღწერილი ცნებების ფსევდო-კავშირებში ჩასმისას შეიძლება ასე გამოიყურებოდეს:

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)
    }
  }
}

Terraform არის ერთერთი ძლიერი (თუ არა დღესდღეისობით ყველაზე ძლიერი) და ერთერთი ყველაზე ხშირად გამოყენებადი ხელსაწყო რომელიც გაძლევთ საშუალებას მართოთ ინფრასტრუქტურა როგორც კოდი (IaC). ის საშუალებას გაძლევთ შექმნათ სხვადასხვა რესურსები და არ ზღუდავს მათ ინტეგრაციასა და მხარდაჭერაში.

ამ წიგნში აღწერილი ზოგიერთი ინფორმაცია შეიძლება არ ჩანდეს საუკეთესო პრაქტიკად. მე ვიცი ეს, ვეხმარები მკითხველს გამიჯნოს თუ რა არის საუკეთესო პრაქტიკა და რა არის კიდევ ერთი გზა ამის გამეორებისა.

ამ წიგნის შექმნა დაიწყო მზიან მადრიდში 2018 წელს და ის ხელმისაწვდომია შემდეგ მისამართზე: https://www.terraform-best-practices.com/.

წლების შემდეგ ის განახლდა უფრო აქტუალური პრაქტიკები რომლებიც ხელმისაწვდომი გახდა Terraform 1.0-ის შემდეგ. საბოლოოდ, ეს წიგნი შეიცავს უდაოდ ყველაზე საუკეთესო პრაქტიკებსა და რეკომენდაციებს Terraform-ის მომხმარებლებისათვის.

სპონსორები

Please contact me if you want to become a sponsor.

თარგმანები

დამეკონტაქტეთ თუ გსურთ დახმარება გამიწიოთ ამ წიგნის თარგმნაში სხვა ენაზე.

კონტრიბუცია

მსურს ყოველთვის მივიღო უკუკავშირი და ახალი იდეები საზოგადოებისგან რაც მომცემს საშუალებას განვაახლო წიგნი დროდადრო.

თუ დაინტერესებული ხართ კონკრეტული საკითხებით, გახსენით ან მონიშნეთ issue, რომელიც გსურთ რომ უფრო დეტალურად იქნას განხილული. თუ გაქვთ კონტექნი კონკრეტული მიმართულებით რომელიც გსურთ რომ გააზიაროთ, დაწერეთ და გააკეთეთ pull-request (ამ ეტაპზე არ არის აუცილებელი იდეალურად დაწერილი ტექსტი გქონდეთ).

ავტორები

ეს წიგნი შექმნილია ანტონ ბაბენკოს, სხვადასხვა კონტრიბუტორებისა და მთარგმნელების მიერ.

ლიცენზია

ეს ნამუშევარი გახლავთ Apache 2 License-ის ქვეშ. იხილეთ LICENSE მეტი ინფორმაციისთვის.

ამ წიგნში მოცემულ ინფორმაციის ვალიდურობაზე მისი ავტორები და კონტრიბუტორები ვერ მოგცემენ გარანტიას. გთხოვთ გაითვალისწინოთ რომ, ამ წიგნში მოყვანილი ინფორმაციას ვრცელდება უფასოდ, არანაირი ხელშეკრულება ან კონტრაქტი არ არსებობს თქვენსა და ამ კონტენტთან/პროექტთან ნებისმიერ ასოცირებულ პირს შორის.ავტორები და კონტრიბუტორები არ იღებენ და ამით უარს აცხადებენ პასუხისმგებლობაზე რომელიმე მხარის წინაშე ნებისმიერი დანაკარგის, დაზიანების ან შეფერხების გამო, რომელიც გამოწვეულია ამ კონტენტში შემავალ, ასოცირებულ ან დაკავშირებულ ინფორმაციაში შეცდომით ან უმოქმედობით, მიუხედავად იმისა, ასეთი შეცდომები ან გამოტოვებები გამოწვეულია დაუდევრობისა, უბედური შემთხვების ან სხვა მიზეზით.

Copyright © 2018-2022 ანტონ ბაბენკო.

წყარო:

ეს Terraform კოდის სტრუქტურის მაგალითი განკუთვნილია დიდი ზომის ინფრასტრუქტურისთვის რომელიც იყენებს შემდეგ კომპონენტებს:

• 2 AWS ანგარიში

• 2 რეგიონი

• 2 გამოყოფილი გარემო (prod და stage რესურსების გაზიარების გარეშე). თითოეული გარემო მუშაობს გამოყოფილ AWS ანგარიშში და მოიცავს რესურსებს ორივე რეგიონში

• თითოეული გარემო იყენებს მზა ინფრასტრუქტურის მოდულის (alb) განსხვავებულ ვერსიას რომლის კოდის წყაროც არის

• თითოეული გარემო იყენებს თვითნაწერ მოდულს modules/network რომელიც ლოკალურად დირექტორიაში ინახება.

წყარო:

ეს Terraform კოდის სტრუქტურის მაგალითი განკუთვნილია საშუალო ზომის ინფრასტრუქტურისთვის რომელიც იყენებს შემდეგ კომპონენტებს:

• 2 AWS ანგარიშს

• 2 გამოყოფილი გარემო (prod და stage რესურსების გაზიარების გარეშე). თითოეული გარემო მუშაობს გამოყოფილ AWS ანგარიშში და მოიცავს რესურსებს ორივე რეგიონში

• თითოეული გარემო იყენებს მზა ინფრასტრუქტურის მოდულის (alb) განსხვავებულ ვერსიას რომლის კოდის წყაროც არის

• თითოეული გარემო იყენებს თვითნაწერ მოდულს modules/network რომელიც ლოკალურად დირექტორიაში ინახება.

ვორქშოპი განკუთვნილია მათთვის ვინც ცდილობს პრაქტიკა მიიღოს ამ წიგნში მოცემულ მასალაზე.

ვორქშოპის კონტენტი - https://github.com/antonbabenko/terraform-best-practices-workshop

გამოიყენეთ locals რესურსებს შორის აშკარა დამოკიდებულების დასაზუსტებლად

სასარგებლო გზა Terraform-ისთვის მინიშნებას მისაცემად, რომ ზოგიერთი რესურსი მანამდე უნდა წაიშალოს მაშინაც კი, როცა Terraform-ის კონფიგურაციებში პირდაპირი დამოკიდებულება არ არსებობს.

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

Terraform 0.12 - საჭირო vs არჩევითი არგუმენტები

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"
}

https://twitter.com/antonbabenko/lists/terraform-experts - List of people who work with Terraform very actively and can tell you a lot (if you ask them).

https://github.com/shuaibiyy/awesome-terraform - Curated list of resources on HashiCorp's Terraform.

http://bit.ly/terraform-youtube - "Your Weekly Dose of Terraform" YouTube channel by Anton Babenko. Live streams with reviews, interviews, Q&A, live coding, and some hacking with Terraform.

https://weekly.tf - Terraform Weekly newsletter. Various news in the Terraform world (projects, announcements, discussions) by Anton Babenko.

ზოგადი კონვენცია

1. გამოიყენეთ _ (underscore) - (dash) მაგიერ ყველგან (რესურსების დასახელებაში, მონაცემთა წყაროს სახელებში, ცვლადების სახელეში და ა.შ.).

2. უკეთესია გამოიყენოთ lowercase ასოები და ციფრები (მიუხედავად 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 module -ში არის მხოლოდ ერთი aws_nat_gateway ტიპის რესურსი და რამოდენიმე typeaws_route_table ტიპის რესურსი, ამიტომ aws_nat_gateway -ს უნდა დაერქვას this და aws_route_table -ს უნდა ჰქონდეს მეტი აღწერითი სახელები - როგორიცაა private, public, database).

2. დასახელებებში ყოველთვის გამოიყენეთ მხოლობითი არსებითი სახელები.

3. გამოიყენეთ - არგუმენტების მნიშვნელობებსა და იმ ადგილებში სადაც ეს მნიშვნელობები იქნება გამოტანილი საჯაროდ (მაგალითად, RDS instance-ის DNS სახელში).

4. გამოიყენე არგუმენტი nclude argument count / for_each რესურსში ან მონაცემთა წყაროს ბლოკში პირველ არგუმენტად დასაწყისში და გამოყავით ახალი ხაზით.

5. გამოიყენეთ არგუმენტი tags, თუ რესურსს აქვს ამის მხარდაჭერა, depends_on და lifecycle ბლოკებამდე, თუ არსებობს ამის საჭიროება. ყველა ბლოკი უნდა გამოიყოს ცარიელი ხაზით.

6. count / for_each არგუმენტებში კონდიციების გამოყენებისას, უპირატესობა მიანიჭეთ boolean მნიშვნელობს ვიდრე length ან სხვა ტიპის expression-ებს.

რესურსის(resource) კოდის მაგალითები

count / for_eachU-ის გამოყენება

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 მნიშვნელობები ცვლადებისთვის ისე როგორც "Argument Reference" სექციაში არის განსაზღვრული.

2. ცვლადებში ვალიდაციის მხარდაჭერა არის საკმაოდ შეზღუდული (მაგალითად არ აქვს წვდომა სხვა ცვლადებზე). ძირითად შემთხვევბში მიზანშეწონილია გამოიყენოთ Plan-ი, რადგაც ვალიდაციის ოფცია ხშირ შემთხვევაში არის უშედეგო.

3. ცვლადის სახელებში გამოიყენეთ მრავლობითი ფორმა როდესაც მისი ტიპი არის list(...) ან map(...).

4. ცვლადის ბლოკში დაიცავით ელემენტების შემდეგი მიმდევრობა: description , type, default, validation.

5. ყოველთვის გამოიყენეთ description ყველა ცვლადზე (სამომავლოდ აუცილებლად გამოგადგებათ)

6. უმჯობესია გამოიყენოთ მარტივი ცვლადის ტიპები (number, string, list(...), map(...), any) ვიდრე სპეციფიური ტიპები როგორიცაა object() იმ შემთხვევაში თუ არ გჭირდებათ მკაცრი შეზღუდვები key-ებზე.

7. გამოიყენეთ სპეციფიური ცვლადის ტიპები როგორიცაა map(map(string)) იმ შემთხვევაში თუ ყველა ელემენტს map-ზე ერთი და იგივე ცვლადის ტიპი (მაგალითად string) ან შესაძლოა დაკონვერტირდეს მასში (მაგალითად number შესაძლოა დაკონვერტირდეს string-ში).

8. გამოიყენეთ ცვლადის ტიპი any რათა გამოტოვოთ ვალიდაცია როდესაც კონკრეტულ შრეზე ან როდესაც რამოდენიმე ცვლადის ტიპი უნდა იქნას მხარდაჭერილი.

9. მნიშვნელობა(Value) {} ზოგჯერ არის map ტიპისა მაგრამ ხანდახან არის object ტიპის. გამოიყენეთ tomap(...) რათა შექმნა map იმ შემთხვევაში თუ შეზღუდულია object-ის შექმნა.

Outputs

Make outputs consistent and understandable outside of its scope (when a user is using a module it should be obvious what type and attribute of the value it returns).

1. The name of output should describe the property it contains and be less free-form than you would normally want.

2. Good structure for the name of output looks like {name}_{type}_{attribute} , where:

   1. {name} is a resource or data source name without a provider prefix. {name} for aws_subnet is subnet, foraws_vpc it is vpc.

   2. {type} is a type of a resource sources

   3. {attribute} is an attribute returned by the output

   4. See examples.

3. If the output is returning a value with interpolation functions and multiple resources, {name} and {type} there should be as generic as possible (this as prefix should be omitted). See example.

4. If the returned value is a list it should have a plural name. See example.

5. Always include description for all outputs even if you think it is obvious.

6. Avoid setting sensitive argument unless you fully control usage of this output in all places in all modules.

7. Prefer try() (available since Terraform 0.13) over element(concat(...)) (legacy approach for the version before 0.13)

outputკოდის მაგალითი

დააბრუნეთ security group მხოლოდ ერთი ID:

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 უნდა იყოს გამოტოვებული 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 სერვერს მოახდინოს რეპოზიტორიის განახლება ახალი არტეფაქტის შექმნისას?

  • მხოლოდ დეველოპერებს აქვთ უფლება შეიტანონ ცვლილება ინფრასტრუქტურის კოდში

  • ყველას შეუძლია შეიტანოს ცვლილებაზე განაცხადი, PR-ის გახსნის მეშვეობით (CI სერვერზე ავტომატურად გაშვებულ დავალებების ჩათვლით)

• რომელ პლატფორმას ან სერვისს იყენებთ დეფლოისთვის?

  • AWS CodeDeploy, Kubernetes, ან OpenShift ითხოვენ სხვადასხვა მიდგომას

• როგორ აჯგუფებთ გარემოებს?

  • გარემოთი, რეგიონით, პროექტით

Terraform-ის კონფიგურაციების სტრუქტურირება

მთლიანი კოდის ჩასმა main.tf-ში არის კარგი იდეა როდესაც წერთ მაგალითს. ყველა სხვა დანარჩენ შემთხვევაში უნდა დაყოთ კოდი ფაილებად ლოგიკის მიხედვით:

• main.tf - აღწერს მოდულებს, locals და მონაცემთა წყაროებს რესურსების შესაქმნელად

• variables.tf - შეიცავს main.tf-ში აღწერილი ცვლადების ეკლარაციებს(declarations)

• outputs.tf - შეიცავს outputs -ში main.tf აღწერილი რესურსებისთვის

• versions.tf - შეიცავს ვერსიის მოთხოვნებს Terraform-ისთვის და პროვაიდერებისთვის

terraform.tfvars უნდა გამოიყენებოდეს მხოლოდ composition-ში.

როგორ ვიფიქროთ Terraform-ის კონფიგურაციის სტრუქტურაზე?

საერთო რეკომენდაციები კოდის სტრუქტურირებისთვის

• უფრო ადვილი და სწრაფია მუშაობა მცირე რაოდენობის რესურსებთან

  • terraform plan და terraform apply ორივე აკეთებს cloud API გამოძახებებს(calls) რესურსების მდგომარეობის შესამოწმებლად

  • თუ მთელი ინფრასტრუქტურა გაქვთ ერთ კომპოზიციაში, ამას შეიძლება გარკვეული დრო დასჭირდეს

• აფეთქების რადიუსი/Blast Radius (უსაფრთხოების დარღვევის შემთხვევაში) უფრო მცირეა ნაკლები რესურსებით

  • ერთმანეთისგან შეუსაბამო რესურსების იზოლირება მათი ცალკეულ კომპოზიციებში მოთავსებით ამცირებს რისკს, თუ რამე არასწორედ მოხდება

• დაიწყეთ თქვენი პროექტი დისტანციური მდგომარეობის გამოყენებით, რადგან:

  • თქვენი ლეპტოპი არ არის ადგილი თქვენი ინფრასტრუქტურის წყაროსთვის

  • tfstate-ის მართვა git-ში არის ღამის კოშმარი

  • მოგვიანებით, როდესაც ინფრასტრუქტურის ფენები დაიწყებენ ზრდას რამდენიმე მიმართულებით (დამოკიდებულებების ან რესურსების რაოდენობა), უფრო ადვილი იქნება ნივთების კონტროლის ქვეშ შენარჩუნება

• ივარჯიშეთ თანმიმდევრულ სტრუქტურასა და დასახელების კონვენციაში:

  • პროცედურული კოდექსის მსგავსად, Terraform კოდი უნდა დაიწეროს იმისთვის, რომ ადამიანებმა პირველ რიგში წაიკითხონ, თანმიმდევრულობა დაგეხმარებათ, როდესაც ცვლილებები მოხდება ექვსი თვის შემდეგ

  • შესაძლებელია რესურსების გადატანა Terraform State ფაილში, მაგრამ ეს შეიძლება იყოს უფრო რთული, თუ თქვენ გაქვთ არათანმიმდევრული სტრუქტურა და დასახელება

• შეეცადეთ რესურსის მოდულები რაც შეიძლება სადად

• ნუ დააკოდირებთ მნიშვნელობებს, რომლებიც შეიძლება გადავიდეს ცვლადებად ან შეიძლება მიეთითონ მონაცემთა წყაროების გამოყენებით

• გამოიყენებთ მონაცემთა წყაროები და terraform_remote_state როგორც წებო ინფრასტრუქტურის მოდულებას და კომპოზიციას შორის.

ამ წიგნში პროექტების მაგალითები დაჯგუფებულია სირთულის მიხედვით - მცირე ინფრასტრუქტურიდან ძალიან დიდამდე. ეს განცალკევება არ არის მკაცრი, ასე რომ შეამოწმეთ სხვა სტრუქტურებიც.

ინფრასტრუქტურის მოდულების და კომპოზიციების ორკესტრირება

მცირე ინფრასტრუქტურის ქონა ნიშნავს, რომ არის მცირე რაოდენობის დამოკიდებულებები და მცირე რესურსი. პროექტის ზრდასთან, აშკარა ხდება Terraform-ის კონფიგურაციების შესრულების ჯაჭვის მოთხოვნილება, სხვადასხვა ინფრასტრუქტურული მოდულების დაკავშირება და კომპოზიციის შიგნით მნიშვნელობების გადაცემა.

არსებობს ორკესტრაციული გადაწყვეტილებების სულ მცირე 5 განსხვავებული ჯგუფი, რომელსაც დეველოპერები იყენებენ::

1. მხოლოდ Terraform. ძალიან მარტივია, დეველოპერებმა უნდა იცოდნენ მხოლოდ Terraform სამუშაოს შესასრულებლად.

2. Terragrunt. სუფთა საორკესტრო ინსტრუმენტი, რომელიც შეიძლება გამოყენებულ იქნას მთელი ინფრასტრუქტურის ორკესტრირებისთვის, ასევე დამოკიდებულებების დასამუშავებლად. Terragrunt მუშაობს ინფრასტრუქტურის მოდულებით და კომპოზიციებით, ამიტომ ამცირებს კოდის დუბლირებას.

3. In-house სკრიპტები. ხშირად ეს ხდება როგორც ამოსავალი წერტილი ორკესტრირებისკენ და Terragrunt-ის აღმოჩენამდე.

4. Ansible ან მსგავსი ზოგადი დანიშნულების ავტომატიზაციის ინსტრუმენტი. ჩვეულებრივ გამოიყენება, როდესაც Terraform მიიღება Ansible-ის შემდეგ, ან როდესაც Ansible UI აქტიურად გამოიყენება.

5. Crossplane და კუბერნეტესისგან შთაგონებული სხვა გადაწყვეტილებები. ზოგჯერ აზრი აქვს Kubernetes-ის ეკოსისტემის გამოყენებას და შერიგების მარყუჟის(reconciliation loop) ფუნქციის გამოყენებას თქვენი Terraform კონფიგურაციის სასურველი მდგომარეობის მისაღწევად. იხილეთ ვიდეოCrossplane vs Terraform მეტი ინფორმაციისთვის.

ამის გათვალისწინებით, ეს წიგნი მიმოიხილავს ამ პროექტის პირველ ორ სტრუქტურას, მხოლოდ Terraform-სა და Terragrunt-ს.

იხილეთ კოდის სტრუქტურების მაგალითები Terraform-ის ან Terragrunt-ისთვის მომდევნო თავში.

რომელი ხელსაწყოები უნდა ვიცოდეთ და გამოვიყენოთ?

• - ორკესტრაციის ხელსაწყო

• - Code linter

• - ვერსიების მენეჯერი

• - Pull Request-ების ავტომატიზაცია