🥇Orkestar performansa

Teško da bi bilo pogrešno reći da najbolji među ljudima
dobijaju radost kroz patnju.
Ludwig van Beethoven

Ja sam Sergey, radim u Yandex.Money u timu za istraživanje performansi. Želim da vam ispričam početak priče o našem putu ka korišćenju orkestracije — kako smo birali alate i na šta smo pritom obraćali pažnju. Svi događaji iz članka se odvijaju u stvarnom vremenu, pa dragi čitatelji, pratite razvoj situacije gotovo uživo.

Zašto nam je potreban dirigent u timu?

Ko je zapravo dirigent? Od francuskog diriger — upravljati, usmeravati, voditi — u svetu muzike, to je osoba, vođa izvođenja i vežbanja ansambl muzike. U našem slučaju, to mesto zauzimaju sistemi orkestracije i automatizacije.

Njihova uloga se ni u čemu ne razlikuje od uloge dirigenta u muzici — potrebni su da pomognu timu, govore i organizuju njegovu igru.

Tim obično poseduje određeni set resursa — nazovimo ih serverima, na kojima realizuju svoje projekte.

Pristup dobijanju i korišćenju tih servera je raznolik. Nekoliko primera:

Tim šalje zahtev, na primer, u grupu eksploatacije, za obezbeđivanje resursa sa određenim parametrima.
Grupa eksploatacije im obezbeđuje potreban broj — cloud ili bare metal ("gola mašina") — i obavezuje se da ih održava u pristojnom stanju prema SLA. Podesavanje takođe vrši grupa eksploatacije.
Tim dobija samo cloud ili bare metal resurse od grupe eksploatacije, a podešavanje vrši samostalno.
Tim sam "nabavlja" resurse i potpuno ih podržava/podešava samostalno.

U našem timu se koriste serveri koji zahtevaju održavanje — ažuriranje operativnog sistema, instalacija novih paketa i sl.

Za sebe smo ih podelili u dve glavne kategorije:

tenkovska grupa,
servisna grupa.

Tenkovska grupa se sastoji od hostova sa Yandex.Tankom.

Servisna grupa obuhvata sve što je vezano za održavanje — to su razne usluge za obezbeđenje podrške u ciklusu izdanja, generisanje automatskih izveštaja i sl.

U jednom trenutku je svima postalo nezgodno upravljati tim ručno, te smo razmislili o automatizaciji cijelog procesa, počevši od "punjenja" poslužitelja do razvoja, postavljanja i pokretanja našeg internog servisa.

Zašto je dirigent potreban, čak i kada orkestar sam zna svirati?

Za početak smo savladali Ansible i počeli "puniti" naše bare metal poslužitelje kako bismo bili manje ovisni o sistemskim administratorima — ovdje svi profitiraju, stječemo nove vještine i oslobađamo administratore od dijela posla koji bez nas uvijek imaju dovoljno. Težimo razvoju izvan naše specijalnosti i autonomiji tima koliko god je moguće.

U firmi je rad s Ansibleom već dugo postavljen i reguliran, pa smo lako integrirali naše rješenje u taj proces.

Trenutno punjenje hostova sastoji se od tri Ansible uloge:

prva uloga instalira operativni sustav,
druga provodi osnovne postavke za host, poput LDAP autorizacije,
a treća instalira Yandex.Tank u docker kontejneru i prateće ovisnosti.

Pređimo na servise koje koristimo unutar tima.

Za svoje zadatke ravnomjerno koristimo Kotlin i Python, a malo i Golang. Kako bismo unificirali razvoj i implementaciju naših servisa, odlučili smo ih pakirati u docker kontejnere. To pruža slobodu izbora programskog jezika i istodobno regulira jedinstveni format isporuke aplikacije.

Mala napomena o ipv6 u Dockeru

Neki servisi s kojima komuniciramo dostupni su samo putem ipv6, pa smo morali istražiti kako omogućiti ipv6 za kontejnere.

Prema dokumentaciji o ipv6 na službenoj stranici Dockera, ipv6 se uključuje dodavanjem parametara u daemon.json:

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

Pri tome bi pružatelj trebao isporučiti ipv6 podsustav koji ćete unijeti u fixed-cidr-v6.
Međutim, odabrali smo drugu opciju — ipv6 NAT, i evo zašto:

Trenutno se docker ne može koristiti samo s ipv6.
Imati globalno rutirajuću adresu u svakom kontejneru znači da su sve portove (čak i neobjavljene) dostupne svima, osim ako se ne provodi dodatna filtracija.
userland proxy za objavljivanje portova, iptables samo za ipv4.

ipv6 NAT je docker-kontejner, koji sam upravlja pravilima u ip6tables i uređuje ih prilikom dodavanja novog kontejnera.

Kako bi ovo rešenje ispravno radilo, bilo je potrebno napraviti još nekoliko manipulacija. Obavezno inicijalizovati ip6table_nat u sistemu. Pojava instaliranog modula u sistemu ne garantuje da će se modul učitati u kernel prilikom pokretanja. Naišli smo na ovo kada smo dobili ovakvu grešku prilikom pokretanja kontejnera s NAT-om na svežem hostu:

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 je rešen nakon dodavanja u Ansible ulogu inicijalizacije pomoću modula modprobe i učitavanja prilikom pokretanja OS-a pomoću 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'

Usput, na habra postoji dobar članak, koji jasno opisuje prednosti i nedostatke različitih metoda za rad s ipv6 u dockeru.

Ali se vratimo našem pitanju postavljenom na početku:
Zašto je dirigent potreban, čak i kada orkestar sam zna svirati?

Sada svi razumeju kako je igrati u našem timu:

proces 'punjenja' servera je uspostavljen,
razvoj i implementacija usluga su standardizovani.

Pojavljuje se razuman pitanje — kako efikasno i maksimalno automatizovano implementirati, ažurirati, kontrolisati naše usluge u docker kontejnerima?

Iako svaki član orkestra zna svoju partiju, može se zbuniti i odmaknuti od prvobitne zamisli. Ovde dolazimo do toga da bez dirigenta naš orkestar neće efikasno vežbati i skladno svirati. Dirigent je odgovoran za sve parametre izvođenja, kako bi sve bilo ujedinjeno jedinstvenim tempom i raspoloženjem.

Kako sa minimalnim ulaganjima dobiti dobrog dirigenta?

Tema orkestracije je dovoljno dobro razvijena na tržištu. Ali prvo ćemo razgovarati o pomoćnim alatima koji mogu pomoći dirigentu.

Consul — sistem koji pruža dve osnovne funkcije:

otkrivanje usluga (service discovery),
raspodeljeno skladište ključ-vrednost.

U našem orkestru, Consul će biti odgovoran za registraciju usluga i čuvanje njihovih konfiguracija. Ima dva načina registracije:

Aktivna — kada se usluga sama registruje koristeći HTTP API;
Pasivna — uslugu je potrebno ručno registrovati.

Vault je skladište koje standardizira i unificira sigurno čuvanje i rad s tajnama — lozinkama, certifikatima.
Evo prednosti koje ćemo dobiti korištenjem ovog alata:

Jedinstveni centar za kreiranje i pohranu tajni, upravljanje njihovim životnim ciklusom putem HTTP API-ja.
Transit Secrets Engine — šifriranje-dešifriranje podataka bez njihova pohranjivanja. Mogućnost prijenosa podataka u šifriranom obliku preko nezaštićenih komunikacijskih kanala.
Pravila pristupa koja se lako podešavaju.
Auditing pristupa tajnama.
Mogućnost stvaranja vlastitog CA (Certificate Authority) za upravljanje samopotpisanim certifikatima unutar vlastite infrastrukture.

Uzimajući u obzir sve naše zahtjeve, kao dirigent su bila dva moguća rješenja — Kubernetes i Nomad.

Kubernetes

Koliko je već napisano članaka i knjiga o njemu (evo ovdje, na primjer), održano mnogo prezentacija, pa ću ukratko reći — to je univerzalni kombinator koji može praktički sve. Cijena za to — nije uvijek lagano konfigurirati i održavati klaster na Kubernetesu.

Nomad

Alat od HashiCorp, tvrtke poznate po prethodno spomenutom consul i vault.

Nomad nam se učinio dovoljno jednostavnim za instalaciju i konfiguraciju, u usporedbi s Kubernetesom. Jedna izvršna datoteka radi i u načinu rada servera i klijenta. Pri tome, Nomad pokriva cijeli popis zadataka koje želimo da rješava: upravljanje klasterom, brzi planer, podrška za multidatacenter. Plus, kada koristimo consul i vault, dobivamo bližu integraciju za orkestraciju naših servisa.

Što se trenutno radi:

pripremili smo poslužitelje za implementaciju Consul-a,
u Consul će biti upisana konfiguracija klastera nomad, pomoću koje će se nomad automatski implementirati,
paralelno ćemo instalirati vault za pohranu tajni.

Pitanje za dvoranu — vrijedi li imati dirigenta za takve zadatke ili se orkestracija može dobro obaviti i bez njega? Podijelite svoje mišljenje u komentarima.

Pretplatite se na naš blog i ostanite u kontaktu — uskoro ćemo objaviti do kojih smo rezultata došli i jesmo li postavili klaster nomad kako smo željeli.

Posjetite naš ugodni telegram kanal, gdje uvijek možete zatražiti savjet, pomoći kolegama i jednostavno razgovarati o istraživanju performansi i ne samo tome.

Izvor: habr.com