对 VMware 模板进行版本控制的推荐方法是什么？

Question

假设您所在的组织拥有众多数据中心，每个数据中心都有自己的私有云，运行在 VMware vCenter 5.5 上。有适用于不同操作系统的 VMware 模板，包括 Windows、Redhat Linux 等。

假设有两个私有云，C1 和 C2。C1 是在一年前建造的，而 C2 是最近才建造的。假设它运行 Windows 2012。自 C1 构建以来，基本模板已更新多次。例如，.NET 框架从 v4.0 更新到 v4.5，然后到 v4.5.1。

C1 中的虚拟机需要重建。但是，在该虚拟机中运行的软件与 .NET v4.5 或 v4.5.1 不兼容。所以我们唯一的模板不兼容。我们必须重新创建模板，但很可能安装了一些操作系统补丁等，从而导致虚拟机出现问题。

因此，版本模板似乎应该是最佳实践。最好的方法是什么？

这是我尝试过的：

1. 在更新模板之前创建快照。VMware vSphere 工具仍然认为它是一个模板，因此从快照“20131031 02:00”创建虚拟机需要更多的工作。
2. 复制模板，所以现在我们有“Windows Server 2012 (20131031)”、“Windows Server 2012 (20130331)”和“Windows Server 2012 (20140601)”。这些工具很好地支持这一点。我们可能很快就会一团糟，人们不知道在什么模板上安装了什么。
3. 模板更新后，将其导出。VMware 工具中只有最新的模板可用，但我总是可以在出现问题时恢复旧版本的模板。

是否有更强大的版本控制 VMware 模板的方法？

Answer 1

我认为您正在尝试使用错误的工具来解决问题。VMware 模板与传统操作系统映像非常相似。它们的存在实际上是为了做两件事：1) 提供所有服务器启动时一致的已知良好基础，2) 减少从安装介质进入已知良好状态所需的管理任务的重复。您构建模板以满足整个车队最常见的配置。如果您有如此多的不同需求，以至于您的“公分母”模板非常多余，以至于模板与所需状态之间存在巨大差距，您必须开始进行数学计算，以确定维护多个模板的努力是否值得您节省了从“共同点”模板到专业模板所需的任务。根据我的经验，维护多个模板或图像通常比执行配置所需的工作量要多得多。正如您所发现的，以这种方式维护不同的模板是一条对数曲线，而不是线性曲线 - 特别是在异构环境中。这就是为什么映像对于台式机非常有效，但对于服务器却不太有用。

您的解决方案在于减少从“共同点”模板到您所需的专门配置所需的任务工作量。这本质上是配置管理。在 Windows 生态系统中，您会看到 GPO、PowerShell DSC 和 SCCM 等工具。我不太熟悉 Linux 世界中的企业工具，但像 Puppet 或 Chef 这样的工具应该可以使用。

如果您所需的最终状态配置存在显着差异，那么使用模板或图像来减少配置工作通常会失败。

如果您不愿意为此使用模板，那么您将需要构建一些脚本（可能使用 PowerCLI）来执行快照、修改和复制模板并用版本标记它或将其放入某种版本控制系统的任务可以处理这种大小的文件。再次，我怀疑以这种方式解决您的问题的工作量少于使用某种配置管理系统。