在使用容器后,我们是否仍然需要担心基础架构层面的配置管理?

31次阅读
没有评论

问题描述

在准备开始使用容器时,想知道在使用容器后,是否仍然需要使用像Chef、Ansible、Terraform等工具来确保基础架构的正确维护。他认为容器只是运行在基础架构上,所以他想知道使用容器后的配置管理会有什么不同。

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

容器是一种可重复使用的基础架构的打包方式。尽管容器提供了一些原生工具来管理基础架构,但我认为在容器基础架构中仍然需要进行配置管理。不过,你可能会改变使用Puppet等工具的方式,而是使用与容器一起提供的原生工具。
例如,Kubernetes可以管理部署、复制集(容器的’pod’)和节点,类似于Puppet管理虚拟机和微服务。Dockerfile和YAML文件也可以满足基础架构即代码的需求,这是Puppet提供的。容器是可重复基础架构的打包方式。
以下是一个支持我的回答的Stack Overflow答案,它在过去对我很有帮助:
https://stackoverflow.com/a/41472271/1524645

方案2

这取决于你愿意租用和允许别人管理的程度。
如果我们看一下这个图表:
在使用容器后,我们是否仍然需要担心基础架构层面的配置管理?
它展示了一整套选项。在一端是自己动手,在本地硬件上设置网络等。旁边是“co-lo”,意味着你购买的服务器安装在某个机架/网络/数据中心中。旁边是IaaS,你通常租用纯软件定义网络上的虚拟机,并支付某人来管理物理服务器和物理网络。
那么容器在哪里适用?我见过大型组织将云IaaS视为本地环境,通过在云中设置网络和防火墙来完全匹配本地环境,与云数据中心进行私有网络连接。所以在云中几乎没有云的优势。他们主要管理的是从本地迁移到云提供商的遗留系统,作为数百万美元云合同的一部分。显然,他们仍然需要像在本地一样进行所有的配置管理来管理虚拟机。然后,他们安装Kubernetes来管理容器,并需要管理它。他们需要在每个级别进行配置管理,容器集群只是他们需要配置和管理的另一种新事物。
在光谱的另一端是SaaS,你不知道他们使用的是虚拟机还是容器。然后你没有传统的配置管理,通常也没有DevOps。从DevOps的角度来看,一个有趣的选择是CaaS+PaaS,你租用一个具有DevOps扩展(如OpenShift)的托管Kubernetes服务上的容量。作为一个初创公司,你可以简单地在共享集群上租用内存,通过OpenShift Kubernetes内的软件定义网络与其他租户隔离。然后,你已经将云中的VM管理和配置以及在VM上运行的Kubernetes集群的扩展外包出去。然后,你可以专注于在Kubernetes上配置管理你的容器。
请注意,你仍然需要对容器运行时进行安全补丁。我们有一个脚本,用于检查RHOAR容器的新安全补丁,并使用最新版本重新构建我们的容器。
所以这取决于你愿意和能够放弃控制的程度。你可以从租用共享托管集群的一部分开始,然后升级到由别人管理的专用集群。一旦你开始在公共云上这样做,很难想象回到在云中管理VM的任何额外优势。除非你被迫这样做来运行遗留应用程序或你必须购买不支持在容器中运行的软件。如果你必须配置VM,你应该应用最佳的配置管理实践。

正文完