Docker容器的非明显问题：隐藏的漏洞
什么是“ Dectionensky Hell”（DH）？
“依赖性地狱”（DH）是一个术语，表示在管理软件中的依赖项时出现的问题。它的主要原因是版本的冲突，整合各种库的困难以及它们之间保持兼容性的需求。 DH包括以下方面：
– 版本的冲突：项目通常需要特定版本的库，并且不同的组件可能取决于同一库的不兼容版本。
– 更新困难：更新依赖项可能会导致意外错误或兼容性故障，即使新版本包含更正或改进。
– 周围环境：隔离和稳定环境的愿望导致使用虚拟环境，容器化和其他旨在简化依赖管理的解决方案。
重要的是要注意，尽管消除漏洞是发布库更新版本的原因之一，但它不是DH的主要驱动力。主要的问题是，每种更改（无论是纠正错误，添加新功能还是消除漏洞）都可能导致一系列依赖关系，使应用程序的稳定开发和支持复杂化。
与DH的战斗是如何导致Docker创建的？
为了解决DH的问题，开发人员正在寻找为应用程序创建孤立稳定的环境的方法。 Docker是对这一挑战的回应。容器化允许：
– 隔离环境：所有依赖关系和库都与应用程序一起包装，这保证了安装Docker的任何地方稳定的工作。
– 简化部署：开发人员可以一旦配置环境并使用它在没有其他设置的情况下将其部署在任何服务器上。
– 减少冲突：由于每个应用程序都在其自身的容器中起作用，因此各个项目依赖关系之间发生冲突的风险大大降低了。
因此，Docker提出了一种有效解决DH问题的有效解决方案，使开发人员可以专注于应用程序的逻辑，而不是设置环境的困难。
Docker中过时的依赖性问题
尽管Docker具有所有优势，但出现了一个新的问题方向 – 成瘾的过时。发生这种情况是有几个原因：
1。容器及时冻结
创建Docker映像时，修复了所有软件包和库的某个状态。即使在基本图像中组装后（例如，`ubuntu：04.20，`python：3.9`，`node：18-alpine’），也会发现漏洞或产生新版本，该容器仍继续与最初安装的版本一起使用。如果不发送图像，该应用程序可以多年来与过时且潜在的脆弱组件一起使用。
2。缺乏自动更新
与传统服务器不同，您可以通过系统管理器配置自动软件包更新（例如，“ APT升级”或“ NPM Update”），容器不会自动更新。更新仅在重新选择图像时才发生，这需要纪律和正常控制。
3。固定依赖
为了确保稳定性，开发人员经常在“redirements.txt`或’poffage.json”等文件中修复依赖项的版本。这种方法可以防止意外变化，但同时冻结了依赖状态，即使随后在其中检测到错误或漏洞。
4。使用过时的基本图像
随着时间的推移，选择用于容器的基本图像也可以过时。例如，如果该应用程序是基于`node：16`的图像构建的，并且由于改进和校正，开发人员已经切换到“节点：18”，那么即使在代码中一切正常运行，您的环境也将保留在过时的版本中。
如何避免过时的依赖性问题？
在CI/CD过程中包括定期检查过时的依赖性和漏洞：
– 对于Python：
pip list --outdated
– for node.js：
npm outdated
– 使用工具来分析漏洞，例如“trivy”：
trivy image my-app
监视基本图像的更新
订阅Docker Hub中基本图像的更新或GitHub上的相应存储库，以便及时了解关键更正和更新。
结论
依赖地狱的问题不仅是因为需要消除脆弱性，而且由于难以管理和更新依赖关系。 Docker提出了一种有效的解决方案来对抗DH，为应用提供了孤立且稳定的环境。但是，随着容器化的出现，出现了一项新任务 – 需要定期更新图像以防止依赖性过时和关键脆弱性的出现。
对于现代DevOps的专家而言，重要的是，不仅要解决版本冲突的问题，而且要定期和自动化的控制实践，以使成瘾的相关性，以便容器保持安全有效。
