Monthly Snap July 2020

Monthly Snap July 2020

July is typically a nice month at the NETWAYS HQ with our annual summer-meeting and our legendary barbecue. This year was a bit different with our first online summer-meeting, and a party with fewer guests, but nonetheless a great night!

Here is what we wrote about in July!

 

NETWAYS Web Services

Many a software for video conferences is found lacking in regards of data protection. Not “our” Jitsi though! Natalie shared the good news in DSGVO: Grün für Open Source Videokonferenzdienste.
In our blog series Kubernetes – so startest du durch! Sebastian wrote about managing Nodegroups in Kubernetes Nodegroups verwalten. Martin shared the advantages of APIs in NETWAYS Cloud: Alles im Griff mit API.

 

Icinga for Windows

A lot is happening in the world of Icinga for Windows! Read Alexanders` Plugins, Provider, PowerShell.

 

 

Technically…

Thomas was asked Is there a Company Backing PostgreSQL? His answer was: well, read it if you want to know! Marius told us of the new Gitlab hack in Gitlab Johnyj12345 Hack. Did you miss Afeefs blog on cluster and nodes? Read Cluster unter Proxmox virtual Environment.

 

Trainings and conferences

Pamela informed us that the stackconf 2020: Archives are now online. Browse through the slides, videos and photos, und look forward to the next stackconf!
Learn about the useful tool Terraform in our trainings! Julia gave us more info as well as the dates of upcoming trainings in Terraform Training: Provisionierung von Infrastruktur in der Cloud.
We are truly sorry to inform you that the DevOpsDays and the Open Source Monitoring Conference (OSMC) 2020 are cancelled. The decision was not easily made, but we feel that it is the right choice under the current circumstances.

 

Shop in our shop!

In Funk me Amadeus! Nicole let us in on upcoming changes in monitoring systems.
Which alerts are possible from the different products? Nicole showed us the shops overview in Neue Vergleichsseite zu unseren Messgeräten. Natalie put together a list explaining all of the SMS Gateway functions in Glossar für SMS Gateways.

 

OSMC 2019 recap

In our series OSMC 2019 | Recap Saeid wrote about the talk Vom Bordstein zur Skyline by Robert Waffen. Read about it or klick on the link to watch the whole talk!

 

#Lifeatnetways

In our blog series NETWAYS stellt sich vor you can get to know our team.

This month read about Ravi.

Catharina Celikel
Catharina Celikel
Office Manager

Catharina unterstützt seit März 2016 unsere Abteilung Finance & Administration. Die gebürtige Norwegerin ist Fremdsprachenkorrespondentin für Englisch. Als Office Manager kümmert sie sich deshalb nicht nur um das Tagesgeschäft sondern übernimmt nebenbei zusätzlich einen Großteil der Übersetzungen. Privat ist der bekennende Bücherwurm am liebsten mit dem Fahrrad unterwegs.

NETWAYS Cloud: Alles im Griff mit API

Die Nutzung von APIs ist in der modernen Softwareentwicklung nicht mehr wegzudenken und ein zentraler Bestandteil einer funktionierenden DevOps-Strategie. Mit einer API können Applikationen, die voneinander unabhängig sind, miteinander arbeiten und Daten austauschen.

Wozu brauche ich APIs?
APIs setzt man immer dann ein, wenn man einen hohen Grad an Automatisierung erreichen und eine dynamische und programmatische Infrastruktur aufbauen und betreiben will.

Was können wir?
Wir setzen bei unserem Cloud-Angebot auf nws.netways.de auf OpenStack und stellen somit unseren Hostingkunden auch die verfügbaren OpenStack-APIs zur Verfügung. APIs gibt es für alle OpenStack-IaaS-Komponenten in der NETWAYS Cloud: Compute (VMs), Storage (S3, Volumes, Images) und Network (VPNaaS, SDN, Firewall usw.).

Die OpenStack-APIs kannst Du verwenden, um Serverinstanzen zu starten, Images zu erstellen, Instanzen und Images Metadaten zuzuweisen, Speichercontainer und -objekte zu erstellen und andere Aktionen in deiner OpenStack-IaaS Instanz auszuführen.

Zielgruppe
Entwickler, Admins, DevOps und alle, die sich voll auf Ihre Anwendungen konzentrieren wollen.

Wie kann ich loslegen?
Einfach unter nws.netways.de einen Account anlegen und loslegen. Und bei Bedarf steht unser MyEngineer bei jedem Projektschritt mit zur Seite.

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.

Plugins, Provider, PowerShell

Im Icinga-Windows-Kosmos passiert in letzter Zeit sehr viel, vor allem durch das Zauberwort PowerShell. Framework, Plugins, Kickstart und Service, das alles hört man recht oft und auch neue Releases sind da oder stehen an. Doch wie schreibe ich meine eigenen Checks beziehungsweise Plugins? Gibt es Vorschriften an die ich mich halten sollte? Und kann ich mich auch an dem Projekt beteiligen?

Plugins und Provider

Als das Projekt gestartet worden ist, war es bereits angedacht, dass Plugins individuell anpassbar sein sollten. Um dies zu gewährleisten, war es wichtig die Daten, die zur Prüfung genutzt werden in einer normierten Form gesammelt zurückzugeben und hier kommen die Provider ins Spiel.

Was ist ein Provider?

Ein Provider sammelt Daten vom System und stellt sie zur Verfügung um in Plugins genutzt zu werden. Sehen wir uns das ganze im icinga-powershell-plugins repository an:
└── provider
├── bios
├── cpu
├── directory
├── disks
├── enums
├── eventlog
├── memory
├── process
├── services
├── updates
├── users
└── windows

Innerhalb dieser Verzeichnisse befinden sich in der Regel zwei Dateien. Im Falle von CPU wären das Icinga_ProviderCpu.psm1 und Show-IcingaCpuData.psm1. Respektive Dateien existieren auch in allen anderen Verzeichnissen.

Mit dem gleichnamigen Befehl Show-IcingaCpuData kann man nun alle generischen Daten zur Thematik CPU abfragen. Während die Datei Icinga_ProviderCpu.psm1 verschiedene Funktionen enthält um spezifische Daten anzufordern. Darunter zum Beispiel folgende Funktionen: Get-IcingaCPUArchitecture, Get-IcingaCPUArchitecture.

Im Falle von Get-IcingaCPUs könnte der Output beziehungsweise die bezogenen Daten, wie folgt aussehen – gekürzt und in JSON konvertiert:
{
"specs":  {
"L3CacheSize":  0,
"CurrentClockSpeed":  2100,
"VoltageCaps":  0,
"L2CacheSpeed":  null,
"ThreadCount":  1,
"CurrentVoltage":  null,
"LoadPercentage":  7,
"L2CacheSize":  null
},
"errors":  {
"ErrorDescription":  null,
"ErrorCleared":  null,
"ConfigManagerErrorCode":  {
"value":  "This device is working properly.",
"raw":  0
},
"LastErrorCode":  null
},
"metadata":  {
"ProcessorType":  {
"value":  "Central Processor",
"raw":  3
},
...
"SocketDesignation":  "CPU 1",
"ProcessorID":  "078BFBFF000306A9",
"NumberOfCores":  1,
"SerialNumber":  "",
"Architecture":  {
"value":  "x64",
"raw":  9
},
"Availability":  {

},
"AddressWidth":  64,
"Status":  "OK",
"StatusInfo":  {
"value":  "Enabled",
"raw":  3
},

}

Auf diese Daten können wir nun Aufbauen. Ob die Daten direkt zuträglich sind oder ausreichend für unsere Anwendung ist individuell.

Bevor ich ein Plugin schreibe!

Bevor es dazu kommt, dass man ein Plugin schreibt und Unmengen an Cmdlets benutzt und die Daten normiert, sollte man sich darüber im Klaren sein, was es alles für Provider gibt und vorher überprüfen, ob die Daten nicht in der ein oder anderen Form bereits vorhanden sind.

Gefällt mir etwas am Invoke-IcingaCheckCPUs Check nicht, dann ist es sinnig, zumindest zunächst den Provider des Check-Plugins zu betrachten und zu prüfen ob man nicht die Informationen die der Check erhält anders nutzen kann.

Falls das nicht der Fall ist, sollte man seinen eigenen Provider schreiben oder einen vorhanden ergänzen und uns vielleicht mit einen Pull-Request überraschen.

Aber wohin das Ganze?

Damit nicht alles verloren ist beim nächsten Update oder Konflikte auftreten, gibt es im Icinga-PowerShell-Framework ein Custom-Verzeichnis. Dieses unterteilt sich wiederum in /lib und /plugins. In das plugins-Verzeichnis kommen folgerichtig natürlich die Plugins, die ihr für euch individuell anlegt und die nicht oder noch nicht Teil des Repositorys sind.

Das Gleiche gilt natürlich auf für das Library-Verzeichnis. Wenn ihr das Rad neu erfinden wollt und ein Custom-Module baut für Test-Numeric oder euch das Ausgabeformat von Convert-Bytes stört, dann sind eure Tools hier sicher. Und natürlich auch da freuen wir uns über einen Pull-Request.

Wir halten fest, wenn man also ein Plugin baut, dann sollte man ein eigenes PowerShell Modul bauen und sich dabei weitestgehend zunächst an den vorhandenen Plugins orientieren und aufpassen, wo was hingehört.

Fazit

Wer es richtig machen will, fängt langsam an und baut vor allem modular. Erst der Provider, dann das eigentliche Check-Plugin. Desto größer der Provider, desto einfacher das Bauen der Check-Plugins, weil mit bereits vorhanden Informationen ist die Logik, der Check-Prüfung das wenigste Problem.

Wem das alles noch nicht genug ist, der kann auch mal auf unserem Youtube-Channel vorbei schauen, wo wir im Umfang unserer Webinare mit unter Custom Plugin Development und Custom Daemon Development besprochen haben.

Seit in jeden Fall gespannt wie es mit dem Projekt weitergeht und für noch mehr zum Thema Plugin schreiben schaut euch den Developer-Guide an.

Alexander Stoll
Alexander Stoll
Junior Consultant

Alexander ist ein Organisationstalent und außerdem seit Kurzem Azubi im Professional Services. Wenn er nicht bei NETWAYS ist, sieht sein Tagesablauf so aus: Montag, Dienstag, Mittwoch Sport - Donnerstag Pen and Paper und ein Wochenende ohne Pläne. Den Sportteil lässt er gern auch mal ausfallen.

DSGVO: Grün für Open Source Videokonferenzdienste

Jitsi Open Source Video Conferencing

Bei einer Prüfung der Berliner Datenschutzbeauftragten Maja Smoltczyk sind die führenden Videokonferenzplattformen Zoom, Teams und Skype von Microsoft sowie Google Meet, GoToMeeting, Blizz und Cisco Webex durchgefallen. “Leider erfüllen einige der Anbieter, die technisch ausgereifte Lösungen bereitstellen, die datenschutzrechtlichen Anforderungen bisher nicht”, erklärte sie. Den entsprechenden Bericht könnt ihr hier nachlesen.

Wörtlich ist dazu in dem Bericht vom 3. Juli 2020 zu lesen: “Rot markiert sind Anbieter, bei denen Mängel vorliegen, die eine rechtskonforme Nutzung des Dienstes ausschließen und deren Beseitigung vermutlich wesentliche Anpassungen der Geschäftsabläufe und/oder der Technik erfordern…”.

Grün abgeschnitten haben in Deutschland gehostete Open Source Videokonferenzlösungen wie Big Blue Button und auch unser Jisti Angebot in den NETWAYS Web Services.

Jitsi

Jitsi ist eine super Lösung, um schnell Videokonferenzen im Browser aufzusetzen oder zu chatten, mit Möglichkeit zum Screensharing und ist sowohl am Desktop als auch mobil nutzbar.

Jitsi lässt sich für den Online-Unterricht von Schulen und Akademien und für Videokonferenzen in Unternehmen einsetzen. Und wie man oben sehen kann, nutzen wir für unsere Videokonferenzen im Homeoffice natürlich auch Jitsi :-).

Der Einstieg bei uns ist ganz einfach: Mit wenigen Klicks steht bei den NETWAYS Web Services deine Videokonferenz – sicher in Deutschland gehostet und 30 Tage kostenfrei zum Testen!

Wir haben uns sehr darüber gefreut, dass unser Jitsi-Angebot gegen große Videokonferenzsystem so gut abschließen konnte. Wenn ihr weitere Informationen zu Jitsi und unseren Leistungen haben möchtet, meldet euch einfach bei uns.

Natalie Regn
Natalie Regn
Junior Office Manager

Natalie macht seit September 2019 ihre Ausbildung zur Kauffrau für Büromanagement hier bei NETWAYS. Vor ihrer Zeit bei NETWAYS war sie ein Jahr als Au-pair in Schottland unterwegs. Passend dazu widmet sie sich seit vielen Jahren dem Spielen der Great Highland Bagpipe. Natalie ist in ihrer Freizeit nicht nur musikalisch unterwegs, sondern auch sportlich. Sie trainiert im Fitnessstudio, geht gerne in den Kletterpark und in die Trampolinhalle.
Kubernetes Nodegroups verwalten

Kubernetes Nodegroups verwalten

This entry is part 8 of 7 in the series Kubernetes - so startest Du durch!

Seit dieser Woche können unsere Kunden das “Nodegroup-Feature” für ihre NWS Managed Kubernetes Cluster nutzen. Was sind Nodegroups und was kann ich damit bewerkstelligen? Das und mehr erklärt unser siebter Blogpost der Serie.

Was sind Nodegroups?

Mit Nodegroups ist es möglich, mehrere Kubernetes-Node-Gruppen zu erstellen und unabhängig voneinander zu verwalten. Eine Nodegroup beschreibt eine Anzahl von virtuellen Maschinen, die als Gruppe diverse Attribute besitzt. Im Wesentlichen wird bestimmt, welches Flavor – also welches VM-Modell – innerhalb dieser Gruppe verwendet werden soll. Es sind aber auch andere Attribute wählbar. Jede Nodegroup kann unabhängig von den anderen jederzeit vertikal skaliert werden.

Wieso Nodegroups?

Nodegroups eignen sich, um Pods gezielt auf bestimmten Nodes auszuführen. Es ist zum Beispiel möglich, eine Gruppe mit dem “Availability-Zone”-Attribut zu definieren. Neben der bereits bestehenden “default-nodegroup”, die die Nodes relativ willkürlich über alle Verfügbarkeitszonen verteilt, können weitere Nodegroups erstellt werden, die jeweils nur in einer Verfügbarkeitszone explizit gestartet werden. Innerhalb des Kubernetes Clusters kann man seine Pods in die entsprechenden Verfügbarkeitszonen bzw. Node-Gruppen aufteilen.
Ein weiteres mögliches Szenario ist es, seine Nodegroups nach schnellen und langsameren VMs einzuteilen. Services und Anwendungen, die keine besonderen Ansprüche erheben, können der langsameren und somit meist auch günstigeren Nodegroup zugewiesen werden, während Pods mit mehr Anspruch ausschließlich auf schnellen Nodes betrieben werden. Der eigenen Fantasie und den eigenen Voraussetzungen wird durch die gewonnene Flexibilität Genüge getan. Neue Nodegroups lassen sich bequem über das NWS Web-Interface anlegen:

Existierende Nodegroups anzeigen


Im ersten Bild sieht man unseren exemplarischen Kubernetes Cluster “k8s-ses”. Dieser verfügt aktuell über zwei Nodegroups: “default-master” und “default-worker”.

 

Neue Nodegroup erstellen

Eine neue Nodegroup lässt sich über den Dialog “Create Nodegroup” mit folgenden Optionen erstellen:

  • Name: Name der Nodegroup, der später als Label für K8s genutzt werden kann
  • Flavor: Größe der eingesetzten virtuellen Maschinen
  • Node Count: Anzahl der initialen Nodes, kann später jederzeit vergrößert und verkleinert werden.
  • Availability Zone: eine spezifische Verfügbarkeitszone
  • Minimum Node Count: Die Nodegroup darf nicht weniger Nodes als den definierten Wert beinhalten.
  • Maximium Node Count: Die Nodegroup kann auf nicht mehr als die angegebene Anzahl Nodes anwachsen.

Die zwei letzten Optionen sind insbesondere für AutoScaling ausschlaggebend und begrenzen somit den automatischen Mechanismus.

 

 


Anschließend sieht man die neue Nodegroup in der Übersicht. Die Provisionierung der Nodes dauert nur wenige Minuten. Jede Gruppe lässt sich zudem individuell in ihrer Anzahl jederzeit verändern oder auch wieder entfernen.

 

Nodegroups im Kubernetes Cluster verwenden

Innerhalb des Kubernetes Clusters kann man seine neuen Nodes, nachdem sie fertig provisioniert wurden und einsatzbereit sind, sehen.

 
kubectl get nodes -L magnum.openstack.org/role
NAME                                 STATUS   ROLES    AGE   VERSION   ROLE
k8s-ses-6osreqalftvz-master-0        Ready    master   23h   v1.18.2   master
k8s-ses-6osreqalftvz-node-0          Ready    <none>   23h   v1.18.2   worker
k8s-ses-6osreqalftvz-node-1          Ready    <none>   23h   v1.18.2   worker
k8s-ses-zone-a-vrzkdalqjcud-node-0   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-1   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-2   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-3   Ready    <none>   31s   v1.18.2   zone-a
k8s-ses-zone-a-vrzkdalqjcud-node-4   Ready    <none>   31s   v1.18.2   zone-a

Die Node-Labels magnum.openstack.org/nodegroup und magnum.openstack.org/role tragen bei Nodes, die der Gruppe zugehörig sind, den Namen der Nodegroup. Zudem gibt es noch das Label topology.kubernetes.io/zone, das den Namen der Availability Zone trägt.

Mit Hilfe des nodeSelectors können Deployments oder Pods den Nodes bzw. Gruppen zugeordnet werden:

 
nodeSelector:
  magnum.openstack.org/role: zone-a

 

Du möchtest Dich selbst davon überzeugen, dass Managed Kubernetes bei NWS so einfach ist? Dann probiere es gleich aus auf: https://nws.netways.de/de/kubernetes/

Sebastian Saemann
Sebastian Saemann
Head of Managed Services

Sebastian kam von einem großen deutschen Hostingprovider zu NETWAYS, weil ihm dort zu langweilig war. Bei uns kann er sich nun besser verwirklichen, denn er leitet das Managed Services Team. Wenn er nicht gerade Cloud-Komponenten patched, versucht er mit seinem Motorrad einen neuen Rundenrekord aufzustellen.

Ansible – Use Blocks and Rescue Errors

Ansible is a widely used and powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

Since version 2.0.0 Ansible introduced the usage of blocks, they provide the possibility to group or rescue failed tasks.
On blocks we can assign most directives which are available for any other task at block level, only loops aren’t available.

- name: Update Systems
  hosts: all
  tasks:
    - name: execute this block only for rhel family hosts
      block:
        - name: install epel repository
          yum:
            name: epel-release
            state: present

        - name: install updates
          yum:
            name: '*'
            state: latest
            exclude: kernel*

      when: ansible_os_family == 'RedHat'
      become: true

When we try to deploy applications, sometimes we need to test connections or if requirements are met. When those tasks fail caused by the negative test result, the playbook by default fails and therefore stops.
To force Ansible to execute all other tasks, we could use the directive ignore_failed: true and checking the return value for any other depending task.

With blocks this is easily solved, by using rescue to catch the error and force a particular tasks to run.
The always will make sure that the listed tasks get executed.


- name: rescue my errors
  hosts: localhost
  tasks:
    - name: Try to reach host
      block:
        - name: "[Try reach DNS] Check Connection over DNS"
          command: ping client01.demo.local -c 2
          register: output
      rescue:
        - name: "[Rescue failed DNS] Check Connection over IP"
          command: ping 192.168.33.1 -c 2
          register: output
      always:
        - debug:
            var: output

To handle more than one rescue statement, the block can be simply used in the rescue section, like in the following example.


  - name: Try to execute skript
    block:
      - name: Check Connection over DNS
        command: ping nclient01.demo.local -c 2
        register: output
    rescue:
      - name: "this will fail"
        block:
          - name: it will be false
            command: /bin/false
            register: output
        rescue:
          - name: "this works"
            command: ping 192.168.33.1 -c 2
            register: output

Try to reduce ignored tasks in failed state with rescue blocks, this reduces the confusion of users when inspecting the output.
As second advice try to reduce code duplication by grouping tasks with similar directives.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

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