Esituse orkester

Väidetavalt ei oleks vale öelda, et parimad inimesed
leiavad rõõmu läbi kannatuste.
Ludwig van Beethoven

Mina olen Sergei, töötan Yandex.Money's jõudlusuuringute meeskonnas. Tahaksin rääkida teile loo meie teekonnast orkestreerimise kasutamise poole — kuidas me valisime tööriistu ja mida arvesse võtsime. Kõik artiklis kirjeldatud sündmused toimuvad reaalajas, seega, kallid lugejad, jälgite olukorra arengut praktiliselt otse-eetris.

Miks on meil meeskonnas dirigeerija?

Kes on dirigeerija? Prantsuse sõnast diriger — juhtima, suunama, juhtima — muusikamaailmas on see inimene, kes juhib ansamblimuusika harjutamist ja esitamist. Meie puhul täidavad seda rolli orkestreerimise ja automatiseerimise süsteemid.

Nende roll ei erine muusikas dirigeerija rollist — nad on vajalikud, et aidata meeskonda, suunata ja korraldada nende mängu.

Tavaliselt omab meeskond teatud komplekti võimekusi — nimetame neid serveriteks, millel nad oma projekte ellu viivad.

Lähteviis nende serverite saamiseks ja kasutamiseks on erinev. Siin on mõned näited:

• Meeskond esitab taotluse näiteks ekspluatrohvale grupile, et saada neilt ressursse, millel on kindlad parameetrid.
• Ekspluateerimise grupp tagab vajaliku hulga — cloud või bare metal ("paljas raud") — ja kohustub neid hooldama vastavalt SLA-le. Seadistamine toimub samuti ekspluateerimise grupi poolt.
• Meeskond saab ainult cloud või bare metal ressursse ekspluateerimise grupilt, seadistamine toimub nende enda jõududega.
• Meeskond "soetab" ressursid iseseisvalt ja hooldab/seadistab need täielikult iseseisvalt.

Meie meeskonnas kasutatakse servereid, mida tuleb hooldada — uuendada OS-i, installida uusi pakette jne.

Oleme need jaganud kahte põhiliiki:

• tankigrupp,
• teenindusgrupp.

Tankigrupp koosneb serveritest, milles on Yandex.Tank.

Teenindusgrupp sisaldab kõike, mis on seotud teenindamisega — need on erinevad teenused, mis toetavad väljaandmise tsüklit, genereerivad automaatseid aruandeid jne.

Ühel hetkel muutus selle kõigega käsitsi hallata ja mõtlesime automatiseerimisele, alates serverite 'täitmisest' kuni meie siseteenuse arendamise, paigaldamise ja käivitamiseni.

Miks on vajalik dirigent, isegi kui orkester oskab ise mängida?

Küsimuse lihtsustamiseks õppisime Ansible'i ja hakkasime 'täitma' meie kettaseadmeid, et olla vähem sõltuvad süsteemiadministraatoritest - see on kõigile kasulik, me saame uusi oskusi ja vabastame administraatoreid osast tööst, millega neil on alati piisavalt tegemist. Me püüdleme arengu poole väljaspool oma eriala ja meeskonna autonoomiat, niipalju kui see on võimalik.

Ettevõttes on Ansible'i kasutamine juba ammu kehtestatud ja reguleeritud, seega suutsime oma lahenduse hõlpsasti sellesse protsessi integreerida.

Praegu koosneb hostide täitmine kolmest Ansible'i rollist:

• esimene roll installib operatsioonisüsteemi,
• teine rakendab hosti põhinähtused, nagu LDAP-autorit.
• ja kolmas paigaldab Docker-konteinerisse Yandex.Tanki ja sellega seotud sõltuvused.

Liigume teenuste juurde, mida me meeskonnas kasutame.

Oma ülesannete jaoks kasutame me võrdselt Kotlinit ja Pythoni ning veidi ka Golangi. Meie teenuste arenduse ja juurutamise ühtlustamiseks otsustasime need pakendada docker-konteineritesse. See annab programmeerimiskeele valiku vabaduse ning reguleerib samas rakenduse tarnimise ühtset formaati.

Mõned märkused ipv6 kohta Dockeris

Osa teenustest, millega me suhtleme, on saadaval ainult ipv6 kaudu, seetõttu pidime välja selgitama, kuidas aktiivselt ipv6 võimaldada konteinerites.

Docker ametlike ipv6 dokumentide kohaselt aktiveeritakse ipv6, lisades parameetreid daemon.json faili:

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

Sel juhul peab teenusepakkuja andma ipv6 alamvõrgu, mille kirjutate fixed-cidr-v6.
Kuid me valisime teise variandi — ipv6 NAT, ja siin on põhjused:

• Praegu ei saa dockerit kasutada ainult ipv6. Iga konteineri globaalne suunatav aadress tähendab, et kõik portid (isegi mittetäiendatud) on kõikidele avatud, kui ei rakendata täiendavat filtreerimist.
• userland proxy portide avalikustamiseks,
• iptables ainult ipv4 jaoks ipv6 NAT — see on.

docker-konteiner docker-konteiner, mis haldavad ip6tables reegleid iseseisvalt ja toimetavad neist uusi konteine lisades.

Selle lahenduse õigeks toimimiseks oli vajalik teha veel mitmeid toiminguid. Oluline on algatada ip6table_nat süsteemis. Isegi kui moodul on süsteemis installitud, ei garanteeri see, et see laaditakse tuuma käivitamisel. Kohtasime seda, kui saime järgmist tõrget, käivitades konteineri NAT-iga uuel hostil:

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?)

Probleem lahendati pärast Ansible'i rolli lisamist koos algatamisega modprobe'i mooduli abil ja os. käivitamisel lineinfile abil:

- name: Lisa ip6table_nat moodul
 modprobe:
   name: ip6table_nat
   state: present
- name: Lisa ip6table_nat käivitamiseks
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

Muide, Habr'is on hea artikkel, mis lühidalt ja selgelt kirjeldab erinevate ipv6 töötamise meetodite eeliseid ja puudusi Docker'is.

Aga naaseme meie algse küsimuse juurde:
Miks on vajalik dirigent, isegi kui orkester oskab ise mängida?

Nüüd kõik mõistavad, kuidas meie meeskonnas mängida:

• serverite „veetmine“ protsess on loodud,
• teenuste arendamine ja juurutamine on ühtlustatud.

Tõstatub mõistlik küsimus — kuidas efektiivselt ja võimalikult automatiselt juurutada, uuendada ja hallata meie teenuseid Docker-konteinerites?

Kuigi iga orkestri liige teab oma osa, võib ta siiski eksida ja eemalduda algsest ideest. Siinkohal jõuamegi järeldusele, et ilma dirigendita ei suuda meie orkester tõhusalt harjutada ja harmooniliselt mängida. Dirigent vastutab kõigi esitusparameetrite eest, et kõik kulgeks ühtse tempo ja meeleoluga.

Kuidas investeerida võimalikult vähe ja leida hea dirigent?

Orkestreerimise teema on turul hästi arenenud. Kuid kõigepealt räägime abivahenditest, mis võivad dirigendile kasuks tulla.

Consul — süsteem, mis pakub kahte põhifunktsiooni:

• teenuste avastamine (service discovery),
• jaotatud võtme-väärtuse salvestamine.

Meie orkestris vastutab Consul teenuste registreerimise ja nende konfiguratsioonide salvestamise eest. Registreerimiseks on kaks varianti:

• Aktiivne — see on siis, kui teenus registreerib end ise, kasutades HTTP API-d;
• Passiivne – teenust tuleb käsitsi seadistada.

Vault on hoiuruum, mis standardiseerib ja ühtlustab turvalise säilitamise ja töötamise saladustega – paroolid, sertifikaadid.
Siin on mõned eelised, mida sellest tööriistast kasutamisel saame:

• Üks sisu loomise ja saladuste säilitamise keskus, mis haldab nende elutsüklit läbi HTTP API.
• Transit Secrets Engine – andmete krüpteerimine ja dekrüpteerimine ilma nende salvestamiseta. Võimalus edastada andmeid krüpteeritud kujul kaitsmata sidekanalite kaudu.
• Kergesti seadistatavad juurdepääsupoliitikad.
• Saladustele juurdepääsu audit.
• Võimalus luua oma CA (Certificate Authority) enda infrastruktuuris iseaegsete sertifikaatide haldamiseks.

Kuna kõik meie nõuded arvesse võttes on kaks varianti dirigeerijaks sobivad – Kubernetes ja Nomad.

Kubernetes

Kui palju artikleid ja raamatuid on juba selle kohta kirjutatud (siin selline, näiteks), on peetud kõnesid, seega kirjutan lühidalt – see on universaalne masin, mis suudab praktiliselt kõike. Tasuda tuleb selle eest – mitte alati lihtne seadistamine ja Kubernetes'i klastri toetamine.

Nomad

Tööriista HashiCorpil, ettevõttel, mis on tuntud ülalmainitud consul ja vault'i poolest.

Nomad tundus meile oluliselt lihtsamini paigaldatav ja seadistatav kui Kubernetes. Üks binaarfail töötab nii serveri kui ka kliendi režiimis. Samuti katab Nomad kõik meie soovitud ülesanded: klastrihaldus, kiire planeerimine ja mitme andmekeskuse tugi. Pluss, kui kasutame Consulit ja Vaulti, saame tihedama integratsiooni meie teenuste orkestreerimiseks.

Praegu on töös:

• serverite ettevalmistamine Consuli juurutamiseks,
• Consulisse lisatakse nomadi klastrikonfiguratsioon, mille abil nomad tuleb automaatselt juurutada,
• samal ajal hakkame installima Vaulti saladuste hoidmiseks.

Küsimus päevakorras — kas on mõttekas luua orkestrator selliste ülesannete jaoks või saab ka ilma selleta hästi hakkama? Jagage oma mõtteid kommentaarides.

Liituge meie blogiga ja püsige kursis — varsti räägime, kuidas kõik välja kukkus ja kas me seadistasime nomadi klastri nii, nagu tahtsime.

Külastage meie hubast Telegrami chatti, kus saate alati küsida nõu, aidata kolleegidel ja lihtsalt arutada jõudlusuuringute teemasid ning mitte ainult.

Allikas: habr.com