NETWAYS Webinare – Aus der Asche

Wer am letzten Webinar zur Icinga 2 Anbindung von Graphite und Grafana teilgenommen hat, wurde Live Zeuge wie sich ein System verhält wenn es faktisch zu heiß ist und einfach seinen Dienst quittiert. Zugegeben, so etwas passiert in der Regel relativ selten. Während eines Webinars ist der Zeitpunkt aber relativ ungünstig.
Wie angekündigt werden wir das Webinar nachholen und zwar am 23. August 2018 um 10:30 Uhr. Die kostenfreie Anmeldung ist direkt hier möglich.
Damit natürlich nicht das selbe Szenario wie beim letzten mal Auftritt, haben wir unser Equipment ein klein wenig aktualisiert.

Somit ist zumindest das Hitze- und Performance Problem kein Hindernis mehr und können entspannt in die Zukunft blicken und die nächsten geplanten Webinare mit Bravur meistern:

Ich freue mich wie immer auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

NETWAYS Webinare: Icinga 2 Serie

NETWAYS Webinare
Heute möchten wir euch darüber informieren, dass wir uns einige Gedanken über unsere beliebten Icinga 2 Webinare gemacht haben. Anders als bisher wollen wir nicht statisch auf einzelne Themen und Inhalte eingehen, sondern einen ganzheitlichen Eindruck der Möglichkeiten von Icinga 2 vermitteln.
In diesem Zuge werden wir gemeinsam in einer Reihe von Webinaren vom Grundaufbau des Monitorings, der Anbindung an Graphite und Grafana bis hin zum Windows Monitoring und der Integration von Rocket.Chat und Request Tracker für die Alarmierung.
Am Ende der Serie soll als Ziel eine fertige Icinga 2 Umgebung bereitstehen, welche vom Grundaufbau im Rahmen der Webinare erstellt wurde und künftig für weitere Themen bereitsteht.
Die geplanten Termine sind alle direkt auf unserer Webinar Seite zu finden. Eine kurze Übersicht möchten wir trotzdem bereitstellen:

Wir freuen uns wie immer auf eine rege Teilnahme!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

OSDC 2017: Community connects

After a fully packed and entertaining first day at OSDC, we really enjoyed the evening event at Umspannwerk Ost. Warm weather, tasty food and lots of interesting discussions, just relaxing a bit and preparing for day 2 🙂

Warming up

Grabbed a coffee and started with Julien Pivotto on Automating Jenkins. Continuous integration matters these days and there’s not only Jenkins but also GitLab CI and more. Julien told us why automation for Jenkins is needed. Likewise, “XML Everywhere” makes configuration a bit tad hard. Same thing goes for plugins, you literally can’t run Jenkins without. Julien also told us “don’t edit XML”, but go for example for Groovy and the Jenkins /script API endpoint. The Jenkins pipeline plugin even allows to use YAML as config files. In terms of managing the daemon, I learned about “init.groovy.d” to manage and fire additional Groovy scripts. You can use the Job DSL Groovy plugin to define jobs in a declarative manner.
Julien’s talk really was an impressive deep dive leading to Jenkins running Docker and more production hints. After all an amazing presentation, like James said 🙂

I decided to stay in MOA5 for the upcoming talks and will happily await the conference archive once videos are uploaded in the next couple of days.
Casey Calendrello from CoreOS led us into the evolution of the container network interface. I’m still a beginner with containers, Kubernetes and also how networks are managed with it, so I learned quite a lot. CNI originates from rkt and is now built as separate project and library for Go-built software. Casey provided an impressive introduction and deep dive on how to connect your containers to the network – bridged, NAT, overlay networks and their pros and cons. CNI also provides many plugins to create and manage specific interfaces on your machine. It’s magic, and lots of mentioned tool names certainly mean I need to look them up and start to play to fully understand the capabilities 😉

Yesterday Seth Vargo from HashiCorp had 164 slides and promised to just have 18 today, us moving to lunch soon. Haha, no – it is live demo time with modern secrets management with Vault. We’ve also learned that Vault was developed and run at HashiCorp internally for over a year. It received a security review by the NCC group before actually releasing it as open source. Generally speaking it is “just” an encrypted key value store for secrets. Seth told us “our” story – create a database password once, write it down and never change it for years. And the process to ask the DBA to gain access is so complicated, you just save the plain-text password somewhere in your home directory 😉
Live demo time – status checks and work with key creation. Manage PostgreSQL users and credentials with vault – wow, that simple? That’s now on the TODO list to play with too. Seth also released the magic Vault demo as open source on GitHub right after, awesome!


Enjoying the afternoon

We had tasty lunch and were glad to see Felix Frank following up with “Is that an Ansible? Stop holding it like a Puppet!” – hilarious talk title already. He provided an overview on the different architecture and naming schemas, community modules (PuppetForge, Ansible Galaxy) and also compared the configuration syntax (Hash-Like DSL, YAML). Both tools have their advantages, but you certainly shouldn’t enforce one’s mode onto the other.

Puh, I learned so many things today already. I’ve unfortunately missed Sebastian giving an introduction about our very own NETWAYS Web Services platform managed with Mesos and Marathon (I rest assured it was just awesome).
After a short coffee break we continued to make decisions – previously Puppet vs. Ansible, now VMware vs. Rudder, location-wise. I decided to listen to Dr. Udo Seidel diving into “VMware’s (Open Source) way of Container“. VMWare is traditionally not very open source friendly, but things are changing. Most likely you’ve heard about Photon OS serving as minimal container host. It was an interesting talk about possibilities with VmWare, but still, I left the talk with the “yet another platform” feeling.
Last talk for a hilarious day about so many learnt things is about containerized DBs by Claus Matzinger from CrateDB provides shared nothing architecture and includes partitioning, auto-sharing, replication. It event supports structured and unstructured data plus SQL language. Sounds promising after all.
Dirk talked about Foreman as lifecycle management tool in MOA4, too bad I missed it.



Coffee breaks and lunch unveiled so many interesting discussions. Food was really tasty and I’m sure everyone had a great time, so did I. My personal highlights this year: Follow-up Seth’s talk and try Consul and Vault and do a deep dive into mgmt and tell James about it. Learn more about Ansible and put it into context with Puppet, like Felix has shown in his talk. As always, I’m in love with Elastic beats and will follow closely how to log management evolves, also on the Graylog side of life (2.3 is coming soon, Jan and Bernd promised).
Many thanks to our sponsor Thomas Krenn AG for being with so long. And also for the tasty Linzer Torte – feels like home 🙂

Thanks for a great conference, safe travels home and see you all next year!
Save the date for OSDC 2018: 12. – 14.6.2018!

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler 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 und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Ein Buch über Icinga 2

Erscheint am 27. Juni 2016

41suqaLOyCL._SX336_BO1,204,203,200_April 2015, nach Monaten des Schwankens machten sich dann zwei verbliebene Möchtegernautoren doch auf ein Buch zum Thema Icinga 2 zu verfassen. Wir wollten ein sehr praxisnahes Werk mit vielen Beispielen wie und mit welchen Plugins etwas zu überwachen ist. Herausgekommen sind 344 Seiten von denen sich 100 mit Plugins und deren Verwendung in Icinga 2 befassen. Vorweg erfolgt eine generelle Einführung, die Vorstellung des neuen Webinterfaces Icingaweb 2 als auch eine ausführliche Erläuterung wie man lokale Werte wie Load bzw. CPU bei Windows oder Disk Usage mit NRPE/NSClient++, SSH und selbstverständlich mit dem neuen Icinga Agenten ermittelt.
Dem Kapitel über Plugins ist noch die Vorstellung einer fiktiven Firma vorangestellt. Diese betreibt ein zweigeteiltes Netzwerk mit einem internen Netz und eine durch Perimeter abgetrennte DMZ. Anhand dieses Beispiels wird eine verteilte Überwachung implementiert. Im internen Netz ist ein Icinga-Server (Master) für die Überwachung der dortig angesiedelten Server und Dienste zuständig. Für die DMZ wird ein weiterer Icinga-Server (Satellit) verwendet, der die ermittelten Ergebnisse an den Master meldet.
Diese Icinga-2-Infrastruktur wird dann im Folgenden benutzt, um eine Vielzahl von Diensten zu überwachen:

  • Host Erreichbarkeit
  • Zeitserver und lokale Zeit
  • Webservices incl. Apache und Ngnix
  • Domain Name Services
  • DHCP
  • Kerberos
  • Mailempfang und -versand
  • Proxy-Server
  • Generische Portüberwachung am Beispiel von Jabber
  • Javabasierte Application-Server
  • SAP
  • Kibana
  • Microsoft-Infrastrukturdienste: CIFS, Terminalservice, Domaincontroller, Exchange
  • Datenbanken: MySQL, PostgreSQL, MS SQL, Oracle
  • LDAP
  • Redis
  • Elasticsearch
  • VMware vSphere
  • Hardware: IPMI, HP, Oracle Solais, Thomas Krenn, Netzwerk, Festplatten
  • NetApp
  • Qnap

Das letzte Drittel ist Graphing mit PNP4Nagios und Graphite, Logmangement, Reporting und Businessprozessen gewidmet.
Teilbereiche werden von den beiden Autoren in einem Workshop vor der diesjährigen Open Source Monitoring Conference mit den Teilnehmern zusammen praktisch umgesetzt.

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.

Weekly Snap: OpenNebula & Puppet VM Provisioning, Icinga 2 Beta & Logstash Training

weekly snap26 – 30 May ended the month with a webinar and tips for VM provisioning, an Icinga 2 Beta release, and musings on development and Logstash training.
Much ado about VMs, Christian and Lennart held their webinar on Puppet: Provisioning on VMWare, as Achim brought Foreman, Fog and OpenNebula together with an OpenNebula Fog provider.
Bernd celebrated the release of Icinga 2 Beta while Gunnar meditated on writing user-friendly error alerts as a developer.
To end the week, Thomas reflected on the last few rounds of our Logstash training courses, and the development of our workshop materials to keep pace with software releases.

Reminder für das morgige Puppet-Webinar

puppet Ich möchte noch einmal die Gelegenheit nutzen und auf unser morgiges Puppet-Webinar zum Thema “Puppet: Provisionierung von VMware” aufmerksam machen. Das Webinar findet morgen um 10:30 Uhr statt. Die Registrierung erfolgt wie immer über unsere Webinar-Seite.
Da Virtualisierungslösungen mittlerweile in fast jeder IT-Landschaft eingesetzt werden, wollen wir aufzeigen wie man diese sinnvoll mit einem Configuration Management Tool wie Puppet kombinieren kann. Wer Puppet noch nicht kennt, dem empfehle ich unser Webinar-Archiv von der Open Source Variante von Puppet und der Puppet Enterprise Variante als kleine Vorbereitung.
Lennart und ich freuen uns bereits.
Bis morgen!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Weekly Snap: VMware & FreeBSD, End-to-End Monitoring & Headless

weekly snap31 March – 4 April started a new month with monitoring tips and fun galore, a how-to guide or two, as well as new hardware.
Eva started the week by counting 8 days to the OSDC and sharing Jan Gehring’s talk on “Orchestrating Servers with Rex” as Bernd peddled our last two tickets to the Berlin event.
He also released the ultimate check_netways plugin just in time for April 1st and offered video evidence that we are home to Germany’s most flexible salesman.
Johannes then gave a guide to installing VMware tools on a FreeBSD 6-8 guest while Christoph showed how to set up end-to-end monitoring with Watir WebDriver and Headless.
Christian continued the monitoring theme, reminding interested attendees to join our Icinga Web webinar and Georg announced newcomers to our hardware store: Braintower SMS Gateway S & L with workshops to boot.

Deployment virtueller Maschinen – Cloud Provisoner vs. Compute Resource

In meinem Blogpost möchte ich zwei Lösungen vorstellen um virtuelle Maschinen unter VMware zu deployen, so dass diese danach mit Puppet weiter gemanaget werden können. Beide Lösungen folgen hierbei ganz unterschiedlichen Ansätzen, weshalb ich die Vor- und Nachteile wie ich sie sehe aufzeigen möchte und sehr an eurer Meinung interessiert wäre.
Die erste Lösung, die ich in den Ring werfen möchte, nennt sich Cloud Provisioner, wird von Puppetlabs entwickelt und ist Teil von Puppet Enterprise. Die Installation ist recht simpel, einfach beim Installation-Assistenten mit ausgewählt, schon erhält man das Kommandozeilen-Tool. Da es sich um ein Kommandozeilen-Tool handelt ist die Konfiguration auch relativ einfach in einer Datei erledigt, in der die Zugangsdaten hinterlegt werden.
War Installation und Konfiguration erfolgreich kann das Puppet-Subkommando node_vmware genutzt werden um die virtuellen Maschinen in der Umgebung aufzulisten, zu starten, stoppen und gleich ganz zu löschen. Die wichtigste Option ist natürlich create, mit dieser kann aus einem bestehenden Template eine neue virtuelle Maschine angelegt werden. In diesem Template sollte idealerweise bereits Puppet installiert sein. Ist dies nicht der Fall kann (ssh-Zugriff vorausgesetzt) mit puppet node install auch noch Puppet nachinstalliert werden. Nun lässt sich die virtuelle Maschine ganz wie gewohnt über die Weboberfläche oder Kommandozeile managen.
Die Alternative stellt Foreman und nennt sich Compute Resource. Auch hier ist die Installation recht einfach. Nachdem bereits Foreman installiert ist, wird über den Paketmanager der Distribution ein Paket foreman-vmware nachinstalliert. Danach hat man in der Oberfläche die Möglichkeit ein Virtual Center als Compute Resource anzulegen, wofür auch nur ein entsprechend berechtigter Account nötig ist. Hier schon mal ein Hinweis für Ausprobierwillige ein einzelner ESX-Host geht nicht, da Foreman nach Clustern sucht.
Installation und Konfiguration geschafft, kann über die Compute Resource direkt mit den virtuellen Maschinen kommuniziert werden. Zusätzlich zu den Optionen wie starten und stoppen ist auch der Konsolenzugiff möglich, wenn man noch etwas Konfigurationsaufwand in Firewallregeln steckt. Das Deployment erfolgt genauso wie bei physikalischen Systemen aus der Hostansicht heraus. Wählt man beim Anlegen eines neuen Hosts die Compute Resource, bekommt man einen zusätzlichen Reiter mit den Optionen für die virtuelle Maschine und kann alles hierbei festlegen. Anschließend wird die VM erzeugt und beispielsweise über PXE gebootet und mittels Kickstart installiert. Hierbei wird auch Puppet gleich mit installiert und die virtuelle Maschinen von Anfang damit konfiguriert.
Wie man sieht zwei völlig unterschiedliche Ansätze. Auf den Unterschied bei Installation und Verwendung auf Kommandozeile oder in der Weboberfläche möchte ich nicht eingehen, hier hat jeder persönliche Präferenzen und der Admin ist meist zufrieden solang es zuverlässig geht. Interessanter finde ich etwas unter die Haube zu schauen:

  • Geschwindigkeit: Hier gewinnt klar das Deployment aus einem Template. In meinen Augen ist die Frage, ob 5 Minuten oder 30, aber nur in den wenigsten Umgebungen entscheidend.
  • Sauberkeit: Hier gewinnt für mich das Deployment durch automatisierte Installation. Zum einen ist es aufwendig ein sauberes Template aus einem installierten System zu machen (zu beachten: Host-Keys, Puppet-Zertifkate, Netzwerkkonfiguration, Regeln für persistente Gerätenamen, Logs, …), dieses dann immer sauber und aktuell zu halten und zum anderen muss ich diesen Aufwand immer wieder neu betreiben und gewährleisten dass auch der nächste Betriebssystemrelease ähnlich aussieht.
  • Übertragbarkeit: Hier gewinnt auch wieder die automatische Installation, denn ich kann den gleichen Automatismus für physikalische Systeme und virtuelle Maschinen nutzen, sogar egal welche Virtualisierungslösung.
  • Nachvollziehbarkeit: Diese habe ich leider bei beiden Lösungen nur bedingt. Klone ich meine VM aus dem Template driften diese genauso auseinander wie bei der Autoinstallation. Aber einen leichter Vorteil sehe ich für letztere da man die Installationsanweisung (nach der installiert wurde) auf dem System ablegen kann, diese im Deploymenttool versionieren kann, etc.
  • Arbeitsaufwand: Auch hier kann ich weder für die eine Seite noch für die andere stimmen. Die manuelle Installation für das Template kann für manch proprietäre Software einfacher sein, aber nachdem unser Ziel ist alles mit Puppet zu erschlagen, sollte der Aufwand unabhängig von der Lösung gleich sein. Der initiale Aufwand für die automatische Installation ist aber typischerweise etwas höher, je nach Betriebssystem sogar drastisch höher (Windows hat leider kein Kickstart 😉 ).
  • Dokumentation: Klarer Sieg für Autoinstallation, da ich auf der Seite von “Quelltext ist die beste Dokumentation” stehe.
  • Security und Rollentrennung: Die internen Vorgaben brechen hier leicht der automatisierten Installation das Genick. Dürfen die Admins für das Betriebssystem nicht auf die Virtualisierung zugreifen ist dies für beide Lösungen nicht hilfreich, aber Templates vorbereiten und dann durch den VMware-Admin ausrollen zu lassen ist meist noch durchsetzbar.

Dies sind in meinen Augen die wichtigsten Punkte und für mich hat nicht nur aufgrund persönlicher schlechter Erfahrung die automatische Installation und somit Foreman mit seinen Compute Ressourcen die Nase vorn. Beide Lösungen lassen aber noch ein Feature vermissen, denn wenn ich nachträglich die virtuelle Hardware noch anpassen könnte, bräuchte ich keinen Zugriff mehr auf eine andere Management-Oberfläche.
Wie gesagt mich würde die Lesermeinung zu dem Thema interessieren, darum schaut euch die Lösungen Cloud Provisioner und Compute Ressource gegebenfalls nochmal an und dann kommentiert fleißig.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Virtuelle Entwicklungsumgebungen mit Vagrant

Mit Vagrant beschreibt und erstellt man virtuelle Entwicklungsumgebungen, was Entwicklern das Leben deutlich vereinfacht. Es läuft unter Linux, Windows und Mac OS X. Wenige Handgriffe reichen, um eine virtuelle Maschine in Betrieb zu nehmen und einzurichten.
Die Umgebung wird über ein Vagrantfile konfiguriert, welches u.a. port forwarding, mounts, Netzwerkkonfiguration und automatische Installation von Software steuert. Letzteres ist über Shellskripte, Ansible, Chef oder Puppet möglich.
Vagrant kann out of the box mit VirtualBox verwendet werden. VMWare ist auch möglich, aber kostenpflichtig. Weitere provider wie lxc findet man auf github.
Warum Vagrant?
Hauptgrund ist die klar definierte Umgebung. Jeder arbeitet mit den exakt gleichen Bibliotheken und identischen Versionen von Software. Infrastrukturkomponenten müssen nicht lokal installiert werden und die Umgebung ist reproduzierbar.
Zum Weiterlesen empfehle ich die Anleitung für Einsteiger.

Eric Lippmann
Eric Lippmann
Lead Senior Developer

Eric kam während seines ersten Lehrjahres zu NETWAYS und hat seine Ausbildung bereits 2011 sehr erfolgreich abgeschlossen. Seit Beginn arbeitet er in der Softwareentwicklung und dort an den unterschiedlichen NETWAYS Open Source Lösungen, insbesondere inGraph und im Icinga Team an Icinga Web. Darüber hinaus zeichnet er sich für viele Kundenentwicklungen in der Finanz- und Automobilbranche verantwortlich.

Webinar Puppet Enterprise and VMware

PL_logo_vertical_RGB_smNach unserem sehr erfolgreichen Webinar zur “Einführung in Puppet” veranstalten wir in wenigen Tagen unser zweites Puppet Webinar mit dem Thema “Puppet Enterprise and VMware“.
PuppetLabs hat vor kurzem ein neues Set an Puppet Modulen für das Management von VMware Umgebungen veröffentlicht. Diese Integration und die weiteren Features von Puppet Enterprise sind Thema des Webinars.
Das einstündige Webinar findet am 14.05.2013 um 11:00Uhr statt und wird von dem sehr erfahrenen Puppet Labs engineer Reid Vandewiele in englischer Sprache durchgeführt. Natürlich sind auch Kollegen von uns mit dabei, die alle aufkommenden Fragen (auch auf deutsch) beantworten können.
Die Registrierung kann hier durchgeführt werden. Bitte nicht von der Zeitangabe beeindrucken lassen (in UTC), das Seminar startet um 11:00h.
Wer sich nochmals das erste Webinar ansehen möchte, kann dies gerne hier machen. Wir freuen uns auf eine rege Teilnahme!

Martin Krodel
Martin Krodel
Head of Sales

Der studierte Volljurist leitet bei NETWAYS die Sales Abteilung und berät unsere Kunden bei ihren Monitoring- und Hosting-Projekten. Privat reist er gerne durch die Weltgeschichte und widmet sich seinem ständig wachsenden Fuhrpark an Apple Hardware.