.NET Core Linux-ზე, DevOps ცხენზე

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

ასე იწყება ამბავი ალექსანდრა სინჩინოვა on DevOpsConf. როდესაც ვინდოუსის წამყვანმა სპეციალისტმა დატოვა კომპანია, ალექსანდრე დაინტერესდა რა ექნა ახლა. გადაერთეთ Linux-ზე, რა თქმა უნდა! ალექსანდრე გეტყვით, როგორ მოახერხა პრეცედენტის შექმნა და Windows-ის განვითარების ნაწილის Linux-ზე გადატანა 100 000 საბოლოო მომხმარებლისთვის დასრულებული პროექტის მაგალითის გამოყენებით.

როგორ მარტივად და უპრობლემოდ მივაწოდოთ პროექტი RPM-ში TFS, Puppet, Linux .NET ბირთვის გამოყენებით? როგორ დავუჭიროთ მხარი პროექტის მონაცემთა ბაზის ვერსიას, თუ დეველოპერების გუნდს პირველად ესმის სიტყვები Postgres და Flyway, და ბოლო ვადა არის ხვალინდელი დღე? როგორ გავაერთიანოთ Docker-თან? როგორ მოვახდინოთ .NET დეველოპერების მოტივაცია, უარი თქვან Windows-სა და სმუზიზე Puppet-ისა და Linux-ის სასარგებლოდ? როგორ გადავწყვიტოთ იდეოლოგიური კონფლიქტები, თუ არ არსებობს არც ძალა, არც სურვილი და არც რესურსები, რომ შევინარჩუნოთ Windows წარმოებაში? ამის შესახებ, ისევე როგორც Web Deploy-ის, ტესტირების, CI-ის, არსებულ პროექტებში TFS-ის გამოყენების პრაქტიკის შესახებ და, რა თქმა უნდა, გატეხილი ხელჯოხებისა და სამუშაო გადაწყვეტილებების შესახებ, ალექსანდრეს მოხსენების ტრანსკრიპტში.

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

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

რატომ .NET core ლინუქსთან ერთად?

ამას რამდენიმე მიზეზი ჰქონდა. "გადაიხადე ფული" და "არ გადაიხადო" შორის უმრავლესობა აირჩევს მეორეს - ჩემსავით. MSDB-ის ლიცენზია დაახლოებით $1 ღირს; Windows-ის ვირტუალური მანქანების ფლოტის შენარჩუნება ასობით დოლარი ღირს. დიდი კომპანიისთვის ეს დიდი ხარჯია. Ამიტომაც დანაზოგი - პირველი მიზეზი. არა ყველაზე მნიშვნელოვანი, მაგრამ ერთ-ერთი ყველაზე მნიშვნელოვანი.

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

სისტემა უბრალოდ ინტეგრირებულია არსებულ CI-ში. ჩვენ თავს პროგრესულად განვიხილავთ DevOps-ს, ვიყენებთ Bamboo-ს, Jenkins-ს და GitLab CI-ს, ამიტომ ჩვენი სამუშაოს უმეტესობა მუშაობს Linux-ზე.

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

მოთხოვნები

Პირველ რიგში - ახალი გადაწყვეტის მოხერხებულობა დეველოპერებისთვის. ყველა მათგანი არ იყო მზად ცვლილებისთვის, განსაკუთრებით მას შემდეგ, რაც სიტყვა Linux წარმოთქვა. დეველოპერებს სურთ მათი საყვარელი Visual Studio, TFS ავტოტესტებით შეკრებებისა და სმუზიებისთვის. როგორ ხდება წარმოებაში მიწოდება მათთვის არ არის მნიშვნელოვანი. ამიტომ, ჩვენ გადავწყვიტეთ არ შეგვეცვალა ჩვეულებრივი პროცესი და ყველაფერი უცვლელი დავტოვოთ Windows-ის განვითარებისთვის.

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

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

ბოლო ვადა - გუშინ.

Win Development Group

რასთან მუშაობდა მაშინ ვინდოუსის გუნდი?

ახლა ამის დარწმუნებით შემიძლია ვთქვა IdentityServer4 არის ADFS-ის მაგარი უფასო ალტერნატივა მსგავსი შესაძლებლობებით, ან რა Entity Framework Core - სამოთხე დეველოპერებისთვის, სადაც თქვენ არ გჭირდებათ SQL სკრიპტების დაწერა, მაგრამ მონაცემთა ბაზაში შეკითხვის აღწერა OOP ტერმინებით. მაგრამ შემდეგ, სამოქმედო გეგმის განხილვისას, მე ვუყურებდი ამ დასტას, თითქოს შუმერული ლურსმული დამწერი ყოფილიყო, მხოლოდ PostgreSQL და Git-ის ამოცნობა.

იმ დროს ჩვენ აქტიურად ვიყენებდით თოჯინები როგორც კონფიგურაციის მართვის სისტემა. ჩვენი პროექტების უმეტესობაში ვიყენებდით GitLab CI, ელასტიური, დაბალანსებული მაღალი დატვირთვის სერვისების გამოყენებით HAProxy აკონტროლებდა ყველაფერს ზაბქსი, ლიგატები გრაფანა и პრომეთე, Jaeger, და ეს ყველაფერი რკინის ნაჭრებზე ტრიალებდა HP c ESXi on VMware. ეს ყველამ იცის - ჟანრის კლასიკა.

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

Რა მოხდა

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

ადრე ეს იყო მყარი ფანჯრები. TFS-მა გამოიყენა რამდენიმე Build აგენტი, რომლებიც გამოიყენებოდა მრავალი პროექტის ასაწყობად. თითოეულ აგენტს ჰყავს 3-4 თანამშრომელი ამოცანების პარალელიზებისთვის და პროცესის ოპტიმიზაციისთვის. შემდეგ, გამოშვების გეგმების მიხედვით, TFS-მა ახლად გამომცხვარი Build მიაწოდა Windows აპლიკაციის სერვერს.

რისი მიღწევა გვინდოდა?

ჩვენ ვიყენებთ TFS-ს მიწოდებისა და განვითარებისთვის და ვაწარმოებთ აპლიკაციას Linux Application სერვერზე და მათ შორის არის რაღაც მაგია. ეს Magic Box და წინ არის სამუშაოს მარილი. სანამ მას ცალ-ცალკე გადავდებ, განზე გადავდგები და რამდენიმე სიტყვას ვიტყვი განაცხადის შესახებ.

პროექტი

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

კლიენტი

ორი ტიპის მომხმარებელი იყო. პირველი მოიპოვა წვდომა SSL SHA-2 სერთიფიკატის გამოყენებით შესვლით. უ მეორე იყო წვდომა შესვლისა და პაროლის გამოყენებით.

HAProxy

შემდეგ კლიენტის მოთხოვნა გადავიდა HAProxy-ზე, რომელმაც გადაჭრა შემდეგი პრობლემები:

• პირველადი ავტორიზაცია;
• SSL შეწყვეტა;
• HTTP მოთხოვნების დარეგულირება;
• სამაუწყებლო მოთხოვნები.

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

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

ხერხდება

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

დაზოგვა HAProxy-ით

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

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

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

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

IdentityServer4-ს აქვს ფუნქცია: ის უბრუნებს პასუხს დაბრუნების მოთხოვნაზე HTTP-ის საშუალებით. რაც არ უნდა გვიჭირდეს სერვერის დაყენება, რამდენიც არ უნდა გაგვეგო დოკუმენტაცია, ყოველ ჯერზე ვღებულობდით კლიენტის თავდაპირველ მოთხოვნას URL-ით, რომელიც მოვიდა HTTPS-ით, და IdentityServer აბრუნებდა იმავე კონტექსტს, მაგრამ HTTP-ით. შოკში ვიყავით! და ეს ყველაფერი პირადობის კონტექსტის მეშვეობით გადავიტანეთ HAProxy-ზე და სათაურებში უნდა შეგვეცვალა HTTP პროტოკოლი HTTPS-ზე.

რა არის გაუმჯობესება და სად დაზოგე?

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

როგორ უნდა იმუშაოს

ასე რომ, როგორც დავპირდი - Magic Box. ჩვენ უკვე გვესმის, რომ გარანტირებული გვაქვს ლინუქსისკენ გადასვლა. მოდით ჩამოვაყალიბოთ კონკრეტული ამოცანები, რომლებიც საჭიროებდა გადაწყვეტილებებს.

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

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

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

TFS-ის დაყენება მივიდა მილსადენის დაყენებაზე. ადრე ჩვენ ვაგროვებდით Windows-ის ყველა პროექტს Windows-ის აგენტებზე, მაგრამ ახლა ჩნდება Linux აგენტი - Build აგენტი, რომელიც უნდა შევიდეს build ჯგუფში, გამდიდრდეს რამდენიმე არტეფაქტით და ვუთხრა, რა ტიპის პროექტები აშენდება ამ Build აგენტზე. და როგორმე შეცვალეთ მილსადენი.

IdentityServer. ADFS არ არის ჩვენი გზა, ჩვენ მივდივართ ღია წყაროზე.

მოდით გავიაროთ კომპონენტები.

Magic Box

შედგება ოთხი ნაწილისაგან.

Linux Build აგენტი. Linux, რადგან ჩვენ ვაშენებთ მას - ეს ლოგიკურია. ეს ნაწილი შესრულდა სამ ეტაპად.

• მუშების კონფიგურაცია და არა მარტო, რადგან მოსალოდნელი იყო პროექტზე განაწილებული მუშაობა.
• დააინსტალირეთ .NET Core 1.x. რატომ 1.x როდესაც 2.0 უკვე ხელმისაწვდომია სტანდარტულ საცავში? იმიტომ, რომ როდესაც ჩვენ დავიწყეთ განვითარება, სტაბილური ვერსია იყო 1.09 და გადაწყდა, რომ პროექტი მასზე დაფუძნებულიყო.
• Git 2.x.

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

GitLab ყურადღება! GitLab აქ გამოიყენება არა დეველოპერების მიერ, არამედ ოპერაციების განყოფილების მიერ აპლიკაციის ვერსიების, პაკეტის ვერსიების გასაკონტროლებლად, ყველა Linux აპარატის სტატუსის მონიტორინგისთვის და ის ინახავს რეცეპტს - ყველა Puppet მანიფესტს.

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

ჩვენ ვიწყებთ ჩაყვინთვის. როგორ მუშაობს DLL მიწოდება RPM-ზე?

DDL მიწოდება RPM-მდე

ვთქვათ, გვყავს .NET განვითარების როკ ვარსკვლავი. ის იყენებს Visual Studio-ს და ქმნის გამოშვების ფილიალს. ამის შემდეგ, ის ატვირთავს მას Git-ში და Git აქ არის TFS ერთეული, ანუ ეს არის აპლიკაციის საცავი, რომლითაც მუშაობს დეველოპერი.

რის შემდეგაც TFS ხედავს, რომ ახალი commit მოვიდა. რომელი აპლიკაცია? TFS პარამეტრებში არის ეტიკეტი, რომელშიც მითითებულია რა რესურსები აქვს კონკრეტულ Build აგენტს. ამ შემთხვევაში, ის ხედავს, რომ ჩვენ ვაშენებთ .NET Core პროექტს და ირჩევს Linux Build აგენტს აუზიდან.

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

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

ყველაფერი მარტივია სიტყვებით, მაგრამ რა ხდება თავად Build აგენტის შიგნით?

შეფუთვა DLL RPM

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

ZIP არქივი გადაყრილია RPM პაკეტის შექმნის დირექტორიაში. შემდეგი, Bash სკრიპტი ახდენს გარემოს ცვლადების ინიციალიზაციას, პოულობს Build ვერსიას, პროექტის ვერსიას, გზას build დირექტორიაში და აწარმოებს RPM-build-ს. მშენებლობის დასრულების შემდეგ, პაკეტი გამოქვეყნებულია ადგილობრივი საცავი, რომელიც მდებარეობს Build აგენტზე.

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

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

მონაცემთა ბაზის ვერსია

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

ამ ნაწილში მინდა გითხრათ, თუ როგორ მოვახდინეთ მონაცემთა ბაზის ვერსია და როგორ ავირჩიეთ Flyway-სა და Entity Framework Core-ს შორის. მოდით შევხედოთ მათ დადებით და უარყოფით მხარეებს.

Cons

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

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

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

დადებითი

Entity Framework Core მუშაობს ყუთში და ადვილად მუშავდებადა Flyway ადვილად ინტეგრირდება არსებულ CI-ში. მაგრამ ჩვენ ამას მოსახერხებელი ვაკეთებთ დეველოპერებისთვის :)

Roll-up პროცედურა

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

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

TFS პრობლემები

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

ერთ-ერთი მთავარი პროექტის აწყობას 12-15 წუთი სჭირდება - ეს დიდი დროა, ასე ცხოვრება არ შეიძლება. სწრაფმა ანალიზმა აჩვენა I/O-ს საშინელი დაქვეითება და ეს იყო მასივებზე.

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

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

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

გადაწყვეტილება

• წყაროები AV გამონაკლისებში.
• გამორთეთ ინდექსირება.
• Წადი npm ci.

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

კონფიგურაცია

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

ჩვენ ასევე ვიყენებთ NuGet, რადგან მას აქვს უკეთესი ქეშირება პაკეტის სხვა მენეჯერებთან შედარებით.

შედეგი

მას შემდეგ რაც Build Agents-ის ოპტიმიზაცია მოვახდინეთ, მშენებლობის საშუალო დრო 12 წუთიდან 7-მდე შემცირდა.

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

გეგმები

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

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

რეზიუმე

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

ალექსანდრე სინჩინოვის სპიკერის პროფილი GitHub-ზე.

DevOps Conf არის კონფერენცია განვითარების, ტესტირებისა და ექსპლუატაციის პროცესების ინტეგრაციის შესახებ პროფესიონალებისთვის პროფესიონალების მიერ. აი რატომ ისაუბრა პროექტზე ალექსანდრე? განხორციელდა და მუშაობდა, ხოლო სპექტაკლის დღეს იყო ორი წარმატებული გამოცემა. ჩართულია DevOps Conf RIT++-ზე 27 და 28 მაისს კიდევ უფრო მეტი მსგავსი შემთხვევა იქნება პრაქტიკოსებისგან. თქვენ მაინც შეგიძლიათ ბოლო ვაგონში გადახტომა და ანგარიშის წარდგენა ან მიიღეთ დრო დაჯავშნა ბილეთი. შეგვხვდით სკოლკოვოში!

წყარო: www.habr.com