Config Management Camp Ghent 2019

Ich habe dieses Jahr die erste Gelegenheit bekommen, mich mit meinen Kollegen und meinem Chef am Configuration Management Camp im Ghent zwischen 4. und 6. Februar zu beteiligen. Wir sind am 3. Februar am Abend in Ghent angekommen und durch die Stadt spazieren gegangen. Ghent hat uns sehr beeindruckt: Nicht nur die Sauberkeit der Straßen, sondern auch die Verbindung von alten und neuen Gebäuden haben Ghent besonders schön wirken lassen.

DevOps und Konfigurationsmanagement

Aber der Höhepunkt war das Camp: Es gab fast 1000 Teilnehmer aus der ganzen Welt. Die Vorträge waren sehr informativ und gingen hauptsächlich um DevOps und Konfigurationsmanagement ( Puppet, Ansible, Chef, Foreman). Viele Referenten haben sowohl ihre Erfahrungen sowie zuletzt aufgekommene und gelöste Probleme in ihrer Firma geteilt, als auch neue Features im Automation- und Konfigurationsmanagement-Feld vorgestellt. Am dritten Tag nahm ich mit meinem Kollegen und Ausbilder auf dem Foreman Construction Day Workshop teil. Wir haben uns in Gruppen praktisch mit “Foreman” beschäftigt. Am Ende des Tages haben einige Foreman-Entwickler und Teilnehmer über Wünsche, Verbesserungen und kommende Features gesprochen.

Ich empfehle jedem, der Interesse am Konfigurationsmanagement hat, das nächste Camp zu besuchen und belgische Waffeln und Bier auf jeden Fall zu probieren. Die sind sehr, sehr lecker.

 

 

 

 

 

 

 

Afeef Ghannam
Afeef Ghannam
Junior Consultant

Afeef macht seit September 2017 eine Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS. Nachdem der gebürtige Syrer erfolgreich Deutsch gelernt hat, stellt er sich jetzt der Herausforderung Programmiersprache. Neben der IT schätzt er vielfältiges Essen. Sein Motto lautet يد واحدة لا تصفق لوحدها , was so viel bedeutet wie „Eine Hand wird nie allein klatschen“.

GitLab CI + Docker + Traefik = ❤️

So wie vermutlich einige, bin auch ich zur Zeit sehr von GitLab und dessen CI/CD Features angetan. Vor einigen Monaten habe ich angefangen, für meine privaten Webprojekte eine Template .gitlab-ci.yml zu erstellen, welche für jeden Commit, auf jedem Branch, automatisch Docker Images baut und diese in meiner Docker-Umgebung mit zum Branch/Projekt passender Subdomain und SSL-Zertifikat bereitstellt.

Um zu funktionieren benötigt das ganze eine erreichbare Docker-API, ein darauf laufendes Traefik, ein Docker-Netzwerk namens Proxy (Traefik muss dieses auch nutzen) und einen Account + Repository auf hub.docker.com. Das ganze kann aber recht einfach umgeschrieben werden, falls man seine eigene Registry verwenden möchte.

Ablauf beim Commit:

  1. Bauen und Pushes des Images (Tag => Branch + Commit-Hash)
  2. Umbenennen des alten Containers, falls vorhanden (Suffix ‘-old’ wird angehangen)
  3. Erstellen des neuen Containers (Name => Deployment Domain bsp. master.dev.domain.tld)
  4. Löschen des alten Containers
  5. (Optional) Löschen & neu erstellen des Produktionscontainers, falls der Commit auf dem Masterbranch stattgefunden hat (Muss durch Button ausgelöst werden und läuft wie Schritte 2 bis 4 ab)
  6. Neue Container stehen unter den Deployment-Domains zur Verfügung

Pipeline eines Commits auf Master/andere Branches (Deploy auf Produktion kann durch “Play”-Button ausgelöst werden):

Pipeline eines Commits auf andere Branches:

Für jeden Branch wird auch ein Environment erstellt, welches über Operations/Environments in GitLab verwaltet werden kann.
Hier können Deployments angesehen, gelöscht, in Produktion ausgerollt und auf einen früheren Stand zurückgesetzt werden:

Zur Nutzung des Templates in einem Projekt wird ein Dockerfile im Repository, ein paar CI/CD-Variablen, und das Template selber benötigt.

Benötigte CI/CD-Variablen:

CI_DEV_URL_SUFFIX (Domain-Suffix der Development-Umgebungen): dev.domain.tld
CI_PRODUCTION_URL (Domain der Produktionsumgeben): domain.tld
CI_DOCKER_HOST (Adresse & Port der Docker-API): docker.domain.tld
CI_REGISTRY_IMAGE (Image-Name auf hub.docker.com): supertolleruser/supertollesoftware
CI_REGISTRY_USER (Docker-Hub Benutzer): supertolleruser
CI_REGISTRY_PASSWORD (Passwort des Docker-Hub Benutzers): supertollespasswort
CI_TRAEFIK_PORT (Port der Webanwendung im Container): 8080

Da das ganze Projekt bis jetzt nur Images baut und Container bereitstellt, könnten hier natürlich noch Tests eingebaut werden um das ganze abzurunden.

Zur Zeit arbeite ich an einer Umstellung auf Kubernetes und werde, sobald abgeschlossen, auch davon berichten.

Noah Hilverling
Noah Hilverling
Developer

Nachdem Noah bei einer vierjährigen Exkursion nach Belgien seine Liebe zum Programmieren entdeckte, holte der gebürtige Euskirchener innerhalb kürzester Zeit gleich zwei Schulabschlüsse nach. Danach verließ Noah sogar den schönen Chiemsee, um sich ab September 2016 im Rahmen der Ausbildung zum Fachinformatiker für Anwendungsentwicklung bei NETWAYS voll und ganz dem Programmieren hinzugeben und viele unterschiedliche Erfahrungen zu sammeln. Wenn er mal nicht am Programmieren und Zocken ist, brettert er mit seinem Snowboard die Pisten runter,...

NoCode, Security by Design

NoPicture

Bei Netways sind wir immer am Puls der Zeit und probieren für euch den neuesten heißen Sch**ß aus. Heute möchte ich euch deswegen NoCode vorstellen. Wenn man NoCode noch nicht kennt; es kann als logische Fortsetzung aller aktuellen Cloud Technologien und Everything as Code Initiativen gesehen werden. So konnte sich NoCode innerhalb kurzer Zeit einen zentralen Platz auf der CloudNative Landscape sichern
Am Anfang steht die Lochkarte. Auf dieser sind Programme binär abgespeichert und werden von damaligen Großrechnern ausgeführt. Leider enthält der Code dieser Anwendungen einige wenige Bugs, was allgemein Verunsericherung führte. Lochkarten werden nach kurzer Zeit wieder abgeschafft.

Weiter geht es mit solide programmierten Unix und Windows Serveranwendungen, die innerhalb von vielen Unternehmen hervorragende Dienste leisteten. Da mit zunehmender Vernetzung die Probleme dieser Lösungen offensichtlicher wurden und man nicht schnell genug hinterher kam einen Fehler immer wieder durch zwei neue zu ersetzen, schaffte man vielerorts diese Insellösungen wieder ab und setzte auf Standards. Das Glück für die schon beinahe von Arbeitslosigkeit bedrohten Admins, es gibt derlei sehr viele.
Mittlerweile haben wir Virtualisierung und können mit P(roblem)aaS, I(nsecure)aaS und S(anduhr)aaS fast alle Kundenwünsche im keim … erfüllen. Ab diesem Zeitpunkt, wo man dank DevOps und dezentralen verbindungslosen Orchestrierungstools seine Bugfixes auf tausende Container gleichzeitig deployen kann, wird es Zeit sich von diesen noch beinah beherrschbaren Problem Factories zu verabschieden.
Jetzt können papierlos, hardwareless, connectionless und configurationless einpacken. Wir machen serverless und führen Funktionen ‘direkt in der Cloud’ aus.
Da wir alles vom Strom, über das Netzwerk bis zum Server abschaffen, fehlt nur noch der Code.
Genau hier springt NoCode ein. Mit wenigen Zeilen NoCode kann man sich fast alle Anwendungsfälle moderner Applikationen vorstellen. Das beste an NoCode, es enthält niemals Bugs und kann für die verschiedensten Einsatzzwecke genutzt werden. Als erste Enterprise Monitoring Lösung hat auch icinga2 die NoCode notation eingeführt. Jedes in NoCode geschriebene config file wird klaglos von der Syntax Prüfung akzeptiert. Ein Kollege arbeitet gerade daran ein neues Backend Feature in NoCode zu implementieren. Ich habe noch keine Details gesehen, aber es rennt wie Sau.

Schaut euch unbedingt das NoCode github Repo von Kelsey Hightower, dem verantwortlichen google Hacker, an. Hier könnt ihr das Projekt auschecken und mit docker testen.

Wer jetzt heiß ist und mal eine Anwendung im live Betrieb sehen möchte. Die vom führenden Crypto Anbieter ROT26 angeboteny Crpyto API ist gerüchteweise in NoCode implementiert. Probiert es direkt aus

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Open Source Camp: Hurry up to get on stage!

You know how to automate things with Ansible? You enjoy sharing your knowledge with your fellows? Then hurry up to get on stage and become a speaker at OSCAMP!

Call for papers runs until February 2019! Submit your paper here.

Open Source Camp is a series of events giving Open Source projects a platform to present themselves to the community. Its third edition on Ansible takes place right after OSDC‘s lecture program on May 16 in Berlin.

 

#OSCAMP | May 16, 2019 | Berlin

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

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.