ეს ამბავი იმაზეა, თუ როგორ ვიყენებთ კონტეინერებს საწარმოო გარემოში, კონკრეტულად Kubernetes-ში. სტატია ეძღვნება კონტეინერებიდან მეტრიკისა და ჟურნალის შეგროვებას, ასევე სურათების აგებას.

ჩვენ ვართ ფინტექ კომპანია Exness-ისგან, რომელიც ავითარებს ონლაინ ვაჭრობის სერვისებს და ფინტექ პროდუქტებს B2B და B2C-სთვის. ჩვენს R&D-ს ჰყავს მრავალი განსხვავებული გუნდი, განვითარების განყოფილებას ჰყავს 100+ თანამშრომელი.

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

ჩვენი მოტივაცია

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

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

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

აგენტები

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

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

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

აგენტები ასევე გულისხმობენ კომუნალურ კომპანიებს ექსპლუატაციისა და შენარჩუნებისთვის, რომლებსაც შეუძლიათ იმუშაონ სხვადასხვა საორკესტრო სისტემებში, რომლებიც მხარს უჭერენ სხვადასხვა სურათებს (Debian, Alpine, Centos და ა.შ.).

და ბოლოს, აგენტებმა უნდა უზრუნველყონ მარტივი CI/CD, რომელიც შეიცავს Docker ფაილებს. წინააღმდეგ შემთხვევაში, გემი დაიშლება, რადგან კონტეინერების მიწოდება დაიწყება "დახრილი" რელსებით.

პროცესის შექმნა და სამიზნე გამოსახულების მოწყობილობა

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

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

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

რა არის კარგი ამ მიდგომაში? 

• პირველი, სრული ვერსიის კონტროლი build ინსტრუმენტების - build კონტეინერი, სკრიპტის და განაწილების ვერსიები. 
• მეორეც, ჩვენ მივაღწიეთ სტანდარტიზაციას: ანალოგიურად ვქმნით შაბლონებს, შუალედურ და გამოსაყენებლად მზა სურათს. 
• მესამე, კონტეინერები გვაძლევს პორტაბელურობას. დღეს ჩვენ ვიყენებთ Gitlab-ს, ხვალ კი გადავალთ TeamCity-ზე ან Jenkins-ზე და ჩვენ შევძლებთ ჩვენი კონტეინერების გაშვებას იმავე გზით. 
• მეოთხე, დამოკიდებულებების მინიმუმამდე შემცირება. შემთხვევითი არ იყო, რომ სადისტრიბუციო კომპლექტები კონტეინერში ჩავდეთ, რადგან ეს საშუალებას გვაძლევს თავიდან ავიცილოთ მათი ინტერნეტიდან ყოველ ჯერზე ჩამოტვირთვა. 
• მეხუთე, გაიზარდა აშენების სიჩქარე - სურათების ლოკალური ასლების არსებობა საშუალებას გაძლევთ თავიდან აიცილოთ დროის დაკარგვა გადმოტვირთვაზე, რადგან არსებობს ადგილობრივი სურათი. 

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

როგორ მუშაობს ჩვენი მშენებლობის პროცედურა

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

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

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

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

 

ერთი და იგივე კონტეინერისთვის მივიღებთ სხვადასხვა პროცესის ხეებს Docker-სა და Kubernetes-ში:

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

თუ გადავხედავთ "pod"-ის სპეციფიკაციას (შემდგომში - Kubernetes pod), დავინახავთ, რომ მოვლენების კონტეინერი შესრულებულია პოდში, რომელსაც აქვს ცალკე კოლექციონერი, რომელიც ასრულებს მეტრიკისა და ჟურნალების შეგროვების ფუნქციას. ჩვენ შეგვიძლია გამოვიყენოთ Kubernetes-ის შესაძლებლობები: კონტეინერების გაშვება ერთ პოდში, ერთ პროცესში და/ან ქსელის სივრცეში. რეალურად წარმოადგინეთ თქვენი აგენტები და შეასრულეთ გარკვეული ფუნქციები. და თუ იგივე კონტეინერი გაიშვება Docker-ში, ის მიიღებს ყველა იმავე შესაძლებლობებს, როგორც გამომავალს, ანუ შეძლებს ჟურნალების და მეტრიკის მიწოდებას, რადგან აგენტები შიგადაშიგ გაშვებული იქნება. 

მეტრიკა და ჟურნალი

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

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

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

და ბოლო ასპექტი არის რესურსების მოხმარების მინიმუმამდე შემცირება.

ჩვენ ავირჩიეთ ღია კოდის Go გადაწყვეტა, სახელწოდებით Telegraf. ეს არის უნივერსალური კონექტორი, რომელიც მხარს უჭერს 140-ზე მეტ ტიპის შეყვანის არხს (შეყვანის დანამატები) და 30 ტიპის გამომავალ არხებს (გამომავალი დანამატები). ჩვენ დავასრულეთ ის და ახლა გეტყვით, თუ როგორ ვიყენებთ მას Kubernetes-ის მაგალითის გამოყენებით. 

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

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

ჩვენ ვაგროვებთ ჟურნალებს Docker API-ის მეშვეობით: დეველოპერებმა უბრალოდ უნდა დააყენონ ისინი stdout ან stderr-ში და კოლექტორი დაალაგებს მას. ჟურნალები გროვდება ნაწილებად გარკვეული დაგვიანებით, რათა თავიდან აიცილოს მასპინძლის შესაძლო გადატვირთვა. 

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

• ჟურნალები ხელმისაწვდომია გრეილოგში (ვიზუალური ანალიზისთვის);
• ჟურნალები, მეტრიკა, მოვლენები იგზავნება Clickhouse-ში გრძელვადიანი შენახვისთვის.

ყველაფერი ზუსტად ერთნაირად მუშაობს AWS-ში, მხოლოდ ჩვენ ვცვლით Graylog-ს კაფკათი Cloudwatch-ით. ჩვენ ვგზავნით მორები იქ და ყველაფერი ძალიან მოსახერხებელია: მაშინვე გასაგებია, რომელ კლასტერსა და კონტეინერს ეკუთვნის ისინი. იგივე ეხება Google Stackdriver-ს. ანუ, ჩვენი სქემა მუშაობს როგორც შიდა კაფკასთან, ასევე ღრუბელში. 

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

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

შედეგად,

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

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

თანაავტორი: ილია პრუდნიკოვი

წყარო: www.habr.com