Der Icinga Buildserver, Version 3

Letztes verbliebene Bild des alten Icinga Jenkins

Der Icinga-Buildserver, erreichbar unter https://build.icinga.com, läuft in dieser Form jetzt etwa ein Jahr. Doch gibt es noch immer ein paar Probleme die mit diesem Setup bestehen: So ist das Hinzufügen neuer Jobs noch etwas umständlich, das provisionieren dauert länger als uns lieb ist und besonders übersichtlich ist die Konfiguration auch nicht. Um diese Probleme anzugehen haben wir uns noch einmal mit Puppet und Jenkins auseinandergesetzt.

Wie vorher verwenden wir ein jenkins puppet-modul, nur diesmal haben wir es mit einem speziellen icinga-jenkins Modul erweitert. Dieses Modul erlaubt es uns spezielle pipeline-jobs mit geringem Konfigurationsaufwand zu erstellen. So ist das unterstehende Beispiel alles was zu konfigurieren ist um eine komplette Pipeline zu erstellen. Selbst der spezielle Umgang mir RPM und Deb ist zu großen Teilen vereinheitlicht und funktioniert für alle Projekte gleich.

icinga_build::pipeline:
  icinga2-snapshot:
    control_repo: https://github.com/Icinga/icinga-packaging.git
    control_branch: snapshot
    matrix_deb:
      'debian-jessie': {}

Die Pipeline erstellt dabei nicht nur einen, sondern gleich vier Jobs: “source”, “binary”, “test” und “publish”. Diese verarbeiten die specfiles, bauen das Paket, testen es und veröffentlichen es auf https://packages.icinga.com

In Produktion ist unser Modul noch nicht, aber um den testen und konfigurieren zu können haben wir Vagrant Boxen gebaut. Mit Hilfe derer bauen wir zur Zeit das icinga-jenkins Modul weiter aus um den bestehenden Buildserver komplett mit den neuen Pipelinejobs abbilden zu können. Wir hoffen unseren Buildprozess damit noch einfacher für Entwickler zu machen und dank der neuen Testsphase für Pakete Problemen in Zukunft besser vorzubeugen zu können

Jean-Marcel Flach

Autor: Jean-Marcel Flach

Auch wenn man Anderes vermuten möchte: Jean ist nicht unser französischer Austauschazubi, sondern waschechter Bamberger. Die Uni war ihm zu langweilig, deshalb knöpft er sich nun im Development gleich die kniffligsten Aufgaben vor.

Chef Cookbook Integration Tests mit TestKitchen

Infrastructure as Code ist zu einem der wichtigsten Themen angewachsen mit denen sich Admins und ganze IT Abteilungen beschäftigen. Wie immer wenn es um Code geht, spielt die Qualität von diesem eine wichtige Rolle. Wenn man seine Chef Cookbooks nicht gerade nur für sich selbst schreibt, sondern gern auch veröffentlichen möchte, gehört Qualität zum guten Ton. Eines der Qualitätsmerkmale ist die Anwendbarkeit des Cookbooks auf verschiedene Betriebssysteme und Versionen. Hier beginnt auch schon die Schwierigkeit: Oft wird ein Cookbook für das System geschrieben das man selbst verwendet, schlicht, weil man andere Systeme ja nicht zum Testen hat. Sicherlich ist die Zeit ein wichtiger Faktor dabei, es hat aber auch kaum jemand Lust dazu sich mit der Installation von mehreren VMs zu beschäftigen. Um richtig testen zu können, müssen diese ja auch regelmäßig zurückgesetzt werden. Abhilfe schafft da das Chef Development Kit (ChefDK).

ChefDK
Im Development Kit sind alle Tools enthalten die man braucht zum Cookbooks zu entwickeln, testen und maintainen. Es ist zudem für alle großen Betriebssysteme verfügbar. Mit dem Commandline tool chef kann man die ersten Schritte gehen: Cookbook generieren, templates anlegen etc. Auch mit dem zentralen Server kann man kommunizieren, etwa um Cookbooks zu installieren. Ein Chef Client ist im Kit auch enthalten, mit ihm lassen sich Cookbooks direkt ausführen. Das Chef Ökosystem bietet relativ viel um Cookbooks zu testen, das Wichtigste ist im ChefDK mit drin:

TestKitchen
Nun also zurück zum Problem mit dem testen von verschiednen Betriebssystemen und deren Versionen. TestKitchen zielt genau darauf ab, dieses Problem zu lösen. In einer Yaml Datei (.kitchen.yml) wird eine Testmatrix angelegt die festlegt, was genau getestet werden soll. Dazu gehören die Betriebsysteme, deren Versionen und eine oder mehrere Suites die auf diese angewendet werden sollen. Suites bestehen aus einer Liste von Recipes die ausgeführt werden. Dazugehörige Attribute können ebenfalls gesetzt werden. Beispielhaft sieht das dann so aus:

---
driver:
  name: vagrant

provisioner:
  name: chef_zero

platforms:
  - name: ubuntu-16.04
  - name: centos-7.2
  - name: windows-2012r2

suites:
  - name: icinga2server
  run_list:
    - recipe[icinga2::server]
  attributes:
    icinga2:
      version: '2.4.10-1'

Mit dem CLI Kommando kitchen kann das Cookbook jetzt auf den aufgelisteten Plattformen ausgeführt werden. Voraussetzung in diesem Beispiel ist, dass Vagrant installiert ist. Auch andere Driver können verwendet werden, Beispiele dafür wären Docker, HyperV oder OpenNebula. Eine gesamte liste findet man in der Dokumentation.

kitchen test

Das Kommando führt ein mal den gesamten Ablauf durch: VMs erstellen, Cookbook ausführen, Zustand prüfen und VMs wieder zerstören. Für jede Kombination zwischen Plattform und Suite werden mithilfe von Vagrant virtuelle Maschinen erstellt. Die dazugehörigen Boxen werden Standardmäßig von Bento angezogen. Beim ausführen sollte man aber vorsichtig sein, je nachdem wie viele Tests und Plattformen man aufgelistet hat, kann das zu relativ vielen VMs führen, was dann gerne auch mal dazu führt, dass das eigene System lahmgelegt wird.

Um das Problem zu umgehen können einzelne Instanzen erstellt werden, indem man genau angibt welche Kombination man testen möchte:

kitchen setup server-ubuntu-1604

Dieses Kommando wird eine VM mit Ubuntu 16.04 erzeugen, einen Chef Client auf dieser installieren und das Cookbook ausführen. Im Idealfall steht dann eine VM auf dem das Cookbook erfolgreich ausgeführt wurde. Man kann sich auf dieser dann auch einloggen, um ggf. manuell zu prüfen ob alles glatt gelaufen ist:

kitchen login icinga2server-ubuntu-1604

Eine Liste aller Instanzen bekommt man mit kitchen list

Zu diesem Zeitpunkt hat man zumindest die Gewissheit, dass das besagte Cookbook generell lauffähig ist und keine Fehler wirft. Ob aber tatsächlich der gewünschte Zustand erreicht ist, ist noch unklar. In Kombination mit TestKitchen lässt sich ein Zustand am besten mit ServerSpec ermitteln.

ServerSpec
Mit ServerSpec werden RSpec Tests geschrieben die den tatsächlichen Zustand eines hosts prüfen. Es wird nicht nur in Kombination mit Chef verwendet, sondern auch mit den meisten anderen Configuration Management Tools.

TestKitchen erwartet die ServerSpec Tests im Verzeichnis test/integration. Jede Suite erhält ihr eigenes Verzeichnis in dem die entsprechenden Dateien liegen in denen beschrieben ist was geprüft werden soll:

test
`-- integration
|-- icinga2server
| `-- serverspec
| |-- icinga2server_spec.rb

Beispielhaft könnte eine icinga2server_spec.rb folgenden Inhalt haben:

require 'serverspec'
require 'pathname'

set :backend, :exec
set :path, '/bin:/usr/local/bin:$PATH'

describe package(“icinga2”) do
  it { should be_installed }
end

describe service('icinga2') do
  it { should be_running }
end

Dabei wird geprüft ob auf dem System das Paket icinga2 tatsächlich installiert ist und ob der Service icinga2 läuft. Ausgedrückt werden Tests in einer relativ einfach verständlichen “Sprache”, da Begriffe und Aufbau stark an die menschliche Sprache angelehnt sind.

Aus den vorherigen Schritten sollte mindestens schon eine VM bereit stehen auf der die ServerSpec tests jetzt angewendet werden können:

kitchen verify icinga2server-ubuntu-1604

Im besten Fall ist die Ausgabe positiv

bsheqa@blerims-mbp ~/git/github/chef-icinga2 (feature/testkitchen-12286) $ kitchen verify client-ubuntu-1404
-----> Starting Kitchen (v1.10.2)
-----> Verifying ...
Preparing files for transfer
[…]

Package "icinga2"
should be installed

Service "icinga2"
should be running

Finished in 0.14585 seconds (files took 0.36682 seconds to load)
2 examples, 0 failures

Finished verifying (0m2.89s)

Mit diesem gesamten Workflow nimmt TestKitchen einem sehr viel Arbeit ab, die man sonst verwenden müsste, um virtuelle Maschinen zu pflegen und nachzusehen, ob alles so angewendet wurde, wie es im Cookbook beschrieben ist. Integration Tests selbst helfen dabei ein Gefühl dafür zu bekommen, wie sich das Cookbook als Ganzes unter verschiedenen Umgebungen mit unterschiedlichen Attributen verhält. Mit entsprechenden ServerSpec Tests gewinnt man endgültig die Sicherheit, das alles wirklich so funktioniert, wie es soll.

Blerim Sheqa

Autor: Blerim Sheqa

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. Mittlerweile kümmert sich Blerim hauptsächlich im Icinga Umfeld um die technischen Partner und deren Integrationen in Verbindung mit Icinga 2.

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

Vagrant-Box mit Icinga2 mit Icingaweb2 aufsetzen

virtualboxAls Entwickler und Systemadministrator kommt man öfters nicht um eine Testmöglichkeit herum.
Eine VM mit einem Hypervisor seiner Wahl aufzusetzen ist meistens sehr zeitaufwendig um kleinere Tests nachzustellen.
Eine einfache und schnelle Möglichkeit bietet hier sich eine Vagrant-Box vom Internet herunter zu laden oder sich ein Git-Repositoriy mit einem vorgefertigten Image zu clonen.
Wie man sich so eine Vagrant-Box per Git cloned werde ich hier beschreiben.

 

Vorraussetzung: Virtualbox-Pakete + GIT sollten installiert sein (Virtualbox wird hier als Provider benutzt):

~ # rpm -qa | grep virtualbox
virtualbox-5.0.18-216.2.x86_64
virtualbox-guest-tools-5.0.18-216.2.x86_64
virtualbox-host-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
virtualbox-qt-5.0.18-216.2.x86_64
virtualbox-guest-kmp-default-5.0.18_k4.1.12_1-216.2.x86_64
git-2.6.6-7.1.x86_64

Info: Die Version kann von den verschiedenen Distributionen variieren.

Als nächsten müssen wir das Git-Repository lokal clonen
Dazu ins home – Verzeichnis in der Shell seiner Wahl wechseln
Ein Verzeichnis seiner Wahl anlegen:
mkdir git z.B

und in diesem Verzeichnis folgendes Kommando ausführen als user versteht sich:

~ # git clone https://github.com/Icinga/icinga-vagrant
Klone nach 'icinga-vagrant' ...
remote: Counting objects: 5172, done.
remote: Total 5172 (delta 0), reused 0 (delta 0), pack-reused 5172
Empfange Objekte: 100% (5172/5172), 1.53 MiB | 569.00 KiB/s, Fertig.
Löse Unterschiede auf: 100% (1929/1929), Fertig.
Prüfe Konnektivität ... Fertig.

So das wars auch fast schon 🙂

Jetzt z.B in das Verzeichnis Icinga2x-cluster wechseln
~ # cd icinga-vagrant/icinga2x-cluster/

Anschließend nur noch die Vagrant-Box starten:
~ # vagrant up

Nun kann es eine Weile dauernd bis die Box gebaut wird, wenn keine Fehler aufgetreten sind kann man sich per ssh connecten.
~ # vagrant ssh
[vagrant@icinga2 ~]$

Weitere vagrant Kommandos:

vagrant help    -> Listet weitere Kommandos von vagrant auf
vagrant halt  -> fährt  die Vagrant-Box herunter  (shutdown)
vagrant reload -> starten die Vagrant-Box neu (reboot)

Login-Information bekommt man direkt auf:
https://github.com/Icinga/icinga-vagrant/

Icingaweb2 nach erfolgreichen Login:

Screenshot_20160603_105621

Viel Spaß beim testen, basteln und herumspielen 🙂

Es lohnt sich auch immer mal unser Schulungsangebot sich anzuschauen.

Johannes Carraro

Autor: Johannes Carraro

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren

Hurra, Hurra der Osterhase war da!

OsternUnd so wartete auf alle NETWAYS Mitarbeiter bereits heute ein Schokohase auf dem Schreibtisch.

Doch der NETWAYS Osterhase ist in diesem Jahr so gut gelaunt und dadurch spendabel, dass er nicht nur die eigenen Schäfchen, sondern auch Familie und Freunde beschenken möchte. Er hat dafür einen 10% Rabattcode für alle Schulungen mitgebracht. Also am besten sofort, oder aber spätestens bis 30. April zu einer NETWAYS Schulung anmelden, OSTERN10% in als Rabatt- / Gutscheincode eintragen und damit sich selbst beschenken!

Und was gibt es da so im Osternest?

Demnächst stehen in Nürnberg folgende Schulungen an:

Da war jetzt nicht ganz das richtige Thema dabei? Oder die Termine sind zu kurzfristig? Natürlich gilt das Geschenk für unser komplettes Schulungsangebot!

Daniela Schwarz

Autor: Daniela Schwarz

Daniela ist seit 2012 unser Designprofi und verantwortlich dafür, dass all unsere Grafiken unverwechselbare Unikate sind. Sie sorgt bei den Logos auf unserer Website, den Schulungsprintanzeigen bis zu den Menükarten auf den Abendveranstaltungen unserer Konferenzen für den richtigen optischen Schliff. Privat äußert sich ihre Kreativität beim Basteln mit Fimo.

Ein lokales Puppet Development Environment muss her

Wenn man für Puppet Code oder Module entwickeln möchte gibt es verschiedene Ansätze die man nutzen kann:

  • locale Entwicklung, git pushen, in Entwicklungs-Environment auf produktivem Puppetmaster testen
  • lokale Entwicklung, VM mit Puppet Agent, puppet apply nutzen
  • lokale Entwicklung, VMs Puppetmaster/Puppetserver mit Puppetdb Anbindung und einer oder mehrere Clients mit Puppet Agent

Wir wollen uns hier die dritte Möglichkeit anschauen. Als Basis nutzen wir Vagrant, eine Automatisierungsplattform für reproduzierbare Entwicklungsumgebungen.Die Virtualisierung übernimmt in dem Fall  Virtual Box.Vagrant nutzt zum Provisionieren der VMs zwei verschiedene Teile:

  • sogenannte Base Boxes, ein Basisimage, auf dem alles weitere aufsetzt
  • Das sogenannte Vagrantfile das diese Box kopiert, startet und in den gewünschten Zustand überführt.

Das schöne ist Vagrantfiles und Base Boxes (sofern sie selbstgebaut sind) lassen sich wunderbar unter Versionskontrolle stellen und mit mehreren Leuten weiterentwickeln. Und das Ergebnis sieht am Ende bei jedem gleich aus, ohne das man sich ein Bein dafür ausreissen muss.

Wie sieht jetzt eine fertige Entwicklungs Umgebung aus mehreren VMs aus?

  • puppet (Puppetmaster/Puppetserver)
  • puppetdb (PuppetDB API Teil)
  • postgres-puppetdb (PuppetDB Datenbank Backend)
  • puppetclient01 (Puppet Agent, für diesen Node wird Entwickelt)

Um nun die Entwicklungsumgebung aufzubauen checkt man folgendes Git aus und installiert Virtual Box und Vagrant. Jetzt wechselt ins Repository und führt das Script yes_create_a_puppet_development_environment.sh aus. Nun entscheidet man sich für eine Puppetversion, wir nehmen Version 4. Nach ca. 20 Minuten hat man eine laufende Entwicklungsumgebung. Man hat jetzt die Wahl ob man aus dem Vagrant Ordner entwickelt oder die Grundlage in ein neues Git überführt und dieses seperat mountet. Eine Anleitung dazu findet sich in der Readme, genau wie geplante Features und Bugs

Das Git Repository für die Base Boxen findet sich Hier und die Boxen können mit Packer zu Images gebaut werden.

Simon Hönscheid

Autor: Simon Hönscheid

Simon ist in der Nähe von Köln geboren und lebt seit einigen Jahren in Berlin. Er arbeitet bei NETWAYS als Senior Consultant und hat schon während der Ausbildung zum Fachinformatiker für Systemintegration die Themen Automatisierung, Monitoring, Backup und Wissenstransfer für sich entdeckt. Wenn er grade nicht arbeitet macht er gerne Sport, Fotografiert, hört Musik oder lernt neue Dinge.

Awesome Dashing dashboards with Icinga 2

vagrant_dashingWe at NETWAYS are using Dashing on our office dashboards already. This blog post solely targets integrating yet another new API providing data – the Icinga 2 REST API introduced in v2.4.

The following instructions were taken from the existing Vagrant boxes and their puppet manifests to allow faster installation. Doing it manually shouldn’t be an issue though 😉

Requirements

Ensure that the following packages are installed, example for RHEL 7 with EPEL enabled:

package { [ 'rubygems', 'rubygem-bundler', 'ruby-devel', 'openssl', 'gcc-c++', 'make', 'nodejs' ]:
  ensure => 'installed',
  require => Class['epel']
}

Furthermore put a specific /etc/gemrc file which disables installing the documentation for gems – this can take fairly long and is not required by default. Especially not when provisioning a Vagrant box or a Docker container.

dashing-icinga2

I’ve created that project as demo for Icinga Camp Portland with the help of the existing Icinga 1.x dashing scripts from Markus, and a new job for fetching the Icinga 2 status data from its REST API.

Clone the git repository somewhere applicable. You don’t need any webserver for it, Dashing uses Thin to run a simple webserver on its own.

vcsrepo { '/usr/share/dashing-icinga2':
  ensure   => 'present',
  path     => '/usr/share/dashing-icinga2',
  provider => 'git',
  revision => 'master',
  source   => 'https://github.com/Icinga/dashing-icinga2.git',
  force    => true,
  require  => Package['git']
}

Install the dashing gem

The installation might take pretty long when it tries to install the gem’s documentation files. Therefore the flags “–no-rdoc” and “–no-ri” ensure that this isn’t done and only the dashing gem and its dependencies are installed into the system.

exec { 'dashing-install':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "gem install --no-rdoc --no-ri dashing",
  timeout => 1800
}

Install the gems for dashing-icinga2

Next to the dashing application itself the project requires additional gems, such as a rest client for communicating with the Icinga 2 REST API (check the Gemfile for details). Additionally the bundled gems are not installed into the system’s library but locally into the dashing-icinga2 git clone underneath the “binpaths” directory (this is to prevent conflicts with rubygem packages in the first place).

exec { 'dashing-bundle-install':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "cd /usr/share/dashing-icinga2 && bundle install --path binpaths", # use binpaths to prevent 'ruby bundler: command not found: thin'
  timeout => 1800
}

Dashing startup script

Put a small startup script somewhere executable to (re)start the Dashing application.

file { 'restart-dashing':
  name => '/usr/local/bin/restart-dashing',
  owner => root,
  group => root,
  mode => '0755',
  source => "puppet:////vagrant/files/usr/local/bin/restart-dashing",
}

Dashing runs as Thin process which puts its pid into the local tree. It is merely all about killing the process, removing the pid and then starting dashing again. “-d” puts the process into daemonize mode (not foreground) as well as “-p 8005” tells the application where to listen for browsers connecting to. Adjust that for your needs 🙂

#!/bin/bash

cd /usr/share/dashing-icinga2
kill -9 $(cat tmp/pids/thin.pid)
rm -f tmp/pids/thin.pid
/usr/local/bin/dashing start -d -p 8005

Now run Dashing.

exec { 'dashing-start':
  path => '/bin:/usr/bin:/sbin:/usr/sbin',
  command => "/usr/local/bin/restart-dashing",
  require => Service['icinga2'],
}

Configure the Icinga 2 API

The dashing job script just requires read-only access to the /v1/status endpoint. Being lazy I’ve just enabled everything but you should consider limited access 🙂

object ApiUser "dashing" {
  password = "icinga2ondashingr0xx"
  client_cn = NodeName
  permissions = [ "*" ]
}

Configure the Dashing job

There’s a bug in Dashing where job scripts ignore the settings from the config.ru file so there is no other way than to put the Icinga 2 REST API credentials and PKI paths directly into the jobs/icinga2.rb file.

$node_name = Socket.gethostbyname(Socket.gethostname).first
if defined? settings.icinga2_api_nodename
  node_name = settings.icinga2_api_nodename
end
#$api_url_base = "https://192.168.99.100:4665"
$api_url_base = "https://localhost:5665"
if defined? settings.icinga2_api_url
  api_url_base = settings.icinga2_api_url
end
$api_username = "dashing"
if defined? settings.icinga2_api_username
  api_username = settings.icinga2_api_username
end
$api_password = "icinga2ondashingr0xx"
if defined? settings.icinga2_api_password
  api_password = settings.icinga2_api_password
end

Modifications?

You really should know your HTML and Ruby foo before starting to modify the dashboards. The main widget used inside the dashboards/icinga2.erb file is “Simplemon” defined as data-view attribute. It is already provided inside the dashing-icinga2 repository. data-row and data-col define the location on the dashboard matrix.

    <li data-row="2" data-col="2" data-sizex="1" data-sizey="1">
      <div data-id="icinga-host-down" data-view="Simplemon" data-title="Hosts Down"></div>
    </li>

The important part is the data-id attribute – that’s the value coming from the icinga2 job defined in jobs/icinga2.erb.

The job update interval is set to 1 second in jobs/icinga2.erb:

SCHEDULER.every '1s' do

Connecting to the Icinga 2 REST API, fetching the status data as JSON and then iterating over these dictionaries is pretty straight forward. Additional programming examples can be found inside the Icinga 2 documentation.

Take the “hosts down” example from above:

hosts_down = status["num_hosts_down"].to_int

Now send the event to dashing by calling the send_event function providing the previosuly extracted value and the demanded color.

  send_event('icinga-host-down', {
   value: hosts_down.to_s,
   color: 'red' })

In case you’re wondering which values are fetched, let dashing run in foreground and print the “status” dictionary to get an idea about possible keys and values. Or query the Icinga 2 REST API with your own client first.

More?

You can play around with an already pre-installed environment inside the icinga2x Vagrant box and if you’re interested in an automated setup, check the puppet provisioner manifest.

I’m fairly certain that I might improve these puppet manifests after joining the NETWAYS Puppet Practitioner & Architect trainings in February 😉 In case you’ll need your own dashboards and custom modifications, just ask 🙂

Michael Friedrich

Autor: Michael Friedrich

Michael ist seit vielen Jahren Icinga Developer und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht im Monitoring-Portal helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst das schöne Nürnberg. Oder - at an Icinga Camp near you 😉