pixel
Select Page

NETWAYS Blog

NETWAYS stellt sich vor: Björn Berg

This entry is part 41 of 41 in the series NETWAYS stellt sich vor

Name: Björn Berg

Alter: 21

Position bei NETWAYS: Junior Consultant

Bei NETWAYS seit: September 2021

Wie bist du zu NETWAYS gekommen und was genau gehört zu deinem Aufgabenbereich?

Ich habe 2019 mein Abitur gemacht und nach diversen Praktika in IT-Abteilungen und nach einigen Semestern Studium (Datenschutz & IT-Sicherheit) mich für eine Ausbildung zum Fachinformatiker für Systemintegration entschieden. Bei der Suche nach interessanten Betrieben stieß ich recht schnell auf NETWAYS und kam im Professional Services Team als Junior Consultant an Bord .
Dort nehme ich an Schulungen teil und mache zur Vertiefung basierend auf den Schulungsthemen verschiedene spannende Projekte, die auch immer mehr Transferleistungen abverlangen. Mit dem zweiten Lehrjahr kommt nun immer mehr Bewegung von “Grüne-Wiesen”-Projekten wie auch reelleren Umgebungen hinzu.

Was macht dir an deiner Arbeit am meisten Spaß?

Dass ich immer was dazulerne, und dabei auch immer wieder ganz neue Seiten sehe und mein Wissen in bekannten Feldern intensivieren kann. Auch habe ich großen Spaß daran, mir bei Projekten zusätzlich zur ursprünglichen Aufgabenstellung weitere sinnvolle Ergänzungen zu überlegen und tiefere Recherchen anzustellen.

Was machst du, wenn du nicht bei NETWAYS bist?

z.B. die abendliche Zockerrunde, Serien und Filme und immer wieder mal Campen. Außerdem wären da noch diverse private IT-Projekte und ich bin in verschiedensten Online-Communities sehr gern aktiv.

Wie geht es in Zukunft bei dir weiter?

Jetzt erstmal die Ausbildung abschließen, und dabei sehen, welches Team/Aufgabenfeld und welche Themen mich am meisten reizen.

 

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

HUGO: GitLab-CI/CD-Pipeline für eine statische Website

Vor etwa 4 Monaten habe ich hier einen Blogpost geschrieben, in dem ich Hugo vorgestellt habe – eine Software zum Generieren statischer Webseiten aus Markdown-Dateien.

Im Lauf meiner Ausbildung zum Fachinformatiker für Systemintegration bei NETWAYS habe ich vor kurzem an einer GitLab Fundamentals Schulung teilgenommen, um mehr über Git im allgemeinen und die Besonderheiten von GitLab im speziellen zu lernen. Auf Basis dieser Schulung und dem Projekt hinter oben genannten Blogpost habe ich nun eine CI/CD-Pipeline – CI/CD steht für Continous Integration and Continous Deployment – zum automatisierten Testen, Bauen und Ausrollen einer mit Hugo erzeugten Website gebaut.

Für dieses Projekt habe ich NETWAYS Web Services (NWS) eine GitLab CE App gestartet und außerdem in der Cloud von NWS zwei Webserver – einen als Testumgebung, einen als Produktivumgebung. Mithilfe meines Laptops als Client habe ich an der Website gearbeitet und die anfallenden Daten regelmäßig in ein eigenes GitLab Repository gepusht. Zum Testen, Bauen und Ausrollen auf die beiden Webserver laufen in der GitLab App zwei GitLab Runner. Das sind im Prinzip Agenten die für die GitLab App auf einem anderen System Befehle ausführen können.

Die CI/CD Pipeline

Die CI/CD Pipeline wird über die .gltiab-ci.yml gesteuert. Anfangs werden in der Pipeline die Quelldateien mithilfe zweier Markdown-Linter (vale.sh und markdownlint) getestet – in der .gitlab-ci.yml schaut das so aus:

lint:
   stage: lint
   tags: 
    - hugo
   allow_failure: true
   script:
    - cd tutorial
    - mdl ./content
    - vale ./content

Diese überprüfen die Inhalte der Website auf die Einhaltung eines Styleguides und auch auf die Sprachliche Korrektheit. Anschließend wird die Webseite mit Hugo gerendert, das heißt aus den Markdown-Dateien für den Websiteinhalt entsteht nun die wirkliche Website:

testBuild:
   stage: build
   tags:
    - test
   script:
    - cd tutorial
    - mkdir test
    - hugo -DEF --debug -d test
   artifacts:
   paths:
    - tutorial/test

Falls diese Operation auf der Testumgebung erfolgreich ist, wird sie auch auf der Produktivumgebung durchgeführt. Als Abschluss wird die gerenderte Webseite noch für den genutzten Webserver (z.B. Apache HTTPD oder nginx) bereitgestellt):

testDeploy:
   stage: deploy
   needs: [testBuild]
   tags:
    - hugotest
   script:
    - cp -r tutorial/test/* /var/www/html/
   only: 
    - main

Grafisch sieht diese Pipeline so aus:

Wenn auch Du solche interessanten Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für eine Ausbildung ab Herbst 2022 bewerben!

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

HUGO: Statische Websites generieren aus Markdown-Dateien

Im Studium hatte ich ein Seminar zur Webentwicklung – da haben wir einfache Websites in reinem HTML-Text mit etwas CSS drum herum geschrieben. Alternativ dazu wurde uns da noch die Benutzung des CMS (Content-Management-Systems) WordPress erklärt.

Im Zuge meiner Ausbildung bei der NETWAYS Professional Services durfte ich mich nun mit dem Static Site Generator Hugo auseinandersetzen. Ein Static Site Generator ist im Prinzip ein Tool das auf Basis von Rohdaten und Templates eine ganze statische HTML-Seite generieren kann. Im Falle von Hugo entscheidet man sich am Anfang der Seite für ein Theme. Je nachdem was herauskommen soll bieten sich verschiedene Themes an – so gibt es beispielsweise für Präsentationen und zum Schreiben von Dokumentationen spezielle Themes. Besonders zum Schreiben von Blogs existieren sehr viele (fast 300) Themes.

Es empfiehlt sich die Website lokal auf dem Client mit einer Hugo-Installation zu erzeugen und diese anschließend auf einen Webserver zu übertragen. Alternativ dazu bietet Hugo auch einen integrierten Webserver, der sich unter anderem mit einem LiveReload-Feature besonders gut zum Entwickeln der Seite eignet. Der Inhalt der Website wird bei Hugo grundsätzlich in Markdown-Dateien geschrieben, falls zusätzliche Formatierungen gewünscht sind kann auch HTML & ggf. auch JavaScript-Code integriert werden. Anstatt Inline-HTML-Code zu nutzen ist auch das Abrufen von Shortcodes möglich. Shortcodes sind im Prinzip kleine Codeschnipsel die eingebaute oder benutzerdefinierte Templates abrufen. Davon sind einige bereits von vornherein integriert, etwa zum simplen Einbetten von Videos auf bekannten Plattformen. Natürlich können Shortcodes in Hugo auch selbst angelegt werden. Hier mal exemplarisch ein Shortcode in der Datei ‘toc.html’:

{{ .Page.TableOfContents }}

Dies würde das vordefinierte TableOfContents-Template abrufen, welches auf Basis von Markdown-Überschriften dann ein Inhaltsverzeichnis generiert. Außerdem können in einem bestimmten Ordner auch Daten in den Formaten JSON, TOML und YAML abgelegt werden und in Hugo wieder eingelesen werden. Auch hier ein Beispiel, diesmal Produktdaten in einer YAML-Datei:

responsible: "Bjoern Berg"
product: "Gohugo"
id: [12345]

Falls gleich mehrere Leute (auch gleichzeitig) an einer Hugo-Website bauen sollen kann die Hugo-Seite auch als Git-Repository umgesetzt werden, so dass alle Personen Zugriff auf die Rohdaten der Website haben. Da es auf Websiten oft einige gleichartige Arten von Beiträgen gibt, können dafür Archetypen erstellt werden. Diese beinhalten dann bspw. bereits ein Grundgerüst für einen solchen Artikel wie Überschriften, Unterüberschriften, Tabellen und Metadaten. Per default erzeugt Hugo die URL-Struktur aus der Ordnerstruktur in den Rohdaten (die sich wiederum aus den vorher erwähnten Archetypen erzeugt). Alternativ dazu kann die URL-Struktur auch selbst spezifiziert werden (was dann für einen ganzen Archetyp gilt). Damit ist z.B. eine Terminologie a la example.com/2021/11/hugo-static-site-generator/ möglich. Dies wird dann im Buildprozess der Website umgesetzt (was bei Nutzung des in Hugo integrierten Webservers direkt nach Speichern der Markdowndatei geschieht). Ebenso im Buildprozess kann Hugo Bilder umformen – dabei ist das unter anderem das Konvertieren zwischen verschiedenen Dateiformaten, Bildgrößen und die Rotation des Bildes möglich.

Mein Eindruck von Hugo ist, dass es damit sehr einfach ist, eine schöne Website zu erstellen und diese auch effizient mit Daten zu befüllen. Durch die große Auswahl an Themes gehen auch viele verschiedene Websites und Designs. Wenn Du auch so tolle Projekte in Deiner Ausbildung zum Fachinformatiker machen möchtest, kannst du Dich gerne für einen Ausbildungsbeginn im Herbst 2022 bewerben!

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

OSMC 2021 | Thola – A tool for monitoring and provisioning network devices

This entry is part 3 of 22 in the series OSMC 2021

In November this year the OSMC 2021 took place. The two-days conference here in Nurembergs Old Town was all about Open Source Monitoring Solutions. This year, two students from Saarbrücken, Tobias Berdin and Stephan Schmidt from Inexio Deutsche Glasfaser talked about Thola, a new open source (licensed under the BSD 2-Clause license) tool for reading, monitoring and provisioning network devices.

 

How Thola has developed

Before they developed Thola, they used an old check plugin written in Perl for monitoring network devices. With the growth of their network, the usage of hardware resources also increased. In order to save resources, they began to create a new tool for monitoring and proviosiong network devcies in Go called Thola. Its first beta release was in late October 2020. The last major release 0.5 was in October 2021. It serves as a unified interface for communication with network devices and features a check mode which compiles with the monitoring plugins development guidelines.

Some of its features:

  • reading, monitoring and configuring of network devices
    • from many vendors like Huawei, Nokia, Cisco
    • from different device types like switches, routers, UPS
  • you can easy add support for more devices with YAML configuration files
  • support for icinga
  • RESTful API

 

Thola’s commands

With Thola you can monitor network interfaces, hardware stats and many more. This can be done by simply using Tholas’s CLI mode. Thola has some different commands:

  • thola identify – for automatically identifying a device with its properties like Vendor, Model, Serialnumber by its IP-Address
  • thola read interfaces – for reading out special interface informations of a device
  • thola check – can check metrics of devices and outputs them in a check plugin format, it can be used in monitoring tools like Icinga2
  • thola api – for configuring the thola api. Afterwards you can use the thola-client binary

Here is an example for checking out the cpu-load of a network device with thola check:

./thola check cpu-load 192.168.112.35 --warning 80 --critical 90
WARNING: average cpu load is 84% | 'cpu_load'=84%;80;90;0;100

For every supported vendor exists a specific device class, so for the ip10 devices from Ceragon exists a subclass in the ceraos-device-class. These device classes are written in a .yaml file. They are easy to write, not bound to a programming language and embedded in a binary. You can also automate the usage of thola with Ansible.

 

Full talk and more from and about OSMC 2021

Watch the whole talk by Tobias Berdin and Stephan Schmidt here:

YouTube player

 

Since OSMC 2021 is unfortunately over we still have something for you: Did you already check out this year’s conference archives? They provide you slides and videos of each talk and also some photographs of the conference itself.

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward  to meeting you all again!

Stay tuned!

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.

OSMC 2021 | Introduction into OpenSearch

This entry is part 1 of 22 in the series OSMC 2021

OSMC 2021 has been over for about a month now, and it was a pretty good conference, and also my first conference at NETWAYS. The two-day conference with Workshop and Hackathon was all about open source monitoring software like Icinga2, CheckMK and Prometheus. Now I want to give you some insights about one of the talks:

 

About the author

Jochen Kressin, CEO of floragunn, the Company behind SearchGuard, which provides Security and Alerting for OpenSearch and ElasticSearch, introduced the audience into OpenSearch at the Open Source Monitoring Conference 2021 in Nuremberg. In his talk, he gave us an overview about the history of ElasticSearch and the reasons for the license change of ElasticStack in early 2021, which was the main reason for the emergence of OpenSearch and OpenSearch Dashboards.

 

OpenSearch

OpenSearch is an open source search and analytics software suite, initiated by Amazon Web Services (AWS) and supported by other big IT companies like Red Hat and SAP. It is derived from Elasticsearch 7.10.2 and Kibana 7.10.2, which were licensed under the Apache Software License 2.0 (ASLv2). OpenSearch consists of two parts:

  • a search engine daemon called OpenSearch
  • a visualization and user interface, OpenSearch Dashboards

OpenSearch combines the features of Elasticsearch 7.10.2 with the features from Open Distro for ElasticSearch by AWS. OpenSearch was first announced in April 2021 and released in July 2021. The current Version 1.2 has been released just two weeks ago, on November 23.

But why was OpenSearch forked from ElasticSearch 7.10.2? Until January 2021, ElasticSearch had a free version with basic features using the ASLv2 and some commercial add-ons. In January 2021, ElasticSearch switched to a dual license model using the SSPL (Server-side public license) and the Elastic License v1. One month later, in February 2021, Elastic License v1 got replaced with the Elastic License v2, which is a more permissive license, but still not approved by the Open Source Initiative as an Open Source software license. The license change also means that ElasticSearch and Kibana cannot be offered as a managed service anymore. Elastic made this license change in order to prevent companies like AWS from making money with their products while not collaborating with Elastic. In other words: It is meant as a response to the continued non-collaborative engagement AWS pursued with ElasticSearch. Afterwards, AWS said that they will create and maintain a ASLv2-licensed fork of ElasticSearch and Kibana in order to ensure the availability of open source versions.

 

Free and Open Source Software

This raises the question of what are the benefits of FOSS (free and open source software). The goals of making open source software are getting developers on the board to contribute in order to improve the software, making the project known in the FOSS space and to increase its popularity in general. But there are also several disadvantages – many open source projects are fighting with a lack of funding, developers and time. Really successful projects are often backed by big companies or organizations, like the Apache2 Web Server (Apache Software Foundation) or Fedora Linux (Red Hat). Jochen Kressin also shared some of his thoughts about all this.

  1. Choose your weapons and license wisely
    You should fully understand what the license allows and disallows, and evaluate the advantages and disadvantages for your project
  2. Stick to your guns and license
    If you have chosen your license, stick with it.
  3. Wide adoption is often only possible with permissive license
  4. FOSS is not a business model
    it is not a means to generate revenue and can’t be the only foundation of a company

The future of OpenSearch and ElasticSearch will be very interesting. Elastic has more parts than only Kibana and ElasticSearch, it’s a whole ecosystem (with Logstash, Beats…). Building a community for the FOSS OpenSearch Project requires effort and steadiness. And enterprises require production readiness, professional services and good support (with SLAs).

 

Full talk and more from and about OSMC 2021

Watch the whole talk by Jochen Kressin here:

YouTube player

 

Since OSMC 2021 is unfortunately over we still have something for you: Did you already check out this year’s conference archives? They provide you slides and videos of each talk and also some photographs of the conference itself.

OSMC 2022 will take place from November 14 – 16 and we’re already looking forward  to meeting you all again!

Stay tuned!

 

Björn Berg
Björn Berg
Junior Consultant

Björn hat nach seinem Abitur 2019 Datenschutz und IT-Sicherheit in Ansbach studiert. Nach einigen Semestern entschied er sich auf eine Ausbildung zum Fachinformatiker für Systemintegration umzusteigen und fing im September 2021 bei NETWAYS Professional Services an. Auch in seiner Freizeit sitzt er viel vor seinem PC und hat Spaß mit diversen Spielen, experimentiert auch mit verschiedenen Linux-Distributionen herum und geht im Sommer gerne mal campen.