容器的可移植性真实含义究竟是什么？
容器提供了可移植性和灵活性的承诺：将应用程序从开发人员的笔记本电脑移动到内部数据中心，并将其转移到不同的云提供商的难度很小？ 他们可以提供新的自定义版本的软件，以快速满足最后签署的合同期限，甚至可能为您的客户提供自助服务。 它们启动速度更快，并且比虚拟机更容易移动。 真的是这样吗？
这是目标，但可移植性和兼容性是不一样的。 可移植性是一个业务问题，而兼容性是一个技术问题。 便携性只能通过规划不同环境中的兼容性来实现。 单独采用容器不能保证应用程序的兼容性。 为什么会这样？ 容器真的只是包装应用程序和所有操作系统依赖关系的一种奇特方式。
这是什么意思？ 这意味着要真正实现可移植性，从而实现业务灵活性，您需要进行规划。 以下是一系列有助于确保成功的建议：
1.标准操作环境
这需要包括容器主机，容器图像，容器引擎和容器编排。 所有这些移动部件都需要对齐和标准化。 所有这些组件需要一起进行版本化和测试。 升级需要作为一个单位一起计划，因为有很多相互依赖关系。 在容器建造或运行的每个环境中，包括开发人员的笔记本电脑，测试服务器和虚拟机都需要保证基础架构的平衡。 始终建议在任何地方使用相同的测试和认证组件。
2.标准应用定义
当涉及到应用程序定义时，有几种技术选择。 Docker Compose，Kubernetes对象，OpenShift模板或Helm图表。 做一个酝酿并选择一个应用程序定义，每个都有优点和缺点。 不要在不同之间翻译; 当一个功能在一款产品支持另一款产品不支持的时候，这只会导致问题。
例如，开发人员不应该使用Docker Compose构建，然后在生产中使用Kubernetes进行重建。 虽然这在技术上是可行的，但却导致了两套经验，两套投资，两套错误，两套学习，两套文件，两套不能正常工作的解决办法等等。 最好选择一个，然后如果需要，如果你发现有更好的东西，这个技术正在快速变化，再重新评估。
3.数据存储，配置和密钥
这些事情应该由环境确定和提供，而不是嵌入到容器镜像中，也不应用于应用程序定义。
例如，您不想在开发人员的笔记本电脑上的数据存储区中使用信用卡信息，这只能在生产中。您不希望嵌入在开发人员在笔记本电脑上使用的容器镜像中的生产数据库密码。
另一方面，如果您在两个云提供商之间移动，则需要移动数据并保持同步。您可以在三个不同的级别（块，文件或事务）执行此操作。这不会随着容器而改变，大多数容器平台都不会为您处理。块存储复制通常使用底层技术DRBD，SRDF或Ceph完成。文件复制通常使用Rsync，Gluster Geo Replication或在低延迟环境中进行GFS2或GPFS处理。在事务层，这需要是数据存储或数据库的一部分，并且与每个技术完全不同 - MySQL是事务复制，MongoDB是地理位置冗余副本集，Oracle数据库有多个选项，JBoss Datagrid它是跨数据中心复制。
保证应用可移植性需要广泛的规划。容器提供可移植性的承诺，但只有在较低级别（容器映像，主机，引擎，编排），更高级别（应用程序定义）以及管理（同步，基于角色的访问等）考虑兼容性时数据，配置和密钥。
图：应用程序定义在环境之间运送，但配置和数据由环境决定
从一个直接的应用程序开始。 标准化一组容器主机，映像，引擎，协调器和应用程序定义。 了解如何管理数据，配置和密钥。 成功后，展开到另一个工作负载。 并不是每个工作量都会很容易。 但是，当你指出这些东西时，您将实现敏捷性和可移植性，并降低更快地提供应用程序的障碍，并且更轻松地在云提供商之间移动它们。
译者观点：
本文作者给出了一个大家可能会忽视的角度，容器确实带来深刻变革，带来巨大的便利性，但是不意味着使用容器就可以忽略兼容性和标准化。要用好容器，同样需要做好标准化和架构设计。
欢迎加入OpenStack vs Kubernetes 群，一起交流技术，申请表填写
扫描二维码
相关阅读：
Kubernetes 1.8专注安全，在容器编排平台中稳居领导地位