32-წუთიანი სამუშაო სესია იმაზე, როგორ აღვწეროთ სერვერები, ქსელები და მონაცემთა ბაზები ტექსტად, რომელსაც git-ში აკომიტებთ — რომ მთელი გარემო გახდეს ის, რისი დაგეგმვაც, განხილვაც და ხელახლა აგებაც შეგიძლიათ, და არა ხელით აწყობილი და ლოცვაზე დამყარებული რამ.
ყველა ღრუბლოვანი ანგარიში ერთნაირად იწყება: ვიღაც კონსოლში დააკლიკებს, აწყობს სერვერსა და მონაცემთა ბაზას და ეს მუშაობს. ექვსი თვის შემდეგ აღარავის ახსოვს ზუსტად, რას აკლიკებდა, სტეიჯინგის გარემო პროდაქშენს დაშორდა, ხოლო ნულიდან აღდგენა ერთი დღის არქეოლოგიაა. IaC ამ ყველაფერს აქცევს ფაილად, რომელსაც წაიკითხავთ, განიხილავთ და ხელახლა გაუშვებთ.
ერთი კონსოლის სესია ერთ უნიკალურ ფიფქს ქმნის. ერთი ფაილი კი იმდენ იდენტურ გარემოს, რამდენიც გჭირდებათ.
იდენტური გარემო წუთებში — dev, სტეიჯინგი, სარეზერვო რეგიონი — ერთი და იმავე წყაროდან.
ინფრასტრუქტურის ცვლილებები pull request-ის სახით მოდის. კოლეგა კითხულობს დიფს მანამ, სანამ ის პროდაქშენს შეეხება.
ყოველი ცვლილება კომიტია. ხედავთ, ვინ რა შეცვალა, როდის და რატომ — და ისევე დააბრუნებთ უკან, როგორც ნებისმიერ სხვა კოდს.
ფაილები თავად არის დოკუმენტაცია. აღარაა მოძველებული ვიკი, რომელიც აღწერს კონსოლს, რომელსაც არავინ ხსნის.
კომპიუტერს ორნაირად შეიძლება ვუთხრათ, რომ რაღაც ააგოს. ან ჩამოთვლით ზუსტ ნაბიჯებს თანმიმდევრობით (იმპერატიული), ან აღწერთ საბოლოო შედეგს და ნაბიჯებს ინსტრუმენტი თავად მოძებნის (დეკლარაციული). თითქმის ყველა თანამედროვე IaC დეკლარაციულია — და სწორედ ეს არჩევანი ხდის ხელახალ გაშვებას უსაფრთხოს.
ძრავა ადარებს სასურველს რეალურთან და მოქმედებს მხოლოდ სხვაობაზე — სწორედ ეს ხდის მეორე გაშვებას უსაფრთხოს.
აი, კითხვა, რომელიც ყველა დამწყებს აბნევს: თქვენი კოდი ამბობს "ერთი სერვერი", ღრუბელში კი სერვერი დგას — მაგრამ საიდან იცის ინსტრუმენტმა, რომ ეს სერვერი სწორედ თქვენი კოდის შექმნილია და არა სხვისი? პასუხია state: ჩანაწერი, რომელიც თქვენს კოდში არსებულ ყოველ რესურსს ღრუბელში არსებულ რეალურ ობიექტს უკავშირებს.
state არის საძიებო ცხრილი: თქვენს კოდში არსებული რესურსი web არის ღრუბლის ობიექტი i-0ab9.
ვიღაცამ სერვერი ხელით გაზარდა. შემდეგი plan შეუსაბამობას ამჩნევს და გთავაზობთ, რეალობა კოდს დაუბრუნოს.
import state-ში, რომ ინსტრუმენტმა თვალყურის დევნება დაიწყოს.საუკეთესო ჩვევა, რომელსაც IaC გაძლევთ: არაფერი იცვლება, სანამ არ წაიკითხავთ ზუსტ ანონსს იმისა, რა შეიცვლება. ძირითადი ციკლია plan (მშრალი გაშვება — მაჩვენე დიფი), შემდეგ კი apply (გააკეთე). სწორედ ეს ანონსი აქცევს "იმედია იმუშავებს"-ს განხილვად, მოსაწყენ დეპლოიდ.
ყოველდღიური ციკლი: write → init → plan → apply, ყოველ ცვლილებაზე გამეორებით. destroy კი ბოლოს ყველაფერს სუფთად ანგრევს.
რესურსი, რომელიც თქვენს კოდშია, მაგრამ ჯერ არ არსებობს. ინსტრუმენტი შექმნის მას.
რესურსი, რომელიც არსებობს, მაგრამ განსხვავდება. ყურადღება მიაქციეთ იმათ, რომლებიც ადგილზე რედაქტირების ნაცვლად ჩანაცვლდება — ეს მოცდენას ნიშნავს.
რესურსი, რომელიც კოდს აღარ სურს. ეს ხაზები ყველაზე ყურადღებით წაიკითხეთ — შემთხვევითმა destroy-მ მონაცემთა ბაზა შეიძლება წაშალოს.
როცა ერთი გარემო უკვე კოდში გაქვთ აღწერილი, მოგინდებათ მეორე, რომელიც თითქმის იგივეა. ფაილების კოპირება ხაფანგია — ახლა ყოველი შესწორება სამ ადგილას უნდა გააკეთოთ. მოდული ინფრასტრუქტურის ნაწილს ერთხელ ალაგებს და საშუალებას გაძლევთ, სხვადასხვა შემავალი პარამეტრით დაბეჭდოთ იგი.
root მოდული ერთმანეთს უკავშირებს შვილობილ მოდულებს; თითოეული შვილი ყველა გარემოში სხვადასხვა პარამეტრით გამოიყენება.
მოდული იღებს ცვლადებს (ზომა, რეგიონი, სახელი) და გამოაქვს შედეგები (მონაცემთა ბაზის ენდპოინტი), რომ გამომძახებლებმა ისინი ერთმანეთს დაუკავშირონ — ზუსტად როგორც ფუნქციის ხელმოწერა.
ერთი რესურსის შემომსაზღვრელი მოდული მხოლოდ ზედმეტ შუამავალ ფენას ამატებს. მიმართეთ მოდულს მაშინ, როცა რესურსების ჯგუფი მეორდება — და არა რეფლექსით.
Terraform / OpenTofu Registry-ს აქვს ბრძოლაში გამოცდილი მოდულები (VPC-ები, EKS კლასტერები). მიამაგრეთ ვერსია და წაიკითხეთ კოდი, სანამ პროდაქშენში ენდობით.
თითქოს სტანდარტული ოთახის ნახაზი — დახატეთ ერთხელ, შემდეგ კი ააშენეთ სამ სართულზე სხვადასხვა საღებავითა და ავეჯით. Kubernetes კლასტერის აწყობა კლასიკური ამოცანაა კარგად ტესტირებული მოდულისთვის და არა ხელით დაწერილი რესურსებისთვის.
ინსტრუმენტები ძირითადად ორ კითხვაზე იყოფა: სპეციალურ საკონფიგურაციო ენას წერთ თუ ნამდვილ საპროგრამო ენას, და ერთ ღრუბელზე ხართ მიბმული თუ ბევრზე. არცერთი არაა "საუკეთესო" — თითოეული სწორი არჩევანია სხვადასხვა ადგილას. აი, პატიოსანი კომპრომისები.
დეკლარაციული HCL. ინდუსტრიის ნაგულისხმევი არჩევანი პროვაიდერების ყველაზე დიდი ეკოსისტემით — მას თითქმის ნებისმიერი ღრუბლის ან SaaS-ის მართვა შეუძლია და არა მხოლოდ AWS-ის.
დადებითი — მრავალღრუბლოვანი, უზარმაზარი მოდულების რეესტრი, დეკლარაციული და წასაკითხად ადვილი; დე-ფაქტო სტანდარტი.
უარყოფითი — HCL ცალკე ენაა შეზღუდული ლოგიკით; რთული პირობები მოუხერხებელი ხდება.
აირჩიეთ, როცა გინდათ პორტატული, დეკლარაციული სტანდარტი ერთზე მეტი პროვაიდერისთვის — უსაფრთხო ნაგულისხმევი არჩევანი.
ინფრასტრუქტურას ზოგადი დანიშნულების ენაზე წერთ, ძრავა კი მაინც დეკლარაციულად მუშაობს — state, plan და apply, ზუსტად ისე, როგორც Terraform-ში.
დადებითი — ენის სრული ძალა: ციკლები, ფუნქციები, ტიპები, ტესტები, IDE-ის ავტოშევსება; შესანიშნავია რთული ლოგიკისთვის.
უარყოფითი — ეს ძალა სირთულეს იწვევს; ეკოსისტემა უფრო პატარაა; გუნდმა ენა უნდა იცოდეს.
აირჩიეთ, როცა ინფრას დეველოპერები ფლობენ და ნამდვილი კოდი უნდათ — აბსტრაქციები, უნიტ-ტესტები და საერთო ბიბლიოთეკები.
CloudFormation არის AWS-ის მშობლიური დეკლარაციული შაბლონები; CDK კი საშუალებას გაძლევთ, ნამდვილი კოდი დაწეროთ, რომელიც ამ შაბლონებს აგენერირებს. state-ს AWS თქვენ ნაცვლად ინახავს.
დადებითი — ღრმა, პირველივე დღიდან AWS ინტეგრაცია; AWS მართავს state-სა და როლბექებს; დამატებითი ინსტრუმენტები არ გჭირდებათ.
უარყოფითი — მხოლოდ AWS, სრული მიბმა; ნედლი შაბლონები სიტყვამრავალია; განახლებები შეიძლება ნელი იყოს.
აირჩიეთ, როცა სრულად AWS-ზე ხართ და გინდათ პირველი მხარის, სრულად მართული ინსტრუმენტი მესამე მხარის გარეშე.
Ansible ამოცანებზეა აგებული და იმპერატიულობისკენ იხრება (ნაბიჯების სია), თუმცა კარგი მოდულები იდემპოტენტურია. მისი ძლიერი მხარეა მანქანების კონფიგურაცია და არა ღრუბლოვანი რესურსების პროვიჟენინგი.
დადებითი — აგენტის გარეშე (მხოლოდ SSH), მარტივი YAML, შესანიშნავია პროგრამების დაყენებისა და კონფიგურაციისთვის.
უარყოფითი — სუსტია ღრუბლოვანი რესურსების სასიცოცხლო ციკლის მართვაში; არ აქვს Terraform-ის მსგავსი state/plan მოდელი.
აირჩიეთ სერვერის შიგნით კონფიგურაციისთვის — ხშირად Terraform-თან ერთად: ერთით ქმნით, მეორით აკონფიგურირებთ.
Terraform / OpenTofu და CloudFormation: თქვენ აცხადებთ საბოლოო შედეგს. უფრო ადვილი წასაკითხია, უფრო უსაფრთხოა ხელახლა გასაშვებად და ბუნებრივად ერგება ღრუბლოვანი რესურსების პროვიჟენინგს. სწორედ აქედან უნდა დაიწყოს გუნდების უმეტესობამ.
ნამდვილ ენებზე აგებული ინსტრუმენტები (Pulumi, CDK) და იმპერატიულები (Ansible) მეტ ძალასა და მოქნილობას გაძლევთ — იმის ფასად, რომ მეტი გზა გაქვთ ისეთი ჭკვიანური რამის დასაწერად, რომელსაც შემდეგი ადამიანი ვეღარ გაჰყვება. ძალას მაშინ მიმართეთ, როცა უბრალო საკონფიგურაციო ენა ნამდვილად ვერ გამოხატავს საჭიროს.
IaC მაშინ ამართლებს, როცა კოდი ჭეშმარიტების ერთადერთი წყაროა და პროდაქშენს ხელით არავინ არედაქტირებს. სამი პრაქტიკა მიგიყვანთ იქამდე: შეინახეთ state დისტანციურად და უსაფრთხოდ, სეკრეტები ფაილებს გარეთ დატოვეთ და ყველაფერი პაიპლაინში გაატარეთ, რომ ყოველი ცვლილება განიხილებოდეს.
შეინახეთ state საერთო ბექენდში — S3 ბაკეტში, Azure Blob-ში, GCS-ში ან მართულ სერვისში, როგორიცაა HCP Terraform — ლოკით, რომ ორი apply ერთდროულად ვერ გაეშვას, და ვერსირებით, რომ აღდგენა შეძლოთ. არასოდეს დააკომიტოთ state git-ში.
არ ჩასვათ პაროლები .tf ფაილებში. წამოიღეთ ისინი სეკრეტების მენეჯერიდან (Vault, AWS Secrets Manager) გაშვების დროს. გახსოვდეთ, state-ს შეუძლია სეკრეტები ღია ტექსტით შეინახოს — ამიტომ დაშიფრეთ ბექენდი და შეზღუდეთ, ვის შეუძლია მისი წაკითხვა.
გაუშვით plan ავტომატურად ყოველ pull request-ზე, გამოაქვეყნეთ დიფი განსახილველად და გაუშვით apply მხოლოდ მერჯის შემდეგ — არასოდეს ლეპტოპიდან. პაიპლაინის მექანიკისთვის იხილეთ Developer Tooling.
pull request-ზე განიხილება გეგმა; მერჯი კი apply-ს უშვებს. პროდაქშენს პირდაპირ ადამიანი არ ეხება.
ხუთი სწრაფი კითხვა დეკლარაციულ IaC-ზე, state-ზე, დრიფტზე, plan/apply-ზე და ინსტრუმენტების რუკაზე — მყისიერი პასუხი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ისრებით ან სქროლით · ბიბლიოთეკაში დაბრუნება