ინფრასტრუქტურა როგორც კოდი: პირველი გაცნობა

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

ჩვენს შიდა ღონისძიებაზე გამოსვლების საფუძველზე დაწერილი სტატიების სერიის გაგრძელება DevForum:

1. შროდინგერის კატა ყუთის გარეშე: კონსენსუსის პრობლემა განაწილებულ სისტემებში.
2. ინფრასტრუქტურა როგორც კოდი. (Აქ ხარ)
3. Typescript კონტრაქტების გენერაცია C# მოდელების გამოყენებით. (Პროგრესირებს...)
4. რაფტის კონსენსუსის ალგორითმის შესავალი. (Პროგრესირებს...)
...

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

გუნდს შემდეგი სავარჯიშო ამოცანები ჰქონდა:

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

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

მსოფლიოს ჩვეულ მოდელში (კლასიკური ადმინისტრაცია) ინფრასტრუქტურის შესახებ ცოდნა განლაგებულია ორ ადგილას:

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

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

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

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

ამრიგად, ინფრასტრუქტურა, როგორც კოდი (Incfastructure as Code - IaC) არის მთელი არსებული ინფრასტრუქტურის აღწერა კოდის სახით, ასევე მასთან მუშაობისა და მისგან რეალური ინფრასტრუქტურის დანერგვის შესაბამისი ინსტრუმენტები.

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

საიდან მოდიან ახალი SRE ინჟინრები?ასე რომ, ჩვენ გადავწყვიტეთ ახალი SRE ინჟინრების დაქირავება, მაგრამ საიდან მივიღოთ ისინი? წიგნი სწორი პასუხებით (Google SRE წიგნი) გვეუბნება: დეველოპერებისგან. ყოველივე ამის შემდეგ, ისინი მუშაობენ კოდით და თქვენ მიაღწევთ იდეალურ მდგომარეობას.

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

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

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

მაგალითი კოდი Terraforma-დან.

კოდის მაგალითი Ansible-დან.

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

1. პირველი პრობლემა ის არის, რომ უმეტეს შემთხვევაში IaC არის ერთგვარი dsl.

და DSL, თავის მხრივ, არის სტრუქტურის აღწერა. უფრო ზუსტად, რა უნდა გქონდეთ: Json, Yaml, მოდიფიკაციები ზოგიერთი მსხვილი კომპანიისგან, რომლებმაც გამოიგონეს საკუთარი dsl (HCL გამოიყენება ტერაფორმაში).

უბედურება ის არის, რომ ის შეიძლება ადვილად არ შეიცავდეს ისეთ ნაცნობ ნივთებს, როგორიცაა:

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

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

ძალიან რეალური სიტუაციაა, როდესაც ბაშ პითონთან ერთად იწყებს რაღაც პროცესს, რომელშიც ჯსონი არის ჩასმული. თქვენ აანალიზებთ მას, შემდეგ სხვა გენერატორი აწარმოებს კიდევ 30 ფაილს. ამ ყველაფრისთვის Azure Key Vault-დან მიიღება შეყვანის ცვლადები, რომლებიც გაერთიანებულია Go-ში დაწერილი drone.io-სთვის და ეს ცვლადები გადის yaml-ში, რომელიც წარმოიქმნა jsonnet შაბლონის ძრავიდან გენერირების შედეგად. საკმაოდ რთულია გქონდეს მკაცრად კარგად აღწერილი კოდი, როცა ასეთი მრავალფეროვანი გარემო გაქვს.

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

3. მესამე პრობლემა არის ტიუნინგი. ჩვენ შეჩვეულები ვართ რედაქტორების (Ms Visual Studio, Jetbrains Rider) გაგრილებას, რომლებიც ყველაფერს აკეთებენ ჩვენთვის. და სულელებიც რომ ვიყოთ, იტყვიან, რომ ვცდებით. როგორც ჩანს ნორმალური და ბუნებრივია.

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

ამ წერის დროს vscode-terraform მოდული ჯერ არ გამოსულა 0.12 ვერსიის მხარდასაჭერად, თუმცა გამოვიდა 3 თვე.

დროა დავივიწყოთ...

1. გამართვა.
2. რეფაქტორირების ინსტრუმენტი.
3. ავტომატური დასრულება.
4. შედგენის დროს შეცდომების გამოვლენა.

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

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

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

რაც შეეხება ტესტებს?

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

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

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

ძნელია Json-ის გარჩევა Go-ში. და თქვენ უნდა დაწეროთ Go-ში, რადგან terraform in Go არის კარგი პრაქტიკა ტესტირებისთვის იმ ენაზე, რომელზეც წერთ. თავად კოდის ორგანიზაცია ძალიან სუსტია. ამავდროულად, ეს არის საუკეთესო ბიბლიოთეკა ტესტირებისთვის.

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

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

მოდით გადავიდეთ. თუ IaC-ში არ არის ტესტები, IDE და tuning ცუდია, მაშინ მაინც უნდა იყოს საუკეთესო პრაქტიკა. მე უბრალოდ მივედი Google Analytics-ზე და შევადარე ორი საძიებო მოთხოვნა: Terraform-ის საუკეთესო პრაქტიკა და c# საუკეთესო პრაქტიკა.

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

რაც შეეხება IaC მოთხოვნას: აქ თქვენ ცდილობთ ცალ-ცალკე შეაგროვოთ ინფორმაცია highload ან HashiConf ანგარიშებიდან, ოფიციალური დოკუმენტაციისა და Github-ის მრავალი საკითხიდან. როგორ გავანაწილოთ ეს მოდულები ზოგადად, რა ვუყოთ მათ? როგორც ჩანს, ეს რეალური პრობლემაა... არის საზოგადოება, ბატონებო, სადაც ნებისმიერი კითხვისთვის 10 კომენტარს მოგცემენ Github-ზე. მაგრამ ეს არ არის ზუსტად.

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

სად მიდის ეს ყველაფერი და რა უნდა გააკეთოს

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

პირადად მე რამდენიმე რამეზე ვდებ ფსონს:

1. განვითარება ამ სფეროში ძალიან სწრაფად ხდება. აქ არის DevOps-ის მოთხოვნების განრიგი.

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

   თუ რამე ასე სწრაფად იზრდება, მაშინ აუცილებლად გამოჩნდებიან ჭკვიანი ადამიანები, რომლებიც გეტყვიან რა უნდა გააკეთო და რა არა. პოპულარობის მატება იწვევს იმ ფაქტს, რომ შესაძლოა ვინმეს ჰქონდეს დრო, რომ საბოლოოდ დაამატოთ jsonnet-ში vscode-ის მოდული, რომელიც საშუალებას მოგცემთ გადახვიდეთ ფუნქციის განხორციელებაზე, ვიდრე მისი ძებნა ctrl+shift+f-ით. მოვლენების განვითარებასთან ერთად, უფრო მეტი მასალა ჩნდება. Google-ისგან SRE-ს შესახებ წიგნის გამოშვება ამის შესანიშნავი მაგალითია.

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

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

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

დასკვნა

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

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

წყარო: www.habr.com