企业容器技术选型策略 这4个坑要绕过

如果企业采用没有明确定义战略的容器技术，无疑会降低应用质量，以及带来治理风险。没有适当的工具和支持架构，采用容器技术肯定会失败。一些容器可能会引入隐藏的变量，最终会导致错误或中断采用，最终影响到产品的质量。没有对容器进行明确的监督，企业就不能区分哪些是策略，哪些不是，而威胁到治理。

还有“变更管理”的附加问题，比如容器专家离开企业后的问题。通过检查不足，以找到解决方法，如额外的测试和开发，确保采用容器技术与开发团队保持一致等。

尽管不管计算环境如何，容器保障软件总是能够运行，但不使用容器的典型原因并不在于技术本身，而是关于如何以更稳定的方式适应更广泛的交付链。以下是实施容器技术时需要考虑的主要弊端：

网络弊端：容器网络允许容器在同一主机上轻松联网，并且通过一些额外的工作，网络功能可以跨不同的主机覆盖。然而，网络配置的操作是有限的，而且是手动的。尽管由于需要将配置的实例添加到网络定义中，容器可以按比例脚本化，但是容易出现错误，因为每次提供容器时都会有其他步骤。

有限的库管理：虽然公共库提供了大量的预建的容器，节省了大量的配置时间，但在在沙盒外使用也会带来风险。在不知道创建镜像的人和如何创建的情况下，也可能存在一定的稳定性和安全风险。企业不得不维持和创建一个易于建立，但管理上有难度的私有库。

没有明确的审计跟踪：尽管容易设置容器，但确定设置的时间，是谁，为什么，如何提供也存在挑战。因此，设置后，企业的审计目的并没有足够的历史记录。

低可视化的运行实例：一次实例的配置，很难达到运行容器所需要的目的。这个问题也是挑战，可能导致资源浪费，无法进行资源规划以及旧版本和配置。

解决这些挑战的关键是：

规划：有时企业不仅需要架构他们的应用程序，而且还必须构建管道。企业不会放弃关于产品功能的规划。企业需要谨慎和积累，以确保容器系统能够持续运营并且有明确的定义。挑选可能出现的问题的实例，并测试团队如何解决这些问题，往往是对整体质量的试金石。

配置：容量配置在低容量下是简单的，但有更多的变量时，则需要增加团队。确保配置匹配预期的团队需要。

日志分析：从主机登录时，可以在整个容器集群中轻松查询，以了解发生的情况。知道每个容器上正在发生什么，都是创建完整可见性的唯一方法。

随着容器的迅速发展，重点放在使企业更加成熟的工具上，未来将会更多地采用诸如微服务，更多抽象的容器管道和更强大的容器库等概念。随着新工具和功能的快速引入，企业通常会等待解决所有挑战的功能出现，并在这期间谨慎使用容器，直到确定其可用性。