კოდის სტრუქტურა

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

როგორ დავასტრუქტურო Terraform-ის პროექტი?

ეს ერთერთი იმ კითხვათაგანია სადაც რთულია უნივერსალური გადაწყვეტილება ან რჩევა გასცე. ამიტომ უმჯობესია იმის გარკვევა თუ რასთან გვაქვს საქმე.

• რა სირთულის პროექტია?

  • დაკავშირებული რესურსების რაოდენობა

  • Terraform-ის პროვაიდერების რაოდენობა (იხილეთ შენიშვნა "ლოგიკური პროვაიდერი")

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

  • დაწყებული ერთხელ თვეში/კვირაში/დღეში

  • დამთავრებული მუდმივად (ყოველი commit-ის დროს)

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

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

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

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

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

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

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

ლოგიკური პროვაიდერები მთლიანად მუშაობენ Terraform-ის ლოგიკის ფარგლებში და ძალიან ხშირად არ ურთიერთობენ სხვა სერვისებთან, ასე რომ, ჩვენ შეგვიძლია ვიფიქროთ მათ სირთულეზე, როგორც O(1). ყველაზე გავრცელებული ლოგიკური პროვაიდერები მოიცავს random, local, terraform, null, time.

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

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

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

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

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

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

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

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

დარწმუნდით, რომ გესმით ძირითადი ცნებები - resource module, infrastructure module, და composition, რადგან ისინი გამოიყენება შემდეგ მაგალითებში.

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

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

  • 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-ისთვის მომდევნო თავში.