Ansible can talk to your favorite API

Ansible is a powerful opensource config management and deployment tool, which can manage nearly any situtation. In many “DevOp” scenarios we come across multiple platforms, which we need to combine. Mostly applications provide an REST Api or web connectors to manage resources, jobs and deployments within the product.
Ansible provides various modules which can execute commands at specific APIs, such as the vmware-guest-module to create virtual machines or the jenkins-job-module to manage jobs over the Jenkins API.
In cases where no module is available, we can use the module “uri”.

The module takes several parameters, of which the “url” is the only required one. For this example I picked an example online API “http://dummy.restapiexample.com/”.
To get a list of all employees we use the method GET on http://dummy.restapiexample.com/api/v1/employees, the header Accept: application/json and register the content.


- name: Make requests to example api
  hosts: localhost
  connection: local
  tasks:
    - name: list employees
      uri:
        method: GET
        url: "http://dummy.restapiexample.com/api/v1/employees"
        return_content: yes
        headers:
          Accept: application/json
      register: response

    - debug:
        msg: "{{ response.content }}"

# Result
TASK [list employees] *************************************************************************
ok: [localhost]

TASK [debug] **********************************************************************************
ok: [localhost] => {
    "msg": [
        {
            "employee_age": "23",
            "employee_name": "test",
            "employee_salary": "46000",
            "id": "12008",
            "profile_image": ""
        }
    ]
}

Now we create a new user in our application, for this we talk to a different url http://dummy.restapiexample.com/api/v1/create and send a body with our user to create.
When the api accepts JSON I use a little trick to generate a valid json body out of yaml variables with the Ansible filter to_json

For this we create a variable with the same key value structure as the API expects it, in this case the structure looks like this {“name”:”test”,”salary”:”123″,”age”:”23″}.


- name: Make requests to example api
  hosts: localhost
  connection: local
  vars:
    data:
      chris:
        name: chris
        salary: 46000
        age: 27
      jessy:
        name: jessy
        salary: 70000
        age: 30
  tasks:
    - name: create employee
      uri:
        method: POST
        url: "http://dummy.restapiexample.com/api/v1/create"
        return_content: yes
        headers:
          Accept: application/json
        body_format: json
        body: "{{ item.value | to_json }}" //Render valid json from each dictionary in the variable data.
      with_dict: "{{ data }}"
      register: post_content

    - debug:
        msg: "{{ item.content }}"
      with_items: "{{ post_content.results }}"

# Result
ansible-playbook create_user.yaml

PLAY [Make requests to example api] ********************************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [localhost]

TASK [create employee] *********************************************************************************
ok: [localhost] => (item={'value': {u'salary': 46000, u'age': 27, u'name': u'chris'}, 'key': u'chris'})
ok: [localhost] => (item={'value': {u'salary': 70000, u'age': 30, u'name': u'jessy'}, 'key': u'jessy'})

With this information given, you can now explore your own favorite API and hopefully reduce your daily tasks as simple Ansible playbooks.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message!

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Deployment, aber bitte ohne PXE

Foreman Logo
Es ist schon eine Weile her, dass ich zum Foreman Discovery-Plugin geschrieben hab. Dieses zählt immer noch zu den von mir am meisten genutzten Plugins und wäre mit seinen Neuerungen wie Discovery-Regeln und erweiterbaren Images sicher auch einen neuen Blogpost wert. Aber die häufigste Frage, die mir in dem Zusammenhang gestellt wird, ist “Ich kann/darf unsere DHCP-/PXE-Konfiguration nicht anpassen. Geht das auch ohne PXE?”.
Natürlich kann ich das Discovery-Image auch einfach lokal starten, aber ich möchte eine weitere Lösung in Form des Bootdisk-Plugins für Foreman vorstellen. Dieses bietet zwar nicht die Funktionen wie Discovery-Regeln und darauf basierendes automatisches Deployment, hat aber den Vorteil auch komplett ohne DHCP und TFTP auskommen zu können.
Die Installation ist einfach, da es sowohl für RPM-basierte als auch Deb-basierte Systeme als entsprechendes Paket vorliegt. Nach der Installation einfach noch Foreman durchstarten und es findet sich ein neuer Menü-Paket “Boot disk” auf der Host-Ansicht. Dieser lässt es zu drei verschiedene Arten Installationsabbilder herunterzuladen. Voraussetzung sind hierfür die iPXE-Templates, die allerdings standardmäßig mitgeliefert werden.
Für Umgebungen in denen zwar DHCP genutzt werden kann, aber weder feste Reservierungen noch eine Anpassung der PXE-Konfiguration möglich ist, bietet sich das generische Installationsabbild an. Dieses enthält in ungefähr einem Megabyte Größe nur den Teil der notwendig ist um sich bei Foreman mit einer MAC-Adresse zu melden und die gewünschte Konfiguration zu erfragen. Danach wird der Installer für das entsprechende Betriebssystem aus dem TFTP-Verzeichnis von Foreman heruntergeladen und die Installation anhand von Kickstart, Preseed, etc. beginnt.
Für Umgebungen in denen gar kein DHCP zur Verfügung steht, können individuelle Boot-Medien heruntergeladen werden, die eine statische Netzwerkkonfiguration für die Installation enthalten. Nachdem von diesem gestartet wurde, wird wieder alles weitere nachgeladen und die Installation beginnt.
In Umgebungen oder auf Hardware bei der auch das Nachladen des Installers nicht klappt, können die individuellen “Full Images” verwendet werden, welche auch noch Installer und Installationsanweisungen enthalten. Dies ist natürlich die aufwendigste Variante, da das Image bei jeder Änderung neu erstellt werden muss. Wobei sich natürlich die Frage stellt wie oft der Aufwand tatsächlich betrieben werden muss.
Um nun keine Hamster-Käufe bei CD-Rohlingen auszulösen, handelt es sich bei den Installationsabbildern um hybride Images, die auch direkt auf einen USB-Stick übertragen werden können. Somit kann jeder Foreman-Nutzer dieses Plugin schnell und einfach ausprobieren und wer noch kein Foreman benutzt, aber keine Lust mehr auf manuelle Installationen hat, sollte diesem ein Chance geben. Wer sich bei der Einrichtung helfen lassen möchte, findet diese natürlich bei uns! 😉

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Reminder für das morgige Foreman / OpenNebula Webinar

opennebula_foreman Ich möchte noch einmal alle auf das morgige Webinar zum Thema Foreman: OpenNebula orchestrieren aufmerksam machen. Dabei wollen wir neben dem von NETWAYS entwickelten Modul Foreman-One auch auf Foreman und OpenNebula eingehen.
Ziel wird es aber sein zu demonstrieren, wie über das Foreman-Webinterface eine virtuelle Maschine erzeugt werden kann.
Wer sich für das Webinar noch registrieren will hat bis morgen Früh um 10:30 Uhr noch Gelegenheit dazu. In unserem Webinar-Archiv finden sich bereits einige Webinare zum Thema OpenNebula und Foreman (im Zusammenspiel mit Puppet).
Bis morgen früh um 10:30 Uhr!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Wir sind auf der CeBIT 2013… wie immer halt.

Jaja… alle Jahre wieder CeBIT mit NETWAYS. Was soll man da noch großartig berichten?
Das sind genau die Blogposts, die ich aus tiefstem Herzen hasse, weil man im Grunde nur die CeBIT-Ankündigungs-Posts der vergangenen 378 Jahre kopieren muss, Jahreszahlen und Standnummern aktualisiert  und feddich is die Laube.
Das ist allerdings ausgesprochen langweilig. Sowohl für den Leser, als auch für den Menschen der schreibt. Wenn man den Anspruch hat wenigstens ein ganz kleines bisschen Abwechslung in den Blog zu bringen kann es sogar geradezu nervtötend sein derartige Standartmitteilungen verfassen zu müssen.
Okay – es gibt dann oft noch einen Absatz in dem die latest News stehen, über die man sich auf der Messe von Angesicht zu Angesicht informieren kann und die sind tatsächlich in jedem Jahr anders – ein Lichtblick auch für den Schreiber, der dieses Jahr zum Beispiel so schöne Dinge in die sprachlich angemessene Form gießen könnte wie:
Neben vielen Neuerungen in den Bereichen Open Source Monitoring auf Basis von Icinga und den entsprechenden Addons, werden wir auch Demos zu Puppet und Puppet Enterprise für Sie dabei haben. Auf die Präsentation einer von uns entwickelten  CMDB-Lösung freuen wir uns dabei ganz besonders.
So können Sie sich bei uns von Configuration Management über Deployment und Virtualisierung bis hin zum Monitoring über die aktuellsten Entwicklungen im Bereich Open Source Datacenter Solutions informieren und die verschiedenen Systeme in Demos kennenlernen.
Außerdem könnte ich noch schreiben, dass wir dieses Jahr zum ersten Mal mit OpenNebula im Schlepptau in Hannover sind und deshalb auch Neuigkeiten von unseren Partnern aus erster Hand mitbringen.
Ja, aber dann kommt normaler Weise auch schon wieder ein Absatz, der total langweilig ist und in dem steht wann man uns wo finden kann. Dieses Jahr z.B.  am:
05. – 09. März 2013
Halle 6
Block F16

Stand 330
Den Absatz hasse ich ganz besonders, weil hier kein Spielraum für literarische Extravaganzen und Spielereien ist und ich mich an der Stelle immer ganz besonders unterfordert  fühle.
Und entweder davor oder danach steht dann, dass man gerne auch einen Termin für ein Gespräch auf der CeBIT mit uns vereinbaren kann und sich dafür einfach nur mit entsprechendem Wunschtermin an unser Sales-Team wendet.
Außerdem wird im gleichen Atemzug auch immer darauf hingewiesen, dass wir gerne Freitickets zur Messe vergeben, die man ebenfalls per Mail anfordern kann so lange unser wohl kalkulierter Vorrat reicht.
Und ich mag diese CeBIT-Grafik nicht, die man dann einbauen muss. Schaut euch das doch mal an! Dieses agressive CeBIT-rot! Nicht zum aushalten!
CeBIT
Ganz ehrlich… wenn mich jemand fragen sollte, ob ich dieses Jahr den nervigen CeBIT-Post schreibe, dann werde ich mich einfach weigern.

Serie NSClient++ – Teil 9: Registry

Konfigurationsdatei

Die Konfiguration von NSClient++ wird im Standard in der Datei nsc.ini vorgenommen.
NSClient++ bietet neben dieser Konfigurationsmethode auch die Möglichkeit die Konfiguration in die System Registry auszulagern.
Ein verlagern der Konfiguration aus der Konfigurationsdatein in die Registry bietet u.a. in großen Deployments den Vorteil das man die Konfiguration z.B.: über eine Gruppenrichtlinie verwalten und steuern kann.
Konfigurationsobjekte befinden sich dann unter HKEY_LOCAL_MACHINE\Software\NSClient++ und können von dort aus bearbeitet werden.

Konfiguration auslagern

In der bestehenden Konfigurationdatei muss neben dem Parameter “use_file=1” der Parameter “use_reg=1” ergänzt werden.
Nachdem die nsc.ini diese Option im Bereich “[Settings]” enthält, kann die Konfiguration in die Registry importiert werden.
Für den Import der Konfiguration in die Registry wird das Module RemoteConfiguration verwendet.

C:\Program Files\NSClient++>"nsclient++.exe" -noboot RemoteConfiguration ini2reg
NSCore not loaded...
Archiving crash dumps in: C:\Users\Administrator\AppData\Local\NSClient++\crash dumps
Migrating to registry settings...
importing: modules/FileLogger.dll=
importing: modules/CheckSystem.dll=
...

Nach dem Import finden sich die Objekte, wie bereits erwähnt, unter HKEY_LOCAL_MACHINE\Software\NSClient++ in der Registry wieder.
Damit NSClient++ nun nicht weiterhin die Konfigurationsdatei nutzt muss die Option “use_file=” deaktiviert werden (“use_file=0”) und der NSClient++ Service neugesartet werden.

net stop nsclientpp
net start nsclientpp

Die Einstellungen der Registry können nun auf andere Windows-Server verteilt werden (z.B.: mittels GroupPolicy oder SoftwareDeployment Lösung). NSClient++ benötigt jedoch weiterhin einen gewissen Teil der nsc.ini, die Einstellungen in der Sektion [Settings] und die Auflistung der zu ladenden Module.