Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
ოფიციალური Terraform დოკუმენტაცია აღწერს კონფიგურაციის ყველა ასპექტს დეტალებში. გაეცანით ყურადღებით რათა ადვილად გაიგოთ შემდეგი თემები.
ეს სექცია შეიცავს ძირითად ცნებებს რომლებიც გამოიყენება წიგნში.
Resource(რესურსი) არის aws_vpc
, aws_db_instance
და ა.შ. ყოველი რესურსი მიეკუთვნება განსაზღვრულ პროვაიდერს, ენიჭება არგუმენტები, აბრუნებს ატრიბუტებს (შემდეგში outputs) და გააჩნია სასიცოცხლო ციკლი(lifecycle). რესურსი შეიძლება შეიქმნას, მოძიებულ იქნას, განახლდეს ან წაიშალოს.
Resource module არის ერთმანეთთანფ დაკავშირებული რესურსების ერთობლიობა რომელიც ჯამურად ქმნის მოქმედებას (მაგ.: AWS VPC Terrafor მოდული ქმნის 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-ის რესურსები გამოიყენება build, push, და deploy ოპერაციებისთვის.
კომპოზიცია არის ინფრასტრუქტურის მოდულების ერთობლიობა, რომლებიც შეიძლება მოიცავდეს ლოგიკურად გაყოფილ ზონებს (მაგ.: AWS Regions, several AWS accounts). კომპოზიცია გამოიყენება სრული ინფრასტრუქტურის აღსაწერად მთელი ორგინაზაციისთვის ან პროქტისთვის.
კომპოზიცია შედგება ინფრასტრუქტურის მოდულებისგან, რომელიც შედგება რესურსის მოდულებისგან, რომელიც შედგება ინდივიდუალური რესურსებისგან.
მონაცემთა წყარო ასრულებს read-only ოპერაციას და დამოკიდებულია პროვაიდერის კონფიგურაციაზე, ის გამოიყენება რესურსის და ინფრასტრუქტურის მოდულებში.
მონაცემთა წყარო terraform_remote_state
ასრულებს დამაკავშირებელ ფუნქციას ზედა დონის მოდულებსა და კომპოზიციებს შორის.
External მონაცემთა წყარო გარე პროგრამებს აძლევს საშუალებას შეასრულონ მონაცემთა წყაროს როლი, მოწოდებული ინფორმაცია კი გამოიყენოთ Terraform კონფიგურაციაში. მაგალითი terraform-aws-lambda module-დან სადაც ფაილის სახელი (filename) გენერირდება გამოძახებული Python script-ის გამოყენებით.
http მონაცემთა წყარო აკეთებს HTTP GET მოთხოვნას მოცემულ URL-ზე და ახორციელებს ინფორმაციის ექსპორტს პასუხის შესახებ, რომელიც ხშირად სასარგებლოა ინფორმაციის მისაღებად ბოლო წერტილებიდან, სადაც Terraform-ის ადგილობრივი პროვაიდერი არ არსებობს.
ინფრასტრუქტურული მოდულები და კომპიზიციები უნდა ინახავდნენ Terraform state-ს მოშორებულ(Remote) ადგილას რაც სხვა Terraform-ის მომხმარებლებს მისცემს საშუალებას ჰქონდეთ წვდომა და შეძლონ გუნდური/კონტროლირებადი მუშაობა (მაგ. მიუთითე ACL, versioning, logging).
Providers, provisioners, და სხვა ტერმინები არის ძალიან კარგად აღწერილი ოფიციალურად დოკუმენტაციაში. ჩემი აზრით არ არის აუცილებლობა აქვს ამ აღწერის აქ გამეორებას და მათ ნაკლები საერთო აქვთ Terraform-ის კარგ მოდულების წერასთან.
როდესაც ცაკლეული რესურსები ჰგვანან ატომებს ინფრასტრუქტურაში, რესურსის მოდულები არიან მოლეკულები (ატომებისგან შემდგარი). მოდული არის ყველაზე პატარა ვერსიონირებადი და გაზიარებადი ერთეული. მას გააჩნია არგუმენტების ზუსტი სია, მას აქვს არგუმენტების ზუსტი სია, განახორციელოს ძირითადი ლოგიკა ასეთი ერთეულისთვის საჭირო ფუნქციის შესასრულებლად. მაგალითად terraform-aws-security-group მოდული ქმნის aws_security_group
და aws_security_group_rule
რესურსებს input-ზე დაფუძნებით. ეს რესურს მოდული თავისთავად შესაძლოა გამოიყენოთ სხვა მოდულთან ერთობლიობაში ახალი ინფრასტრუქტურის მოდულის შესაქმნელად.
მოლეკულებს (რესურს და ინფრასტრუქტურის) შორის მონაცემთა გაცვლა ხორციელდება მოდულების, Outputs-ების და მონაცემთა წყაროების მეშვეობით.
კომპოზიციებს შორის წვდომა ხშირად ხორციელდება remote state მონაცემთა წყაროების მეშვეობით. არსებობს მონაცემთა გაზიარების სხვადასხვა გზები.
ზემოაღწერილი ცნებების ფსევდო-კავშირებში ჩასმისას შეიძლება ასე გამოიყურებოდეს:
ეს დოკუმენტი არის მცდელობა სისტემატიურად აღიწეროს Terraform-ის გამოყენების საუკეთესო პრაქტიკები და მოგაწოდოთ მითითებები ყველაზე გავრცელებულ პრობლემებზე, რომლებსაც აწყდებიან Terraform-ის მომხმარებლები.
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
რომელიც ლოკალურად დირექტორიაში ინახება.
დიდ პროექტში, როგორიც აქ არის აღწერილი, Terragrunt-ის გამოყენების სარგებელი ძალიან თვალსაჩინო ხდება. იხილეთ .
იდეალურია პროექტებისთვის, სადაც ინფრასტრუქტურა ლოგიკურად არის გამოყოფილი (ცალკე AWS ანგარიშები)
კარგია, როდესაც არ არის საჭირო AWS ანგარიშებს შორის გაზიარებული რესურსების ცვლილება (ერთი გარემო = ერთი AWS ანგარიში = ერთი სახელმწიფო ფაილი)
კარგია, როდესაც არ არის საჭირო გარემოს შორის ცვლილებების ორკესტრირება
კარგია, როდესაც ინფრასტრუქტურის რესურსები განსხვავებულია თითო გარემოში და მიზანმიმართულად და მათი განზოგადება შეუძლებელია (მაგ., ზოგიერთი რესურსი არ არის ერთ გარემოში ან ზოგიერთ რეგიონში)
რაც უფრო იზრდება პროექტი, უფრო რთული იქნება ამ გარემოს ერთმანეთთან განახლების შენარჩუნება. განიხილეთ ინფრასტრუქტურის მოდულების გამოყენება (თაროზე მოთავსებული ან შიდა) განმეორებადი ამოცანებისთვის.
წყარო:
ეს Terraform კოდის სტრუქტურის მაგალითი განკუთვნილია საშუალო ზომის ინფრასტრუქტურისთვის რომელიც იყენებს შემდეგ კომპონენტებს:
2 AWS ანგარიშს
2 გამოყოფილი გარემო (prod
და stage
რესურსების გაზიარების გარეშე). თითოეული გარემო მუშაობს გამოყოფილ AWS ანგარიშში და მოიცავს რესურსებს ორივე რეგიონში
თითოეული გარემო იყენებს მზა ინფრასტრუქტურის მოდულის (alb
) განსხვავებულ ვერსიას რომლის კოდის წყაროც არის
თითოეული გარემო იყენებს თვითნაწერ მოდულს modules/network
რომელიც ლოკალურად დირექტორიაში ინახება.
იდეალურია პროექტებისთვის, სადაც ინფრასტრუქტურა ლოგიკურად არის გამოყოფილი (ცალკე AWS ანგარიშები)
კარგია, როდესაც არ არის საჭირო AWS ანგარიშებს შორის გაზიარებული რესურსების ცვლილება (ერთი გარემო = ერთი AWS ანგარიში = ერთი მდგომარეობის ფაილი)
კარგია, როდესაც არ არის საჭირო გარემოს შორის ცვლილებების ორკესტრირება
კარგია, როდესაც ინფრასტრუქტურის რესურსები განსხვავებულია თითო გარემოზე დანიშნულებისამებრ და არ შეიძლება განზოგადდეს (მაგ., ზოგიერთი რესურსი არ არის ერთ გარემოში ან ზოგიერთ რეგიონში)
რაც უფრო იზრდება პროექტი, უფრო რთული იქნება ამ გარემოს ერთმანეთთან განახლების შენარჩუნება. განიხილეთ ინფრასტრუქტურის მოდულების გამოყენება განმეორებადი ამოცანებისთვის.
ვორქშოპი განკუთვნილია მათთვის ვინც ცდილობს პრაქტიკა მიიღოს ამ წიგნში მოცემულ მასალაზე.
ვორქშოპის კონტენტი - https://github.com/antonbabenko/terraform-best-practices-workshop
locals
რესურსებს შორის აშკარა დამოკიდებულების დასაზუსტებლადსასარგებლო გზა Terraform-ისთვის მინიშნებას მისაცემად, რომ ზოგიერთი რესურსი მანამდე უნდა წაიშალოს მაშინაც კი, როცა Terraform-ის კონფიგურაციებში პირდაპირი დამოკიდებულება არ არსებობს.
https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tf
საჭირო არგუმენტი index_document
უნდა იყოს არჩეული თუ var.website
არ არის ცარიელი map.
არჩევითი არგუმენტი error_document
შეიძლება გამოტოვოთ.
არის უამრავი ადამიანი ვინც ქმნის და მართავს Terraform-თან დაკავშირებულ open-source პროექტებს, თუმცა რთულია ვიფიქრო საუკეთესო სტრუქტურაზე. ამიტომ უცვლელად გთავაზობთ ჩამონათვალს awesome-terraform.
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.
არ არსებობს მიზეზი იმისა თუ რატომ არ უნდა გაყვეთ ამ დასახელების კონვენციას :)
გაითვალისწინეთ რომ ღრუბლოვან რესურსებს (cloud resources) ხშირად აქვთ აკრძალვები დაშვებულ სახელებში. ზოგიერთი რესურსს მაგალითად არ შეუძლია შეიცავდეს - ს. ამ წიგნში მოყვანილი კონვენციები თავისთავად ეხება Terraform სახელებს.
გამოიყენეთ _
(underscore) -
(dash) მაგიერ ყველგან (რესურსების დასახელებაში, მონაცემთა წყაროს სახელებში, ცვლადების სახელეში და ა.შ.).
უკეთესია გამოიყენოთ lowercase ასოები და ციფრები (მიუხედავად UTF-8 მხარდაჭერისა).
ნუ გამოიყენებთ რესურსის ტიპს რესურსის სახელში (ნაწილობრივ თუ სრულად):
რესურსის სახელს უნდა ერქვას this
იმ შემთხვევაში თუ არ არის მეტი აღწერითი და ზოგადი სახელი ხელმისაწვდომი, ან თუ რესურსის მოდული ქმნის მხოლოდ ერთ ასეთი ტიპის რესურსს (მაგალითად, AWS VPC module -ში არის მხოლოდ ერთი aws_nat_gateway
ტიპის რესურსი და რამოდენიმე typeaws_route_table
ტიპის რესურსი, ამიტომ aws_nat_gateway
-ს უნდა დაერქვას this
და aws_route_table
-ს უნდა ჰქონდეს მეტი აღწერითი სახელები - როგორიცაა private
, public
, database
).
დასახელებებში ყოველთვის გამოიყენეთ მხოლობითი არსებითი სახელები.
გამოიყენეთ -
არგუმენტების მნიშვნელობებსა და იმ ადგილებში სადაც ეს მნიშვნელობები იქნება გამოტანილი საჯაროდ (მაგალითად, RDS instance-ის DNS სახელში).
გამოიყენე არგუმენტი nclude argument count
/ for_each
რესურსში ან მონაცემთა წყაროს ბლოკში პირველ არგუმენტად დასაწყისში და გამოყავით ახალი ხაზით.
გამოიყენეთ არგუმენტი tags,
თუ რესურსს აქვს ამის მხარდაჭერა, depends_on
და lifecycle
ბლოკებამდე, თუ არსებობს ამის საჭიროება. ყველა ბლოკი უნდა გამოიყოს ცარიელი ხაზით.
count
/ for_each
არგუმენტებში კონდიციების გამოყენებისას, უპირატესობა მიანიჭეთ boolean მნიშვნელობს ვიდრე length
ან სხვა ტიპის expression-ებს.
resource
) კოდის მაგალითებიcount
/ for_each
U-ის გამოყენებაtags
) განთავსებაcount
-შინუ გამოიგონებთ ველოსიპედს რესურსის მოდულებში, გამოიყენეთ: name
, description
, და default
მნიშვნელობები ცვლადებისთვის ისე როგორც "Argument Reference" სექციაში არის განსაზღვრული.
ცვლადებში ვალიდაციის მხარდაჭერა არის საკმაოდ შეზღუდული (მაგალითად არ აქვს წვდომა სხვა ცვლადებზე). ძირითად შემთხვევბში მიზანშეწონილია გამოიყენოთ Plan-ი, რადგაც ვალიდაციის ოფცია ხშირ შემთხვევაში არის უშედეგო.
ცვლადის სახელებში გამოიყენეთ მრავლობითი ფორმა როდესაც მისი ტიპი არის list(...)
ან map(...)
.
ცვლადის ბლოკში დაიცავით ელემენტების შემდეგი მიმდევრობა: description
, type
, default
, validation
.
ყოველთვის გამოიყენეთ description
ყველა ცვლადზე (სამომავლოდ აუცილებლად გამოგადგებათ)
უმჯობესია გამოიყენოთ მარტივი ცვლადის ტიპები (number
, string
, list(...)
, map(...)
, any
) ვიდრე სპეციფიური ტიპები როგორიცაა object()
იმ შემთხვევაში თუ არ გჭირდებათ მკაცრი შეზღუდვები key-ებზე.
გამოიყენეთ სპეციფიური ცვლადის ტიპები როგორიცაა map(map(string))
იმ შემთხვევაში თუ ყველა ელემენტს map-ზე ერთი და იგივე ცვლადის ტიპი (მაგალითად string
) ან შესაძლოა დაკონვერტირდეს მასში (მაგალითად number
შესაძლოა დაკონვერტირდეს string
-ში).
გამოიყენეთ ცვლადის ტიპი any
რათა გამოტოვოთ ვალიდაცია როდესაც კონკრეტულ შრეზე ან როდესაც რამოდენიმე ცვლადის ტიპი უნდა იქნას მხარდაჭერილი.
მნიშვნელობა(Value) {}
ზოგჯერ არის map ტიპისა მაგრამ ხანდახან არის object ტიპის. გამოიყენეთ tomap(...)
რათა შექმნა map იმ შემთხვევაში თუ შეზღუდულია object-ის შექმნა.
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).
The name of output should describe the property it contains and be less free-form than you would normally want.
Good structure for the name of output looks like {name}_{type}_{attribute}
, where:
{name}
is a resource or data source name without a provider prefix. {name}
for aws_subnet
is subnet
, foraws_vpc
it is vpc
.
{type}
is a type of a resource sources
{attribute}
is an attribute returned by the output
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.
If the returned value is a list it should have a plural name. See example.
Always include description
for all outputs even if you think it is obvious.
Avoid setting sensitive
argument unless you fully control usage of this output in all places in all modules.
Prefer try()
(available since Terraform 0.13) over element(concat(...))
(legacy approach for the version before 0.13)
output
კოდის მაგალითიდააბრუნეთ security group მხოლოდ ერთი ID:
ერთი და იმავე ტიპის მრავალი რესურსის არსებობისას, this
უნდა იყოს გამოტოვებული Output სახელით:
საზოგადოებაში ყველაზე ხშირად დასმული კითხვები როგორც წესი დაკავშირებულია Terraform-ის კოდის სტრუქტურასთან. ყველას ერთხელ მაინც დროის რომელიმე მონაკვეთში უფიქრია კოდის საუკეთესო სტრუქტურაზე.
ეს ერთერთი იმ კითხვათაგანია სადაც რთულია უნივერსალური გადაწყვეტილება ან რჩევა გასცე. ამიტომ უმჯობესია იმის გარკვევა თუ რასთან გვაქვს საქმე.
რა სირთულის პროექტია?
დაკავშირებული რესურსების რაოდენობა
Terraform-ის პროვაიდერების რაოდენობა (იხილეთ შენიშვნა "ლოგიკური პროვაიდერი")
რამდენად ხშირად იცვლება თქვენი ინფრასტრუქტურა?
დაწყებული ერთხელ თვეში/კვირაში/დღეში
დამთავრებული მუდმივად (ყოველი commit-ის დროს)
ვინ არის კოდის ცვლილების ინიციატორი? აძლევთ თუ არა უფლებას თქვენს CI სერვერს მოახდინოს რეპოზიტორიის განახლება ახალი არტეფაქტის შექმნისას?
მხოლოდ დეველოპერებს აქვთ უფლება შეიტანონ ცვლილება ინფრასტრუქტურის კოდში
ყველას შეუძლია შეიტანოს ცვლილებაზე განაცხადი, PR-ის გახსნის მეშვეობით (CI სერვერზე ავტომატურად გაშვებულ დავალებების ჩათვლით)
რომელ პლატფორმას ან სერვისს იყენებთ დეფლოისთვის?
AWS CodeDeploy, Kubernetes, ან OpenShift ითხოვენ სხვადასხვა მიდგომას
როგორ აჯგუფებთ გარემოებს?
გარემოთი, რეგიონით, პროექტით
მთლიანი კოდის ჩასმა main.tf
-ში არის კარგი იდეა როდესაც წერთ მაგალითს. ყველა სხვა დანარჩენ შემთხვევაში უნდა დაყოთ კოდი ფაილებად ლოგიკის მიხედვით:
main.tf
- აღწერს მოდულებს, locals და მონაცემთა წყაროებს რესურსების შესაქმნელად
variables.tf
- შეიცავს main.tf
-ში აღწერილი ცვლადების ეკლარაციებს(declarations)
outputs.tf
- შეიცავს outputs -ში main.tf
აღწერილი რესურსებისთვის
versions.tf
- შეიცავს ვერსიის მოთხოვნებს Terraform-ისთვის და პროვაიდერებისთვის
terraform.tfvars
უნდა გამოიყენებოდეს მხოლოდ composition-ში.
დარწმუნდით, რომ გესმით ძირითადი ცნებები - resource module, infrastructure module, და composition, რადგან ისინი გამოიყენება შემდეგ მაგალითებში.
უფრო ადვილი და სწრაფია მუშაობა მცირე რაოდენობის რესურსებთან
terraform plan
და terraform apply
ორივე აკეთებს cloud API გამოძახებებს(calls) რესურსების მდგომარეობის შესამოწმებლად
თუ მთელი ინფრასტრუქტურა გაქვთ ერთ კომპოზიციაში, ამას შეიძლება გარკვეული დრო დასჭირდეს
აფეთქების რადიუსი/Blast Radius (უსაფრთხოების დარღვევის შემთხვევაში) უფრო მცირეა ნაკლები რესურსებით
ერთმანეთისგან შეუსაბამო რესურსების იზოლირება მათი ცალკეულ კომპოზიციებში მოთავსებით ამცირებს რისკს, თუ რამე არასწორედ მოხდება
დაიწყეთ თქვენი პროექტი დისტანციური მდგომარეობის გამოყენებით, რადგან:
თქვენი ლეპტოპი არ არის ადგილი თქვენი ინფრასტრუქტურის წყაროსთვის
tfstate
-ის მართვა git-ში არის ღამის კოშმარი
მოგვიანებით, როდესაც ინფრასტრუქტურის ფენები დაიწყებენ ზრდას რამდენიმე მიმართულებით (დამოკიდებულებების ან რესურსების რაოდენობა), უფრო ადვილი იქნება ნივთების კონტროლის ქვეშ შენარჩუნება
ივარჯიშეთ თანმიმდევრულ სტრუქტურასა და დასახელების კონვენციაში:
პროცედურული კოდექსის მსგავსად, Terraform კოდი უნდა დაიწეროს იმისთვის, რომ ადამიანებმა პირველ რიგში წაიკითხონ, თანმიმდევრულობა დაგეხმარებათ, როდესაც ცვლილებები მოხდება ექვსი თვის შემდეგ
შესაძლებელია რესურსების გადატანა Terraform State ფაილში, მაგრამ ეს შეიძლება იყოს უფრო რთული, თუ თქვენ გაქვთ არათანმიმდევრული სტრუქტურა და დასახელება
შეეცადეთ რესურსის მოდულები რაც შეიძლება სადად
ნუ დააკოდირებთ მნიშვნელობებს, რომლებიც შეიძლება გადავიდეს ცვლადებად ან შეიძლება მიეთითონ მონაცემთა წყაროების გამოყენებით
გამოიყენებთ მონაცემთა წყაროები და terraform_remote_state
როგორც წებო ინფრასტრუქტურის მოდულებას და კომპოზიციას შორის.
ამ წიგნში პროექტების მაგალითები დაჯგუფებულია სირთულის მიხედვით - მცირე ინფრასტრუქტურიდან ძალიან დიდამდე. ეს განცალკევება არ არის მკაცრი, ასე რომ შეამოწმეთ სხვა სტრუქტურებიც.
მცირე ინფრასტრუქტურის ქონა ნიშნავს, რომ არის მცირე რაოდენობის დამოკიდებულებები და მცირე რესურსი. პროექტის ზრდასთან, აშკარა ხდება Terraform-ის კონფიგურაციების შესრულების ჯაჭვის მოთხოვნილება, სხვადასხვა ინფრასტრუქტურული მოდულების დაკავშირება და კომპოზიციის შიგნით მნიშვნელობების გადაცემა.
არსებობს ორკესტრაციული გადაწყვეტილებების სულ მცირე 5 განსხვავებული ჯგუფი, რომელსაც დეველოპერები იყენებენ::
მხოლოდ Terraform. ძალიან მარტივია, დეველოპერებმა უნდა იცოდნენ მხოლოდ Terraform სამუშაოს შესასრულებლად.
Terragrunt. სუფთა საორკესტრო ინსტრუმენტი, რომელიც შეიძლება გამოყენებულ იქნას მთელი ინფრასტრუქტურის ორკესტრირებისთვის, ასევე დამოკიდებულებების დასამუშავებლად. Terragrunt მუშაობს ინფრასტრუქტურის მოდულებით და კომპოზიციებით, ამიტომ ამცირებს კოდის დუბლირებას.
In-house სკრიპტები. ხშირად ეს ხდება როგორც ამოსავალი წერტილი ორკესტრირებისკენ და Terragrunt-ის აღმოჩენამდე.
Ansible ან მსგავსი ზოგადი დანიშნულების ავტომატიზაციის ინსტრუმენტი. ჩვეულებრივ გამოიყენება, როდესაც Terraform მიიღება Ansible-ის შემდეგ, ან როდესაც Ansible UI აქტიურად გამოიყენება.
Crossplane და კუბერნეტესისგან შთაგონებული სხვა გადაწყვეტილებები. ზოგჯერ აზრი აქვს Kubernetes-ის ეკოსისტემის გამოყენებას და შერიგების მარყუჟის(reconciliation loop) ფუნქციის გამოყენებას თქვენი Terraform კონფიგურაციის სასურველი მდგომარეობის მისაღწევად. იხილეთ ვიდეოCrossplane vs Terraform მეტი ინფორმაციისთვის.
ამის გათვალისწინებით, ეს წიგნი მიმოიხილავს ამ პროექტის პირველ ორ სტრუქტურას, მხოლოდ Terraform-სა და Terragrunt-ს.
იხილეთ კოდის სტრუქტურების მაგალითები Terraform-ის ან Terragrunt-ისთვის მომდევნო თავში.
Compliance.tf — Terraform Compliance Simplified. Make your Terraform modules compliance-ready.
—