Docker入门终极指南！
|
容器专用操作系统通常不运行(或不支持)包管理。这减少了安装或更新包引起冲突导致节点或服务停止运行的机会。由于没有Chef和Puppet等管理工具，运行不完整对系统运行稳定性造成不利影响的机会减少。取而代之的是，一个应用了所有更新和配置的完整的操作系统镜像被安装在一个备用的启动机制中，并在下一次重启时被启动，或回退到之前已知的工作良好的镜像。这意味着，节点的配置在任何时候都是完全已知的，任何版本都可以从使用的版本控制系统中还原。 一些容器专用的操作系统更像通用Linux发行版，例如VMware公司的PhotonOS与普通Linux发行版相比，安装的包数量较少，但仍然包括包管理器、SSH访问，并且不会将文件系统挂载为只读。人们有时会困惑的一点是，通用Linux系统的“云优化”版本仍然是通用Linux系统，如Ubuntu发布的“云镜像”，是“由Ubuntu工程部门定制的，可以在公共云上运行”。然而，这些仍然是完整的Linux发行版，安装了所有的包，只是多了一个cloud-init包，这样可以更容易地配置启动，而无需人工干预。 CoreOS是第一个被普遍采用的容器专用操作系统，并普及了在容器中运行所有进程以提高安全性和隔离性的理念。CoreOS取消了软件包管理器，并使用重启到两个只读/usr分区中的一个，以确保更新是原子的，并可以回滚。不过自从CoreOS被RedHat收购后，该项目就被终结了。 当前的容器专用操作系统都采用最小的姿态(在操作系统中安装的软件包很少);锁定(在一定程度上);在容器中运行进程(为了更好的安全性、稳定性和服务隔离)，并提供原子更新(通过启动到一个可启动分区，并更新另一个分区)。这样的例子有：
Talos是一个例外，它是容器专用操作系统中意见最大的一个。和其他系统一样，Talos操作系统也是最小化的，没有包管理器，只使用只读文件系统(除了/var和/etc/kubernetes，以及一两个短暂可写(重启时重置)的特殊文件，如/etc/resolv.conf)，并通过升级控制器与K8s集成升级。 然而，Talos操作系统比其他系统更进一步地提出了不可变基础设施的理念，它取消了所有SSH和控制台访问，并使所有的OS访问和管理通过API驱动。在运行Kubernetes的节点上，你想做的所有事情都有API调用，查看所有的容器，检查网络设置等。但在节点上你没办法做不该做的事情，比如卸载文件系统。Talos还选择完全重写Linux Init系统，它只做一件事，那就是启动Kubernetes。
不能管理任何用户定义的服务(这些都应该通过Kubernetes管理)，这进一步提高了安全性(没有SSH，没有控制台)，减少了维护(没有用户，没有补丁)，降低了任何CVE的影响(因为文件系统是不可变的，是短暂的)。你可能不同意放弃SSH访问，限制SRE的动作，强迫节点完全不可变的观点是可取的，但这也是不久前反对不可变容器的论点，这值得探究。拥有一个API管理的操作系统也非常适合大规模的操作和管理，如果你需要检查一个节点、一类节点或者所有节点上的某个容器的日志，那就是使用不同参数的同一个API调用而已。 许多企业已经开始使用多个云服务（通常来自多个供应商），同时继续使用本地 IT 环境。这种模式代表了下一代 IT 环境的趋势：基于多个来源的混合运营模式，将各种公有云和私有云以及传统 IT 结合在一起。但是企业该如何管理和优化向这种新运营模式的转变过程呢？关键在于，利用一系列针对动态自助服务设计的新流程，全方位扩展传统 IT 运营模式。当前的服务请求门户网站需要扩展，例如添加云服务商店，使用户能够轻松发现、订购和管理数字化服务，并为所使用的内容付费。这种全新的运营模式还必须启用 DevOps，支持多个用户、多个云提供商能够无缝互动。 与合作伙伴并肩前行
通过转变为混合云运营模式，可以帮助 IT 团队更有效地支持业务计划，降低业务部门自行部署云服务的可能性。但要采用这种新运营模式，就需要立即进行大刀阔斧的改革，如果没有他人帮助，IT 团队单枪匹马完成这项任务可能比较困难。无论 IT 组织身处业务模式转型的哪个阶段，IBM 都可以提供帮助，支持他们向业务团队提供自动化的自助能力，并更好地帮助企业充分发挥云计算的优势，灵活地实施多源方法，将现有 IT 环境与多个云提供商的服务整合在一起。 （编辑：唐山站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
