Bedreiwer zu Kubernetes fir d'Gestioun vun Datebank Cluster. Vladislav Klimenko (Altinity, 2019)

De Bericht ass gewidmet fir praktesch Themen fir e Bedreiwer zu Kubernetes z'entwéckelen, seng Architektur a Basisbetribsprinzipien ze designen.

Am éischten Deel vum Bericht wäerte mir berücksichtegen:

• wat ass en Operateur zu Kubernetes a firwat ass et néideg;
• wéi genee de Bedreiwer vereinfacht d'Gestioun vu komplexe Systemer;
• wat de Bedreiwer kann a kann net maachen.

Als nächst wäerte mir weidergoen fir d'intern Struktur vum Bedreiwer ze diskutéieren. Loosst eis d'Architektur an d'Operatioun vum Bedreiwer Schrëtt fir Schrëtt kucken. Loosst eis et am Detail kucken:

• Interaktioun tëscht dem Bedreiwer a Kubernetes;
• wéi eng Funktiounen de Bedreiwer iwwerhëlt a wéi eng Funktiounen hien un Kubernetes delegéiert.

Loosst eis kucken op d'Gestioun vun Shards an Datebank Repliken a Kubernetes.
Als nächst wäerte mir Datenspeicherprobleemer diskutéieren:

• wéi Dir mat Persistent Storage aus der Siicht vun engem Bedreiwer schafft;
• Fallfäegkeete vu lokale Späichere benotzt.

Am leschten Deel vum Bericht wäerte mir praktesch Beispiller vun der Uwendung betruechten clickhouse-Operateur vun Amazon oder Google Cloud Service. De Bericht baséiert op dem Beispill vun der Entwécklung an der Operatiounserfahrung vun engem Bedreiwer fir ClickHouse.

Video:

Mäin Numm ass Vladislav Klimenko. Haut wollt ech iwwer eis Erfahrung an der Entwécklung an der Betreiung vun engem Bedreiwer schwätzen, an dëst ass e spezialiséierte Bedreiwer fir d'Gestioun vun Datebankcluster. Zum Beispill ClickHouse-Operateur fir de ClickHouse Cluster ze managen.

Firwat hu mir d'Méiglechkeet iwwer de Bedreiwer an ClickHouse ze schwätzen?

• Mir ënnerstëtzen an entwéckelen ClickHouse.
• Am Moment probéieren mir lues a lues eise Bäitrag zur Entwécklung vum ClickHouse ze maachen. A mir sinn zweet nom Yandex wat de Volume vun den Ännerungen am ClickHouse ugeet.
• Mir probéieren zousätzlech Projete fir de ClickHouse Ökosystem ze maachen.

Ech wéilt Iech iwwer ee vun dëse Projete soen. Dëst ass iwwer ClickHouse-Bedreiwer fir Kubernetes.

A mengem Bericht wëll ech zwee Themen beréieren:

• Dat éischt Thema ass wéi eise ClickHouse Datebank Management Bedreiwer a Kubernetes funktionnéiert.
• Dat zweet Thema ass wéi all Bedreiwer funktionnéiert, dat heescht wéi et mat Kubernetes interagéiert.

Wéi och ëmmer, dës zwou Froen wäerte sech a mengem Bericht duerchschnëttlech maachen.

Wien wier interesséiert fir nozelauschteren wat ech probéieren ze soen?

• Et wäert am meeschten Interessi fir déi sinn, déi Bedreiwer bedreiwen.
• Oder fir déi, déi hir eege maachen wëllen, fir ze verstoen, wéi et intern funktionnéiert, wéi de Bedreiwer mat Kubernetes interagéiert, a wéi eng Falen optrieden.

Fir am beschten ze verstoen wat mir haut diskutéieren, ass et eng gutt Iddi ze wëssen wéi Kubernetes funktionnéiert an e puer Basis Cloud Training hunn.

Wat ass ClickHouse? Dëst ass eng spalten Datebank mat spezifesche Funktiounen fir online Veraarbechtung vun analyteschen Ufroen. An et ass komplett Open Source.

An et ass wichteg fir eis nëmmen zwou Saachen ze wëssen. Dir musst wëssen datt dëst eng Datebank ass, also wat ech Iech soen wäert op bal all Datebank applicabel sinn. An de Fakt datt de ClickHouse DBMS ganz gutt skaléiert, gëtt bal linear Skalierbarkeet. An dofir ass de Clusterstaat en natierlechen Zoustand fir ClickHouse. A mir sinn am meeschten interesséiert ze diskutéieren wéi de ClickHouse Stärekoup zu Kubernetes ze déngen.

Firwat gëtt hien do gebraucht? Firwat kënne mir et net weider selwer bedreiwen? An d'Äntwerten sinn deelweis technesch an deelweis organisatoresch.

• An der Praxis sti mir ëmmer méi op eng Situatioun, wou a grousse Firmen bal all Komponente schonn a Kubernetes sinn. Datebanke bleiwen ausserhalb.
• An d'Fro gëtt ëmmer méi gestallt: "Kann dat dobannen placéiert ginn?" Dofir probéieren grouss Firmen maximal Unifikatioun vun der Gestioun z'erreechen fir séier hir Datelager ze verwalten.
• An dëst hëlleft besonnesch wann Dir déi maximal Méiglechkeet braucht fir datselwecht op enger neier Plaz ze widderhuelen, also maximal Portabilitéit.

Wéi einfach oder schwéier ass et? Dëst kann natierlech mat der Hand gemaach ginn. Awer et ass net sou einfach, well mir déi zousätzlech Komplexitéit hunn fir Kubernetes selwer ze managen, awer gläichzäiteg d'Spezifizitéite vum ClickHouse iwwerlagert. An esou eng Aggregatioun Resultater.

An all zesummen gëtt dëst e relativ grousst Set vun Technologien, déi zimmlech schwéier ze verwalten gëtt, well Kubernetes seng eegen alldeeglech Themen op d'Operatioun bréngt, a ClickHouse bréngt seng eegen Themen op alldeeglech Operatioun. Besonnesch wa mir e puer ClickHouses hunn, a mir mussen dauernd eppes mat hinnen maachen.

Mat enger dynamescher Konfiguratioun huet ClickHouse eng zimlech grouss Unzuel u Themen déi eng konstant Laascht op DevOps kreéieren:

• Wann mir eppes am ClickHouse änneren wëllen, zum Beispill, eng Replika oder Shard addéieren, da musse mir d'Konfiguratioun verwalten.
• Dann ännert d'Dateschema, well ClickHouse eng spezifesch Shardingmethod huet. Do musst Dir d'Datendiagramm ausleeën, d'Konfiguratiounen ausleeën.
• Dir musst d'Iwwerwaachung opsetzen.
• Sammelt Logbicher fir nei Schnëtt, fir nei Repliken.
• Këmmere sech ëm Restauratioun.
• An nei starten.

Dëst sinn routinéiert Aufgaben déi ech wierklech gär méi einfach ze benotzen.

Kubernetes selwer hëlleft gutt an der Operatioun, awer op Basis System Saachen.

Kubernetes ass gutt fir Saachen ze erliichteren an ze automatiséieren wéi:

• Erhuelung.
• Neistart.
• Stockage System Gestioun.

Dat ass gutt, dat ass déi richteg Richtung, awer hien ass komplett onkloer iwwer wéi een en Datebankcluster operéiert.

Mir wëllen méi, mir wëllen datt déi ganz Datebank a Kubernetes funktionnéiert.

Ech wéilt eppes wéi e grousse Magie roude Knäppchen kréien, deen Dir dréckt an e Stärekoup mat alldeeglechen Aufgaben, déi geléist musse ginn, gëtt duerch säi ganze Liewenszyklus agesat an ënnerhalen. ClickHouse Cluster zu Kubernetes.

A mir hu probéiert eng Léisung ze maachen, déi hëlleft d'Aarbecht méi einfach ze maachen. Dëst ass e ClickHouse-Bedreiwer fir Kubernetes vun Altinity.

En Bedreiwer ass e Programm deem seng Haaptaufgab ass aner Programmer ze managen, dat heescht et ass e Manager.

An et enthält Verhalensmuster. Dir kënnt dat kodifizéiert Wëssen iwwer d'Themaberäich nennen.

A seng Haaptaufgab ass d'Liewe vun DevOps méi einfach ze maachen an d'Mikromanagement ze reduzéieren, sou datt hien (DevOps) schonn op héijem Niveau denkt, dat heescht, datt hien (DevOps) net mat Mikromanagement engagéiert, sou datt hien net konfiguréiert all Detailer manuell.

A just de Bedreiwer ass e Roboter Assistent dee sech mat Mikrotasks beschäftegt an DevOps hëlleft.

Firwat braucht Dir en Operateur? Hie mécht besonnesch gutt an zwee Beräicher:

• Wann de Spezialist, dee mat ClickHouse beschäftegt, net genuch Erfahrung huet, awer scho ClickHouse muss bedreiwen, erliichtert de Bedreiwer d'Operatioun an erlaabt Iech e ClickHouse-Cluster mat enger zimlech komplexer Konfiguratioun ze bedreiwen, ouni ze vill Detailer iwwer wéi et alles funktionnéiert bannen. Dir gitt him just héich-Niveau Aufgaben, an et Wierker.
• An déi zweet Aufgab an där et am beschten leeft ass wann et néideg ass eng grouss Zuel vun typesch Aufgaben ze automatiséieren. Ewechzehuelen microtasks aus System Administrateuren.

Dëst ass am meeschte gebraucht entweder vun deenen, déi just hir Rees ufänken, oder vun deenen, déi vill Automatioun musse maachen.

Wéi ënnerscheet sech d'Operateur-baséiert Approche vun anere Systemer? Do ass Helm. Et hëlleft och ClickHouse z'installéieren; Dir kënnt Helm Charts zéien, déi souguer e ganze ClickHouse Cluster installéieren. Wat ass dann den Ënnerscheed tëscht dem Bedreiwer an dem selwechten, zum Beispill, Helm?

Den Haaptfundamental Ënnerscheed ass datt Helm Package Management ass an de Bedreiwer e Schrëtt weider geet. Dëst ass Ënnerstëtzung fir de ganze Liewenszyklus. Dëst ass net nëmmen d'Installatioun, dëst sinn alldeeglech Aufgaben, déi d'Skaléierung, d'Schärfen enthalen, dh alles wat am Liewenszyklus gemaach muss ginn (wann néideg, dann och d'Läschen) - dat gëtt alles vum Bedreiwer entscheet. Et probéiert de ganze Software Liewenszyklus ze automatiséieren an z'erhalen. Dëst ass säi fundamentalen Ënnerscheed vun anere Léisungen déi presentéiert ginn.

Dat war den Aféierungs Deel, loosst eis weidergoen.

Wéi bauen mir eise Bedreiwer? Mir probéieren d'Thema unzegoen fir de ClickHouse Cluster als eenzeg Ressource ze managen.

Hei hu mir Inputdaten op der lénker Säit vum Bild. Dëst ass YAML mat enger Cluster Spezifikatioun, déi op Kubernetes op klassesch Manéier iwwer kubectl weidergeleet gëtt. Do hëlt eise Bedreiwer et op a mécht seng Magie. A bei der Ausgab kréie mir de folgende Schema. Dëst ass eng Implementatioun vu ClickHouse a Kubernetes.

An da kucke mer lues a lues wéi genee den Bedreiwer funktionéiert, wéi eng typesch Aufgaben geléist kënne ginn. Mir wäerten nëmmen typesch Aufgaben betruecht well mir limitéiert Zäit hunn. An net alles, wat de Bedreiwer kann entscheeden, gëtt diskutéiert.

Loosst eis vun der Praxis ufänken. Eise Projet ass komplett Open Source, sou datt Dir kënnt gesinn wéi et op GitHub funktionnéiert. An Dir kënnt aus de Considératiounen virgoen datt wann Dir et just wëllt starten, da kënnt Dir mam Quick Start Guide ufänken.

Wann Dir wëllt am Detail verstoen, da probéieren mir d'Dokumentatioun an enger méi oder manner uerdentlecher Form z'erhalen.

Loosst eis mat engem praktesche Problem ufänken. Déi éischt Aufgab, wou mir all wëllen ufänken, ass dat éischt Beispill iergendwéi auszeféieren. Wéi kann ech ClickHouse mam Bedreiwer starten, och wann ech net wierklech weess wéi et funktionnéiert? Mir schreiwen e Manifest, well... All Kommunikatioun mat k8s ass Kommunikatioun duerch Manifestatiounen.

Dëst ass sou e komplexe Manifest. Wat mir rout beliicht hunn ass wat mir musse fokusséieren. Mir froen de Bedreiwer fir e Cluster mam Numm Demo ze kreéieren.

Dëst sinn Basis Beispiller fir elo. D'Lagerung ass nach net beschriwwe ginn, awer mir kommen e bësse méi spéit op d'Lagerung zréck. Fir de Moment wäerte mir d'Dynamik vun der Entwécklung vum Cluster beobachten.

Mir hunn dëse Manifest erstallt. Mir fidderen et un eise Bedreiwer. Hien huet geschafft, hien huet Magie gemaach.

Mir kucken op d'Konsol. Dräi Komponente si vun Interesse: e Pod, zwee Services, an e StatefulSet.

De Bedreiwer huet geschafft, a mir kënne gesinn wat hien erstallt huet.

Hie mécht esou eppes. Mir hunn e StatefulSet, Pod, ConfigMap fir all Replik, ConfigMap fir de ganze Cluster. Servicer sinn als Entrée Punkten an de Cluster néideg.

Servicer sinn den zentrale Load Balancer Service a kënnen och fir all Replica benotzt ginn, fir all Shard.

Eise Basiscluster gesäit sou eppes aus. Et ass vun engem eenzegen Node.

Loosst eis méi wäit goen a Saache komplizéiere. Mir mussen de Cluster zerstéieren.

Eis Aufgaben wuessen, Dynamik fänkt un. Mir wëllen e Schnëtt derbäisetzen. Mir verfollegen d'Entwécklung. Mir änneren eis Spezifizéierung. Mir weisen datt mir zwee Schiermer wëllen.

Dëst ass déiselwecht Datei déi dynamesch mam Wuesstum vum System entwéckelt. Stockage nee, Stockage wäert weider diskutéiert ginn, dëst ass eng separat Thema.

Mir fidderen den YAML Bedreiwer a kucke wat geschitt.

De Bedreiwer geduecht an huet déi folgend Entitéite gemaach. Mir hu schonn zwee Pods, dräi Services an, op eemol, 2 StatefulSets. Firwat 2 StatefulSets?

Op dem Diagramm war et esou - dëst ass eisen initialen Zoustand, wa mir e Pod haten.

Et gouf esou. Bis elo ass alles einfach, et gouf duplizéiert.

A firwat sinn et zwee StatefulSets ginn? Hei musse mir d'Fro ausschwätzen an diskutéieren wéi Pods a Kubernetes geréiert ginn.

Et gëtt en Objet genannt StatefulSet deen Iech erlaabt e Set vu Pods aus enger Schabloun ze kreéieren. De Schlësselfaktor hei ass Schabloun. An Dir kënnt vill Pods starten mat enger Schabloun an engem StatefulSet. An de Schlëssel Ausdrock hei ass "vill Pods fir eng Schabloun."

An et war eng grouss Versuchung de ganze Stärekoup ze maachen, et an ee StatefulSet ze packen. Et wäert schaffen, et gëtt kee Problem mat et. Awer et gëtt eng Viraussetzung. Wa mir en heterogene Stärekoup zesummestellen wëllen, dat heescht aus verschiddene Versioune vum ClickHouse, da fänken d'Froen op. Jo, StatefulSet kann e rullende Update maachen, an do kënnt Dir eng nei Versioun ausrollen, erklären datt Dir net méi wéi sou vill Noden zur selwechter Zäit muss probéieren.

Awer wa mir d'Aufgab extrapoléieren a soen datt mir e komplett heterogene Stärekoup wëllen maachen a mir wëllen net vun der aler Versioun op eng nei änneren mat engem Rolling Update, awer mir wëllen einfach en heterogene Stärekoup erstellen souwuel a punkto. vu verschiddene Versioune vu ClickHouse a wat verschidde Späicheren ugeet. Mir wëllen zum Beispill e puer Repliken op getrennten Disken maachen, op luesen, am Allgemengen, fir en heterogene Stärekoup komplett ze bauen. A wéinst der Tatsaach datt StatefulSet eng standardiséiert Léisung aus enger Schabloun mécht, gëtt et kee Wee fir dëst ze maachen.

No e bëssen Iwwerleeung gouf decidéiert, datt mir dat esou maachen. Mir hunn all Replik a sengem eegene StatefulSet. Et ginn e puer Nodeeler fir dës Léisung, awer an der Praxis ass et alles komplett vum Bedreiwer encapsuléiert. An et gi vill Virdeeler. Mir kënnen de genaue Cluster bauen, dee mir wëllen, zum Beispill en absolut heterogenen. Dofir, an engem Stärekoup, an deem mir zwee Stécker mat enger Replika hunn, wäerte mir 2 StatefulSets an 2 Pods hunn, genee well mir dës Approche aus de Grënn hei uewen gewielt hunn fir en heterogene Stärekoup ze bauen.

Komme mer zréck op praktesch Problemer. An eisem Cluster musse mir Benotzer konfiguréieren, d.h. Dir musst e puer Konfiguratioun vu ClickHouse an Kubernetes maachen. De Bedreiwer bitt all Méiglechkeeten dofir.

Mir kënnen direkt an YAML schreiwen wat mir wëllen. All Konfiguratiounsoptioune ginn direkt vun dësem YAML an ClickHouse Konfiguratioune mapéiert, déi dann am ganze Cluster verdeelt ginn.

Dir kënnt et esou schreiwen. Dëst ass zum Beispill. D'Passwuert kann verschlësselte ginn. Absolut all ClickHouse Konfiguratiounsoptioune ginn ënnerstëtzt. Hei ass just e Beispill.

D'Clusterkonfiguratioun gëtt als ConfigMap verdeelt. An der Praxis geschitt de ConfigMap Update net direkt, also wann de Cluster grouss ass, da dauert de Prozess fir d'Konfiguratioun ze drécken. Mä all dat ass ganz bequem ze benotzen.

Loosst eis d'Aufgab komplizéiere. De Cluster entwéckelt sech. Mir wëllen Daten replizéieren. Dat ass, mir hu schonn zwee shards, eng Replica all, an Benotzer sinn konfiguréiert. Mir wuessen a wëlle Replikatioun maachen.

Wat brauche mir fir Replikatioun?

Mir brauchen ZooKeeper. Am ClickHouse gëtt Replikatioun mat ZooKeeper gebaut. ZooKeeper ass gebraucht fir datt verschidde ClickHouse Repliken e Konsens hunn iwwer wéi eng Dateblocken op wéi engem ClickHouse sinn.

ZooKeeper ka vu jidderengem benotzt ginn. Wann d'Entreprise en externen ZooKeeper huet, da kann et benotzt ginn. Wann net, kënnt Dir et aus eisem Repository installéieren. Et gëtt en Installateur deen dat Ganzt méi einfach mécht.

An d'Interaktiounsdiagramm vum ganze System stellt sech esou eraus. Mir hunn Kubernetes als Plattform. Et féiert den ClickHouse Bedreiwer aus. Ech hunn ZooKeeper hei virgestallt. An de Bedreiwer interagéiert mat ClickHouse an ZooKeeper. Dat ass, Interaktioun Resultater.

An all dat ass néideg fir ClickHouse fir erfollegräich Daten an k8s ze replizéieren.

Loosst eis elo d'Aufgab selwer kucken, wéi de Manifest fir d'Replikatioun ausgesäit.

Mir addéieren zwee Sektiounen un eisem Manifest. Déi éischt ass wou ZooKeeper ze kréien, deen entweder bannent Kubernetes oder extern ka sinn. Dëst ass just eng Beschreiwung. A mir bestellen Repliken. Déi. mir wëllen zwee replicas. Am Ganze sollte mir 4 Pods um Ausgang hunn. Mir erënneren un d'Lagerung, et wäert e bësse méi spéit zréckkommen. Stockage ass eng separat Geschicht.

Et war esou.

Et gëtt esou. Replicas ginn dobäi. Déi 4. huet net gepasst, mir gleewen datt et der vill do kéinte sinn. An ZooKeeper gëtt op d'Säit bäigefüügt. D'Schemae ginn ëmmer méi komplex.

An et ass Zäit déi nächst Aufgab derbäi ze ginn. Mir addéieren Persistent Storage.

Fir Persistent Storage hu mir verschidde Méiglechkeeten.

Wa mir an engem Cloud Provider lafen, zum Beispill Amazon, Google benotzt, da gëtt et eng grouss Versuchung fir Cloud Storage ze benotzen. Et ass ganz bequem, et ass gutt.

An et gëtt eng zweet Optioun. Dëst ass fir lokal Späichere, wa mir lokal Disken op all Node hunn. Dës Optioun ass vill méi schwéier ze realiséieren, awer gläichzäiteg ass et méi produktiv.

Loosst eis kucken wat mir iwwer Cloud Storage hunn.

Et gi Virdeeler. Et ass ganz einfach ze konfiguréieren. Mir bestellen einfach vum Cloud-Provider deen eis w.e.g. Späichere vun esou an esou Kapazitéit, vun esou an esou Klass. Klassen sinn vun Ubidder onofhängeg geplangt.

An et gëtt en Nodeel. Fir e puer ass dëst en net kriteschen Nodeel. Natierlech wäert et e puer Leeschtung Problemer ginn. Et ass ganz bequem ze benotzen an zouverlässeg, awer et ginn e puer potenziell Performance Nodeeler.

A well ClickHouse konzentréiert sech speziell op Produktivitéit, et kéint souguer soen datt et alles ausdréckt wat et kann, dofir probéieren vill Clienten maximal Produktivitéit erauszedrécken.

A fir dat Bescht ze kréien, brauche mir lokal Lagerung.

Kubernetes bitt dräi Abstraktioune fir lokal Lagerung a Kubernetes ze benotzen. Dëst:

• Empty Dir
• HostPath.
• lokal

Loosst eis kucken wéi se ënnerscheeden a wéi se ähnlech sinn.

Als éischt, an allen dräi Approche hu mir Späicheren - dëst sinn lokal Disken déi um selwechte kierperleche k8s Node sinn. Awer si hunn e puer Differenzen.

Fänke mer mat dem einfachsten un, also eidelDir. Wat ass dat an der Praxis? An eiser Spezifizéierung froe mir de Containeriséierungssystem (meeschtens Docker) fir eis Zougang zu engem Dossier op der lokaler Disk ze ginn.

An der Praxis erstellt Docker en temporäre Dossier iergendwou laanscht seng eege Weeër a nennt et e laangen Hash. A bitt en Interface fir et z'erreechen.

Wéi funktionéiert dat performant? Dëst wäert mat lokaler Scheifgeschwindegkeet funktionnéieren, d.h. Dëst ass voll Zougang zu Ärer Schraube.

Awer dëse Fall huet säin Nodeel. Persistent ass zimmlech zweifelhaft an dëser Matière. Déi éischte Kéier datt Docker mat Container beweegt, ass Persistent verluer. Wann de Kubernetes dëse Pod aus irgendege Grënn op eng aner Disk wëllt réckelen, ginn d'Donnéeë verluer.

Dës Approche ass gutt fir Tester, well et schonn normal Vitesse weist, mä fir eppes sérieux ass dës Optioun net gëeegent.

Dofir gëtt et eng zweet Approche. Dëst ass HostPath. Wann Dir de fréiere Rutsch an dësen kuckt, kënnt Dir nëmmen een Ënnerscheed gesinn. Eisen Dossier ass vum Docker direkt op de Kubernetes Node geplënnert. Et ass e bësse méi einfach hei. Mir spezifizéieren direkt de Wee am lokalen Dateiesystem wou mir eis Donnéeën späichere wëllen.

Dës Method huet Virdeeler. Dëst ass schonn e richtege Persistent, an och e Klassiker. Mir wäerten Daten op der Disk op eng Adress opgeholl hunn.

Et ginn och Nodeeler. Dëst ass d'Komplexitéit vun der Gestioun. Eis Kubernetes wëllen vläicht de Pod an en anere kierperleche Node réckelen. An dat ass wou DevOps an d'Spill kënnt. Hie muss dem ganze System richteg erklären, datt dës Pods nëmmen op déi Node geplënnert kënne ginn, op deenen Dir eppes laanscht dës Weeër montéiert hutt, an net méi wéi ee Node gläichzäiteg. Et ass zimlech schwéier.

Besonnesch fir dës Zwecker hu mir Templates an eisem Bedreiwer gemaach fir all dës Komplexitéit ze verstoppen. An Dir kënnt einfach soen: "Ech wëll eng Instanz vu ClickHouse fir all kierperlechen Node hunn a laanscht esou an esou e Wee."

Awer mir sinn net déi eenzeg, déi dëse Besoin brauchen, also verstinn d'Hären vu Kubernetes selwer och datt d'Leit Zougang zu kierperlechen Disken hunn, sou datt se eng drëtt Layer ubidden.

Et gëtt lokal genannt. Et gëtt praktesch keen Ënnerscheed vun der viregter Rutsch. Nëmmen ier et néideg war manuell ze bestätegen datt mir dës Pods net vun Node op Node kënnen transferéieren, well se op e puer Wee op eng lokal kierperlech Scheif befestegt musse sinn, awer elo ass all dëst Wëssen a Kubernetes selwer akapselt. An et stellt sech eraus vill méi einfach ze konfiguréieren.

Komme mer zréck op eise praktesche Problem. Loosst eis zréck op d'YAML Schabloun. Hei hu mir richteg Lagerung. Mir sinn zréck op et. Mir setzen déi klassesch VolumeClaim Schabloun wéi an k8s. A mir beschreiwen wat fir eng Lagerung mir wëllen.

No dëser wäert k8s Stockage Ufro. Wäert et eis am StatefulSet zoudeelen. An um Enn steet et zur Verfügung vum ClickHouse.

Mir haten dëse Schema. Eis Persistent Storage war rout, wat schéngt ze weisen datt et muss gemaach ginn.

An et gëtt gréng. Elo ass de ClickHouse op k8s Cluster Schema komplett finaliséiert. Mir hunn shards, replicas, ZooKeeper, mir hunn eng real Persistent, déi an déi eng oder aner Manéier ëmgesat ass. De Schema ass scho voll operationell.

Mir liewen weider. Eise Cluster entwéckelt sech. An Alexey probéiert, a verëffentlecht eng nei Versioun vum ClickHouse.

Eng praktesch Aufgab entsteet - déi nei Versioun vum ClickHouse op eisem Cluster ze testen. An natierlech, Dir wëllt et net alles ausrollen; Dir wëllt eng nei Versioun an enger Replica iergendwou am wäiten Eck setzen, a vläicht net eng nei Versioun, awer zwou gläichzäiteg, well se kommen dacks eraus.

Wat kënne mir doriwwer soen?

Hei hu mer grad esou eng Chance. Dëst sinn Pod Templates. Dir kënnt schreiwen datt eise Bedreiwer Iech komplett erlaabt Iech en heterogene Stärekoup ze bauen. Déi. konfiguréieren, ugefaange vun all Repliken an enger Rëtsch, mat all perséinleche Replika ophalen, wéi eng Versioun mir ClickHouse wëllen, wéi eng Versioun mir Stockage wëllen. Mir kënnen de Cluster voll mat der Konfiguratioun konfiguréieren déi mir brauchen.

Loosst eis e bësse méi déif bannen. Virun dëser hu mir geschwat wéi de ClickHouse-Bedreiwer funktionnéiert a Relatioun mat de Spezifizitéite vum ClickHouse.

Elo wëll ech e puer Wierder soen iwwer wéi all Bedreiwer am Allgemengen funktionnéiert, wéi och wéi et mat K8s interagéiert.

Loosst eis als éischt d'Interaktioun mat de K8s kucken. Wat geschitt wa mir kubectl gëllen? Eis Objete schéngen an etcd duerch d'API.

Zum Beispill, Basis Kubernetes Objete: Pod, StatefulSet, Service, a sou weider op der Lëscht.

Zur selwechter Zäit geschitt nach näischt kierperlecht. Dës Objete mussen am Cluster materialiséiert ginn.

Fir dësen Zweck erschéngt e Controller. De Controller ass e spezielle k8s Komponent deen dës Beschreiwunge ka materialiséieren. Hie weess wéi a wat kierperlech ze maachen. Hie weess wéi ee Container leeft, wat muss do konfiguréiert ginn fir datt de Server funktionnéiert.

An et materialiséiert eis Objeten an K8s.

Awer mir wëllen net nëmme mat Pods a StatefulSets operéieren, mir wëllen eng ClickHouseInstallatioun erstellen, also en Objet vum ClickHouse Typ, fir domat als eenzegt Ganzt ze bedreiwen. Bis elo gëtt et keng esou Méiglechkeet.

Mee K8s huet déi folgend flott Saach. Mir wëllen datt mir iergendwou wéi dës komplex Entitéit hunn, an där eise Cluster aus Pods a StatefulSet zesummegesat gëtt.

A wat muss dofir gemaach ginn? Als éischt kënnt Custom Ressource Definitioun an d'Bild. Wat ass et? Dëst ass eng Beschreiwung fir K8s, datt Dir eng méi Datentyp hutt, datt mir eng personaliséiert Ressource zum Pod addéiere wëllen, StatefulSet, déi bannen komplex wäert sinn. Dëst ass eng Beschreiwung vun der Datestruktur.

Mir schécken et och do iwwer kubectl application. Kubernetes huet et glécklech geholl.

An elo an eiser Lagerung huet den Objet an etcd d'Méiglechkeet fir eng personaliséiert Ressource opzehuelen genannt ClickHouseInstallation.

Awer fir de Moment wäert näischt méi geschéien. Dat ass, wa mir elo d'YAML-Datei erstellen, déi mir gekuckt hunn, d'Shards a Repliken ze beschreiwen a soen "kubectl gëllen", da akzeptéiert de Kubernetes et, setzt se an etcd a seet: "Super, awer ech weess net wat ze maachen domat. Ech weess net wéi ech ClickHouseInstallation erhalen.

Deementspriechend brauche mir een deen Kubernetes hëlleft den neien Datetyp ze déngen. Op der lénker Säit hu mir e gebiertege Kubernetes Controller dee mat gebiertege Datentypen funktionnéiert. A riets solle mir e personaliséierte Controller hunn, dee mat personaliséierten Datentypen ka schaffen.

An op eng aner Manéier gëtt et Bedreiwer genannt. Ech hunn et speziell hei als Kubernetes abegraff, well et kann och ausserhalb K8s ausgefouert ginn. Meeschtens sinn natierlech all Bedreiwer a Kubernetes ausgeführt, awer näischt verhënnert datt et dobausse steet, also hei ass et speziell dobausse geréckelt.

An am Tour interagéiert de personaliséierte Controller, och bekannt als de Bedreiwer, mat Kubernetes iwwer d'API. Et weess scho wéi een mat der API interagéiert. An hie weess scho wéi de komplexe Circuit, dee mir aus enger personaliséierter Ressource maache wëllen, materialiséieren. Dat ass genee wat de Bedreiwer mécht.

Wéi funktionnéiert de Bedreiwer? Loosst eis op der rietser Säit kucken fir ze kucken wéi hien et mécht. Loosst eis erausfannen wéi de Bedreiwer dat alles materialiséiert a wéi weider Interaktioun mat K8s geschitt.

En Operateur ass e Programm. Si ass Event-orientéiert. De Bedreiwer abonnéiert op Eventer mat der Kubernetes API. D'Kubernetes API huet Entréespunkte wou Dir op Eventer abonnéiere kënnt. A wann eppes an K8s ännert, da schéckt Kubernetes Eventer fir jiddereen, d.h. wien op dësem API Punkt abonnéiert huet, kritt Notifikatiounen.

De Bedreiwer abonnéiert op Eventer a muss eng Aart Reaktioun maachen. Seng Aufgab ass op entstanen Eventer ze reagéieren.

Eventer ginn duerch gewësse Updates generéiert. Eis YAML Datei mat enger Beschreiwung vun ClickHouseInstallation kënnt. Hien ass op etcd duerch kubectl gëllen. Do gouf en Event ausgeléist, an als Resultat koum dëst Evenement un de ClickHouse-Bedreiwer. De Bedreiwer krut dës Beschreiwung. An hie muss eppes maachen. Wann en Update fir den ClickHouseInstallation Objet ukomm ass, da musst Dir de Cluster aktualiséieren. An d'Aufgab vum Bedreiwer ass de Stärekoup ze aktualiséieren.

Wat mecht hien? Als éischt musse mir en Aktiounsplang opstellen fir wat mir mat dësem Update maachen. Updates kënne ganz kleng sinn, d.h. kleng an der YAML Ausféierung, awer ka ganz grouss Ännerungen am Stärekoup matmaachen. Dofir schafft de Bedreiwer e Plang, an dann hält hien un.

No dësem Plang fänkt hien dës Struktur bannen ze kachen fir Pods, Servicer, d.h. maachen wat seng Haaptaufgab ass. Dëst ass wéi ee ClickHouse Cluster a Kubernetes bauen.

Loosst eis elo op sou eng interessant Saach beréieren. Dëst ass eng Divisioun vun der Verantwortung tëscht Kubernetes an dem Bedreiwer, d.h. wat Kubernetes mécht, wat de Bedreiwer mécht, a wéi se matenee interagéieren.

Kubernetes ass responsabel fir System Saachen, d.h. fir eng Basis Set vun Objeten déi als System-Ëmfang interpretéiert kënne ginn. Kubernetes weess wéi Pods lancéiert ginn, wéi Container nei starten, wéi Volumen montéiert ginn, wéi een mat ConfigMap schafft, d.h. alles wat e System genannt ka ginn.

Opérateuren operéieren an Domänen. All Bedreiwer ass fir säin eegene Fachberäich gemaach. Mir hunn et fir ClickHouse gemaach.

An de Bedreiwer interagéiert präzis wat d'Themaberäich ugeet, wéi zB eng Replika derbäisetzen, en Diagramm ze maachen, d'Iwwerwaachung opzestellen. Dëst féiert zu enger Divisioun.

Loosst eis e praktescht Beispill kucken wéi dës Divisioun vun der Verantwortung geschitt wa mir d'Add Replica Aktioun maachen.

De Bedreiwer kritt eng Aufgab - eng Replika ze addéieren. Wat mécht de Bedreiwer? De Bedreiwer wäert berechent datt en neie StatefulSet erstallt muss ginn, an deem esou an esou Templates, Volume Fuerderung, musse beschriwwe ginn.

Hien huet alles virbereet a gëtt et op K8s weider. Hie seet datt hien ConfigMap, StatefulSet, Volume brauch. Kubernetes funktionnéiert. Hien materialiséiert d'Basis Eenheeten mat deenen hien operéiert.

An da kënnt ClickHouse-Bedreiwer erëm an d'Spill. Hien huet schonn e kierperleche Pod op deem hien schonn eppes maache kann. An de ClickHouse-Bedreiwer funktionnéiert erëm a Domain Begrëffer. Déi. Speziell ClickHouse, fir eng Replika an engem Stärekoup ze enthalen, musst Dir als éischt den Dateschema konfiguréieren deen an dësem Stärekoup existéiert. An zweetens muss dës Replica an d'Iwwerwaachung agefouert ginn, fir datt se kloer tracéiert ka ginn. De Bedreiwer konfiguréiert dëst schonn.

An eréischt duerno kënnt ClickHouse selwer an d'Spill, d.h. eng aner méi héich Entitéit. Dëst ass schonn eng Datebank. Et huet seng eege Instanz, eng aner konfiguréiert Replika déi prett ass fir de Cluster matzemaachen.

Et stellt sech eraus datt eng Kette vun Ausféierung an Divisioun vun Verantwortung wann Dir eng Replika bäidréit, zimlech laang ass.

Mir weiderhin eis praktesch Aufgaben. Wann Dir schonn e Cluster hutt, kënnt Dir d'Konfiguratioun migréieren.

Mir hunn et gemaach fir datt Dir direkt an existent XML Paste kënnt, wat ClickHouse versteet.

Dir kënnt ClickHouse feinjustéieren. Just zonéiert Détachement ass wat ech geschwat hunn wann ech HostPath, lokal Späichere erkläert hunn. Dëst ass wéi een zonéiert Deployment korrekt mécht.

Déi nächst praktesch Aufgab ass d'Iwwerwaachung.

Wann eise Cluster ännert, da musse mir d'Iwwerwaachung periodesch konfiguréieren.

Loosst eis d'Diagramm kucken. Déi gréng Pfeile hu mir hei schonn ugekuckt. Loosst eis elo déi rout Pfeile kucken. Esou wëlle mir eise Cluster iwwerwaachen. Wéi Metriken aus dem ClickHouse Stärekoup op Prometheus kommen, an dann op Grafana.

Wat ass d'Schwieregkeet mat der Iwwerwaachung? Firwat gëtt dëst als eng Zort Leeschtung presentéiert? D'Schwieregkeet läit an der Dynamik. Wa mir ee Stärekoup hunn an et ass statesch, da kënne mir d'Iwwerwaachung eemol astellen an net méi stéieren.

Awer wa mir vill Cluster hunn, oder eppes ännert sech permanent, dann ass de Prozess dynamesch. A stänneg d'Iwwerwaachung nei konfiguréieren ass eng Verschwendung vu Ressourcen an Zäit, d.h. souguer just faul. Dëst muss automatiséiert ginn. D'Schwieregkeet läit an der Dynamik vum Prozess. An de Bedreiwer automatiséiert dat ganz gutt.

Wéi huet eise Cluster sech entwéckelt? Am Ufank war hien esou.

Da war hien esou.

Um Enn gouf hien esou.

An d'Iwwerwaachung gëtt automatesch vum Bedreiwer gemaach. Eenzege Punkt vun der Entrée.

A just bei der Sortie kucke mir op de Grafana Dashboard fir ze kucken wéi d'Liewen vun eisem Stärekoup dobannen kachen.

Grafana Dashboard gëtt iwwregens och mat eisem Bedreiwer direkt am Quellcode verdeelt. Dir kënnt konnektéieren a benotzen. Eis DevOps huet mir dëse Screenshot ginn.

Wou wëlle mir als nächst goen? Dëst:

• Entwéckelt Testautomatiséierung. D'Haaptaufgab ass automatiséiert Testen vun neie Versiounen.
• Mir wëllen och wierklech d'Integratioun mat ZooKeeper automatiséieren. An et gi Pläng mat ZooKeeper-Bedreiwer z'integréieren. Déi. En Bedreiwer gouf fir ZooKeeper geschriwwen an et ass logesch datt déi zwee Bedreiwer ufänken ze integréieren fir eng méi praktesch Léisung ze bauen.
• Mir wëllen méi komplex vital Schëlder maachen.
• Ech hu gréng beliicht datt mir Ierfschaft vun Templates ukommen - DONE, dh mat der nächster Verëffentlechung vum Bedreiwer wäerte mir scho Ierfschaft vu Templates hunn. Dëst ass e mächtegt Tool dat Iech erlaabt komplex Konfiguratiounen aus Stécker ze bauen.
• A mir wëllen Automatisatioun vu komplexe Aufgaben. Den Haapt Saach ass Re-Sharding.

Loosst eis e puer Tëscheresultater huelen.

Wat kréie mir als Resultat? An ass et derwäert ze maachen oder net? Ass et iwwerhaapt néideg ze probéieren d'Datebank op Kubernetes ze zéien an den Bedreiwer am Allgemengen an den Alitnity Bedreiwer besonnesch ze benotzen?

Am Ausgang kréien mir:

• Bedeitend Vereinfachung an Automatiséierung vun der Konfiguratioun, Deployment an Ënnerhalt.
• Direkt gebaut-an Iwwerwachung.
• A prett-ze-benotzen kodifizéiert Template fir komplex Situatiounen. Eng Handlung wéi eng Replika bäizefügen brauch net manuell ze maachen. De Bedreiwer mécht dat.

Et bleift nëmmen eng lescht Fro. Mir hu schonn eng Datebank an Kubernetes, Virtualiséierung. Wat iwwer d'Performance vun esou enger Léisung, besonnesch well ClickHouse fir d'Performance optimiséiert ass?

D'Äntwert ass alles gutt! Ech ginn net an den Detail, dëst ass d'Thema vun engem separaten Rapport.

Mä et gëtt esou e Projet wéi TSBS. Wat ass seng Haaptaufgab? Dëst ass eng Datebank Performance Test. Dëst ass e Versuch, waarm mat waarm ze vergläichen, mëll mat mëll.

Wéi funktionéiert hien? Een Datenset gëtt generéiert. Da gëtt dëse Satz vun Daten op verschiddenen Datenbanken mat deemselwechte Set vun Tester lafen. An all Datebank léist ee Problem esou wéi se weess wéi. An da kënnt Dir d'Resultater vergläichen.

Et ënnerstëtzt schonn eng grouss Rëtsch vun Datenbanken. Ech hunn dräi Haapt identifizéiert. Dëst:

• Zäitskala DB.
• Influx DB.
• ClickHouse.

E Verglach gouf och mat enger anerer ähnlecher Léisung gemaach. Verglach mat RedShift. De Verglach gouf op Amazon gemaach. ClickHouse ass och gutt virun jidderengem an dëser Matière.

Wéi eng Conclusiounen kënnen aus deem wat ech gesot hunn?

• DB zu Kubernetes ass méiglech. Wahrscheinlech all ass méiglech, awer allgemeng gesäit et aus wéi wann et méiglech ass. ClickHouse zu Kubernetes ass definitiv méiglech mat der Hëllef vun eisem Bedreiwer.
• De Bedreiwer hëlleft Prozesser ze automatiséieren a mécht d'Liewen wierklech méi einfach.
• Leeschtung ass normal.
• An et schéngt eis, datt dat kann a soll benotzt ginn.

Open Source - maach mat!

Wéi ech scho gesot hunn, ass de Bedreiwer e komplett Open Source Produkt, also wier et ganz gutt wann déi maximal Unzuel vu Leit et benotzt. Komm mat eis! Mir waarden op Iech all!

Villmols Merci!

Är Froen

Merci fir de Bericht! Mäin Numm ass Anton. Ech sinn aus SEMrush. Ech froe mech wat mam Logbuch ass. Mir héieren iwwer Iwwerwaachung, awer näischt iwwer Logbicher, wa mir iwwer de ganze Cluster schwätzen. Zum Beispill hu mir e Cluster op Hardware opgeworf. A mir benotzen zentraliséiert Logged, sammelen se an e gemeinsame Koup mat Standardmëttelen. An da kréie mer vun do déi Donnéeën, déi eis interesséieren.

Gutt Fro, also eng Todo Lëscht aloggen. Eise Bedreiwer automatiséiert dat nach net. Et entwéckelt sech nach, de Projet ass nach relativ jonk. Mir verstinn de Besoin fir Logged. Dëst ass och e ganz wichtegt Thema. An et ass wahrscheinlech net manner wichteg wéi d'Iwwerwaachung. Awer éischt op der Lëscht fir Ëmsetzung war Iwwerwaachung. Et gëtt Logged ginn. Natierlech probéieren mir all Aspekter vum Liewen vum Stärekoup ze automatiséieren. Dofir ass d'Äntwert datt am Moment de Bedreiwer, leider, net weess wéi dëst ze maachen, awer et ass an de Pläng, mir wäerten et maachen. Wann Dir wëllt matmaachen, dann zitt d'Ufro un.

Hallo! Merci fir de Bericht! Ech hunn eng Standardfro am Zesummenhang mat Persistent Volumes. Wa mir eng Konfiguratioun mat dësem Bedreiwer erstellen, wéi bestëmmt de Bedreiwer op wéi engem Node mir e bestëmmten Disk oder Dossier befestegt hunn? Mir mussen him fir d'éischt erklären datt w.e.g. eis ClickHouse op dës Wirbelen setzen déi eng Scheif hunn?

Souwäit ech verstinn, ass dës Fro eng Fortsetzung vun der lokaler Späichere, besonnesch den HostPath Deel dovun. Dat ass wéi de ganze System z'erklären, datt de Pod op esou an esou engem Node lancéiert muss ginn, op deen mir eng physesch verbonne Scheif hunn, déi laanscht esou an esou e Wee montéiert ass. Dëst ass eng ganz Rubrik, déi ech ganz iwwerflächlech beréiert hunn, well d'Äntwert do zimlech grouss ass.

Kuerz gesot gesäit et esou aus. Natierlech musse mir dës Volumen zur Verfügung stellen. Am Moment gëtt et keng dynamesch Dispositioun an der lokaler Späichere, sou datt DevOps d'Disks selwer musse schneiden, dës Bänn. A si musse Kubernetes Bestëmmung erklären datt Dir Persistent Bänn vun esou an esou Klasse wäert hunn, déi op esou an esou Noden lokaliséiert sinn. Da musst Dir Kubernetes erklären datt Pods, déi sou an esou eng lokal Späicherklass erfuerderen, nëmmen op esou an esou Noden mat Etiketten geriicht musse ginn. Fir dës Zwecker huet de Bedreiwer d'Fäegkeet eng Aart Label an een pro Hostinstanz ze ginn. An et stellt sech eraus datt Pods vu Kubernetes geréckelt ginn fir nëmmen op Wirbelen ze lafen, déi den Ufuerderungen, Etiketten, an einfache Begrëffer entspriechen. Administrateuren ginn Etiketten a Versuergungsdisken manuell zou. An dann schalt et.

An et ass déi drëtt Optioun, lokal, déi hëlleft dëst e bësse méi einfach ze maachen. Wéi ech scho betount hunn, ass dëst ustrengend Aarbecht beim Tuning, wat schlussendlech hëlleft fir maximal Leeschtung ze kréien.

Ech hunn eng zweet Fro am Zesummenhang mat dëser. Kubernetes gouf esou entworf datt et eis egal ass ob mir en Node verléieren oder net. Wat solle mir an dësem Fall maachen, wa mir den Node verluer hunn, wou eise Schnéi hänkt?

Jo, Kubernetes war am Ufank positionéiert datt eis Relatioun mat eise Pods wéi Ranner ass, awer hei bei eis gëtt all Scheif eppes wéi en Hausdéier. Et gëtt esou e Problem, datt mir se net einfach kënnen ewech werfen. An d'Entwécklung vu Kubernetes geet an d'Richtung datt et onméiglech ass et philosophesch komplett ze behandelen, wéi wann et eng komplett verworf Ressource wier.

Elo fir eng praktesch Fro. Wat maache wann Dir den Node verluer hutt op deem den Disk war? Hei gëtt de Problem op engem méi héijen Niveau geléist. Am Fall vum ClickHouse hu mir Repliken déi op engem méi héijen Niveau funktionnéieren, d.h. um ClickHouse Niveau.

Wat ass déi resultéierend Dispositioun? DevOps ass verantwortlech fir sécherzestellen datt Daten net verluer sinn. Hie muss d'Replikatioun korrekt astellen a muss sécherstellen datt d'Replikatioun leeft. D'Replika um ClickHouse Niveau muss duplizéiert Daten hunn. Dëst ass net de Problem deen de Bedreiwer léist. An net de Problem deen Kubernetes selwer léist. Dëst ass um ClickHouse Niveau.

Wat maache wann Ären Eisennode fällt? An et stellt sech eraus datt Dir en zweeten installéiere musst, d'Disc op se richteg virbereeden an d'Etiketten opmaachen. An duerno wäert et den Ufuerderunge entspriechen datt Kubernetes en Instanz Pod drop lancéiere kann. Kubernetes wäert et starten. Är Zuel vu Pods ass net genuch fir déi spezifizéiert Zuel ze treffen. Et wäert duerch den Zyklus goen, deen ech gewisen hunn. An um héchsten Niveau wäert ClickHouse verstoen datt mir eng Replika eraginn hunn, et ass nach ëmmer eidel a mir mussen ufänken d'Donnéeën ze transferéieren. Déi. Dëse Prozess ass nach net gutt automatiséiert.

Merci fir de Bericht! Wann all méiglech béis Saache geschéien, de Bedreiwer crasht an nei start, an dee Moment kommen d'Evenementer un, handhabt Dir dat iergendwéi?

Wat geschitt wann de Bedreiwer erofgefall an nei gestart huet, richteg?

Jo. An dee Moment koumen d'Evenementer.

D'Aufgab wat an dësem Fall ze maachen ass deelweis tëscht dem Bedreiwer a Kubernetes gedeelt. Kubernetes huet d'Fäegkeet en Event ze widderhuelen deen geschitt ass. Hien replays. An d'Aufgab vum Bedreiwer ass sécher ze stellen datt wann den Eventprotokoll op him erëmgespillt gëtt, dës Eventer idempotent sinn. A sou datt de widderholl Optriede vum selwechten Event eise System net brécht. An eise Bedreiwer këmmert sech mat dëser Aufgab.

Hallo! Merci fir de Bericht! Dmitry Zavyalov, Firma Smedova. Ginn et Pläng fir d'Fäegkeet ze addéieren fir mat Haproxy dem Bedreiwer ze konfiguréieren? Ech wier interesséiert un engem aneren Balancer nieft dem Standard, sou datt et intelligent ass a versteet datt ClickHouse wierklech do ass.

Schwätzt Dir vun Ingress?

Jo, ersetzt Ingress mat Haproxy. An Haproxy kënnt Dir d'Topologie vum Stärekoup spezifizéieren wou et Repliken huet.

Mir hunn nach net driwwer geduecht. Wann Dir et braucht a kënnt erkläre firwat et néideg ass, da wäert et méiglech sinn et ëmzesetzen, besonnesch wann Dir wëllt matmaachen. Mir wäerten frou d'Optioun ze betruecht. Déi kuerz Äntwert ass nee, mir hu momentan keng sou Funktionalitéit. Merci fir den Tipp, mir wäerten dës Saach kucken. A wann Dir och de Gebrauchsfall erkläert a firwat et an der Praxis gebraucht gëtt, zum Beispill, Themen op GitHub erstellen, da wäert dat super sinn.

Huet schonn.

Gutt. Mir sinn op fir all Virschléi. An Haproxy gëtt op d'Todo Lëscht bäigefüügt. D'Todo Lëscht wiisst, schrumpft nach net. Awer dëst ass gutt, et heescht datt d'Produkt gefuerdert ass.

Source: will.com