{"id":81173,"date":"2020-05-11T13:42:51","date_gmt":"2020-05-11T11:42:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/production-ready-images-for-k8s"},"modified":"2020-05-11T13:42:51","modified_gmt":"2020-05-11T11:42:51","slug":"production-ready-images-for-k8s","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/production-ready-images-for-k8s","title":{"rendered":"Images pr\u00eates pour la production pour K8s","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cette histoire porte sur notre utilisation des conteneurs dans un environnement de production, en particulier sous Kubernetes. Cet article est d\u00e9di\u00e9 \u00e0 la collecte de m\u00e9triques et de journaux \u00e0 partir des conteneurs, ainsi qu'\u00e0 la cr\u00e9ation d'images.<\/p>\n

\"Images
\n<\/a><\/noindex>
\nNous sommes de la soci\u00e9t\u00e9 fintech Exness, qui d\u00e9veloppe des services de trading en ligne et des produits fintech pour le B2B et le B2C. Dans notre R&D, il y a plusieurs \u00e9quipes diff\u00e9rentes, et notre d\u00e9partement de d\u00e9veloppement compte plus de 100 employ\u00e9s.<\/p>\n

Nous repr\u00e9sentons l'\u00e9quipe responsable de la plateforme permettant \u00e0 nos d\u00e9veloppeurs de collecter et de d\u00e9ployer du code. En particulier, nous sommes charg\u00e9s de la collecte, du stockage et de la fourniture de m\u00e9triques, de journaux, et d'\u00e9v\u00e9nements provenant des applications. Actuellement, nous g\u00e9rons environ trois mille conteneurs Docker dans un environnement de production, maintenons notre stockage big data de 50 To et fournissons des solutions architecturales construites autour de notre infrastructure : Kubernetes, Rancher et divers fournisseurs de cloud publics.\u00a0<\/p>\n

Notre motivation<\/h1>\n

\nQu'est-ce qui br\u00fble ? Personne ne peut r\u00e9pondre. O\u00f9 est le foyer ? Difficile \u00e0 comprendre. Quand cela a-t-il commenc\u00e9 ? On peut le d\u00e9terminer, mais pas tout de suite.\u00a0<\/p>\n

\"Images
\n
\nPourquoi certains conteneurs sont-ils \u00e0 l'arr\u00eat tandis que d'autres sont en panne ? Quel conteneur en est la cause ? En dehors, les conteneurs sont identiques, mais chacun a son propre Neo \u00e0 l'int\u00e9rieur.<\/p>\n

\"Images
\n
\nNos d\u00e9veloppeurs sont des gens comp\u00e9tents. Ils cr\u00e9ent de bons services qui rapportent de l'argent \u00e0 l'entreprise. Mais il y a des \u00e9checs, lorsque les conteneurs avec les applications sont en d\u00e9sordre. Un conteneur consomme trop de CPU, un autre de la bande passante, un troisi\u00e8me des op\u00e9rations d'entr\u00e9e-sortie, et un quatri\u00e8me fait quelque chose d'incompr\u00e9hensible avec les sockets. Tout cela s'effondre et le navire coule.\u00a0<\/p>\n

Agents<\/h1>\n

\nPour comprendre ce qui se passe \u00e0 l'int\u00e9rieur, nous avons d\u00e9cid\u00e9 d'installer des agents directement dans les conteneurs.<\/p>\n

\"Images
\n
\nCes agents sont des programmes d'alerte qui maintiennent les conteneurs dans un \u00e9tat tel qu'ils ne se cassent pas les uns les autres. Les agents sont standardis\u00e9s, et cela permet de normaliser l'approche de maintenance des conteneurs.\u00a0<\/p>\n

Dans notre cas, les agents doivent fournir des journaux dans un format standard, \u00e9tiquet\u00e9s et avec un throttling. Ils doivent \u00e9galement nous fournir des m\u00e9triques normalis\u00e9es, extensibles du point de vue des applications commerciales.<\/p>\n

Sous le terme agents, on entend \u00e9galement des utilitaires pour l'exploitation et la maintenance, capables de fonctionner dans diff\u00e9rents syst\u00e8mes d'orchestration, prenant en charge diff\u00e9rentes images (Debian, Alpine, Centos, etc.).<\/p>\n

Enfin, les agents doivent maintenir un CI\/CD simple, incluant des fichiers Docker. Sinon, le navire se brisera, car les conteneurs commenceront \u00e0 \u00eatre livr\u00e9s sur des \u00ab rails tordus \u00bb.<\/p>\n

Le processus de construction et la structure de l'image cible<\/h1>\n

\nPour que tout soit standardis\u00e9 et g\u00e9rable, il est n\u00e9cessaire de suivre un certain processus standard de construction. C'est pourquoi nous avons d\u00e9cid\u00e9 de construire des conteneurs avec des conteneurs \u2014 une sorte de r\u00e9cursion.<\/p>\n

\"Images
\n
\nIci, les conteneurs sont repr\u00e9sent\u00e9s par des contours solides. En m\u00eame temps, nous avons d\u00e9cid\u00e9 d'y mettre des distributions, pour que \u00ab la vie ne soit pas trop facile \u00bb. Nous expliquerons pourquoi cela a \u00e9t\u00e9 fait ci-dessous.
\n\u00a0
\nEn r\u00e9sultat, nous avons obtenu un outil de construction \u2014 un conteneur d'une version sp\u00e9cifique, qui fait r\u00e9f\u00e9rence \u00e0 des versions sp\u00e9cifiques de distributions et de scripts.<\/p>\n

Comment l'utilisons-nous ? Nous avons un Docker Hub, o\u00f9 se trouve le conteneur. Nous le r\u00e9fl\u00e9chissons dans notre syst\u00e8me pour nous d\u00e9barrasser des d\u00e9pendances externes. Cela a abouti \u00e0 un conteneur marqu\u00e9 en jaune. Nous cr\u00e9ons un mod\u00e8le pour installer dans le conteneur toutes les distributions et scripts n\u00e9cessaires. Ensuite, nous construisons une image pr\u00eate \u00e0 l'exploitation : les d\u00e9veloppeurs y ajoutent leur code et certaines de leurs d\u00e9pendances sp\u00e9cifiques.\u00a0<\/p>\n

Quels sont les avantages de cette approche ?\u00a0<\/p>\n