Le probl\u00e8me non \u00e9vident des conteneurs Docker: Vuln\u00e9rabilit\u00e9s cach\u00e9es<\/p>\n
Qu’est-ce que “Enfer endensky” (DH)?<\/p>\n
“Dependency Hell” (DH) est un terme indiquant un probl\u00e8me qui se pose lors de la gestion des d\u00e9pendances dans le logiciel. Ses principales raisons sont dans le conflit de versions, les difficult\u00e9s d’int\u00e9grer diverses biblioth\u00e8ques et la n\u00e9cessit\u00e9 de maintenir la compatibilit\u00e9 entre eux. DH comprend les aspects suivants:<\/p>\n
– Conflits de versions: les projets n\u00e9cessitent souvent des versions sp\u00e9cifiques de biblioth\u00e8ques, et les diff\u00e9rents composants peuvent d\u00e9pendre de versions incompatibles de la m\u00eame biblioth\u00e8que.
\n– Difficult\u00e9s de mises \u00e0 jour: la mise \u00e0 jour des d\u00e9pendances peut entra\u00eener des erreurs inattendues ou une rupture de compatibilit\u00e9, m\u00eame si une nouvelle version contient des corrections ou des am\u00e9liorations.
\n– L’environnement: Le d\u00e9sir d’isoler et de stabiliser l’environnement a conduit \u00e0 l’utilisation d’environnements virtuels, de conteneurisation et d’autres solutions visant \u00e0 simplifier la gestion de la d\u00e9pendance.<\/p>\n
Il est important de noter que bien que l’\u00e9limination des vuln\u00e9rabilit\u00e9s soit l’une des raisons de la publication des versions mises \u00e0 jour des biblioth\u00e8ques, ce n’est pas la principale force motrice de DH. Le principal probl\u00e8me est que chaque changement – qu’il s’agisse de corriger les bogues, d’ajouter une nouvelle fonctionnalit\u00e9 ou d’\u00e9liminer la vuln\u00e9rabilit\u00e9 – peut provoquer une cha\u00eene de d\u00e9pendances qui compliquent le d\u00e9veloppement stable et le support de l’application.<\/p>\n
Comment la lutte contre DH a-t-elle conduit \u00e0 la cr\u00e9ation de Docker?<\/p>\n
Dans une tentative de r\u00e9soudre les probl\u00e8mes DH, les d\u00e9veloppeurs cherchaient des moyens de cr\u00e9er un environnement isol\u00e9 et stable pour les applications. Docker a \u00e9t\u00e9 une r\u00e9ponse \u00e0 ce d\u00e9fi. La conteneurisation permet:<\/p>\n
– Isoler l’environnement: toutes les d\u00e9pendances et biblioth\u00e8ques sont emball\u00e9es avec l’application, qui garantit un travail stable partout o\u00f9 Docker est install\u00e9.
\n– Simplifier le d\u00e9ploiement: le d\u00e9veloppeur peut une fois configurer l’environnement et l’utiliser pour se d\u00e9ployer sur des serveurs sans param\u00e8tres suppl\u00e9mentaires.
\n– Minimiser les conflits: \u00c9tant donn\u00e9 que chaque application fonctionne dans son propre conteneur, le risque de conflits entre les d\u00e9pendances de divers projets est consid\u00e9rablement r\u00e9duit.<\/p>\n
Ainsi, Docker a propos\u00e9 une solution efficace pour lutter contre le probl\u00e8me DH, permettant aux d\u00e9veloppeurs de se concentrer sur la logique de l’application et non sur les difficult\u00e9s de configuration de l’environnement.<\/p>\n
Le probl\u00e8me des d\u00e9pendances obsol\u00e8tes dans Docker<\/p>\n
Malgr\u00e9 tous les avantages de Docker, une nouvelle direction des probl\u00e8mes est apparue – l’obsolescence des d\u00e9pendances. Cela se produit pour plusieurs raisons:<\/p>\n
1. Le conteneur se fige dans le temps<\/p>\n
Lors de la cr\u00e9ation d’une image Docker, un certain \u00e9tat de tous les packages et biblioth\u00e8ques est corrig\u00e9. M\u00eame si apr\u00e8s assemblage dans l’image de base (par exemple, `Ubuntu: 04.20,` Python: 3.9`, `Node: 18-Alpine`), des vuln\u00e9rabilit\u00e9s sont trouv\u00e9es ou de nouvelles versions sont produites, le conteneur continue de fonctionner avec les versions initialement install\u00e9es. Si l’image ne doit pas \u00eatre envoy\u00e9e, l’application peut fonctionner avec des composants obsol\u00e8tes et potentiellement vuln\u00e9rables pendant des ann\u00e9es.<\/p>\n
2. Manque de mises \u00e0 jour automatiques<\/p>\n
Contrairement aux serveurs traditionnels, o\u00f9 vous pouvez configurer la mise \u00e0 jour des packages automatiques via les gestionnaires syst\u00e8me (par exemple, `APT Updgrade` ou\u00ab NPM Update \u00bb), les conteneurs ne sont pas mis \u00e0 jour automatiquement. La mise \u00e0 jour ne se produit que lors de l’\u00e9lection de l’image, qui n\u00e9cessite une discipline et un contr\u00f4le r\u00e9gulier.<\/p>\n
3. D\u00e9pendances fixes<\/p>\n
Pour garantir la stabilit\u00e9, les d\u00e9veloppeurs corrigent souvent la version des d\u00e9pendances dans des fichiers comme `redirements.txt` ou\u00ab package.json`. Cette approche emp\u00eache les changements inattendus, mais g\u00e8le en m\u00eame temps l’\u00e9tat des d\u00e9pendances, m\u00eame si des erreurs ou une vuln\u00e9rabilit\u00e9 sont d\u00e9tect\u00e9es par la suite.<\/p>\n
4. en utilisant des images de base obsol\u00e8tes<\/p>\n
Les images de base s\u00e9lectionn\u00e9es pour les conteneurs peuvent \u00e9galement \u00eatre obsol\u00e8tes au fil du temps. Par exemple, si l’application est construite sur l’image de \u00abNode: 16\u00bb, et que les d\u00e9veloppeurs sont d\u00e9j\u00e0 pass\u00e9s au \u00abn\u0153ud: 18\u00bb en raison d’am\u00e9liorations et de corrections, votre environnement restera avec une version obsol\u00e8te, m\u00eame si tout fonctionne correctement \u00e0 l’int\u00e9rieur du code.<\/p>\n
Comment \u00e9viter les probl\u00e8mes de d\u00e9pendances obsol\u00e8tes?<\/p>\n
Inclure des inspections r\u00e9guli\u00e8res pour les d\u00e9pendances et vuln\u00e9rabilit\u00e9s obsol\u00e8tes dans le processus CI \/ CD:<\/p>\n
– pour Python:<\/p>\n
pip list --outdated\n<\/code><\/pre>\n<\/div>\n– pour node.js:<\/p>\n
\nnpm outdated\n<\/code><\/pre>\n<\/div>\n– Utilisez des outils pour analyser les vuln\u00e9rabilit\u00e9s, par exemple, \u00abTRIVY\u00bb:<\/p>\n
\ntrivy image my-app\n<\/code><\/pre>\n<\/div>\nSurveillez les mises \u00e0 jour des images de base<\/p>\n
Abonnez-vous aux mises \u00e0 jour des images de base dans Docker Hub ou des r\u00e9f\u00e9rentiels correspondants sur GitHub afin de d\u00e9couvrir en temps opportun les corrections et les mises \u00e0 jour critiques.<\/p>\n
Conclusion<\/p>\n
Le probl\u00e8me de l’enfer de d\u00e9pendance est survenu non seulement en raison de la n\u00e9cessit\u00e9 d’\u00e9liminer la vuln\u00e9rabilit\u00e9, mais aussi en raison de difficult\u00e9s \u00e0 g\u00e9rer et \u00e0 mettre \u00e0 jour les d\u00e9pendances. Docker a propos\u00e9 une solution efficace pour lutter contre la DH, fournissant un environnement isol\u00e9 et stable pour les applications. Cependant, avec l’av\u00e8nement de la conteneurisation, une nouvelle t\u00e2che est survenue – la n\u00e9cessit\u00e9 d’un renouvellement r\u00e9gulier des images afin d’emp\u00eacher l’obsolescence des d\u00e9pendances et l’apparition d’une vuln\u00e9rabilit\u00e9 critique.<\/p>\n
Il est important pour les sp\u00e9cialistes modernes de DevOps non seulement de r\u00e9soudre les probl\u00e8mes de conflits de versions, mais aussi d’introduire r\u00e9guli\u00e8rement et automatis\u00e9 les pratiques de contr\u00f4le pour la pertinence des d\u00e9pendances afin que les conteneurs restent s\u00fbrs et efficaces.<\/p>\n","protected":false},"excerpt":{"rendered":"
Le probl\u00e8me non \u00e9vident des conteneurs Docker: Vuln\u00e9rabilit\u00e9s cach\u00e9es Qu’est-ce que “Enfer endensky” (DH)? “Dependency Hell” (DH) est un terme indiquant un probl\u00e8me qui se pose lors de la gestion des d\u00e9pendances dans le logiciel. Ses principales raisons sont dans le conflit de versions, les difficult\u00e9s d’int\u00e9grer diverses biblioth\u00e8ques et la n\u00e9cessit\u00e9 de maintenir laContinue reading “Le probl\u00e8me non \u00e9vident des conteneurs Docker: Vuln\u00e9rabilit\u00e9s cach\u00e9es”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[49],"tags":[],"class_list":["post-4143","post","type-post","status-publish","format-standard","hentry","category-blog","entry"],"translation":{"provider":"WPGlobus","version":"3.0.2","language":"fr","enabled_languages":["en","ru","zh","de","fr","ja","pt","hi"],"languages":{"en":{"title":true,"content":true,"excerpt":false},"ru":{"title":true,"content":true,"excerpt":false},"zh":{"title":true,"content":true,"excerpt":false},"de":{"title":true,"content":true,"excerpt":false},"fr":{"title":true,"content":true,"excerpt":false},"ja":{"title":true,"content":true,"excerpt":false},"pt":{"title":true,"content":true,"excerpt":false},"hi":{"title":false,"content":false,"excerpt":false}}},"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/4143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=4143"}],"version-history":[{"count":2,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/4143\/revisions"}],"predecessor-version":[{"id":4145,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/4143\/revisions\/4145"}],"wp:attachment":[{"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=4143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=4143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/demensdeum.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=4143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}