Performance orkester

Det ville næppe være forkert at sige, at de bedste mennesker
finder glæde gennem lidelse.
Ludwig van Beethoven

Jeg er Sergey, jeg arbejder i Yandex.Money i et team, der forsker i ydeevne. Jeg vil fortælle dig begyndelsen af historien om vores vej til brugen af orkestrering — hvordan vi valgte værktøjer og hvad vi overvejede. Alle begivenhederne i artiklen sker i realtid, så kære læsere, følger I udviklingen næsten i direkte sendefejl.

Hvorfor har vi en dirigent i teamet?

Hvem er dirigenten? Fra fransk diriger — at lede, styre, administrere — i musikverdenen refererer det til en person, der leder øvning og udførelse af ensemblemusik. I vores tilfælde udfylder orkestrerings- og automatiseringssystemer denne rolle.

Deres rolle adskiller sig ikke fra dirigentens rolle i musikken — de er nødvendige for at hjælpe teamet, styre og organisere deres spil.

Som regel har teamet et bestemt sæt kapaciteter — lad os kalde dem servere, hvorpå de implementerer deres projekter.

Tilgangen til opnåelse og drift af disse servere er mangesidet. Nogle eksempler:

• Teamet sender en anmodning, eksempelvis til driftsgruppen, om at give dem ressourcer med bestemte specifikationer.
• Driftsgruppen giver dem det nødvendige antal — cloud eller bare metal — og forpligter sig til at holde dem i god stand i overensstemmelse med SLA. Opsætningen udføres også af driftsgruppen.
• Teamet modtager kun cloud- eller bare metal-ressourcer fra driftsgruppen og foretager opsætningen selv.
• Teamet 'køber' selv ressourcerne og vedligeholder/opsætter dem helt selv.

I vores team anvendes servere, som vi skal vedligeholde — opdatere OS, installere nye pakker osv.

Vi har kategoriseret dem i to hovedtyper:

• tankgruppe,
• servicegruppe.

Tankgruppen består af værter med Yandex.Tank.

Servicegruppen inkluderer alt, der vedrører vedligeholdelse — det er forskellige tjenesteydelser til støtte af udgivelsescirklen, generering af automatiske rapporter osv.

På et tidspunkt blev det uhandy at administrere alt dette manuelt, og vi overvejede at automatisere hele processen, fra 'skænkning' af servere til udviklingen, implementeringen og lanceringen af vores interne service.

Hvorfor er en dirigent nødvendig, selvom orkestret kan spille selv?

Til at begynde med lærte vi Ansible at kende og begyndte at 'skænke' vores bare metal-servere, så vi blev mindre afhængige af systemadministratorer - her vinder alle, vi får nye færdigheder og aflastes administratorernes arbejde, som de i forvejen har rigelig af. Vi stræber efter udvikling uden for vores specialitet og teamets autonomi, så vidt det er muligt.

I virksomheden er arbejdet med Ansible allerede indarbejdet og reguleret i længere tid, så vi nemt kunne integrere vores løsning i denne proces.

I øjeblikket består skænkning af værter af tre Ansible-roller:

• den første rolle installerer OS,
• den anden anvender grundlæggende indstillinger for værten, f.eks. LDAP-godkendelse,
• og den tredje installerer Yandex.Tank i en docker-container sammen med de nødvendige afhængigheder.

Lad os gå videre til de tjenester, vi bruger internt i teamet.

Til vores opgaver bruger vi ligeligt Kotlin og Python, samt lidt Golang. For at ensarte udviklingen og implementeringen af vores tjenester besluttede vi at pakke dem ind i docker-containere. Dette giver friheden til at vælge programmeringssprog og samtidig regulerer det et ensartet format for levering af vores applikation.

En lille bemærkning om ipv6 i Docker

Nogle af de tjenester, vi interagerer med, er kun tilgængelige via ipv6, så vi måtte finde ud af, hvordan man aktiverer ipv6 for containerne.

Ifølge dokumentationen for ipv6 på Docks officielle side aktiveres ipv6 ved at tilføje parametre i daemon.json:

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

Udbyderen skal dog tildele et ipv6-subnet, som du indtaster i fixed-cidr-v6.
Vi valgte dog en anden mulighed - ipv6 NAT, og her er hvorfor:

• I øjeblikket kan docker ikke bruges kun med ipv6.
• At have en globalt routbar adresse i hver container betyder, at alle porte (selv de ikke-publicerede) bliver tilgængelige for alle, medmindre der udføres yderligere filtrering.
• userland proxy til publicering af porte, iptables kun for ipv4.

ipv6 NAT er docker-container, der selv administrerer reglerne i ip6tables og redigerer dem, når der tilføjes en ny container.

For at denne løsning fungerede korrekt, var det nødvendigt at udføre en række yderligere manipulationer. Det er bestemt nødvendigt at initialisere ip6table_nat i systemet. At have modulet installeret i systemet garanterer ikke, at modulet vil blive indlæst i kernen ved opstart. Vi stødte på dette, da vi fik følgende fejl ved opstart af containeren med NAT på en ny vært:

2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: kan ikke ændre biblioteket til '/lib/modules': Ingen sådan fil eller bibliotek
ip6tables v1.6.2: kan ikke initialisere ip6tables tabel `filter': Tabel findes ikke (skal du bruge insmod?)

Problemet blev løst efter at have tilføjet initialisering til Ansible-rollen ved hjælp af modprobe-modulet og indlæsning ved opstart af OS ved hjælp af lineinfile:

- name: Tilføj ip6table_nat modul
 modprobe:
   name: ip6table_nat
   state: present
- name: Tilføj ip6table_nat til opstart
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

Forresten, der er en god artikel på Habr, artikel, der kort og klart beskriver fordele og ulemper ved forskellige metoder til at arbejde med ipv6 i docker.

Men lad os vende tilbage til vores spørgsmål stillet i starten:
Hvorfor er en dirigent nødvendig, selvom orkestret kan spille selv?

Nu ved alle, hvordan man spiller i vores team:

• processen med ‘fyldning’ af servere er oprettet,
• udvikling og deployment af tjenester er ensartede.

Der opstår et rimeligt spørgsmål – hvordan kan vi effektivt og så automatiseret som muligt deployere, opdatere og overvåge vores tjenester i docker-containere?

På trods af at hver deltager i orkesteret kender sin part, kan han komme til at miste fokus og afvige fra den oprindelige tanke. Her kommer vi til den konklusion, at uden en dirigent vil vores orkester ikke effektivt kunne øve og spille i harmoni. Dirigenten er ansvarlig for alle udførelsesparametre, for at alt er forenet med en fælles tempo og stemning.

Hvordan kan man få en god dirigent med minimale investeringer?

Emnet orkestrering er ret godt udviklet på markedet. Men lad os først tale om de hjælpeværktøjer, der kan hjælpe dirigenten.

Consul – et system, der tilbyder to hovedfunktioner:

• tjenesteopdagelse (service discovery),
• fordelt nøgle-værdi lager.

I vores orkester vil Consul være ansvarlig for registrering af tjenester og opbevaring af deres konfigurationer. Der er to muligheder for registrering:

• Aktiv – det er, når tjenesten registrerer sig selv ved hjælp af HTTP API;
• Passiv – tjenesten skal skrives manuelt.

Vault er et lager, der standardiserer og ensretter sikker opbevaring og brug af hemmeligheder — adgangskoder, certifikater.
Her er fordelene, vi får ved at bruge dette værktøj:

• Et centralt sted til oprettelse og opbevaring af hemmeligheder, styring af deres livscyklus via HTTP API.
• Transit Secrets Engine — kryptering-afkryptering af data uden at gemme dem. Mulighed for at overføre data i krypteret form over usikre kommunikationskanaler.
• Adgangspolitikker, der er nemme at konfigurere.
• Audit af adgang til hemmeligheder.
• Mulighed for at oprette sin egen CA (Certificate Authority) til at administrere selvsignerede certifikater inden for sin infrastruktur.

Under hensyntagen til alle vores krav var der to mulige kandidater til rollen som orkestrator — Kubernetes og Nomad.

Kubernetes

Der er allerede skrevet mange artikler og bøger om det (her sådan en, for eksempel), og der er givet mange præsentationer, så jeg skriver kort — det er en universel kombineret løsning, der kan næsten alt. Prisen for dette er ikke altid let konfiguration og vedligeholdelse af en Kubernetes-klynge.

Nomad

Værktøj fra HashiCorp, et selskab kendt for de nævnte consul og vault.

Nomad syntes at være lettere at installere og konfigurere end Kubernetes. Én binær fil fungerer både som server og klient. Samtidig dækker Nomad hele listen af opgaver, som vi ønsker, det skal løse: klyngehåndtering, hurtig planlægger, support for multidatacenter. Plus ved at bruge consul og vault får vi tættere integration til orkestrering af vores tjenester.

Hvad der arbejdes på nu:

• vi har forberedt servere til udrulning af Consul,
• konfigurationen af nomad-klyngen vil blive indtastet i Consul, hvormed nomad skal udrulles automatisk,
• samtidig vil vi installere vault til opbevaring af hemmeligheder.

Spørgsmålet på gulvet — er det nødvendigt at have en orkestrator til sådanne opgaver, eller fungerer orkestrering godt uden den? Fortæl os i kommentarerne, hvad du synes om det.

Tilmeld dig vores blog og hold kontakten — snart fortæller vi, hvad vi opnåede, og om vi fik konfigureret klyngen nomad, som vi ønskede.

Besøg vores hyggelige telegramchat, hvor du altid kan bede om råd, hjælpe kolleger og bare tale om ydelsestests og andet.

Kilde: habr.com