Icinga 2 – Monitoring automatisiert mit Puppet Teil 14: Profile Part VI

This entry is part 14 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Nachdem letzte Woche der Nginx verwendet wurde, wenden wir uns im nun vorerst letzten Teil der Konfiguration des Apaches als Webserver zur Auslieferung von Icinga Web 2 zu.
Der Apache kommt unter Debian als abhängig zu installierendes Paket von icingaweb2 mit und wird ensprechend konfiguriert. Damit dies unsere Anforderung an den Apache nicht wieder überschreibt, sorgen wir dafür, dass das Paket icingaweb2 vor der Klasse apache installiert wird. Hierfür müssen wir das Managment des Pakets durch die Klasse icingaweb2 unterbinden.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse apache aus dessen Modul.

 
  
if $web_server == 'nginx' {
     [...]
  } else {
    #
    # Apache
    #
    $manage_package = false
    Package['icingaweb2']
      -> Class['apache']
    package { 'icingaweb2':
      ensure => installed,
    }
    class { '::apache':
      default_mods => false,
      default_vhost =>false,
      mpm_module => 'worker',
    }
    apache::listen { '80': }
    $web_conf_user = $::apache::user
    include ::apache::mod::alias
    include ::apache::mod::status
    include ::apache::mod::dir
    include ::apache::mod::env
    include ::apache::mod::rewrite
    include ::apache::mod::proxy
    include ::apache::mod::proxy_fcgi
    apache::custom_config { 'icingaweb2':
      ensure       => present,
      source        => 'puppet:///modules/icingaweb2/examples/apache2/for-mod_proxy_fcgi.conf',
      verify_config => false,
      priority      => false,
    }
  }
  [...]

Der Apache wird von uns komplett mit allen Modulen für Icinga Web 2 verwaltet, da sich die Defaults für RedHat und Debian zu sehr unterscheiden. Auch hier, wie bei Nginx, entfernen wird alle Konfiguration sonstiger auszuliefernder Webseiten und benutzen die vom Icinga-Web-2-Modul zur Verfügung gestellt Beispielkonfiguration.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 13: Profile Part V

This entry is part 13 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Im heutigen Teil dieser Reihe, fügen wir den ausstehenden Code zur Konfiguration von Nginx als Webserver für Icinga Web 2 hinzu. Neben den benötigten Nginx-Ressources, vor allem der Umleitung auf den PHP-FPM, ist darauf zu achten, dass Nginx vor der Klasse icingaweb2 und damit vor dem Paket icingaweb2 abzuarbeiten ist. Wird dies nich beachtet installiert das icingaweb2-Paket automatisch den Apache als Abhängigkeit und man hätte zwei Webserver bei sich auf dem Icinga-2-Server.
Damit das Icinga-Web-2-Modul für seine Konfigurationsdateien den korrekten Benutzer verwenden kann, ziehen wir diesen nach der Abarbeitung der Klasse nginx aus dessen Modul.

  [...]
 if $web_server == 'nginx' {
    #
    # Nginx
    #
    $manage_package = true
    Class['nginx']
      -> Class['icingaweb2']
    class { '::nginx':
      manage_repo  => false,
      server_purge => true,
      confd_purge  => true,
    }
    $web_conf_user = $::nginx::daemon_user
    nginx::resource::server { 'icingaweb2':
      server_name          => [ 'localhost' ],
      ssl                  => false,
      index_files          => [],
      use_default_location => false,
    }
    nginx::resource::location { 'icingaweb2':
      location       => '~ ^/icingaweb2(.+)?',
      location_alias => '/usr/share/icingaweb2/public',
      try_files      => ['$1', '$uri', '$uri/', '/icingaweb2/index.php$is_args$args'],
      index_files    => ['index.php'],
      server         => 'icingaweb2',
      ssl            => false,
    }
    nginx::resource::location { 'icingaweb2_index':
      location       => '~ ^/icingaweb2/index\.php(.*)$',
      server         => 'icingaweb2',
      ssl            => false,
      index_files    => [],
      fastcgi        => '127.0.0.1:9000',
      fastcgi_index  => 'index.php',
      fastcgi_param  => {
        'SCRIPT_FILENAME'         => '/usr/share/icingaweb2/public/index.php',
        'ICINGAWEB_CONFIGDIR' => '/etc/icingaweb2',
        'REMOTE_USER'         => '$remote_user',
      },
    }
  } else {
  [...]

Beim Nginx selbst werden alle von der Standard-Installation kommenden virtuellen Hosts (server_purge => true) und sonstigen Konfigurationsdateien entfernt. Der Artikel der kommenden Woche schließt diesen Abschnitt über eine komplexere Konfiguration vorerst ab. Dort wird dann der noch fehlende Code präsentiert, der einen Apache-Webserver zum Ausliefern von Icinga Web 2 verwendet.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

OpenStack Summit Berlin 2018

Vom 13. bis zum 15. November 2018 fand in Berlin der OpenStack Summit statt, der etwa 2700 Interessierte aus aller Welt in die deutsche Hauptstadt lockte. Entsprechend der Releasezyklen des OpenStack Softwareprojekts, wird diese Veranstaltung alle sechs Monate an wechselnden Orten rund um den Globus abgehalten. Der nächste Summit steigt Ende April 2019 in Denver – dann jedoch unter dem neuen Namen „Open Infrastructure Summit“, was den universellen Anspruch von OpenStack deutlich macht.
Dass mit Berlin zum ersten mal ein Austragungsort in Deutschland gewählt wurde, liegt auch an der großen OpenStack Nutzergemeinde hierzulande. Gemessen an den Nutzerzahlen ist Deutschland laut User Survey eine der Top 3 „OpenStack-Nationen“. Als große Anwender wären unter anderem die Deutsche Telekom, BMW und VW zu nennen, die allesamt auf der Konferenz vertreten waren.
Auch bei Netways ist Openstack seit einiger Zeit produktiv im Einsatz. Folgerichtig ließ sich das Team von Netways Web Services dieses Event „vor der eigenen Haustür“ nicht entgehen. Auf dem Programm standen mehr als hundert Workshops und Vorträge auf dem Gelände des CityCube Berlin.
Besonders interessant war eine Keynote über den Einsatz von OpenStack im Bereich Network Functions Virtualization (NFV). AT&T eröffnete dem Publikum, dass OpenStack eine zentrale Rolle bei der Bereitstellung der Infrastruktur für den Mobilfunkstandard 5G spielt. Das Software-definierte Kernnetz läuft auf einer Openstack Undercloud, die komplett containerisiert ist und mithilfe von Airship verwaltet wird. Zur Demonstration der Verlässlichkeit des Systems startete der Referent von AT&T ein Videotelefonat mit einem Kollegen in den USA, der über ein 5G Testnetzwerk verbunden war. Die Virtuelle Maschine, auf der diese Session lief, wurde daraufhin heruntergefahren. Innerhalb eines Augenblicks übernahm eine andere VM diese Session, so dass das Videotelefonat ohne eine besondere Beeinträchtigung aufrecht erhalten werden konnte.
Ein weiterer eindrucksvoller Vortrag hatte den Anwendungsfall AI/Machine Learning zum Thema. Mit dem PCI Passthrough Feature von Nova werden PCI Geräte wie GPUs und FPGAs als Hardwareressourcen über die Cloud verfügbar gemacht, die dann vom Nutzer per REST API dynamisch angefordert werden können. So können aufwändige Machine Learning Anwendungen über die Cloud hardwarebeschleunigt werden. Die Spracherkennung und Übersetzung eines kurzen Videoausschnitts erfolgte in der Demo dank GPU-Hardwarebeschleunigung doppelt so schnell wie bei der alleinigen Nutzung von CPU. Im zweiten Beispiel verwendete man FPGAs zur Beschleunigung von Gesichtserkennungssoftware. Wichtige Funktionen hierzu liefert Cyborg, womit FPGAs in der Cloud verwaltet und programmiert werden können.
Wer es nicht zum Summit nach Berlin geschafft hat, kann sich hier Mitschnitte der Vorträge anschauen.

Dominik Seidel
Dominik Seidel
Junior Systems Engineer

Dominik ist seit Kurzem Azubi in der Abteilung Managed Services. Er interessiert sich für Geschichte, die Natur, und hört und macht gerne Musik. Wenn er nicht arbeitet, spielt er Gitarre oder wandert durch heimische Wälder.

Icinga 2 – Monitoring automatisiert mit Puppet Teil 12: Profile Part IV

This entry is part 12 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Heute geht es mit der Konfiguration von Icinga Web 2 weiter, nach dem im letzte Teil als Voraussetzung PHP konfiguriert wurde. Als Backend zur Speicherung von Authentifizierungs- und Benutzerdaten, kommt eine eigene MySQL Datenbank auf dem gleichen lokalen System zum Einsatz. Der Datenbank- und der Benutzername, sowie dass Passwort soll mittels Parameter festgelegt werden könnten, das gleiche gilt für den zum Senden von Kommandos an Icinga benötigten API-Benutzer und man soll sich als Webserver zwischen einem Apache bzw. einem Nginx entscheiden können. Die Konfiguration letztgenannter, wird im nächsten Teil der kommenden Woche behandelt.

class profile::icinga2::server(
  String                    $web_db_pass,
  String                    $web_api_pass,
  ...
  String                    $web_db_user  = 'icingaweb2',
  String                    $web_db_name  = 'icingaweb2',
  String                    $web_api_user = 'icingaweb2',
  Enum['apache', 'nginx']   $web_server   = 'apache',
) {
  ...
  mysql::db { $web_db_name:
    host     => $web_db_host,
    user     => $web_db_user,
    password => $web_db_pass,
    grant    => ['ALL'],
    before   => Class['icingaweb2'],
  }
  if $web_server == 'nginx' {
    $manage_package = true
#    $web_conf_user =
  } else {
    $manage_package = false
#    $web_conf_user =
    package { 'icingaweb2':
      ensure => installed,
    }
  }
  class { 'icingaweb2':
    db_username    => $web_db_user,
    db_password    => $web_db_pass,
    import_schema  => true,
    config_backend => 'db',
    conf_user      => $web_conf_user,
    manage_package => $manage_package,
  }
  ::icinga2::object::apiuser { $web_api_user:
    ensure      => present,
    password    => $web_api_pass,
    permissions => [ 'status/query', 'actions/*', 'objects/modify/*', 'objects/query/*' ],
    target      => '/etc/icinga2/conf.d/api-users.conf',
  }
  class { '::icingaweb2::module::monitoring':
    ido_db_host       => '127.0.0.1',
    ido_db_name       => $ido_db_name,
    ido_db_username   => $ido_db_user,
    ido_db_password   => $ido_db_pass,
    commandtransports => {
      'icinga2' => {
        transport => 'api',
        username  => $web_api_user,
        password  => $web_api_pass,
      }
    }
  }
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.

Startup Days bei Netways Vol. II

Dass Bernd einen gewissen Hang zum TrashTV hat, dürfte allgemein bekannt sein. Was würde also näher liegen, als sich von einem ehemaligen (stv.) Mitglied im Kunstbeirat des Deutschen Bundestages aus Nürnberg inspirieren zu lassen und seine Netways-Familie in eine selbstkonzipierte Löwenhöhle zu schicken.

Letztes Jahr wurde das Projekt initial gepitcht und dabei fiel unser neues Konferenzbuchungssystem raus.

Bis repetita non placent, könnte man meinen, aber dieses Jahr treten wir mit noch mehr Ideen an als schon 2017.
Zwischen Oktober 2018 und heute kamen etwa 100 Commits auf unsere Wiki-Page und brachten somit 12 Projekte zu Stande.
Zwar wird gibt es hier nochmal einen weed out, aber hier ein kurzer Abriss über die Projekte mit der höchsten Resonanz bisher:
Christian möchte weiter an seinem Windows Monitoring Konzept mit Icinga schrauben und sammelt hierfür Wünsche und Vorschläge.
Marius und Eric planen die Weltherrschaft bis Merz per automatisertem Aktientrading und hoffen auf mehr als 39,24% bzw. 48,52 % in der Endabstimmung.
Max verfolgt einen technischeren Ansatz und will mit seinem “SkyNET(ways)” heute das Office und morgen die Welt automatisiert kontrollieren.

(what could possibly go wrong)

Vanessa dagegen möchte etwas für unsere Gesundheit zu tun, wobei sie fachkundig von Julia unterstützt wird.
Nicole geht mit ihrem Projekt in eine Produktevaluation von Tinkerforge um unser Shop-Portfolio eventuell zu erweitern.
Wie die/der eine oder andere mitbekommen hat, sind wir dabei, in neue Buroräume zu ziehen. Die dort neue Dachterasse versuche ich, unter anderem mit Daniel, in eine Spielwiese für Urban Gardening und Gartenautomation umzuwandeln.
Wie man sehen kann, sind die Interessen bei Netways nicht ausschließlich technisch ausgerichtet.
Unseren Projektverläufen folgen kann man auf twitter: #lifeatnetways und #startupdays
Wer nächstes Jahr mitmachen möchte, darf gerne auf jobs.netways.de vorbeikommen!

Tim Albert
Tim Albert
System Engineer

Tim kommt aus einem kleinen Ort zwischen Nürnberg und Ansbach, an der malerischen B14 gelegen. Er hat in Erlangen Lehramt und in Koblenz Informationsmanagement studiert, wobei seine Tätigkeit als Werkstudent bei IDS Scheer seinen Schwenk von Lehramt zur IT erheblich beeinflusst hat. Neben dem Studium hat Tim sich außerdem noch bei einer Werkskundendienstfirma im User-Support verdingt. Blerim und Sebastian haben ihn Anfang 2016 zu uns ins Managed Services Team geholt, wo er sich nun insbesondere...

Icinga 2 – Monitoring automatisiert mit Puppet Teil 11: Profile Part III

This entry is part 11 of 14 in the series Icinga 2 Monitoring automatisiert mit Puppet

Die heutige Fortsetzung dieser Serie befasst sich mit dem Management einer PHP-Umgebung für daen Betrieb eines Icinga Web 2 auf dem Icinga-Server. Icinga Web 2 benötigt in aktuellen Versionen mindestens ein PHP in der Version 5.6, kommen dann noch Module hinzu, wird damit einhergehend ein PHP 7 oder neuer vorausgesetzt.
Server mit Debian Stretch bekommen ein aktuelles PHP aus ihren eigenen Repositories, bei RedHat 7 muss auf das SCL (Softwarer Collection Linux) Repository zurückgegriffen werden.

class profile::icinga2::server(
  ...
) {
  case $::osfamily {
    'redhat': {
      require ::profile::repo::epel
      require ::profile::repo::icinga
      require ::profile::repo::scl
      $manage_package = false
      $manage_repo    = false
      $php_globals    = {
        php_version => 'rh-php71',
        rhscl_mode  => 'rhscl',
      }
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysqlnd => {}, pgsql => {}, },
      ...
    }
    'debian': {
      $manage_package = true
      $manage_repo    = true
      $php_globals    = {}
      $php_extensions = { mbstring => {}, json => {}, ldap => {}, gd => {}, xml => {}, intl => {}, mysql => {}, pgsql => {}, },
      ...
    }
    default: {
      fail("'Your operatingsystem ${::operatingsystem} is not supported.'")
    }
  }
  ...

PHP selbst lässt sich mit dem Puppet-Module puppet/php des Projektes Vox Pubuli konfigurieren. Hierbei werden über die Klasse php::globals Einstellungen getätigt, welches PHP, aus welchen Quellen benutzt werden soll. Im Anschluss wir über die Hauptklasse php das Management auf das Betreiben eines FPM (FastCGI Process Manager) eingeschränkt. Dieser lauscht standardmäßig auf TCP-Port 9000 ausschließlich auf localhost.
Neben einem erhöhen des Speicherlimits und dem Setzen der Zeitzone, werden auch die von Icinga Web vorausgesetzten PHP-Extensions aktiviert.

...
#
# PHP
#
class { '::php::globals':
  * => $php_globals,
}
class { '::php':
  ensure        => installed,
  manage_repos  => false,
  apache_config => false,
  fpm           => true,
  extensions    => $php_extensions,
  settings      => {
    'PHP/memory_limit'   => '128M',
    'Date/date.timezone' => 'Europe/Berlin',
  },
  dev           => false,
  composer      => false,
  pear          => false,
  phpunit       => false,
  require       => Class['::php::globals'],
}

Bei der Klasse profile::repo::scl beschränken wir uns im folgenden Beispiel auf CentOS basierte Systeme, wie es auf RHEL einzubinden ist muss aus der Installations-Dokumentation abgeleitet werden.

class profile::repo::scl {
  case $::operatingsystem {
    'centos': {
      package { 'centos-release-scl':
        ensure => installed,
      }
    } # CentOS
    default: {
      fail("'Your plattform ${::operatingsystem} is not supported.'")
    }
  } # case
}
Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.