Terraform-დან CloudFormation-ზე გადაერთო - და ვინანე

ინფრასტრუქტურის კოდის სახით წარმოდგენა განმეორებადი ტექსტის ფორმატში არის მარტივი საუკეთესო პრაქტიკა სისტემებისთვის, რომლებიც არ საჭიროებენ თაგვებთან ჩხუბს. ამ პრაქტიკას აქვს სახელი - ინფრასტრუქტურა, როგორც კოდექსიდა ჯერჯერობით მისი განსახორციელებლად ორი პოპულარული ინსტრუმენტია, განსაკუთრებით AWS-ში: Terraform и CloudFormation.

გამოცდილების შედარება Terraform-თან და CloudFormation-თან

მოსვლამდე Twitch (აკა ამაზონი უმც.) Მე ვმუშაობდი ერთ სტარტაპში და გამოიყენა Terraform სამი წლის განმავლობაში. ახალ ადგილზე მეც მთელი ძალით გამოვიყენე Terraform, შემდეგ კი კომპანიამ აიძულა გადასვლა ყველაფერზე a la Amazon-ზე, CloudFormation-ის ჩათვლით. მე გულმოდგინედ შევიმუშავე საუკეთესო პრაქტიკა ორივესთვის და გამოვიყენე ორივე ინსტრუმენტი ძალიან რთულ, ორგანიზაციის მასშტაბურ სამუშაო პროცესებში. მოგვიანებით, Terraform-დან CloudFormation-ში მიგრაციის შედეგების დაფიქრების შემდეგ, დავრწმუნდი, რომ Terraform ალბათ საუკეთესო არჩევანი იყო ორგანიზაციისთვის.

Terraform საშინელი

ბეტა პროგრამული უზრუნველყოფა

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

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

გაიცანი ფეხი... ტყვია

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

ტერაფორმი დიდი

აღდგენა არასრული მდგომარეობიდან

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

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

უფრო მკაფიო ცვლილებები დოკუმენტის მდგომარეობაში

„კარგი, დატვირთვის ბალანსერი, შენ იცვლები. Მაგრამ როგორ?"

- შეშფოთებული ინჟინერი, მზად არის დააჭიროს ღილაკს "მიღება".

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

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

მოქნილობა

დაწერეთ პროგრამული უზრუნველყოფა უკან.

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

მოდულები git-ში

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

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

ოპერაციები, როგორც კოდი

"მოდით დავწეროთ და კარგი."

- ინჟინერი Terraform ველოსიპედის გამოგონებამდე 3 წლით ადრე.

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

კოდი როგორც კოდი

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

ინფრასტრუქტურა, როგორც კოდექსი

მაგრამ საიდან არის ის? როგორ გავაკონტროლო? სად ცხოვრობს შენი კოდი? სჭირდებათ თუ არა დეველოპერებს წვდომის ნებართვა?

ოპერაციები, როგორც კოდი

იყო პროგრამული უზრუნველყოფის შემქმნელი არ ნიშნავს მხოლოდ კოდის დაწერას.

AWS არ არის ერთადერთი: თქვენ ალბათ იყენებთ სხვა პროვაიდერებს. SignalFx, PagerDuty ან Github. შესაძლოა გქონდეთ ჯენკინსის შიდა სერვერი CI/CD-სთვის ან შიდა Grafana დაფა მონიტორინგისთვის. Infra as Code არჩეულია სხვადასხვა მიზეზის გამო და თითოეული თანაბრად მნიშვნელოვანია პროგრამულ უზრუნველყოფასთან დაკავშირებული ყველაფრისთვის.

როცა Twitch-ში ვმუშაობდი, ჩვენ ვაჩქარებდით სერვისებს Amazon-ის შერეული ჩაშენებული და AWS სისტემების შიგნით. ჩვენ შევქმენით და მხარი დავუჭირეთ ბევრ მიკროსერვისს, გავზარდეთ საოპერაციო ხარჯები. დისკუსიები ასე წარიმართა:

• Я: ჯანდაბა, ეს არის ბევრი ჟესტი ერთი მიკროსერვისის გადატვირთვისთვის. მე მომიწევს ამ ნაგვის გამოყენება AWS ანგარიშის შესაქმნელად (ჩვენ გადავედით 2 ანგარიშზე მიკროსერვისი), შემდეგ ეს გაფრთხილებების დასაყენებლად, ეს კოდის საცავისთვის და ეს ელფოსტის სიისთვის და შემდეგ ეს...
• ტყვია: მოდი დავწეროთ და კარგი.
• Я: კარგი, მაგრამ თავად სცენარი შეიცვლება. ჩვენ დაგვჭირდება გზა, რომ შევამოწმოთ, რომ ყველა ეს ჩაშენებული ამაზონის გიზმო განახლებულია.
• ტყვია: Კარგად ჟღერს. და ჩვენ დავწერთ სკრიპტს ამისათვის.
• Я: მშვენიერია! და სკრიპტს ალბათ მაინც დასჭირდება პარამეტრების დაყენება. მიიღებს ის მათ?
• ტყვია: სად მიდის წაიყვანოს!
• Я: პროცესი შეიძლება შეიცვალოს და უკან თავსებადობა დაიკარგოს. საჭირო იქნება გარკვეული სემანტიკური ვერსიის კონტროლი.
• ტყვია: Შესანიშნავი იდეა!
• Я: ხელსაწყოები შეიძლება შეიცვალოს ხელით, მომხმარებლის ინტერფეისის შიგნით. ჩვენ დაგვჭირდება გზა ამის შესამოწმებლად და გამოსწორების მიზნით.

3 წლის შემდეგ:

• ტყვია: და მივიღეთ ტერაფორმა.

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

CloudFormation lambda vs git მოდულები ტერაფორმული

lambda არის CloudFormation-ის გადაწყვეტა საბაჟო ლოგიკის საკითხისთვის. ლამბდასთან ერთად შეგიძლია მაკროების შექმნა ან მომხმარებლის რესურსი. ეს მიდგომა შემოაქვს დამატებით სირთულეებს, რომლებიც არ არის წარმოდგენილი Terraform-ის git მოდულების სემანტიკურ ვერსიაში. ჩემთვის ყველაზე აქტუალური პრობლემა იყო ყველა ამ მომხმარებლის ლამბდას ნებართვების მართვა (და ეს არის ათობით AWS ანგარიში). კიდევ ერთი მნიშვნელოვანი პრობლემა იყო „რა იყო პირველი, ქათამი თუ კვერცხი?“ პრობლემა: ეს დაკავშირებული იყო ლამბდა კოდთან. ეს ფუნქცია თავისთავად არის ინფრასტრუქტურა და კოდი და მას სჭირდება მონიტორინგი და განახლებები. ბოლო ლურსმანი კუბოში იყო ლამბდა კოდის ცვლილებების სემანტიკურად განახლების სირთულე; ჩვენ ასევე უნდა დავრწმუნდეთ, რომ სტეკის მოქმედებები პირდაპირი ბრძანების გარეშე არ იცვლებოდა გაშვებებს შორის.

მახსოვს, ერთხელ მინდოდა შემექმნა კანარის განლაგება Elastic Beanstalk გარემოსთვის კლასიკური დატვირთვის ბალანსერით. ყველაზე მარტივი გასაკეთებელი იქნება მეორე განლაგება EB-სთვის საწარმოო გარემოს გვერდით, გადადგმული ნაბიჯით წინ: ავტომატური სკალირების კანარის განლაგების ჯგუფის LB განლაგების საწარმოო გარემოში. და რადგან Terraform იყენებს ASG beantalk როგორც დასკვნა, ამას დასჭირდება 4 დამატებითი სტრიქონი კოდი Terraform-ში. როდესაც ვკითხე, იყო თუ არა შესადარებელი გადაწყვეტა CloudFormation-ში, მათ მიმითითეს მთელი git საცავი, განლაგების მილსადენით და ყველაფერი, ყველაფერი იმისთვის, რისი გაკეთებაც Terraform კოდის ცუდი 4 სტრიქონისთვის შეეძლო.

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

დარწმუნდით, რომ რეალობა შეესაბამება მოლოდინს.

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

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

CDK და CloudFormation-ის მომავალი

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

ისე, რომ Terraform არ გაგიცრუოს

ეს არის „ინფრასტრუქტურა როგორც კოდი“ და არა „როგორც ტექსტი“.

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

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

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

როგორ შეიძლება კოდი არ იყოს დოკუმენტირებული?

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

როგორ შეგვიძლია განვათავსოთ სერვისები, რომლებიც ოდესღაც ერთ დიდ მთავარ() ფუნქციას წარმოადგენდნენ?

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

თქვენი კომპანია არ იყენებს ბიბლიოთეკებს?

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

PEP8-ს ან gofmt-ს არ იყენებ?

ენების უმეტესობას აქვს სტანდარტული, მიღებული ფორმატირების სქემა. პითონში ეს არის PEP8. გო-ში - გოფმტ. Terraform-ს აქვს საკუთარი: terraform fmt. ისიამოვნეთ თქვენი ჯანმრთელობისთვის!

გამოიყენებ React-ს JavaScript-ის ცოდნის გარეშე?

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

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

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

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

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

როგორ შეიტანოთ ცვლილებები ბიბლიოთეკებში უკანა თავსებადობის გარეშე?

ჩვეულებრივ Terraform მოდულს, ისევე როგორც ჩვეულებრივ ბიბლიოთეკას, სჭირდება როგორმე მიაწოდოს ცვლილებებს მომხმარებლებთან უკუთავსებადობის გარეშე. შემაშფოთებელია, როდესაც ეს ცვლილებები ხდება ბიბლიოთეკებში და ისეთივე შემაშფოთებელია, როდესაც არაუკან თავსებადი ცვლილებები ხდება Terraform მოდულებში. Terraform მოდულების გამოყენებისას რეკომენდებულია git tags და semver-ის გამოყენება.

თქვენი წარმოების სერვისი მუშაობს თქვენს ლეპტოპზე ან მონაცემთა ცენტრში?

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

ტესტებს არ წერ?

ინჟინრები აღიარებენ, რომ კოდი საჭიროებს შემოწმებას, მაგრამ ისინი ხშირად ივიწყებენ ტესტირებას Terraform-თან მუშაობისას. ინფრასტრუქტურისთვის, ეს სავსეა მოღალატე მომენტებით. ჩემი რჩევაა „შემოწმოთ“ ან „შექმნათ მაგალითი“ სტეკები მოდულების გამოყენებით, რომლებიც შეიძლება სწორად განლაგდეს ტესტირებისთვის CI/CD-ის დროს.

ტერაფორმი და მიკროსერვისები

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

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

წყარო: www.habr.com