🥇Orkiestra performansu

Trudno się nie zgodzić, że najlepsi z ludzi
znajdują radość w cierpieniu.
Ludwig van Beethoven

Jestem Sergiusz, pracuję w Yandex.Money w zespole badawczym ds. wydajności. Chcę opowiedzieć Wam początek historii o naszej drodze do wykorzystania orkiestracji — jak wybieraliśmy narzędzia i na co zwracaliśmy uwagę. Wszystkie zdarzenia opisywane w artykule odbywają się w czasie rzeczywistym, więc drodzy czytelnicy, śledzicie rozwój sytuacji niemal na żywo.

Po co nam dyrygent w zespole?

Kim jest dyrygent? Od fr. diriger — zarządzać, kierować, prowadzić — w świecie muzyki to osoba, która prowadzi próbę i wykonanie muzyki zespołowej. W naszym przypadku to rolę te pełnią systemy orkiestracji i automatyzacji.

Ich rola nie różni się od roli dyrygenta w muzyce — są potrzebni, aby wspierać zespół, kierować i organizować jego grę.

Zespół zazwyczaj dysponuje pewnym zestawem zasobów — nazwijmy je serwerami, na których realizują swoje projekty.

Podejście do pozyskiwania i eksploatacji tych serwerów jest różnorodne. Oto kilka przykładów:

Zespół składa zapytanie, na przykład do grupy eksploatacyjnej, o udostępnienie im zasobów o określonych parametrach.
Grupa eksploatacyjna zapewnia im potrzebną ilość — cloud lub bare metal („gołe żelazo”) — i zobowiązuje się do ich utrzymywania w odpowiednim stanie zgodnie z SLA. Konfiguracja również jest przeprowadzana przez grupę eksploatacyjną.
Zespół otrzymuje tylko zasoby cloud lub bare metal od grupy eksploatacyjnej, konfigurację dokonuje samodzielnie.
Zespół samodzielnie „zakupuje” zasoby i w pełni je utrzymuje/konfiguruje samodzielnie.

W naszym zespole używamy serwerów, które muszą być utrzymywane — aktualizować system operacyjny, instalować nowe pakiety itd.

Dla siebie wyróżniliśmy je w dwa główne typy:

grupa czołgów,
grupa serwisowa.

Grupa czołgów składa się z hostów z Yandex.Tankiem.

Grupa serwisowa obejmuje wszystko, co związane z obsługą — to różne usługi wspierające cykl wydania, generowanie automatycznych raportów itd.

W pewnym momencie zarządzanie tym wszystkim ręcznie stało się niewygodne, więc zaczęliśmy myśleć o automatyzacji całego procesu, rozpoczynając od instalacji serwerów, a kończąc na opracowaniu, wdrożeniu i uruchomieniu naszego wewnętrznego serwisu.

Dlaczego dyrygent jest potrzebny, nawet jeśli orkiestra potrafi sama grać?

Na początek opanowaliśmy Ansible i zaczęliśmy instalować nasze serwery bare metal, aby być w mniejszym stopniu zależnymi od administratorów systemów — wygrywają wszyscy, zdobywamy nowe umiejętności i uwalniamy administratorów od części pracy, której i tak mają zawsze w nadmiarze. Dążymy do rozwoju poza swoją specjalizacją oraz autonomii zespołu, na ile to możliwe.

W firmie praca z Ansible jest już достаточно хорошо zorganizowana i uregulowana, więc łatwo włączyliśmy nasze rozwiązanie w ten proces.

Obecnie instalacja hostów składa się z trzech ról Ansible:

pierwsza rola instaluje system operacyjny,
druga wprowadza podstawowe ustawienia dla hosta, na przykład autoryzację LDAP,
a trzecia instaluje w kontenerze docker Yandex.Tank oraz niezbędne zależności.

Przejdźmy do usług, które wykorzystujemy w zespole.

Do naszych zadań w równym stopniu wykorzystujemy Kotlin i Pythona, a także trochę Golanga. Aby ujednolicić rozwój i wdrażanie naszych usług, postanowiliśmy pakować je w kontenery docker. Daje to wolność wyboru języka programowania, a jednocześnie reguluje jednolity format dostarczania aplikacji.

Mała uwaga na temat ipv6 w Docker

Część usług, z którymi współpracujemy, jest dostępna tylko przez ipv6, więc musieliśmy się dowiedzieć, jak zrealizować ipv6 dla kontenerów.

Zgodnie z dokumentacją na oficjalnej stronie Docker, ipv6 włącza się, dodając parametry do daemon.json:

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

Jednak dostawca musi przydzielić podsieć ipv6, którą zapiszecie w fixed-cidr-v6.
Jednak wybraliśmy inną opcję — ipv6 NAT, oto dlaczego:

Obecnie docker nie może być używany tylko z ipv6.
Obecność w każdym kontenerze globalnie routowanego adresu oznacza, że wszystkie porty (nawet nieopublikowane) stają się dostępne dla wszystkich, jeśli nie zostanie zastosowane dodatkowe filtrowanie.
proxy userland do publikacji portów, iptables tylko dla ipv4,.

ipv6 NAT to kontener docker, który sam zarządza regułami w ip6tables i edytuje je podczas dodawania nowego kontenera.

Aby to rozwiązanie działało poprawnie, trzeba było wykonać jeszcze szereg działań. Należy obowiązkowo zainicjować ip6table_nat w systemie. Obecność zainstalowanego modułu w systemie nie gwarantuje, że przy uruchomieniu moduł zostanie załadowany do jądra. Napotkaliśmy ten problem, gdy otrzymaliśmy taki błąd podczas uruchamiania kontenera z NAT na świeżym hoście:

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?)

Problem został rozwiązany po dodaniu do roli Ansible inicjalizacji za pomocą modułu modprobe i załadunku przy starcie systemu za pomocą 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'

A propos, na Habr jest dobrzy artykuł, która krótko i jasno opisuje zalety i wady różnych metod pracy z ipv6 w dockerze.

Ale wróćmy do naszego pytania z początku:
Dlaczego dyrygent jest potrzebny, nawet jeśli orkiestra potrafi sama grać?

Teraz wszyscy wiedzą, jak grać w naszej drużynie:

proces »nalewania« serwerów został stworzony,
rozwój i wdrażanie usług zostały ujednolicone.

Pojawia się zasadne pytanie — jak efektywnie i maksymalnie zautomatyzowanie wdrażać, aktualizować, kontrolować nasze usługi w kontenerach docker?

Pomimo że każdy członek orkiestry zna swoją partię, może zgubić wątek lub odejść od pierwotnego zamiaru. Tutaj dochodzimy do sytuacji, w której bez dyrygenta nasza orkiestra nie będzie skutecznie ćwiczyć i grać razem. Dyrygent odpowiada za wszystkie parametry wykonania, aby wszystko było zjednoczone jednym tempem i nastrojem.

Jak za minimalne środki zdobyć dobrego dyrygenta?

Temat orkiestracji jest dość dobrze rozwinięty na rynku. Ale najpierw porozmawiajmy o narzędziach pomocniczych, które mogą pomóc dyrygentowi.

Consul — system, który zapewnia dwie główne funkcje:

odkrywanie usług (service discovery),
rozproszoną pamięć klucz-wartość.

W naszej orkiestrze Consul będzie odpowiedzialny za rejestrację usług i przechowywanie ich konfiguracji. Istnieją dwa warianty rejestracji:

Aktywna — to gdy usługa rejestruje się sama, korzystając z API HTTP;
Pasywna — usługę należy wpisać ręcznie.

Vault — to magazyn, który standaryzuje i ujednolica bezpieczne przechowywanie oraz obsługę sekretów — haseł, certyfikatów.
Oto zalety, które uzyskamy korzystając z tego narzędzia:

Jednolity centrum tworzenia i przechowywania sekretów, zarządzanie ich cyklem życia za pomocą HTTP API.
Transit Secrets Engine — szyfrowanie-dekupowanie danych bez ich przechowywania. Możliwość przesyłania danych w zaszyfrowanej formie przez niezabezpieczone kanały komunikacyjne.
Polityki dostępu, które łatwo skonfigurować.
Audyt dostępu do sekretów.
Możliwość utworzenia własnego CA (Certificate Authority) do zarządzania certyfikatami samopodpisanymi w swojej infrastrukturze.

Biorąc pod uwagę wszystkie nasze wymagania, na rolę dyrygenta nadawały się dwa warianty — Kubernetes i Nomad.

Kubernetes

Ile już napisano o nim artykułów i książek (oto taki, na przykład), opublikowano referatów, więc napiszę krótko — to uniwersalny kombajn, który potrafi praktycznie wszystko. Odpłatność za to — nie zawsze łatwa konfiguracja i utrzymanie klastra na Kubernetes.

Nomad

Narzędzie od HashiCorp, firmy znanej z wymienionych wcześniej consul i vault.

Nomad wydawał się nam wystarczająco prosty w instalacji i konfiguracji w porównaniu do Kubernetes. Jeden plik binarny działa zarówno w trybie serwera, jak i klienta. W tym samym czasie Nomad obejmuje wszelki zakres zadań, które chcemy, aby realizował: zarządzanie klastrem, szybki harmonogram, wsparcie dla multidatacenter. Dodatkowo, przy użyciu consul i vault otrzymujemy bliższą integrację do orkiestracji naszych usług.

Co teraz jest w trakcie pracy:

przygotowaliśmy serwery do wdrożenia Consul,
w Consul zostanie wprowadzona konfiguracja klastra nomad, za pomocą której nomad powinien zostać wdrożony automatycznie,
równolegle będziemy instalować vault do przechowywania sekretów.

Pytanie do sali — czy warto wprowadzić dyrygenta do takich zadań, czy orkiestra i bez niego dobrze sobie radzi? Podzielcie się w komentarzach, co myślicie na ten temat.

Subskrybujcie nasz blog i bądźcie na bieżąco — wkrótce opowiemy, co w efekcie się udało, oraz czy skonfigurowaliśmy klaster nomad, tak jak tego oczekiwaliśmy.

Zapraszamy do naszego przytulnego czatu na Telegramie, gdzie zawsze możecie poprosić o radę, pomóc kolegom oraz po prostu porozmawiać na temat badań wydajności i innych zagadnień.

Źródło: habr.com