{"id":33654,"date":"2019-10-31T21:53:58","date_gmt":"2019-10-31T18:53:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/deploj-prilozhenij-v-vm-nomad-i-kubernetes\/"},"modified":"2019-10-31T21:53:58","modified_gmt":"2019-10-31T18:53:58","slug":"deploj-prilozhenij-v-vm-nomad-i-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","title":{"rendered":"D\u00e9ploiement d'applications dans VM, Nomad et Kubernetes.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour \u00e0 tous ! Je m'appelle Pavel Agaletski. Je suis responsable d'\u00e9quipe dans le groupe qui d\u00e9veloppe le syst\u00e8me de livraison de Lamoda. En 2018, j'ai pr\u00e9sent\u00e9 \u00e0 la conf\u00e9rence HighLoad++, et aujourd'hui, je souhaite vous pr\u00e9senter la transcription de ma pr\u00e9sentation.<\/p>\n

Mon th\u00e8me est consacr\u00e9 \u00e0 l'exp\u00e9rience de notre entreprise concernant le d\u00e9ploiement de syst\u00e8mes et de services dans diff\u00e9rents environnements. Nous allons passer de nos temps pr\u00e9historiques, o\u00f9 nous d\u00e9ployions tous nos syst\u00e8mes sur des serveurs virtuels ordinaires, \u00e0 la transition progressive de Nomad au d\u00e9ploiement sur Kubernetes. Je vais expliquer pourquoi nous avons fait cela et quels probl\u00e8mes nous avons rencontr\u00e9s au cours de ce processus.<\/p>\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

D\u00e9ploiement d'applications sur VM<\/h1>\n

\nCommen\u00e7ons par le fait qu'il y a 3 ans, tous les syst\u00e8mes et services de l'entreprise \u00e9taient d\u00e9ploy\u00e9s sur des serveurs virtuels ordinaires. Tout \u00e9tait organis\u00e9 de mani\u00e8re \u00e0 ce que tout le code de nos syst\u00e8mes \u00e9tait stock\u00e9 et construit gr\u00e2ce \u00e0 des outils d'assemblage automatique comme Jenkins. Gr\u00e2ce \u00e0 Ansible, il \u00e9tait d\u00e9ploy\u00e9 depuis notre syst\u00e8me de contr\u00f4le de version vers les serveurs virtuels. Chaque syst\u00e8me au sein de notre soci\u00e9t\u00e9 \u00e9tait d\u00e9ploy\u00e9 sur au moins 2 serveurs : l'un d'eux sur le head, l'autre sur le tail. Ces deux syst\u00e8mes \u00e9taient absolument identiques dans tous leurs r\u00e9glages, performances, configurations, et ainsi de suite. La seule diff\u00e9rence entre eux \u00e9tait que le head recevait le trafic utilisateur, tandis que le tail n'en recevait jamais. <\/p>\n

Pourquoi cela a-t-il \u00e9t\u00e9 fait ? <\/p>\n

Lorsque nous d\u00e9ployions de nouvelles versions de notre application, nous voulions garantir la possibilit\u00e9 d'un d\u00e9ploiement sans interruption, c'est-\u00e0-dire sans cons\u00e9quences notables pour les utilisateurs. Cela a \u00e9t\u00e9 r\u00e9alis\u00e9 de sorte que la nouvelle version construite soit d\u00e9ploy\u00e9e sur le tail gr\u00e2ce \u00e0 Ansible. L\u00e0, les personnes charg\u00e9es du d\u00e9ploiement pouvaient v\u00e9rifier et s'assurer que tout fonctionnait correctement : toutes les m\u00e9triques, sections et applications \u00e9taient op\u00e9rationnelles ; les scripts n\u00e9cessaires \u00e9taient ex\u00e9cut\u00e9s. Ce n'est qu'apr\u00e8s qu'ils se sont assur\u00e9s que tout allait bien que le trafic \u00e9tait redirig\u00e9. Il a commenc\u00e9 \u00e0 aller vers le serveur qui \u00e9tait pr\u00e9c\u00e9demment en position de tail. Celui qui \u00e9tait auparavant en t\u00eate est rest\u00e9 sans trafic utilisateur, tout en conservant la version pr\u00e9c\u00e9dente de notre application.<\/p>\n

Ainsi, pour les utilisateurs, cela s'est fait de mani\u00e8re transparente. Parce que le basculement est instantan\u00e9, car il s'agit simplement d'un changement de load balancer. Il est tr\u00e8s facile de revenir \u00e0 la version pr\u00e9c\u00e9dente en remettant simplement le load balancer. Nous avons \u00e9galement pu nous assurer de la capacit\u00e9 de l'application en production avant m\u00eame que le trafic utilisateur ne commence, ce qui \u00e9tait tr\u00e8s pratique. <\/p>\n

Quels ont \u00e9t\u00e9 les avantages que nous avons constat\u00e9s dans tout cela ?<\/p>\n

    \n
  1. Tout d'abord, cela fonctionne assez bien. Cela fonctionne tout simplement.<\/b> Il est clair pour tout le monde comment un tel sch\u00e9ma de d\u00e9ploiement fonctionne, car la plupart des gens ont d\u00e9j\u00e0 d\u00e9ploy\u00e9 sur des serveurs virtuels classiques.<\/li>\n
  2. C'est assez fiable<\/b>, car la technologie de d\u00e9ploiement est simple, \u00e9prouv\u00e9e par des milliers d'entreprises. Des millions de serveurs sont d\u00e9ploy\u00e9s de cette fa\u00e7on. Il est difficile de casser quelque chose. <\/li>\n
  3. Enfin, nous avons pu obtenir des d\u00e9ploiements atomiques<\/b>. Des d\u00e9ploiements qui se produisent instantan\u00e9ment pour les utilisateurs, sans phase de transition perceptible entre la version ancienne et la nouvelle. <\/li>\n<\/ol>\n

    \nCependant, nous avons \u00e9galement vu quelques inconv\u00e9nients : <\/p>\n

      \n
    1. En plus de l'environnement de production et de d\u00e9veloppement, il y a d'autres environnements. Par exemple, QA et pr\u00e9production. \u00c0 l'\u00e9poque, nous avions de nombreux serveurs et environ 60 services. Pour cette raison, nous devions maintenir une version de machine virtuelle appropri\u00e9e pour chaque service. <\/b>De plus, si vous souhaitez mettre \u00e0 jour les biblioth\u00e8ques ou ajouter de nouvelles d\u00e9pendances, vous devez le faire dans tous les environnements. Il \u00e9tait \u00e9galement n\u00e9cessaire de synchroniser le moment o\u00f9 vous souhaitez d\u00e9ployer la nouvelle version de votre application avec le moment o\u00f9 DevOps effectuera les configurations n\u00e9cessaires. Dans ce cas, il est facile de se retrouver dans une situation o\u00f9 nos environnements diff\u00e8rent l\u00e9g\u00e8rement les uns des autres. Par exemple, dans l'environnement QA, il y aura une version des biblioth\u00e8ques, et en production, une autre, ce qui entra\u00eenera des probl\u00e8mes. <\/li>\n
    2. La complexit\u00e9 de la mise \u00e0 jour des d\u00e9pendances<\/b> de votre application. Cela ne d\u00e9pend pas de vous, mais d'une autre \u00e9quipe. \u00c0 savoir, l'\u00e9quipe DevOps, qui g\u00e8re les serveurs. Vous devez leur assigner une t\u00e2che correspondante et leur donner une description de ce que vous souhaitez accomplir.<\/li>\n
    3. \u00c0 l'\u00e9poque, nous voulions \u00e9galement diviser nos grands monolithes en petits services distincts, car nous r\u00e9alisions qu'ils allaient de plus en plus se multiplier. \u00c0 ce moment-l\u00e0, nous en avions d\u00e9j\u00e0 plus de 100. Il \u00e9tait n\u00e9cessaire de cr\u00e9er une nouvelle machine virtuelle pour chaque nouveau service, qui devait \u00e9galement \u00eatre maintenue et d\u00e9ploy\u00e9e. De plus, il ne fallait pas une seule machine, mais au moins deux. \u00c0 cela s'ajoutait un environnement de QA. Cela pose des probl\u00e8mes et rend la cr\u00e9ation et le lancement de nouveaux syst\u00e8mes plus complexes, co\u00fbteux et longs.<\/b><\/li>\n<\/ol>\n

      \nC'est pourquoi nous avons pris la d\u00e9cision qu'il serait plus pratique de passer du d\u00e9ploiement de machines virtuelles classiques au d\u00e9ploiement de nos applications dans des conteneurs Docker. Avec Docker, vous avez besoin d'un syst\u00e8me capable de lancer l'application en cluster, car vous ne pouvez pas simplement lever un conteneur. En g\u00e9n\u00e9ral, il est souhaitable de surveiller combien de conteneurs sont actifs pour qu'ils se lancent automatiquement. Pour cette raison, nous avions besoin de choisir un syst\u00e8me de gestion. <\/p>\n

      Nous avons beaucoup r\u00e9fl\u00e9chi \u00e0 celui que nous pouvions adopter. Le fait est qu'\u00e0 ce moment-l\u00e0, notre stack de d\u00e9ploiement sur des serveurs virtuels classiques \u00e9tait quelque peu obsol\u00e8te, car les versions du syst\u00e8me d'exploitation n'\u00e9taient pas les plus r\u00e9centes. \u00c0 un moment donn\u00e9, m\u00eame FreeBSD \u00e9tait install\u00e9, ce qui n'\u00e9tait pas tr\u00e8s pratique \u00e0 maintenir. Nous savions qu'il fallait migrer vers Docker le plus rapidement possible. Nos DevOps ont examin\u00e9 leur exp\u00e9rience avec diff\u00e9rentes solutions et ont choisi un syst\u00e8me comme Nomad. <\/p>\n

      Transition vers Nomad<\/h1>\n

      \nNomad est un produit de l'entreprise HashiCorp. Ils sont \u00e9galement connus pour d'autres solutions :<\/p>\n

      \"D\u00e9ploiement
      \n
      \n\"Consul\"<\/b> est un outil pour la d\u00e9couverte de services.<\/p>\n

      \"Terraform\"<\/b> est un syst\u00e8me de gestion des serveurs qui vous permet de les configurer via une infrastructure-as-code.<\/p>\n

      \"Vagrant\"<\/b> vous permet de d\u00e9ployer des machines virtuelles localement ou dans le cloud gr\u00e2ce \u00e0 des fichiers de configuration sp\u00e9cifiques. <\/p>\n

      \u00c0 ce moment-l\u00e0, Nomad semblait \u00eatre une solution assez simple, vers laquelle nous pourrions rapidement migrer sans changer toute l'infrastructure. De plus, il est relativement facile \u00e0 ma\u00eetriser. C'est pourquoi nous l'avons choisi comme syst\u00e8me de filtrage pour notre conteneur. <\/p>\n

      Que faut-il pour d\u00e9ployer votre syst\u00e8me dans Nomad ? <\/p>\n

        \n
      1. Tout d'abord, il faut un docker image<\/b> de votre application. Il est n\u00e9cessaire de le compiler et de le placer dans un stockage de images Docker. Dans notre cas, cela sera Artifactory \u2014 un syst\u00e8me qui permet de pousser divers artefacts de diff\u00e9rents types. Il peut stocker des archives, des images Docker, des paquets composer PHP, des paquets NPM, et ainsi de suite. <\/li>\n
      2. Il est \u00e9galement n\u00e9cessaire le fichier de configuration<\/b>, qui dira \u00e0 Nomad ce que vous souhaitez d\u00e9ployer, o\u00f9 et en quelle quantit\u00e9. <\/li>\n<\/ol>\n

        \nLorsque nous parlons de Nomad, le format de fichier d'information qu'il utilise est le langage HCL, qui signifie HashiCorp Configuration Language<\/i>. C'est un sur-ensemble de YAML qui vous permet de d\u00e9crire votre service en termes de Nomad. <\/p>\n

        \"D\u00e9ploiement
        \n
        \nIl permet de sp\u00e9cifier combien de conteneurs vous souhaitez d\u00e9ployer, de quels images se servir et de transmettre divers param\u00e8tres lors du d\u00e9ploiement. Ainsi, vous fournissez ce fichier \u00e0 Nomad, et il lance les conteneurs en production en accord avec celui-ci. <\/p>\n

        Dans notre cas, nous avons compris qu'il n'\u00e9tait pas tr\u00e8s pratique de r\u00e9diger des fichiers HCL compl\u00e8tement identiques pour chaque service, car il y a beaucoup de services et il arrive parfois que nous souhaitions les mettre \u00e0 jour. Il arrive qu'un service ne soit pas d\u00e9ploy\u00e9 qu'en un seul exemplaire, mais en plusieurs versions. Par exemple, l'un des syst\u00e8mes que nous avons en production dispose de plus de 100 instances. Ils sont lanc\u00e9s \u00e0 partir des m\u00eames images, mais diff\u00e8rent par leurs r\u00e9glages de configuration et leurs fichiers de configuration. <\/p>\n

        C'est pourquoi nous avons d\u00e9cid\u00e9 qu'il serait pratique de stocker tous nos fichiers de configuration pour le d\u00e9ploiement dans un d\u00e9p\u00f4t commun. De cette mani\u00e8re, ils deviennent consultables : il est facile de les maintenir et de voir quels syst\u00e8mes nous avons. En cas de besoin, il est \u00e9galement simple de mettre \u00e0 jour ou de modifier quelque chose. Ajouter un nouveau syst\u00e8me ne sera pas compliqu\u00e9 non plus \u2014 il suffit de cr\u00e9er un fichier de configuration dans un nouveau r\u00e9pertoire. \u00c0 l'int\u00e9rieur, il y a des fichiers : service.hcl, qui contient la description de notre service, et certains fichiers env qui permettent de configurer ce service une fois d\u00e9ploy\u00e9 en production. <\/p>\n

        \"D\u00e9ploiement
        \n
        \nCependant, certains de nos syst\u00e8mes ne sont pas d\u00e9ploy\u00e9s en production en un seul exemplaire, mais en plusieurs simultan\u00e9ment. Par cons\u00e9quent, nous avons d\u00e9cid\u00e9 qu'il serait plus pratique pour nous de conserver non pas des configurations sous leur forme brute, mais plut\u00f4t sous forme de mod\u00e8les. Et comme langage de mod\u00e9lisation, nous avons choisi jinja 2<\/i>. Dans ce format, nous stockons \u00e0 la fois les configs du service lui-m\u00eame et les fichiers env n\u00e9cessaires pour celui-ci. <\/p>\n

        De plus, nous avons plac\u00e9 dans le d\u00e9p\u00f4t un script de d\u00e9ploiement commun \u00e0 tous les projets, qui permet de d\u00e9marrer et de d\u00e9ployer votre service en production, dans l'environnement souhait\u00e9, dans la cible ad\u00e9quate. Lorsque nous avons transform\u00e9 notre configuration HCL en mod\u00e8le, le fichier HCL qui \u00e9tait auparavant une configuration Nomad a alors l\u00e9g\u00e8rement chang\u00e9 d'apparence.<\/p>\n

        \"D\u00e9ploiement
        \n
        \nC'est-\u00e0-dire que nous avons remplac\u00e9 certaines variables de la configuration par des insertions de variables, qui proviennent des fichiers env ou d'autres sources. En outre, nous avons obtenu la possibilit\u00e9 de g\u00e9n\u00e9rer des fichiers HCL dynamiquement, ce qui signifie que nous pouvons appliquer non seulement des insertions de variables ordinaires. \u00c9tant donn\u00e9 que Jinja prend en charge les boucles et les conditions, nous pouvons \u00e9galement cr\u00e9er des fichiers de configuration qui changent en fonction de l'endroit o\u00f9 vous d\u00e9ployez vos applications. <\/p>\n

        Par exemple, vous souhaitez d\u00e9ployer votre service en pr\u00e9production et en production. Supposons qu'en pr\u00e9production, vous ne souhaitiez pas ex\u00e9cuter de scripts cron, mais que vous vouliez simplement voir le service sur un domaine s\u00e9par\u00e9, afin de vous assurer qu'il fonctionne. Pour quiconque d\u00e9ployant un service, le processus est tr\u00e8s simple et transparent. Il suffit d'ex\u00e9cuter le fichier deploy.sh, d'indiquer quel service vous souhaitez d\u00e9ployer et dans quelle cible. Par exemple, vous souhaitez d\u00e9ployer un certain syst\u00e8me en Russie, en Bi\u00e9lorussie ou au Kazakhstan. Il vous suffit de modifier l'un des param\u00e8tres, et un fichier de configuration correct sera g\u00e9n\u00e9r\u00e9. <\/p>\n

        Une fois que le service Nomad est d\u00e9ploy\u00e9 dans votre cluster, il appara\u00eet comme suit.<\/p>\n

        \"D\u00e9ploiement
        \n
        \nTout d'abord, vous avez besoin d'un \u00e9quilibrage de charge \u00e0 l'ext\u00e9rieur, qui acceptera tout le trafic utilisateur. Il fonctionnera avec Consul et lui demandera o\u00f9 se trouve, sur quel n\u0153ud, sp\u00e9cifique service, qui correspond \u00e0 tel ou tel nom de domaine. une adresse IP<\/a> Les services dans Consul proviennent de Nomad lui-m\u00eame. \u00c9tant donn\u00e9 qu'ils sont des produits de la m\u00eame entreprise, ils sont bien li\u00e9s entre eux. On peut dire que Nomad est capable de s'inscrire automatiquement pour tous les services lanc\u00e9s \u00e0 l'int\u00e9rieur de Consul. <\/p>\n

        Une fois que votre r\u00e9partiteur de charge externe sait vers quel service acheminer le trafic, il le redirige vers le conteneur correspondant ou vers plusieurs conteneurs li\u00e9s \u00e0 votre application. Naturellement, il est \u00e9galement essentiel de r\u00e9fl\u00e9chir \u00e0 la s\u00e9curit\u00e9. Bien que tous les services soient lanc\u00e9s sur les m\u00eames machines virtuelles dans des conteneurs, cela n\u00e9cessite g\u00e9n\u00e9ralement d'interdire l'acc\u00e8s libre de tout service \u00e0 tout autre. Nous avons atteint cet objectif gr\u00e2ce \u00e0 la segmentation. Chaque service \u00e9tait lanc\u00e9 dans son propre r\u00e9seau virtuel, o\u00f9 des r\u00e8gles de routage et des r\u00e8gles de permis\/refus d'acc\u00e8s aux autres syst\u00e8mes et services \u00e9taient \u00e9tablies. Ceux-ci pouvaient se situer \u00e0 l'int\u00e9rieur comme \u00e0 l'ext\u00e9rieur de ce cluster. Par exemple, si vous souhaitez interdire \u00e0 un service de se connecter \u00e0 une base de donn\u00e9es sp\u00e9cifique, cela peut \u00eatre accompli par la segmentation au niveau du r\u00e9seau. C'est-\u00e0-dire qu'il est impossible, m\u00eame par accident, de se connecter depuis un environnement de test \u00e0 votre base de production.<\/p>\n

        Quel a \u00e9t\u00e9 le co\u00fbt humain du processus de transition? <\/p>\n

        La transition de toute l'entreprise vers Nomad a dur\u00e9 environ 5 \u00e0 6 mois. Nous avons migr\u00e9 service par service, mais \u00e0 un rythme assez rapide. Chaque \u00e9quipe devait cr\u00e9er ses propres conteneurs pour les services. <\/p>\n

        Nous avons adopt\u00e9 l'approche selon laquelle chaque \u00e9quipe est responsable de ses propres images Docker. Les DevOps fournissent l'infrastructure g\u00e9n\u00e9rale n\u00e9cessaire au d\u00e9ploiement, c'est-\u00e0-dire le support du cluster lui-m\u00eame, le support du syst\u00e8me CI, etc. \u00c0 ce moment-l\u00e0, plus de 60 syst\u00e8mes avaient d\u00e9m\u00e9nag\u00e9 vers Nomad, ce qui a donn\u00e9 environ 2000 conteneurs. <\/p>\n

        Les DevOps sont responsables de l'infrastructure g\u00e9n\u00e9rale de tout ce qui concerne le d\u00e9ploiement et les serveurs. Chaque \u00e9quipe de d\u00e9veloppement est responsable de la mise en \u0153uvre des conteneurs pour son syst\u00e8me sp\u00e9cifique, car c'est l'\u00e9quipe qui sait exactement ce dont elle a besoin dans tel ou tel conteneur.<\/p>\n

        Raisons de l'abandon de Nomad<\/h1>\n

        \nQuels avantages avons-nous obtenus en migrant vers un d\u00e9ploiement via Nomad et Docker, entre autres?<\/p>\n

          \n
        1. Nous Nous avons assur\u00e9 des conditions homog\u00e8nes<\/b> pour tous les environnements. Dans le d\u00e9veloppement, l'environnement QA, la pr\u00e9production et la production, les m\u00eames images de conteneurs avec les m\u00eames d\u00e9pendances sont utilis\u00e9es. Vous avez donc pratiquement aucune chance que ce qui parvienne en production soit diff\u00e9rent de ce que vous avez test\u00e9 localement ou dans un environnement de test. <\/li>\n
        2. Nous avons \u00e9galement d\u00e9couvert qu'il suffit d'ajouter facilement un nouveau service<\/b>. Tous les nouveaux syst\u00e8mes en termes de d\u00e9ploiement sont lanc\u00e9s tr\u00e8s simplement. Il suffit d'aller dans le r\u00e9f\u00e9rentiel o\u00f9 les configurations sont stock\u00e9es, d'y ajouter une nouvelle configuration pour votre syst\u00e8me, et vous \u00eates pr\u00eat. Vous pouvez d\u00e9ployer votre syst\u00e8me en production sans effort suppl\u00e9mentaire de la part des DevOps. <\/li>\n
        3. Tous fichiers de configuration<\/b> dans un r\u00e9f\u00e9rentiel commun ont \u00e9t\u00e9 examin\u00e9s<\/b>. Au moment o\u00f9 nous avons d\u00e9ploy\u00e9 nos syst\u00e8mes \u00e0 l'aide de serveurs virtuels<\/a>, nous utilisions Ansible, o\u00f9 les configurations \u00e9taient dans le m\u00eame r\u00e9f\u00e9rentiel. Cependant, pour la plupart des d\u00e9veloppeurs, travailler avec cela \u00e9tait un peu plus compliqu\u00e9. Ici, le volume des configurations et du code que vous devez ajouter pour d\u00e9ployer le service a consid\u00e9rablement diminu\u00e9. De plus, il est tr\u00e8s facile pour les DevOps de le modifier ou de le changer. En cas de transitions, par exemple lors d'une nouvelle version de Nomad, ils peuvent mettre \u00e0 jour massivement tous les fichiers d'exploitation qui se trouvent au m\u00eame endroit.<\/li>\n<\/ol>\n

          \nMais nous avons \u00e9galement rencontr\u00e9 plusieurs inconv\u00e9nients : <\/p>\n

          Il s'est av\u00e9r\u00e9 que nous n'avons pas pu atteindre une transparence des d\u00e9ploiements <\/b>dans le cas de Nomad. Lors du d\u00e9ploiement de conteneurs depuis diff\u00e9rents environnements, il pouvait arriver qu'il soit lanc\u00e9, et Nomad le consid\u00e9rait comme pr\u00eat \u00e0 recevoir du trafic. Cela se produisait avant m\u00eame que l'application \u00e0 l'int\u00e9rieur ait eu le temps de d\u00e9marrer. Pour cette raison, le syst\u00e8me a commenc\u00e9 \u00e0 g\u00e9n\u00e9rer des erreurs 500 pendant une courte p\u00e9riode, car le trafic commen\u00e7ait \u00e0 aller vers un conteneur qui n'\u00e9tait pas encore pr\u00eat \u00e0 l'accepter. <\/p>\n

          Nous avons rencontr\u00e9 certains bugs<\/b>. Le principal probl\u00e8me r\u00e9side dans le fait que Nomad ne g\u00e8re pas tr\u00e8s bien un grand cluster, surtout si vous avez beaucoup de syst\u00e8mes et de conteneurs. Lorsque vous souhaitez retirer un des serveurs qui fait partie du cluster Nomad pour maintenance, il y a une probabilit\u00e9 assez \u00e9lev\u00e9e que le cluster ne fonctionne pas tr\u00e8s bien et se d\u00e9sint\u00e8gre. Une partie des conteneurs peut, par exemple, \u00e9chouer et ne pas red\u00e9marrer \u2013 cela pourrait vous co\u00fbter cher si tous vos syst\u00e8mes en production se trouvent dans le cluster g\u00e9r\u00e9 par Nomad. <\/p>\n

          C'est pourquoi nous avons d\u00e9cid\u00e9 de r\u00e9fl\u00e9chir \u00e0 la direction \u00e0 prendre. \u00c0 ce moment-l\u00e0, nous avons bien compris ce que nous voulions atteindre. En effet : nous cherchons de la fiabilit\u00e9, un peu plus de fonctionnalit\u00e9s que ce que propose Nomad, et un syst\u00e8me plus mature et plus stable. <\/p>\n

          Dans ce contexte, notre choix s'est port\u00e9 sur Kubernetes, la plate-forme la plus populaire pour ex\u00e9cuter des clusters. Surtout \u00e9tant donn\u00e9 que la taille et le nombre de nos conteneurs \u00e9taient suffisamment importants. Pour ces objectifs, Kubernetes s'est av\u00e9r\u00e9e \u00eatre le syst\u00e8me le plus adapt\u00e9 parmi ceux que nous avons envisag\u00e9s. <\/p>\n

          Transition vers Kubernetes<\/h1>\n

          \nJe vais expliquer les principaux concepts de Kubernetes et en quoi ils diff\u00e8rent de Nomad. <\/p>\n

          \"D\u00e9ploiement
          \n
          \nTout d'abord, le concept le plus fondamental dans Kubernetes est celui de pod. Pod<\/b> \u2014 c'est un groupe d'un ou plusieurs conteneurs qui sont toujours d\u00e9ploy\u00e9s ensemble. Ils fonctionnent comme s'ils \u00e9taient toujours strictement sur une seule machine virtuelle. Ils sont accessibles entre eux par l'adresse IP 127.0.0.1 sur diff\u00e9rents ports. <\/p>\n

          Supposons que vous ayez une application PHP compos\u00e9e de nginx et php-fpm \u2013 un sch\u00e9ma classique. Il est probable que vous souhaitiez que les conteneurs nginx et php-fpm soient toujours ensemble. Kubernetes permet d'y parvenir en les d\u00e9crivant comme un pod commun. C'est pr\u00e9cis\u00e9ment ce que nous n'avons pas pu obtenir avec Nomad.<\/p>\n

          Le deuxi\u00e8me concept est celui de d\u00e9ploiement<\/b>. En r\u00e9alit\u00e9, un pod en soi est une chose \u00e9ph\u00e9m\u00e8re, il se lance et dispara\u00eet. Voulez-vous d'abord supprimer tous vos conteneurs pr\u00e9c\u00e9dents puis lancer directement de nouvelles versions, ou souhaitez-vous les d\u00e9ployer progressivement ? C'est ce processus qui est g\u00e9r\u00e9 par le concept de d\u00e9ploiement. Il d\u00e9crit comment vous d\u00e9ployez vos pods, en quelle quantit\u00e9 et comment les mettre \u00e0 jour. <\/p>\n

          Le troisi\u00e8me concept est service<\/b>. Votre service est en fait votre syst\u00e8me qui re\u00e7oit un certain trafic et le redirige vers un ou plusieurs pods correspondant \u00e0 votre service. Cela signifie qu'il permet de diriger tout le trafic entrant vers un service particulier avec un nom donn\u00e9 sur ces pods sp\u00e9cifiques. Il vous assure \u00e9galement un \u00e9quilibrage de charge. Vous pouvez lancer deux pods de votre application, et tout le trafic entrant sera r\u00e9parti de mani\u00e8re uniforme entre les pods associ\u00e9s \u00e0 ce service.<\/p>\n

          Et le quatri\u00e8me concept fondamental \u2014 Ingress<\/b>. C'est un service qui s'ex\u00e9cute dans un cluster Kubernetes. Il agit en tant qu'\u00e9quilibreur de charge externe qui re\u00e7oit toutes les requ\u00eates. Gr\u00e2ce \u00e0 l'API Kubernetes Ingress, il peut d\u00e9terminer o\u00f9 ces requ\u00eates doivent \u00eatre envoy\u00e9es. Il le fait de mani\u00e8re tr\u00e8s flexible. Vous pouvez dire que toutes les requ\u00eates \u00e0 cet h\u00f4te et \u00e0 cette URL doivent \u00eatre envoy\u00e9es \u00e0 ce service. Et celles-ci, qui arrivent \u00e0 cet h\u00f4te mais \u00e0 une autre URL, doivent \u00eatre envoy\u00e9es \u00e0 un autre service. <\/p>\n

          Ce qui est vraiment g\u00e9nial du point de vue du d\u00e9veloppeur d'application, c'est que vous pouvez g\u00e9rer tout cela vous-m\u00eame. En configurant Ingress, vous pouvez diriger tout le trafic entrant sur un API sp\u00e9cifique vers des conteneurs distincts, par exemple \u00e9crits en Go. Et ce trafic, qui arrive au m\u00eame domaine mais \u00e0 une autre URL, peut \u00eatre dirig\u00e9 vers des conteneurs \u00e9crits en PHP, o\u00f9 se trouve beaucoup de logique, mais qui ne sont pas tr\u00e8s rapides.<\/p>\n

          Si l'on compare tous ces concepts avec Nomad, on peut dire que les trois premiers concepts constituent ensemble un Service. Quant au dernier concept, il n'existe pas dans Nomad. Nous avons utilis\u00e9 un \u00e9quilibreur de charge externe \u00e0 sa place : cela peut \u00eatre haproxy, nginx, nginx+ et ainsi de suite. Dans le cas de Kubernetes, vous n'avez pas besoin d'introduire ce concept suppl\u00e9mentaire s\u00e9par\u00e9ment. Cependant, si l'on regarde Ingress en interne, c'est soit nginx, soit haproxy, soit traefik, mais int\u00e9gr\u00e9 dans Kubernetes. <\/p>\n

          Tous les concepts que j'ai d\u00e9crits sont essentiellement des ressources qui existent \u00e0 l'int\u00e9rieur d'un cluster Kubernetes. Pour les d\u00e9crire, Kubernetes utilise un format yaml, qui est plus lisible et familier que les fichiers HCL dans le cas de Nomad. Mais structurellement, ils d\u00e9crivent la m\u00eame chose, par exemple pour les pods. Ils disent : je veux d\u00e9ployer ces pods l\u00e0, avec ces images, en telle quantit\u00e9. <\/p>\n

          \"D\u00e9ploiement
          \n
          \nDe plus, nous avons compris que nous ne souhaitions pas cr\u00e9er manuellement chaque ressource distincte : d\u00e9ploiement, services, Ingress et autres. Au lieu de cela, nous voulions, lors du d\u00e9ploiement, d\u00e9crire chacun de nos syst\u00e8mes en utilisant les termes de Kubernetes, afin de ne pas avoir \u00e0 recr\u00e9er manuellement toutes les d\u00e9pendances n\u00e9cessaires des ressources dans le bon ordre. Pour cela, nous avons choisi Helm comme syst\u00e8me qui nous permettrait de le faire. <\/p>\n

          Concepts de base de Helm<\/h1>\n

          \nHelm est un gestionnaire de paquets<\/b> pour Kubernetes. Il est tr\u00e8s similaire au fonctionnement des gestionnaires de paquets dans les langages de programmation. Ils vous permettent de stocker un service compos\u00e9, par exemple, de d\u00e9ploiements nginx, de d\u00e9ploiements php-fpm, de configurations pour Ingress, de configmaps (c'est une entit\u00e9 qui vous permet de d\u00e9finir des env et d'autres param\u00e8tres pour votre syst\u00e8me) sous forme des chartes appel\u00e9es ainsi. Par ailleurs, Helm fonctionne au-dessus de Kubernetes<\/b>. Donc, ce n'est pas un syst\u00e8me s\u00e9par\u00e9, mais juste un autre service qui s'ex\u00e9cute \u00e0 l'int\u00e9rieur du cluster. Vous interagissez avec lui via son API en utilisant une commande en ligne. Sa commodit\u00e9 et son attrait r\u00e9sident dans le fait que m\u00eame si le helm plante ou si vous le supprimez du cluster, vos services ne dispara\u00eetront pas, car le helm sert essentiellement uniquement \u00e0 lancer le syst\u00e8me. Kubernetes est ensuite responsable du bon fonctionnement et de l'\u00e9tat des services. <\/p>\n

          Nous avons \u00e9galement r\u00e9alis\u00e9 que la templatisation<\/b>, que nous avions auparavant \u00e9t\u00e9 contraints de r\u00e9aliser nous-m\u00eames en int\u00e9grant jinja dans nos configurations, est l'une des principales fonctionnalit\u00e9s de helm. Tous les fichiers de configuration que vous cr\u00e9ez pour vos syst\u00e8mes sont stock\u00e9s dans helm sous forme de mod\u00e8les, semblables \u00e0 jinja, mais utilisant en fait la templatisation du langage Go, dans lequel helm est \u00e9crit, tout comme Kubernetes. <\/p>\n

          Helm nous ajoute \u00e9galement quelques concepts suppl\u00e9mentaires. <\/p>\n

          Chart<\/b> \u2014 c'est la description de votre service. Dans d'autres gestionnaires de paquets, cela serait appel\u00e9 paquet, bundle ou quelque chose de similaire. Ici, cela s'appelle un chart. <\/p>\n

          Valeurs <\/b>\u2013 ce sont les variables que vous souhaitez utiliser pour assembler vos configurations \u00e0 partir des mod\u00e8les. <\/p>\n

          Publication<\/b>. Chaque fois qu\u2019un service d\u00e9ploy\u00e9 avec helm re\u00e7oit une version incr\u00e9mentale de la version. Helm se souvient de la configuration du service lors des pr\u00e9c\u00e9dentes versions, et ainsi de suite. Par cons\u00e9quent, si vous devez revenir en arri\u00e8re, il suffit d\u2019ex\u00e9cuter la commande helm callback en sp\u00e9cifiant la version pr\u00e9c\u00e9dente. M\u00eame si la configuration correspondante n\u2019est pas accessible dans votre d\u00e9p\u00f4t au moment du retour, helm se souvient de ce qu\u2019elle \u00e9tait et ram\u00e8ne votre syst\u00e8me \u00e0 l\u2019\u00e9tat pr\u00e9c\u00e9dent. <\/p>\n

          Lorsqu\u2019on utilise helm, les configurations habituelles pour Kubernetes se transforment \u00e9galement en mod\u00e8les, permettant d\u2019utiliser des variables, des fonctions et des op\u00e9rateurs conditionnels. Ainsi, vous pouvez assembler la configuration de votre service en fonction de l\u2019environnement.<\/p>\n

          \"D\u00e9ploiement
          \n
          \nEn pratique, nous avons d\u00e9cid\u00e9 de proc\u00e9der l\u00e9g\u00e8rement diff\u00e9remment par rapport \u00e0 ce que nous avions fait avec Nomad. Dans Nomad, le m\u00eame d\u00e9p\u00f4t contenait \u00e0 la fois les configurations de d\u00e9ploiement et les variables n\u00e9cessaires pour d\u00e9ployer notre service. Ici, nous avons choisi de les s\u00e9parer en deux d\u00e9p\u00f4ts distincts. Le d\u00e9p\u00f4t \u00ab deploy \u00bb ne contient que les variables n\u00e9cessaires pour le d\u00e9ploiement, tandis que le d\u00e9p\u00f4t \u00ab helm \u00bb contient les configurations ou charts.<\/p>\n

          \"D\u00e9ploiement
          \n
          \nQu'est-ce que cela nous a apport\u00e9 ? <\/p>\n

          Bien que nous ne stockions pas de donn\u00e9es r\u00e9ellement sensibles dans les fichiers de configuration, par exemple, les mots de passe des bases de donn\u00e9es, qui sont stock\u00e9s sous forme de secrets dans Kubernetes, il existe tout de m\u00eame des \u00e9l\u00e9ments auxquels nous ne souhaitons pas donner un acc\u00e8s g\u00e9n\u00e9ral. Ainsi, l\u2019acc\u00e8s au d\u00e9p\u00f4t \u00ab deploy \u00bb est plus restreint, tandis que le d\u00e9p\u00f4t \u00ab helm \u00bb contient simplement la description du service. Pour cette raison, on peut donner un acc\u00e8s en toute s\u00e9curit\u00e9 \u00e0 un plus grand nombre de personnes. <\/p>\n

          \u00c9tant donn\u00e9 que nous avons non seulement un environnement de production mais aussi d\u2019autres environnements, gr\u00e2ce \u00e0 cette s\u00e9paration, nous pouvons r\u00e9utiliser nos charts helm pour d\u00e9ployer des services non seulement en production, mais aussi, par exemple, dans un environnement QA. M\u00eame pour les d\u00e9ployer localement, en utilisant Minikube<\/i> \u2014 c\u2019est un outil pour le lancement local de Kubernetes. <\/p>\n

          Dans chaque r\u00e9f\u00e9rentiel, nous avons laiss\u00e9 une s\u00e9paration en plusieurs r\u00e9pertoires pour chaque service. Autrement dit, chaque r\u00e9pertoire contient des mod\u00e8les relatifs au graphique correspondant et d\u00e9crivant les ressources \u00e0 d\u00e9ployer pour lancer notre syst\u00e8me. Dans le r\u00e9f\u00e9rentiel \u00ab deploy \u00bb, nous avons laiss\u00e9 uniquement les en-t\u00eates. Dans ce cas, nous n'avons pas utilis\u00e9 la templatisation avec jinja, car helm fournit lui-m\u00eame une templatisation par d\u00e9faut \u2013 c'est l'une de ses principales fonctionnalit\u00e9s. <\/p>\n

          Nous avons laiss\u00e9 un script de d\u00e9ploiement \u2013 deploy.sh, qui simplifie et standardise le lancement du d\u00e9ploiement avec helm. Ainsi, pour quiconque souhaitant d\u00e9ployer, l'interface de d\u00e9ploiement ressemble exactement \u00e0 celle utilis\u00e9e lors d'un d\u00e9ploiement via Nomad. Le m\u00eame deploy.sh, le nom de votre service, et l'endroit o\u00f9 vous souhaitez le d\u00e9ployer. Cela conduit \u00e0 l'ex\u00e9cution de helm. Celui-ci rassemble les configurations \u00e0 partir des mod\u00e8les, ins\u00e8re les fichiers values n\u00e9cessaires, puis d\u00e9ploie en les lan\u00e7ant dans Kubernetes. <\/p>\n

          Conclusions<\/h1>\n

          \nLe service Kubernetes semble plus complexe que Nomad. <\/p>\n

          \"D\u00e9ploiement
          \n
          \nIci, le trafic sortant arrive dans Ingress. C'est le contr\u00f4leur frontal qui prend en charge toutes les requ\u00eates et les envoie ensuite aux services correspondant aux donn\u00e9es de la requ\u00eate. Il les d\u00e9termine en fonction des configurations, qui font partie de la description de votre application dans helm et qui sont d\u00e9finies par les d\u00e9veloppeurs eux-m\u00eames. Le service envoie les requ\u00eates \u00e0 ses pods, c'est-\u00e0-dire des conteneurs sp\u00e9cifiques, \u00e9quilibrant le trafic entrant entre tous les conteneurs li\u00e9s \u00e0 ce service. Et bien s\u00fbr, il ne faut pas oublier que nous ne devons pas n\u00e9gliger la s\u00e9curit\u00e9 au niveau du r\u00e9seau. Ainsi, dans le cluster Kubernetes, une segmentation bas\u00e9e sur le balisage est mise en \u0153uvre. Tous les services ont des balises sp\u00e9cifiques auxquelles sont attach\u00e9s les droits d'acc\u00e8s des services \u00e0 certaines ressources externes\/internes \u00e0 l'int\u00e9rieur ou \u00e0 l'ext\u00e9rieur du cluster. <\/p>\n

          En faisant la transition, nous avons constat\u00e9 que Kubernetes poss\u00e8de toutes les fonctionnalit\u00e9s de Nomad, que nous utilisions auparavant, tout en ajoutant beaucoup de nouveaut\u00e9s. Il peut \u00eatre \u00e9tendu via des plugins, et en fait, via des types de ressources personnalis\u00e9s. Cela signifie que vous avez la possibilit\u00e9 de ne pas seulement utiliser ce qui est standard dans Kubernetes, mais de cr\u00e9er votre propre ressource et service qui interagira avec votre ressource. Cela offre des possibilit\u00e9s d'extension suppl\u00e9mentaires pour votre syst\u00e8me sans avoir besoin de r\u00e9installer Kubernetes ou de proc\u00e9der \u00e0 des modifications. <\/p>\n

          Un exemple d'utilisation est Prometheus, qui s'ex\u00e9cute dans notre cluster Kubernetes. Pour qu'il commence \u00e0 collecter des m\u00e9triques d'un service donn\u00e9, nous devons ajouter un type de ressource suppl\u00e9mentaire dans la description du service, appel\u00e9 le service-monitor. Gr\u00e2ce au fait que Prometheus peut lire les types de ressources personnalis\u00e9s lorsqu'il est lanc\u00e9 dans Kubernetes, il commence automatiquement \u00e0 collecter des m\u00e9triques de ce nouveau syst\u00e8me. C'est assez pratique. <\/p>\n

          Le premier d\u00e9ploiement que nous avons effectu\u00e9 dans Kubernetes a eu lieu en mars 2018. Et pendant tout ce temps, nous n'avons jamais rencontr\u00e9 de probl\u00e8mes. Il fonctionne de mani\u00e8re assez stable sans bugs significatifs. De plus, nous pouvons l'\u00e9tendre davantage. \u00c0 ce jour, nous disposons des fonctionnalit\u00e9s qu'il offre, et nous appr\u00e9cions beaucoup la rapidit\u00e9 d'\u00e9volution de Kubernetes. Actuellement, plus de 3000 conteneurs sont ex\u00e9cut\u00e9s dans Kubernetes. Le cluster couvre plusieurs n\u0153uds. Il est en service, stable et tr\u00e8s contr\u00f4l\u00e9.
          \n
          Source :           habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

          \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda. \u0412 2018 \u0433\u043e\u0434\u0443 \u044f \u0432\u044b\u0441\u0442\u0443\u043f\u0430\u043b \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 HighLoad++, \u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0445\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0443 \u0441\u0432\u043e\u0435\u0433\u043e \u0434\u043e\u043a\u043b\u0430\u0434\u0430. \u041c\u043e\u044f \u0442\u0435\u043c\u0430 \u043f\u043e\u0441\u0432\u044f\u0449\u0435\u043d\u0430 \u043e\u043f\u044b\u0442\u0443 \u043d\u0430\u0448\u0435\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u043f\u043e \u0434\u0435\u043f\u043b\u043e\u044e \u0441\u0438\u0441\u0442\u0435\u043c \u0438 \u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u0432 \u0440\u0430\u0437\u043d\u044b\u0435 \u0441\u0440\u0435\u0434\u044b. \u041d\u0430\u0447\u0438\u043d\u0430\u044f \u043e\u0442 \u043d\u0430\u0448\u0438\u0445 \u0434\u043e\u0438\u0441\u0442\u043e\u0440\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u0432\u0440\u0435\u043c\u0435\u043d, \u043a\u043e\u0433\u0434\u0430 \u043c\u044b \u0434\u0435\u043f\u043b\u043e\u0438\u043b\u0438 \u0432\u0441\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25343,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33654","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47D\u00e9ploiement d'applications dans VM, Nomad et Kubernetes | ProHoster","description":"Bonjour \u00e0 tous ! Je m'appelle Pavel Agaletsky. Je suis chef d'\u00e9quipe dans une \u00e9quipe qui d\u00e9veloppe le syst\u00e8me de livraison de Lamoda.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043f\u043b\u043e\u0439 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 VM, Nomad \u0438 Kubernetes | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041f\u0430\u0432\u0435\u043b \u0410\u0433\u0430\u043b\u0435\u0446\u043a\u0438\u0439. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0442\u0438\u043c\u043b\u0438\u0434\u043e\u043c \u0432 \u043a\u043e\u043c\u0430\u043d\u0434\u0435, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 Lamoda.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/deploj-prilozhenij-v-vm-nomad-i-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:53:58+00:00","article:modified_time":"2019-10-31T18:53:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33654","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:38:40","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:36:34","updated":"2026-02-08 20:38:40","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33654","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=33654"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33654\/revisions"}],"predecessor-version":[{"id":157982,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/33654\/revisions\/157982"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/25343"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=33654"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=33654"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=33654"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}