Aligha lenne helytelen azt mondani, hogy az emberek legjobbjai
örömre lelnek a szenvedés révén.
Ludwig van Beethoven
Én Szergej vagyok, a Yandex.Pénz csapatában dolgozom, amely a teljesítménykutatásért felel. Szeretném elmesélni nektek történetünk kezdetét az orkestrálás használatának folyamatáról – arról, hogyan választottuk az eszközöket és mit vettünk figyelembe. Minden esemény a cikkben valós időben zajlik, így kedves olvasók, gyakorlatilag élő közvetítés keretében követhetitek a történéseket.
Miért van szükségünk karmesterre a csapatban?
Ki is az a karmester? A francia diriger szóból ered – irányítani, vezetni, felügyelni –, a zene világában ez a személy az, aki vezeti az együttes zenei gyakorlását és előadását. A mi esetünkben ezt a szerepet az orkestrációs és automatizálási rendszerek töltik be.
Szerepük semmiben sem különbözik a karmester szerepétől a zenében – a csapatnak azért van szüksége rájuk, hogy segítsenek, irányítsák és szervezzék a játékukat.
Általában a csapat rendelkezik egy bizonyos kapacitással – nevezzük őket szervereknek, amelyeken megvalósítják projektjeiket.
A szerverek beszerzésének és működtetésének megközelítése változatos. Íme néhány példa:
- A csapat például kérdést intéz a működtetések csoportjához, hogy biztosítsanak számukra erőforrásokat bizonyos paraméterekkel.
- A működtetési csoport a szükséges mennyiséget biztosítja számukra – cloud vagy bare metal (»meztelen vas«) – és vállalja, hogy azokat a megfelelő állapotban tartja az SLA szerint. A konfigurálást is ez a csoport végzi.
- A csapat csak cloud vagy bare metal erőforrásokat kap a működtetési csoporttól, a konfigurálást saját maguk végzik.
- A csapat saját magának »vásárolja« meg az erőforrásokat, és teljesen önállóan tartja karban/konfigurálja őket.
A csapatunkban olyan szerverek találhatók, amelyeket karban kell tartani – operációs rendszert frissíteni, új csomagokat telepíteni stb.
Számunkra két fő típust különítettünk el:
- tankcsoport,
- szolgáltató csoport.
A tankcsoport Yandex.Tankkal rendelkező hosztokból áll.
A szolgáltató csoport mindennel foglalkozik, ami a fenntartással kapcsolatos – ez különféle szolgáltatások a kiadási ciklus támogatásának, automatikus jelentések generálásának stb. biztosítása érdekében.
Egy idő után kényelmetlenné vált mindezt kézi módszerrel kezelni, ezért gondolkodni kezdtünk a folyamat automatizálásán, kezdve a szerverek "telepítésétől" egészen a belső szolgáltatásunk fejlesztéséig, kiadásáig és elindításáig.
Miért van szükség karmesterre, még ha a zenekar magától is tud játszani?
Először elsajátítottuk az Ansible-t, és elkezdtük "telepíteni" a bare metal szervereinket, hogy kevésbé legyünk függővé a rendszergazdáktól – ezzel mindenki nyer, új készségekre teszünk szert, és megszabadítjuk a rendszergazdákat egy résznyi munkától, amire nekik is mindig van elég dolguk. Törekszünk a fejlődésre, a szakmánkon kívüli tanulásra és a csapat autonómiájára, amennyire lehetséges.
A cégnél az Ansible-lal való munka már elegendő ideje be van állítva és szabályozva, ezért könnyen be tudtuk integrálni a megoldásunkat ebbe a folyamatba.
Jelenleg a hosztok telepítése három Ansible szerepből áll:
- az első szerep telepíti az operációs rendszert,
- a második végrehajtja az alap beállításokat a hoszton, például az LDAP-azonosítást
- és a harmadik telepíti a Yandex.Tankot és a kapcsolódó függőségeket docker-konténerben.
Térjünk át azokkal a szolgáltatásokra, amelyeket a csapatunkon belül használunk.
Feladatainkhoz egyenlő arányban használjuk a Kotlin-t és a Python-t, valamint egy kicsit a Golang-ot is. Annak érdekében, hogy egységesítsük a szolgáltatásaink fejlesztését és telepítését, úgy döntöttünk, hogy docker-konténerekbe csomagoljuk őket. Ez lehetőséget ad a programozási nyelv szabad megválasztására, miközben egy egységes alkalmazásforma létrehozását is szabályozza.
Kis megjegyzés az ipv6-ról a Dockerben
Néhány szolgáltatás, amellyel kapcsolatba lépünk, csak ipv6-on érhető el, ezért meg kellett értenünk, hogyan lehet ipv6-ot létrehozni a konténerek számára.
A Docker hivatalos weboldalán található ipv6 dokumentáció szerint az ipv6 engedélyezéséhez paramétereket kell hozzáadni a daemon.json fájlhoz:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Eközben a szolgáltatónak ki kell adnia egy ipv6 alhálózatot, amelyet a fixed-cidr-v6-ban kell megadnod.
Azonban mi egy másik megoldást választottunk – ipv6 NAT-ot, és ez az oka:
- Jelenleg a Docker-t csak ipv6-tal.
- A globálisan irányítható címek megléte minden egyes konténerben azt jelenti, hogy minden port (akár publikálatlan) elérhetővé válik mindenki számára, ha nem végeznek el további szűrést.
- userland proxy a portok publikálásához, .
ipv6 NAT – ez a , amely automatikusan kezeli az ip6tables szabályait és azokat módosítja új konténer hozzáadásakor.
Ahhoz, hogy ez a megoldás megfelelően működjön, még számos manipulációt el kellett végezni. Kötelező inicializálni az ip6table_nat-ot a rendszerben. A telepített modul megléte nem garantálja, hogy az indításkor a modul betöltődik a kernelbe. Ezzel akkor találkoztunk, amikor ezt a hibát kaptuk egy NAT konténer indításakor egy friss hoston:
2019/01/22 14:59:54 fut: [/sbin/ip6tables -t filter -N DOCKER --wait]: kilépési állapot 3: modprobe: nem lehet megváltoztatni a könyvtárat ' /lib/modules': Nincs ilyen fájl vagy könyvtár
ip6tables v1.6.2: nem lehet inicializálni az ip6tables táblát `filter': A tábla nem létezik (lehet, hogy szükséged van insmod-ra?)A probléma megoldódott, miután hozzáadtuk az Ansible szerepkörhöz az inicializálást a modprobe modullal és az OS indításakor a lineinfile segítségével:
- név: ip6table_nat modul hozzáadása
modprobe:
név: ip6table_nat
állapot: jelen
- név: ip6table_nat hozzáadása a rendszerindításhoz
lineinfile:
útvonal: /etc/modules
sor: 'ip6table_nat'Egyébként a Habr-on van egy jó , amely röviden és világosan leírja az ipv6 működésének különböző módszereinek előnyeit és hátrányait a dockeren belül.
De térjünk vissza az elején feltett kérdésünkhöz:
Miért van szükség karmesterre, még ha a zenekar magától is tud játszani?
Most mindenki tudja, hogyan kell játszani a csapatunkban:
- a szerverek 'beöntési' folyamata elkészült,
- a szolgáltatások fejlesztése és telepítése egységesítve van.
Felmerül a jogos kérdés — hogyan lehet hatékonyan és a lehető legautomatikusabban telepíteni, frissíteni, ellenőrizni a szolgáltatásainkat docker konténerekben?
Bár a zenekar minden tagja tudja a saját részét, eltérhet az eredeti elképzeléstől. Itt jutunk el ahhoz, hogy karmester nélkül a zenekarunk nem tud hatékonyan próbálni és összhangban játszani. A karmester felelős az előadás minden paraméteréért, hogy minden egy közös tempóval és hangulattal legyen összehangolva.
Hogyan szerezhetünk jó karmestert minimális befektetéssel?
A zenekarokkal kapcsolatos téma a piacon jól kifejlődött. De először beszéljünk azokról az segédeszközökről, amelyek segíthetnek a karmesternek.
— egy rendszer, amely két fő funkciót biztosít:
- szolgáltatások felfedezése (service discovery),
- elOsztott kulcs-érték tároló.
A mi zenekarunkban a Consul fog felelni a szolgáltatások regisztrálásáért és a konfigurációik tárolásáért. Két lehetőség van a regisztrációra:
- Aktív — amikor a szolgáltatás saját magát regisztrálja HTTP API használatával;
- Passzív — a szolgáltatást manuálisan kell bejegyezni.
A Vault egy tároló, amely standardizálja és egységesíti a titkok — például jelszavak és tanúsítványok — biztonságos tárolását és kezelését.
Íme az előnyök, amelyeket ezzel az eszközzel nyerhetünk:
- Egyetlen titok létrehozási és tárolási központ, amely lehetővé teszi a titkok életciklusának kezelését HTTP API-n keresztül.
- A Transit Secrets Engine lehetővé teszi az adatok titkosítását és visszafejtését anélkül, hogy azokat tárolnánk. Lehetőség arra, hogy az adatokat titkosítva küldjük el védtelen kommunikációs csatornákon.
- Kényelmesen beállítható hozzáférési irányelvek.
- A titkokhoz való hozzáférés auditálása.
- Lehetőség saját CA (Tanúsítványhatóság) létrehozására, amely lehetővé teszi az önaláírású tanúsítványok kezelését a saját infrastruktúrán belül.
Figyelembe véve minden követelményünket, két lehetőség vált be a vezérlő szerepére: a Kubernetes és a Nomad.
Kubernetes
Már mennyi cikk és könyv született róla (itt , sok mondat hangzott el, így röviden összefoglalom — ez egy univerzális kombájn, amely szinte mindenre képes. Az ára — hogy a Kubernetes klaszterének beállítása és fenntartása nem mindig egyszerű.
A Nomad
a HashiCorp-tól, a fent említett consul és vault gyártójától.
A Nomad egyszerűbbnek tűnt az installálás és beállítás szempontjából, mint a Kubernetes. Egyetlen bináris fájl működik szerverként és kliensként is. Ráadásul a Nomad lefedi mindazokat a feladatokat, amelyeket meg szeretnénk oldani: klaszterkezelés, gyors ütemező és multináci támogatás. Továbbá a consul és vault használatával szorosabb integrációt kapunk a szolgáltatásaink orchestration-jához.
Jelenleg folyamatban van:
- szerverek előkészítése a Consul telepítésére,
- a Consulba bekerül a nomad klaszter konfigurációja, amellyel a nomad automatikusan telepítve lesz,
- párhuzamosan telepítjük a vaultot a titkok tárolására.
Kérdés a teremben — érdemes-e vezérlőért folyamodnunk az ilyen feladatokhoz, vagy az orchestration jól működik nélküle? Mondjátok el a véleményeteket a megjegyzésekben.
Iratkozzatok fel a blogunkra, és tartsatok velünk — hamarosan beszámolunk arról, hogy sikerült-e beállítanunk a nomad klasztert a kívánt módon.
Látogassatok el a barátságos ahol mindig kérhettek tanácsot, segíthettek kollégáknak és egyszerűen beszélgethettek a teljesítménykutatásokról és más témákról.
Forrás: habr.com
