web-dev-qa-db-ja.com

opsworksインスタンスでのchefレシピのデバッグ-カスタムjson /データバッグ属性へのアクセス

Aws opsworks ec2サーバーで chef-Shell セッションを使用して、カスタムレシピに含めたい環境とインスタンス固有のコードをテストできるようにしたいと思います。たとえば、node [：opsworks] [：instance] [：layers]またはnode [：opsworks] [：instance] [：public_dns_name]などの instance attributes の出力を確認したいと思います。 custom json を使用してopsworksスタックに渡したデータと同様に。

私はchef-Shellを起動できますが、それを使用してopsworks属性にアクセスする方法がわかりません

Opsworks ec2インスタンスにSSH接続すると、node ['ec2'] ['instance_id']のような属性にアクセスできますが、node ['opsworks'] ['instance'] ['layers']のようなopsworks固有の属性にはアクセスできません

root@mongodb1:/opt/aws/opsworks/current/bin# ./chef-Shell
loading configuration: none (standalone session)
Session type: standalone
Loading......done.

This is the chef-Shell.
 Chef Version: 11.10.4
 http://www.opscode.com/chef
 http://docs.opscode.com/

run `help' for help, `exit' or ^D to quit.

Ohai2u [email protected]!
chef > attributes_mode
chef:attributes > node['ec2']['instance_id']
 => "i-c1a98f2c"
chef:attributes > node['opsworks']['instance']['layers']
NoMethodError: undefined method `[]' for nil:NilClass
        from (irb#1):4
chef:attributes >
amazon-web-serviceschefopsworks
7
Peter M

カスタムJSONとスタックの状態は、OpsWorksイベント（セットアップ、構成、デプロイ、アンデプロイ、シャットダウン）が発生すると、JSON構造体のインスタンスにプッシュされます。レシピでOpsWorksスタックの最新の状態を確認する場合は、Deploy-> Run Command-> Execute Recipesフォームを介してOpsWorks UIからレシピを実行する必要があります。 。

OpsWorksによって送信されたJSONはインスタンスに保存されます。このインスタンスが最後にOpsWorksイベントを実行したときと同じくらい新しい、潜在的に古くなったスタック状態情報を使用する場合は、*.jsonでインスタンスの最新の/var/lib/aws/opsworks/chefファイルを探し、Rubyコード。

インスタンスでopsworks-agent-cliユーティリティを使用して、インスタンスのコマンドラインから直接OpsWorksイベントからレシピを（再）実行することもできます。このユーティリティは、OpsWorksイベントを再実行します。新しいイベントは開始されませんしないスタック状態またはカスタムJSONの新しいコピーをプルします。OpsWorksが使用する.jsonファイルを再利用しますそのイベントが最初に実行されたときにインスタンスに送信されます。たとえば、インスタンスでsetupイベントを再実行するには、次のようにします（セットアップイベントは既に実行されているため）。

Sudo opsworks-agent-cli run_command setup

UIからExecute Recipesを実行したときに前回実行したのと同じレシピのセットを再実行するには、次のようにします。

Sudo opsworks-agent-cli run_command execute_recipes

最初にUIを介してイベントを実行する必要があるので、この種の問題です。したがって、カスタムレシピを実行する場合、またはカスタムクックブックを更新する場合は、最初にそのイベントをUIから実行する必要があります。ただし、2回目、3回目、およびそれ以降は、opsworks-agent-cliを介してこれらのイベントを再実行できます。

Opsworks-agent-cliの詳細については、 こちら を参照してください。

10
Shlomo Swidler

上記の彼の回答のec2インスタンスファイルでのカスタムjsonの場所に関する@schlomoswidlerからのアドバイスを使用して、次のコマンドを実行して、探していたカスタムopsworks属性を含むインタラクティブシェフシェルを取得しました。

root@mongodb1:/opt/aws/opsworks/current/bin# /opt/aws/opsworks/current/bin/chef-Shell -j /var/lib/aws/opsworks/chef/2014-10-27-13-46-53-01.json
loading configuration: none (standalone session)
Session type: standalone
Loading.....done.

This is the chef-Shell.
 Chef Version: 11.10.4
 http://www.opscode.com/chef
 http://docs.opscode.com/

run `help' for help, `exit' or ^D to quit.

Ohai2u [email protected]!
chef > node['opsworks']['instance']['layers']
 => ["mongodb"]
chef >

/ var/lib/aws/opsworks/chefフォルダーのjsonをシステム上の適切なファイルに置き換える必要があることは明らかです。

Chef 12 Linux OpsWorksスタックの更新（2016）

Chef 12 LinuxベースのOpsWorksスタック Chef 11スタックとは動作が異なります。 1つの違いは、 chef search が、レシピ内でOpsWorksによって提供されるデータにアクセスするための適切な方法であることです。インスタンスでは、属性データは データバッグ （スタック 移行 ＆ 参照 ）を通じて公開されるようになりました。 Chef実行の1つのディレクトリを調べることにより、使用可能なデータバッグの概要を取得できます。各データバッグには、/var/chef/runs/<ID>/data_bags/の下に独自のサブディレクトリがあります。

[root@asd1 ~]# ll /var/chef/runs/c7f67e3e-c15d-4159-bb14-5bde07751543/data_bags/
total 36
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_app
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_command
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_ecs_cluster
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_elastic_load_balancer
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_instance
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_layer
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_rds_db_instance
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_stack
drwxr-xr-x 2 root root 4096 Nov 23 21:19 aws_opsworks_user
[root@asd1 ~]#

上記のChef 11スタックで使用したのと同じchef-Shellテクニックを使用することはできません。

検索を試すために知っている最善の方法は、 Pryセッション を使用して、クライアント専用の2番目のchef runのランタイム環境にアクセスすることです。 。

こじ開けセッション

次の例では、最初にUIから「レシピの実行」ライフサイクルイベントをトリガーし、実行するレシピとして「opsworks_cookbook_demo :: foo」を使用します。次に、インスタンスにSSH接続して/var/chef/cookbooks/opsworks_cookbook_demo/recipes/foo.rbを編集し、次の2行を追加します。

require "pry"
binding.pry

次に、opsworks-agent-cli runを実行して、最新の実行を繰り返します。最新の実行のタイプが「カスタムクックブックの更新」でなかった場合を除き、ローカルの変更はそのまま残ります。

レシピが再度実行されますが、今度はインタラクティブなシェルで実験できます。 2つの検索を実行する方法は次のとおりです。

[root@asd1 ~]# opsworks-agent-cli run
[2015-11-23 21:46:35]  INFO [opsworks-agent(3396)]: About to re-run 'execute_recipes' from 2015-11-23T21:43:15
... lots more output ...
From: /var/chef/runs/76ff2d58-ab8f-4cf6-8744-9562025321fd/local-mode-cache/cache/cookbooks/opsworks_cookbook_demo/recipes/foo.rb @ line 4 Chef::Mixin::FromFile#from_file:

    1: Chef::Log.info "foo"
    2:
    3: require "pry"
 => 4: binding.pry

search(:aws_opsworks_stack)
=> [{"data_bag_item('aws_opsworks_stack', 'f24bd5ea-3ff2-4a1a-a4e4-9298495ae263')"=>
   {"arn"=>"arn:aws:opsworks:us-west-2:153700967203:stack/f24bd5ea-3ff2-4a1a-a4e4-9298495ae263/",
    "custom_cookbooks_source"=>{"type"=>"s3", "url"=>"redacted", "username"=>nil, "password"=>nil, "ssh_key"=>nil, "revision"=>nil},
    "name"=>"susan",
    "region"=>"us-west-2",
    "stack_id"=>"f24bd5ea-3ff2-4a1a-a4e4-9298495ae263",
    "use_custom_cookbooks"=>true,
    "vpc_id"=>nil,
    "id"=>"f24bd5ea-3ff2-4a1a-a4e4-9298495ae263",
    "chef_type"=>"data_bag_item",
    "data_bag"=>"aws_opsworks_stack"}}]

search(:aws_opsworks_instance, "self:true")
=> [{"data_bag_item('aws_opsworks_instance', 'asd1')"=>
   {"AMI_id"=>"AMI-d93622b8",
    "architecture"=>"x86_64",
    "auto_scaling_type"=>nil,
    "availability_zone"=>"us-west-2a",
    "created_at"=>"2015-11-20T12:48:29+00:00",
    "ebs_optimized"=>false,
    "ec2_instance_id"=>"i-be823867",
    "elastic_ip"=>nil,
    "hostname"=>"asd1",
    "instance_id"=>"42d28e39-29a8-4fdf-a327-afdc23668ff1",
    "instance_type"=>"c3.large",
    "layer_ids"=>["f08fb7e2-9278-498a-8c0d-7d1c1bae22aa"],
… lots more data …

Awsブログ投稿 Quickly Explore the Chef Environment in AWS OpsWorks には、OpsWorksインスタンスでpryを使用する他の例があります。

9
Peter M