Haec fabula agit de modo quo receptacula in productione utimur, praesertim sub Kubernetes. Collectionem mensurarum et diariorum ex receptaculis, necnon constructionem imaginum, tractat.

Exness sumus, societas fintech quae officia negotiationis interretialis et producta fintech pro B2B et B2C explicat. Turma nostra investigationis et progressionis (R&D) ex multis variis turmis constat, et pars nostra progressionis plus quam centum operarios habet.

Nos sumus turma quae curam gerit de suggestu quo nostri artifices codicem colligunt et exsequuntur. Praesertim, curam gerimus de colligendis, conservandis, et tradendis metricis, actis, et eventibus ex applicationibus. Nunc circiter tria milia receptaculorum Docker in productione administramus, magnum repositorium datorum quinquaginta TB conservamus, et solutiones architecturae circa infrastructuram nostram constructas praebemus: Kubernetes, Rancher, et varios praebitores nubium publicarum. 

Nostra motivatio

Quid ardet? Nemo dicere potest. Ubi est fons? Difficile est dicere. Quando coepit? Invenire potest, sed non statim. 

Cur quaedam receptacula stant, alia autem ceciderunt? Quod receptaculum culpandum est? Postremo, receptacula extrinsecus eadem apparent, sed intus unumquodque suum Neo habet.

Nostri artifices callidi sunt. Magna officia construunt quae lucrum societati generant. Sed interdum res male eveniunt cum receptacula et applicationes a synchronia discrepant. Unum receptaculum nimium CPU consumit, alterum nimium latitudinis retialis consumit, tertium nimium I/O consumit, et quartum ne scit quidem quid cum socketis agat. Haec omnia corruunt, et navis submergitur. 

Agentes

Ut intellegeremus quid intus ageretur, constituimus agentes directe in receptacula ponere.

Haec agentia sunt programmata continentiae quae receptacula in statu servant qui prohibet ne inter se frangantur. Agentia normata sunt, permittens modum normatum ad receptacula conservanda. 

In nostro casu, agentes acta forma consueta, signata et restricta, praebere debent. Etiam nobis mensuras normatas praebere debent, quae ad usus negotiales extendi possunt.

Под агентами также подразумеваются утилиты для эксплуатации и обслуживания, умеющие работать  в разных системах оркестрирования, поддерживающие разные images (Debian, Alpine, Centos and v. d.).

Denique, agentes simplicem CI/CD, inter quae Dockerfiles, sustinere debent. Alioquin navis in partes dissolvetur, cum receptacula per vias vitiosas advehantur.

Processus congregationis et instrumentum imaginis destinatae

Ut omnia normata et tractabilia maneant, necesse est nobis quodammodo processui constructionis communi adhaerere. Itaque constituimus continentia construere per constructionem continentium — genus recursionis.

Hic, receptacula lineis solidis repraesentantur. Distributiones quoque in eis includere decrevimus, ne "vita rosarum similis videatur." Rationem huius infra explicabimus.
 
Resultatum est instrumentum aedificandi—continens versioni proprium quod versiones distributionis specificas et versiones scriptorum specificas refert.

Quomodo eo utimur? Docker Hub cum receptaculo habemus. Intra systema nostrum id imitamur ut dependentias externas removeamus. Receptaculum inde ortum flavo colore illustratur. Formulam creamus ut omnes distributiones et scripta necessaria in receptaculum instituamus. Post hoc, imaginem productioni paratam construimus: artifices codicem suum et quaslibet dependentias specificas ei addunt. 

Quid bonum est in hac ratione? 

• Primo, plena potestas versionum instrumentorum aedificandi – receptaculi aedificandi, versionum scriptorum et distributionum. 
• Deinde, standardizationem consecuti sumus: eodem modo formulas, intermedias, et imagines ad usum paratas creamus. 
• Tertio, receptacula nobis portabilitatem praebent. Hodie Gitlab utimur, et cras ad TeamCity aut Jenkins transibimus et receptacula nostra eodem modo currere poterimus. 
• Quarto, dependentias minuendo. Non casu accidit nos distributiones in vasis inclusisse, cum hoc necessitatem eas ex interreti quotiescumque depromere tollat. 
• Quinto, celeritas constructionis aucta est – exemplaria localia imaginum habere significat te non debere tempus terere eas demptionis, cum imago localis exstet. 

Aliis verbis, processum constructionis moderatum et flexibilem adepti sumus. Eadem instrumenta utimur ad quodlibet receptaculum cum plena versione construendum. 

Quomodo processus noster congregationis operatur

Constructio uno mandato incipit, et processus in imagine (rubro colore illustrata) currit. Fabricator fasciculum Docker (flavo colore illustratum) habet, quem reddimus, variabiles valoribus substituentes. Capita et pedes paginarum etiam interea addimus — haec sunt nostri agentes. 

Caput distributiones ex imaginibus correspondentibus addit. Pes paginae officia nostra instituit, initium operis, inscriptiones, aliosque agentes configurat, punctum ingressus substituit, et cetera. 

Diu disputavimus utrum supervisorem instituere oporteret. Tandem unum nobis opus esse decrevimus. S6 elegimus. Supervisor receptaculum administrat: permittit te ei coniungi si processus principalis corruit et potestatem manualem receptaculi praebet sine eo recreando. Acta et mensurae sunt processus intra receptaculum currentes. Etiam aliquo modo monitorari debent, et hoc cum supervisore facimus. Denique, S6 curam gerit curae internae, processus signorum, et alia officia.

Cum variis systematibus orchestrationis utamur, postquam constructum et emissum est, receptaculum ambitum in quo versatur intellegere et proinde agere debet. Exempli gratia:
Hoc nobis permittit ut imaginem singularem construamus et eam in diversis systematibus orchestrationis currere possimus, et ea proicietur habita ratione proprietatum cuiusque systematis orchestrationis.

 

Pro eodem receptaculo, arbores processus diversas in Docker et Kubernetes obtinemus:

Sarcina sub supervisore S6 currit. Nota collectorem et eventa—hi sunt nostri agentes qui pro diariis et metris responsabiles sunt. Kubernetes ea non habet, sed Docker habet. Cur? 

Si specificationem "pod" (deinceps "pod" Kubernetes appellatam) inspicimus, videbimus receptaculum eventuum in "pod" currere, quod receptaculum collectoris separatum continet, qui mensuras et acta colligit. Facultates Kubernetes adhibere possumus: receptacula in uno "pod", in uno spatio processus et/vel retiaculi, currendo. Hoc nobis permittit ut agentes nostros efficaciter inseramus et functiones specificas exsequamur. Et si idem hoc receptaculum in Docker currit, omnes easdem facultates habebit, id est, acta et mensuras tradere poterit, cum agentes intus current. 

Metrica et acta

Tradere mensuras et acta est negotium multiplex. Plures aspectus in eius solutione implicantur.
Infrastructura ad exsecutionem oneris utilis, non ad traditionem magnarum copiarum diarium, constructa est. Hoc significat processum cum minimis requisitis opum receptaculi perfici debere. Studemus adiuvare nostros programmatores: "Receptaculum Docker Hub accipe, curre, et diarium tradere possumus." 

Alter aspectus est volumen diarii limitare. Si incrementum voluminis diarii in pluribus receptaculis accidit (applicatio iterat et vestigium stack edit), onus in CPU, canalibus communicationis, et systemate processus diarii augetur, totum hospitem et alia receptacula in hospite afficiens, interdum ad ruinam hospitis ducens. 

Tertium aspectum est necessitas quam plurimas methodos colligendi mensuras statim sustinendi. Hoc includit lectionem fasciculorum et interrogationem puncti terminalis Promethei, necnon usum protocollorum applicationibus proprii.

Et postremus aspectus est ut necesse sit consumptionem opum ad minimum reducere.

Solutionem apertam in Go nomine Telegraf elegimus. Est coniunctor universalis qui plus quam 140 extensiones input et 30 extensiones output sustinet. Eam ulterius elaboravimus, et nunc explicabimus quomodo ea in Kubernetes utimur. 

Dicamus artificem programmatum onus laboris (vel "workload") disponit, et Kubernetes petitionem accipit ad pod creandum. Hoc loco, receptaculum nomine "Collector" (Collector) automatice creatur pro quolibet pod (nos utimur "mutation webhook"). "Collector" est agens noster. In initio, hoc receptaculum se configurat ut cum Prometheo et systemate collectionis diariorum operetur.

• Ad hoc faciendum, annotationes "pod" utitur, et pro contentis suis, exempli gratia, punctum extremum Prometheus creat; 
• Secundum specificationem pod et configurationes proprias continentis, decernit quomodo acta tradere.

Acta per API Docker colligimus: opificibus tantum ea in stdout vel stderr ponere necesse est, Collector autem reliqua curabit. Acta in partes cum parva mora colliguntur ne potentialis oneratio computatri sit. 

Metricae pro instantiis operis (processibus) in receptaculis colliguntur. Omnia nominibus, "pods", et cetera insignita sunt, deinde in formam Promethei convertuntur, ita ut ad collectionem (praeter acta diurna) praesto sint. Acta diurna, mensuras, et eventa etiam ad Kafka mittimus et ulterius:

• Acta in Graylog praesto sunt (ad analysin visualem);
• Acta, mensurae, et eventus ad Clickhouse mittuntur ad diuturnam conservationem.

Omnia in AWS eodem modo operantur, nisi quod Graylog Kafka et Cloudwatch substituimus. Eo diaria mittimus, et omnia percommoda sunt: ​​statim apparet ad quem gregem et receptaculum pertineant. Idem valet de Google Stackdriver. Hoc significat nostram configurationem et in situ cum Kafka et in nube operari. 

Si Kubernetes cum pods non habemus, schema paulo implicatius est, sed eisdem principiis operatur.

Eaedem processus intra receptaculum currunt, per S6 ordinati. Omnes eaedem processus intra unum receptaculum currunt.

Ut a praecessi,

Solutionem comprehensivam ad imagines construendas et disponendas creavimus, cum optionibus ad acta et mensuras colligendas et tradendas:

• Rationem normatam ad imagines componendas elaboravimus, et eam innixi, exempla CI creavimus;
• Instrumenta collectionis datorum extensiones nostrae Telegraf sunt. Ea diligenter in productione probavimus;
• Utimur mutation webhook ad iniiciendas receptacula cum agentibus in pods; 
• In oecosystema Kubernetes/Rancher integratum;
• Eadem receptacula in diversis systematibus orchestrationis exsequi et exitum exspectatum consequi possumus;
• Configurationem administrationis receptaculorum plene dynamicam creavi. 

Co-auctor: Ilya Prudnikov

Source: www.habr.com