Debuggen von Kochrezepten auf opsworks-Instanzen - Zugriff auf benutzerdefinierte json / data bag-Attribute


7

Ich möchte eine Chef-Shell- Sitzung auf einem aws opsworks ec2-Server verwenden, damit ich einen umgebungs- und instanzspezifischen Code testen kann, den ich in ein benutzerdefiniertes Rezept aufnehmen möchte. Zum Beispiel würde Ich mag die Ausgabe sehen Instanzattribute wie node [: opsworks] [: instance] [: Schichten] oder node [: opsworks] [: instance] [: public_dns_name] sowie Daten I bestanden haben , zum opsworks-Stapel mit benutzerdefiniertem json .

Ich kann Chef-Shell starten, ich weiß nur nicht, wie ich damit auf opsworks-Attribute zugreifen soll.

Wenn ich in die opsworks ec2-Instanz ssh, kann ich auf Attribute wie node ['ec2'] ['instance_id'] zugreifen, aber keine opsworks-spezifischen wie node ['opsworks'] ['instance'] ['layer']

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 ubuntu@mongodb1.localdomain!
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 >

Antworten:


10

Der benutzerdefinierte JSON- und der Stack-Status werden in einer JSON-Struktur an die Instanz übertragen, wenn ein OpsWorks-Ereignis (Einrichten, Konfigurieren, Bereitstellen, Aufheben der Bereitstellung, Herunterfahren) auftritt. Wenn Sie möchten, dass Ihr Rezept den aktuellen Status des OpsWorks-Stapels anzeigt, müssen Sie Ihr Rezept über das Formular Bereitstellen -> Befehl ausführen -> Rezepte ausführen über die OpsWorks-Benutzeroberfläche ausführen .

Der von OpsWorks gesendete JSON wird in der Instanz gespeichert. Wenn Sie bereit sind, möglicherweise veraltete Stapelstatusinformationen zu verwenden, die nur so aktuell sind wie das letzte Mal, als diese Instanz ein OpsWorks-Ereignis ausgeführt hat, können Sie nach der neuesten *.jsonDatei auf der Instanz in suchen /var/lib/aws/opsworks/chefund diese über Ruby-Code analysieren.

Sie können das opsworks-agent-cliDienstprogramm auch für die Instanz verwenden, um die Rezepte eines OpsWorks-Ereignisses direkt über die Befehlszeile der Instanz (erneut) auszuführen. Dieses Dienstprogramm führt OpsWorks-Ereignisse erneut aus - es initiiert keine neuen Ereignisse und zieht keine neue Kopie des Stapelstatus oder des benutzerdefinierten JSON ab, sondern verwendet die .jsonDatei, die OpsWorks an die Instanz gesendet hat, als dieses Ereignis aufgetreten ist ursprünglich ausführen . Zum Beispiel, um das setupEreignis auf Ihrer Instanz erneut auszuführen (da das Setup-Ereignis definitiv bereits ausgeführt wurde):

sudo opsworks-agent-cli run_command setup

Um die gleichen Rezepte erneut auszuführen, die Sie beim letzten Ausführen von "Rezepte ausführen" über die Benutzeroberfläche ausgeführt haben:

sudo opsworks-agent-cli run_command execute_recipes

Diese Art von nervt, weil Sie das Ereignis zuerst über die Benutzeroberfläche ausführen müssen. Wenn Sie also ein benutzerdefiniertes Rezept ausführen oder benutzerdefinierte Kochbücher aktualisieren möchten, müssen Sie dieses Ereignis zuerst über die Benutzeroberfläche ausführen. Beim zweiten, dritten und nachfolgenden Mal können Sie diese Ereignisse jedoch erneut ausführen opsworks-agent-cli.

Sehen Sie hier für mehr über die opsworks-agent-cli.


9

Unter Verwendung der Ratschläge von @schlomoswidler zum Speicherort des benutzerdefinierten JSON in der ec2-Instanzdatei in seiner obigen Antwort habe ich Folgendes ausgeführt, um eine interaktive Chef-Shell zu erhalten, die die von mir gesuchten benutzerdefinierten opsworks-Attribute enthält:

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 ubuntu@mongodb1.localdomain!
chef > node['opsworks']['instance']['layers']
 => ["mongodb"]
chef >

Sie müssen natürlich den json im Ordner / var / lib / aws / opsworks / chef durch eine entsprechende Datei auf Ihrem System ersetzen.

Update für Chef 12 Linux OpsWorks Stacks (2016)

Chef 12 Linux-basierte OpsWorks-Stacks funktionieren anders als Chef 11-Stacks. Ein Unterschied besteht darin , dass Koch Suche ist jetzt der richtige Weg , um auf Daten zuzugreifen , die von OpsWorks innerhalb eines Rezeptes. Auf der Instanz wird nun durch Attributdaten ausgesetzt Daten Taschen (Stapel Migration & Referenz ). Sie können sich einen Überblick über die verfügbaren Datentaschen verschaffen, indem Sie das Verzeichnis auf einen Ihrer Chef-Läufe überprüfen. Jeder Datentasche hat unten ein eigenes Unterverzeichnis /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 ~]#

Sie können nicht die gleiche chef-shellTechnik verwenden, die ich oben für Chef 11-Stapel verwendet habe.

Der beste Weg, mit der Suche zu experimentieren, ist die Verwendung einer Pry-Sitzung , um Zugriff auf die Laufzeitumgebung des zweiten Kochlaufs zu erhalten, der für Kunden bestimmt ist.

Beispiel Pry Session

Im folgenden Beispiel löse ich zuerst das Lebenszyklusereignis "Rezepte ausführen" über die Benutzeroberfläche aus und verwende "opsworks_cookbook_demo :: foo" als das auszuführende Rezept. Dann SSH in meine Instanz und bearbeite /var/chef/cookbooks/opsworks_cookbook_demo/recipes/foo.rb, indem ich die folgenden zwei Zeilen hinzufüge.

require "pry"
binding.pry

Dann laufe ich opsworks-agent-cli run, um den letzten Lauf zu wiederholen. Sofern der letzte Lauf nicht vom Typ "Benutzerdefinierte Kochbücher aktualisieren" war, bleiben die lokalen Änderungen erhalten.

Das Rezept wird erneut ausgeführt, aber jetzt haben wir eine interaktive Shell zum Experimentieren. So können Sie zwei Suchvorgänge durchführen:

[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 …

Der aws-Blogbeitrag Quickly Explore the Chef Environment in AWS OpsWorks enthält weitere Beispiele für die Verwendung von pry in einer OpsWorks-Instanz.


Aus irgendeinem Grund bringt mich das dahin, [1] pry(#<Chef::CookbookVersion>)>wo ich auf nichts zugreifen kann. Ein stepWille bringt mich in [1] pry(#<Chef::RunContext::CookbookCompiler>):1>das nicht hilfreich ist. Ein anderer, stepmit [1] pry(#<Chef::EventDispatch::Dispatcher>)> dem Pry abstürzt Error: Cannot find local context. Did you use binding.pry? - hat das jemand erlebt?
stiller_leser
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.