Tämä tarina kertoo, kuinka käytämme kontteja tuotantoympäristössä, erityisesti Kubernetesissa. Artikkeli on omistettu mittareiden ja lokien keräämiseen säiliöistä sekä rakennuskuvien luomiseen.

Olemme fintech-yrityksestä Exness, joka kehittää palveluita verkkokaupan ja fintech-tuotteita B2B- ja B2C-palveluille. Tuotekehityksessämme on useita erilaisia ​​tiimejä, kehitysosastolla on yli 100 työntekijää.

Edustamme tiimiä, joka vastaa alustasta, jonka avulla kehittäjät voivat kerätä ja suorittaa koodia. Olemme erityisesti vastuussa sovellusten mittareiden, lokien ja tapahtumien keräämisestä, tallentamisesta ja raportoinnista. Käytämme tällä hetkellä noin kolmea tuhatta Docker-konttia tuotantoympäristössä, ylläpidämme 50 TB:n iso datavarastoamme ja tarjoamme arkkitehtonisia ratkaisuja, jotka rakentuvat infrastruktuurimme ympärille: Kubernetes, Rancher ja useat julkiset pilvipalveluntarjoajat. 

Meidän motivaatiomme

Mikä palaa? Kukaan ei osaa vastata. Missä takka on? Sitä on vaikea ymmärtää. Milloin se syttyi tuleen? Voit selvittää, mutta ei heti. 

Miksi jotkut kontit seisovat, kun taas toiset ovat pudonneet? Mikä kontti oli syyllinen? Loppujen lopuksi astioiden ulkopinta on sama, mutta sisällä jokaisessa on oma Neo.

Kehittäjämme ovat osaavia miehiä. He tekevät hyviä palveluita, jotka tuovat voittoa yritykselle. Mutta on virheitä, kun sovelluksia sisältävät säiliöt menevät harhaan. Yksi kontti kuluttaa liikaa prosessoria, toinen verkkoa, kolmas kuluttaa I/O-toimintoja ja neljäs on täysin epäselvää, mitä se tekee pistokkeilla. Kaikki kaatuu ja laiva uppoaa. 

Agentit

Ymmärtääksemme, mitä sisällä tapahtuu, päätimme sijoittaa agentit suoraan astioihin.

Nämä aineet ovat rajoitusohjelmia, jotka pitävät säiliöt sellaisessa tilassa, etteivät ne riko toisiaan. Agentit ovat standardoituja, mikä mahdollistaa standardoidun lähestymistavan säiliöiden huoltoon. 

Meidän tapauksessamme agenttien on toimitettava lokit vakiomuodossa, merkittyinä ja rajoitettuina. Niiden pitäisi myös tarjota meille standardoituja mittareita, jotka ovat laajennettavissa yrityssovellusten näkökulmasta.

Agentit tarkoittavat myös käyttö- ja ylläpitoapuohjelmia, jotka voivat toimia erilaisissa orkestrointijärjestelmissä, jotka tukevat erilaisia ​​kuvia (Debian, Alpine, Centos jne.).

Lopuksi agenttien on tuettava yksinkertaista CI-/CD-levyä, joka sisältää Docker-tiedostoja. Muuten laiva hajoaa, koska kontteja aletaan kuljettaa "kiertyneitä" kiskoja pitkin.

Rakenna prosessi ja kohdekuvalaite

Jotta kaikki pysyisi standardoituna ja hallittavissa, on noudatettava jonkinlaista vakiomuotoiluprosessia. Siksi päätimme kerätä kontit konteittain - tämä on rekursio.

Tässä säiliöt on esitetty yhtenäisin ääriviivoin. Samalla he päättivät laittaa niihin jakelusarjoja, jotta "elämä ei tunnu vadelmalta". Miksi näin tehtiin, selitämme alla.
 
Tuloksena on koontityökalu – versiokohtainen säilö, joka viittaa tiettyihin jakeluversioihin ja tiettyihin komentosarjaversioihin.

Kuinka käytämme sitä? Meillä on Docker Hub, joka sisältää kontin. Peilaamme sen järjestelmämme sisällä päästäksemme eroon ulkoisista riippuvuuksista. Tuloksena on keltaisella merkitty säiliö. Luomme mallin kaikkien tarvitsemamme jakelujen ja komentosarjojen asentamiseksi säilöön. Sen jälkeen kootaan käyttövalmis kuva: kehittäjät laittavat siihen koodin ja joitain omia erityisriippuvuuksiaan. 

Mitä hyvää tässä lähestymistavassa on? 

• Ensinnäkin koontityökalujen täydellinen versionhallinta - rakennussäilö, komentosarja ja jakeluversiot. 
• Toiseksi olemme saavuttaneet standardoinnin: luomme malleja, väli- ja käyttövalmiita kuvia samalla tavalla. 
• Kolmanneksi kontit antavat meille siirrettävyyden. Tänään käytämme Gitlabia ja huomenna siirrymme TeamCityyn tai Jenkinsiin ja voimme käyttää konttiamme samalla tavalla. 
• Neljänneksi riippuvuuksien minimoiminen. Ei ollut sattuma, että laitoimme jakelupaketteja säiliöön, koska näin voimme välttää niiden lataamisen Internetistä joka kerta. 
• Viidenneksi rakennusnopeus on lisääntynyt - kuvien paikallisten kopioiden avulla voit välttää ajanhukkaa lataamiseen, koska siellä on paikallinen kuva. 

Toisin sanoen olemme saavuttaneet hallitun ja joustavan kokoonpanoprosessin. Käytämme samoja työkaluja kaikkien täysin versioittujen säiliöiden rakentamiseen. 

Kuinka rakennusprosessimme toimii

Kokoonpano käynnistetään yhdellä komennolla, prosessi suoritetaan kuvassa (korostettu punaisella). Kehittäjällä on Docker-tiedosto (korostettu keltaisella), renderöimme sen korvaamalla muuttujat arvoilla. Ja matkan varrella lisäämme ylä- ja alatunnisteita - nämä ovat agenttimme. 

Otsikko lisää jakelut vastaavista kuvista. Ja alatunniste asentaa palvelumme sisälle, määrittää työkuorman, lokikirjauksen ja muiden agenttien käynnistämisen, korvaa aloituspisteen jne. 

Mietimme pitkään, asentaisimmeko valvojan. Lopulta päätimme, että tarvitsemme häntä. Valitsimme S6:n. Valvoja tarjoaa kontinhallinnan: voit muodostaa yhteyden siihen, jos pääprosessi kaatuu, ja mahdollistaa säilön manuaalisen hallinnan luomatta sitä uudelleen. Lokit ja mittarit ovat prosesseja, jotka suoritetaan säilön sisällä. Niitä on myös jotenkin valvottava, ja teemme tämän esimiehen avulla. Lopuksi S6 huolehtii taloudenpidosta, signaalinkäsittelystä ja muista tehtävistä.

Koska käytämme erilaisia ​​orkestrointijärjestelmiä, kontin tulee rakentamisen ja ajon jälkeen ymmärtää missä ympäristössä se on ja toimia tilanteen mukaan. Esimerkiksi:
Näin voimme rakentaa yhden kuvan ja ajaa sitä eri orkestrointijärjestelmissä, ja se lanseerataan ottaen huomioon tämän orkestrointijärjestelmän erityispiirteet.

 

Samalle säiliölle saamme erilaisia ​​prosessipuita Dockerissa ja Kubernetesissa:

Hyötykuorma suoritetaan S6:n valvonnassa. Kiinnitä huomiota keräilijöihin ja tapahtumiin – nämä ovat lokeista ja mittareista vastaavat edustajamme. Kubernetesilla ei niitä ole, mutta Dockerilla on. Miksi? 

Jos katsomme "podin" (jäljempänä - Kubernetes pod) spesifikaatiota, huomaamme, että tapahtumasäilö suoritetaan podissa, jossa on erillinen keräyssäiliö, joka suorittaa mittareiden ja lokien keräämisen. Voimme käyttää Kubernetesin ominaisuuksia: konttien ajamista yhdessä podissa, yhdessä prosessissa ja/tai verkkotilassa. Esittele agenttisi ja suorita joitain toimintoja. Ja jos sama säilö käynnistetään Dockerissa, se saa kaikki samat ominaisuudet kuin tulos, eli se pystyy toimittamaan lokeja ja mittareita, koska agentit käynnistetään sisäisesti. 

Mittarit ja lokit

Mittareiden ja lokien toimittaminen on monimutkainen tehtävä. Hänen päätöksessään on useita näkökohtia.
Infrastruktuuri on luotu hyötykuorman suorittamista varten, ei tukkien massatoimitusta varten. Toisin sanoen tämä prosessi on suoritettava minimaalisilla säilöresurssivaatimuksilla. Pyrimme auttamaan kehittäjiämme: "Hanki Docker Hub -kontti, käytä sitä, niin voimme toimittaa lokit." 

Toinen näkökohta on tukkien määrän rajoittaminen. Jos lokien määrä kasvaa useissa säiliöissä (sovellus tulostaa pinojäljityksen silmukassa), CPU:n, viestintäkanavien ja lokinkäsittelyjärjestelmän kuormitus kasvaa, mikä vaikuttaa isäntäkoneen toimintaan. kokonaisia ​​ja muita säiliöitä isännässä, joskus tämä johtaa isännän "putoamiseen". 

Kolmas näkökohta on se, että on välttämätöntä tukea mahdollisimman monia metriikan keruumenetelmiä heti alusta alkaen. Tiedostojen lukemisesta ja Prometheus-päätepisteen kyselystä sovelluskohtaisten protokollien käyttöön.

Ja viimeinen näkökohta on minimoida resurssien kulutus.

Valitsimme avoimen lähdekoodin Go-ratkaisun nimeltä Telegraf. Tämä on yleisliitin, joka tukee yli 140 tyyppistä tulokanavaa (tulolaajennuksia) ja 30 tyyppistä lähtökanavaa (lähtölaajennuksia). Olemme viimeistellyt sen ja nyt kerromme sinulle, kuinka käytämme sitä esimerkkinä Kubernetes. 

Oletetaan, että kehittäjä ottaa käyttöön työkuorman ja Kubernetes vastaanottaa pyynnön luoda pod. Tässä vaiheessa jokaiselle podille luodaan automaattisesti säiliö nimeltä Collector (käytämme mutaatio webhookia). Keräilijä on edustajamme. Alussa tämä säilö määrittää itsensä toimimaan Prometheuksen ja lokinkeräysjärjestelmän kanssa.

• Tätä varten se käyttää pod-merkintöjä ja sisällöstään riippuen luo esimerkiksi Prometheus-päätepisteen; 
• Pod-määrityksen ja tiettyjen säilöasetusten perusteella se päättää, kuinka lokit toimitetaan.

Keräämme lokit Docker API:n kautta: kehittäjien tarvitsee vain laittaa ne stdout- tai stderriin, ja Collector selvittää ne. Lokit kerätään paloina pienellä viiveellä mahdollisen isännän ylikuormituksen estämiseksi. 

Mittarit kerätään työkuormitusesiintymien (prosessien) kesken säilöihin. Kaikki on merkitty tunnisteella: nimiavaruus, alle ja niin edelleen, ja sitten muunnetaan Prometheus-muotoon - ja se tulee saataville kerättäväksi (paitsi lokit). Lähetämme myös lokeja, mittareita ja tapahtumia Kafkalle ja muille:

• Lokit ovat saatavilla Graylogissa (visuaalista analyysiä varten);
• Lokit, mittarit ja tapahtumat lähetetään Clickhouseen pitkäaikaista säilytystä varten.

Kaikki toimii täsmälleen samalla tavalla AWS:ssä, vain korvaamme Graylogin Kafkalla Cloudwatchilla. Lähetämme lokit sinne, ja kaikki on erittäin kätevää: on heti selvää, mihin klusteriin ja konttiin ne kuuluvat. Sama pätee Google Stackdriveriin. Eli järjestelmämme toimii sekä paikan päällä Kafkan kanssa että pilvessä. 

Jos meillä ei ole podilla varustettua Kubernetesia, järjestelmä on hieman monimutkaisempi, mutta se toimii samoilla periaatteilla.

Samat prosessit suoritetaan kontin sisällä, ne ohjataan S6:lla. Kaikki samat prosessit ovat käynnissä samassa säiliössä.

Tämän seurauksena

Olemme luoneet täydellisen ratkaisun kuvien rakentamiseen ja käynnistämiseen, jossa on vaihtoehtoja lokien ja mittareiden keräämiseen ja toimittamiseen:

• Kehitimme standardoidun lähestymistavan kuvien kokoamiseen ja sen pohjalta kehitimme CI-malleja;
• Tiedonkeruuagentit ovat Telegraf-laajennuksiamme. Testasimme ne hyvin tuotannossa;
• Käytämme mutaatio-webhookia toteuttaaksemme säiliöitä, joissa on aineita podissa; 
• Integroitu Kubernetes/Rancher-ekosysteemiin;
• Voimme toteuttaa samat kontit erilaisissa orkestrointijärjestelmissä ja saada odottamamme tuloksen;
• Loi täysin dynaamisen säilönhallintakokoonpanon. 

Yhteiskirjoittaja: Ilja Prudnikov

Lähde: will.com