You missed out OSDC? — Sign up for OSCamp!

Hey folks!

The OSDC 2019 is in full swing! You didn’t get to be part of the happy DevOps crowd meeting in Berlin?

Here‘s your chance to find some relief by participating in the next big Open Source thing happening in Berlin this week: Be part of our OSCamp on Ansible!

But you gotta be really fast to grab one of the few remaining seats at opensourcecamp.de

To get a glimpse of how it feels to be one of the OSDC guys, just take a look at the photos published so far on our Twitter channel. And start getting excited what’s coming up at the OSCamp…

See you in Berlin on Thursday!

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...
OSDC 2019: Buzzwo…erm…DevOps, Agile & YAML programmers

OSDC 2019: Buzzwo…erm…DevOps, Agile & YAML programmers

Cheers from Berlin, Moabit, 11th round for OSDC keeping you in the loop with everything with and around DevOps, Kubernetes, log event management, config management, … and obviously magnificent food and enjoyable get-together.

 

Goooood mooooorning, Berlin!

DevOps neither is the question, nor the answer … Arnold Bechtoldt from inovex kicked off OSDC with a provocative talk title. After diving through several problems and scenarios in common environments, we learned to fail often and fail hard, and improve upon. DevOps really is a culture, and not a job title. Also funny – the CV driven development, or when you propose a tool to prepare for the next job 🙂 One key thing I’ve learned – everyone gets the SAME permissions, which is kind of hard with the learned admin philosophy. Well, and obviously we are YAML programmers now … wait … oh, that’s truly inspired by Mr. Buytaert, isn’t it? 😉

Next up, Nicolas Frankel took us on a journey into logs and scaling at Exoscale. Being not the only developer in the room, he showed off that debug logging with computed results actually eats a lot of resources. Passing the handles/pointers to lazy log function is key here, that reminds me of rewriting the logging backend for Icinga 2 😉 Digging deeper, he showed a UML diagram with the log flow – filebeat collects logs, logstash parses the logs into JSON and Elasticsearch stores that. If you want to go fast, you don’t care about the schema and let ES do the work. Running a query then will be slow, not really matching the best index then – lesson learned. To conclude with, we’ve learned that filebeat actually can parse the log events into JSON already, so if you don’t need advanced filtering, remove Logstash from your log event stream for better performance.

Right before the magnificent lunch, Dan Barker being a chief architect at RSA Security for the Archer platform shared stories from normal production environments to actually following the DevOps spirit. Or, to avoid these hard buzzwords, just like “agile”, and to quote “A former colleague told me: ‘I’ve now understood agile – it’s like waterfall but with shorter steps.'”. He’s also told about important things – you’re not alone, praise your team members publicly.

 

Something new at OSDC: Ignites

Ignite time after lunch – Werner Fischer challenged himself with a few seconds per slide explaining microcode debugging to the audience, while Time Meusel shared their awesome work within the Puppet community with logs of automation involved (modulesync, etc) at Voxpupuli. Dan Barker really talked fast about monitoring best practices, whereas one shouldn’t put metrics into log aggregation tools and use real business metrics.

 

The new hot shit

Demo time – James “purpleidea” Shubin showed the latest developments on mgmt configuration, including the DSL similar to Puppet. Seeing the realtime changes and detecting combined with dynamic processing of e.g. setting the CPU counts really looks promising. Also the sound exaggeration tests with the audience where just awesome. James not only needs hackers, docs writers, testers, but also sponsors for more awesome resource types and data collectors (similar to Puppet facts).

Our Achim “AL” Ledermüller shared the war stories on our storage system, ranging from commercial netApp to GlusterFS (“no one uses that in production”) up until the final destination with Ceph. Addictive story with Tim mimicking the customer asking why the clusterfuck happened again 😉

Kedar Bidarkar from Red Hat told us more about KubeVirt which extends the custom resource definitions available from k8s with the VM type. There are several components involved: operator, api, handler, launcher in order to actually run a virtual machine. If I understand that correctly, this combines Kubernetes and Libvirt to launch real VMs instead of containers – sounds interesting and complicated in the same sentence.

Kubernetes operators the easy way – Matt Jarvis from Mesosphere introduced Kudo today. Creating native Kubernetes operators can become really complex, as you need to know a lot about the internals of k8s. Kudo aims to simplify creating such operators with a universal declarative operator configured via YAML.

 

Oh, they have food too!

The many coffee breaks with delicious Käsekuchen (or: Kaiser Torte ;)) also invite to visit our sponsor booths too. Keep an eye on the peeps from Thomas-Krenn AG, they have #drageekeksi from Austria with them. We’re now off for the evening event at the Spree river, chatting about the things learnt thus far with a G&T or a beer 🙂

PS: Follow the #osdc stream and NetwaysEvents on Twitter for more, and join us next year!

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

Count Down for OSDC 2019

Only two more weeks to go until OSDC 2019! Your guide to happiness:

Mark the date. Grab your ticket. And start with getting excited!

To be fully prepared, here is your OSDC to do list:

  1. Grab your conference ticket – hurry, it’s already the last tickets call!
  2. Check out the conference agenda and create your very own conference program.
  3. Sign up for our “2019 Extra”: the free workshop on May 13 with James Shubin.
  4. See what we have planned for this year’s Dinner & Drinks event – Just this much: it’s getting wet …
  5. For the ultimate OSDC mood: take a glance at last year’s photos and start dreaming.

Well, there’s a lot for you to do – you better start right away! See you in Berlin!

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...

Ansible can talk to your favorite API

Ansible is a powerful opensource config management and deployment tool, which can manage nearly any situtation. In many “DevOp” scenarios we come across multiple platforms, which we need to combine. Mostly applications provide an REST Api or web connectors to manage resources, jobs and deployments within the product.
Ansible provides various modules which can execute commands at specific APIs, such as the vmware-guest-module to create virtual machines or the jenkins-job-module to manage jobs over the Jenkins API.
In cases where no module is available, we can use the module “uri”.

The module takes several parameters, of which the “url” is the only required one. For this example I picked an example online API “http://dummy.restapiexample.com/”.
To get a list of all employees we use the method GET on http://dummy.restapiexample.com/api/v1/employees, the header Accept: application/json and register the content.


- name: Make requests to example api
  hosts: localhost
  connection: local
  tasks:
    - name: list employees
      uri:
        method: GET
        url: "http://dummy.restapiexample.com/api/v1/employees"
        return_content: yes
        headers:
          Accept: application/json
      register: response

    - debug:
        msg: "{{ response.content }}"

# Result
TASK [list employees] *************************************************************************
ok: [localhost]

TASK [debug] **********************************************************************************
ok: [localhost] => {
    "msg": [
        {
            "employee_age": "23",
            "employee_name": "test",
            "employee_salary": "46000",
            "id": "12008",
            "profile_image": ""
        }
    ]
}

Now we create a new user in our application, for this we talk to a different url http://dummy.restapiexample.com/api/v1/create and send a body with our user to create.
When the api accepts JSON I use a little trick to generate a valid json body out of yaml variables with the Ansible filter to_json

For this we create a variable with the same key value structure as the API expects it, in this case the structure looks like this {“name”:”test”,”salary”:”123″,”age”:”23″}.


- name: Make requests to example api
  hosts: localhost
  connection: local
  vars:
    data:
      chris:
        name: chris
        salary: 46000
        age: 27
      jessy:
        name: jessy
        salary: 70000
        age: 30
  tasks:
    - name: create employee
      uri:
        method: POST
        url: "http://dummy.restapiexample.com/api/v1/create"
        return_content: yes
        headers:
          Accept: application/json
        body_format: json
        body: "{{ item.value | to_json }}" //Render valid json from each dictionary in the variable data.
      with_dict: "{{ data }}"
      register: post_content

    - debug:
        msg: "{{ item.content }}"
      with_items: "{{ post_content.results }}"

# Result
ansible-playbook create_user.yaml

PLAY [Make requests to example api] ********************************************************************

TASK [Gathering Facts] *********************************************************************************
ok: [localhost]

TASK [create employee] *********************************************************************************
ok: [localhost] => (item={'value': {u'salary': 46000, u'age': 27, u'name': u'chris'}, 'key': u'chris'})
ok: [localhost] => (item={'value': {u'salary': 70000, u'age': 30, u'name': u'jessy'}, 'key': u'jessy'})

With this information given, you can now explore your own favorite API and hopefully reduce your daily tasks as simple Ansible playbooks.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message!

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.

OSDC: DevOps Culture meets Technology

It has been there for a decade. In this time it has grown up from a buzzword to a key-subject discussed in many companies. You know, what I mean!

They call it DevOps

It’s more than a group therapy for frustrated IT engineers with new fancy tools, says Arnold Bechtoldt, Senior Systems Engineer at inovex. What are the technical symptoms of the DevOps method? Which problems aren’t actually technical? How to approach these issues? Arnold’s talk at OSDC will guide you through the jungle!

Are containers the DevOps killer? Or is there still any hope left for this culture in a containerized world? Martin Alfke is CEO at example42 GmbH, located in Berlin. He is a long-term Puppet specialist and trainer. At OSDC Martin will let you know what kind of security borders we have at hand to work separately but with trust.

Prepared thus, we will finally empower you to go the five steps to transformational change. At OSDC you’ll learn the essential methods that Dan Barker used in real transformations at multiple companies! Dan is Chief Architect at RSA Security for cloud migration and an organizer of DevOps KC.

OSDC focuses on innovative strategies, trendsetting developments and new perspectives in dealing with large data centers. The event takes place in Berlin, May 14 – 15, 2019.

NEW at OSDC: Free Workshop

Mgmt Config: Autonomous, real-time systems“ with James Shubin on the pre-conference day, May 13, 2019.
Get your conference ticket and workshop add-on ticket at osdc.de.

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.
Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Quick and Dirty: OpenStack + CoreOS + GitLab Runner

Wer in GitLab die CI/CD-Features nutzen möchte und nicht zufällig einen ungenutzten Kubernetes-Cluster übrig hat, mit dem man GitLab’s Auto DevOps Funktion einrichten kann, der benötigt zumindest einen GitLab Runner, um Build-Jobs und Tests zum Laufen zu bekommen.
Der GitLab Runner ist eine zusätzliche Anwendung, welche sich ausschließlich darum kümmert, bei einer GitLab-CE/-EE Instanz die CI/CD-Aufträge abzuholen und diese abzuarbeiten. Der Runner muss dabei nicht zwingend auf dem selben System wie das GitLab installiert sein und kann somit auch extern auf einem anderen Host laufen. Der Hintergrund, weshalb man das auch so umsetzen sollte, ist eigentlich recht klar: ein GitLab Runner steht bei einer aktiven CI/CD-Pipeline oftmals unter hoher Last und würde er auf dem gleichen Host wie das GitLab selbst laufen, so könnte er dessen Performance stark beeinträchtigen. Deshalb macht es Sinn, den GitLab Runner z.B. auf eine VM in OpenStack auszulagern.
In diesem Blogpost werde ich kurz darauf eingehen, wie man schnell und einfach eine GitLab Runner VM per CLI in OpenStack aufsetzen kann. Da ich den Runner als Docker-Container starten möchte, bietet sich CoreOS an. CoreOS kommt mit Docker vorinstalliert und es bietet die Möglichkeit per Ignition Config nach dem Start des Betriebssystems Container, oder auch andere Prozesse, automatisch starten zu lassen.

Sobald man sich bei seinem OpenStack-Anbieter in sein Projekt eingeloggt hat, kann man sich dort unter “API Zugriff” die OpenStack-RC-Datei herunterladen. Damit kann man sich dann recht einfach per CLI bei OpenStack authentifizieren. Voraussetzung für die Nutzung der CLI ist, dass man bei sich den OpenStack Command-Line Client installiert hat.
Sobald man beides hat, kann es auch schon losgehen:

    1. Runner Registration Token abholen
      Dazu loggt man sich als Admin in sein GitLab-CE/-EE ein und navigiert zu “Admin Area” -> “Overview” -> “Runners”. Hier findet man den aktuellen Registration Token.
    2. CoreOS Ignition Config
      Die Konfigurationsdatei für CoreOS nennt man z.B. config.ign. Diese legt man sich ebenfalls auf dem Rechner ab.
      Der Inhalt muss im nächsten Schritt geringfügig angepasst werden.

      config.ign

      { "ignition": { "version": "2.2.0", "config": {} }, "storage": { "filesystems": [{ "mount": { "device": "/dev/disk/by-label/ROOT", "format": "btrfs", "wipeFilesystem": true, "label": "ROOT" } }] }, "storage": { "files": [{ "filesystem": "root", "path": "/etc/hostname", "mode": 420, "contents": { "source": "data:,core1" } }, { "filesystem": "root", "path": "/home/core/config.toml", "mode": 644, "contents": { "source": "data:,concurrent=4" } } ] }, "systemd": { "units": [ { "name": "gitlab-runner.service", "enable": true, "contents": "[Service]\nType=simple\nRestart=always\nRestartSec=10\nExecStartPre=/sbin/rngd -r /dev/urandom\nExecStart=/usr/bin/docker run --rm --name gitlab-runner -e 'GIT_SSL_NO_VERIFY=true' -v /home/core:/etc/gitlab-runner -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:v11.8.0 \n\n[Install]\nWantedBy=multi-user.target" }, { "name": "gitlab-runner-register.service", "enable": true, "contents": "[Unit]\nRequires=gitlab-runner.service\n[Service]\nType=simple\nRestart=on-failure\nRestartSec=20\nExecStart=/usr/bin/docker exec gitlab-runner gitlab-runner register -n --env 'GIT_SSL_NO_VERIFY=true' --url https://$URL -r $TOKEN --description myOpenStackRunner--locked=false --executor docker --docker-volumes /var/run/docker.sock:/var/run/docker.sock --docker-image ruby:2.5 \n\n[Install]\nWantedBy=multi-user.target" } ] }, "networkd": {}, "passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "$your-ssh-pub-key" ] } ] } }
    3. Ignition Config anpassen
      Beim Systemd-Unit “gitlab-runner-register.service” setzt man im Content bei den Variablen “$URL” den FQDN der eigenen GitLab-Instanz und bei “$TOKEN” den in Schritt 1 kopierten Registration Token ein.
      Außerdem kann man gleich noch seinen SSH-Key mitgeben, damit man später auch per SSH auf die VM zugreifen kann. Diesen hinterlegt man unter dem Abschnitt “passwd” im Platzhalter “$your-ssh-pub-key”.
    4. CLI Commands
      Nun kann man sich auch schon das Kommando zum anlegen der VM zusammenbauen.
      Als erstes muss man sich bei OpenStack authentifizieren, indem man die Datei sourced, die man sich eingangs aus seinem OpenStack Projekt geladen hat und dabei sein OpenStack Passwort angibt:

      source projectname-openrc.sh

      Man sollte außerdem sicherstellen, dass in dem Projekt ein CoreOS Image zur Verfügung steht.
      Anschließend kann man nach folgendem Schema die Runner-VM anlegen:

      openstack server create --network 1826-openstack-7f8d2 --user-data config.ign --flavor s1.medium --image CoreOS_Live "GitLab Runner"

      Network, Flavor und Image sollten aber individuell noch angepasst werden.

    Nach ca. zwei Minuten sollte dann der Runner auch schon zur Verfügung stehen. Überprüfen lässt sich das, indem man sich als Admin in seine GitLab-Instanz einloggt und im Bereich unter “Admin Area” -> “Overview” -> “Runners” nach einem Runner mit dem Namen “myOpenStackRunner” nachsieht.

    Wer noch auf der Suche nach einem OpenStack-Provider ist, der wird bei den NETWAYS Web Services fündig. Mit nur wenigen Clicks hat man sein eigenes OpenStack-Projekt und kann sofort loslegen.

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.