例 5: 属性の使用

重要

この AWS OpsWorks Stacks サービスは 2024 年 5 月 26 日にサポート終了となり、新規および既存のお客様の両方で無効になっています。できるだけ早くワークロードを他のソリューションに移行することを強くお勧めします。移行に関するご質問は、 AWS re:Post または AWS Premium Support を通じて AWS Support チームにお問い合わせください。

前述のセクションのレシピでは、プラットフォーム以外のすべてにハードコーディングされた値を使用しました。この方法は、たとえば複数のレシピで同じ値を使用したい場合は不便なことがあります。クックブックに属性ファイルを含めることにより、値をレシピとは別に定義できます。

属性ファイルは、1 つ以上の属性に値を割り当てる Ruby アプリケーションです。クックブックの attributes フォルダにある必要があります。Chef はノードオブジェクトに属性を組み込みます。属性を参照することでどのレシピでも属性値を使用できます。このトピックでは、「イテレーション」のレシピを変更して属性を使用する方法を説明します。参考までに、元のレシピを以下に示します。

[ "/srv/www/config", "/srv/www/shared" ].each do |path|
  directory path do
    mode 0755
    owner 'root'
    group 'root'
    recursive true
    action :create
  end
end

以下はサブディレクトリ名、モード、所有者およびグループの値の属性を定義します。

default['createdir']['shared_dir'] = 'shared'
default['createdir']['config_dir'] = 'config'
default['createdir']['mode'] = 0755
default['createdir']['owner'] = 'root'
default['createdir']['group'] = 'root'

次の点に注意してください。

• 各定義は属性タイプから始まります。

  属性が複数回定義されている場合 (おそらく異なる属性ファイルで)、属性タイプは属性の優先順位を指定し、ノードオブジェクトに組み込まれるかが決定されます。詳細については、「属性の優先順位」を参照してください。この例の定義はすべて、この目的のための通常のタイプである default 属性タイプです。

• 属性はネストされた名前を持ちます。

  ノードオブジェクトは基本的に任意に深くネストされたハッシュテーブルであるため、属性名もネストされたものになることがよくあります。この属性ファイルは、クックブック名でネストされた名前を使用する場合の標準的な手法に従い、createdir が最初の要素になります。

属性の最初の要素として createdir を使用する理由は、Chef を実行する時に Chef がクックブックからノードオブジェクトに属性を取り入れるためです。 AWS OpsWorks スタックでは、ノードオブジェクトには、定義した属性に加えて、組み込みクックブックの多数の属性が含まれます。クックブック名を属性名に含めることで、特に属性がport や user のような名前である場合、別のクックブックからの属性名と競合する危険性を大幅に減少します。その属性値を上書きする場合を除き、属性に "[:apache2][:user]" のような名前をつけないでください。詳細については、「カスタムクックブック属性の使用」を参照してください。

以下の例で、ハードコードされた値の代わりに属性を使用した元のレシピを示します。

[ "/srv/www/#{node['createdir']['shared_dir']}", "/srv/www/#{node['createdir']['config_dir']}" ].each do |path|
  directory path do
    mode node['createdir']['mode']
    owner node['createdir']['owner']
    group node['createdir']['group']
    recursive true
    action :create
  end
end

注記

属性値を文字列に組み込みたい場合は、#{} でパッケージ化します。前述の例では、#{node['createdir']['shared_dir']} は "/srv/www/" に "shared" を追加しています。

レシピを実行するには

1. kitchen destroy を実行して新しいインスタンスで始められるようにします。

2. recipes/default.rb のコードを前述のレシピ例で置き換えます。

3. createdir に attributes という名前のサブディレクトリを作成して、default.rb という名前の属性定義を含むファイルを追加します。

4. .kitchen.yml を編集してプラットフォームの一覧から CentOS を削除します。

5. kitchen converge を実行し、その後インスタンスにログインして /srv/www/shared と /srv/www/config がそこにあることを確認します。

注記

AWS OpsWorks スタックでは、値を属性として定義すると、さらに利点があります。カスタム JSON を使用して、スタックごと、またはデプロイごとにこれらの値を上書きできます。以下を含むさまざまな目的に便利です。

• クックブックを変更せずに、設定やユーザー名などのレシピの動作をカスタマイズできます。

  たとえば、異なるスタックに同じクックブックを使用しながら、カスタム JSON を使用して特定のスタックのキー設定を指定できます。これにより、クックブックを変更したりそれぞれのスタックに異なるクックブックを使用する手間を省くことができます。

• クックブックリポジトリにデータベースのパスワードなどの機密と考えられる情報を置く必要はありません。

  代わりに属性を使用してデフォルト値を定義し、カスタム JSON を使用してそこに実際の値を上書きすることができます。

カスタム JSON を使用して属性を上書きする方法の詳細については、「属性の上書き」を参照してください。

属性ファイルは Ruby アプリケーションであるため、もっともシンプルなものは default.rb という名前になります。これにより、たとえば条件付きロジックを使用してオペレーティングシステムに基づいて属性値を指定できます。「条件付きロジック」で、レシピで異なる Linux ファミリーに対して異なるサブディレクトリ名を指定しました。属性ファイルを使用すると、属性ファイルに条件付きロジックを配置できます。

以下の属性ファイルは、value_for_platform を使用してオペレーティングシステムによって異なる ['shared_dir'] 属性値を指定します。その他の条件では、Ruby の if-elsif-else ロジックまたは case ステートメントを使用できます。

data_dir = value_for_platform(
  "centos" => { "default" => "shared" },
  "ubuntu" => { "default" => "data" },
  "default" => "user_data"
)
default['createdir']['shared_dir'] = data_dir
default['createdir']['config_dir'] = "config"
default['createdir']['mode'] = 0755
default['createdir']['owner'] = 'root'
default['createdir']['group'] = 'root'

レシピを実行するには

1. kitchen destroy を実行して新しいインスタンスで開始できるようにします。

2. attributes/default.rb のコードを前述の例で置き換えます。

3. .kitchen.yml を編集して、「条件付きロジック」の説明に従い CentOS プラットフォームをプラットフォームセクションに追加します。

4. kitchen converge を実行し、その後インスタンスにログインしてディレクトリがそこにあることを確認します。

完了したら、kitchen destroy を実行してインスタンスを終了します。以下の例では、新しいクックブックを使用します。