VMwareテンプレートをバージョン管理するための推奨される方法は何ですか？
多数のデータセンターがあり、それぞれがVMware vCenter5.5で実行されている独自のプライベートクラウドを備えている組織にいると想定します。 Windows、Redhat Linuxなど、さまざまなオペレーティングシステム用のVMwareテンプレートがあります。
C1とC2の2つのプライベートクラウドがあると仮定しましょう。 C1は1年前に構築され、C2はごく最近に構築されました。 Windows 2012を実行していると仮定します。ベーステンプレートは、C1が構築されてから数回更新されました。たとえば、.NET Frameworkはv4.0からv4.5に更新され、次にv4.5.1に更新されました。
C1の仮想マシンを再構築する必要があります。ただし、その仮想マシンで実行されているソフトウェアは、.NETv4.5またはv4.5.1と互換性がありません。したがって、私たちが持っている唯一のテンプレートは互換性がありません。テンプレートを再作成する必要がありますが、仮想マシンに問題を引き起こすOSパッチなどがインストールされている可能性があります。
したがって、テンプレートをバージョン管理することがベストプラクティスのようです。最善のアプローチは何ですか？
これが私が試したことです：
- テンプレートを更新する前にスナップショットを作成します。 VMware vSphereツールは、それを1つのテンプレートと見なしているため、スナップショット「2013103102：00」から仮想マシンを作成するのは少し複雑です。
- テンプレートを複製すると、「Windows Server 2012（20131031）」、「Windows Server 2012（20130331）」、「Windows Server 2012（20140601）」になります。ツールはこれをうまくサポートします。何がどのテンプレートにインストールされているのかわからない人がいると、すぐに混乱する可能性があります。
- テンプレートが更新されたら、エクスポートします。 VMwareツールで使用できるのは最新のテンプレートのみですが、問題が発生した場合はいつでも古いバージョンのテンプレートを復元できます。
VMwareテンプレートをバージョン管理するためのより堅牢な方法はおそらくありますか？
間違ったツールで問題を解決しようとしていると思います。 VMwareテンプレートは、従来のオペレーティングシステムイメージと非常によく似ています。それらは実際に2つのことを行うために存在します：1）すべてのサーバーが開始する一貫した既知の良好なベースを提供します。2）インストールメディアからその既知の良好な状態に移行するために必要な管理タスクの繰り返しを減らします。フリート全体で最も一般的な構成を満たすようにテンプレートを作成します。非常に多くの異なるニーズがあり、「共通分母」テンプレートが非常にスペアであるため、テンプレートと目的の状態の間に大きなギャップがある場合は、計算を開始して、複数のテンプレートを維持する努力が努力に値するかどうかを判断する必要があります。 「共通分母」テンプレートから特殊なテンプレートに移動するために必要なタスクの観点から保存しました。私の経験では、複数のテンプレートまたはイメージを維持することは、構成を実行するために必要な労力よりもはるかに多くの労力を要します。さまざまなテンプレートをこのように維持することを発見したように、この方法は対数曲線であり、線形曲線ではありません-特に異種環境では。これが、イメージングがデスクトップではうまく機能するが、サーバーではあまり役に立たない理由です。
ソリューションは、「共通分母」テンプレートから特殊な目的の構成に移行するために必要なタスクの労力を削減することにあります。これは本質的に構成管理です。 Windowsエコシステムでは、GPO、PowerShell DSC、SCCMなどのツールを検討しています。 Linuxの世界のエンタープライズツールについてはあまり詳しくありませんが、PuppetやChefのようなもので動作するはずです。
テンプレートまたはイメージを使用して構成の労力を削減することは、目的の最終状態の構成に大幅な多様性がある場合、多くの場合、負けゲームです。
このためのテンプレートを使用するための行き詰まりがある場合は、おそらくPowerCLIを使用して、いくつかのスクリプトを作成し、テンプレートのスナップショット、変更、コピー、バージョンのマーク付け、または何らかのバージョン管理システムへの配置のタスクを実行する必要があります。このサイズのファイルを処理できます。繰り返しになりますが、この方法で問題を解決する努力は、ある種の構成管理システムを使用するよりも少ないと思います。