L'any 2010 l'empresa hi havia 50 servidors i un model de xarxa senzill: backend, frontend i firewall. El nombre de servidors va créixer, el model es va fer més complex: escenificació, VLAN aïllades amb ACL, després VPN amb VRF, VLAN amb ACL a L2, VRF amb ACL a L3. El cap gira? Més endavant serà més divertit.
Quan hi havia 16 servidors, es va fer impossible treballar sense llàgrimes amb tants segments heterogenis. Així que vam trobar una altra solució. Vam agafar la pila Netfilter, hi vam afegir Consul com a font de dades i vam obtenir un tallafoc distribuït ràpidament. Van substituir les ACL als encaminadors i les van utilitzar com a tallafocs extern i intern. Per gestionar l'eina de manera dinàmica, vam desenvolupar el sistema BEFW, que s'utilitzava a tot arreu: des de la gestió de l'accés dels usuaris a la xarxa del producte fins a l'aïllament dels segments de la xarxa entre si.
Ell us dirà com funciona tot i per què hauríeu de mirar més de prop aquest sistema. Ivan Agarkov () és el cap del grup de seguretat d'infraestructura de la divisió de manteniment al centre de desenvolupament de Minsk de l'empresa. L'Ivan és un fan de SELinux, li encanta Perl i escriu codi. Com a cap del grup de seguretat de la informació, treballa regularment amb registres, còpies de seguretat i R+D per protegir Wargaming dels pirates informàtics i garantir el funcionament de tots els servidors de jocs de l'empresa.
La informació històrica
Abans d'explicar-vos com ho vam fer, us explicaré com vam arribar a això en primer lloc i per què era necessari. Per fer-ho, retrocedim 9 anys: 2010, acaba d'aparèixer World of Tanks. Wargaming tenia aproximadament 50 servidors.
Gràfic de creixement del servidor de l'empresa.
Teníem un model de xarxa. Per aquell moment era òptim.
Model de xarxa el 2010.
Hi ha nois dolents al front que volen trencar-nos, però té un tallafoc. No hi ha tallafocs al backend, però hi ha 50 servidors, els coneixem tots. Tot funciona bé.
En 4 anys, la flota de servidors va créixer 100 vegades, fins a arribar a 5000. Van aparèixer les primeres xarxes aïllades: posada en escena: no podien anar a la producció i sovint hi havia coses que hi funcionaven que podien ser perilloses.
Model de xarxa el 2014.
Per inèrcia, vam utilitzar les mateixes peces de maquinari, i tot el treball es va fer en VLAN aïllades: les ACL s'escriuen a les VLAN, que permeten o deneguen algun tipus de connexió.
El 2016, el nombre de servidors va arribar als 8000. Wargaming va absorbir altres estudis i van aparèixer xarxes d'afiliació addicionals. Sembla que són nostres, però no del tot: la VLAN sovint no funciona per als socis, cal utilitzar VPN amb VRF, l'aïllament es fa més complicat. La barreja d'aïllament ACL va créixer.
Model de xarxa el 2016.
A principis del 2018, el parc de màquines havia crescut fins a 16. Hi havia 000 segments, i la resta no els vam comptabilitzar, inclosos els tancats en què s'emmagatzemaven dades financeres. Han aparegut xarxes de contenidors (Kubernetes), DevOps, xarxes de núvol connectades mitjançant VPN, per exemple, des d'un IVS. Hi havia moltes regles: era dolorós.
Model de xarxa i mètodes d'aïllament el 2018.
Per aïllar-nos hem utilitzat: VLAN amb ACL a L2, VRF amb ACL a L3, VPN i molt més. Massa.
Problemes
Tothom viu amb ACL i VLAN. Que passa? Aquesta pregunta serà contestada per Harold, amagant el dolor.
Hi havia molts problemes, però n'hi havia cinc de massius.
- Augment de preu geomètric per a noves normes. Cada regla nova trigava més a afegir que l'anterior, perquè primer calia veure si ja existia aquesta regla.
- No hi ha tallafocs dins dels segments. Els segments estaven d'alguna manera separats els uns dels altres, i ja no hi havia prou recursos a dins.
- Les regles es van aplicar durant molt de temps. Els operadors podrien escriure una regla local a mà en una hora. El global va durar diversos dies.
- Dificultats amb les normes d'auditoria. Més precisament, no va ser possible. Les primeres regles es van escriure l'any 2010 i la majoria dels seus autors ja no treballaven per a l'empresa.
- Baix nivell de control de la infraestructura. Aquest és el principal problema: no sabíem molt bé què estava passant al nostre país.
Així es veia un enginyer de xarxa el 2018 quan va sentir: "Necessito més ACL".
Solucions
A principis del 2018 es va decidir fer alguna cosa al respecte.
El preu de les integracions està en constant creixement. El punt de partida va ser que els grans centres de dades van deixar de donar suport a VLAN i ACL aïllades perquè els dispositius es van quedar sense memòria.
Solució: vam eliminar el factor humà i vam automatitzar al màxim la prestació de l'accés.
Les noves normes triguen molt a aplicar-se. Solució: accelerar l'aplicació de regles, fer-la distribuïda i paral·lela. Això requereix un sistema distribuït perquè les regles es lliuren elles mateixes, sense rsync ni SFTP a mil sistemes.
No hi ha tallafocs dins dels segments. Un tallafocs dins dels segments va començar a arribar a nosaltres quan van aparèixer diferents serveis dins de la mateixa xarxa. Solució: utilitzeu un tallafocs a nivell d'amfitrió: tallafocs basats en l'amfitrió. Gairebé a tot arreu tenim Linux, i a tot arreu tenim iptables, això no és un problema.
Dificultats amb les normes d'auditoria. Solució: mantingueu totes les regles en un sol lloc per a la seva revisió i gestió, de manera que puguem auditar-ho tot.
Baix nivell de control de la infraestructura. Solució: fer un inventari de tots els serveis i accessos entre ells.
Aquest és més un procés administratiu que tècnic. De vegades tenim entre 200 i 300 nous llançaments a la setmana, especialment durant les promocions i les vacances. A més, això només és per a un equip dels nostres DevOps. Amb tantes versions, és impossible veure quins ports, IPs i integracions es necessiten. Per tant, necessitàvem gestors de serveis especialment formats que preguntessin als equips: "Què hi ha de totes maneres i per què ho vau plantejar?"
Després de tot el que vam llançar, un enginyer de xarxa el 2019 va començar a semblar així.
Cònsol
Vam decidir que posaríem tot el que trobàvem amb l'ajuda dels responsables del servei a Cònsol i a partir d'aquí escriurem les regles d'iptables.
Com vam decidir fer això?
- Recollirem tots els serveis, xarxes i usuaris.
- Creem regles d'iptables basades en elles.
- Automatitzem el control.
- ....
- BENEFICIS.
Consul no és una API remota, es pot executar a tots els nodes i escriure a iptables. Només queda crear controls automàtics que netejaran les coses innecessàries i la majoria dels problemes es solucionaran! La resta la anirem preparant a mesura que avancem.
Per què cònsol?
S'ha demostrat bé. El 2014-15, el vam utilitzar com a backend per a Vault, on emmagatzemem les contrasenyes.
No perd dades. Durant el temps d'ús, Cònsol no va perdre dades durant un sol accident. Aquest és un gran avantatge per a un sistema de gestió de tallafocs.
Les connexions P2P acceleren la propagació del canvi. Amb P2P, tots els canvis arriben ràpidament, no cal esperar hores.
API REST convenient. També hem considerat Apache ZooKeeper, però no té una API REST, així que hauràs d'instal·lar crosses.
Funciona tant com a Key Vault (KV) com com a directori (Service Discovery). Podeu emmagatzemar serveis, catàlegs i centres de dades alhora. Això és convenient no només per a nosaltres, sinó també per als equips veïns, perquè a l'hora de construir un servei global, pensem en gran.
Escrit a Go, que forma part de la pila de Wargaming. Ens encanta aquest llenguatge, tenim molts desenvolupadors de Go.
Potent sistema ACL. A Consul, podeu utilitzar les ACL per controlar qui escriu què. Garantim que les regles del tallafoc no es superposaran amb res més i no tindrem problemes amb això.
Però Cònsol també té els seus inconvenients.
- No escala dins d'un centre de dades tret que tingueu una versió empresarial. Només és escalable per federació.
- Molt depenent de la qualitat de la xarxa i de la càrrega del servidor. Consul no funcionarà correctament com a servidor en un servidor ocupat si hi ha retards a la xarxa, per exemple, velocitat desigual. Això es deu a les connexions P2P i als models de distribució actualitzats.
- Dificultat per controlar la disponibilitat. En condició de cònsol pot dir que tot està bé, però va morir fa molt de temps.
Hem resolt la majoria d'aquests problemes mentre utilitzem Consul, per això l'hem escollit. L'empresa té plans per a un backend alternatiu, però hem après a fer front als problemes i actualment vivim amb Consul.
Com funciona Cònsol
Instal·larem de tres a cinc servidors en un centre de dades condicional. Un o dos servidors no funcionaran: no podran organitzar un quòrum i decidir qui té raó i qui s'equivoca quan les dades no coincideixen. Més de cinc no té sentit, la productivitat baixarà.
Els clients es connecten als servidors en qualsevol ordre: els mateixos agents, només amb la bandera server = false.
Després d'això, els clients reben una llista de connexions P2P i construeixen connexions entre ells.
A nivell global, connectem diversos centres de dades. També connecten P2P i es comuniquen.
Quan volem recuperar dades d'un altre centre de dades, la sol·licitud va de servidor en servidor. Aquest esquema s'anomena Protocol de serf. El protocol Serf, com Consul, està desenvolupat per HashiCorp.
Alguns fets importants sobre el cònsol
Cònsol té documentació que descriu com funciona. Només donaré fets seleccionats que val la pena conèixer.
Els servidors cònsols seleccionen un mestre d'entre els votants. Consul selecciona un mestre de la llista de servidors per a cada centre de dades i totes les sol·licituds només s'hi dirigeixen, independentment del nombre de servidors. La congelació del mestre no comporta la reelecció. Si el mestre no està seleccionat, ningú no atendrà les sol·licituds.
Voleu una escala horitzontal? Ho sento, no.
Una sol·licitud a un altre centre de dades passa de mestre a mestre, independentment del servidor al qual va arribar. El mestre seleccionat rep el 100% de la càrrega, excepte la càrrega de les sol·licituds d'enviament. Tots els servidors del centre de dades tenen una còpia actualitzada de les dades, però només un respon.
L'única manera d'escalar és activar el mode obsolet al client.
En mode obsolet, podeu respondre sense quòrum. Aquest és un mode en què renunciem a la coherència de les dades, però llegim una mica més ràpid del que és habitual i qualsevol servidor respon. Naturalment, enregistrant només a través del mestre.
Consul no copia dades entre centres de dades. Quan es constitueix una federació, cada servidor només tindrà les seves pròpies dades. Per als altres, sempre recorre a algú altre.
L'atomicitat de les operacions no està garantida fora d'una transacció. Recorda que no ets l'únic que pot canviar les coses. Si ho voleu diferent, feu una transacció amb un bloqueig.
Les operacions de bloqueig no garanteixen el bloqueig. La sol·licitud va de mestre a mestre, i no directament, de manera que no hi ha cap garantia que el bloqueig funcioni quan bloquegeu, per exemple, en un altre centre de dades.
ACL tampoc garanteix l'accés (en molts casos). És possible que l'ACL no funcioni perquè s'emmagatzema en un centre de dades de federació: al centre de dades ACL (DC principal). Si el DC no us respon, l'ACL no funcionarà.
Un mestre congelat farà que tota la federació es congeli. Per exemple, hi ha 10 centres de dades en una federació, un té una xarxa dolenta i un mestre falla. Tothom que es comuniqui amb ell quedarà atrapat en un cercle: hi ha una petició, no hi ha resposta, el fil es congela. No hi ha manera de saber quan passarà això, només en una hora o dues caurà tota la federació. No hi pots fer res.
L'estat, el quòrum i les eleccions es gestionen mitjançant un fil separat. La reelecció no es produirà, l'estat no mostrarà res. Penses que tens un cònsol viu, preguntes, i no passa res, no hi ha resposta. Al mateix temps, l'estat mostra que tot està bé.
Hem trobat aquest problema i hem hagut de reconstruir parts específiques dels centres de dades per evitar-ho.
La versió empresarial de Consul Enterprise no té alguns dels inconvenients anteriors. Té moltes funcions útils: selecció de votants, distribució, escala. Només hi ha un "però": el sistema de llicències per a un sistema distribuït és molt car.
Pirateria de la vida: rm -rf /var/lib/consul - una cura per a totes les malalties de l'agent. Si alguna cosa no us funciona, suprimiu les vostres dades i descarregueu-les d'una còpia. El més probable és que el cònsol funcioni.
BEFW
Ara parlem del que hem afegit a Cònsol.
és un acrònim de BACKEndFirWtots. Vaig haver de nomenar el producte d'alguna manera quan vaig crear el dipòsit per posar-hi les primeres confirmacions de prova. Aquest nom es manté.
Plantilles de regles
Les regles estan escrites en la sintaxi d'iptables.
- -N BEFW
- -P CAÍDA D'ENTRADA
- -A INPUT -m estat—estat RELACIONAT,ESTABLECITAT -j ACEPTAR
- -A ENTRADA -i lo -j ACEPTAR
- -A ENTRADA -j BEFW
Tot entra a la cadena BEFW, excepte ESTABLISHED, RELATED i localhost. La plantilla pot ser qualsevol cosa, això és només un exemple.
Com és útil BEFW?
Serveis
Tenim un servei, sempre té un port, un node on s'executa. Des del nostre node, podem preguntar localment a l'agent i esbrinar que tenim algun tipus de servei. També podeu posar etiquetes.
Qualsevol servei que s'està executant i registrat amb Consul es converteix en una regla iptables. Tenim SSH - port obert 22. L'script Bash és senzill: curl i iptables, no cal res més.
Clients
Com obrir l'accés no a tothom, sinó de manera selectiva? Afegiu llistes d'IP a l'emmagatzematge KV pel nom del servei.
Per exemple, volem que tothom de la desena xarxa pugui accedir al servei SSH_TCP_22. Afegiu un camp TTL petit? i ara tenim permisos temporals, per exemple, per un dia.
Accessos
Connectem serveis i clients: tenim un servei, l'emmagatzematge KV està preparat per a cadascun. Ara donem accés no a tothom, sinó de manera selectiva.
Grups
Si escrivim milers d'IPs per accedir-hi cada vegada, ens cansarem. Anem a crear agrupacions: un subconjunt separat en KV. Diguem-ne Àlies (o grups) i emmagatzemem-hi grups segons el mateix principi.
Connectem-nos: ara podem obrir SSH no específicament per a P2P, sinó per a tot un grup o diversos grups. De la mateixa manera, hi ha TTL: podeu afegir-lo a un grup i eliminar-lo temporalment.
Integració
El nostre problema és el factor humà i l'automatització. Fins ara ho hem resolt d'aquesta manera.
Treballem amb Puppet, i els transferim tot el que té relació amb el sistema (codi de l'aplicació). Puppetdb (PostgreSQL normal) emmagatzema una llista de serveis que s'hi estan executant, es poden trobar per tipus de recurs. Allà podeu esbrinar qui sol·licita on. També tenim un sistema de sol·licitud d'extracció i sol·licitud de combinació per a això.
Hem escrit befw-sync, una solució senzilla que ajuda a transferir dades. En primer lloc, puppetdb accedeix a les galetes de sincronització. Allà es configura una API HTTP: demanem quins serveis tenim, què cal fer. Després fan una petició al cònsol.
Hi ha integració? Sí: van escriure les regles i van permetre que s'acceptissin les sol·licituds d'extracció. Necessites un port determinat o afegir un amfitrió a algun grup? Sol·licitud d'extracció, revisa - no més "Troba 200 ACL més i intenta fer-hi alguna cosa".
Optimització
Fer ping localhost amb una cadena de regles buida triga 0,075 ms.
Afegim 10 adreces iptables a aquesta cadena. Com a resultat, el ping augmentarà 000 vegades: iptables és completament lineal, processar cada adreça triga un temps.
Per a un tallafocs on migrem milers d'ACL, tenim moltes regles, i això introdueix latència. Això és dolent per als protocols de joc.
Però si posem 10 adreces en ipset El ping fins i tot disminuirà.
La qüestió és que "O" (complexitat de l'algoritme) per a ipset és sempre igual a 1, no importa quantes regles hi hagi. És cert que hi ha una limitació: no hi pot haver més de 65535 regles. De moment vivim amb això: podeu combinar-les, ampliar-les, fer dos ipsets en un.
emmagatzematge
Una continuació lògica del procés d'iteració és emmagatzemar informació sobre clients per al servei a ipset.
Ara tenim el mateix SSH, i no escrivim 100 IP alhora, sinó que establim el nom de l'ipset amb el qual ens hem de comunicar i la següent regla DROP. Es pot convertir en una regla "Qui no és aquí, DROP", però és més clar.
Ara tenim regles i conjunts. La tasca principal és fer un conjunt abans d'escriure la regla, perquè si no, iptables no escriurà la regla.
Esquema general
En forma de diagrama, tot el que he dit es veu així.
Ens comprometem amb Puppet, tot s'envia a l'amfitrió, els serveis aquí, ipset allà, i qualsevol persona que no estigui registrat allà no està permès.
Permetre denegar
Per salvar el món ràpidament o desactivar ràpidament algú, al principi de totes les cadenes vam fer dos ipsets: rules_allow и rules_deny. Com funciona?
Per exemple, algú està creant una càrrega a la nostra web amb robots. Abans, havíeu de trobar la seva IP als registres, portar-la als enginyers de xarxa, perquè poguessin trobar la font del trànsit i prohibir-lo. Ara es veu diferent.
L'enviem al cònsol, esperem 2,5 segons i ja està. Com que Consul distribueix ràpidament a través de P2P, funciona a tot arreu, a qualsevol part del món.
Una vegada vaig aturar completament WOT a causa d'un error amb el tallafoc. rules_allow - aquesta és la nostra assegurança contra aquests casos. Si ens hem equivocat en algun lloc amb el tallafoc, alguna cosa està bloquejada en algun lloc, sempre podem enviar un condicional 0.0/0per recollir-ho tot ràpidament. Més endavant ho arreglarem tot a mà.
Altres conjunts
Podeu afegir qualsevol altre conjunt a l'espai $IPSETS$.
Per a què? De vegades algú necessita ipset, per exemple, per emular l'aturada d'alguna part del clúster. Qualsevol pot portar qualsevol conjunt, posar-los un nom, i els recolliran al Cònsol. Al mateix temps, els conjunts poden participar en les regles d'iptables o actuar com a equip NOOP: el dimoni mantindrà la coherència.
Membres
Abans, era així: l'usuari es connectava a la xarxa i rebia paràmetres a través del domini. Abans de l'arribada dels tallafocs de nova generació, Cisco no sabia com entendre on era l'usuari i on era la IP. Per tant, només es va concedir l'accés a través del nom d'amfitrió de la màquina.
Què hem fet? Ens vam quedar atrapats en el moment en què vam rebre l'adreça. Normalment això és dot1x, Wi-Fi o VPN: tot passa per RADIUS. Per a cada usuari, creem un grup per nom d'usuari i hi col·loquem una IP amb un TTL que és igual al seu dhcp.lease: tan bon punt expiri, la regla desapareixerà.
Ara podem obrir l'accés als serveis, com altres grups, per nom d'usuari. Hem eliminat el dolor dels noms d'amfitrió quan canvien i hem eliminat la càrrega dels enginyers de xarxa perquè ja no necessiten Cisco. Ara els mateixos enginyers registren l'accés als seus servidors.
Aïllament
Al mateix temps, vam començar a desmuntar l'aïllament. Els gestors del servei van fer un inventari i vam analitzar totes les nostres xarxes. Dividim-los en els mateixos grups, i als servidors necessaris es van afegir els grups, per exemple, per negar. Ara el mateix aïllament de la posada en escena acaba en les regles_denegació de la producció, però no en la producció en si.
L'esquema funciona de manera ràpida i senzilla: eliminem totes les ACL dels servidors, descarreguem el maquinari i reduïm el nombre de VLAN aïllades.
Control d'integritat
Anteriorment, teníem un activador especial que informava quan algú canviava una regla del tallafoc manualment. Estava escrivint un gran linter per comprovar les regles del tallafoc, era difícil. La integritat ara està controlada per BEFW. S'assegura amb zel que les regles que fa no canvien. Si algú canvia les regles del tallafoc, ho canviarà tot. "Vaig configurar ràpidament un servidor intermediari per poder treballar des de casa": no hi ha més opcions.
BEFW controla l'ipset des dels serveis i llista a befw.conf, les regles de serveis de la cadena BEFW. Però no supervisa altres cadenes i regles i altres ipsets.
Protecció contra xoc
BEFW sempre emmagatzema l'últim estat bo conegut directament a l'estructura binària state.bin. Si alguna cosa va malament, sempre es torna a aquest state.bin.
Es tracta d'una assegurança contra l'operació inestable del Cònsol, quan no ha enviat dades o algú s'ha equivocat i ha utilitzat normes que no es poden aplicar. Per assegurar-nos que no ens quedem sense un tallafoc, BEFW tornarà a l'estat més recent si es produeix un error en qualsevol moment.
En situacions crítiques, això és una garantia que ens quedarem amb un tallafocs que funcioni. Obrim totes les xarxes grises amb l'esperança que vingui l'administrador i ho solucioni. Algun dia ho posaré a les configuracions, però ara només tenim tres xarxes grises: 10/8, 172/12 i 192.168/16. Dins del nostre cònsol, aquesta és una característica important que ens ajuda a seguir desenvolupant-nos.
Demostració: durant el reportatge, l'Ivan mostra el mode de demostració de BEFW. És més fàcil veure la demostració . Codi font de demostració disponible .
Trampes
Us explicaré els errors que hem trobat.
ipset add set 0.0.0.0/0. Què passa si afegiu 0.0.0.0/0 a ipset? S'afegiran totes les IP? Hi haurà accés a Internet?
No, rebrem un error que ens ha costat dues hores d'inactivitat. A més, l'error no funciona des de l'any 2016, es troba a RedHat Bugzilla amb el número #1297092 i l'hem trobat per accident, a partir d'un informe del desenvolupador.
Ara és una norma estricta a BEFW això 0.0.0.0/0 es converteix en dues adreces: 0.0.0.0/1 и 128.0.0.0/1.
ipset restore set < fitxer. Què fa ipset quan li dius? restore? Creus que funciona igual que iptables? Recuperarà dades?
Res d'això: fa una fusió i les adreces antigues no van enlloc, no bloquegeu l'accés.
Hem trobat un error en provar l'aïllament. Ara hi ha un sistema força complex, en lloc de restore retingut create tempaleshores restore flush temp и restore temp. Al final de l'intercanvi: per atomicitat, perquè si ho fas primer flush i en aquest moment arriba algun paquet, es descartarà i alguna cosa sortirà malament. Així que hi ha una mica de màgia negra.
consul kv get -datacenter=altre. Com he dit, creiem que demanem algunes dades, però obtindrem dades o un error. Ho podem fer a través de Consul localment, però en aquest cas tots dos es congelaran.
El client Consul local és un embolcall de l'API HTTP. Però només es penja i no respon a Ctrl+C, o Ctrl+Z, ni res, només kill -9 a la següent consola. Ens vam trobar amb això quan estàvem construint un gran clúster. Però encara no tenim solució; estem preparant-nos per solucionar aquest error a Cònsol.
El líder del cònsol no respon. El nostre mestre al centre de dades no respon, pensem: "Potser l'algoritme de reselecció funcionarà ara?"
No, no funcionarà, i el seguiment no mostrarà res: el cònsol dirà que hi ha un índex de compromís, s'ha trobat un líder, tot està bé.
Com tractem això? service consul restart en cron cada hora. Si teniu 50 servidors, no és gran cosa. Quan n'hi hagi 16, entendràs com funciona.
Conclusió
Com a resultat, vam rebre els següents avantatges:
- Cobertura del 100% de totes les màquines Linux.
- Velocitat
- Automatització.
- Vam alliberar els enginyers de maquinari i xarxes de l'esclavitud.
- Han aparegut possibilitats d'integració gairebé il·limitades: fins i tot amb Kubernetes, fins i tot amb Ansible, fins i tot amb Python.
Contres: Cònsol, amb el qual ara hem de conviure, i el cost altíssim de l'error. Com a exemple, una vegada a les 6 de la tarda (prime time a Rússia) estava editant alguna cosa a les llistes de xarxes. En aquell moment només estàvem construint aïllament a BEFW. Em vaig equivocar en algun lloc, sembla que vaig indicar la màscara equivocada, però tot va caure en dos segons. El seguiment s'il·lumina, la persona de suport de torn ve corrent: "Ho tenim tot!" El cap del departament es va posar gris quan va explicar a l'empresa per què va passar això.
El cost de l'error és tan alt que hem creat el nostre propi procediment de prevenció complex. Si implementeu això en un lloc de producció gran, no cal que doneu un testimoni mestre sobre Cònsol a tothom. Això acabarà malament.
Cost Vaig escriure codi només durant 400 hores. El meu equip de 4 persones dediquen 10 hores al mes a donar suport a tothom. En comparació amb el preu de qualsevol tallafocs de nova generació, és gratuït.
Plans. El pla a llarg termini és trobar un transport alternatiu per substituir o complementar al Cònsol. Potser serà Kafka o alguna cosa semblant. Però en els propers anys viurem de Cònsol.
Plans immediats: integració amb Fail2ban, amb monitorització, amb nftables, possiblement amb altres distribucions, mètriques, monitorització avançada, optimització. El suport de Kubernetes també està en algun lloc dels plans, perquè ara tenim diversos clústers i el desig.
Més dels plans:
- recerca d'anomalies en el trànsit;
- gestió de mapes de xarxa;
- suport Kubernetes;
- muntar paquets per a tots els sistemes;
- Interfície d'usuari web.
Estem treballant constantment per ampliar la configuració, augmentar les mètriques i l'optimització.
Uneix-te al projecte. El projecte va resultar genial, però, malauradament, segueix sent un projecte unipersonal. Vine a i intenta fer alguna cosa: comprometre't, provar, suggerir alguna cosa, donar la teva valoració.
Mentrestant ens estem preparant , que tindrà lloc els dies 6 i 7 d'abril a Sant Petersburg, i convidem els desenvolupadors de sistemes d'alta càrrega . Els parlants amb experiència ja saben què fer, però per als que no parlen, recomanem almenys . Participar a la conferència com a ponent té diversos avantatges. Podeu llegir quins, per exemple, al final .
Font: www.habr.com