有关容器的六大误区和八大正确场景
|
除了容器从技术角度，能够使得大部分的内部配置可以放在镜像里面之外，更重要的是从流程角度，将环境配置这件事情，往前推了，推到了开发这里，要求开发完毕之后，就需要考虑环境部署的问题，而不能当甩手掌柜。 这样做的好处就是，虽然进程多，配置变化多，更新频繁，但是对于某个模块的开发团队来讲，这个量是很小的，因为5-10个人专门维护这个模块的配置和更新，不容易出错。 如果这些工作量全交给少数的运维团队，不但信息传递会使得环境配置不一致，部署量会大非常多。 容器是一个非常好的工具，就是让每个开发仅仅多做5%的工作，就能够节约运维200%的工作，并且不容易出错。 然而本来原来运维该做的事情开发做了，开发的老大愿意么？开发的老大会投诉运维的老大么？ 这就不是技术问题了，其实这就是DevOps，DevOps不是不区分开发和运维，而是公司从组织到流程，能够打通，看如何合作，边界如何划分，对系统的稳定性更有好处。
所以微服务，DevOps，容器是相辅相成，不可分割的。 不是微服务，根本不需要容器，虚拟机就能搞定，不需要DevOps，一年部署一次，开发和运维沟通再慢都能搞定。 所以，容器的本质是基于镜像的跨环境迁移。 镜像是容器的根本性发明，是封装和运行的标准，其他什么namespace，cgroup，早就有了。这是技术方面。 在流程方面，镜像是DevOps的良好工具。 容器是为了跨环境迁移的，第一种迁移的场景是开发，测试，生产环境之间的迁移。如果不需要迁移，或者迁移不频繁，虚拟机镜像也行，但是总是要迁移，带着几百G的虚拟机镜像，太大了。 第二种迁移的场景是跨云迁移，跨公有云，跨Region，跨两个OpenStack的虚拟机迁移都是非常麻烦，甚至不可能的，因为公有云不提供虚拟机镜像的下载和上传功能，而且虚拟机镜像太大了，一传传一天。 所以跨云场景下，混合云场景下，容器也是很好的使用场景。这也同时解决了仅仅私有云资源不足，扛不住流量的问题。 第三部分：容器的正确使用场景 根据以上的分析，我们发现容器推荐使用在下面的场景下。 1. 部署无状态服务，同虚拟机互补使用，实现隔离性 2. 如果要部署有状态服务，需要对里面的应用十分的了解 3. 作为持续集成的重要工具，可以顺利在开发，测试，生产之间迁移 4. 适合部署跨云，跨Region，跨数据中心，混合云场景下的应用部署和弹性伸缩 5. 以容器作为应用的交付物，保持环境一致性，树立不可变更基础设施的理念 6. 运行进程基本的任务类型的程序 7. 用于管理变更，变更频繁的应用使用容器镜像和版本号，轻量级方便的多 8. 使用容器一定要管理好应用，进行health check和容错的设计 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
