{"id":82244,"date":"2020-05-20T13:42:45","date_gmt":"2020-05-20T11:42:45","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov"},"modified":"2020-05-20T13:42:45","modified_gmt":"2020-05-20T11:42:45","slug":"luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","title":{"rendered":"Meilleures pratiques Kubernetes. Cr\u00e9ation de petits conteneurs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Meilleures
\n
\nLa premi\u00e8re \u00e9tape du d\u00e9ploiement dans Kubernetes consiste \u00e0 placer votre application dans un conteneur. Dans cette s\u00e9rie, nous allons examiner comment cr\u00e9er une image de conteneur petite et s\u00e9curis\u00e9e.
\nAvec Docker, cr\u00e9er des images de conteneurs n'a jamais \u00e9t\u00e9 aussi simple. Sp\u00e9cifiez une image de base, ajoutez vos modifications et cr\u00e9ez le conteneur.<\/p>\n

\"Meilleures
\n
\nBien que cette m\u00e9thode soit id\u00e9ale pour commencer, utiliser des images de base par d\u00e9faut peut entra\u00eener des probl\u00e8mes de s\u00e9curit\u00e9 avec de grandes images remplies de vuln\u00e9rabilit\u00e9s.<\/a><\/noindex><\/p>\n

De plus, la plupart des images Docker utilisent Debian ou Ubuntu comme image de base, ce qui offre une excellente compatibilit\u00e9 et une adaptation facile (le fichier Docker ne n\u00e9cessite que deux lignes de code), mais ces images de base peuvent ajouter des centaines de m\u00e9gaoctets de surcharge \u00e0 votre conteneur. Par exemple, un simple fichier d'application node.js Go \u00ab hello-world \u00bb p\u00e8se environ 700 m\u00e9gaoctets, alors que la taille r\u00e9elle de votre application n'est que de quelques m\u00e9gaoctets.<\/p>\n

\"Meilleures
\n
\nAinsi, toute cette surcharge suppl\u00e9mentaire est un gaspillage d'espace num\u00e9rique et un excellent refuge pour les vuln\u00e9rabilit\u00e9s et les erreurs de s\u00e9curit\u00e9. Par cons\u00e9quent, examinons deux fa\u00e7ons de r\u00e9duire la taille de l'image du conteneur. <\/p>\n

La premi\u00e8re consiste \u00e0 utiliser des images de base de petite taille, la seconde \u00e0 appliquer le mod\u00e8le de conception Builder Pattern. L'utilisation d'images de base plus petites est probablement le moyen le plus simple de r\u00e9duire la taille de votre conteneur. Il est probable que le langage ou la pile que vous utilisez fournisse une image d'application originale beaucoup plus petite que l'image par d\u00e9faut. Jetons un coup d'\u0153il \u00e0 notre conteneur node.js. <\/p>\n

\"Meilleures
\n
\nPar d\u00e9faut, l'image de base Docker node:8 p\u00e8se 670 Mo, tandis que l'image node:8-alpine ne p\u00e8se que 65 Mo, soit dix fois moins. En utilisant une image de base Alpine plus petite, vous r\u00e9duisez consid\u00e9rablement la taille de votre conteneur. Alpine est une distribution Linux l\u00e9g\u00e8re et petite, tr\u00e8s appr\u00e9ci\u00e9e des utilisateurs de Docker, car elle est compatible avec de nombreuses applications tout en maintenant la taille des conteneurs \u00e0 un minimum. Contrairement \u00e0 l'image Docker standard \u00ab node \u00bb, \u00ab node:alpine \u00bb supprime de nombreux fichiers et programmes auxiliaires, ne conservant que ceux n\u00e9cessaires au fonctionnement de votre application.<\/p>\n

Pour passer \u00e0 une image de base plus petite, mettez simplement \u00e0 jour le fichier Docker pour commencer \u00e0 travailler avec la nouvelle image de base :<\/p>\n

\"Meilleures
\n
\nD\u00e9sormais, contrairement \u00e0 l'ancienne image onbuild, vous devez copier votre code dans le conteneur et installer toutes les d\u00e9pendances. Dans le nouveau fichier Docker, le conteneur commence avec l'image node:alpine, cr\u00e9e ensuite un r\u00e9pertoire pour le code, installe les d\u00e9pendances \u00e0 l'aide du gestionnaire de paquets NPM et, enfin, ex\u00e9cute server.js.<\/p>\n

\"Meilleures
\n
\nCet aggiornamento permet d'obtenir un conteneur de taille dix fois plus petite. Si votre langage de programmation ou votre stack ne pr\u00e9sente pas de fonction permettant de r\u00e9duire l'image de base, utilisez Alpine Linux. Cela vous donnera \u00e9galement la possibilit\u00e9 de g\u00e9rer compl\u00e8tement le contenu du conteneur. Utiliser des images de base de petite taille est un excellent moyen de cr\u00e9er rapidement de petits conteneurs. Mais vous pouvez obtenir une r\u00e9duction encore plus importante en utilisant le pattern Builder.<\/p>\n

\"Meilleures
\n
\nDans les langages interpr\u00e9t\u00e9s, le code source est d'abord pass\u00e9 \u00e0 l'interpr\u00e9teur, puis ex\u00e9cut\u00e9 directement. Dans les langages compil\u00e9s, le code source est d'abord transform\u00e9 en code compil\u00e9. Par cons\u00e9quent, la compilation utilise souvent des outils qui ne sont en r\u00e9alit\u00e9 pas n\u00e9cessaires \u00e0 l'ex\u00e9cution du code. Cela signifie que vous pouvez compl\u00e8tement \u00e9liminer ces outils du conteneur final. Cela peut \u00eatre r\u00e9alis\u00e9 en utilisant le pattern Builder.<\/p>\n

\"Meilleures
\n
\nLe code est g\u00e9n\u00e9r\u00e9 dans le premier conteneur et est compil\u00e9. Ensuite, le code compil\u00e9 est emball\u00e9 dans le conteneur final sans les compilateurs et les outils n\u00e9cessaires pour la compilation de ce code. Passons cet processus \u00e0 une application Go. Tout d'abord, nous allons passer de l'image onbuild \u00e0 Alpine Linux.<\/p>\n

\"Meilleures
\n
\nDans le nouveau fichier Docker, le conteneur commence par l'image golang:alpine. Ensuite, il cr\u00e9e un r\u00e9pertoire pour le code, y copie le code source, compile celui-ci et ex\u00e9cute l'application. Ce conteneur est beaucoup plus petit que le conteneur onbuild, mais il contient encore le compilateur et d'autres outils Go, qui ne nous sont en r\u00e9alit\u00e9 pas n\u00e9cessaires. Par cons\u00e9quent, extrayons simplement le programme compil\u00e9 et emballons-le dans notre propre conteneur.<\/p>\n

\"Meilleures
\n
\nVous pouvez remarquer quelque chose d'\u00e9trange dans ce fichier Docker : il contient deux lignes FROM. La premi\u00e8re section de 4 lignes ressemble exactement \u00e0 l'ancien fichier Docker, sauf qu'elle utilise le mot cl\u00e9 AS pour nommer cette \u00e9tape. Dans la section suivante, il y a une nouvelle ligne FROM, permettant de d\u00e9marrer une nouvelle image, en utilisant Raw alpine comme image de base au lieu de golang:alpine.<\/p>\n

Raw Alpine Linux n'a pas de certificats SSL install\u00e9s, ce qui provoquera l'\u00e9chec de la plupart des appels API via le protocole HTTPS, donc installons quelques certificats racines CA.<\/p>\n

Et maintenant, la partie int\u00e9ressante : pour copier le code compil\u00e9 du premier conteneur vers le second, on peut simplement utiliser la commande COPY, situ\u00e9e \u00e0 la 5\u00e8me ligne de la deuxi\u00e8me section. Elle ne copiera qu'un fichier d'application et ne touchera pas aux outils Go. Le nouveau fichier Docker multi-\u00e9tapes contiendra une image de conteneur d'\u00e0 peine 12 m\u00e9gaoctets alors que l'image de conteneur d'origine faisait 700 m\u00e9gaoctets, ce qui repr\u00e9sente une grande diff\u00e9rence !
\nAinsi, l'utilisation de petites images de base et du mod\u00e8le Builder sont d'excellents moyens de cr\u00e9er des conteneurs beaucoup plus petits sans avoir \u00e0 faire beaucoup de travail.
\nIl est possible qu'en fonction de la pile de l'application, il existe d'autres fa\u00e7ons de r\u00e9duire la taille de l'image et du conteneur, mais les petits conteneurs ont-ils vraiment un avantage mesurable ? Examinons deux aspects o\u00f9 les petits conteneurs sont extr\u00eamement efficaces \u2013 les performances et la s\u00e9curit\u00e9.<\/p>\n

Pour \u00e9valuer l'augmentation des performances, examinons la dur\u00e9e du processus de cr\u00e9ation d'un conteneur, de son insertion dans un registre (push) et de son extraction ult\u00e9rieure (pull). Vous pouvez voir qu'un conteneur de plus petite taille a un avantage ind\u00e9niable par rapport \u00e0 un conteneur de plus grande taille.<\/p>\n

\"Meilleures
\n
\nDocker va mettre en cache les couches, donc les constructions suivantes se feront tr\u00e8s rapidement. Cependant, dans de nombreux syst\u00e8mes CI utilis\u00e9s pour construire et tester des conteneurs, les couches ne sont pas mises en cache, ce qui repr\u00e9sente donc un gain de temps significatif. Comme vous pouvez le voir, le temps de construction d'un conteneur de grande taille, en fonction de la puissance de votre machine, varie de 34 \u00e0 54 secondes, tandis qu'avec un conteneur r\u00e9duit gr\u00e2ce au Builder Pattern, il est compris entre 23 et 28 secondes. Pour ce type d'op\u00e9rations, le gain de performance sera de 40 \u00e0 50 %. Donc, pensez simplement combien de fois vous cr\u00e9ez et testez votre code.<\/p>\n

Une fois le conteneur construit, vous devez ins\u00e9rer son image (push container image) dans le registre de conteneurs afin de l'utiliser ensuite dans votre cluster Kubernetes. Je recommande d'utiliser le registre de conteneurs de Google.<\/p>\n

\"Meilleures
\n
\nAvec le Google Container Registry (GCR), vous ne payez que pour le stockage \u00ab brut \u00bb et le r\u00e9seau, et aucun frais suppl\u00e9mentaire n'est factur\u00e9 pour la gestion des conteneurs. C'est confidentiel, s\u00e9curis\u00e9 et tr\u00e8s rapide. GCR utilise de nombreuses astuces pour acc\u00e9l\u00e9rer l'op\u00e9ration pull. Comme vous pouvez le voir, l'insertion de l'image du conteneur Docker Container Image en utilisant go:onbuild, selon la performance de l'ordinateur, prendra entre 15 et 48 secondes, tandis que la m\u00eame op\u00e9ration avec un conteneur de plus petite taille prendra entre 14 et 16 secondes, et pour les machines moins performantes, l'avantage en termes de vitesse augmente de trois fois. Pour les grandes machines, le temps est \u00e0 peu pr\u00e8s le m\u00eame, car GCR utilise un cache global pour la base d'images partag\u00e9e, ce qui signifie que vous n'avez pas besoin de les t\u00e9l\u00e9charger du tout. Dans un ordinateur \u00e0 faible puissance, le CPU est le goulot d'\u00e9tranglement, donc l'avantage d'utiliser des conteneurs r\u00e9duits est ici beaucoup plus perceptible.<\/p>\n

Si vous utilisez GCR, je vous recommande vivement d'appliquer Google Container Builder (GCB) comme partie de votre syst\u00e8me de construction.<\/p>\n

\"Meilleures
\n
\nComme vous pouvez le voir, son utilisation permet d'obtenir des r\u00e9sultats bien meilleurs dans la r\u00e9duction de la dur\u00e9e de l'op\u00e9ration Build+Push, m\u00eame par rapport \u00e0 une machine performante - dans ce cas, le processus de construction et d'envoi de conteneurs vers l'h\u00f4te est presque deux fois plus rapide. De plus, vous b\u00e9n\u00e9ficiez chaque jour de 120 minutes de construction gratuites, ce qui satisfait dans la plupart des cas les besoins en cr\u00e9ation de conteneurs. <\/p>\n

Nous arrivons maintenant \u00e0 la m\u00e9trique de performance la plus importante - la vitesse d'extraction, ou de t\u00e9l\u00e9chargement des conteneurs Pull. Et si le temps pass\u00e9 sur l'op\u00e9ration push ne vous pr\u00e9occupe pas trop, la dur\u00e9e du processus pull a un impact consid\u00e9rable sur la performance globale du syst\u00e8me. Supposons que vous ayez un cluster de trois n\u0153uds et qu'il y ait une panne sur l'un d'entre eux. Si vous utilisez un syst\u00e8me de gestion tel que Google Kubernetes Engine, il remplacera automatiquement le n\u0153ud d\u00e9faillant par un nouveau. Cependant, ce nouveau n\u0153ud sera compl\u00e8tement vide, et vous devrez y d\u00e9placer tous vos conteneurs pour qu'il commence \u00e0 fonctionner. Si l'op\u00e9ration pull prend beaucoup de temps, alors durant ce temps, votre cluster fonctionnera avec une performance r\u00e9duite.<\/p>\n

Il existe de nombreux cas o\u00f9 cela peut se produire : l'ajout d'un nouveau n\u0153ud au cluster, la mise \u00e0 jour des n\u0153uds ou m\u00eame le passage \u00e0 un nouveau conteneur pour le d\u00e9ploiement. Ainsi, minimiser le temps d'extraction pull devient un facteur cl\u00e9. Il est ind\u00e9niable qu'un petit conteneur se t\u00e9l\u00e9charge beaucoup plus rapidement qu'un grand. Si vous utilisez plusieurs conteneurs dans un cluster Kubernetes, l'\u00e9conomie de temps peut \u00eatre tr\u00e8s significative.<\/p>\n

\"Meilleures
\n
\nRegardez la comparaison suivante : l'op\u00e9ration pull avec de petits conteneurs prend de 4 \u00e0 9 fois moins de temps en fonction de la puissance de la machine, qu'une op\u00e9ration similaire utilisant go:onbuild. L'utilisation d'images conteneurs de base de petite taille acc\u00e9l\u00e8re consid\u00e9rablement le temps et la vitesse auxquels de nouveaux n\u0153uds Kubernetes peuvent \u00eatre d\u00e9ploy\u00e9s et mis en ligne.<\/p>\n

Examinons la question de la s\u00e9curit\u00e9. On consid\u00e8re que les conteneurs plus petits sont beaucoup plus s\u00fbrs que les grands, car ils ont une surface d'attaque plus r\u00e9duite. Est-ce vraiment le cas ? L'une des fonctionnalit\u00e9s les plus utiles de Google Container Registry est la possibilit\u00e9 de scanner automatiquement vos conteneurs \u00e0 la recherche de vuln\u00e9rabilit\u00e9s. Il y a quelques mois, j'ai cr\u00e9\u00e9 des conteneurs onbuild et multistades, alors voyons s'il y a des failles \u00e0 cet \u00e9gard. <\/p>\n

\"Meilleures
\n
\nLe r\u00e9sultat est impressionnant : seulement 3 vuln\u00e9rabilit\u00e9s mod\u00e9r\u00e9es ont \u00e9t\u00e9 d\u00e9tect\u00e9es dans le petit conteneur, contre 16 critiques et 376 autres dans le grand conteneur. En examinant le contenu du grand conteneur, il est \u00e9vident que la plupart des probl\u00e8mes de s\u00e9curit\u00e9 n'ont rien \u00e0 voir avec notre application mais sont li\u00e9s \u00e0 des programmes que nous n'utilisons m\u00eame pas. C'est donc cela que les gens entendent par grande surface d'attaque. <\/p>\n

\"Meilleures
\n
\nLa conclusion est claire : cr\u00e9ez des conteneurs de petite taille, car ils offrent de r\u00e9els avantages en termes de performance et de s\u00e9curit\u00e9 pour votre syst\u00e8me. <\/p>\n

Meilleures pratiques Kubernetes. Organisation de Kubernetes avec des espaces de noms<\/a><\/noindex><\/p>\n

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

Un peu de publicit\u00e9 \ud83d\ude42<\/h3>\n

\nMerci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu int\u00e9ressant ? Soutenez-nous en passants une commande ou en nous recommandant \u00e0 des amis, VPS cloud pour d\u00e9veloppeurs \u00e0 partir de 4,99 $<\/a><\/noindex>, un \u00e9quivalent unique des serveurs d'entr\u00e9e de gamme, con\u00e7u pour vous :<\/b> Toute la v\u00e9rit\u00e9 sur le VPS (KVM) E5-2697 v3 (6 c\u0153urs) 10 Go DDR4 480 Go SSD 1 Gbps \u00e0 partir de 19 $ ou comment bien diviser un serveur ?<\/a><\/noindex> (options disponibles avec RAID1 et RAID10, jusqu'\u00e0 24 c\u0153urs et jusqu'\u00e0 40 Go DDR4).<\/p>\n

Dell R730xd deux fois moins cher dans le data center Equinix Tier IV \u00e0 Amsterdam ?<\/b> Uniquement chez nous 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To \u00e0 partir de 199 $<\/a><\/noindex> aux Pays-Bas ! Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To \u2014 \u00e0 partir de 99 $ !<\/b><\/b> Lisez sur Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 co\u00fbtant 9000 euros pour des clopinettes ?<\/a><\/noindex>
\n
Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041f\u0435\u0440\u0432\u044b\u0439 \u0448\u0430\u0433 \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0432 Kubernetes \u2013 \u044d\u0442\u043e \u0440\u0430\u0437\u043c\u0435\u0449\u0435\u043d\u0438\u0435 \u0432\u0430\u0448\u0435\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0435. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u043e\u0431\u0440\u0430\u0437 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0433\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f Docker, \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u0435\u0449\u0435 \u043d\u0435 \u0431\u044b\u043b\u043e \u043d\u0430\u0441\u0442\u043e\u043b\u044c\u043a\u043e \u043f\u0440\u043e\u0441\u0442\u044b\u043c. \u0423\u043a\u0430\u0436\u0438\u0442\u0435 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u043e\u0431\u0440\u0430\u0437, \u0434\u043e\u0431\u0430\u0432\u044c\u0442\u0435 \u0441\u0432\u043e\u0438 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438 \u0441\u043e\u0437\u0434\u0430\u0439\u0442\u0435 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440. \u041d\u0435\u0441\u043c\u043e\u0442\u0440\u044f \u043d\u0430 \u0442\u043e, \u0447\u0442\u043e \u0434\u0430\u043d\u043d\u044b\u0439 \u043f\u0440\u0438\u0435\u043c \u043e\u0442\u043b\u0438\u0447\u043d\u043e \u043f\u043e\u0434\u0445\u043e\u0434\u0438\u0442 \u0434\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":82245,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-82244","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\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\udd47Meilleures pratiques Kubernetes. Cr\u00e9ation de petits conteneurs | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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\u041b\u0443\u0447\u0448\u0438\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 Kubernetes. \u0421\u043e\u0437\u0434\u0430\u043d\u0438\u0435 \u043d\u0435\u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/luchshie-praktiki-kubernetes-sozdanie-nebolshih-kontejnerov","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":"2020-05-20T11:42:45+00:00","article:modified_time":"2020-05-20T11:42:45+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"82244","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:41:28","updated":"2022-09-28 11:52:01","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\/82244","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=82244"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/82244\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/82245"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=82244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=82244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=82244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}