仮想リソースとは？
仮想リソースは通常のリソースとは異なり，マニフェストで宣言しただけでは，システムに適用されません。「実体化」することによってはじめてシステムに適用されます。
仮想リソースの宣言は通常のリソースの宣言とほぼ同じですが，リソースタイプの前に@を付加します。
@user { luke: ensure => present }
この仮想リソースをシステムに適用するためには，realize関数によって実体化します。
realize(User['luke'])
これでシステム上にlukeというユーザが作成されます。
他にも実体化の方法はありますが，その解説の前に，まずは仮想リソースを具体的にどのような場面で利用するとうれしいのかを説明します。
仮想リソースの利用シナリオ
仮想リソースの利用シーンとして，以下のようなシナリオを想定します。
- ウェブサービスのためのサーバを構築する。
- このウェブサービスでは，前段にリバースプロキシを置いてブラウザからのリクエストを受ける。
- リバースプロキシは背後のウェブアプリケーションサーバにリクエストを中継する。
- スモールスタートでコストを抑えつつ，冗長性も確保するために，マシンは2台用意し，それぞれにリバースプロキシとウェブアプリケーションサーバを同居させる。
- リバースプロキシ，ウェブアプリケーションのどちらでも負荷に応じて個別に台数を増やせるような柔軟性を確保する。
- リバースプロキシで利用するPerlbalと，ウェブアプリケーションで利用するBackgrounDrbのプロセスは，daemontoolsで管理する。
このようなシナリオを想定した上で，まずは仮想リソースを使わずにマニフェストを記述してみます。
リバースプロキシとウェブアプリケーションサーバが同居しない場合には，マニフェストは以下のようになり，特に問題はありません。
class proxy {
package {
'daemontools':
ensure => present;
'perl-Perlbal':
ensure => present;
}
}
class www {
package {
'daemontools':
ensure => present;
'rubygem-rails':
ensure => present;
}
}
node proxy {
include proxy
}
node www {
include www
}
リバースプロキシとウェブアプリケーションサーバを同居させようとした場合，以下のようなマニフェストになります。
class proxy {
package {
'daemontools':
ensure => present;
'perl-Perlbal':
ensure => present;
}
}
class www {
package {
'daemontools':
ensure => present;
'rubygem-rails':
ensure => present;
}
}
node proxy_and_www {
include proxy
include www
}
これをシステムに適用しようとすると，daemontoolsパッケージリソース宣言が重複しているため，以下のようなエラーが発生します。
err: Could not retrieve configuration: Duplicate definition: Package[daemontools] is already defined in file manifests/site.pp at line 11; cannot redefine at manifests/site.pp:2
