Seite wählen

NETWAYS Blog

i-doit API Ruby-Scripting

Wie in meinem letzten Blogpost angekündigt stelle ich heute eine gescriptete Variante für die API der i-doit CMDB vor.

Einzelne Abfragen, sowie das Anlegen von Objekten über den RESTClient mögen auf den ersten Blick zum Testen bzw. Debuggen  ziemlich sinnvoll erscheinen, aber man stößt schnell an Grenzen, sobald es sich über mehrere hundert solcher Objekte handelt. Darüber hinaus ist diese Methode sehr umständlich.

Meine Idee war es eine Webanwendung zu benutzen, welche mit einem einzelnen Requests (im JSON-Format) an die API von I-doit Abfragen oder das Neuanlegen von Objekten vereinfacht. Da bot sich das Framework Sinatra an, da dieses eine sehr einfache und schnell zu lernende DSL besitzt. Wenn diese Anwendung läuft, kann mit der Eingabe einer bestimmten URL, ein Objekt abgefragt bzw. erstellt werden. In diesem Beispiel, werde ich die Namen sowie IDs aller Server aus der CMDB auslesen.

Zunächst müssen wir folgende drei Bibliotheken einbinden:

#!/usr/bin/env ruby

require 'sinatra/base'
require 'json'
require 'rest-client

Im nächsten Schritt bauen wir uns einen generischen Request (wie in meinem vorherigen Blogpost zu lesen) zusammen:

$baseurl = "https://example-idoit-web-gui.de"
$apikey = "random_key"

class CMDBApi
  def initialize(url=$baseurl, apikey=$apikey, objID=nil)
    @url = url
    @apikey = apikey
    @objID = objID
  end

  def postHeader(endpoint, method, payload)
    response = RestClient::Request.new({
      :method => method,
      :headers => {:accept => :json, :content_type => :json},
      :url => "#{@url}/#{endpoint}",
      :payload => payload
    }).execute
  end
  def readAllServer()
    payloadMetadata = Hash.new
    payloadMetadata[:version] = "2.0"
    payloadMetadata[:id] = "1"
    payloadMetadata[:method] = "cmdb.objects.read"
    payloadMetadata[:params] = Hash.new
    payloadMetadata[:params][:apikey] = @apikey
    payloadMetadata[:params][:filter] = {"type": "5"}
    @payloadJsonFormat = payloadMetadata.to_json
    response = postHeader("src/jsonrpc.php", :post, @payloadJsonFormat)
    response_hash = JSON.parse(response)
  end
end

get "/server" do
  api = CMDBApi.new($baseurl, $apikey)
  response = api.readAllServer(objectID)
  allServerHash = {}
  response["result"].each do |result|
    serverID = result["id"]
    serverName = result["title"]
    allServerHash[:"#{serverName}"] = serverID
  end
  allServerHash.to_json
end

Wenn man das Skript ausführt, wird (je nach Konfiguration) über http://127.0.0.1:4567 auf das Webfrontend zu gegriffen. Durch das zusätzliche Anhängen von  „/server“ ist es möglich, alle Servernamen und deren zugehörigen Server-IDs aus i-doit auszulesen.

{
  • "Server_A" : 66273,
  • "Server_B" : 94647,
  • „Server_C“ : 21221,
  • „…“: ….
}

Der große Vorteil einer solchen Webanwendung ist, dass man durch Erweiterung eine Automatisierung erreichen kann. Erhält man z.B. einen neuen Server, der mittels Puppet provisioniert wurde, kann vom Puppetmaster ein Objekt im i-doit angelegt werden. Hierzu kann damit auch auf alle ermittelten Facts zurückgegriffen werden. Diese sind dann über das zu erweiternde Skript an die API weiterzugeben, um final ein Server-Objekt mit allen angereicherten Informationen zu erhalten.

AJAX mit Ruby on Rails und :remote => true

Mit :remote => true bietet das das Ruby Webframework Rails eine sehr einfache Methode um mit Hilfe von AJAX eine Webseite zu aktualisieren. Dieses kann z.B. einfach zu HTML-Elementen wie Formulare, Buttons, Links und Checkboxen hinzugefügt werden. Dadurch werden z.B. gefüllte Formulare nicht mehr wie gewohnt an den Webserver gesendet, sondern mit AJAX. Man erspart dem Benutzer dadurch einen lästigen ggf. langwierigen Seitenaufbau. Im Gegenzug muss man sich aber selber um eine Aktualisierung der Webseite mit Hilfe von jQuery oder JavaScript kümmern.

Folgender Code in einem View erstellt eine Checkbox welche bei einem Klick mit Hilfe von AJAX einen HTTP Post an die angeben URL sendet:

[ruby]
check_box_tag(
"my_checkbox", "i_am_checked", false,
data: {
remote: true,
url: "my_checkbox/click",
method: "POST"
}
)
[/ruby]

Der Request muss in diesem Fall vom my_checkbox Controller angenommen und verarbeitet werden. Um die Ansicht des Benutzers zu ändern schickt man mit den bekannten Rails Methoden Javascript an den Browser zurück. Im my_checkbox_controller.rb erweitert man z.B. die respond_to einfach um ein format.js:

[ruby]
def click
respond_to do |format|
format.js {}
end
end
[/ruby]

Der dazugehörigen View (click.js.erb) wird somit an den Browser zurück gesendet und man kann per JavaScript die Webseite aktualisieren:

[javascript]
console.log(‚I am the response!‘)
alert(‚You clicked the checkbox!‘)
[/javascript]

Rails bietet mit :remote=>true somit eine wirklich einfach Methode um AJAX für seine Webseite einzusetzen!

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.

Ruby Applikationen testen mit RSpec und WebMock

Das Testen von Software begleitet mich von Projekt zu Projekt. Bei bisherigen Entwicklungen habe ich immer wieder auf RSpec zurück gegriffen, ein tool zum testen von Ruby Applikationen. Es zeichnet sich durch eine relativ einfache Handhabung aus und eine Ausdrucksweise die an die menschliche Sprache angelehnt ist. Auch wenn nicht jeder mögliche einzutretende Fall getestet werden kann, tests geben Entwicklern Sicherheit wenn Änderungen am Code vorgenommen werden.

WebMock

WebMock ist eine Library die es einem ermöglich HTTP requests auszudrücken und Erwartungen an diese zu setzen. In Verbindung mit RSpec lässt sich WebMock verwenden um eine Ruby Anwendung zu testen die HTTP Requests ausführt, beispielsweise an eine API. Oft sind diese Requests nicht starr sondern werden dynamisch anhand von Parametern zusammen gesetzt. WebMock/RSpec hilft dabei unterschiedliche Fälle zu simulieren, Erwartungen zu definieren und diese mit zu prüfen.
WebMock ist als Gem verfügbar, die Installation ist daher relativ einfach:

user@localhost ~ $ gem install webmock

Als Beispiel verwende ich eine sehr simple Ruby Klasse. Deren einzige Methode ‘request’ sendet einen GET request an die URL ‘https://wtfismyip.com’. Abhängig vom Parameter ‘option’ wird die IP entweder in Textform oder als JSON abgefragt:

require 'net/http'
require 'uri'
class ApiCaller
  def self.request(option)
    uri = URI.parse("https://wtfismyip.com/#{option}")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    request = Net::HTTP::Get.new(uri.request_uri)
    http.request(request)
  end
end

Mein Test beinhaltet den Aufruf der ‘request’ Methode. Der HTTP request wird simuliert und die Erwartung das ein Request an eine bestimmte URL stattfinden soll wird auch definiert.

require 'api_caller'
require 'webmock/rspec'
describe ApiCaller do
  describe '.request' do
    context 'given json parameter' do
      it 'requests json url' do
        stub_request(:get, 'https://wtfismyip.com/json')
        expect(ApiCaller.request('json')).
          to have_requested(:get, 'https://wtfismyip.com/json').once
      end
    end
    context 'given text parameter' do
      it 'requests text url' do
        stub_request(:get, 'https://wtfismyip.com/text')
        expect(ApiCaller.request('text')).
          to have_requested(:get, 'https://wtfismyip.com/text').once
      end
    end
  end
end

Beim testen sieht das nun folgendermaßen aus:

user@localhost ~ $ rspec --format documentation
ApiCaller
  .request
    given json parameter
      requests json url
    given text parameter
      requests text url
Finished in 0.00557 seconds (files took 0.37426 seconds to load)
2 examples, 0 failures
Blerim Sheqa
Blerim Sheqa
COO

Blerim ist seit 2013 bei NETWAYS und seitdem schon viel in der Firma rum gekommen. Neben dem Support und diversen internen Projekten hat er auch im Team Infrastruktur tatkräftig mitgewirkt. Hin und wieder lässt er sich auch den ein oder anderen Consulting Termin nicht entgehen. Inzwischen ist Blerim als COO für Icinga tätig und kümmert sich dort um die organisatorische Leitung.

Clustershell und Foreman-API

i-love-apisForeman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells „csshX“ im Einsatz, welches ich auch direkt mit eingebunden habe.
Das get_hosts Script gibt es als GIST.
In diesem Script wird zunächst eine „config.yml“ geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter „-s / –server“ gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.
Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)
Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: „Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?“
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.
user@computer ~/Documents/ruby/foreman $ ruby script.rb
Enter password:
[ ] Trying to establish a connection...
[OK] Password correct
[OK] Connection established
[ ] Collecting data...
[OK] Data collected
[RESULTS]
Ubuntu
csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de
Debian
csshX --login root icinga-002.test.de db-003.test.de db-021.test.de
Finished succesfully

Wie bereits erwähnt, ist hierfür noch eine „config.yml“ Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem „bundle install“ können diese installiert werden)
Die config.yml und das Gemfile gibt es ebenfalls als GIST.
Eingebaute „rescue Execptions“ im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

May I introduce the Rubocop

When you are into developing Ruby code, or even Ruby near stuff like Puppet modules, or Chef cookbooks, there is a nice tool you should have a look at.
The RuboCop can help you writing better Ruby code, it certainly did it for me.
In short words, RubyCop is a code analyzer that checks Ruby code against common style guidelines and tries to detect a lot of mistakes and errors that you might write into your code.
There are a lot of configuration options, and even an auto-correct functionality, that updates your code.

Simple usage

Either install the gem, or add it to your Gemfile:

gem 'rubocop', require: false

You can just run it without configuration, and it will look for all Ruby files in your work directory.

$ rubocop
Inspecting 19 files
....C............CC
Offenses:
lib/test/cli.rb:3:3: C: Missing top-level class documentation comment.
 class CLI
 ^^^^^
lib/test/cli.rb:36:1: C: Extra empty line detected at method body beginning.
lib/test/cli.rb:41:1: C: Extra empty line detected at block body beginning.
lib/test/cli.rb:45:4: C: Final newline missing.
end
bin/test:12:1: C: Missing space after #.
#api.login('username', 'Passw0rd') unless api.logged_in?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
bin/test:15:3: C: Missing space after #.
 #puts response.code
 ^^^^^^^^^^^^^^^^^^^
bin/test:19:1: C: Missing space after #.
#session.save(file)
^^^^^^^^^^^^^^^^^^^
18 files inspected, 7 offenses detected

You can add it as a rake job to your Rakefile:

require 'rubocop/rake_task'
RuboCop::RakeTask.new
task default: [:spec, :rubocop]

And run the test via your rake tests:

$ rake
$ rake rubocop

Configuration galore

There are a lot of options to modify the behavior and expectations of RuboCop.
Here is a short example I used with recent Puppet module.

require: rubocop-rspec
AllCops:
  TargetRubyVersion: 1.9
  Include:
    - ./**/*.rb
  Exclude:
    - vendor/**/*
    - .vendor/**/*
    - pkg/**/*
    - spec/fixtures/**/*
# We don't use rspec in this way
RSpec/DescribeClass:
  Enabled: False
RSpec/ImplicitExpect:
  Enabled: False
# Example length is not necessarily an indicator of code quality
RSpec/ExampleLength:
  Enabled: False
RSpec/NamedSubject:
  Enabled: False

Where to go next