Landscape – On-Premise

Bei Netways muss jeder Azubi jede Abteilung durchlaufen. Grund hierfür ist die Arbeit der anderen Mitarbeiter besser zu verstehen und zu respektieren. Derzeit bin ich bei Managed Services, genauer noch im Customer Hosting. Im Zuge dessen sollte ich mich mit alternativen Verwaltungstools auseinandersetzen im speziellen mit Landscape.

Was ist Landscape?

Landscape ist ein Management-Tool von Canonical. Des Weiteren bietet Landscape einige kleinere Kapazitäten hinsichtlich Monitoring, darunter Netzwerk- und Speicherauslastung, aber auch verbleibende Speicherkapazität, Netzwerkbelastung oder derzeitiger SWAP-Verbrauch.

Der Kern der Anwendung ist jedoch die einfache Ausführung von Updates/Upgrades, sowie Scripts auf Systemen, sowie die Möglichkeit diese zu limitieren und individuell anzuwenden. Eine Reihe an weiteren Features werden von Canonical für Landscape beworben, die ihr hier finden könnt.

Was kostet Landscape?

Landscape’s Kosten variieren stark anhand der Umgebung, die man damit verwalten möchte. Jedoch gibt es die Möglichkeit Landscape in einer kleineren Umgebung – bis zu 10 Vms und 50 Container – umsonst zuverwenden, dies nennt sich Landscape On-premises.

Wie installiere ich Landscape On-premises?

Die entsprechende Software Repository hinzufügen:

sudo add-apt-repository ppa:landscape/18.03

sudo apt-get update

Und daraufhin installieren:

sudo aptitude install landscape-server

sudo aptitude install landscape-server-quickstart

Die Quickstart-Variante installiert App-Server, Datenbank etc. alles auf das gleiche System.

Sollte das nicht gewünscht sein, gibt es ebenfalls eine ausführliche Dokumentation zur manuellen Installation hier.

Falls es zu Fehlern aufgrund von Package-Dependencys kommen sollte, dann kann dieses einfach mit aptitude anstelle von apt-get gelöst werden.

Jetzt können bereits Clients hinzugefügt werden. Eine ausführliche Anleitung dafür ist zwar auch im Webinterface unter <IP_of_APP-Server>/account/standalone/how-to-register zu finden. Dort wird auch automatisch ein Befehl generiert, der die entsprechenden Parameter setzt die zum hinzufügen relevant sind.

 

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

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.

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.