Esitlusorkester

Vähe on tõenäoline, et oleks vale öelda, et parimad inimesed
leidnud rõõmu kannatuste kaudu.
Ludwig van Beethoven

Mina olen Sergei, töötan Yandex.Money's jõudlusuuringute meeskonnas. Soovin rääkida teile loo algusest meie teekonnast orkestreerimise kasutusele võtmisel — kuidas me valisime tööriistu ja mida me seejuures arvesse võtsime. Kõik artikliesitatud sündmused toimuvad reaalajas, seega, kallid lugejad, saate jälgida olukorra arengut peaaegu otse-eetris.

Miks meil on tiimis dirigent?

Kes on siis dirigent? Prantsuse keelest diriger — juhtima, suunama, korraldama — muusika maailmas on see inimene, kes juhib ansambli muusika harjutamist ja esitust. Meie puhul on selle asemel süsteemid orkestreerimise ja automatiseerimise.

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

Tavaliselt on meeskonnal teatud võimekuste kogu — nimetame neid serveriteks, millel nad oma projekte ellu viivad.

Lähenemised nende serverite hankimisele ja kasutamisele on erinevad. Siin on mõned näited:

• Meeskond esitab taotluse, näiteks ekspluatatsioonigruppile, et anda neile ressursse teatud parameetritega.
• Ekspluatatsioonigrupp pakub neile vajalikku hulka — cloud või bare metal („puhta raudvara”) — ja kohustub neid SLA kohaselt hooldama. Konfiguratsioon tehakse samuti ekspluatatsioonigruppi kuuluvate isikute poolt.
• Meeskond saab ekspluatatsioonigruppilt ainult cloud või bare metal ressursse, konfiguratsiooni teevad nad ise.
• Meeskond ise „ostab” ressursid ja hooldab/konfigureerib need täielikult iseseisvalt.

Meie meeskonnas kasutatakse servereid, mida tuleb hooldada — operatsioonisüsteemi värskendamine, uute pakettide installimine jne.

Oleme need jaganud kahte põhiliiki:

• tankigrupi,
• teenindusgrupi.

Tankigrupp koosneb hostidest Yandex.Tankiga.

Teenindusgrupp sisaldab kõike, mis on seotud hooldusega — see on erinevad teenused, mis toetavad väljaande elutsüklit, automaatsete raportite genereerimist jne.

Ühel hetkel muutus selle kõik käsitsi haldamine ebamugavaks ja me mõtlesime protsessi automatiseerimisele, alustades serverite 'täitmisest' ja lõpetades meie siseteenuse arendamise, ülesseadmise ja käivitamisega.

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

Alguses õppisime Ansible'i ja alustasime oma bare metal serverite 'täitmist', et olla vähem sõltuvad süsteemiadministraatoritest — see toob kasu kõigile, me saame uusi oskusi ja vabastame administraatoreid osa töödest, millega neil on niigi palju tegemist. Me püüdleme arengu poole oma spetsialiteedist väljaspool ja tähelepanu sujuvusele meeskonnas, kuivõrd see on võimalik.

Meie ettevõttes on Ansible'i kasutamine juba piisavalt kaua seadistatud ja reguleeritud, seega suutsime kergesti oma lahenduse sellesse protsessi integreerida.

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

• esimene roll ütleb operatsioonisüsteemi installima;
• teine rakendab hosti põhiseaded, näiteks LDAP-autentimise;
• ja kolmas installib Yandex.Tanki docker-konteinerisse ja sellega seotud sõltuvused.

Liigume edasi teenustele, mida me meeskonnas kasutame.

Oma ülesannete jaoks kasutame võrdselt Kotlin'i ja Python'it, ning natuke ka Golang'i. Et ühte moodi teha arendust ja meie teenuste juurutamist, otsustasime pakkida need docker-konteineritesse. See annab programmeerimiskeele valikul vabaduse ja samal ajal reguleerib meie rakenduse ühtset tarnimisvormi.

Väike märkus ipv6 kohta Docker'is

Mõned teenused, millega me suhtleme, on kättesaadavad ainult ipv6 kaudu, seega pidime välja selgitama, kuidas konteineritele ipv6 seadistada.

Dokumentatsiooni kohaselt ipv6 ametlikul Docker'i veebilehel, lülitatakse ipv6 sisse, lisades valikud daemon.json faili:

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

Sellega peab teenusepakkuja andma ipv6 alamvõrgu, mille sa kirjutad fixed-cidr-v6.
Kuid me valisime teise variandi — ipv6 NAT, ja siin on miks:

• Praegu ei saa Docker'it kasutada ainult ipv6.
• Iga konteineri globaalne marsruuteerimise aadress tähendab, et kõik portid (isegi avaldatud) on kättesaadavad kõigile, kui täiendavat filtreerimist ei tehta.
• userland proxy portide avaldamiseks, iptables ainult ipv4 jaoks.

ipv6 NAT — see on docker-konteiner, mis juhendab ise ip6tables reegleid ja muudab neid uue konteineri lisamisel.

Kuna see lahendus pidi õigesti töötama, tuli teha veel mitmeid toiminguid. Oluline on süsteemis initsialiseerida ip6table_nat. Mooduli olemasolu süsteemis ei garanteeri, et käivitamisel laaditakse moodul kerneli. Me kohtusime selle probleemiga, kui saime sellise vea konteineri käivitamisel NAT-iga värskes hostis:

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, lisades Ansible'i rolli initsialiseerimise modprobe mooduliga ja laadimise käivitamise ajal lineinfile abil:

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

Muide, Habr's on hea artikkel, mis selgelt ja lühidalt kirjeldab eri meetodite eeliseid ja puudusi ipv6 töötamiseks dockeris.

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

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

• serverite «sisetamise» protsess on loodud,
• teenuste arendamine ja juurutamine on ühtlustatud.

Tuleb mõistlik küsimus — kuidas tõhusalt ja võimalikult automatiseeritult juurutada, uuendada ja hallata meie teenuseid docker-konteinerites?

Kuigi iga orkestri liige teab oma osa, võib ta eksida ja kaugemale minna algsest ideest. Siin jõuamegi arusaamale, et ilma dirigendita ei saa meie orkester tõhusalt harjutada ja harmooniliselt mängida. Dirigent vastutab kõikide esitusparameetrite eest, et kõik oleks ühise tempo ja meeleoluga ühendatud.

Kuidas saada head dirigenti minimaalse investeeringuga?

Orkestreerimise teema on turul piisavalt hästi arenenud. Kuid alustame 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. On kaks registreerimise võimalust:

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

Vault on turvaline salvestuslahendus, mis standardiseerib ja ühtlustab saladuste — paroolide, sertifikaatide — turvalist hoidmist ja töötlemist.
Siin on eelised, mida me selle tööriista kasutamisel saavutame:

• Ühtne saladuste loomise ja salvestamise keskus, nende elutsükli haldamine HTTP API kaudu.
• Transit Secrets Engine — andmete krüpteerimine ja dekrüpteerimine ilma nende salvestamiseta. Võimalus edastada andmeid krüpteeritud kujul kaitsmata sidekanalitel.
• Lihtsalt seadistatavad juurdepääsu poliitikad.
• Saladuste juurdepääsu auditeerimine.
• Võimalus luua oma CA (Certificate Authority), et hallata enda allkirjastatud sertifikaate oma infrastruktuuris.

Kuna arvestasime kõiki meie nõudeid, sobis dirigendiks kaks varianti — Kubernetes ja Nomad.

Kubernetes

Kui palju sellest on juba kirjutatud artikleid ja raamatuid (näiteks selline), räägitud ettekandeid, et ma kirjutan lühidalt — see on universaalne kombain, mis suudab peaaegu kõike. Hind selle eest on see, et Kubernetes'e klastrite seadistamine ja haldamine ei ole alati lihtne.

Nomad

Tööriist on HashiCorpi toode, ettevõtte, mis on tuntud eelnevalt mainitud consul'i ja vault'i poolest.

Nomad tundus meile paigaldamise ja seadistamise osas piisavalt lihtne võrreldes Kubernetesega. Üks binaarfail töötab nii serveri kui ka kliendi režiimis. Samuti katab Nomad kõik ülesanded, mida me soovime, et ta lahendaks: klastrihalduse, kiire planeerimise, multidatacenter toe. Pluss, kasutades consul'i ja vault'i, saame tihedama integreerimise meie teenuste orkestreerimiseks.

Praegu töös on:

• valmistatud serverid Consuli juurutamiseks,
• Consuli salvestatakse Nomadi klastri konfiguratsioon, mille abil peaks nomad automaatselt juurutama,
• samaaegselt seadistame vault'i saladuste talletamiseks.

Küsimus saali — kas on mõtet sellisteks ülesanneteks dirigent luua või toimib orkestreerimine ka ilma selleta hästi? Jagage kommentaarides, mida te sellest arvate.

Liituge meie blogiga ja püsige kursis — peagi räägime, kuidas meil läks ja kas me suutsime Nomadi klastrit seadistada nii nagu soovisime.

Tulge meie mõnusasse Telegrami gruppi, kus võite alati küsida nõu, aidata kolleegide ja lihtsalt arutada tootlikkuse uuringute ja muude teemade üle.

Allikas: habr.com