📖 🔪 🤴 Consul + iptables =: 3 ⛰️ ♋️ 🙌🏾

En 2010, Wargaming avait 50 serveurs et un modèle de réseau simple: backend, frontend et firewall. Le nombre de serveurs a augmenté, le modèle est devenu plus compliqué: staging, VLAN isolés avec ACL, puis VPN avec VRF, VLAN avec ACL vers L2, VRF depuis ACL vers L3. La tête tourne? Plus sera plus amusant.

Lorsque les serveurs ont commencé à fonctionner 16 000 sans larmes avec autant de segments hétérogènes, cela est devenu impossible. Par conséquent, ils ont trouvé une solution différente. Nous avons pris la pile Netfilter, y avons ajouté Consul comme source de données et nous avons obtenu un pare-feu distribué rapidement. Ils ont remplacé l'ACL sur les routeurs et utilisé comme pare-feu externe et interne. Pour la gestion dynamique des outils, nous avons développé le système BEFW, utilisé partout: du contrôle de l'accès des utilisateurs au réseau d'épicerie à l'isolement des segments du réseau les uns des autres.

Comment tout cela fonctionne et pourquoi vous devriez examiner de plus près ce système, explique Ivan Agarkov (Annmuor) - le chef du groupe de sécurité des infrastructures de l'unité de maintenance du centre de développement de l'entreprise de Minsk. Ivan est un fan de SELinux, aime Perl, écrit du code. En tant que chef du groupe IB, il travaille régulièrement avec les journaux, les sauvegardes et la R&D pour protéger Wargaming contre les pirates et assurer le fonctionnement de tous les serveurs de jeux de l'entreprise.

Référence historique

Avant de dire comment nous l'avons fait, je vais vous dire comment nous en sommes arrivés là et pourquoi c'était nécessaire. Pour ce faire, nous avons transféré il y a 9 ans: 2010, seul le World of Tanks est apparu. Wargaming avait environ 50 serveurs.

Graphique de croissance des serveurs de l'entreprise.

Nous avions un modèle de réseau. Pour l'époque, c'était optimal.

Le modèle de réseau en 2010.

À l'avant, il y a des méchants qui veulent nous briser, mais il y a un pare-feu. Il n'y a pas de pare-feu sur le backend, mais il y a 50 serveurs là-bas, nous les connaissons tous. Tout fonctionne bien.

Pendant 4 ans, le parc de serveurs a augmenté 100 fois, jusqu'à 5000. Les premiers réseaux isolés sont apparus - des étapes: ils ne peuvent pas entrer en production, et souvent des choses qui pouvaient être dangereuses y tournaient.

Modèle de réseau en 2014.

Par inertie, tous les mêmes morceaux de fer ont été utilisés et tout le travail a été effectué sur des VLAN isolés: les ACL sont écrites sur le VLAN qui autorisent ou interdisent toute connexion.

En 2016, le nombre de serveurs a atteint 8000. Wargaming a absorbé d'autres studios, d'autres réseaux d'affiliation sont apparus. Ils semblent être les nôtres, mais pas tout à fait: les VLAN ne fonctionnent souvent pas pour les partenaires, vous devez utiliser un VPN avec VRF, l'isolement devient plus compliqué. Un mélange d'isolats d'ACL s'est développé.

Le modèle de réseau en 2016.

Au début de 2018, le parc de voitures était passé à 16 000. Il y avait 6 segments, et le reste nous ne comptions pas, y compris ceux fermés, dans lesquels les données financières étaient stockées. Il existe des réseaux de conteneurs (Kubernetes), DevOps, des réseaux cloud connectés via VPN, par exemple, à partir de l'IVS. Il y avait beaucoup de règles - ça faisait mal.

Modèle de réseau et méthodes d'isolement en 2018.

Pour l'isolement, nous avons utilisé: VLAN avec ACL sur L2, VRF avec ACL sur L3, VPN et bien plus encore. Trop.

Problèmes

Tout le monde vit avec des ACL et des VLAN. Qu'est-ce qui ne va généralement pas? Harold, cachant la douleur, répondra à cette question.

Il y avait beaucoup de problèmes, mais il y en avait cinq énormes.

Augmentation géométrique des prix pour les nouvelles règles . Chaque nouvelle règle a été ajoutée plus longtemps que la précédente, car il fallait d'abord voir s'il existait déjà une telle règle.
Il n'y a pas de pare-feu à l'intérieur des segments . Les segments étaient en quelque sorte séparés les uns des autres, à l'intérieur il n'y a déjà pas assez de ressources.
Les règles sont appliquées depuis longtemps. Les opérateurs de règles locaux peuvent écrire en une heure. Global a pris plusieurs jours.
Difficultés avec l'audit des règles . Plus précisément, ce n'était pas possible. Les premières règles ont été écrites en 2010, et la plupart de leurs auteurs ne travaillaient plus pour l'entreprise.
Faible niveau de contrôle sur l'infrastructure . C'est le principal problème - nous ne savions pas bien ce qui se passait avec nous.

Voici à quoi ressemblait l'ingénieur réseau en 2018 lorsqu'il a entendu: «Nous avons besoin de plus de listes de contrôle d'accès».

Solutions

Début 2018, il a été décidé de faire quelque chose.

Le prix de l'intégration est en constante augmentation. Le point de départ était que les grands centres de données ne prenaient plus en charge les VLAN et ACL isolés, car la mémoire des appareils était épuisée.

Solution: supprimer le facteur humain et automatiser la fourniture d'accès au maximum.

De nouvelles règles s'appliquent depuis longtemps. Solution: accélérer l'application des règles, les rendre réparties et parallèles. Pour ce faire, vous avez besoin d'un système distribué afin que les règles soient livrées seules, sans rsync ou SFTP pour mille systèmes.

L'absence de pare-feu à l'intérieur des segments.Le pare-feu à l'intérieur des segments a commencé à voler vers nous lorsque différents services sont apparus au sein du même réseau. Solution: utilisez un pare-feu basé sur l'hôte. Presque partout où nous avons Linux, et iptables sont partout, ce n'est pas un problème.

Difficultés avec l'audit des règles. Solution: conservez toutes les règles en un seul endroit pour examen et gestion, afin que nous puissions tout auditer.

Faible niveau de contrôle sur l'infrastructure. Solution: faites l'inventaire de tous les services et accès entre eux.

Il s'agit plus d'un processus administratif que technique. Parfois, nous avons 200 à 300 nouvelles versions par semaine, en particulier pendant les promotions et les jours fériés. Cependant, cela ne concerne qu'une seule équipe de nos DevOps. Avec autant de versions, il est impossible de voir quel type de ports, IP et intégration sont nécessaires. Par conséquent, nous avions besoin de responsables de service spécialement formés qui ont interviewé les équipes: «Qu'y a-t-il et pourquoi l'avez-vous soulevé?»

Après tout ce que nous avons lancé, l'ingénieur réseau en 2019 a commencé à ressembler à ceci.

Consul

Nous avons décidé de mettre tout ce que nous avons trouvé avec l'aide des gestionnaires de services dans Consul et à partir de là, nous écririons des règles iptables.

Comment avons-nous décidé de faire cela?

Nous collectons tous les services, réseaux et utilisateurs.
Faisons des règles iptables basées sur eux.
Automatisez le contrôle.
...
PROFIT.

Consul n'est pas une API distante; il peut fonctionner sur tous les nœuds et écrire sur iptables. Il ne reste plus qu'à trouver des commandes automatiques qui nettoieront l'excédent, et la plupart des problèmes seront résolus! Nous finaliserons le reste dans le processus.

Pourquoi consul?

Bien établi. En 2014-15, nous l'avons utilisé comme backend pour Vault, dans lequel nous stockons les mots de passe.

Ne perd pas de données . Pendant l'utilisation, Consul n'a pas perdu de données dans aucun accident. C'est un énorme avantage pour le système de gestion de pare-feu.

Les communications P2P accélèrent la propagation du changement . Avec le P2P, tous les changements arrivent rapidement, pas besoin d'attendre des heures.

API REST pratique. Nous avons également considéré Apache ZooKeeper, mais il ne dispose pas d'une API REST, vous devrez mettre des béquilles.

Il fonctionne comme un magasin de clés (KV) et comme un répertoire (Service Discovery) . Vous pouvez immédiatement stocker des services, des catalogues, des centres de données. C'est pratique non seulement pour nous, mais aussi pour les équipes voisines, car lorsque nous construisons un service mondial, nous pensons grand.

Écrit en Go, qui fait partie de la pile Wargaming. Nous aimons ce langage, nous avons de nombreux développeurs Go.

Système ACL puissant. Dans Consul, vous pouvez utiliser les listes de contrôle d'accès pour gérer qui et quoi écrire. Nous garantissons que les règles du pare-feu ne chevaucheront rien d'autre et nous n'aurons aucun problème avec cela.

Mais le consul a ses inconvénients.

Il n'est pas évolutif dans le centre de données, si vous ne disposez pas d'une version commerciale. Il est mis à l'échelle uniquement par la fédération.
Très dépendant de la qualité du réseau et de la charge du serveur. Consul ne fonctionnera pas normalement comme serveur sur un serveur occupé s'il y a des retards dans le réseau, par exemple, une vitesse inégale. Cela est dû aux connexions P2P et aux modèles de distribution de mise à jour.
Difficultés avec la surveillance de l'accessibilité . Dans le statut de consul peut dire que tout va bien, mais il est mort depuis longtemps.

Nous avons résolu la plupart de ces problèmes pendant le fonctionnement du Consul, nous l'avons donc choisi. La société a des plans pour un backend alternatif, mais nous avons appris à gérer les problèmes et vivons toujours avec Consul.

Fonctionnement du consul

Dans le centre de données conditionnel, nous installons des serveurs - de trois à cinq. Un ou deux serveurs ne fonctionneront pas: ils ne pourront pas organiser un quorum et décider qui a raison, qui a tort, lorsque les données ne correspondent pas. Plus de cinq n'a aucun sens, les performances chuteront.

Les clients se connectent dans n'importe quel ordre aux serveurs: les mêmes agents, uniquement avec un drapeau server = false.

Après cela, les clients reçoivent une liste de connexions P2P et établissent des connexions entre eux.

Au niveau mondial, nous interconnectons plusieurs centres de données. Ils connectent également le P2P et communiquent.

Lorsque nous voulons collecter des données dans un autre centre de données, la demande va de serveur en serveur. Un tel schéma est appelé protocole Serf . Le protocole Serf, comme Consul, est développé par HashiCorp.

Quelques faits importants sur le consul

Le consul possède une documentation décrivant son travail. Je ne donnerai que des faits sélectionnés qui valent la peine d'être connus.

Les serveurs du consul sélectionnent les maîtres parmi les électeurs . Consul sélectionne l'assistant dans la liste des serveurs de chaque centre de données et toutes les demandes ne lui sont adressées, quel que soit le nombre de serveurs. Suspendre l'assistant ne conduit pas à une réélection. Si l'assistant n'est pas sélectionné, les demandes ne sont traitées par personne.

Voulez-vous une mise à l'échelle horizontale? Désolé, mais non.

Une demande adressée à un autre centre de données passe de maître à maître, quel que soit le serveur auquel elle est adressée. Le maître sélectionné reçoit 100% de la charge, à l'exception de la charge sur les demandes de transfert. Tous les serveurs du centre de données ont une copie à jour des données, mais une seule réponse.

La seule façon de mettre à l'échelle est d'activer le mode périmé sur le client.

En mode périmé, vous pouvez répondre sans quorum. Il s'agit d'un mode dans lequel nous refusons la cohérence des données, mais nous lisons un peu plus vite que d'habitude et n'importe quel serveur répond. Naturellement, l'enregistrement se fait uniquement via le master.

Consul ne copie pas les données entre les centres de données . Lors de la collecte de fédération, chaque serveur n'aura que ses propres données. Pour les autres, il se tourne toujours vers quelqu'un d'autre.

L'atomicité des opérations n'est pas garantie en dehors de la transaction . N'oubliez pas que non seulement vous pouvez changer quelque chose. Si vous le souhaitez différemment, effectuez une transaction avec un verrou.

Les opérations de blocage ne garantissent pas le blocage . La demande va de maître à maître, et non directement, il n'y a donc aucune garantie que le verrou fonctionne lorsque vous verrouillez, par exemple, dans un autre centre de données.

Les ACL ne garantissent pas non plus l'accès (dans de nombreux cas) . L'ACL peut ne pas fonctionner car elle est stockée dans un centre de données de la fédération - dans le centre de données ACL (DC principal). Si le contrôleur de domaine ne vous répond pas, l'ACL ne fonctionnera pas.

Un assistant en vol stationnaire gèle toute la fédération . Par exemple, dans la fédération, il y a 10 centres de données, et dans l'un il y a un mauvais réseau et un maître tombe. Tous ceux qui communiquent avec lui sont coincés dans un cercle: une demande est faite, il n'y a pas de réponse, le fil se bloque. Il ne sera pas possible de savoir quand cela se produira, dans une heure ou deux, toute la fédération tombera. Vous ne pouvez rien y faire.

Le statut, le quorum et les élections sont traités dans un fil distinct. La resélection ne se produira pas, le statut ne montrera rien. Vous pensez avoir un consul vivant, demandez-vous, et rien ne se passe - il n'y a pas de réponse. De plus, le statut montre que tout va bien.

Nous avons été confrontés à ce problème, nous avons dû reconstruire des parties spécifiques des centres de données afin de l'éviter.

La version commerciale de Consul Enterprise ne présente pas certains des inconvénients ci-dessus . Il a de nombreuses fonctions utiles: vote, distribution, mise à l'échelle. Il n'y a qu'un «mais» - un système de licence pour un système distribué coûte très cher.

Life hack: rm -rf /var/lib/consul- un remède contre toutes les maladies de l'agent. Si quelque chose ne fonctionne pas pour vous, supprimez simplement vos données et téléchargez-les à partir de la copie. Très probablement, Consul fonctionnera.

Befw

Parlons maintenant de ce que nous avons ajouté au Consul.

BEFW - un acronyme pour Bed and ack E nd the F the ire of the W all. Il était nécessaire de nommer le produit d'une manière ou d'une autre lorsque j'ai créé le référentiel afin d'y mettre les premières validations de test. Ce nom reste.

Modèles de règles

Les règles sont écrites dans la syntaxe iptables.

-N BEFW
-P BAISSE D'ENTRÉE
-A INPUT -m état - état RELATED, ESTABLISHED -j ACCEPT
-A ENTRÉE -i lo -j ACCEPTER
-A ENTRÉE -j BEFW

Nous allons tous à la chaîne BEFW, sauf ESTABLISHED, RELATEDet à l'hôte local. Le modèle peut être n'importe quoi, ce n'est qu'un exemple.

À quoi sert BEFW?

Prestations de service

Nous avons un service, il a toujours un port, le nœud sur lequel il fonctionne. Depuis notre nœud, nous pouvons demander localement à l'agent et savoir que nous avons une sorte de service. Vous pouvez également mettre des balises.

Tout service en cours d'exécution et enregistré auprès de Consul devient une règle iptables. Nous avons SSH - port ouvert 22. Le script bash est simple: curl et iptables, rien d'autre n'est nécessaire.

Les clients

Comment ouvrir l'accès non à tout le monde, mais de manière sélective? Par le nom du service, ajoutez des listes IP au référentiel KV.

Par exemple, nous voulons que tous les membres du dixième réseau puissent accéder au service SSH_TCP_22. Ajouter un petit champ TTL? et maintenant nous avons des autorisations temporaires, par exemple, pour une journée.

Accès

Nous connectons les services et les clients: nous avons un service, pour chaque stockage KV est prêt. Maintenant, nous donnons accès non pas à tout le monde, mais de manière sélective.

Groupes

Si chaque fois que nous écrivons des milliers d'adresses IP pour les accès, nous nous fatiguerons. Imaginons des regroupements - un sous-ensemble distinct en KV. Nous l'appellerons Alias (ou groupes) et nous y stockerons des groupes selon le même principe.

Connect: maintenant, nous pouvons ouvrir SSH non pas spécifiquement sur P2P, mais sur un groupe entier ou plusieurs groupes. De même, il existe TTL - vous pouvez ajouter au groupe et supprimer temporairement du groupe.

L'intégration

Notre problème est le facteur humain et l'automatisation. Jusqu'à présent, nous l'avons résolu comme ça.

Nous travaillons avec Puppet et y transférons tout ce qui concerne le système (code d'application). Puppetdb (PostgreSQL standard) stocke une liste de services qui y sont exécutés, vous pouvez les trouver par type de ressource. Vous pouvez y trouver qui va où. Nous avons également un système de demande d'extraction et de fusion pour cela.

Nous avons écrit befw-sync, la solution la plus simple qui facilite le transfert de données. Tout d'abord, les cookies de synchronisation vont à puppetdb. L'API HTTP y est configurée: nous demandons quels services nous avons, ce qui doit être fait. Ensuite, ils font une demande au consul.

Y a-t-il intégration? Oui: ils ont écrit les règles, autorisés à accepter la Pull Request. Besoin d'un port ou ajouter un hôte à un groupe? Pull Request, review - no more "Trouvez 200 autres ACL et essayez de faire quelque chose."

Optimisation

Le ping localhost avec une chaîne de règles vide prend 0,075 ms.

Ajoutez 10 000 iptables à cette chaîne. En conséquence, le ping augmentera de 5 fois: iptables est complètement linéaire, le traitement de chaque adresse prend un certain temps.

Pour le pare-feu, dans lequel nous migrons des milliers d'ACL, nous avons de nombreuses règles, ce qui introduit un retard. Pour les protocoles de jeu, c'est mauvais.

Mais si nous mettons 10 000 adresses en ipset, le ping diminuera même.

Le fait est que le «O» (complexité de l'algorithme) pour l'ipset est toujours 1, quel que soit le nombre de règles. Certes, il y a une limitation - il ne peut pas y avoir plus de 65535 règles. Pour l'instant, nous vivons avec ceci: vous pouvez les combiner, les développer, créer deux ipsets en un.

Espace de rangement

La suite logique du processus d'itération est le stockage des informations client pour le service dans l'ipset.

Nous avons maintenant le même SSH, et nous n'écrivons pas immédiatement 100 IP, mais nous définissons le nom de l'ipset avec lequel communiquer et la règle suivante DROP. Vous pouvez refaire la règle «Qui n'est pas ici, c'est DROP», mais plus clairement.

Maintenant, nous avons des règles et des ensembles. La tâche principale consiste à créer un ensemble avant d'écrire la règle, car sinon iptables n'écrira pas la règle.

Schéma général

Sous la forme d'un diagramme, tout ce que j'ai dit ressemble à ceci.

Engagez-vous à Puppet, tout est envoyé à l'hôte, les services sont ici, l'ipset est là, et celui qui n'est pas enregistré là-bas n'est pas autorisé.

Autoriser et refuser

Pour sauver rapidement le monde ou désactiver rapidement quelqu'un, au début de toutes les chaînes, nous avons créé deux ipsets: rules_allowet rules_deny. Comment ça fonctionne?

Par exemple, quelqu'un avec des robots crée une charge sur notre site Web. Auparavant, il était nécessaire de trouver son adresse IP dans les journaux, de la référer aux ingénieurs réseau afin qu'ils puissent trouver la source du trafic et l'interdire. Maintenant, ça a l'air différent.

Nous expédions au consul, attendez 2,5 s et vous avez terminé. Étant donné que Consul distribue rapidement via le P2P, il fonctionne partout, partout dans le monde.

Une fois que j'ai en quelque sorte complètement arrêté WOT, j'ai fait une erreur avec le pare-feu. rules_allow- Ceci est notre assurance contre de tels cas. Si nous avons fait une erreur avec le pare-feu quelque part, quelque chose est bloqué quelque part, nous pouvons toujours envoyer un conditionnel 0.0/0pour tout lever rapidement. Ensuite, nous allons tout réparer avec nos mains.

Autres ensembles

Vous pouvez ajouter d'autres ensembles dans l'espace $IPSETS$ .

Pourquoi? Parfois, quelqu'un a besoin d'un ipset, par exemple, pour émuler la déconnexion d'une partie du cluster. Tout le monde peut apporter des sets, les appeler et ils seront pris au Consul. En même temps, les ensembles peuvent à la fois participer aux règles iptables et être comme une équipe NOOP: la cohérence sera prise en charge par le démon.

Utilisateurs

Auparavant, c'était comme ça: un utilisateur connecté à un réseau et reçu des paramètres via un domaine. Jusqu'à la prochaine génération de pare-feu, Cisco n'était pas en mesure de comprendre où se trouve l'utilisateur et où se trouve l'IP. Par conséquent, l'accès a été accordé uniquement via des machines de nom d'hôte.

Qu'avons-nous fait? Coincé au moment de la réception de l'adresse. Il s'agit généralement de dot1x, Wi-Fi ou VPN - tout passe par RADIUS. Pour chaque utilisateur, créez un groupe par nom d'utilisateur et mettez-y une IP avec TTL, qui est égale à son dhcp.lease - dès son expiration, la règle disparaîtra.

Maintenant, nous pouvons ouvrir l'accès aux services, ainsi qu'à d'autres groupes, par nom d'utilisateur. Nous nous sommes débarrassés de la douleur du nom d'hôte lors de leur changement et avons supprimé la charge des ingénieurs réseau car ils n'avaient plus besoin de Cisco. Désormais, les ingénieurs eux-mêmes prescrivent l'accès à leurs serveurs.

Isolation

En parallèle, nous avons commencé à démonter l'isolation. Les responsables de service ont fait un inventaire et nous avons analysé tous nos réseaux. Nous les décomposons dans les mêmes groupes, et sur les serveurs nécessaires les groupes ont été ajoutés, par exemple, à refuser. Désormais, le même isolement intermédiaire entre dans les règles de la production, mais pas dans la production elle-même.

Le schéma fonctionne rapidement et simplement: supprimez toutes les ACL des serveurs, déchargez le matériel, réduisez le nombre de VLAN isolés.

Contrôle d'intégrité

Auparavant, un déclencheur spécial fonctionnait pour nous, qui nous informait lorsque quelqu'un changeait la règle de pare-feu avec ses mains. J'ai écrit un énorme vérificateur de règles de pare-feu, c'était difficile. Désormais, l'intégrité contrôle BEFW. Il s'assure avec zèle que les règles qu'il établit ne changent pas. Si quelqu'un change les règles du pare-feu, il retournera tout. «J'ai rapidement levé une procuration ici pour travailler à domicile» - il n'y a plus de telles options.

BEFW contrôle l'ipset à partir des services et de la liste dans befw.conf, les règles de service dans la chaîne BEFW. Mais ne suit pas d'autres chaînes et règles et autres ipsets.

Protection contre les accidents

BEFW enregistre toujours le dernier état réussi directement dans la structure binaire de state.bin. En cas de problème, il revient toujours à cet état.bin.

Il s'agit de l'assurance instable du Consul lorsqu'il n'a pas envoyé de données ou que quelqu'un a fait une erreur et a utilisé des règles qui n'ont pas pu être appliquées. Pour ne pas nous retrouver sans pare-feu, BEFW reviendra au dernier état si une erreur se produit à un moment donné.

Dans les situations critiques, c'est la garantie que nous resterons avec un pare-feu fonctionnel. Nous ouvrons tous les réseaux gris dans l'espoir que l'administrateur viendra le réparer. Un jour, je le retirerai dans les configs, mais maintenant nous n'avons que trois réseaux gris: 10/8, 172/12 et 192.168 / 16. En tant que membre de notre Consul, c'est une caractéristique importante qui aide à se développer davantage.

: - BEFW. . GitHub.

Je vais vous parler des bugs rencontrés.

ipset add set 0.0.0.0/0. Que se passe-t-il si vous ajoutez à l'ipset 0.0.0.0/0? Toutes les adresses IP seront-elles ajoutées? L'accès à Internet sera-t-il ouvert?

Non, nous obtenons un bug qui nous a coûté deux heures d'indisponibilité. De plus, le bug ne fonctionne plus depuis 2016, il se trouve dans RedHat Bugzilla sous le numéro # 1297092, mais nous l'avons trouvé par accident - d'après le rapport du développeur.

Maintenant, BEFW a une règle stricte, qui 0.0.0.0/0se transforme en deux adresses: 0.0.0.0/1et 128.0.0.0/1.

ipset restore set <fichier. Que fait l'ipset lorsque vous le dites restore? Pensez-vous que cela fonctionne exactement comme iptables? Récupérer des données?

Rien de tel - il fait une fusion, et les anciennes adresses ne disparaissent pas, vous ne fermez pas l'accès.

Nous avons trouvé un bogue lorsque nous avons testé l'isolement. Maintenant, il y a un système assez compliqué - au lieu d'être restoreexécuté create temp, alors restore flush tempet restore temp. À la fin du swap: pour l'atomicité, car si vous effectuez d'abord flushet à ce moment un paquet arrive, il sera jeté et quelque chose ira mal. Il y a donc un peu de magie noire.

consul kv get -datacenter = autre. Comme je l'ai dit, nous pensons que nous demandons des données, mais nous obtiendrons soit des données, soit une erreur. Nous pouvons le faire par le biais du consul localement, mais dans ce cas, l'un et l'autre se bloqueront.

Le client Consul local est un wrapper sur l'API HTTP. Mais il se bloque et ne répond ni à Ctrl + C, ni à Ctrl + Z, quoi qu'il arrive, seulementkill -9dans la console adjacente. Nous sommes tombés sur cela lorsque nous construisions un grand cluster. Mais nous n'avons toujours pas de solution, nous nous préparons à corriger cette erreur dans Consul.

Le chef du consul ne répond pas. Notre maître dans le centre de données ne répond pas, nous pensons: "Probablement, l'algorithme de re-sélection fonctionnera maintenant?"

Non, cela ne fonctionnera pas, et le suivi ne montrera rien: le consul dira qu'il y a un indice d'engagement, un leader a été trouvé, tout va bien.

Comment combattons-nous cela? service consul restarten cron toutes les heures. Si vous avez 50 serveurs - ce n'est pas grave. Quand il y en aura 16 000, vous comprendrez comment cela fonctionne.

Conclusion

En conséquence, nous avons obtenu les avantages suivants:

Couverture à 100% de toutes les machines Linux.
La vitesse.
Automatisation
Libéré l'esclavage des ingénieurs du fer et des réseaux
Il existe des possibilités d'intégration presque infinies: même avec Kubernetes, même avec Ansible, même avec Python.

Inconvénients : Consul, avec qui nous vivons maintenant, et un prix d'erreur très élevé. À titre d'exemple, une fois à 18 heures (heures de grande écoute en Russie), j'ai statué quelque chose sur les listes de réseaux. Nous construisions l'isolation au BEFW à ce moment-là. Je me suis trompé quelque part, semble-t-il, j'ai indiqué le mauvais masque, mais tout est tombé en deux secondes. La surveillance s'allume, l'officier de garde entre: «Tout nous appartient!» Le chef du département est devenu gris quand il a expliqué à l'entreprise pourquoi cela s'était produit.

Le prix de l'erreur est si élevé que nous avons trouvé notre propre procédure compliquée de prophylaxie. Si vous l'implémentez sur une grande production, vous n'avez pas besoin de donner un jeton maître sur Consul à tout le monde. Ça va mal finir.

Coût.J'ai écrit le code pendant 400 heures seulement. Pour soutenir mon équipe de 4 personnes passe 10 heures par mois. Comparé au prix de tout pare-feu nouvelle génération, il est gratuit.

Des plans. Le plan à long terme est la recherche de transports alternatifs en échange ou en complément du Consul. Ce sera peut-être Kafka ou quelque chose comme ça. Mais dans les années à venir, nous vivrons sur Consul.

Plans immédiats: intégration avec Fail2ban, avec surveillance, avec nftables, éventuellement avec d'autres distributions, métriques, surveillance avancée, optimisation. Le support de Kubernetes est également quelque part dans les plans, car en ce moment nous avons plusieurs clusters et désir.

Un autre des plans:

rechercher des anomalies de trafic;
gestion de la carte du réseau;
Prise en charge de Kubernetes;
assemblage de packages pour tous les systèmes;
Interface Web

Nous travaillons constamment sur l'extension de la configuration, l'augmentation des métriques et l'optimisation.

Rejoignez le projet. Le projet s'est avéré être cool, mais, malheureusement, il s'agit toujours d'un projet d'une seule personne. Venez sur GitHub et essayez de faire quelque chose: engager, tester, offrir quelque chose, donner votre évaluation.

En attendant, nous nous préparons pour Saint HighLoad ++ , qui se tiendra les 6 et 7 avril à Saint-Pétersbourg, et nous invitons les développeurs de systèmes à forte charge à demander un rapport . Conférenciers expérimentés savent déjà quoi faire, et nous recommandons que les nouveaux arrivants à des discours au moins essayer . Participer à la conférence en tant qu'orateur présente plusieurs avantages. Lequel, vous pouvez lire, par exemple, à la fin de cet article .

Consul + iptables =: 3