2010 företaget det fanns 50 servrar och en enkel nätverksmodell: backend, frontend och brandvägg. Antalet servrar växte, modellen blev mer komplex: iscensättning, isolerade VLAN med ACL, sedan VPN med VRF, VLAN med ACL på L2, VRF med ACL på L3. Snurrar huvudet? Det blir roligare sen.
När det fanns 16 000 servrar blev det omöjligt att arbeta utan tårar med så många heterogena segment. Så vi kom på en annan lösning. Vi tog Netfilter-stacken, lade till Consul till den som en datakälla och vi fick en snabbt distribuerad brandvägg. De ersatte ACL på routrar och använde dem som en extern och intern brandvägg. För att dynamiskt hantera verktyget utvecklade vi BEFW-systemet, som användes överallt: från att hantera användaråtkomst till produktnätverket till att isolera nätverkssegment från varandra.
Han kommer att berätta hur det hela fungerar och varför du bör titta närmare på detta system. Ivan Agarkov () är chef för infrastruktursäkerhetsgruppen för underhållsdivisionen vid företagets utvecklingscenter i Minsk. Ivan är ett SELinux-fan, älskar Perl och skriver kod. Som chef för informationssäkerhetsgruppen arbetar han regelbundet med loggar, backuper och FoU för att skydda Wargaming från hackare och säkerställa driften av alla spelservrar i företaget.
Historisk information
Innan jag berättar hur vi gjorde det, ska jag berätta hur vi kom fram till det här från början och varför det behövdes. För att göra detta, låt oss gå tillbaka 9 år: 2010 dök World of Tanks upp. Wargaming hade cirka 50 servrar.
Företagets servertillväxtdiagram.
Vi hade en nätverksmodell. För den tiden var det optimalt.
Nätverksmodell 2010.
Det finns skurkar på fronten som vill knäcka oss, men den har en brandvägg. Det finns ingen brandvägg på backend, men det finns 50 servrar där, vi känner till dem alla. Allt fungerar bra.
På fyra år växte serverflottan 4 gånger, till 100. De första isolerade nätverken dök upp - iscensättning: de kunde inte gå till produktion, och det var ofta saker som körde där som kunde vara farliga.
Nätverksmodell 2014.
Genom tröghet använde vi samma hårdvara, och allt arbete utfördes på isolerade VLAN: ACL skrivs till VLAN, som tillåter eller förnekar någon form av anslutning.
Under 2016 nådde antalet servrar 8000 XNUMX. Wargaming absorberade andra studior och ytterligare affiliate-nätverk dök upp. De verkar vara våra, men inte riktigt: VLAN fungerar ofta inte för partners, du måste använda VPN med VRF, isolering blir mer komplicerat. ACL-isoleringsblandningen växte.
Nätverksmodell 2016.
I början av 2018 hade maskinparken vuxit till 16 000. Det fanns 6 segment, och vi räknade inte resten, inklusive slutna sådana där finansiell data lagrades. Containernätverk (Kubernetes), DevOps, molnnätverk anslutna via VPN, till exempel från ett IVS, har dykt upp. Det fanns många regler - det var smärtsamt.
Nätverksmodell och isoleringsmetoder 2018.
För isolering använde vi: VLAN med ACL på L2, VRF med ACL på L3, VPN och mycket mer. För mycket.
Problem
Alla lever med ACL och VLAN. Vad är fel? Denna fråga kommer att besvaras av Harold och döljer smärtan.
Det fanns många problem, men det fanns fem stora.
- Geometrisk prishöjning för nya regler. Varje ny regel tog längre tid att lägga till än den tidigare, eftersom det var nödvändigt att först se om det redan fanns en sådan regel.
- Ingen brandvägg inuti segment. Segmenten var på något sätt separerade från varandra, och det fanns redan inte tillräckligt med resurser inuti.
- Reglerna har tillämpats under lång tid. Operatörer kunde skriva en lokal regel för hand på en timme. Den globala tog flera dagar.
- Svårigheter med revisionsregler. Mer exakt var det inte möjligt. De första reglerna skrevs redan 2010, och de flesta av deras författare arbetade inte längre för företaget.
- Låg nivå av infrastrukturkontroll. Detta är huvudproblemet - vi visste inte så väl vad som pågick i vårt land.
Så här såg en nätverksingenjör ut 2018 när han hörde: "Behöver lite mer ACL."
Решения
I början av 2018 beslutades det att göra något åt saken.
Priset på integrationer växer hela tiden. Utgångspunkten var att stora datacenter slutade stödja isolerade VLAN och ACL eftersom enheterna fick slut på minne.
Lösning: vi tog bort den mänskliga faktorn och automatiserade tillhandahållandet av tillgång till maximalt.
De nya reglerna tar lång tid att tillämpa. Lösning: påskynda tillämpningen av regler, gör den distribuerad och parallell. Detta kräver ett distribuerat system så att reglerna levereras själva, utan rsync eller SFTP till tusen system.
Ingen brandvägg inuti segment. En brandvägg inom segment började komma till oss när olika tjänster dök upp inom samma nätverk. Lösning: använd en brandvägg på värdnivå - värdbaserade brandväggar. Nästan överallt där vi har Linux, och överallt vi har iptables, är detta inte ett problem.
Svårigheter med revisionsregler. Lösning: Håll alla regler på ett ställe för granskning och hantering, så att vi kan granska allt.
Låg kontroll över infrastrukturen. Lösning: inventera alla tjänster och åtkomster mellan dem.
Detta är mer en administrativ process än en teknisk. Ibland har vi 200-300 nya releaser i veckan, speciellt under kampanjer och helgdagar. Dessutom är detta bara för ett team av våra DevOps. Med så många utgåvor är det omöjligt att se vilka portar, IP:er och integrationer som behövs. Därför behövde vi specialutbildade servicechefer som frågade teamen: "Vad finns det egentligen och varför tog ni upp det?"
Efter allt vi lanserade började en nätverksingenjör 2019 se ut så här.
Konsul
Vi bestämde att vi skulle lägga allt som vi hittade med hjälp av servicechefer i Consul och därifrån skulle vi skriva iptables regler.
Hur bestämde vi oss för att göra detta?
- Vi kommer att samla in alla tjänster, nätverk och användare.
- Låt oss skapa iptables-regler baserat på dem.
- Vi automatiserar kontrollen.
- ....
- VINST.
Consul är inte ett fjärr-API, det kan köras på alla noder och skriva till iptables. Allt som återstår är att komma med automatiska kontroller som rensar bort onödiga saker, och de flesta problemen kommer att lösas! Vi fixar resten allt eftersom.
Varför konsul?
Har visat sig väl. Under 2014-15 använde vi det som en backend för Vault, där vi lagrar lösenord.
Förlorar inte data. Under användningstiden förlorade Consul inte data under en enda olycka. Detta är ett stort plus för ett brandväggssystem.
P2P-anslutningar påskyndar spridningen av förändringar. Med P2P kommer alla förändringar snabbt, du behöver inte vänta i timmar.
Bekvämt REST API. Vi övervägde också Apache ZooKeeper, men den har inget REST API, så du måste installera kryckor.
Fungerar både som ett nyckelvalv (KV) och en katalog (Service Discovery). Du kan lagra tjänster, kataloger och datacenter på en gång. Detta är praktiskt inte bara för oss utan också för angränsande team, för när vi bygger en global tjänst tänker vi stort.
Skrivet i Go, som är en del av Wargaming-stacken. Vi älskar det här språket, vi har många Go-utvecklare.
Kraftfullt ACL-system. I Consul kan du använda ACL för att styra vem som skriver vad. Vi garanterar att brandväggsreglerna inte kommer att överlappa med något annat och vi kommer inte ha problem med detta.
Men Consul har också sina nackdelar.
- Skalas inte i ett datacenter om du inte har en affärsversion. Det är bara skalbart av federation.
- Mycket beroende på kvaliteten på nätverket och serverbelastningen. Consul kommer inte att fungera korrekt som server på en upptagen server om det finns några fördröjningar i nätverket, till exempel ojämn hastighet. Detta beror på P2P-anslutningar och uppdaterade distributionsmodeller.
- Svårighet att övervaka tillgänglighet. I konsulstatus kan han säga att allt är bra, men han dog för länge sedan.
Vi löste de flesta av dessa problem när vi använde Consul, varför vi valde det. Företaget har planer på en alternativ backend, men vi har lärt oss att hantera problem och bor just nu hos Consul.
Hur Consul fungerar
Vi kommer att installera tre till fem servrar i ett villkorat datacenter. En eller två servrar kommer inte att fungera: de kommer inte att kunna organisera ett kvorum och avgöra vem som har rätt och vem som har fel när uppgifterna inte stämmer överens. Mer än fem är ingen mening, produktiviteten kommer att sjunka.
Klienter ansluter till servrarna i valfri ordning: samma agenter, bara med flaggan server = false.
Efter detta får kunderna en lista över P2P-anslutningar och bygger anslutningar sinsemellan.
På global nivå kopplar vi ihop flera datacenter. De kopplar också upp P2P och kommunicerar.
När vi vill hämta data från ett annat datacenter går förfrågan från server till server. Detta schema kallas Serf-protokoll. Serf-protokollet, liksom Consul, är utvecklat av HashiCorp.
Några viktiga fakta om Consul
Consul har dokumentation som beskriver hur det fungerar. Jag kommer bara att ge utvalda fakta som är värda att veta.
Konsulservrar väljer en master bland väljarna. Consul väljer en master från listan över servrar för varje datacenter, och alla förfrågningar går bara till den, oavsett antalet servrar. Masterfrysning leder inte till omval. Om mastern inte är vald, betjänas inte förfrågningar av någon.
Ville du ha horisontell skalning? Förlåt, nej.
En förfrågan till ett annat datacenter går från master till master, oavsett vilken server den kom till. Den valda mastern tar emot 100 % av lasten, förutom lasten på vidarebefordran. Alla servrar i datacentret har en uppdaterad kopia av datan, men bara en svarar.
Det enda sättet att skala är att aktivera inaktuellt läge på klienten.
I inaktuellt läge kan du svara utan beslutförhet. Detta är ett läge där vi ger upp datakonsistens, men läser lite snabbare än vanligt, och vilken server som helst svarar. Naturligtvis inspelning endast genom mastern.
Consul kopierar inte data mellan datacenter. När en federation är sammansatt kommer varje server bara att ha sina egna data. För andra vänder han sig alltid till någon annan.
Atomiciteten för verksamheten garanteras inte utanför en transaktion. Kom ihåg att du inte är den enda som kan förändra saker. Om du vill ha det annorlunda, gör en transaktion med ett lås.
Blockeringsoperationer garanterar inte låsning. Förfrågan går från master till master, och inte direkt, så det finns ingen garanti för att blockeringen fungerar när du blockerar till exempel i ett annat datacenter.
ACL garanterar inte heller åtkomst (i många fall). ACL kanske inte fungerar eftersom den är lagrad i ett federationsdatacenter - i ACL-datacentret (Primary DC). Om DC inte svarar dig kommer ACL inte att fungera.
En frusen master kommer att få hela förbundet att frysa. Till exempel finns det 10 datacenter i en federation, och ett har ett dåligt nätverk och en master misslyckas. Alla som kommunicerar med honom kommer att frysa i en cirkel: det finns en begäran, det finns inget svar på det, tråden fryser. Det finns inget sätt att veta när detta kommer att hända, bara om en timme eller två faller hela förbundet. Det finns inget du kan göra åt det.
Status, beslutförhet och val hanteras av en separat tråd. Omval kommer inte att ske, status kommer inte att visa någonting. Du tror att du har en levande konsul, du frågar, och ingenting händer - det finns inget svar. Samtidigt visar status att allt är bra.
Vi har stött på det här problemet och var tvungna att bygga om specifika delar av datacenter för att undvika det.
Affärsversionen av Consul Enterprise har inte några av nackdelarna ovan. Den har många användbara funktioner: välja väljare, distribution, skalning. Det finns bara ett "men" - licenssystemet för ett distribuerat system är mycket dyrt.
Livshackning: rm -rf /var/lib/consul - ett botemedel mot alla sjukdomar hos medlet. Om något inte fungerar för dig, radera bara dina data och ladda ner data från en kopia. Mest troligt kommer Consul att arbeta.
BEFW
Låt oss nu prata om vad vi har lagt till Consul.
är en akronym för BackEndFvredeWAllt. Jag var tvungen att namnge produkten på något sätt när jag skapade arkivet för att kunna lägga in de första testbekräftelserna i den. Detta namn finns kvar.
Regelmallar
Reglerna är skrivna i iptables-syntax.
- -N BEFW
- -P INPUT DROP
- -A INPUT -m tillstånd—tillstånd RELATED,ETABLISHED -j ACCEPTERA
- -A INPUT -i lo -j ACCEPTERA
- -A INPUT -j BEFW
Allt går in i BEFW-kedjan, utom ESTABLISHED, RELATED och lokalvärd. Mallen kan vara vad som helst, detta är bara ett exempel.
Hur är BEFW användbar?
Tjänster
Vi har en tjänst, den har alltid en port, en nod som den körs på. Från vår nod kan vi lokalt fråga agenten och få reda på att vi har någon form av tjänst. Du kan också sätta taggar.
Alla tjänster som körs och registreras hos Consul förvandlas till en iptables-regel. Vi har SSH - öppen port 22. Bash-skriptet är enkelt: curl och iptables, inget annat behövs.
Kunder
Hur öppnar man åtkomst inte för alla, men selektivt? Lägg till IP-listor till KV-lagring efter tjänstnamn.
Till exempel vill vi att alla på det tionde nätverket ska kunna komma åt tjänsten SSH_TCP_22. Lägg till ett litet TTL-fält? och nu har vi tillfälliga tillstånd för till exempel en dag.
Åtkomster
Vi kopplar samman tjänster och kunder: vi har en tjänst, KV-lagring är redo för varje. Nu ger vi tillgång inte till alla, utan selektivt.
Grupper
Om vi skriver tusentals IP-adresser för åtkomst varje gång kommer vi att tröttna. Låt oss komma på grupperingar - en separat delmängd i KV. Låt oss kalla det Alias (eller grupper) och lagra grupper där enligt samma princip.
Låt oss ansluta: nu kan vi öppna SSH inte specifikt för P2P, utan för en hel grupp eller flera grupper. På samma sätt finns TTL - du kan lägga till i en grupp och ta bort från gruppen tillfälligt.
Интеграция
Vårt problem är den mänskliga faktorn och automatisering. Hittills har vi löst det så här.
Vi arbetar med Puppet och överför allt som rör systemet (applikationskod) till dem. Puppetdb (vanlig PostgreSQL) lagrar en lista över tjänster som körs där, de kan hittas efter resurstyp. Där kan du ta reda på vem som ansöker var. Vi har även ett pull request och merge request system för detta.
Vi skrev befw-sync, en enkel lösning som hjälper till att överföra data. Först nås sync-cookies av puppetdb. Ett HTTP API är konfigurerat där: vi begär vilka tjänster vi har, vad som behöver göras. Sedan gör de en begäran till konsul.
Finns det integration? Ja: de skrev reglerna och lät Pull Requests accepteras. Behöver du en viss port eller lägga till en värd till någon grupp? Dra Begäran, granska - inte mer "Hitta 200 andra ACL och försök göra något åt det."
optimering
Att pinga localhost med en tom regelkedja tar 0,075 ms.
Låt oss lägga till 10 000 iptables-adresser till den här kedjan. Som ett resultat kommer pinget att öka 5 gånger: iptables är helt linjärt, att bearbeta varje adress tar lite tid.
För en brandvägg där vi migrerar tusentals ACL:er har vi många regler, och detta introducerar latens. Detta är dåligt för spelprotokoll.
Men om vi sätter 10 000 adresser i ipset Pingen kommer till och med att minska.
Poängen är att "O" (algoritmkomplexitet) för ipset alltid är lika med 1, oavsett hur många regler det finns. Det finns sant att det finns en begränsning - det kan inte finnas fler än 65535 regler. För närvarande lever vi med detta: du kan kombinera dem, utöka dem, göra två ipsets i en.
Förvaring
En logisk fortsättning på iterationsprocessen är att lagra information om klienter för tjänsten i ipset.
Nu har vi samma SSH, och vi skriver inte 100 IP-adresser på en gång, utan ställer in namnet på den ipset som vi behöver kommunicera med, och följande regel DROP. Det kan omvandlas till en regel "Vem är inte här, DROP", men det är tydligare.
Nu har vi regler och uppsättningar. Huvuduppgiften är att göra en uppsättning innan du skriver regeln, för annars kommer inte iptables att skriva regeln.
Allmän ordning
I form av ett diagram ser allt jag sa ut så här.
Vi förbinder oss till Puppet, allt skickas till värden, tjänster här, ipset där, och alla som inte är registrerade där är inte tillåtna.
Tillåta neka
För att snabbt rädda världen eller snabbt inaktivera någon, gjorde vi två ipsets i början av alla kedjor: rules_allow и rules_deny. Hur det fungerar?
Till exempel, någon skapar en belastning på vår webb med bots. Tidigare var du tvungen att hitta hans IP från loggarna, ta den till nätverksingenjörer, så att de kunde hitta källan till trafiken och förbjuda honom. Det ser annorlunda ut nu.
Vi skickar det till Consul, vänta 2,5 sekunder och det är klart. Eftersom Consul distribuerar snabbt genom P2P fungerar det överallt, i alla delar av världen.
En gång slutade jag på något sätt helt WOT på grund av ett misstag med brandväggen. rules_allow – det här är vår försäkring mot sådana fall. Om vi gjorde ett misstag någonstans med brandväggen, något är blockerat någonstans, vi kan alltid skicka en villkorad 0.0/0att snabbt plocka upp allt. Senare fixar vi allt för hand.
Andra uppsättningar
Du kan lägga till andra uppsättningar i rymden $IPSETS$.
För vad? Ibland behöver någon ipset, till exempel för att efterlikna avstängningen av någon del av klustret. Vem som helst kan ta med vilka uppsättningar som helst, namnge dem, så hämtas de från Consul. Samtidigt kan set antingen delta i iptables regler eller fungera som ett lag NOOP: Konsistens kommer att upprätthållas av demonen.
Medlemmar
Tidigare var det så här: användaren kopplade till nätverket och fick parametrar via domänen. Före tillkomsten av den nya generationens brandväggar visste Cisco inte hur man skulle förstå var användaren var och var IP:n var. Därför beviljades åtkomst endast via maskinens värdnamn.
Vad gjorde vi? Vi fastnade i det ögonblick vi fick adressen. Vanligtvis är detta dot1x, Wi-Fi eller VPN - allt går genom RADIUS. För varje användare skapar vi en grupp efter användarnamn och placerar en IP i den med en TTL som är lika med dess dhcp.lease - så fort den löper ut försvinner regeln.
Nu kan vi öppna åtkomst till tjänster, precis som andra grupper, efter användarnamn. Vi har tagit bort smärtan av värdnamn när de ändras, och vi har tagit bort bördan från nätverksingenjörer eftersom de inte längre behöver Cisco. Nu registrerar ingenjörer själva åtkomst på sina servrar.
Isolering
Samtidigt började vi demontera isoleringen. Servicechefer gjorde en inventering och vi analyserade alla våra nätverk. Låt oss dela upp dem i samma grupper, och på de nödvändiga servrarna lades grupperna till, till exempel för att neka. Nu hamnar samma iscensättningsisolering i produktionens regler_förneka, men inte i själva produktionen.
Schemat fungerar snabbt och enkelt: vi tar bort alla ACL från servrarna, laddar ur hårdvaran och minskar antalet isolerade VLAN.
Integritetskontroll
Tidigare hade vi en speciell trigger som rapporterade när någon ändrade en brandväggsregel manuellt. Jag skrev en enorm linter för att kontrollera brandväggsreglerna, det var svårt. Integriteten kontrolleras nu av BEFW. Han ser ivrigt till att reglerna han gör inte ändras. Om någon ändrar brandväggsreglerna kommer det att ändra tillbaka allt. "Jag satte snabbt upp en proxy så att jag kunde arbeta hemifrån" - det finns inga fler sådana alternativ.
BEFW styr ipset från tjänsterna och listan i befw.conf, reglerna för tjänster i BEFW-kedjan. Men den övervakar inte andra kedjor och regler och andra ipsets.
Krockskydd
BEFW lagrar alltid det senast kända goda tillståndet direkt i den binära strukturen state.bin. Om något går fel rullar det alltid tillbaka till denna state.bin.
Detta är en försäkring mot instabil Consul-drift, när den inte skickade data eller någon gjorde ett misstag och använde regler som inte kan tillämpas. För att säkerställa att vi inte lämnas utan en brandvägg kommer BEFW att rulla tillbaka till det senaste tillståndet om ett fel inträffar i något skede.
I kritiska situationer är detta en garanti för att vi kommer att sitta kvar med en fungerande brandvägg. Vi öppnar alla gråa nätverk i hopp om att admin kommer och fixar det. Någon gång kommer jag att lägga in detta i konfigurationerna, men nu har vi bara tre gråa nätverk: 10/8, 172/12 och 192.168/16. Inom vår konsul är detta en viktig funktion som hjälper oss att utvecklas vidare.
Demo: under rapporten demonstrerar Ivan demoläget för BEFW. Det är lättare att se demonstrationen . Demo källkod tillgänglig .
Fallgropar
Jag ska berätta om de buggar vi stötte på.
ipset add set 0.0.0.0/0. Vad händer om du lägger till 0.0.0.0/0 till ipset? Kommer alla IP-adresser att läggas till? Kommer internetåtkomst att vara tillgänglig?
Nej, vi får en bugg som kostade oss två timmars driftstopp. Dessutom har buggen inte fungerat sedan 2016, den ligger i RedHat Bugzilla under nummer #1297092, och vi hittade den av en slump - från en utvecklarrapport.
Det är nu en strikt regel på BEFW att 0.0.0.0/0 blir till två adresser: 0.0.0.0/1 и 128.0.0.0/1.
ipset återställ set < fil. Vad gör ipset när du säger till det restore? Tror du att det fungerar på samma sätt som iptables? Kommer det att återställa data?
Inget sådant - det slår samman, och de gamla adresserna går ingenstans, du blockerar inte åtkomst.
Vi hittade en bugg när vi testade isolering. Nu finns det ett ganska komplext system – istället för restore utförs create tempdå restore flush temp и restore temp. I slutet av swap: för atomicitet, för om du gör det först flush och i detta ögonblick kommer något paket, det kommer att kasseras och något kommer att gå fel. Så det finns lite svart magi där.
konsul kv få -datacenter=övrigt. Vi tror som sagt att vi efterfrågar en del data, men vi får antingen data eller ett fel. Vi kan göra detta via Consul lokalt, men i det här fallet kommer båda att frysa.
Den lokala Consul-klienten är ett omslag över HTTP API. Men den bara hänger och svarar inte bara på Ctrl+C, eller Ctrl+Z eller något annat kill -9 i nästa konsol. Vi stötte på detta när vi byggde ett stort kluster. Men vi har ingen lösning än, vi förbereder oss för att fixa detta fel i Consul.
Konsulledaren svarar inte. Vår mästare i datacentret svarar inte, vi tänker: "Kanske kommer omvalsalgoritmen att fungera nu?"
Nej, det kommer inte att fungera, och övervakning kommer inte att visa någonting: Consul kommer att säga att det finns ett engagemangsindex, en ledare har hittats, allt är bra.
Hur hanterar vi detta? service consul restart i cron varje timme. Om du har 50 servrar, ingen stor sak. När det finns 16 000 av dem kommer du att förstå hur det fungerar.
Slutsats
Som ett resultat fick vi följande fördelar:
- 100% täckning av alla Linux-maskiner.
- Speed.
- Automatisering.
- Vi befriade hårdvaru- och nätverksingenjörer från slaveri.
- Det har dykt upp integrationsmöjligheter som är nästan obegränsade: även med Kubernetes, även med Ansible, till och med med Python.
Nackdelar: Konsul, som vi nu måste leva med, och den mycket höga kostnaden för fel. Som ett exempel, en gång vid 6-tiden (sändningstid i Ryssland) redigerade jag något i listorna över nätverk. Vi byggde precis isolering på BEFW vid den tiden. Jag gjorde ett misstag någonstans, det verkar som om jag angav fel mask, men allt föll på två sekunder. Övervakningen tänds, vakthavande stödperson kommer springande: "Vi har allt!" Avdelningschefen blev grå när han förklarade för verksamheten varför det hände.
Kostnaden för fel är så hög att vi har tagit fram ett eget komplext förebyggande förfarande. Om du implementerar detta på en stor produktionsplats behöver du inte ge en master-token över Consul till alla. Detta kommer att sluta illa.
Kostnad. Jag skrev bara kod för 400 timmar. Mitt team på 4 personer lägger 10 timmar i månaden på support för alla. Jämfört med priset på en ny generations brandvägg är det gratis.
Planer. Den långsiktiga planen är att hitta alternativa transporter för att ersätta eller komplettera Consul. Kanske blir det Kafka eller något liknande. Men under de kommande åren kommer vi att leva på Consul.
Omedelbara planer: integration med Fail2ban, med övervakning, med nftables, eventuellt med andra distributioner, mätvärden, avancerad övervakning, optimering. Kubernetes support finns också någonstans i planerna, för nu har vi flera kluster och önskan.
Mer från planerna:
- söka efter anomalier i trafiken;
- hantering av nätverkskartor;
- Kubernetes-stöd;
- montering av paket för alla system;
- Webb-UI.
Vi arbetar ständigt med att utöka konfigurationen, öka mätvärdena och optimera.
Gå med i projektet. Projektet visade sig vara coolt, men tyvärr är det fortfarande ett enmansprojekt. Komma till och försök göra något: begå, testa, föreslå något, ge din bedömning.
Samtidigt förbereder vi oss , som äger rum den 6 och 7 april i St. Petersburg, och vi bjuder in utvecklare av högbelastningssystem . Erfarna talare vet redan vad de ska göra, men för de som är nybörjare rekommenderar vi åtminstone . Att delta i konferensen som talare har en rad fördelar. Vilka kan du läsa till exempel i slutet .
Källa: will.com