სპექტაკლის ორკესტრი

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

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

რატომ გვჭირდება დირიჟორი ჩვენს გუნდში?

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

მათი როლი არაფრით განსხვავდება მუსიკაში დირიჟორის როლისგან - ისინი საჭიროა გუნდის დასახმარებლად, მისი ხელმძღვანელობისა და თამაშის ორგანიზებისთვის.

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

ამ სერვერების მოპოვებისა და მუშაობის მიდგომა მრავალფეროვანია. რამდენიმე მაგალითი:

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

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

ჩვენთვის, ჩვენ დავყავით ისინი ორ ძირითად ტიპად:

• სატანკო ჯგუფი,
• მომსახურების ჯგუფი.

სატანკო ჯგუფი შედგება მასპინძლებისგან Yandex.Tank-ით.

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

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

რატომ არის საჭირო დირიჟორი, მაშინაც კი, თუ ორკესტრს შეუძლია დაკვრა?

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

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

ამჟამად, მასპინძელი აუზი შედგება სამი Ansible როლისგან:

• პირველი როლი აყენებს OS-ს,
• მეორე აწარმოებს ძირითად პარამეტრებს ჰოსტისთვის, LDAP ავტორიზაცია, მაგალითად,
• და მესამე დააინსტალირებს Yandex.Tank და მასთან დაკავშირებულ დამოკიდებულებებს დოკერის კონტეინერში.

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

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

მცირე შენიშვნა ipv6-ის შესახებ Docker-ში

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

Docker-ის ოფიციალურ ვებსაიტზე ipv6 დოკუმენტაციის მიხედვით, ipv6 ჩართულია daemon.json-ზე პარამეტრების დამატებით:

{
  "ipv6": true,
  "fixed-cidr-v6": "2001:db8:1::/64"
}

ამ შემთხვევაში, პროვაიდერმა უნდა გასცეს ipv6 ქვექსელი, რომელშიც დარეგისტრირდებით fixed-cidr-v6.
თუმცა, ჩვენ ავირჩიეთ სხვა ვარიანტი - ipv6 NAT და აი რატომ:

• ახლა დოკერი ვერ გამოიყენებს მხოლოდ ipv6-ით.
• თითოეულ კონტეინერში გლობალურად მარშრუტირებადი მისამართის ქონა ნიშნავს, რომ ყველა პორტი (თუნდაც გამოუქვეყნებელი) ექვემდებარება ყველას, თუ არ განხორციელდება დამატებითი ფილტრაცია.
• userland პროქსი პორტების გამოქვეყნებისთვის, iptables მხოლოდ ipv4-ისთვის.

ipv6 NAT არის დოკერის კონტეინერი, რომელიც თავად მართავს წესებს ip6tables-ში და არედაქტირებს მათ ახალი კონტეინერის დამატებისას.

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

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)

პრობლემა მოგვარდა Ansible როლზე ინიციალიზაციის დამატების შემდეგ, modprobe მოდულის გამოყენებით და OS-ის გაშვებისას ჩატვირთვის შემდეგ lineinfile-ის გამოყენებით:

- name: Add ip6table_nat module
 modprobe:
   name: ip6table_nat
   state: present
- name: Add ip6table_nat to boot
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

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

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

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

• შეიქმნა სერვერების „ჩასხმის“ პროცესი,
• სერვისების განვითარება და დანერგვა ერთიანია.

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

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

როგორ მივიღოთ კარგი დირიჟორი მინიმალური ინვესტიციით?

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

კონსული - სისტემა, რომელიც უზრუნველყოფს ორ ძირითად ფუნქციას:

• სერვისის აღმოჩენა,
• განაწილებული გასაღები-მნიშვნელობის საცავი.

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

• აქტიურია, როდესაც სერვისი თავად რეგისტრირდება HTTP API-ს გამოყენებით;
• პასიური - სერვისი ხელით უნდა დარეგისტრირდეს.

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

• საიდუმლოების შექმნისა და შენახვისა და მათი ცხოვრების ციკლის მართვის ერთი ცენტრი HTTP API-ს გამოყენებით.
• Transit Secrets Engine - მონაცემთა დაშიფვრა და გაშიფვრა შენახვის გარეშე. მონაცემთა დაშიფრული ფორმით გადაცემის შესაძლებლობა დაუცველ საკომუნიკაციო არხებზე.
• წვდომა პოლიტიკაზე, რომლის კონფიგურაცია მარტივია.
• საიდუმლოებაზე წვდომის აუდიტი.
• შესაძლებლობა შექმნათ თქვენი საკუთარი CA (სერთიფიკატის ორგანო) თქვენი ინფრასტრუქტურის ფარგლებში ხელმოწერილი სერთიფიკატების სამართავად.

ჩვენი ყველა მოთხოვნის გათვალისწინებით, დირიჟორის როლისთვის ორი ვარიანტი იყო შესაფერისი - Kubernetes და Nomad.

კუბერნეტები

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

Nomad

Tool ზემოთ ნახსენები კონსულითა და საცავებით ცნობილი კომპანია HashiCorp-ისგან.

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

რა მიმდინარეობს ამჟამად:

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

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

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

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

წყარო: www.habr.com