NETWAYS Blog

HUGO: Statische Websites generieren aus Markdown-Dateien

by Björn Berg | Jan 20, 2022 | Development, HTML / CSS, Programmiersprachen, NETWAYS

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’:

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

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.

Read more from Björn and meet the Team

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

by Björn Berg | Jan 4, 2022 | OSMC

This entry is part 3 of 23 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:

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

Junior Consultant

Read more from Björn and meet the Team

OSMC 2021 | Introduction into OpenSearch

by Björn Berg | Dec 7, 2021 | NETWAYS

This entry is part 1 of 23 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.

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
Stick to your guns and license
If you have chosen your license, stick with it.
Wide adoption is often only possible with permissive license
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).