No seria equivocat dir que el millor dels homes
trobar l'alegria a través del patiment.
Ludwig van Beethoven
Em dic Sergey, treballo a Yandex.Money a l'equip d'investigació del rendiment. Vull explicar-vos l'inici de la història sobre el nostre camí cap a l'ús de l'orquestració: com vam triar els instruments i què vam tenir en compte. Tots els esdeveniments de l'article tenen lloc en temps real, de manera que vosaltres, estimats lectors, esteu seguint l'evolució de la situació gairebé en directe.
Per què necessitem un director al nostre equip?
Qui és director d'orquestra? De fr. diriger - per gestionar, dirigir, liderar - en el món de la música - és una persona que és el líder de l'aprenentatge i la interpretació de la música de conjunt. En el nostre cas, aquest lloc està ocupat per sistemes d'orquestració i automatització.
El seu paper no és diferent del paper d'un director en la música: són necessaris per ajudar l'equip, guiar i organitzar el seu joc.
Com a regla general, un equip té un determinat conjunt de capacitats, anomenem-los servidors, sobre les quals implementa els seus projectes.
L'enfocament per obtenir i operar aquests servidors és variat. Alguns exemples:
- L'equip fa una sol·licitud, per exemple, al grup d'operacions, per proporcionar-los recursos amb determinats paràmetres.
- L'equip d'operacions els proporciona la quantitat necessària -núvol o metall nu- i es compromet a mantenir-los en condicions adequades segons el SLA. La configuració també la porta a terme l'equip d'operacions.
- L'equip només rep recursos en núvol o metall nu del grup d'operacions i els configura per si mateix.
- El propi equip "compra" els recursos i els manté/configura de manera totalment independent.
El nostre equip utilitza servidors que necessiten ser compatibles: actualitzar el sistema operatiu, instal·lar nous paquets, etc.
Per nosaltres mateixos, els hem dividit en dos tipus principals:
- grup de tancs,
- grup de serveis.
El grup de tancs està format per amfitrions amb Yandex.Tank.
El grup de serveis inclou tot allò relacionat amb el manteniment: es tracta de diversos serveis per donar suport al cicle de llançament, generar informes automàtics, etc.
En un moment donat, tot això es va convertir en incòmode de gestionar manualment, i vam pensar en automatitzar tot el procés, començant per la “càrrega” de servidors i acabant amb el desenvolupament, llançament i llançament del nostre servei intern.
Per què es necessita un director, encara que la mateixa orquestra pugui tocar?
Per començar, vam dominar Ansible i vam començar a "abocar" els nostres servidors nus per tal de dependre menys dels administradors del sistema: aquí tothom guanya, adquirim noves habilitats i alleujarem els administradors d'alguna de la feina que sempre en tenen prou sense nosaltres. . Ens esforcem per desenvolupar-nos més enllà de la nostra especialitat i l'autonomia de l'equip tant com sigui possible.
A l'empresa, el treball amb Ansible s'ha configurat i regulat des de fa força temps, de manera que hem integrat fàcilment la nostra solució en aquest procés.
Actualment, el conjunt d'amfitrions consta de tres rols Ansible:
- el primer rol instal·la el sistema operatiu,
- el segon executa la configuració bàsica per a l'amfitrió, l'autorització LDAP, per exemple,
- i el tercer instal·la Yandex.Tank i dependències relacionades en un contenidor Docker.
Passem als serveis que fem servir dins de l'equip.
Per a les nostres tasques, fem servir Kotlin i Python per igual, i una mica més de Golang. Per unificar el desenvolupament i el desplegament dels nostres serveis, vam decidir empaquetar-los en contenidors Docker. Això us dóna la llibertat d'escollir un llenguatge de programació i alhora regula un format de lliurament uniforme per a la vostra aplicació.
Una petita nota sobre ipv6 a Docker
Alguns dels serveis amb els quals interactuem només estan disponibles mitjançant ipv6, així que vam haver d'esbrinar com fer ipv6 per als contenidors.
Segons la documentació d'ipv6 al lloc web oficial de Docker, ipv6 s'habilita afegint paràmetres a daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}En aquest cas, el proveïdor ha d'emetre una subxarxa ipv6, a la qual us registrareu fixed-cidr-v6.
No obstant això, vam triar una altra opció: IPv6 NAT, i aquí teniu el perquè:
- Ara docker només amb ipv6.
- Tenir una adreça encaminable globalment a cada contenidor significa que tots els ports (fins i tot els no publicats) estan exposats a tothom tret que es realitzi un filtratge addicional.
- proxy userland per als ports de publicació, .
IPv6 NAT és , que gestiona les regles en ip6tables i les edita quan afegeix un contenidor nou.
Perquè aquesta solució funcionés correctament, calia fer una sèrie d'altres manipulacions. Assegureu-vos d'inicialitzar ip6table_nat al sistema. La presència d'un mòdul instal·lat al sistema no garanteix que el mòdul es carregarà al nucli a l'inici. Ens hem trobat amb això quan hem rebut aquest error en executar un contenidor amb NAT en un amfitrió nou:
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?)El problema es va resoldre després d'afegir la inicialització al rol Ansible mitjançant el mòdul modprobe i carregar-lo a l'inici del sistema operatiu mitjançant 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'Per cert, n'hi ha un de bo al centre , que descriu breument i clarament els avantatges i desavantatges d'un o altre mètode per executar ipv6 a docker.
Però tornem a la pregunta que vam fer al principi:
Per què es necessita un director, encara que la mateixa orquestra pugui tocar?
Ara tothom s'imagina com jugar al nostre equip:
- s'ha creat el procés de "abocar" servidors,
- desenvolupament i desplegament de serveis estan unificats.
Sorgeix una pregunta raonable: com implementar, actualitzar i controlar els nostres serveis als contenidors Docker de la manera més eficient i automàtica possible?
Tot i que cada membre de l'orquestra coneix la seva part, es pot confondre i desviar-se de la idea original. Aquí arribem a la conclusió que sense un director la nostra orquestra no assajarà amb eficàcia i tocarà de manera coherent. El director és responsable de tots els paràmetres de l'actuació, assegurant que tot estigui unit per un sol tempo i estat d'ànim.
Com aconseguir un bon conductor amb una inversió mínima?
El tema de l'orquestració està força ben desenvolupat al mercat. Però primer, parlem d'eines auxiliars que poden ajudar el conductor.
- un sistema que ofereix dues funcions principals:
- descobriment de serveis,
- emmagatzematge de valor-clau distribuït.
A la nostra orquestra, Cònsol serà l'encarregat de registrar els serveis i emmagatzemar les seves configuracions. Hi ha dues opcions de registre:
- Actiu és quan el servei es registra mitjançant l'API HTTP;
- Passiu: el servei s'ha de registrar manualment.
Vault és un repositori que estandarditza i unifica l'emmagatzematge segur i el maneig de secrets: contrasenyes, certificats.
Aquests són els avantatges que obtindrem utilitzant aquesta eina:
- Un centre únic per crear i emmagatzemar secrets i gestionar el seu cicle de vida mitjançant l'API HTTP.
- Transit Secrets Engine: xifratge i desxifrat de dades sense desar-les. La capacitat de transmetre dades en forma xifrada per canals de comunicació no segurs.
- Polítiques d'accés fàcils de configurar.
- Auditoria d'accés als secrets.
- La possibilitat de crear la vostra pròpia CA (Autoritat de certificació) per gestionar els certificats autofirmats dins de la vostra infraestructura.
Tenint en compte tots els nostres requisits, dues opcions eren adequades per al paper de director: Kubernetes i Nomad.
Kubernetes
Quants articles i llibres ja s'han escrit sobre ell (aquí , per exemple), hi ha informes que escriuré breument: aquesta és una recol·lectora universal que pot fer gairebé tot. El preu d'això és que configurar i mantenir un clúster a Kubernetes no sempre és fàcil.
nòmada
de HashiCorp, una empresa coneguda pel cònsol i la volta esmentats anteriorment.
Hem trobat que Nomad és bastant més fàcil d'instal·lar i configurar que Kubernetes. Un fitxer binari funciona tant en mode servidor com en mode client. Paral·lelament, Nomad cobreix tota la llista de tasques que volem que resolgui: gestió de clúster, programador ràpid, suport multidatacenter. A més, quan utilitzem cònsol i volta, obtenim una integració més estreta per orquestrar els nostres serveis.
Què està en curs actualment:
- servidors preparats per al desplegament de Cònsol,
- la configuració del clúster nòmada s'introduirà a Consul, amb l'ajuda de la qual s'hauria de desplegar automàticament,
- Paral·lelament, instal·larem Vault per emmagatzemar secrets.
Pregunta per al públic: val la pena contractar un director per a aquestes tasques o l'orquestra va bé sense ell? Digueu-nos als comentaris què en penseu.
Subscriviu-vos al nostre bloc i mantingueu-vos en contacte: aviat us explicarem què va passar al final i si vam configurar el clúster nòmada com volíem.
Vine al nostre acollidor , on sempre podeu demanar consell, ajudar els companys i només xerrar sobre investigacions de productivitat i molt més.
Font: www.habr.com
