NETWAYS Blog

A short introduction to Kubernetes

von Rania Hedrich | Apr 6, 2022 | Kubernetes, Web Services

Ever since I was working in a DevOps role I was very curious about Kubernetes, what better way is there to learn through creating a YouTube video? Let me guide through the process of creating the YouTube Tutorial!

How did I get started?

First off I tried to watch a few different YouTube videos myself, and then transitioned to writing a script for it.
Since I was familiar with OpenStack, it was easier to get into it by diving head first into the documentation.
Even though the Kubernetes Documentation might be too technical or not well explained in some parts, in combination with the youtubers and blog posts you can get a good overview of K8s.
I gathered all the information I could find about all the objects and features in Kubernetes, and tried to get a broad understanding on how everything works.

Let’s hit the record button!

Since then I have been trying to see how I could record it best and which information I was getting across and what I needed to change.
After redoing my script and selecting, what Kubernetes knowledge I’d like to convey, I was finally able to get more into doing a proper recording.
Check out our webinar room at NETWAYS HQ! I was really happy that we already have such a good lighting and recording setup!

Rinse and repeat.

I recorded with OBS and really had a fun time, trying to get everything right and present it in a nice way.
As soon as I got some proper recordings down I demuxed the files with OBS and went on to edit the footage.
First I sorted everything into Intro, Welcome, Objects, Features, Benefits of Kubernetes and how to get started folders.
So I could easily edit the footage before putting it together.
Then I went into Adobe Premiere and cut the clips short and removed the unnecessary audio tracks.
After that I put everything together, threw in the Intro and Outro.
I was almost done after that, just needed to denoise the audio tracks and find some music for the intro and outro!

It’s a wrap!

Then the whole thing was finished, yay!
Who would’ve thought, creating a 12-minute-video would need that many steps prior, before it is actually uploaded on the internet? 😀 It was exciting to create the Kubernetes YouTube Tutorial, but now it’s even more exciting having the video ready!
Here’s the result and I hope you have fun watching the video, and maybe it helps you to get into Kubernetes more easily now!

If you are curious about your own Managed Kubernetes environment, then our NWS website is a great source of information for that. Our MyEngineers are also always available to help you create your dream cluster.
Cheers and have a good one!

Liebes Icinga 2, sag "Aaaaaah"

von Thomas Widhalm | Dez 22, 2017 | Icinga

Die meisten, die schon mal ein Support Ticket aufgemacht haben, kennen das:
„Hallo, ich hab‘ ein Problem, weil blah blubb.“
„Hi, das ist schade. Ich hab‘ hier ein paar Seiten Doku über Euer Setup. Ist das noch aktuell?“
Und erst dann geht’s los mit der eigentlichen Fehlersuche. Das hat vor allem den Hintergrund, dass viele unserer Kunden sehr unterschiedliche Ansätze haben, wie sie ihr Setup betreuen und mit uns zusammenarbeiten. Manche kontaktieren uns nur im Notfall, andere nehmen nur grössere Umbauten mit uns gemeinsam vor und pflegen alles andere selbst und wieder andere lassen alles von uns machen. Deshalb kommt auch immer erst die Frage, ob sich nicht vielleicht was geändert hat, was natürlich völlig ok ist, nur wissen muss man es für den Support.
Oder man stellt eine Frage im Monitoringportal. Dann kommt da auch gern mal: „Sag erstmal, was für ein Setup Du hast.“
Und genau für diese Fälle gibt’s jetzt (oder eher demnächst) das „Icinga 2 Diagnostics Script“. Das Script soll zwei Anwendungsfälle haben:

Einen ersten Überblick über die Eckdaten einer Installation
Eine umfassende Datensammlung um alle Feinheiten abzuklopfen

Dabei liegt der Fokus klar auf der ersten Anwendung. Icinga und die damit verbundenen Tools haben eine unglaubliche Flexibilität und können auf so viele unterschiedliche Arten verwendet und konfiguriert werden, dass es oft ziemlich aufwändig sein kann, einen ersten Überblick zu erhalten. Deshalb soll das Script einen nicht gleich mit Unmengen an Information überwältigen, sondern sie sinnvoll und übersichtlich aufbereiten. Dazu probiert es meist verschiedene Befehle durch, die einem Betriebssystem Informationen entlocken können und listet die Ausgabe dann entsprechend aufbereitet auf.
Der andere Modus sammelt so viele Informationen wie er nur kann, inklusive Logfiles, Konfiguration, Datenbankdumps, etc. Weil diese Daten manchmal Informationen enthalten, die man nicht rausgeben darf oder will, ist das nicht der Default Modus.
Egal, welchen Modus man verwendet, das Script sammelt die Daten und legt sie auf dem Host ab, der sie eingesammelt hat. Es gibt also keinen versteckten „Phone-Home“ Mechanismus oder eine „praktische“ Verschlüsselung, die nur verschlüsselte Daten zurücklässt, sodass der User nicht sieht, was er da verschickt. Auch ein Ändern der Daten ist vor dem Versand natürlich möglich, um z.B. Passwörter zu entfernen.
Ein Wunschtraum für die Zukunft wäre, dass das Script im Überblicksmodus auch auf ungewöhnliche Dinge prüft und nur meldet, wenn es etwas Erwähnenswertes gefunden hat. Also z.B. wenn eine Datenbank nicht dem Schema entspricht, das mitgeliefert wird – entspricht es, gibt’s aber keinen „Ok“ Eintrag, um die Übersicht nicht zu beeinträchtigen.
Das Script ist aktuell noch auf dem Stand eines schnellen Hacks, der nach einem Dokumentationstermin bei einem Kunden entstanden ist. Ich habe damals versucht, die relevantesten Eckdaten des Setups zu dokumentieren und mir notiert, welche Befehle ich benutzt habe. Das wurde noch etwas erweitert (Danke Dirk, für die vielen guten Ideen) und einige davon in ein Script gegossen. Wie wahrscheinlich die meisten, die selber Projekte laufen haben, bin ich noch höchst unzufrieden mit dem Funktionsumfang, dem Errorhandling, dem Scripting-Stil, usw. Da ich aber nicht wieder ewig warten will, bis ich doch mal Zeit finde, daran weiter zu schrauben, folge ich der Empfehlung meiner Kollegen und mache ein offizielles Icinga-Projekt daraus. Das motiviert mich erstens sicherlich dazu, eher weiter zu arbeiten und andererseits, wird so wohl eher auch mal jemand den ein oder anderen Pull-Request schicken. Bitte habt aber Verständnis dafür, dass der Fokus darauf bleibt, den Output übersichtlich zu halten.
Inzwischen befindet sich das Script schon in einem GitHub Repo im Icinga Bereich. Wer es testen möchte, Ideen dafür hat oder auch mitarbeiten möchte, findet dort alles Nötige.

Thomas Widhalm

Manager Operations

Pronomina: er/ihm. Anrede: "Hey, Du" oder wenn's ganz förmlich sein muss "Herr". Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 ist er bei der NETWAYS. Zuerst als Consultant, jetzt als Leiter vom Operations Team der NETWAYS Professional Services, das unter anderem zuständig ist für Support und Betriebsunterstützung. Nebenbei hat er sich noch auf alles mögliche rund um den Elastic Stack spezialisiert, schreibt und hält Schulungen und macht auch noch das eine oder andere Consulting zum Thema. Privat begeistert er sich für Outdoorausrüstung und Tarnmuster, was ihm schon mal schiefe Blicke einbringt...

Lies mehr von Thomas und triff unser Team

Clustershell und Foreman-API

von Marius Gebert | Dez 14, 2016 | Puppet, Engineering, Team, Programmiersprachen, Mac, Betriebssysteme, Ruby, Linux, Bash, IT Automation, Foreman, DevOps

Foreman bietet die Möglichkeit verschiedene Informationen über die Hosts einzusehen. Dazu gehören der Status, das Betriebssystem, Ressourcen etc. Möchte man nun, auf mehreren Hosts gleichzeitig ein Kommando absetzen, kann man sich auf jedem einzelnen einloggen oder eine Clustershell aufbauen.
Hierfür gibt es verschiedene Tools die dies erlauben. Eine Unbequemlichkeit die hier jedoch schnell aufkommt, ist das kopieren und einfügen der Hostnamen in die Commandline. Aus diesem Grund, habe ich etwas Zeit investiert und ein Ruby Script geschrieben, das es mir ermöglicht, mit festgelegten Filtern nach speziellen Listen von Hostnamen zu suchen und diese als eine einzige Ausgabe zu speichern. Ich habe für das erzeugen von Clustershells „csshX“ im Einsatz, welches ich auch direkt mit eingebunden habe.
Das get_hosts Script gibt es als GIST.
In diesem Script wird zunächst eine „config.yml“ geladen, in der die Foreman-URL und der Nutzername definiert sind. Eine Passwortabfrage erfolgt in diesem Script direkt auf der Commandline. Anschließend wird die Ausgabe der Foreman-API nach dem Auflisten aller Hostinformationen in JSON geparst und alle verfügbaren Parameter für die Hosts in das entsprechende Array gespeichert. Mit dem Parameter „-s / –server“ gibt man einen String an, nachdem speziell gesucht werden soll. Diese Ausgabe wird zusätzlich mit angehängt.
Gefiltert wird nach:
1) Reports enabled
2) OS Ubuntu 14.04 / Debian 8
3) Kein Match auf net-* oder netways.de (Als Beispiel)
Von den selektierten Hosts werden die Hostnamen in einer Commandline-Ausgabe mit einem Leerzeichen getrennt ausgegeben. Verschiedene werden sich eventuell fragen: „Wofür brauche ich das? Wieso sollte ich so ein Script verwenden?“
Die Antwort ist einfach: Bequemlichkeit und live Übersicht, was gerade passiert. Die Suchparameter lassen sich sehr leicht anpassen und die Ausgabe des Scriptes wird etwas an Zeit der administrativen Aufgaben sparen, vorallem dann, wenn man mehr als nur 2 oder 3 Server mit Puppet bespielen lassen möchte.
user@computer ~/Documents/ruby/foreman $ ruby script.rb Enter password: [ ] Trying to establish a connection... [OK] Password correct [OK] Connection established [ ] Collecting data... [OK] Data collected [RESULTS] Ubuntu csshX --login root test1.test.de test2.test.de test34.test.de test19.test.de mail.test.de icinga-001.test.de Debian csshX --login root icinga-002.test.de db-003.test.de db-021.test.de Finished succesfully
Wie bereits erwähnt, ist hierfür noch eine „config.yml“ Datei nötig, die gewünschte Parameter enthält. In diesem Fall die URL und den usernamen. Aber auch ein Gemfile, das sich in Ruby um bestimmte Versionen von Gems kümmert. (Mit einem „bundle install“ können diese installiert werden)
Die config.yml und das Gemfile gibt es ebenfalls als GIST.
Eingebaute „rescue Execptions“ im Script selbst, geben entsprechende Rückmeldung, sollte der Login oder eine der auszuführenden Verarbeitungsschritte fehlschlagen und brechen den Vorgang an dieser Stelle ab.

Braintower SMS Gateway – Icinga Plugin verfügbar!

von Christian Stein | Dez 31, 2015 | Icinga, Technology, Python, Development, Linux, Hardware

Trotz Weihnachten und dem bevorstehenden Jahreswechsel sind wir natürlich nicht untätig und stehts dabei unser Portfolio an Plugins weiter auszubauen. Heute möchte ich die Gelegenheit nutzen, um zum Jahresende ein nützliches Plugin für die Überwachung unserer Braintower Geräte mit Icinga vorzustellen.
Das kleine Python-Plugin bedient sich dabei der Statusseite des Gateways und liefert unter anderem Informationen über die Failed-Queue, die Signalstärke sowie die Uptime.
Will man das Gateways überwachen, ruft man das Plugin einfach mit folgenden Parametern auf:
./check_braintower -H 192.168.1.1 --signal-warning -85 --signal-critical -90
Die Werte der Parameter muss natürlich jeder auf seine Bedürfnisse anpassen 🙂
Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:
BRAINTOWER OK - que: 0 failed: 0 signal: -83db total: 0 state: Idle load: 0;0.03;0.05 time: 1451320254 disk free: 647569408 uptime: 9 min, 0 users
Selbstverständlich kann man nicht nur die Signalstärke überwachen, sondern eine Vielzahl von Parametern. Mit –help erhält man hier eine schöne Erklärung über die Möglichkeiten:
usage: check_braintower [-h] -H HOSTNAME [-T TIMEOUT] [-Q QUEUE] [-F FAIL] [--signal-warning SIGNAL_WARNING] [--signal-critical SIGNAL_CRITICAL]
optional arguments:

-h, –help	show this help message and exit
-H HOSTNAME, –hostname HOSTNAME	The host address of the SMS Gateway
-T TIMEOUT, –timeout TIMEOUT	Seconds before connection times out (default 10)
-Q QUEUE, –queue QUEUE	The warning threshold for the amount of queued SMS (default 1)
-F FAIL, –fail FAIL	The critical threshold for failed SMS (default 1)
–signal-warning SIGNAL_WARNING	The warning threshold for the minimum signal strength (in db, default 0)
–signal-critical SIGNAL_CRITICAL	The critical threshold for the minimum signal strength (in db, default 0)

Wer das Plugin ausprobieren möchte, kann dies natürlich gerne tun – wir freuen uns über Feedback! Verfügbar ist es auf Icinga Exchange und in unserem NETWAYS Git.

Christian Stein

Manager Sales

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Manager Sales 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".

Lies mehr von Christian und triff unser Team

Azubis erzählen: März 2015 Jean

von Diana Flach | Mrz 16, 2015 | Team, Serien, Technology

Name: Jean-Marcel Fach
Ausbildungsberuf: Fachinformatiker für Anwendungsentwicklung
Abteilung: Icinga2 core development
Lehrjahr: 1

Hallo,
ich schreibe hier als Azubi im Development einen Blogppost zur Serie „Azubis erzählen“. Dieser ist nach diesem Absatz auch zu lesen, aber zunächst werde ich vorstellen.
Ich bin 21 Jahre alt und arbeite seit einem halben Jahr bei Netways. Vorher war ich Student an der Erlanger Universität. Meine Aufgaben haben fast immer mit Icinga 2 zu tun, hin und wieder müssen auch sonstige Aufgaben erledigt werden, mal mehr programmiertechnischer Natur und mal weniger.
Eine dieser Aufgaben war das Script, das das Vorkommen eines Datums in einer Tabelle zählen sollte, doch bevor ich mich damit beschäftigen konnte musste ich erst einmal dafür sorgen das die richtige Datei geöffnet wird. Die Dateinamen sind etwa so kodiert:
NAME_DATUM_UHRZEIT_NUMMER.ENDUNG

Die Matrix war ein Perl Programm. Deswegen machen die Nachfolger auch so wenig Sinn

Wichtig sind dabei eigentlich nur Datum und Uhrzeit, doch wie unterscheidet man diese von den übrigen Teilen des Dateinamens?
Unterstriche zählen fiel als Erstes weg, da der NAME meist selbst noch Unterstriche enthielt. Also muss rückwärts gesucht werden. die Endung erkennt man daran, dass ein Punkt vor ihr steht… leider kann so eine Datei auch mehrere Endungen haben, etwa .txt.gz für komprimierte Dateien. Und wenn der NAME dann selbst einen Punkt enthalten kann…
Also musste eine andere Lösung her: regex
Die regular expression
Lange war ich etwas eingeschüchtert von regex, oft sah ich nur Monster wie dieses hier (Soll Email Adressen validieren, und ist dabei nicht einmal 100% korrekt, wenn man es genau nimmt) und wer will schon mit so einer Wand Text arbeiten müssen?
Also Augen zu und durch, anhand dieses Tutorials brachte ich mir also die regex Grundlagen bei, denn zum Lernen ist hier immer Zeit. Gar nicht mal so schwer, zum Glück gibt es dann noch diese Seite auf der man nach Herzenslust ausprobieren kann.
Nun aber zu meinem konkreten Problem:
deq_2214_20140415_140857_0413.txt.gz
Nach dem Muster oben ist klar, dass es sich um eine verpackte Textdatei, die 413te am 15.4.2014 aus der Serie ‚deq_2214‘, gespeichert um 14:08:57, handelt. Aber selbst wenn man das Muster nicht schon vorher kennt ist es leicht es zu erkennen, für einen Menschen. Für einen Computer eben nicht (Daher sind Computer Menschen in Go noch unterlegen, während sie im Schach unschlagbar sind).
Aber ein dummer Computer kann gut stur Schemata überprüfen:
(\w+)_(\d{8})_(\d{6})_(\d{4})(\.txt)(\.gz)?$
Ist die Lösung, Erklärung:

(\w+)    # Fasse den Anfang zu einer Gruppe zusammen ("deq_2214")
  _      # Unterstriche dienen als Abtrennung und werden übergangen
(\d{8})  # Eine Gruppe aus genau acht Zahlen, das Datum ("20140415")
  _
(\d{6})  # Eine Gruppe aus genau sechs Zahlen, die Uhrzeit ("140857")
  _
(\d{4})  # Eine Gruppe aus genau vier Zahlen, die Nummer ("0413")
(\.txt)  # Die Endung ".txt"
(\.gz)?  # Die optionale Zusatzendung ".gz"
  $      # Sorgt dafür das nach der Endung nichts mehr kommen kann
         # (".txt.gz.temp" ist ungültig)

« Ältere Einträge