Schleifen mit Puppet 4

War es bisher mit Puppet notwendig über eine Defined Ressource zu iterieren, ist dies nun in Puppet 4 in einer normalen Klasse möglich.
Als Beispiel nehmen wir eine internationale Firma. Diese Firma hat auf Ihrem Webserver Webseiten für Deutschland, England und Frankreich. nun möchte man für bestimmte Virtual Hosts den Webroot in dem die Seite liegt evtl. an einer anderen Stelle haben.

Dazu definieren wir einen Hash über den wir anschließend iterieren werden.

Folgender Hash kommt aus Hiera:

nginx::vhost::vhosts:
  'www.firma.de':
    webroot_ensure: 'present'
    web_root_directory: '/var/www/www.firma.de'
  'www.firma.co.uk':
    webroot_ensure: 'present'
    web_root_directory: '/var/www/www.firma.co.uk'
  'www.firma.fr':
    webroot_ensure: 'present'
    web_root_directory: '/opt/www/www.firma.fr'

Und hier der Puppetcode:

class nginx::vhost(
  Hash $vhosts = hiera_hash('nginx::vhost::vhosts', {}),
){
 
  file { ['/var/www', '/opt/www']:
    ensure  => directory,
    owner   => 'www-data'
    group   => 'www-data'
    mode    => '0755'
  }
 
  $vhosts.each |$key, $value| {
    $vhost_name = $key
    $webroot_ensure = $value['webroot_ensure']
    $web_root_directory = $value['web_root_directory']
 
 
    if $webroot_ensure == 'present' {
      $create_webroot = 'directory'
      $force_webroot = false
      $webroot_action = 'creating'
    }
    elsif $webroot_ensure == 'absent' {
      $create_webroot = 'absent'
      $force_webroot = true
      $webroot_action = 'removing'
    }
    else {
      fail("Unknown value ${webroot_ensure} for parameter 'webroot_ensure'")
    }
 
    file { "${webroot_action} Webroot ${web_root_directory} for ${vhost_name}":
      path    => $web_root_directory,
      ensure  => $create_webroot,
      force   => $force_webroot,
      owner   => 'www-data'
      group   => 'www-data'
      mode    => '0755'
    }
  }
}

Mit $vhosts.each wird über jedes Hash-Element iteriert. Der Key ist dabei der Domainname. In $value stehen dann die jeweiligen Unterschlüssel. Mit $value[‘Unterschlüssel’] greift man auf den Wert des jeweiligen Unterschlüssels im Hash zu.

Die Möglichkeit Schleifen in normalen Klassen zu nutzen ist definitiv eine der nützlichsten Neuerungen in der Puppet DSL. Viel Spass beim ausprobieren!

Selbstentwickelte Anwendungen überwachen

Die Basis

Bei selbstentwickelten Anwendungen stellt sich häufig die Frage wie sich diese im Monitoringsystem überwachen lassen.
Häufig läuft es dann darauf hinaus das einzelne Komponenten der Anwendung überwacht werden. Der Webserver, die Datenbank, eventuell der Applicationserver oder die Messagequeue die von der Anwendung benötigt wird. Das alles ist ein Solides Grundgerüst auf dem sich aufbauen lässt.

Die Anwendung verrät Ihren Status

In einer agilen (Web-)Plattform ist es aber hilfreich wenn die Anwendung etwas über ihren Status verrät. Welches Softwarelease ist ausgerollt und passt die Version des Datenbank Schemas zu dieser Version? Erreicht der Server seine Failover Systeme und sind diese OK?

Die Software kann aber noch mehr über sich verraten. Wie ist der Gesamtstatus der Software? Dieser ist nur OK wenn alle einzelnen Prüfungen OK sind.

Wünschen sich Entwickler oder Admins bestimmte Infos auf einer Infoseite oder einer API, lassen sich diese häufig recht einfach implementieren.

Hier das Beispiel einer möglichen API Ausgabe:

{
  "health": {
    "status": "OK"
  },
  "checks": [
    {
      "version": "1.0.1"
    },
    {
      "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
    },
    {
      "nodeid": "node2"
    }
  ],
  "cluster": [
    {
      "node1": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    },
    {
      "node2": [
        {
          "status": "MAINTENANCE"
        },
        {
          "version": "1.0.1"
        },
        {
          "commit": "338308edb94efb7e54e609d5a8ee3f5df78595d0"
        }
      ]
    },
    {
      "node3": [
        {
          "status": "OK"
        },
        {
          "version": "1.0.2"
        },
        {
          "commit": "f28d07c9ec90a4f17b446de060c44cf6ff379de5"
        }
      ]
    }
  ]
}

Die Informationen im Monitoring nutzen

Im Monitoring lassen sich einzelne Werte zum Beispiel mit check_http auswerten, indem man auf den zu erwartenden String prüft. Mit check_multi lassen sich diese Infos dann mit anderen Checks verknüpfen. Die Kollegen in der Rufbereitschaft freuen sich über weitere Anhaltspunkte, wo das Problem zu suchen ist.

Hilfe bei der Automatisierung

Diese Infos sind zum Beispiel bei Continuous Delivery Szenarien enorm hilfreich. Das CI System kann prüfen ob der Rollout der ersten Knotens erfolgreich war und diesen dann z.B. über einen API Call wieder als Live markieren, das Monitoring System beendet die Downtime und der Loadbalancer nimmt den Knoten wieder in die Verteilung.

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.