Puțin probabil să fie greșit să spunem că cei mai buni oameni
găsesc bucurie prin suferință.
Ludwig van Beethoven
Sunt Sergey, lucrez la Yandex.Money în echipa de cercetare a performanței. Vreau să vă povestesc începutul poveștii noastre despre drumul nostru spre utilizarea orchestration – cum am ales instrumentele și ce am avut în vedere. Toate evenimentele din articol se desfășoară în timp real, așa că, dragi cititori, urmăriți dezvoltarea situației aproape în direct.
De ce avem nevoie de un dirijor în echipă?
Cine este de fapt dirijorul? Din franțuzescul diriger – a conduce, a orienta, a coordona – în lumea muzicii, acesta este omul care conduce repetițiile și interpretarea muzicii de ansamblu. În cazul nostru, acest rol este ocupat de sistemele de orchestrare și automatizare.
Rolul lor nu diferă de rolul dirijorului în muzică – sunt necesari pentru a ajuta echipa, a îndruma și a organiza interpretarea acesteia.
În general, echipa dispune de un set de resurse – să le numim servere, pe care își desfășoară proiectele.
Abordarea pentru obținerea și exploatarea acestor servere este diversificată. Iată câteva exemple:
- Echipa face o solicitare, de exemplu către grupul de exploatare, pentru a le furniza resurse cu anumite specificații.
- Grupul de exploatare le oferă cantitatea necesară – cloud sau bare metal („hardver gol”) – și se angajează să le mențină în condiții corespunzătoare conform SLA. Configurarea este, de asemenea, realizată de grupul de exploatare.
- Echipa primește doar resurse cloud sau bare metal de la grupul de exploatare, configurarea fiind realizată de ea însuși.
- Echipa își 'cumpără' singură resursele și le întreține/configurează complet fără ajutor.
În echipa noastră, folosim servere care necesită întreținere – actualizarea sistemului de operare, instalarea de pachete noi etc.
Am împărțit aceste servere în două tipuri principale:
- grupul tancurilor,
- grupul de servicii.
Grupul tancurilor este format din gazde cu Yandex.Tank.
Grupul de servicii include tot ce ține de suport – este vorba de diverse servicii de asigurare a ciclului de lansare, generarea de rapoarte automate etc.
La un moment dat, gestionarea manuală a devenit incomodă, așa că ne-am gândit la automatizarea întregului proces, începând cu 'umplerea' serverelor și terminând cu dezvoltarea, implementarea și lansarea serviciului nostru intern.
De ce este necesar un dirijor, chiar dacă orchestra știe să cânte singură?
Pentru început, am învățat Ansible și am început să 'umplem' serverele noastre bare metal, pentru a fi mai puțin dependenți de administratorii de sistem - toată lumea câștigă, noi ne dezvoltăm abilitățile și îi scutim pe administratori de o parte din munca pe care oricum o au. Ne străduim să ne dezvoltăm în afara specialității noastre și spre autonomia echipei, cât mai mult posibil.
În companie, munca cu Ansible este deja bine stabilită și reglementată, așa că ne-am integrat cu ușurință soluția în acest proces.
Acum, umplerea host-urilor constă din trei roluri Ansible:
- primul rol instalează OS-ul,
- al doilea aplică setările de bază pentru host, cum ar fi autentificarea LDAP,
- iar al treilea instalează Yandex.Tank în containerul docker și dependențele sale asociate.
Să trecem la serviciile pe care le folosim în cadrul echipei.
Pentru sarcinile noastre, folosim în mod egal Kotlin și Python, și puțin Golang. Pentru a unifica dezvoltarea și desfășurarea serviciilor noastre, am decis să le împachetăm în containere docker. Acest lucru oferă libertatea de a alege limbajul de programare și reglează în același timp un format unic pentru livrarea aplicației noastre.
O mică observație despre ipv6 în Docker
O parte din serviciile cu care interacționăm sunt disponibile doar prin ipv6, așa că a trebuit să ne dăm seama cum să facem ipv6 pentru containere.
Conform documentației despre ipv6 de pe site-ul oficial Docker, ipv6 se activează adăugând parametrii în daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}În acest caz, furnizorul trebuie să ofere un subnet ipv6, pe care îl veți specifica în fixed-cidr-v6.
Cu toate acestea, am ales o altă variantă - ipv6 NAT, și iată de ce:
- În prezent, docker doar cu ipv6.
- Prezența unei adrese global rutabile în fiecare container înseamnă că toate porturile (chiar și cele nepublicate) devin accesibile tuturor, dacă nu se efectuează filtrare suplimentară.
- proxy-ul userland pentru publicarea porturilor, .
ipv6 NAT - este , care se ocupă singur de regulile din ip6tables și le modifică atunci când se adaugă un nou container.
Pentru ca această soluție să funcționeze corect, a fost necesar să efectuăm o serie de manevre suplimentare. Este esențial să se inițializeze ip6table_nat în sistem. Prezența modulelor instalate în sistem nu garantează că, la pornire, modulul va fi încărcat în nucleu. Ne-am confruntat cu aceasta când am primit următoarea eroare la pornirea containerului cu NAT pe un nou host:
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?)Problema a fost rezolvată după ce am adăugat în rolul Ansible o inițializare cu modulul modprobe și încărcarea la startul sistemului cu 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'Apropo, pe Habr există un articol bun , care descrie pe scurt și clar avantajele și dezavantajele fiecărei metode pentru a lucra cu ipv6 în docker.
Dar să ne întoarcem la întrebarea noastră formulată la început:
De ce este necesar un dirijor, chiar dacă orchestra știe să cânte singură?
Acum toată lumea își imaginează cum să joace în echipa noastră:
- procesul de „umplere” a serverelor a fost creat,
- dezvoltarea și desfășurarea serviciilor sunt unificate.
O întrebare rezonabilă apare — cum să desfășurăm, să actualizăm și să controlăm serviciile noastre în containerele docker cât mai eficient și automatizat posibil?
Deși fiecare participant al orchestrei își cunoaște partea, el poate să dezvăluie, să se abată de la concepția inițială. Aici ajungem la concluzia că, fără dirijor, orchestra noastră nu va repeta eficient și nu va cânta în armonie. Dirijorul este responsabil pentru toate parametrii executării, pentru a se asigura că totul este unit printr-un tempo și un spirit comun.
Cum putem obține un bun dirijor cu investiții minime?
Tema orchestrării este destul de bine dezvoltată pe piață. Dar mai întâi, să discutăm despre instrumentele auxiliare care pot ajuta dirijorul.
— sistem care oferă două funcții principale:
- descoperirea serviciilor (service discovery),
- stocare distribuită cheie-valoare.
În orchestra noastră, Consul va fi responsabil pentru înregistrarea serviciilor și salvarea configurațiilor acestora. Există două opțiuni de înregistrare:
- Activă — atunci când serviciul se înregistrează singur folosind API-ul HTTP;
- Pasivă — serviciul trebuie să fie înregistrat manual.
Vault este un depozit care standardizează și unifică stocarea și gestionarea sigură a secretelor - parole, certificate.
Iată avantajele pe care le vom obține folosind acest instrument:
- Un centru unic de creare și stocare a secretelor, gestionându-le ciclul de viață prin intermediul API-ului HTTP.
- Motorul de secrete Transit - criptarea și decriptarea datelor fără a le stoca. Posibilitatea de a transmite date în format criptat prin canale de comunicare nesecurizate.
- Politici de acces care pot fi configurate cu ușurință.
- Auditul accesului la secrete.
- Posibilitatea de a crea un CA (Autoritate de Certificare) propriu pentru gestionarea certificatelor auto-semnate în cadrul infrastructurii.
Având în vedere toate cerințele noastre, două opțiuni se potrivesc rolului de orchestrator - Kubernetes și Nomad.
Kubernetes
Câte articole și cărți au fost deja scrise despre el (iată , de exemplu), și câte prezentări au fost făcute, voi scrie pe scurt - este un combine universal care poate face aproape totul. Prețul pentru aceasta - setarea și întreținerea unui cluster pe Kubernetes nu sunt întotdeauna simple.
Nomad
de la HashiCorp, compania cunoscută pentru consul și vault menționate mai sus.
Nomad ne-a părut suficient de simplu de instalat și configurat, comparativ cu Kubernetes. Un singur fișier binar funcționează atât în modul server, cât și în modul client. De asemenea, Nomad acoperă întreaga listă de sarcini pe care dorim să le rezolve: gestionarea cluster-ului, un planificator rapid, suport pentru multicentră. Plus, prin utilizarea consul și vault, obținem o integrare mai strânsă pentru orchestraterea serviciilor noastre.
Ce este în lucru acum:
- am pregătit serverele pentru desfășurarea Consul,
- în Consul va fi introdusă configurația cluster-ului nomad, cu ajutorul căreia nomad ar trebui să fie desfășurat automat,
- în paralel vom instala vault pentru stocarea secretelor.
Întrebare în sală - merită să avem un orchestrator pentru astfel de sarcini sau orchestrarea se face bine și fără el? Spuneți-ne în comentarii ce părere aveți.
Abonați-vă la blogul nostru și rămâneți în conexiune - în curând vom povesti ce a ieșit în cele din urmă și dacă am configurat clusterul nomad așa cum ne-am dorit.
Vizitați nepoftit , unde puteți cere întotdeauna sfaturi, ajuta colegii și pur și simplu discuta despre cercetarea performanței și nu numai.
Sursa: habr.com
