Težko bi bilo reči, da najboljši ljudje
pridobivajo veselje skozi trpljenje.
Ludwig van Beethoven

Jaz sem Sergej, delam pri Yandex.Money v skupini za raziskovanje zmogljivosti. Rad bi vam povedal začetek zgodbe o našem potovanju k uporabi orkestracije — kako smo izbirali orodja in kaj smo pri tem upoštevali. Vse dogodke v članku se dogajajo v realnem času, zato vi, dragi bralci, spremljate razvoj situacije skoraj v živo.
Zakaj potrebujemo dirigenta v ekipi?
Kdo je dirigent? Iz francoščine diriger — upravljati, usmerjati, voditi — v svetu glasbe je to oseba, ki vodi učenje in izvajanje ansambelske glasbe. V našem primeru to mesto zasedajo sistemi orkestracije in avtomatizacije.
Njihova vloga se ne razlikuje od vloge dirigenta v glasbi — potrebni so, da pomagajo ekipi, usmerjajo in organizirajo njeno igro.
Ekipa ima običajno neki nabor zmogljivosti — poimenujmo jih strežniki, na katerih izvajajo svoje projekte.
Pristop k pridobivanju in izkoriščanju teh strežnikov je raznolik. Nekaj primerov:
- Ekipa pošlje zahtevo, na primer skupini za obratovanje, na zagotavljanje virov z določenimi parametri.
- Skupina za obratovanje jim zagotovi potrebno količino — cloud ali bare metal (»golo železo«) — in se zavezuje, da jih bo vzdrževala v ustreznem stanju v skladu z SLA. Nastavitev prav tako opravi skupina za obratovanje.
- Ekipa prejme le cloud ali bare metal vire od skupine za obratovanje, nastavitev pa izvede sama.
- Ekipa sama „naroči“ vire in jih popolnoma vzdržuje/nastavlja samostojno.
V naši ekipi uporabljamo strežnike, ki jih je treba vzdrževati — posodabljati OS, namestiti nove pakete itd.
Za sebe smo jih razdelili v dve osnovni vrsti:
- tanka skupina,
- servisna skupina.
Tanka skupina je sestavljena iz gostiteljev z Yandex.Tankom.
Servisna skupina vključuje vse, kar je povezano z vzdrževanjem — to so različne storitve za zagotavljanje podpore ciklu sproščanja, generiranje avtomatskih poročil itd.
V enem trenutku je postalo nepraktično upravljati s tem ročno, zato smo se odločili za avtomatizacijo celotnega procesa, od 'nalivanja' strežnikov do razvoja, nalaganja in zagon našega notranjega servisa.
Zakaj je dirigent potreben, tudi če orkester zna sam igrati?
Najprej smo usvojili Ansible in začeli 'nalivati' naše bare metal strežnike, da bi bili manj odvisni od sistemskih administratorjev – koristi imamo vsi, pridobivamo nove veščine in razbremenjujemo administratorje dela, ki ga že tako imajo dovolj. Stremimo k razvoju izven svoje specializacije in avtonomnosti ekipe, kolikor je to mogoče.
V podjetju je delo z Ansible že dolgo časa urejeno in regulirano, zato smo enostavno vgradili svoje rešitev v ta proces.
Danes se nalivanje gostiteljev sestoji iz treh vlog Ansible:
- prva vloga namesti OS,
- druga izvajanje osnovnih nastavitev za gostitelja, na primer LDAP-avtorizacijo,
- in tretja namesti Yandex.Tank v docker kontejnerju ter povezane odvisnosti.
Preidimo k storitvam, ki jih uporabljamo znotraj ekipe.
Za naloge enakovredno uporabljamo Kotlin in Python, malo pa tudi Golang. Da bi poenotili razvoj in uvajanje naših storitev, smo se odločili, da jih zapakiramo v docker kontejnerje. To nam omogoča svobodo izbire programskega jezika in hkrati ureja enoten format dostave naše aplikacije.
Majhna opomba glede ipv6 v Dockerju
Nekatere storitve, s katerimi sodelujemo, so dostopne samo prek ipv6, zato smo se morali naučiti, kako omogočiti ipv6 za kontejnerje.
Po dokumentaciji o ipv6 na uradni spletni strani Dockerja, se ipv6 omogoči z dodajanjem parametrov v daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Pri tem mora ponudnik dodeliti ipv6 podomrežje, ki ga vpisujete v fixed-cidr-v6.
Vendar pa smo izbrali drugo možnost – ipv6 NAT, in to je razlog:
- Trenutno docker samo z ipv6.
- To, da ima vsak kontejner globalno usmerljiv naslov, pomeni, da so vsi porti (tudi neopublikovani) dostopni vsem, razen če se ne izvaja dodatno filtriranje.
- userland proxy za objavo portov, .
ipv6 NAT je , ki sam upravlja pravili v ip6tables in jih ureja ob dodajanju novega kontejnerja.
Da bi ta rešitev pravilno delovala, je bilo potrebno izvesti še vrsto drugih postopkov. Obvezno je treba inicializirati ip6table_nat v sistemu. Obstoječ modul v sistemu ne zagotavlja, da bo ob zagonu modul naložen v jedro. S tem smo se srečali, ko smo ob zagonu kontejnerja z NAT na svežem gostitelju dobili naslednjo napako:
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?)Težava se je rešila po dodajanju inicializacije preko modula modprobe v vlogo Ansible in nalaganja ob zagonu OS z uporabo 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'Sicer pa na habru obstaja dobra , ki kratko in jasno opisuje prednosti in slabosti določenih metod dela z ipv6 v dockerju.
Toda vrnimo se k našemu vprašanju, postavljenem na začetku:
Zakaj je dirigent potreben, tudi če orkester zna sam igrati?
Zdaj vsi razumejo, kako igrati v naši ekipi:
- postopek 'nalivanja' strežnikov je ustvarjen,
- razvoj in uvedba storitev sta poenotena.
Pojavi se upravičeno vprašanje — kako učinkovito in čim bolj avtomatizirano uvajati, posodabljati in nadzorovati naše storitve v docker kontejnerjih?
Kljub temu, da vsak član orkestra pozna svojo vlogo, se lahko zmoti in oddalji od prvotne zasnove. Tukaj pridemo do tega, da brez dirigenta naš orkester ne bo učinkovito vadil in usklajeno igral. Dirigent odgovarja za vse parametre izvedbe, da je vse povezano z enim tempom in razpoloženjem.
Kako z minimalnimi vlaganji dobiti dobrega dirigenta?
Tema orkestracije je na trgu dovolj dobro razvita. Preden pa se pogovorimo o pomožnih orodjih, ki lahko pomagajo dirigentu.
— sistem, ki zagotavlja dve osnovni funkciji:
- odkrivanje storitev (service discovery),
- porazdeljeno shranjevanje ključ-vrednost.
V našem orkestru bo Consul odgovoren za registracijo storitev in shranjevanje njihovih konfiguracij. Obstoja dve možnosti registracije:
- Aktivna — to je, ko se storitev sama registrira z uporabo HTTP API;
- Pasivna — storitev je treba ročno zapisati.
Vault je skladište koje standardizira i unificira sigurno čuvanje i rad sa tajnama — lozinke, certifikate.
Evo prednosti koje ćemo dobiti korišćenjem ovog alata:
- Jedinstveni centar za kreiranje i čuvanje tajni, upravljanje njihovim životnim ciklusom putem HTTP API.
- Transit Secrets Engine — šifriranje-dešifriranje podataka bez njihove pohrane. Mogućnost prenošenja podataka u šifrovanom obliku preko nezaštićenih komunikacionih kanala.
- Politike pristupa koje se lako podešavaju.
- Revizija pristupa tajnama.
- Mogućnost kreiranja vlastitog CA (Certificate Authority) za upravljanje samopotpisanim certifikatima unutar svoje infrastrukture.
Uzimajući u obzir sve naše zahteve, za ulogu dirigenta dolazile su u obzir dve opcije — Kubernetes i Nomad.
Kubernetes
Koliko je već napisanih članaka i knjiga o njemu (evo , na primer), održano predavanja, da ću napisati ukratko — ovo je univerzalni kombajn koji može praktično sve. Cena za to — nije uvek laka konfiguracija i održavanje klastera na Kubernetesu.
Nomad
od HashiCorp-a, kompanije poznate po gore spomenutim consul i vault.
Nomad nam se učinio dovoljno jednostavnim za instalaciju i podešavanje, u poređenju sa Kubernetesom. Jedan binarni fajl radi i kao server i kao klijent. Pored toga, Nomad pokriva ceo spisak zadataka koje želimo da reši: upravljanje klasterom, brzi planirnik, podrška za multidatacentar. Plus, korišćenjem consula i vault-a dobijamo bližu integraciju za orkestraciju naših servisa.
Šta je sada u radu:
- pripremili smo servere za implementaciju Consul-a,
- u Consul će biti unesena konfiguracija klastera nomad, prema kojoj bi nomad trebao biti automatski implementiran,
- paralelno ćemo instalirati vault za skladištenje tajni.
Pitanje u sali — da li treba imati dirigenta za takve zadatke ili orkestracija i bez njega dobro funkcioniše? Ispričajte u komentarima, šta mislite o tome.
Pratite naš blog i ostanite u kontaktu — uskoro ćemo pričati o tome šta je na kraju ispalo i da li smo postavili klaster nomad onako kako smo želeli.
Posetite naš prijatan , gde uvek možete zatražiti savet, pomoći kolegama i jednostavno razgovarati o istraživanju performansi i ne samo.
Izvor: habr.com
