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

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

აპლიკაციების დაყენება VM-ზე

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

რატომ გაკეთდა ეს?

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

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

რა უპირატესობა ვნახეთ ამ ყველაფერში?

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

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

1. საწარმოო გარემოს, განვითარების გარემოს გარდა, არის სხვა გარემოც. მაგალითად, qa და preproduction. იმ დროს ჩვენ გვქონდა ბევრი სერვერი და დაახლოებით 60 სერვისი. ამ მიზეზით იყო საჭირო თითოეული სერვისისთვის შეინახეთ მისთვის უახლესი ვერსია ვირტუალური ხელსაწყო. უფრო მეტიც, თუ გსურთ ბიბლიოთეკების განახლება ან ახალი დამოკიდებულებების დაყენება, ეს უნდა გააკეთოთ ყველა გარემოში. თქვენ ასევე დაგჭირდათ დროის სინქრონიზაცია, როდესაც აპირებთ თქვენი აპლიკაციის შემდეგი ახალი ვერსიის დანერგვას იმ დროს, როდესაც devops ასრულებს საჭირო გარემოს პარამეტრებს. ამ შემთხვევაში ადვილია ისეთ სიტუაციაში მოხვედრა, როცა ჩვენი გარემო გარკვეულწილად განსხვავებული იქნება ყველა გარემოში ერთდროულად. მაგალითად, QA გარემოში იქნება ბიბლიოთეკების რამდენიმე ვერსია, ხოლო საწარმოო გარემოში იქნება სხვადასხვა, რაც გამოიწვევს პრობლემებს.
2. დამოკიდებულებების განახლების სირთულე თქვენი განაცხადი. ეს შენზე კი არა, სხვა გუნდზეა დამოკიდებული. კერძოდ, devops გუნდიდან, რომელიც ინარჩუნებს სერვერებს. თქვენ უნდა მისცეთ მათ შესაბამისი დავალება და იმის აღწერა, რისი გაკეთებაც გსურთ.
3. იმ დროს ჩვენ ასევე გვინდოდა დაგვეყო დიდი დიდი მონოლითები, რომლებიც გვქონდა ცალკეულ მცირე სერვისებად, რადგან გვესმოდა, რომ უფრო და უფრო მეტი იქნებოდა. იმ დროს უკვე 100-ზე მეტი გვქონდა, ყოველი ახალი სერვისისთვის საჭირო იყო ცალკე ახალი ვირტუალური მანქანის შექმნა, რომელიც ასევე საჭიროებდა შენარჩუნებას და დანერგვას. გარდა ამისა, თქვენ გჭირდებათ არა ერთი მანქანა, არამედ მინიმუმ ორი. ამ ყველაფერს ემატება QA გარემო. ეს იწვევს პრობლემებს და ართულებს თქვენთვის ახალი სისტემების აშენებას და გაშვებას. რთული, ძვირი და ხანგრძლივი პროცესი.

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

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

გადაერთეთ Nomad-ზე

Nomad არის HashiCorp-ის პროდუქტი. ისინი ასევე ცნობილია მათი სხვა გადაწყვეტილებებით:

"კონსული" არის სერვისის აღმოჩენის ინსტრუმენტი.

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

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

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

რა გჭირდებათ თქვენი სისტემის Nomad-ში განსათავსებლად?

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

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

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

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

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

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

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

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

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

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

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

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

რა დაგვიჯდა ტრანზიცია ადამიანური რესურსების თვალსაზრისით?

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

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

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

Nomad-ის მიტოვების მიზეზები

რა უპირატესობები მივიღეთ განლაგებაზე გადასვლით Nomad-ისა და docker-ის გამოყენებით, სხვათა შორის?

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

მაგრამ ჩვენ ასევე შეგვხვდა რამდენიმე უარყოფითი მხარე:

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

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

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

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

გადასვლა Kubernetes-ზე

მე ცოტას გეტყვით Kubernetes-ის ძირითადი ცნებების შესახებ და როგორ განსხვავდებიან ისინი Nomad-ისგან.

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

დავუშვათ, რომ თქვენ გაქვთ PHP აპლიკაცია, რომელიც შედგება nginx და php-fpm - კლასიკური სქემისგან. დიდი ალბათობით, მოგინდებათ, რომ nginx და php-fpm კონტეინერები ყოველთვის ერთად შეინახოთ. Kubernetes საშუალებას გაძლევთ მიაღწიოთ ამას, აღწერთ მათ, როგორც ერთ საერთო პოდს. ეს არის ზუსტად ის, რაც ვერ მივიღეთ Nomad-თან.

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

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

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

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

თუ ყველა ამ ცნებას შევადარებთ Nomad-ს, შეგვიძლია ვთქვათ, რომ პირველი სამი კონცეფცია არის ყველა ერთად Service. და ბოლო კონცეფცია არ არსებობს თავად Nomad-ში. ჩვენ გამოვიყენეთ გარე ბალანსერი: ეს შეიძლება იყოს ჰაპროქსი, ნგინქსი, ნგინქსი+ და ა.შ. კუბის შემთხვევაში, თქვენ არ გჭირდებათ ამ დამატებითი კონცეფციის ცალკე შემოღება. თუმცა, თუ Ingress-ს შიგნიდან შეხედავთ, ის არის nginx, ჰაპროქსი ან ტრაეფიკი, მაგრამ ერთგვარი ჩაშენებული Kubernetes-ში.

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

გარდა ამისა, მივხვდით, რომ არ გვინდოდა თითოეული ინდივიდუალური რესურსის ხელით შექმნა: განლაგება, სერვისები, Ingress და ა.შ. ამის ნაცვლად, ჩვენ გვინდოდა აღვწეროთ თითოეული ჩვენი სისტემა Kubernetes-ით განლაგების დროს, რათა არ მოგვიწიოს ხელით ხელახლა შევქმნათ ყველა საჭირო რესურსზე დამოკიდებულების სწორი თანმიმდევრობა. Helm აირჩიეს სისტემად, რომელმაც ამის საშუალება მოგვცა.

ძირითადი ცნებები Helm-ში

ჩაფხუტი არის პაკეტის მენეჯერი კუბერნეტისთვის. ეს ძალიან ჰგავს იმას, თუ როგორ მუშაობენ პაკეტის მენეჯერები პროგრამირების ენებში. ისინი საშუალებას გაძლევთ შეინახოთ სერვისი, რომელიც შედგება, მაგალითად, განლაგების nginx, განლაგების php-fpm, Config for Ingress, configmaps (ეს არის ერთეული, რომელიც საშუალებას გაძლევთ დააყენოთ env და სხვა პარამეტრები თქვენი სისტემისთვის) ასე- ჩარტებს უწოდებენ. ამავე დროს ჰელმ ეშვება კუბერნეტის თავზე. ანუ, ეს არ არის გვერდით მდგომი სისტემა, არამედ კუბის შიგნით გაშვებული კიდევ ერთი სერვისი. თქვენ მასთან ურთიერთობთ მისი API-ის მეშვეობით კონსოლის ბრძანების საშუალებით. მისი მოხერხებულობა და სილამაზე იმაში მდგომარეობს, რომ იმ შემთხვევაშიც კი, თუ საჭე გატყდება ან ამოიღებთ მას კლასტერიდან, თქვენი სერვისები არ გაქრება, რადგან საჭე არსებითად მხოლოდ სისტემის გაშვებას ემსახურება. თავად Kubernetes არის პასუხისმგებელი სერვისების შესრულებასა და მდგომარეობაზე.

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

Helm ამატებს კიდევ რამდენიმე კონცეფციას ჩვენთვის.

სტრუქტურა - ეს არის თქვენი სერვისის აღწერა. სხვა პაკეტების მენეჯერებში მას ეძახიან პაკეტი, პაკეტი ან მსგავსი რამ. აქ მას სქემა ჰქვია.

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

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

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

პრაქტიკაში, ჩვენ გადავწყვიტეთ ცოტა განსხვავებულად გაგვეკეთებინა საქმეები, ვიდრე Nomad-თან. თუ Nomad-ში ორივე განლაგების კონფიგურაციები და n-ცვლადები, რომლებიც საჭირო იყო ჩვენი სერვისის განსათავსებლად, ინახებოდა ერთ საცავში, აქ ჩვენ გადავწყვიტეთ მათი გაყოფა ორ ცალკეულ საცავად. "deploy" საცავი ინახავს მხოლოდ განლაგებისთვის საჭირო n-ცვლადებს, ხოლო "helm" საცავი ინახავს კონფიგურაციებს ან სქემებს.

რა მოგვცა ამან?

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

ვინაიდან ჩვენ გვაქვს არა მხოლოდ წარმოება, არამედ სხვა გარემოც, ამ განცალკევების წყალობით, ჩვენ შეგვიძლია ხელახლა გამოვიყენოთ ჩვენი საჭის დიაგრამები, რათა განვათავსოთ სერვისები არა მხოლოდ წარმოებაში, არამედ, მაგალითად, QA გარემოში. მათი ლოკალურად განლაგებაც კი მინიკუბე - ეს არის Kubernetes ადგილობრივად გაშვების საქმე.

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

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

დასკვნები

როგორც ჩანს, Kubernetes სერვისი უფრო რთულია, ვიდრე Nomad.

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

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

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

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

წყარო: www.habr.com