ინფრასტრუქტურის აღწერა Terraform-ში მომავლისთვის. ანტონ ბაბენკო (2018)

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

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

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

Github-ზე AWS-ისთვის Terraform საზოგადოების მოდულების კოლექციის მართვის სამი წლის შემდეგ და წარმოებაში Terraform-ის გრძელვადიანი შენარჩუნების შემდეგ, ანტონ ბაბენკო მზადაა გაგიზიაროთ თავისი გამოცდილება: როგორ დავწეროთ TF მოდულები ისე, რომ მომავალში არ დააზარალებს.

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

პასუხისმგებლობის შეზღუდვის განაცხადი: აღვნიშნავ, რომ ეს ანგარიში 2018 წლის ნოემბრით არის დათარიღებული - უკვე 2 წელი გავიდა. ანგარიშში განხილული Terraform 0.11 ვერსია აღარ არის მხარდაჭერილი. ბოლო 2 წლის განმავლობაში გამოვიდა 2 ახალი გამოცემა, რომელიც შეიცავს უამრავ სიახლეს, გაუმჯობესებას და ცვლილებას. გთხოვთ ყურადღება მიაქციოთ ამას და შეამოწმოთ დოკუმენტაცია.

ბმულები:

• ტერაფორმი-საზოგადოება-მოდულები + terraform-aws-modules
• antonbabenko/pre-commit-terraform — ავტომატური ფორმატირების კოდი და დოკუმენტაცია
• antonbabenko/terrapin - Terraform მოდულების გენერატორი (WIP)
• antonbabenko/modules.tf-lambda - Terraform კოდის გენერატორი ვიზუალური დიაგრამებიდან (WIP)
• www.terraform-best-practices.com
• medium.com/@anton.babenko (ახალი პოსტები ჩემს პირად ვებსაიტზე www.antonbabenko.com/)
• @antonbabenko - Twitter და სხვადასხვა Slacks-ის თაიგული

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

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

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

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

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

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

მე ვარ უკრაინიდან. მრავალი წელია ვცხოვრობ ნორვეგიაში.

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

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

როგორც აღვნიშნე, მე ვარ Terraform AWS მოდულების მთავარი შემსრულებელი, რომელიც არის ერთ-ერთი უდიდესი საცავი GitHub-ზე, სადაც ჩვენ ვმასპინძლობთ მოდულებს ყველაზე გავრცელებული ამოცანებისთვის: VPC, Autoscaling, RDS.

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

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

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

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

ამ შემთხვევაში ჩვენ განვსაზღვრავთ "aws_region".

შემდეგ ჩვენ აღვწერთ რა რესურსების შექმნა გვინდა.

ჩვენ ვატარებთ რამდენიმე ბრძანებას, კერძოდ, „terraform init“ დამოკიდებულებების და პროვაიდერების ჩატვირთვის მიზნით.

და ჩვენ ვასრულებთ ბრძანებას "terraform application", რათა შევამოწმოთ, შეესაბამება თუ არა მითითებული კონფიგურაცია ჩვენს მიერ შექმნილ რესურსებს. ვინაიდან აქამდე არაფერი შეგვიქმნია, Terraform გვაიძულებს შევქმნათ ეს რესურსები.

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

ასევე არსებობს რამდენიმე მსგავსი კომუნალური პროგრამა. ბევრ თქვენგანს, ვინც ამაზონს იყენებს, იცის AWS CloudFormation ან Google Cloud Deployment Manager ან Azure Resource Manager. თითოეულ მათგანს აქვს გარკვეული სახის დანერგვა რესურსების მართვისთვის თითოეულ ამ საჯარო ღრუბლოვან პროვაიდერში. Terraform განსაკუთრებით სასარგებლოა, რადგან ის საშუალებას გაძლევთ მართოთ 100-ზე მეტი პროვაიდერი. (Უფრო ვრცლად აქ)

მიზნები, რომლებსაც Terraform თავიდანვე ახორციელებდა:

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

2014 წელს სიტყვა „პროგნოზირებადი“ ამ კონტექსტში ძალიან უჩვეულოდ ჟღერდა.

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

• თქვენ შეგიძლიათ გამოიყენოთ 120-ზე მეტი პროვაიდერი, რომ მართოთ ყველაფერი, რაც გსურთ.
• მაგალითად, შეგიძლიათ გამოიყენოთ Terraform GitHub საცავებზე წვდომის აღსაწერად.
• თქვენ შეგიძლიათ შექმნათ და დახუროთ შეცდომები Jira-ში.
• თქვენ შეგიძლიათ მართოთ New Relic მეტრიკა.
• თუ ნამდვილად გსურთ, შეგიძლიათ შექმნათ ფაილები dropbox-ში.

ეს ყველაფერი მიიღწევა Terraform პროვაიდერების გამოყენებით, რომლებსაც აქვთ ღია API, რომელიც შეიძლება აღწერილი იყოს Go-ში.

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

და ყველაფერი შესანიშნავია, თქვენ გაქვთ ფაილი, რომელიც ქმნის VPC-ს.

თუ გსურთ შექმნათ VPC, მაშინ მიუთითეთ დაახლოებით ეს 12 ხაზი. აღწერეთ რომელ რეგიონში გსურთ შექმნათ, IP მისამართების რომელი cidr_block გამოიყენოთ. Სულ ეს არის.

ბუნებრივია, პროექტი თანდათან გაიზრდება.

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

მოდით შევხედოთ შემდეგ მაგალითს.

თქვენ თანდათან ამატებთ internet_gateway-ს, რადგან გსურთ თქვენი VPC-ის რესურსებს ჰქონდეს ინტერნეტთან წვდომა. ეს კარგი იდეაა.

შედეგი არის ეს main.tf:

ეს არის main.tf-ის ზედა ნაწილი.

ეს არის main.tf-ის ქვედა ნაწილი.

შემდეგ დაამატეთ ქვექსელი. იმ დროისთვის, როდესაც გსურთ დაამატოთ NAT კარიბჭეები, მარშრუტები, მარშრუტიზაციის ცხრილები და სხვა ქვექსელები, თქვენ არ გექნებათ 38 ხაზი, მაგრამ დაახლოებით 200-300 ხაზი.

ანუ თქვენი main.tf ფაილი თანდათან იზრდება. და საკმაოდ ხშირად ადამიანები ყველაფერს ერთ ფაილში ათავსებენ. 10-20 Kb გამოჩნდება main.tf. წარმოიდგინეთ, რომ 10-20 Kb არის ტექსტური შინაარსი. და ყველაფერი ყველაფერთან არის დაკავშირებული. ამაზე მუშაობა თანდათან რთულდება. 10-20 Kb არის კარგი მომხმარებლის შემთხვევა, ზოგჯერ მეტი. და ხალხი ყოველთვის არ ფიქრობს, რომ ეს ცუდია.

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

• კოდი იზრდება.
• რესურსებს შორის დამოკიდებულებაც იზრდება.

და ჩვენ გვაქვს დიდი, დიდი მოთხოვნილება. ჩვენ გვესმის, რომ ასე ცხოვრება აღარ შეგვიძლია. ჩვენი კოდი ხდება უზარმაზარი. 10-20 Kb, რა თქმა უნდა, არც თუ ისე დიდია, მაგრამ ჩვენ ვსაუბრობთ მხოლოდ ქსელის სტეკზე, ანუ თქვენ მხოლოდ დაამატეთ ქსელის რესურსები. ჩვენ არ ვსაუბრობთ Application Load Balancer-ზე, განლაგების ES კლასტერზე, Kubernetes-ზე და ა.შ., სადაც 100 Kb ადვილად შეიძლება ჩაერთოს. თუ ამ ყველაფერს ჩაწერთ, ძალიან მალე გაიგებთ, რომ Terraform გთავაზობთ Terraform მოდულებს.

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

ასე რომ, ჩვენ ვცდილობთ გავიგოთ, როგორ მოვახდინოთ ჩვენი 10-20-30 Kb კოდის ოპტიმიზაცია. თანდათან ვაცნობიერებთ, რომ რაღაც მოდული უნდა გამოვიყენოთ.

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

რესურსის მოდულის მაგალითი.

რესურსის მოდულის გამოძახებისას ვაზუსტებთ, რომელი გზიდან უნდა ჩავტვირთოთ მისი შინაარსი.

ჩვენ მიუთითეთ რომელი ვერსიის ჩამოტვირთვა გვინდა.

ჩვენ იქ არგუმენტების სიმრავლეს ვატარებთ. Სულ ეს არის. ეს არის ყველაფერი, რაც უნდა ვიცოდეთ ამ მოდულის გამოყენებისას.

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

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

მომხმარებელმა არ უნდა იცოდეს, როგორ მზადდება შიგნით.

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

შემდეგ მე გაჩვენებთ ამის რამდენიმე მაგალითს.

ინფრასტრუქტურის მოდული იწოდება ზუსტად იგივე გზით.

მითითებულია წყარო, საიდანაც უნდა ჩამოტვირთოთ შინაარსი.

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

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

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

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

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

Terraform Registry - https://registry.terraform.io/

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

ამ მაგალითში ვიღაც მოვიდა თქვენთან და თქვა: „მინდა შევძლო მონაცემთა ბაზის მართვა. შექმენით მოდული, რათა შევქმნა მონაცემთა ბაზა." ადამიანმა არ იცის არც Amazon-ის და არც Terraform-ის განხორციელების დეტალები. ის უბრალოდ ამბობს: "მსურს ვმართო MSSQL." ანუ, ჩვენ ვგულისხმობთ, რომ ის გამოიძახებს ჩვენს მოდულს, გადასცემს ძრავის ტიპს და მიუთითებს დროის ზონას.

და ადამიანმა არ უნდა იცოდეს, რომ ჩვენ შევქმნით ორ განსხვავებულ რესურსს ამ მოდულის შიგნით: ერთი MSSQL-სთვის, მეორე ყველა დანარჩენისთვის, მხოლოდ იმიტომ, რომ Terraform 0.11-ში არ შეგიძლიათ მიუთითოთ დროის ზონის მნიშვნელობები, როგორც სურვილისამებრ.

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

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

მაგრამ პრობლემა ისაა, თუ როგორ უწოდებს Terraform ამ მოდულებს. მაგალითად, თუ თქვენ დარეკავთ მოდულს თითოეული ინდივიდუალური მომხმარებლის შესაქმნელად, Terraform ჯერ ჩატვირთავს მთელ საცავს და შემდეგ გადავა საქაღალდეში, სადაც ეს კონკრეტული მოდული მდებარეობს. ამ გზით თქვენ ყოველ ჯერზე ჩამოტვირთავთ ერთ მეგაბაიტს. თუ თქვენ მართავთ 100 ან 200 მომხმარებელს, მაშინ ჩამოტვირთავთ 100 ან 200 მეგაბაიტს და შემდეგ გადადით იმ საქაღალდეში. ასე რომ, ბუნებრივია, თქვენ არ გსურთ ჩამოტვირთოთ ბევრი პერსონალი ყოველ ჯერზე, როდესაც დააჭირეთ "Terraform init".

https://github.com/mbtproject/mbt

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

რა თქმა უნდა, ბევრი უარყოფითი მხარეა. მაგალითად, თქვენ არ შეგიძლიათ გამოიყენოთ ვერსიები. და ამით ზოგჯერ რთულია ცხოვრება.

მეორე გამოსავალი. თუ თქვენ გაქვთ ბევრი ქვემოდული და უკვე გაქვთ გარკვეული სახის მილსადენი, მაშინ არის MBT პროექტი, რომელიც საშუალებას გაძლევთ შეაგროვოთ მრავალი განსხვავებული პაკეტი მონორეპოზიტორიდან და ატვირთოთ ისინი S3-ზე. ეს ძალიან კარგი გზაა. ამრიგად, iam-user-1.0.0.zip ფაილი იწონის მხოლოდ 1 კბ-ს, რადგან ამ რესურსის შექმნის კოდი ძალიან მცირეა. და ის იმუშავებს ბევრად უფრო სწრაფად.

მოდით ვისაუბროთ იმაზე, რისი გამოყენება შეუძლებელია მოდულებში.

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

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

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

ბოროტება ის არის, რომ თქვენ ყოველთვის არ აკონტროლებთ, როდის დაიწყება ეს პროვაიდერი, პირველ რიგში. და მეორეც, თქვენ არ აკონტროლებთ რას ნიშნავს aws ec2, ანუ ახლა ვსაუბრობთ Linux-ზე თუ Windows-ზე. ასე რომ, თქვენ არ შეგიძლიათ დაწეროთ ის, რაც ერთნაირად იმუშავებს სხვადასხვა ოპერაციულ სისტემაზე ან მომხმარებლის სხვადასხვა შემთხვევისთვის.

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

სინამდვილეში, დიახ, ამაში ცუდი არაფერია. მაგრამ ფაქტიურად მალე მიხვდებით, რომ ეს ადგილობრივი-exec არ არსებობს, მაგალითად, launch_configuration-ში.

და როდესაც იყენებთ launch_configuration-ს და გსურთ შექმნათ ავტოსკალირების ჯგუფი ერთი ინსტანციიდან, მაშინ launch_configuration-ში არ არსებობს „პროვაიდერის“ ცნება. არსებობს "მომხმარებლის მონაცემების" კონცეფცია.

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

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

და ამისათვის ყველაზე სწორ რესურსს ეწოდება null_resource. Null_resource არის მოჩვენებითი რესურსი, რომელიც რეალურად არასოდეს იქმნება. ის არაფერს ეხება, არც API-ს, არც ავტოსკალირებას. მაგრამ ის საშუალებას გაძლევთ აკონტროლოთ, როდის გაუშვით ბრძანება. ამ შემთხვევაში, ბრძანება გაშვებულია შექმნის დროს.

ლინკები http://bit.ly/common-traits-in-terraform-modules

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

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

ესენია:

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

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

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

ეს არის დოკუმენტაციის ნაცრისფერი ნაწილი. შეიძლება ახლა ფიქრობთ: „რაღაც გაუგებარია. არ არის დარწმუნებული." მაგრამ ვნახოთ ექვს თვეში.

ახლა მოდით ვისაუბროთ იმაზე, თუ როგორ გამოვიძახოთ ეს მოდულები.

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

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

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

ბევრი დროა, მაგალითად, 5 წუთი. ზოგისთვის ეს დიდი დროა. მე მინახავს შემთხვევები, როდესაც ამას 15 წუთი დასჭირდა. AWS API-მ 15 წუთი დახარჯა იმის გარკვევაში, თუ რა ხდებოდა თითოეული რესურსის მდგომარეობასთან დაკავშირებით. ეს არის ძალიან დიდი ტერიტორია.

და, ბუნებრივია, დაკავშირებული პრობლემა გაჩნდება, როდესაც გსურთ შეცვალოთ რაღაც ერთ ადგილას, შემდეგ დაელოდოთ 15 წუთს და ეს გაძლევს გარკვეული ცვლილებების ტილოს. გადააფურთხე, დაწერე „დიახ“ და რაღაც არასწორედ წარიმართა. ეს ძალიან რეალური მაგალითია. Terraform არ ცდილობს დაგიფაროს პრობლემებისგან. ანუ დაწერე რაც გინდა. იქნება პრობლემები - თქვენი პრობლემები. მაშინ როცა Terraform 0.11 არანაირად არ ცდილობს დაგეხმაროთ. 0.12-ში არის გარკვეული საინტერესო ადგილები, რომლებიც საშუალებას გაძლევთ თქვათ: "ვასია, შენ ძალიან გინდა ეს, შეგიძლია გონს მოხვიდე?"

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

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

ვის აქვს ეს ყველაფერი ერთ ადგილას? ერთი, ორი, სამი ადამიანი, ანუ ვიღაც იყენებს.

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

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

თუ რაღაც შეიცვალა სტეკის VPC-ში და გინდოდათ ამ ცვლილებების გამოყენება EC2-ზე, ანუ გინდოდათ ავტოსკალირების ჯგუფის განახლება, რადგან გქონდათ ახალი ქვექსელი, მაშინ მე ვუწოდებ ამ სახის დამოკიდებულების ორკესტრირებას. არსებობს რამდენიმე გამოსავალი: ვინ რას იყენებს?

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

როგორ მოგწონთ ეს გადაწყვეტილება? ვინმეს სჯერა რომ ეს მაგარი გამოსავალია? მე ვხედავ ღიმილს, აშკარად ეჭვები შემოიპარა.

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

ერთ მოხსენებაში მათ მითხრეს: „არა, ეს არ იმუშავებს“. საქმე იმაშია, რომ არ უნდა იმუშაოს. მიუხედავად იმისა, რომ ძალიან შთამბეჭდავად გამოიყურება, როდესაც შეგიძლიათ Terraform-ის გაშვება Terraform-დან და შემდეგ Terraform-იდან, ეს არ უნდა გააკეთოთ. Terraform ყოველთვის უნდა დაიწყოს ძალიან მარტივად.

https://github.com/gruntwork-io/terragrunt/

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

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

ტიპიური Terraform კონფიგურაციის ფაილი ასე გამოიყურება.

თქვენ მიუთითეთ რომელი კონკრეტული მოდულის დარეკვა გსურთ.

რა დამოკიდებულებები აქვს მოდულს?

და რა არგუმენტებს იღებს ეს მოდული. ეს ყველაფერია რაც უნდა ვიცოდეთ Terragrunt-ის შესახებ.

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

ასე რომ, ორკესტრირება არის Terragrunt. არის სხვა ვარიანტებიც.

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

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

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

და მხარი დაუჭირა ახალი რესურსების შექმნას ბლოკის რესურსის გამოყენებით.

გამომავალზე ჩვენ ყოველთვის ვაბრუნებთ გამომავალი ID-ს იმისდა მიხედვით, თუ რა იყო გამოყენებული.

მეორე ძალიან მნიშვნელოვანი პრობლემა Terraform 0.11-ში არის სიებთან მუშაობა.

სირთულე ის არის, რომ თუ ჩვენ გვაქვს მომხმარებელთა ასეთი სია.

და როდესაც ჩვენ ვქმნით ამ მომხმარებლებს ბლოკის რესურსის გამოყენებით, მაშინ ყველაფერი კარგად მიდის. ჩვენ გავდივართ მთელ სიას, ვქმნით ფაილს თითოეულისთვის. Ყველაფერი კარგადაა. და შემდეგ, მაგალითად, user3, რომელიც შუაშია, უნდა მოიხსნას აქედან, შემდეგ ყველა რესურსი, რომელიც მის შემდეგ შეიქმნა, ხელახლა იქმნება, რადგან ინდექსი შეიცვლება.

სიებთან მუშაობა სახელმწიფოებრივ გარემოში. რა არის სახელმწიფოებრივი გარემო? ეს არის სიტუაცია, როდესაც ამ რესურსის შექმნისას იქმნება ახალი მნიშვნელობა. მაგალითად, AWS Access Key ან AWS Secret Key, ანუ როდესაც ჩვენ ვქმნით მომხმარებელს, ვიღებთ ახალ წვდომას ან საიდუმლო კლავიშს. და ყოველ ჯერზე, როდესაც ჩვენ წაშლით მომხმარებელს, ამ მომხმარებელს ექნება ახალი გასაღები. მაგრამ ეს არ არის ფენგ შუი, რადგან მომხმარებელს არ სურს ჩვენთან მეგობრობა, თუ ჩვენ შევქმნით მისთვის ახალ მომხმარებელს ყოველ ჯერზე, როცა ვინმე ტოვებს გუნდს.

ეს არის გამოსავალი. ეს არის კოდი დაწერილი Jsonnet-ში. Jsonnet არის Google-ის შაბლონის ენა.

ეს ბრძანება საშუალებას გაძლევთ მიიღოთ ეს შაბლონი და გამომავალი სახით დააბრუნებს json ფაილს, რომელიც შედგენილია თქვენი შაბლონის მიხედვით.

შაბლონი ასე გამოიყურება.

Terraform გაძლევთ საშუალებას იმუშაოთ როგორც HCL-თან, ასევე Json-თან ერთნაირად, ასე რომ, თუ თქვენ გაქვთ Json-ის გენერირების შესაძლებლობა, მაშინ შეგიძლიათ გადაიტანოთ იგი Terraform-ში. ფაილი გაფართოებით .tf.json წარმატებით ჩამოიტვირთება.

და შემდეგ ჩვენ ვმუშაობთ მასთან, როგორც ყოველთვის: terraform init, terramorm application. და ჩვენ ვქმნით ორ მომხმარებელს.

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

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

მაგრამ ჩნდება სიტუაციები, როდესაც გვინდა გავაფართოვოთ Terraform და გამოვიძახოთ რაიმე ბრძანება რაღაცის დასრულების შემდეგ.

პირველი გზა. ჩვენ ვქმნით გამოსავალს, სადაც ვწერთ ამ ბრძანებას.

შემდეგ ჩვენ ვუწოდებთ ამ ბრძანებას shell terraform გამომავალიდან და მივუთითებთ ჩვენთვის საჭირო მნიშვნელობას. ამრიგად, ბრძანება შესრულებულია ყველა ჩანაცვლებული მნიშვნელობით. ძალიან კომფორტულია.

მეორე გზა. ეს არის null_resource-ის გამოყენება, რაც დამოკიდებულია ჩვენს ინფრასტრუქტურაში არსებულ ცვლილებებზე. ჩვენ შეგვიძლია დავარქვათ იგივე ლოკალური exe, როგორც კი ზოგიერთი რესურსის ID შეიცვლება.

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

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

არის რამდენიმე რამ, რისი თავიდან აცილებასაც გირჩევთ.

დასაწყისისთვის, მოერიდეთ ყველა არასაიდუმლო არგუმენტს Terraform გეგმის ან Terraform CLI-ის შიგნით. ეს ყველაფერი შეიძლება ჩაიწეროს ან tfvars ფაილში ან გარემოს ცვლადში.

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

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

ასევე, არ არის საჭირო პარალელურობის შეზღუდვა და გაზრდა. თუ მე მაქვს 150 რესურსი და მინდა გავზარდო ამაზონის პარალელიზმი ნაგულისხმევი 10-დან 100-მდე, მაშინ დიდი ალბათობით რაღაც არასწორედ მოხდება. ან შეიძლება ახლა კარგად წავიდეს, მაგრამ როცა Amazon ამბობს, რომ ძალიან ბევრ ზარს აკეთებ, გაგიჭირდება.

Terraform შეეცდება გადატვირთოს ამ პრობლემების უმეტესობა, მაგრამ თქვენ თითქმის ვერაფერს მიაღწევთ. პარალელიზმი=1 არის მნიშვნელოვანი გამოსაყენებელი, თუ შეგხვდებათ შეცდომა AWS API-ში ან Terraform-ის პროვაიდერში. შემდეგ თქვენ უნდა მიუთითოთ: parallelism=1 და დაელოდოთ სანამ Terraform დაასრულებს ერთ ზარს, შემდეგ მეორეს, შემდეგ მესამეს. ის მათ სათითაოდ გაუშვებს.

ადამიანები ხშირად მეკითხებიან: „რატომ ვთვლი, რომ Terraform სამუშაო სივრცე ბოროტია? ვფიქრობ, ინფრასტრუქტურის, როგორც კოდის პრინციპი არის იმის დანახვა, თუ რა ინფრასტრუქტურა შეიქმნა და რა ღირებულებებით.

სამუშაო ადგილები მომხმარებლების მიერ არ შექმნილა. ეს არ ნიშნავს იმას, რომ მომხმარებლებმა დაწერეს GitHub საკითხებში, რომ ჩვენ ვერ ვიცხოვრებთ Terraform სამუშაო სივრცის გარეშე. არა ასე არა. Terraform Enterprise არის კომერციული გადაწყვეტა. Terraform–მა HashiCorp–დან გადაწყვიტა, რომ გვჭირდებოდა სამუშაო ადგილები, ამიტომ გავუშვით. მე ბევრად უფრო ადვილია მისი ცალკე საქაღალდეში მოთავსება. შემდეგ იქნება ცოტა მეტი ფაილი, მაგრამ ეს უფრო ნათელი იქნება.

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

მოხსენების თემა დაიწერა "მომავლისთვის". ამაზე ძალიან მოკლედ ვისაუბრებ. სამომავლოდ, ეს ნიშნავს, რომ 0.12 მალე გამოვა.

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

მაგრამ! თუ უფრო და უფრო მარტივად წერთ, მზა მოდულების და მესამე მხარის გადაწყვეტილებების გამოყენებით, მაშინ არ მოგიწევთ ლოდინი და იმედი, რომ მოვა 0.12 და გამოგისწორებთ ყველაფერს.

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

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

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

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

ანტონ, მადლობა მოხსენებისთვის! მე მქვია ვალერი. ნება მომეცით დავსვა პატარა ფილოსოფიური კითხვა. არის, პირობითად, უზრუნველყოფა, არის განლაგება. უზრუნველყოფა ქმნის ჩემს ინფრასტრუქტურას, განლაგებისას ჩვენ ვავსებთ მას რაიმე სასარგებლოთ, მაგალითად, სერვერებით, აპლიკაციებით და ა.შ. და ჩემი აზრით, Terraform უფრო პროვიაჟირებისთვისაა, ხოლო Ansible უფრო განლაგებისთვის, რადგან Ansible ასევე არის ფიზიკური ინფრასტრუქტურისთვის. საშუალებას გაძლევთ დააინსტალიროთ nginx, Postgres. მაგრამ ამავე დროს, Ansible, როგორც ჩანს, საშუალებას იძლევა უზრუნველყოს, მაგალითად, Amazon ან Google რესურსები. მაგრამ Terraform ასევე გაძლევთ საშუალებას განათავსოთ გარკვეული პროგრამული უზრუნველყოფა მისი მოდულების გამოყენებით. თქვენი აზრით, არის თუ არა რაიმე სახის საზღვარი, რომელიც გადის Terraform-სა და Ansible-ს შორის, სად და რისი გამოყენება ჯობია? ან, მაგალითად, გგონიათ, რომ Ansible უკვე ნაგავია, ყველაფერში უნდა სცადოთ Terraform-ის გამოყენება?

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

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

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

ადამიანები ორივეს თანაბარი წარმატებით იყენებენ. მეჩვენება, რომ Ansible-ში დინამიური ინვენტარი მოსახერხებელია, თუ ავტოსკალირების ჯგუფზე არ არის საუბარი. იმის გამო, რომ ავტოსკალირების ჯგუფში ჩვენ უკვე გვაქვს საკუთარი ინსტრუმენტარიუმი, რომელსაც ეწოდება launch_configuration. launch_configuration-ში ჩვენ ჩავწერთ ყველაფერს, რაც უნდა გაშვებულიყო ახალი რესურსის შექმნისას. ამიტომ, ამაზონთან, დინამიური ინვენტარის გამოყენება და Terraform ts ფაილის წაკითხვა, ჩემი აზრით, ზედმეტია. და თუ იყენებთ სხვა ინსტრუმენტებს, სადაც არ არის „ავტოსკალირების ჯგუფის“ კონცეფცია, მაგალითად, იყენებთ DigitalOcean ან სხვა პროვაიდერს, სადაც არ არის ავტოსკალირების ჯგუფი, მაშინ თქვენ მოგიწევთ ხელით გაიყვანოთ API, იპოვოთ IP მისამართები, შექმნათ. დინამიური ინვენტარის ფაილი და Ansible უკვე გაივლის მასში. ანუ ამაზონისთვის არის launch_configuration და სხვა ყველაფრისთვის არის დინამიური ინვენტარი.

წყარო: www.habr.com