Wie wir dienstlich Reisen

Als Consultant bei NETWAYS ist man durchaus auch auf Reisen, sei es zweigleisig, mit dem Auto oder Flugzeug. Auch das eine oder andere Hotel kennt uns schon als Stammgäste.

Nach nun knapp über 6 Jahren bei NETWAYS habe ich mir einen gewissen Rhythmus angewöhnt und möchte ein paar Eindrücke und Tipps weitergeben.

Die Warnung

Bei uns kann jeder Mitarbeiter seine Reisen selbstständig, und ohne Reisebüro, buchen. Das ist leider nicht bei jedem Unternehmen / Konzern so.

Reisebüros bringen zwar den Vorteil von Verfügbarkeit und ggf. Unterstützung beim Buchen, der Preis oder die Buchungsgeschwindigkeit zeigt eher aber das Gegenteil.

Als Mitarbeiter vor Ort wissen Sie spätestens nach dem 1. Besuch mehr als der Mitarbeiter im Reisebüro. Wenn ich fast jede Woche reise, habe ich lieber die Zügel selbst in der Hand.

(more…)

Markus Frosch

Autor: Markus Frosch

Markus arbeitet bei NETWAYS als Principal Consultant und unterstützt Kunden bei der Implementierung von Nagios, Icinga und anderen Open Source Systems Management Tools. Neben seiner beruflichen Tätigkeit ist Markus aktiver Mitarbeiter im Debian Projekt.

The Icinga Config Compiler: An Overview

The Icinga configuration format was designed to be easy to use for novice users while at the same time providing more advanced features to expert users. At first glance it might look like a simple key-value configuration format:

object Host "example.icinga.com" {
	import "generic-host"

	address = "203.0.113.17"
	address6 = "2001:db8::17"
}

However, it features quite a bit of functionality that elevates it to the level of scripting languages: variables, functions, control flow (if, for, while) and a whole lot more.

Icinga’s scripting language is used in several places:

  • configuration files
  • API filter expressions
  • auto-generated files used for keeping track of modified attributes

In this post I’d like to show how some of the config machinery works internally.

The vast majority of the config compiler is contained in the lib/config directory. It weighs in at about 4.5% of the entire code base (3059 out of 68851 lines of code as of July 2018). The compiler is made up of three major parts:

Lexer

The lexer (lib/config/config_lexer.ll, based on flex) takes the configuration source code in text form and breaks it up into tokens. In doing so the lexer recognizes all the basic building blocks that make up the language:

  • keywords (e.g. “object”, “for”, “break”) and operators (e.g. >, ==, in)
  • identifiers
  • literals (numbers, strings, booleans)
  • comments

However, it has no understanding of how these tokens fit together syntactically. For that it forwards them to the parser. All in all the lexer is actually quite boring.

Parser/AST

The parser (lib/config/config_parser.yy, based on GNU Bison) takes the tokens from the lexer and tries to figure out whether they represent a valid program. In order to do so it has production rules which define the language’s syntax. As an example here’s one of those rules for “for” loops:

| T_FOR '(' identifier T_FOLLOWS identifier T_IN rterm ')'
{
        BeginFlowControlBlock(context, FlowControlContinue | FlowControlBreak, true);
}
rterm_scope_require_side_effect
{
        EndFlowControlBlock(context);

        $$ = new ForExpression(*$3, *$5, std::unique_ptr($7), std::unique_ptr($10), @$);
        delete $3;
        delete $5;
}

Here’s a list of some of the terms used in the production rule example:

Symbol Description
T_FOR Literal text “for”.
identifier A valid identifier
T_FOLLOWS Literal text “=>”.
T_IN Literal text “in”.
BeginFlowControlBlock, EndFlowControlBlock These functions enable the use of certain flow control statements which would otherwise not be allowed in code blocks. In this case the “continue” and “break” keywords can be used in the loop’s body.
rterm_scope_require_side_effect A code block for which Icinga can’t prove that the last statement doesn’t modify the program state.

An example for a side-effect-free code block would be { 3 } because Icinga can prove that executing its last statement has no effect.

After matching the lexer tokens against its production rules the parser continues by constructing an abstract syntax tree (AST). The AST is an executable representation of the script’s code. Each node in the tree corresponds to an operation which Icinga can perform (e.g. “multiply two numbers”, “create an object”, “retrieve a variable’s value”). Here’s an example of an AST for the expression “2 + 3 * 5”:

Note how the parser supports operator precedence by placing the AddExpression AST node on top of the MultiplyExpression node.

Icinga’s AST supports a total of 52 different AST node types. Here are some of the more interesting ones:

Node Type Description
ArrayExpression An array definition, e.g. [ varName, "3", true ]. Its interior values are also AST nodes.
BreakpointExpression Spawns the script debugger console if Icinga is started with the -X command-line option.
ImportExpression Corresponds to the import keyword which can be used to import another object or template.
LogicalOrExpression Implements the || operator. This is one of the AST node types which don’t necessarily evaluate all of its interior AST nodes, e.g. for true || func() the function call never happens.
SetExpression This is essentially the = operator in its various forms, e.g. host_name = "localhost"

On their own the AST nodes just describe the semantical structure of the script. They don’t actually do anything in terms of performing any real actions.

VM

Icinga contains a virtual machine (in the language sense) for executing AST expressions (mostly lib/config/expression.cpp and lib/config/vmops.hpp). Given a reference to an AST node – such as root node from the example in the previous section – it attempts to evaluate that node. What that means exactly depends on the kind of AST node:

The LiteralExpression class represents bare values (e.g. strings, numbers and boolean literals). Evaluating a LiteralExpression AST node merely yields the value that is stored inside of that node, i.e. no calculation of any kind takes place. On the other hand, the AddExpression and MultiplyExpression AST nodes each have references to two other AST nodes. These are the operands which are used when asking an AddExpression or MultiplyExpression AST node for “their” value.

Some AST nodes require additional context in order to run. For example a script function needs a way to access its arguments. The VM provides these – and a way to store local variables for the duration of the script’s execution – through an instance of the StackFrame (lib/base/scriptframe.hpp) class.

Future Considerations

All in all the Icinga scripting language is actually fairly simple – at least when compared to other more sophisticated scripting engines like V8. In particular Icinga does not implement any kind of optimization.

A first step would be to get rid of the AST and implement a bytecode interpreter. This would most likely result in a significant performance boost – because it allows us to use the CPU cache much more effectively than with thousands, if not hundreds of thousands AST nodes scattered around the address space. It would also decrease memory usage both directly and indirectly by avoiding memory fragmentation.

However, for now the config compiler seems to be doing its job just fine and is probably one of the most solid parts of the Icinga codebase.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Teamevent 2018

Plötzlich klafft ein mehrere Meter tiefer, fast senkrechter Spalt im Gestein. Es gibt keinen anderen Weg. Da müssen wir durch. Wird die Bismarckgrotte uns verschlingen? „Ich habe euch jetzt schon eine Weile beobachtet. Ihr seid fit! Ihr schafft das“, hat Nils gesagt. Na, wenn Nils das sagt. Nils muss es wissen. Immerhin hat er schon ganz andere Einsätze geleitet. 2014 etwa, als der Extrem-Höhlenforscher Westhauser im Riesending am Untersberg verunglückte, koordinierte er 14 Tage lang 700 Helfer – laut Wikipedia, ein neues Kapitel alpiner Rettungsgeschichte.

Heute führen er und Dirk uns, elf todesmutige Abenteurer aus den Abteilungen “Sales”, “Finance & Administration”, “Events & Marketing”, durch die Bismarckgrotte bei Rinnenbrunn. Die Höhle gehört mit einer Gesamtganglänge von ca. 1240 m und einer Tiefe von 52 m zu den größten frei zugänglichen der fränkischen Schweiz. Um es gleich vorweg zu nehmen: Wir mussten nicht gerettet werden! In mehreren Etappen 30 Meter abseilen, durch engste Schlufe sliden (“Schlufslider, go!”), die Dunkelheit und Stille, als wir einmal alle unsere Stirnlampen ausschalten mussten, der eingangs erwähnte, klaffende Spreizgang und sogar, dass wir drei Stunden weder Wifi noch Handys hatten: Kein Problem für uns! Jede und jeder behielt seinen Hintermann bzw. seine Hinterfrau im Blick, sodass wir am Ende geschlossen und ziemlich stolz wieder das Tageslicht erblickten. „Geschafft!“ — „Was wir alleine nicht schaffen, das schaffen wir dann zusammen,“ hatte am Vormittag als Motto 2018 auf der Flipchart gestanden. Vanessa, die es ausgesucht hat, und unsere Höhlenführer Nils und Dirk hatten also Recht! We can do it!

Bestens auf den abenteuerlichen Ausflug in die Höhle vorbereitet hatte uns der Vormittag: Keine Medien, keine Präsentation, stattdessen Flipchart und Gespräche. Alle drei Abteilungen gemeinsam und jedes Team im Einzelnen tauschte sich aus in punkto Wünsche und Ziele, Lob und Kritik, Ideen und Verbesserungsvorschläge. Alles, was gesagt werden musste, war gesagt. Der Team-Spirit gestärkt! Der Konferenzraum des Hotels Reiterhof in Wirsberg bot den richtigen Rahmen dafür, die sonnige Terrasse mit Weitblick über die Hügel des Frankenwalds das passende Ambiente für unsere mittägliche Stärkung.

Am Abend nach bestandenem Höhlenabenteuer wartete eine weitere Überraschung: Auf der Wiese oberhalb des Hotels flackerte ein Lagerfeuer, auf einem großen Grill bruzzelten leckere Steaks und an einer langen, festlich gedeckten Tafel servierte uns das Servicepersonal alles, was das Herz begehrt.

Zu welcher Zeit die Feierei ihr Ende nahm, soll geheim bleiben. Unsere drei Abteilungen dürfen ab sofort den Zusatz „& Expeditionen“ im Namen führen. Danke Vanessa und Markus für die hervorragende Organisation, an unsere Höhlenguides Dirk und Nils und das Team vom Reiterhof! Schön war’s!

Julia Hornung

Autor: Julia Hornung

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

AI – Artificial Intelligence (Was ist das? Ist das Gefährlich?)

Heute mal was anderes:

Da ich mich in letzter Zeit mehr mit dem Thema AI/KI beschäftige, bot es sich für mich an einen kurzen Blogpost über dieses Thema zu schreiben.

Was ist AI/KI?

AI steht für “Artificial Intelligence“, zu deutsch “Künstliche Intelligenz (KI)

Schauen wir uns ein normales Programm an. Nach einer Reihe von Abläufen passiert etwas, dass nicht vorgesehen war und das Programm crasht mit einem Fehlercode, den man dann Googlen muss um in einem Forum auf eine Lösung zu stoßen.
Wenn wir uns jetzt eine KI anschauen, fällt uns schnell die Parallele zum Menschen auf. Die KI lernt nach dem Eintreten dieses unerwarteten Ereignisses, automatisch, wie man dieses vermeidet und den daraus resultierenden Error behebt.

Bill Gates hat das Ausmaß einer KI anhand eines Beispiels erklärt, das ich nun auch verwenden will.

Die Evolution hat uns mit einem sehr fortschrittlichen Algorythmus ausgestattet, der allerdings auf einem sehr langsamen Computer läuft. Limitierter Arbeitsspeicher, die Möglichkeit Informationen über Gestik und Sprache an andere Computer zu versenden und auch die Möglichkeit diese, über die Ohren, zu empfangen. Dieser Menschliche-Algorythmus ist allerdings so gut, dass er Erfahrung in Wissen umwandeln kann. Wenn wir das auf Softwareebene realisieren würden, könnten wir nicht wissen was passiert. Der Mensch ist durch eine langsame Evolution in seiner Weiterentwicklung limitiert, der fortschritt der Technik nicht. Im Gegenteil, der Fortschritt der Technik ist durch den Menschen limitiert. Würde eine KI mit genügend Rechenleistung sich weiterentwickeln, würde der für uns rasante Fortschritt der Technik, noch schneller gehen. Der Computer, bzw. die KI, wäre uns in jeder Art und Weise überlegen. Die Rechenleistung des Computers, auf dem die KI läuft, entscheidet hierbei die Geschwindigkeit, des Lernens, der KI.

Erste Ereignisse, bei denen der Computer den Menschen besiegte:

Deep Blue” war ein von IBM entwickelter Schachroboter, der aus dem vorherigen Projekt “Deep Thought” resultierte. 1996 gelang es Deep Blue den damaligen Schachweltmeister Garri Kasparow nach dem 90. Zug zur Kapitulation zu zwingen.

Google DeepMindsAlphaGo” ist eine weitaus leistungsstärkere KI als die damalige von IBM entwickelte Deep Blue-KI. AlphaGo hat 2016 den amtierenden Champion des Chinesischen Brettspiel “Go” nach einer Runde besiegt.

Warum ist der Erfolg von AlphaGo höher zu werten als der von Deep Blue?

Das Spiel “Go” bietet mehr Spielzüge an als Schach. Bei Go sind mehr Spielzüge möglich als es Atome im Universum gibt, sodass es unmöglich ist jeden möglichen Ausgang vorherzusehen und so eine Niederlage abzuwenden. Schach hat eine limitierte Zahl an Zügen, sodass das Simulieren eines Spielzugs für den Computer kaum ein Problem darstellt.

Warum ist AlphaGo, DeepBlue überlegen?

AlphaGo arbeitet mit dem “Deep Reinforcement Learning” was unserer Menschlichen Art zu lernen sehr nahe kommt. Es ist im Prinzip nur Try-and-Error, Reward-and-Punishment und Raw-Input. Der Computer lernt selber wie er in diesem Spiel gut wird.
Im Internet ist ein Video viral gegangen. In dem Video wird gezeigt wie ein Computer lernt “Super Mario World” zu spielen. Der Twitch-Streamer und Youtuber “SethBling”, schrieb diese KI und nannte sie “MarI/O”. Anders als bei anderen KIs, wurde MarI/O nicht gezeigt wie er das Spiel spielt oder gar wie die Steuerung lautet. Die KI musste selber lernen, wie es dieses Spiel spielt.

Deep Blue ging dagegen, im Spiel gegen Kasparow mit einer ganz banalen Methode vor. Nach jedem Zug, ging er jeden möglichen Ausgang des Spiels durch und errechnete eine Wahrscheinlichkeit um den nächsten Zug vorherzusehen und direkt auszukontern.

Forscher warnen vor Gefahren!

Durch Filme, wie zum Beispiel “Terminator” oder “iRobot”,  wird uns oft auf unterhaltende Art und Weise gezeigt, welche Gefahren beim entwickeln von KIs bestehen. Jedoch ist das ja nur Sci-Fi, oder? Der Astrophysiker Steven Hawking ist der Meinung, dass KI die größte Entwicklung in der Geschichte der Zivilisation sein kann.

“Success in creating AI, could be the biggest event in the History of our Civilization. Alongside the benefits, it brings Dangers, like powerful Atonomous Weapons […] it could bring great distruption to our Economy […] AI could develop a will of its own, that stands in conflict with ours.”

~ Steven Hawking

“But I think, the development of a full Artificial Intelligence, could spell the end of the Human race.”

~ Steven Hawking

Steven Hawking ist nicht der einzige der vor den Gefahren warnt. Tesla und SpaceX CEO Elon Musk ist der Meinung, dass KI der Auslöser für den dritten Weltkrieg sein könnte.

“The pace of progress in artificial intelligence […] is incredibly fast. […] The risk of something seriously dangerous happening is in the five-year timeframe. 10 years at most.”

~ Elon Musk

“There certainly will be job disruption. Because what’s going to happen is robots will be able to do everything better than us. … I mean all of us […] I am not sure exactly what to do about this. This is really the scariest problem to me”

~ Elon Musk

“If you’re not concerned about AI safety, you should be.”

~ Elon Musk

“AI is a rare case where I think we need to be proactive in regulation than be reactive”

~ Elon Musk

Russischer Präsident Vladimir Putin ist der Meinung, dass das Land das als erstes eine vollfunktionsfähige KI besitzt, die Welt regieren werde.

“It comes with colossal opportunities, but also threats that are difficult to predict. Whoever becomes the leader in this sphere will become the ruler of the world.”

~ Vladimir Putin

Meine Meinung

Meiner Meinung nach, ist KI ein sehr wichtiges Thema, wenn es um Technologie geht. Künstliche Intelligenz könnte sehr vieles bedeuten und es liegt in unserer Hand zu entscheiden, ob die Bedeutung nun Negativ oder Positiv ausfällt. Ich hoffe ich konnte einen kleinen Einblick bringen, Informieren und zu Diskussionen anregen.

Killian Pieper-Müller

Autor: Killian Pieper-Müller

Killian ist seit 1. September 2017 bei uns als angehender Fachinformatiker für Systemintegration. Er erwartet sich von seiner Ausbildung richtige Kenntnisse im Programmieren und in Linux. In seiner Freizeit schaut er sehr gerne Serien, Programmiert oder trifft sich mit Freunden ... im Internet zum Online-Gaming.

Let’s Encrypt HTTP Proxy: Another approach

Yes, we all know that providing microservices with Docker is a very wicked thing. Easy to use and of course there is a Docker image available for almost every application you need. The next step to master is how we can expose this service to the public. It seems that this is where most people struggle. Browsing the web (generally GitHub) for HTTP proxies you’ll find an incredible number of images, people build to fit into their environments. Especially when it comes to implement a Let’s Encrypt / SNI encryption service. Because it raises the same questions every time: Is this really the definitely right way to do this? Wrap custom API’s around conventional products like web servers and proxies, inject megabytes of JSON (or YAML or TOML) through environment variables and build scrips to convert this into the product specific configuration language? Always my bad conscience tapped on the door while I did every time.

Some weeks ago, I stumble upon Træfik which is obviously not a new Tool album but a HTTP proxy server which has everything a highly dynamic Docker platform needs to expose its services and includes Let’s Encrypt silently – Such a thing doesn’t exist you say?

A brief summary:

Træfik is a single binary daemon, written in Go, lightweight and can be used in virtually any modern environment. Configuration is done by choosing a backend you have. This could be an orchestrator like Swarm or Kubernetes but you can also use a more “open” approach, like etcd, REST API’s or file backend (backends can be mixed of course). For example, if you are using plain Docker, or Docker Compose, Træfik uses Docker object labels to configures services. A simple configuration looks like this:

[docker]
endpoint = "unix:///var/run/docker.sock"
# endpoint = "tcp://127.0.0.1:2375"
domain = "docker.localhost"
watch = true

Træfik constantly watch for changes in your running Docker container and automatically adds backends to its configuration. Docker container itself only needs labels like this (configured as Docker Compose in this example):

whoami:
image: emilevauge/whoami # A container that exposes an API to show its IP address
labels:
- "traefik.frontend.rule=Host:whoami.docker.localhost"

The clue is, that you can configure everything you’ll need that is often pretty complex in conventional products. This is for Example multiple domains, headers for API’s, redirects, permissions, container which exposes multiple ports and interfaces and so on.

How you succeed with the configuration can be validated in a frontend which is included in Træfik.

However, the best thing everybody was waiting is the seamless Let’s Encrypt integration which can be achieved with this snippet:

[acme]
email = "test@traefik.io"
storage = "acme.json"
entryPoint = "https"
[acme.httpChallenge]
entryPoint = "http"
# [[acme.domains]]
# main = "local1.com"
# sans = ["test1.local1.com", "test2.local1.com"]
# [[acme.domains]]
# main = "local2.com"
# [[acme.domains]]
# main = "*.local3.com"
# sans = ["local3.com", "test1.test1.local3.com"]

Træfik will create the certificates automatically. Of course, you have a lot of conveniences here too, like wildcard certificates with DNS verification though different DNS API providers and stuff like that.

To conclude that above statements, it exists a thing which can meet the demands for a simple, apified reverse proxy we need in a dockerized world. Just give it a try and see how easy microservices – especially TLS-encrypted – can be.

Marius Hein

Autor: Marius Hein

Marius Hein ist schon seit 2003 bei NETWAYS. Er hat hier seine Ausbildung zum Fachinformatiker absolviert, dann als Application Developer gearbeitet und ist nun Leiter der Softwareentwicklung. Ausserdem ist er Mitglied im Icinga Team und verantwortet dort das Icinga Web.

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

Autor: Christian Stein

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".