Devs are from Venus, Ops are from Mars? – DevOpsDays Berlin Program Online!!

You think Devs are from Venus, Ops are from Mars? Then you should definitely join us in Berlin for the upcoming DevOpsDays!
The two days are filled with learning about the new full spectrum for DevOps, latest platforms, and much more about the digital DevOps Journey – from September 12 – 13 at the Kalkscheune Berlin. Contribute to the Open Space and listen to professional talks.
The Program is now online – find out more about detailed talks, ignites, Open Spaces here
In a few days the DevOpsDays Berlin will start! Collaborate, exchange ideas, contribute to the Open Space and gain the know-how of the experts. Check it out – and get your ticket on

Keya Kher
Keya Kher
Marketing Manager

Keya ist seit Oktober 2017 in unserem Marketing Team. Sie kennt sich mit Social Media Marketing aus und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

A peek into GitLab 11, the Web IDE and Auto DevOps with Kubernetes

GitLab 11 was just released last week and introduces a bunch of new features. I’ve picked the most exciting ones for a short peek as our hosted production environment was already upgraded by Stefan 🙂


You can already add and edit files directly in your browser. Dirk mentioned this in his blog post, it motivates open source contributors to enhance the documentation. For larger changes we are used to fire up an IDE like Visual Studio, JetBrains Goland, PHPStorm, Atom, Eclipse, etc.
Sometimes you don’t need a full blown IDE, or you don’t have access to on your mobile device. It would be nice to have immediate results from build, compile and test stages, best in an isolated (container) environment.
The newly introduced GitLab Web IDE attempts to become a new player in the field. On the right you can already see the current pipeline job status from the latest commit. Once we’ve edited the file, we can commit (and push at once) and the CI will trigger a new job run. Just awesome!

In its current implementation, the IDE is accessible from files view only, but the roadmap proves that there’s more to come on project creation. Just type t in the main project view and search for a specific file. Then pick Web IDE from the upper left bullets and rock on. There is syntax highlighting and code auto-completion included ❤️


Auto DevOps with Kubernetes

Our vision is to replace disparate DevOps toolchains with a single integrated application that is pre-configured to work by default across the complete DevOps lifecycle.

Auto DevOps enables your CI/CD workflow to advance even further with pipeline container environments built on Kubernetes. GitLab provides its own Kubernetes integration, accompanied with default templates for projects and build pipelines. This isn’t limited to build, test, deploy stages but also includes a variety of additional stages:

  • Build and Test
  • Code Quality checks
  • Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Dependency and container scanning for vulnerabilities
  • Review Apps, deploy current state to temporary application environment in Kubernetes (optional)
  • Deploy to Kubernetes production environment (optional)
  • Monitoring for fetching deployment metrics from the Kubernetes cluster via Prometheus exporter (optional)

You can see the changes inside the menu where Operations was introduced and provides settings for environments and Kubernetes integration. This was previously found in the CI/CD section. A Kubernetes cluster can be assigned to a specific project, you can safely play and test without harming a global environment.
Nicole and Gabriel shared more insights into GitLab 11 features in their OSDC talk on “Git things done with GitLab!”. Check the archive for a live demo especially on the Auto DevOps feature, first time I fully understood its purpose 🙂

Notable Changes

In terms of roles, GitLab renamed “Master” to “Maintainer”.

GitLab also decided to release the “Squash and Merge” option into the Open source edition. This feature allows you to develop a merge request in multiple commits, and upon merge back to master, it will automatically squash the commits into a single one. Want to learn more about git squash? We’ve got you covered in our GitLab training 🙂

I really hope that GitLab will also open-source Merge request approvals in future releases. This is something which we use for code review and release managed on GitHub on a daily basis and would enhance our GitLab flow too.
Still not enough? I’d love to talk GitLab with you in our upcoming training sessions, including the best development workflows from our daily work 🙂

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

Releasing our Git and GitLab training as Open Source

Development is super fast these days, there are many tools and integrations to make it more comfortable. One of the version control systems is Git, next to well-known SVN and CVS. Git got really pushed by GitHub and most recently GitLab which provide entire collaboration suites. Nowadays you not only commit code revisions/diffs, you can also test and deployment changes immediately to see whether your code is good on defined platforms or breaks. Issue and project management is put on top and makes it very easy to collaborate.
Continuous integration (CI) allows for deeper code quality too. Add code coverage reports, unit test results, end2end tests and actually build distribution packages with tests on many platforms included. In addition to CI, continuous deployment (CD) adds the icing on the cake. Once CI tests and package builds are fine, add a new build job to your pipeline for automated deployments. This could for example push updated RPM packages for your repository and immediately install the bugfix release in production on all your client hosts with Puppet or Ansible.
You can do all of this with the ease of GitHub or your own hosted GitLab instance (try it out in NWS right now!). Don’t forget about the basics for development and devops workflows:

  • Untracked files, staging area, … what’s within the .git directory?
  • What is a “good commit“?
  • I want to create patch for an open source project – what’s a “pull request“?
  • Workflow with branches?
  • A developer asked me to “rebase your branch against master” and “squash the commits” … what’s that?

Our Git training sessions have been renewed into a two day hands-on session on Git and GitLab. Many of us are using Git on a daily basis at NETWAYS, in addition to GitLab. Knowledge which we share and improve upon. The training starts with the Git basics, diving into good commits, branching, remote repositories and even more. Day 1 also provides your own NWS hosted GitLab instance.
Starting with day 2, you’ll learn about development workflows with branches and real-life use cases. Continuing with CI/CD and generating your own Job pipeline, and exploring GitLab even further. We’ll also discuss integrations into modern development tools (Visual Studio, JetBrains, etc.) and have time to share experiences from daily work. I’ve been working with Git since the beginning of Icinga more than nine years ago.
We have open-sourced our GitLab training material. We truly believe in Open Source and want make it easier for development and contributions on your favourite OSS project, like Icinga.
You are welcome to use our training material for your own studies, especially if you are an open source developer who’s been learning to use Git, GitLab and GitHub. For offline convenience, the handouts, exercises and solutions are provided as PDF too.
Many of the mentioned practical examples and experiences are only available in our two day training sessions at NETWAYS so please consider getting a ticket. There’s also time for your own experience and ideas – the previous training sessions have shown that you can always learn something new about Git. You can see that in the Git repository and the newer Git commits, where this feedback was added to the training material ❤️
See you soon at the famous NETWAYS Kesselhaus for a deep-dive into Git and GitLab!
Please note that the training material is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

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

OSCamp 2018 – Speakers Line-Up

We are overwhelmed with all the excellent proposals we received for the OSCamp #1. We are happy to announce the speakers line-up for the 2018 Camp.
Confirmed speakers are:
Lennart Koopmann | GRAYLOG
Jan Doberstein | GRAYLOG
Daniel Neuberger | NETWAYS
Rico Spiesberger | MANN+HUMMEL
Dr. Matthias Dellweg | ATIX AG
Tanya Tereshchenko | Red Hat Czech s.r.o.
Timo Goebel | FILIADATA GmbH
Ewoud Kohl van Wijngaarden
Alexander Olofsson & Magnus Svensson | Linköpings University
…look for the updated speakers-list and further details here.
Short overview of the Open Source Camp
The main idea behind the OSCamp is a day packed with expert talks on the newest research, developments and future trends. The 2018 issue is dedicated to the OS projects Foreman and Graylog. Designed for experienced administrators and architects, the Camp will reflect new influences and developments of the featured Open Source projects. Get in touch with like-minded people, share expertise and discover new grounds – go for OSCamp this summer!
Does it sound tempting? Get your tickets here.
We look forward to welcoming you @OSCamp on June 14, 2018 in Berlin!

Keya Kher
Keya Kher
Marketing Manager

Keya ist seit Oktober 2017 in unserem Marketing Team. Sie kennt sich mit Social Media Marketing aus und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

DevOpsDays 2017 | Berlin, Berlin, wir fahren nach Berlin!

Bald geht’s los zum 2. Hauptstadtevent in diesem Jahr! Am 18.+19. Oktober gehen die DevOpsDays in die nächste Runde!
Und NETWAYS darf wieder bei der Organisation unterstützen!

Als Unterstützung im kaufmännischen Bereich sind wir nun schon mehrere Jahre dabei und das Team der DevOpsDays ist uns dabei richtig ans Herz gewachsen. Umso mehr freuen wir uns auf zwei tolle Tage in Berlin (Hallo, Curry 36!).

Das Programm steht auch schon! Mit dabei sind unter anderem:

– Jason Diller (Long-lived DevOps and the Pit of Success)
– Ken Mugrage (It’s not Continuous Delivery if you can’t deploy right now)
– Andrea Giardini (DevOps moves fast, how can you move faster)
Neben vertiefenden Workshops bieten Open Spaces Raum für eigene Ideen der Teilnehmer! Hier findet Ihr das Programm!

Jetzt müsst ihr eigentlich nur noch euer Ticket holen und euch freuen wie ein Schnitzel! Wir tun das jetzt schon und freuen uns auf das vorletzte Spitzenevent in diesem Jahr, ehe die OSMC dem Jahr den krönenden Abschluss bereitet!

Ansible, so einfach!

Konfigurationsmanagement in Rechenzentren ist aus der modernen “DevOps” IT nicht mehr wegzudenken. Puppet, Chef, Salt oder Ansible automatisieren Umgebungen von mittelständischen Unternehmen bis hin zu Weltkonzernen.
Wenn wir die verschiedenen Lösungen betrachten, bedienen sie sich alle einer eigenen Sprache, diese soll möglichst einfach unsere Infrastruktur abbilden. (“infrastructure as a code”)
Da nicht jeder Admin im Tagesgeschäft programmiert, kann so eine Sprache ein Hindernis werden und Arbeitsschritte vielleicht verkomplizieren.
Seit einiger Zeit beschäftige ich mit Ansible, ein Tool welches ohne vorinstallierte Clients arbeitet und eine Konfiurationsprache basierend auf YAML nutzt.
Um Ansible zu nutzen muss lediglich eine SSH Verbindung, ein Benutzer mit Rootrechten und ein Inventarfile bestehen.
Das Sprache im YAML Format ist für jeden leicht lesbar und sofort verständlich.
Ansible kann entweder lokal auf dem Arbeitsrechner oder auf einem sogenannten “Managementnode” über bereitgestellte Pakete installiert werden.
Unter “/etc/ansible/” legen wir nach der Installation zusätzlich ein Inventar an.

$ cat /etc/ansible/hosts
host01.localdomain ansible_ssh_host=
host02.localdomain ansible_ssh_host=</pre lang="bash">

Wenn Ansible installiert und ein Inventarfile erstellt wurde, kann die Verbindung zum Server mit dem Modul “ping” getestet werden. Hierbei versucht Ansible den Server per SSH zu erreichen und einzuloggen.

$ ansible host01.localdomain -m ping
host01.localdomain | success >> {
"changed": false,
"ping": "pong"
}</pre lang="bash">

Alternativ kann statt dem Hostalias auch “all” gesetzt werden um alle Hosts aus dem Inventar zu prüfen.

$ ansible all -m ping</pre lang="bash">

Ansible bietet zahlreiche Module mit denen Pakete installiert, Dateien kopiert oder bearbeitet werden können. Hier findet ihr eine Übersicht aller Module
Tasks verwenden diese Module um die Arbeitsschritte in Playbooks oder Rollen auszuführen.
Beispiel eines Playbooks:

$ cat ansible_starter.yml
- hosts: all <- Führe die Tasks auf allen Hosts aus
    - name: say hello to everyone <- Name des Tasks
      debug:                      <- Name des Moduls
        msg: "Hello World"        <- Parameter des Moduls

– name: install ntp
name: ntp
state: installed
</pre lang=”yaml”>

$ ansible-playbook -s ansible_starter.yml
</pre lang="bash">
Diese Task werden der Reihenfolge nach auf dem Zielhost ausgeführt und damit haben wir schon eine kleine Automation geschaffen. Probiert's aus!

Da Ansible im Sturm mein Automationsherz erobern konnte war ich mit meinem Kollegen dieses Jahr auf dem Ansible Fest in London, einen Erfahrungsbericht der Veranstaltung findet ihr hier.

Thilo Wening
Thilo Wening
Senior Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Schleifen mit Puppet 4

War es bisher mit Puppet notwendig über eine Defined Ressource zu iterieren, ist dies nun in Puppet 4 in einer normalen Klasse möglich.
Als Beispiel nehmen wir eine internationale Firma. Diese Firma hat auf Ihrem Webserver Webseiten für Deutschland, England und Frankreich. nun möchte man für bestimmte Virtual Hosts den Webroot in dem die Seite liegt evtl. an einer anderen Stelle haben.
Dazu definieren wir einen Hash über den wir anschließend iterieren werden.
Folgender Hash kommt aus Hiera:

    webroot_ensure: 'present'
    web_root_directory: '/var/www/'
    webroot_ensure: 'present'
    web_root_directory: '/var/www/'
    webroot_ensure: 'present'
    web_root_directory: '/opt/www/'

Und hier der Puppetcode:

class nginx::vhost(
  Hash $vhosts = hiera_hash('nginx::vhost::vhosts', {}),
  file { ['/var/www', '/opt/www']:
    ensure  => directory,
    owner   => 'www-data'
    group   => 'www-data'
    mode    => '0755'
  $vhosts.each |$key, $value| {
    $vhost_name = $key
    $webroot_ensure = $value['webroot_ensure']
    $web_root_directory = $value['web_root_directory']
    if $webroot_ensure == 'present' {
      $create_webroot = 'directory'
      $force_webroot = false
      $webroot_action = 'creating'
    elsif $webroot_ensure == 'absent' {
      $create_webroot = 'absent'
      $force_webroot = true
      $webroot_action = 'removing'
    else {
      fail("Unknown value ${webroot_ensure} for parameter 'webroot_ensure'")
    file { "${webroot_action} Webroot ${web_root_directory} for ${vhost_name}":
      path    => $web_root_directory,
      ensure  => $create_webroot,
      force   => $force_webroot,
      owner   => 'www-data'
      group   => 'www-data'
      mode    => '0755'

Mit $vhosts.each wird über jedes Hash-Element iteriert. Der Key ist dabei der Domainname. In $value stehen dann die jeweiligen Unterschlüssel. Mit $value[‘Unterschlüssel’] greift man auf den Wert des jeweiligen Unterschlüssels im Hash zu.
Die Möglichkeit Schleifen in normalen Klassen zu nutzen ist definitiv eine der nützlichsten Neuerungen in der Puppet DSL. Viel Spass beim ausprobieren!

NodeJS HA mit PM2…

ich hatte in Vergangenheit bereits einen Blog Post über NodeJS in Verbindung mit dem NodeJS ‘Cluster’ Modul geschrieben ( siehe hier ), nun möchte ich euch zeigen wie Ihr eure NodeJS Anwendung auch ohne Programmierarbeit (also als reine Ops Tätigkeit) zum Cluster umfunktioniert und wie ihr diese anschließend verwalten könnt.
Legen wir los, wir benötigen hierzu NodeJS, am besten 4.4 LTS und 4 zusätzliche Module/Helper, fangen wir also mit der Installation an…

$ npm install -g pm2
$ npm install -g express-generator
$ mkdir ~/project && cd project
$ npm install --save express
$ npm install --save sleep

…nun generieren wir das Express Anwendungsgerüst…

$ express -f .
   create : .
   create : ./package.json
   create : ./app.js
   create : ./public
   create : ./public/javascripts
   create : ./public/images
   create : ./public/stylesheets
   create : ./public/stylesheets/style.css
   create : ./routes
   create : ./routes/index.js
   create : ./routes/users.js
   create : ./views
   create : ./views/index.jade
   create : ./views/layout.jade
   create : ./views/error.jade
   create : ./bin
   create : ./bin/www
   install dependencies:
     $ cd . && npm install
   run the app:
     $ DEBUG=project:* npm start

… danach löschen wir in der Datei app.js alles von Zeile 13 bis 58, wir benötigen nur das Gerüst selbst und ein paar Zeile selbst geschriebenen Code, um diesen kommen wir leider nicht herum, da wir ja auch was sehen wollen.
Fügt nun ab Zeile 14 folgenden Code hinzu…

var crypto = require( 'crypto' );
var util = require( 'util' );
var sleep = require( 'sleep' ).sleep;
function getRandHash() {
    var current_date = (new Date()).valueOf().toString();
    var random = Math.random().toString();
    return crypto.createHash('sha1').update(current_date + random).digest('hex');
var myID = getRandHash();
app.get( '/', function( req, res ) {
    sleep( Math.floor( (Math.random() * 3) + 1 ) );
        "ID": myID,
        "ENV": process.env

…nun starten wir die App über PM2 im Cluster Mode, hier bitte dem Parameter ‘-i’ nur einen Wert gleich der Anzahl der CPU Cores mitgeben. Dann testen wir das Ganze doch gleich mal…

$ cd project
$ pm2 start bin/www -i 4

…ihr solltet nun folgende Ausgabe zu sehen bekommen…
…ihr könnt eure Anwendung auch auf Fehler überprüfen, dafür gibt euch PM2 einen Parameter ‘logs’ mit, der wiederum einige Flags kennt. Wenn ihr nur ‘pm2 logs’ eingebt dann bekommt ihr die Standardausgabe unserer Anwendung zu sehen, wenn ihr zusätzlich das Flag ‘–err’ mit angebt, bekommt ihr die Standard Fehlerausgabe, was für das Debugging recht hilfreich ist.
So, nun könnt ihr in eurem Browser mal die Anwendung aufrufen. Der Listener der Anwendung horcht auf dem Port 3000. Ein Aufruf auf sollte ein JSON liefern, ähnlich zu dieser Ausgabe hier…
Da wir in unserem Code eine künstliche Verzögerung eingebaut haben, könnt ihr nun mit 2 direkt Aufeinander folgenden Browser Reload sehen das sich die ID u. PID Werte gelegentlich ändern, dies bedeutet, dass unsere Cluster Anwendung funktioniert.
Ich hoffe ich konnte euch nun zum Spielen und Experimentieren animieren. PM2 wird von der Firma Kissmetrics als OpenSource Project stetig weiter entwickelt und hat noch so viel mehr zu bieten, ganz findige unter euch werden die Monitoring API zu schätzen wissen und diese vmtl. in Icinga2, Graphite, Kibana und anderen Lösungen integrieren wollen.
Dann bis demnächst 🙂

And again: Das Löschen von Images in der Docker-Registry

DockerDas Löschen von Images in einer Docker-Registry, ist ein Thema, das bereits sehr viel Zeit in Anspruch genommen hat. In einem früheren Blogpost wurde eine Variante vorgestellt, die mit einem separaten Script arbeitete. Da diese mit neueren Docker-Versionen jedoch nicht mehr funktioniert, wurde nach einer Alternative gesucht. Dabei haben wir erneut die von Docker mitgelieferte Möglichkeit getestet, die zu unserer Überraschung nun endlich richtig implementiert wurde.
Dieses Vorgehen sieht so aus, dass ein Image über die API gelöscht wird, wodurch die Abhängigkeiten der einzelnen Layer aufgelöst werden. Um dieser Layer Herr zu werden, ist es nötig einen Garbage-Collector zu starten, der diese Layer erfasst und entfernt. Der API-Call sieht zunächst wie folgt aus:
curl -k -X DELETE https://localhost:5000/v2/$IMAGENAME$/manifests/sha256:$BLOBSUM$
Die hierfür benötigte Blobsum kann einem Push/Pull des betroffenen Images entnommen werden. Tags wie “latest” werden in diesem Aufruf nicht akzeptiert. Der Garbage-Collector sollte in einem separaten Docker-Container laufen nachdem die Registry selbst gestoppt wurde. Wir haben diesen Vorgang mit einem Script umgesetzt. So ist es möglich, tagsüber Images manuell zu entfernen, sodass diese zu einer bestimmten Uhrzeit von einem Cronjob entfernt werden können.
echo "###################################################" >> /var/log/docker-registry-cleanup.log
/usr/local/sbin/icingaweb2-downtime.rb -s -H -S 'docker registry' -t 15 -c Cleanup && echo "$(date) [OKAY] Downtime was set." >> /var/log/docker-registry-cleanup.log
/etc/init.d/docker-registry stop && echo " $(date) [STOP] Stopping Docker-Registry ..." >> /var/log/docker-registry-cleanup.log
touch /var/log/docker-registry-cleanup.log
sleep 30
pgrep -f "/etc/docker/registry/config.yml"
echo $i
if [ "$i" = "0" ]
echo "$(date) [FAIL] Docker-Registry is still running. Aborting Cleanup" >> /var/log/docker-registry-cleanup.log
echo "$(date) [OKAY] Docker-Registry is not running. Starting Cleanup" >> /var/log/docker-registry-cleanup.log
docker run --rm -v /storage:/var/lib/registry -v /etc/docker/config.yml:/etc/docker/registry/config.yml registry:2 garbage-collect /etc/docker/registry/config.yml
/etc/init.d/docker-registry start && echo "$(date) [START] Starting the Docker-Registry ..."
pgrep -f "/etc/docker/registry/config.yml"
if [ $i=0 ]
echo "$(date) [OKAY] Docker-Registry is running after cleanup" >> /var/log/docker-registry-cleanup.log
echo "$(date) [FAIL] Docker-Registry is not running after cleanup" >> /var/log/docker-registry-cleanup.log

Dieses Script setzt ebenso eine Downtime von 15 Minuten für den Container der Registry im Icinga2 und schreibt seinen Output in ein Log.
Fri May 27 02:00:03 CEST 2016 [OKAY] Downtime was set.
Fri May 27 02:00:07 CEST 2016 [STOP] Stopping Docker-Registry ...
Fri May 27 02:00:37 CEST 2016 [OKAY] Docker-Registry is not running. Starting Cleanup
Fri May 27 02:01:10 CEST 2016 [OKAY] Docker-Registry is running after cleanup
Sat May 28 02:00:03 CEST 2016 [OKAY] Downtime was set.
Sat May 28 02:00:07 CEST 2016 [STOP] Stopping Docker-Registry ...
Sat May 28 02:00:37 CEST 2016 [OKAY] Docker-Registry is not running. Starting Cleanup
Sat May 28 02:01:13 CEST 2016 [OKAY] Docker-Registry is running after cleanup
Sun May 29 02:00:03 CEST 2016 [OKAY] Downtime was set.
Sun May 29 02:00:06 CEST 2016 [STOP] Stopping Docker-Registry ...
Sun May 29 02:00:36 CEST 2016 [OKAY] Docker-Registry is not running. Starting Cleanup
Sun May 29 02:01:13 CEST 2016 [OKAY] Docker-Registry is running after cleanup
Mon May 30 02:00:02 CEST 2016 [OKAY] Downtime was set.
Mon May 30 02:00:03 CEST 2016 [STOP] Stopping Docker-Registry ...
Mon May 30 02:00:33 CEST 2016 [OKAY] Docker-Registry is not running. Starting Cleanup
Mon May 30 02:00:41 CEST 2016 [OKAY] Docker-Registry is running after cleanup

Dieses Verfahren testen wir nun seit ein paar Wochen und sind mit dem Ergebnis sehr zufrieden.
Brauchen Sie Unterstützung für Ihr Docker Projekt? Dann empfehlen wir unser Docker-Hosting Angebot.

Marius Gebert
Marius Gebert
Systems Engineer

Marius ist seit 2013 bei NETWAYS. Er hat 2016 seine Ausbildung zum Fachinformatiker für Systemintegration absolviert und ist nun im Web Services Team tätig. Hier kümmert er sich mit seinen Kollegen um die NWS Plattform und alles was hiermit zusammen hängt. 2017 hat Marius die Prüfung zum Ausbilder abgelegt und kümmert sich in seiner Abteilung um die Ausbildung unserer jungen Kollegen. Seine Freizeit verbringt Marius gerne an der frischen Luft und ist für jeden Spaß zu...

OSDC 2016 – 8th year of glory

Time flies – 8 years Open Source Datacenter Conference (OSDC) already and now the 3rd time in lovely Berlin.
Kicking off with Dawn Foster’s keynote on Open Source – A job and an adventure gave an interesting insight into Open Source careers and living the spirit. As we do at NETWAYS since 1995 inviting everyone onto our journey and happily organising conferences for talks, chats & some drinks together.
And remember …

Next up was Kris talking about Another 7 tools for your #devops stack which is always fun to watch. I couldn’t decide whether to join him or go for Mike Elsmore on NoSQL is a lie … though Daniela approached me and said “go for Mike, it is funny”. And so it was in combination with the interesting technical questions asked.

Tough decisions already in the morning – we’re using CoreOS at NETWAYS too and so I could join Jonathan Bulle on rkt and Kubernetes: What’s new with Container Runtimes and Orchestration … or learning something new, moving away from Puppet and learn about Salt – A Scalable Systems Management Solution for Datacenters by Sebastian Meyer.
A pretty hard one also for the presenters as these talks ended right before lunch break – and as you might know already, food is always so delicious at OSDC.

Finding a place to chill after lunch (oh, it was delicious) should it now be What’s wrong with my Puppet? by Felix Frank or would I go for learning about some monitoring tasks with Hello Redfish, Goodbye IPMI – The Future of System Management in the Data Center with Werner Fischer. I guess I’m more with Puppet these days, less monitoring admin – and the live demo stuff somehow failed but nice to see David Schmitt helping out.

Ever since Elastic announced their Beats toolstack I wanted to learn more about it. I was pretty sad that I couldn’t join Elasticon earlier this year. So I was eagerly waiting for Monica Sarbu telling me more about Unifying Log Management and Metrics Monitoring with the Elastic Beats.

Having the Icinga stack in mind with open APIs and such, this shed interesting insights on how to further push integration with Elastic forward. Oh and I definitely need to learn Golang to hack my own beats based on the libbeat library.

Continuous Integration in Data Centers – Further 3 Years Later with Michael Prokop sounded interesting as well, especially when it comes to Jenkins and Docker integration. Luckily all talks are recorded and made available later in the conference archive so I decided to go for Elastic Beats this time.

Martin Schütte gave interesting insights into Terraform: Config Management for Cloud Services. This tool fits into the devops stack HashiCorp has been building over the last years, including Vagrant, Atlas and Otto. MySQL clusters are overly complicated in my (developer) opinion so I didn’t go for MySQL-Server in Teamwork – Replication and Galera Cluster presented by Jörg Brühe. Again one for the archive watchers 🙂

ChatOps is becoming more important these days. I’ve already seen Martin’s great talk at Icinga Camp Berlin earlier this year – especially his live demo talking to the Icinga 2 API which makes me a proud developer. ChatOps – Collaborative Communication (or: You cannot not communicate) is definitely something everyone needs to consider and play around with. Especially when it is Open Source.

Heading over from Austria left behind my DNS related past though I’m trying to keep with it. Especially since Jan-Piet is talking about DNS for Developers aka “Everything is a freaky DNS problem” 😉

Evening event

Now that we’ve learnt and discussed so much on the first day we are ready for the evening event. This time it located at Umspannwerk Ost which looks nice indeed. Looking forward to delicious food again and later on, some G&T with the OSDC gang 🙂

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