შაბლონები Terraform-ში ქაოსთან და სახელმძღვანელო რუტინასთან საბრძოლველად. მაქსიმ კოსტრიკინი (იქსტენსი)

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

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

ვიდეო:

40 წლის ვარ, 20 წელია IT სფეროში ვარ. Ixtens-ში 12 წელია ვმუშაობ. ჩვენ დაკავებული ვართ ელექტრონული კომერციით ორიენტირებული განვითარებით. და მე უკვე 5 წელია ვვარჯიშობ DevOps-ის პრაქტიკას.

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

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

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

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

ჩამოვიდნენ დეველოპერები და დაიწყეს ინფრასტრუქტურის კოდის შექმნა.

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

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

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

მაგალითად, ჩვენ გვჭირდება ვირტუალური მანქანა. ჩვენ აღვწერთ და დავამატებთ რამდენიმე საჭირო პარამეტრს.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

სად შემიძლია მონაცემების მიღება? JSON ფაილი. Terraform საშუალებას გაძლევთ დაწეროთ ინფრასტრუქტურა არა მხოლოდ hcl-ში (HashiCorp Configuration Language), არამედ JSON-ში.

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

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

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

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

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

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

ახლა ცოტა ტესტის შესახებ. რა შეგიძლიათ შეამოწმოთ Terraform-ში? ალბათ ბევრია შესაძლებელი, მაგრამ ამ 4 რამეზე ვისაუბრებ.

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

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

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

პარალელი ძალიან მაგარი რამეა, გამოიყენე.

მაგრამ ყოველ ჯერზე, როცა Terraform ინიციალიზდება, ის მიდის HashiCorp-ში და ეკითხება: „რა არის მოდულის უახლესი ვერსიები? და დანამატი, რომელიც მე მაქვს ქეშში – სწორია თუ არასწორი?” და ეს შენელდა ყოველ ნაბიჯზე.

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

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

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

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

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

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

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

გეგმა საკმაოდ ძვირია. ამას დრო სჭირდება, რადგან Terraform მიდის ამაზონში და ეკითხება: „ეს შემთხვევა ჯერ კიდევ არსებობს? აქვს თუ არა ამ ავტოსკალას ზუსტად იგივე პარამეტრები?” და ამის დასაჩქარებლად, შეგიძლიათ გამოიყენოთ ისეთი პარამეტრი, როგორიცაა refresh=false. ეს ნიშნავს, რომ Terraform ჩამოტვირთავს მდგომარეობას S3-დან. და დაიჯერებს, რომ სახელმწიფო ზუსტად დაემთხვევა იმას, რაც ამაზონშია.

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

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

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

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

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

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

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

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

შემდეგი, რაზეც მსურს ვისაუბრო, არის Terraform-ის ავტომატიზირება.

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

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

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

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

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

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

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

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

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

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

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

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

შევაჯამოთ:

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

• უცვლელი ინფრასტრუქტურა. AMI მიწოდება გრაფიკით.
• მარშრუტის 53 სტრუქტურა, როდესაც თქვენ გაქვთ ბევრი ჩანაწერი და გსურთ, რომ ისინი თანმიმდევრული იყოს.
• API სიჩქარის ლიმიტების ბრძოლა. ამაზონი ამბობს: ”ესე იგი, მე ვერ მივიღებ სხვა მოთხოვნას, გთხოვთ დაელოდოთ.” ოფისის ნახევარი კი ელოდება, სანამ ინფრასტრუქტურის გაშვებას შეძლებს.
• ადგილზე შემთხვევები. Amazon არ არის იაფი ღონისძიება და ლაქები საშუალებას გაძლევთ დაზოგოთ საკმაოდ ბევრი. და იქ შეგიძლიათ გითხრათ მთელი ანგარიში ამის შესახებ.
• უსაფრთხოების და IAM როლები.
• დაკარგული რესურსების ძიებაში, როდესაც თქვენ გაქვთ უცნობი წარმოშობის შემთხვევები Amazone-ში, ისინი ჭამენ ფულს. მაშინაც კი, თუ ასეთი შემთხვევები თვეში 100-150 დოლარი ღირს, ეს წელიწადში 1 დოლარზე მეტია. ასეთი რესურსების მოძიება მომგებიანი ბიზნესია.
• და რეზერვირებული შემთხვევები.

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

კითხვები

გმადლობთ ანგარიშისთვის! თქვენი სახელმწიფო ფაილი არის S3-ში, მაგრამ როგორ გადაჭრით პრობლემას, რომ რამდენიმე ადამიანს შეუძლია მიიღოს ეს სახელმწიფო ფაილი და სცადოს გაფართოება?

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

იყენებთ ღია წყაროს ან საწარმოს?

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

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

დრო შეზღუდული იყო. Კარგი არგუმენტია.

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

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

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

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

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

გსმენიათ რამე jsonnet-ზე?

პოსტები

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

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

Უბრალოდ შეხედე. Გმადლობთ!

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

ეს არის ძალიან განსხვავებული რამ. თქვენ შეგიძლიათ შექმნათ რესურსები Ansible-ში, ხოლო Puppet-ს შეუძლია შექმნას რესურსები Amazon-ში. მაგრამ Terraform არის პირდაპირ up sharpened.

მხოლოდ ამაზონი გაქვს?

ეს არ არის ის, რომ ჩვენ მხოლოდ Amazon გვაქვს. ჩვენ თითქმის მხოლოდ Amazon გვაქვს. მაგრამ მთავარი თვისება ის არის, რომ Terraform ახსოვს. Ansible-ში თუ იტყვით: „მომეცი 5 შემთხვევა“, მაშინ ის გაიზრდება და შემდეგ იტყვი: „ახლა კი მჭირდება 3“. და ტერაფორმი იტყვის: „კარგი, მე მოვკლავ 2-ს“, ხოლო ანსიბლი იტყვის: „კარგი, აქ არის 3 შენთვის“. სულ 8.

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

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

კითხვა არის ეს. თქვენ იყენებთ Remote backend-ს, იყენებთ S 3-ს. რატომ არ იყენებთ ოფიციალურ backend-ს?

ოფიციალური?

ტერაფორმული ღრუბელი.

როდის გამოჩნდა?

დაახლოებით 4 თვის წინ.

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

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

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

ფიფქებზე ილაპარაკე, ტოტი რატომ არ გამოიყენე? რატომ არ გამოვიდა ასე?

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

ანუ არ მუშაობს?

ეს საერთოდ არ მუშაობს.

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

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

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

ანუ ჯერ არ მოგვარებულა?

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

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

Მომხმარებლის მონაცემები.

ანუ უბრალოდ აფურთხებ ფაილს და როგორმე ასრულებ?

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

ანუ, არის ეს რაღაც ცალკეული პროცესი, რომელიც გაცემულია?

ჩვენ არ გამოვიგონეთ. ჩვენ ვიყენებთ მას.

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

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

გამოდის, რომ ერთადერთი გამოსავალი ტესტირებაა?

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

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

არც დამიწყია.

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

ანუ აქ უნდა დავწერო (სლაიდი: Production/environment/settings.tf): domain = variable, domain vpcnetwork, variable vpcnetwork და stvars – შემიძლია იგივე მივიღო?

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

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

შესაძლებელია თუ არა ყველაფერი ერთ ადგილას?

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

გამარჯობა! შეგხვედრიათ სიტუაციები, როდესაც ღრუბლოვანი პროვაიდერი ერევა თქვენს მიერ შექმნილ Terraform-ში? ვთქვათ, ჩვენ ვასწორებთ მეტამონაცემებს. არის ssh გასაღებები. და Google მუდმივად აყენებს თავის მეტამონაცემებს და მის გასაღებებს. და Terraform ყოველთვის წერს, რომ მას აქვს ცვლილებები. ყოველი გაშვების შემდეგ, თუნდაც არაფერი შეიცვალოს, ის ყოველთვის ამბობს, რომ ახლა განაახლებს ამ ველს.

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

ანუ თქვენ შეგხვედრიათ მსგავსი რამ, მაგრამ არაფერი გამოგივიდათ, როგორ აკეთებს და აკეთებს ამას თავად?

სამწუხაროდ, დიახ.

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

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

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

კიდევ რაზე იყო კითხვა?

როცა SG ქმნის ასობით შემთხვევას, საჭიროა თუ არა მათი გარჩევა?

არა, ნუ. თითოეულ შემთხვევაში არის აგენტი, რომელიც იტყობინება, რომ მე მაქვს პრობლემა. თუ აგენტი იტყობინება, მაშინ აგენტმა იცის მის შესახებ და, სულ მცირე, მისი IP მისამართი არსებობს. უკვე შეგიძლია გაქცევა. მეორეც, ჩვენ ვიყენებთ Consul for Discovery, სადაც Kubernetes არ არის. და კონსული ასევე აჩვენებს ინსტანციის IP მისამართს.

ანუ კონკრეტულად IP-ზე აკეთებთ აქცენტს და არა ჰოსტის სახელზე?

ჰოსტის სახელით ნავიგაცია შეუძლებელია, ანუ ბევრია. არსებობს ინსტანციის იდენტიფიკატორები - AE და ა.შ. შეგიძლიათ იპოვოთ სადმე, შეგიძლიათ ჩააგდოთ ძებნაში.

გამარჯობა! მივხვდი, რომ Terraform არის კარგი რამ, მორგებული ღრუბლებზე.

Არა მხოლოდ.

ეს არის ზუსტად ის კითხვა, რომელიც მაინტერესებს. თუ გადაწყვეტთ, ვთქვათ, Bare Metal-ზე მასიურად გადაადგილება ყველა თქვენი ინსტანციით? რაიმე პრობლემა ხომ არ იქნება? ან კიდევ მოგიწევთ სხვა პროდუქტების გამოყენება, მაგალითად, იგივე Ansible, რომელიც აქ იყო ნახსენები?

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

ახლა არა, მაგრამ ბიზნესი მოვა და იტყვის: „მოდი“.

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

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

Terraform გაძლევთ საშუალებას შექმნათ Front-End სამუშაოები, დააკონფიგურიროთ PagerDuty, data doc და ა.შ. მას აქვს ბევრი კუდი. მას შეუძლია პრაქტიკულად გააკონტროლოს მთელი მსოფლიო.

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

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

თუ არის შეცდომა, უკან აბრუნებთ? გიცდიათ ამის გაკეთება?

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

წყარო: www.habr.com