წარმოგიდგენთ პროგრამირებადი AWS სადესანტო ზონას Terraform მოდულში

Სალამი ყველას! დეკემბერში OTUS იწყებს ახალ კურსს - Cloud Solution Architecture. ამ კურსის დაწყების მოლოდინში გაგიზიარებთ საინტერესო მასალის თარგმანს თემაზე.

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

ხუთ წელზე მეტი ხნის განმავლობაში, ჩვენი გუნდი Mitoc Group-ში დაუღალავად მუშაობდა, რათა დაეხმარა მსხვილ ორგანიზაციებს ციფრულად გარდაქმნას და შექმნას ან გადაიტანოს მათი ციფრული კვალი AWS ღრუბელში. სხვა სიტყვებით რომ ვთქვათ, AWS-ის ჩვენი მეგობრების ციტირება: „ჩვენი მომხმარებლები ხელახლა იგონებენ თავს AWS-ით“. ეს არის დაუსრულებელი მცდელობა ხელახლა გამოგონება და გამარტივდეს მექანიკა თავად მომხმარებლების სახელით და AWS შესანიშნავ საქმეს აკეთებს რთული პრობლემების გადაჭრაში ადვილად შესასწავლი გადაწყვეტილებებით.

AWS სადესანტო ზონა (წყარო)

რა არის AWS სადესანტო ზონა?

ოფიციალური წყაროს ინფორმაციით:

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

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

ასე რომ, ჩვენ ვკითხეთ საკუთარ თავს, რატომ არ ავაშენოთ AWS Landing Zone-ის მთელი გადაწყვეტა Terraform-ში? შეგვიძლია ამის გაკეთება და გადაჭრის თუ არა ის ჩვენს მომხმარებლებს პრობლემებს? სპოილერი: იქნება და უკვე გადაწყვეტს! 🙂

როდის არ უნდა გამოიყენოთ AWS Landing Zone?

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

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

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

სტრატეგიის დადგენისას, წარმატებული AWS Landing Zone მომხმარებლები აქტიურად ამახვილებენ ყურადღებას შემდეგზე:

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

წარმოგიდგენთ Terraform მოდულს AWS სადესანტო ზონისთვის

რამდენიმეთვიანი მძიმე შრომის შემდეგ, მოხარული ვარ წარმოგიდგინოთ ტერაფორმული მოდული AWS სადესანტო ზონისთვის. კოდის კოდი ინახება GitHub-ზე და სტაბილური გამოშვების ვერსიები გამოქვეყნებულია Terraform Module Registry-ზე.

დასაწყებად, უბრალოდ ჩართეთ main.tf თქვენს კოდს:

module "landing_zone" {
  source     = "TerraHubCorp/landing-zone/aws"
  version    = "0.0.6"
  root_path  = "${path.module}"
  account_id = "${var.account_id}"
  region     = "${var.region}"
  landing_zone_components = "${var.landing_zone_components}"
}

შენიშვნა: დარწმუნდით, რომ ჩართეთ variables.tf და ყველაფერი, რაც შეიძლება დაგჭირდეთ outputs.tf.

გასაგებად გასაადვილებლად, ჩვენ დავამატეთ ნაგულისხმევი მნიშვნელობები terraform.tfvars:

account_id = "123456789012"
region = "us-east-1"
landing_zone_components = {
  landing_zone_pipeline_s3_bucket = "s3://terraform-aws-landing-zone/mycompany/landing_zone_pipeline_s3_bucket/default.tfvars"
  [...]
}

ეს ნიშნავს, რომ ამ მოდულის გამოყენებისას terraform დაგჭირდებათ:

1. შეცვალეთ მნიშვნელობები account_id и region საკუთარზე, რომელიც შეესაბამება AWS ორგანიზაციის მონაცემებს;
2. შეცვალეთ მნიშვნელობები landing_zone_components ისინი, რომლებიც ემთხვევა თქვენს AWS Landing Zone გამოყენების შემთხვევას;
3. შეცვალოს s3://terraform-aws-landing-zone/mycompany თქვენს ბლოკში S3 და გასაღების პრეფიქსი S3სადაც შეინახავთ ფაილებს .tfvars (ან ფაილების აბსოლუტური გზა .tfvars თქვენს ადგილობრივ საცავში).

ამ მოდულს შეიძლება ჰქონდეს ათობით, ასობით ან ათასობით განთავსებადი კომპონენტი, მაგრამ ყველა მათგანი არ უნდა იყოს ან განლაგებული იქნება. გაშვების დროს, კომპონენტები, რომლებიც არ არიან ცვლადი რუკის ნაწილი landing_zone_components იგნორირებული იქნება.

დასკვნა

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

Სულ ეს არის. ველოდებით თქვენს კომენტარებს და გეპატიჟებით უფასო ვებინარი რომლის ფარგლებშიც ჩვენ მოდით შევისწავლოთ Cloud Landing Zone დომენის არქიტექტურის დიზაინი და განვიხილოთ ძირითადი დომენების არქიტექტურული ნიმუშები.

წყარო: www.habr.com