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

ინგლისური ვერსია

ეს ჩემი ჩანაწერია სპექტაკლები on DevopsConf 2019-05-28.

სლაიდები და ვიდეოები

• ინგლისური ვერსია
• რუსული ვერსია
• მშრალი რბენა 2019-04-24 SpbLUG
• ვიდეო (RU) DevopsConf-დან 2019-05-28
• ვიდეო(RU) DINS DevOps EVENING 2019-06-20
• სლაიდები

ინფრასტრუქტურა, როგორც ბაშის ისტორია

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

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

1. გამეორებადობა: შეგიძლიათ აიღოთ bash ისტორია, აწარმოოთ ბრძანებები იქიდან და, სხვათა შორის, მიიღოთ სამუშაო კონფიგურაცია, როგორც გამოსავალი.
2. ვერსიირება: თქვენ იცით, ვინ შემოვიდა და რა გააკეთა, კიდევ ერთხელ, ფაქტი არ არის, რომ ეს მიგიყვანთ სამუშაო კონფიგურაციამდე გასასვლელში.
3. история: ამბავი ვინ რა გააკეთა. მხოლოდ თქვენ ვერ შეძლებთ მის გამოყენებას სერვერის დაკარგვის შემთხვევაში.

რა უნდა გავაკეთოთ?

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

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

მშრალი

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

• შედით აქ ssh-ის საშუალებით და შეასრულეთ ბრძანება.
• დააკოპირეთ ფაილი იქ.
• შეასწორეთ კონფიგურაცია აქ.
• დაიწყეთ მომსახურება იქ
• ...
• მოგება!

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

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

SOLID CFM-სთვის

დროთა განმავლობაში პროექტი გაიზარდა და ბუნებრივი გაგრძელება იყო ანსიბლის გაჩენა. მისი გარეგნობის მთავარი მიზეზი ის არის, რომ გუნდში არის ექსპერტიზა და რომ ბაში არ არის შექმნილი რთული ლოგიკით. Ansible ასევე დაიწყო შეიცავდეს რთული ლოგიკა. რთული ლოგიკის ქაოსში გადაქცევის თავიდან ასაცილებლად, არსებობს პროგრამული უზრუნველყოფის შემუშავებაში კოდის ორგანიზების პრინციპები ᲛᲧᲐᲠᲘ ასევე, მაგალითად, გრიგორი პეტროვმა მოხსენებაში „რატომ სჭირდება IT სპეციალისტს პერსონალური ბრენდი“ დასვა კითხვა, რომ ადამიანი შექმნილია ისე, რომ მას გაუადვილდეს თანამშრომლობა ზოგიერთ სოციალურ ობიექტთან, პროგრამული უზრუნველყოფის შემუშავებაში ამ არის ობიექტები. თუ ამ ორ იდეას გავაერთიანებთ და გავაგრძელებთ მათ განვითარებას, შევამჩნევთ, რომ შეგვიძლია გამოვიყენოთ ᲛᲧᲐᲠᲘ რათა მომავალში ამ ლოგიკის შენარჩუნება და შეცვლა გაუადვილოს.

ერთიანი პასუხისმგებლობის პრინციპი

თითოეული კლასი ასრულებს მხოლოდ ერთ დავალებას.

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

ღია დახურული პრინციპი

ღია/დახურული პრინციპი.

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

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

ლისკოვის ჩანაცვლების პრინციპი

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

თუ უფრო ფართოდ შეხედავთ, ეს არ არის რაიმე კონკრეტული პროექტის მახასიათებელი, რომლის გამოყენებაც იქ შეიძლება ᲛᲧᲐᲠᲘ, ზოგადად საუბარია CFM-ზე, მაგალითად, სხვა პროექტზე აუცილებელია ჯავის აპლიკაციის განლაგება სხვადასხვა Java-ზე, აპლიკაციის სერვერებზე, მონაცემთა ბაზებზე, OS და ა.შ. ამ მაგალითის გამოყენებით განვიხილავ შემდგომ პრინციპებს ᲛᲧᲐᲠᲘ

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

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

ინტერფეისის სეგრეგაციის პრინციპი

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

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

დამოკიდებულების ინვერსიის პრინციპი

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

აქ მაგალითი დაფუძნებული იქნება ანტიპატერნაზე.

1. ერთ-ერთ მომხმარებელს ჰქონდა პირადი ღრუბელი.
2. ჩვენ შეუკვეთეთ ვირტუალური მანქანები ღრუბელში.
3. მაგრამ ღრუბლის ბუნების გამო, აპლიკაციის განლაგება იყო მიბმული რომელ ჰიპერვიზორზე იყო VM.

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

ურთიერთქმედება

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

ავტობუსის ფაქტორი

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

წყვილი Devopsing

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

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

კოდის მიმოხილვა

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

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

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

კოდის სტილი

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

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

მწვანე აშენების ოსტატი

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

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

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

IaC ტესტირება

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

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

IaC ტესტირების პირამიდა

IaC ტესტირება: სტატიკური ანალიზი

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

ბაში სახიფათოა

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

for i in * ; do 
    cp $i /some/path/$i.bak
done

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

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

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

find . -type f -exec mv -v {} dst/{}.bak ;

კარგად გააკეთე ახლა? არა... დაგავიწყდა რა შეიძლება იყოს ფაილის სახელი n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

სტატიკური ანალიზის ხელსაწყოები

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

ენა
Tool

Bash
Shellcheck

Ruby
RuboCop

პითონი
პილონია

პასუხისმგებელი
Ansible Lint

IaC ტესტირება: ერთეულის ტესტები

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

თავიდანვე ვისაუბრეთ ᲛᲧᲐᲠᲘ და რომ ჩვენი ინფრასტრუქტურა უნდა შედგებოდეს პატარა აგურისგან. მათი დროც დადგა.

1. ინფრასტრუქტურა დაყოფილია პატარა აგურებად, მაგალითად, Ansible როლები.
2. განლაგებულია რაიმე სახის გარემო, იქნება ეს დოკერი თუ VM.
3. ჩვენ ვიყენებთ ჩვენს Ansible როლს ამ ტესტის გარემოში.
4. ჩვენ ვამოწმებთ, რომ ყველაფერი მუშაობდა ისე, როგორც ველოდით (ჩვენ ვაწარმოებთ ტესტებს).
5. ჩვენ გადავწყვიტეთ კარგია თუ არა კარგი.

IaC ტესტირება: ერთეულის ტესტირების ხელსაწყოები

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

CFM
Tool

შეუძლებელია
ტესტინფრა

შეფ
ინსპექტირება

შეფ
სერვერსპექტი

მარილის დასტა
Goss

მაგალითი testinfra-სთვის, მომხმარებლების შემოწმება test1, test2 არსებობენ და არიან ჯგუფში sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

რა აირჩიოს? კითხვა რთული და ორაზროვანია, აქ მოცემულია პროექტების ცვლილებების მაგალითი github-ზე 2018-2019 წლებში:

IaC ტესტირების ჩარჩოები

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

CFM
Tool

შეუძლებელია
მოლეკულა

შეფ
საცდელი სამზარეულო

Terraform
ტერატესტი

პროექტების ცვლილებების მაგალითი github-ზე 2018-2019 წლებში:

მოლეკულა vs. სატესტო სამზარეულო

თავდაპირველად ჩვენ სცადა ტესტის სამზარეულოს გამოყენება:

1. პარალელურად შექმენით VM.
2. გამოიყენეთ Ansible როლები.
3. გაიარეთ შემოწმება.

25-35 როლზე მუშაობდა 40-70 წუთი, რაც ხანგრძლივი იყო.

შემდეგი ნაბიჯი იყო გადასვლა jenkins/docker/ansible/მოლეკულაზე. იდეოლოგიურად ყველაფერი ერთნაირია

1. ლინტის სათამაშო წიგნები.
2. გაანაწილე როლები.
3. გაშვების კონტეინერი
4. გამოიყენეთ Ansible როლები.
5. გაუშვით testinfra.
6. შეამოწმეთ იმპოტენცია.

40 როლის დამზადება და ათეულის ტესტირება დაახლოებით 15 წუთი გაგრძელდა.

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

IaC ტესტირება: ინტეგრაციის ტესტები

ინფრასტრუქტურის ტესტირების პირამიდის შემდეგი ნაბიჯი იქნება ინტეგრაციის ტესტები. ისინი მსგავსია ერთეული ტესტების:

1. ინფრასტრუქტურა დაყოფილია პატარა აგურებად, მაგალითად Ansible როლებზე.
2. განლაგებულია რაიმე სახის გარემო, იქნება ეს დოკერი თუ VM.
3. გამოიყენეთ ამ ტესტის გარემო ბევრი შესამჩნევი როლები.
4. ჩვენ ვამოწმებთ, რომ ყველაფერი მუშაობდა ისე, როგორც ველოდით (ჩვენ ვაწარმოებთ ტესტებს).
5. ჩვენ გადავწყვიტეთ კარგია თუ არა კარგი.

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

IaC ტესტირება: ტესტები ბოლომდე

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

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

ეს სქემა საკმაოდ დიდი ხნის განმავლობაში მუშაობდა, სანამ ჩარჩოში კვლევა ჩვენ არ გვიცდია ამის გადაცემა Openshift-ზე. კონტეინერები იგივე რჩება, მაგრამ გაშვების გარემო შეიცვალა (გამარჯობა ისევ DRY).

კვლევის იდეა უფრო შორს წავიდა და openshift-ში მათ იპოვეს ისეთი რამ, როგორიცაა APB (Ansible Playbook Bundle), რომელიც საშუალებას გაძლევთ შეფუთოთ ცოდნა იმის შესახებ, თუ როგორ უნდა განათავსოთ ინფრასტრუქტურა კონტეინერში. იმათ. არსებობს ცოდნის განმეორებადი, შესამოწმებელი წერტილი ინფრასტრუქტურის განლაგების შესახებ.

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

დასკვნა

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

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

ბმულები

• ინგლისური ვერსია
• ჯვარედინი პოსტი პირადი ბლოგიდან
• მშრალი რბენა 2019-04-24 SpbLUG
• ვიდეო (RU) DevopsConf-დან 2019-05-28
• ვიდეო(RU) DINS DevOps EVENING 2019-06-20
• 300,000-ზე მეტი სტრიქონული ინფრასტრუქტურის კოდის დაწერის შედეგად მიღებული გაკვეთილები & ტექსტური ვერსია
• ინფრასტრუქტურის, როგორც კოდის ინტეგრირება უწყვეტი მიწოდების მილსადენში
• ინფრასტრუქტურის ტესტირება კოდის სახით
• Ansible როლების ეფექტური განვითარება და შენარჩუნება
• Ansible არ არის ბაში!

წყარო: www.habr.com