{"id":87282,"date":"2020-07-06T13:44:51","date_gmt":"2020-07-06T11:44:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury"},"modified":"2021-02-01T11:41:48","modified_gmt":"2021-02-01T09:41:48","slug":"ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"De \u00ab startup \u00bb \u00e0 des milliers de serveurs dans une dizaine de centres de donn\u00e9es. Comment nous avons poursuivi la croissance de l'infrastructure Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si votre infrastructure IT cro\u00eet trop rapidement, vous serez t\u00f4t ou tard confront\u00e9 \u00e0 un choix : augmenter lin\u00e9airement les ressources humaines pour la soutenir ou commencer l'automatisation. Jusqu'\u00e0 un certain point, nous avons v\u00e9cu dans ce premier paradigme, puis a commenc\u00e9 un long chemin vers l'Infrastructure-as-Code.<\/p>\n

\"De
\n<\/a><\/noindex>
\nBien s\u00fbr, NSPK n'est pas une startup, mais c'est l'atmosph\u00e8re qui r\u00e9gnait dans l'entreprise durant les premi\u00e8res ann\u00e9es, et elles ont \u00e9t\u00e9 tr\u00e8s int\u00e9ressantes. Je m'appelle Dmitriy Koryakov<\/a><\/noindex>, cela fait plus de 10 ans que je soutiens une infrastructure Linux avec des exigences de disponibilit\u00e9 \u00e9lev\u00e9es. J'ai rejoint l'\u00e9quipe NSPK en janvier 2016 et, malheureusement, je n'ai pas connu le tout d\u00e9but de l'existence de l'entreprise, mais je suis arriv\u00e9 \u00e0 un moment de grands changements.<\/p>\n

Dans l'ensemble, on peut dire que notre \u00e9quipe fournit deux produits \u00e0 l'entreprise. Le premier est l'infrastructure. Les e-mails doivent circuler, le DNS doit fonctionner, et les contr\u00f4leurs de domaine doivent vous permettre d'acc\u00e9der \u00e0 des serveurs qui ne doivent pas tomber. Le paysage IT de l'entreprise est immense ! Ce sont des syst\u00e8mes critiques pour les affaires et les missions, et les exigences de disponibilit\u00e9 de certains atteignent 99,999. Le deuxi\u00e8me produit est constitu\u00e9 par les serveurs eux-m\u00eames, physiques et virtuels. Il faut surveiller ceux qui existent, et en fournir de nouveaux r\u00e9guli\u00e8rement aux clients dans de nombreux d\u00e9partements. Dans cet article, je souhaite me concentrer sur la mani\u00e8re dont nous avons d\u00e9velopp\u00e9 l'infrastructure qui g\u00e8re le cycle de vie. serveurs<\/a>.<\/p>\n

Le d\u00e9but du parcours<\/b><\/p>\n

Au d\u00e9but, notre pile technologique ressemblait \u00e0 ceci :
\nOS CentOS 7
\nContr\u00f4leurs de domaine FreeIPA
\nAutomatisation - Ansible(+Tower), Cobbler<\/i><\/p>\n

Tout cela \u00e9tait r\u00e9parti sur 3 domaines, dispers\u00e9s sur plusieurs centres de donn\u00e9es. Dans un centre de donn\u00e9es se trouvaient les syst\u00e8mes bureautiques et les environnements de test, dans les autres, la production.<\/p>\n

La cr\u00e9ation de serveurs \u00e0 un certain moment ressemblait \u00e0 ceci :<\/p>\n

\"De<\/p>\n

Dans le mod\u00e8le VM CentOS minimal, le minimum n\u00e9cessaire comme un correct \/etc\/resolv.conf, le reste arrive via Ansible.<\/p>\n

CMDB - Excel.<\/p>\n

Si le serveur est physique, au lieu de copier la machine virtuelle, on installait le syst\u00e8me d'exploitation \u00e0 l'aide de Cobbler - les adresses MAC du serveur cible \u00e9taient ajout\u00e9es \u00e0 la configuration de Cobbler, le serveur obtenait une adresse IP via DHCP, et ensuite, le syst\u00e8me d'exploitation \u00e9tait charg\u00e9.<\/p>\n

Au d\u00e9but, nous avons m\u00eame essay\u00e9 de faire une gestion de configuration dans Cobbler. Mais avec le temps, cela a commenc\u00e9 \u00e0 poser des probl\u00e8mes de portabilit\u00e9 des configurations \u00e0 la fois vers d'autres centres de donn\u00e9es et dans le code Ansible pour la pr\u00e9paration des VM.<\/p>\n

\u00c0 l'\u00e9poque, beaucoup d'entre nous percevaient Ansible comme une extension pratique de Bash et n'h\u00e9sitaient pas \u00e0 utiliser des constructions avec shell, sed. En gros, Bashsible. Cela menait finalement au fait que, si un playbook ne fonctionnait pas pour une raison quelconque sur le serveur, il \u00e9tait plus simple de supprimer le serveur, de corriger le playbook et de le faire passer \u00e0 nouveau. Il n'y avait en fait aucune version des scripts, et la portabilit\u00e9 des configurations non plus.<\/p>\n

Par exemple, si nous souhaitions modifier une certaine configuration sur tous les serveurs :<\/p>\n

    \n
  1. Nous modifions la configuration sur les serveurs existants dans un segment logique \/ un datacenter. Parfois pas en un jour \u2013 les exigences de disponibilit\u00e9 et la loi des grands nombres ne permettent pas d'appliquer tous les changements d'un coup. Et certains changements peuvent \u00eatre potentiellement destructeurs et n\u00e9cessiter un red\u00e9marrage de quelque chose \u2013 des services jusqu'au syst\u00e8me d'exploitation lui-m\u00eame.<\/li>\n
  2. Correction dans Ansible<\/li>\n
  3. Correction dans Cobbler<\/li>\n
  4. R\u00e9p\u00e9tons N fois pour chaque segment logique \/ datacenter<\/li>\n<\/ol>\n

    Pour que tous les changements se passent sans accroc, il \u00e9tait n\u00e9cessaire de prendre en compte de nombreux facteurs, et les changements se produisent constamment.<\/p>\n