pixel
Seite wählen

NETWAYS Blog

Hier erfährst Du alles was uns bewegt. Technology, Hardware, das Leben bei NETWAYS, Events, Schulungen und vieles mehr.

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

Internationale Feste | Wir feiern das ganze Jahr!

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

Prometheus Webinare in 2023

Prometheus Webinare in 2023

Letzte Woche haben wir im Rahmen unserer Webinare auf YouTube einen groben Überblick über die Lösung Prometheus gegeben - das Video kann man sich hier ansehen, sofern man den Termin verpasst hat. Um neben unserer Beratungsdienstleistung das Thema Prometheus weiter...

Automate Icinga for Windows with Ansible

Automate Icinga for Windows with Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw The role will allow you to manage...

Beratung & Technology

Automate Icinga for Windows with Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw The role will allow you to manage...

Automate Icinga for Windows with Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw The role will allow you to manage...

Automate Icinga for Windows with Ansible

Automate Icinga for Windows with Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw The role will allow you to manage...

Leap(p) to Red Hat Enterprise Linux 9

Leap(p) to Red Hat Enterprise Linux 9

Ich muss mich direkt für das Wortspiel im Titel entschuldigen, aber es lag so nahe als ich mich für das Thema entschieden hatte, denn ich möchte einen neuen Blick auf Leapp werfen mit dem Upgrades von Red Hat Enterprise Linux (RHEL) durchgeführt werden können. Der...

Schulungsnotebooks in neuem Gewand

Schulungsnotebooks in neuem Gewand

In diesem Jahr konnten wir endlich wieder mehr Vor-Ort Trainings durchführen als in den vergangenen Jahren und sogar vereinzelte Inhouse-Trainings bei Kunden waren möglich. Bisher haben wir bei unseren Präsenztrainings oder auch -workshops auf Notebooks mit CentOS 7...

Kickstart your Laptop with Linux

Kickstart your Laptop with Linux

Alle paar Jahre bekomme ich einen neuen Laptop bei Netways. Vor zwei Wochen war es wieder so weit und somit eine gute Gelegenheit mal wieder die Betriebssystem-Frage zu stellen. Die alte Frage also: "Welches Linux ist das Beste?". Also für mich ganz persönlich. Nicht...

Events & Trainings

OSMC 2022 | A Full Success

A Warm Welcome Finally the time has come! Our OSMC 2022 has started - this year without any restrictions. Thanks to Lukas and Markus, who took care of the planning like every year! Everything went flawlessly this time as well. We were very happy about all attendees...

OSMC 2022 | A Full Success

A Warm Welcome Finally the time has come! Our OSMC 2022 has started - this year without any restrictions. Thanks to Lukas and Markus, who took care of the planning like every year! Everything went flawlessly this time as well. We were very happy about all attendees...

OSMC 2022 | A Full Success

OSMC 2022 | A Full Success

A Warm Welcome Finally the time has come! Our OSMC 2022 has started - this year without any restrictions. Thanks to Lukas and Markus, who took care of the planning like every year! Everything went flawlessly this time as well. We were very happy about all attendees...

OSMC 2022 | Recap Day 1

OSMC 2022 | Recap Day 1

Welcome to our recap series of the Open Source Monitoring Conference 2022 (OSMC 2022) in Nuremberg. Last year the workshop and hackathon concluded the OSMC. This year three workshops will kick-off our long awaited conference. While the conference will be consecutive...

OSMC 2022 | The Countdown is on!

OSMC 2022 | The Countdown is on!

Wohoo! 🥳  It’s just one more week until our long-awaited Open Source Monitoring Conference is going to start. Our team’s preparations are in full swing and we’re super excited and happy to finally meet the whole OSMC community here in Nuremberg. Anticipation is half...

Jetzt ganz NEU: Prometheus Training

Jetzt ganz NEU: Prometheus Training

Wir haben unser Trainings Portfolio erweitert und freuen uns riesig, ab sofort Schulungen zum Monitoring Tool Prometheus mit und für Dich halten zu dürfen.   Was ist Prometheus? Prometheus ist ein Monitoring Tool auf Basis von Open Source. Es hilft Dir dabei, die...

Web Services

Announcing Kubernetes v1.24 and v1.25

We'd finally like to announce the release of Kubernetes v1.24 and v1.25 on our Kubernetes Platform. Since 1.24 brought many under the hood changes, our deployment process had to be refactored as well. While Version 1.24 and 1.25 were available on our platform for some...

Announcing Kubernetes v1.24 and v1.25

We'd finally like to announce the release of Kubernetes v1.24 and v1.25 on our Kubernetes Platform. Since 1.24 brought many under the hood changes, our deployment process had to be refactored as well. While Version 1.24 and 1.25 were available on our platform for some...

Announcing Kubernetes v1.24 and v1.25

Announcing Kubernetes v1.24 and v1.25

We'd finally like to announce the release of Kubernetes v1.24 and v1.25 on our Kubernetes Platform. Since 1.24 brought many under the hood changes, our deployment process had to be refactored as well. While Version 1.24 and 1.25 were available on our platform for some...

Wie Du Apps über Rocket.Chat Marketplace installierst

Wie Du Apps über Rocket.Chat Marketplace installierst

Nachdem Rocket.Chat von immer mehr Kunden möchte, ihren Cloud Service zu nutzen, ist es uns leider nicht mehr möglich, einige Features direkt beim Start Deiner App bereitzustellen. Nehmen wir als Beispiel mal die Jitsi App: um Jitsi nun nutzen zu können, musst Du die...

Cachet: Statuswebsite leicht gemacht!

Cachet: Statuswebsite leicht gemacht!

Wer die Blogs von NWS regelmäßig verfolgt und liest, wundert sich wahrscheinlich gerade „da ist ja jemand neues im Team" - ja ich habe die Ehre bei NWS vorbei schauen zu dürfen und noch mehr zu lernen. Das gehört zur Ausbildung bei NETWAYS dazu, um ein einheitliches...

Hardware

Klein aber Leistungsstark – Die neue sensorProbe1+

Die AKCP sensorProbe1+ erweitert mit ihrer simplen, aber Leistungsstarken Ausstattung ab sofort die sensorProbe+ Serie. Das kleine Gerät ist ein kostengünstiger Einstieg für die grundlegende Überwachung, da es mit allen intelligenten AKCP-Sensoren kompatibel ist....

Klein aber Leistungsstark – Die neue sensorProbe1+

Die AKCP sensorProbe1+ erweitert mit ihrer simplen, aber Leistungsstarken Ausstattung ab sofort die sensorProbe+ Serie. Das kleine Gerät ist ein kostengünstiger Einstieg für die grundlegende Überwachung, da es mit allen intelligenten AKCP-Sensoren kompatibel ist....

Klein aber Leistungsstark – Die neue sensorProbe1+

Klein aber Leistungsstark – Die neue sensorProbe1+

Die AKCP sensorProbe1+ erweitert mit ihrer simplen, aber Leistungsstarken Ausstattung ab sofort die sensorProbe+ Serie. Das kleine Gerät ist ein kostengünstiger Einstieg für die grundlegende Überwachung, da es mit allen intelligenten AKCP-Sensoren kompatibel ist....

Produkte im Shop bewerten und sparen!

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden? Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft...

HWgroup IP Watchdog2 – Volle Kontrolle in 2 Versionen

HWgroup IP Watchdog2 – Volle Kontrolle in 2 Versionen

Der HWgroup IP Watchdog2 ist ein Gerät zur Überwachung bestimmter Prozesse, das in der Lage ist, das überwachte Gerät aus der Ferne neu zu starten. Das Gerät ist in 2 Versionen erhältlich, die ich heute gerne vorstellen möchte. Beide sind ähnlich in der Anwendung,...

SMSEagle: Neue Software-Version 4.30

SMSEagle: Neue Software-Version 4.30

Wir freuen uns, Euch mitteilen zu können, dass diese Woche die neue Software-Version 4.30 für SMSEagle-Geräte veröffentlicht wurde! Diese Version enthält aufregende neue Funktionen, verschiedene Verbesserungen und einige Fehlerbehebungen. Nachfolgend findet Ihr eine...

Unternehmen

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

Internationale Feste | Wir feiern das ganze Jahr!

Internationale Feste | Wir feiern das ganze Jahr!

Advent, Advent, ein Lichtlein brennt... 🕯 Wir sind in Weihnachts- und Feiertagsstimmung! Aber genau genommen wird bei uns das ganze Jahr über gefeiert. Wir haben einige unserer internationalen Kollegen gefragt, welcher Feiertag in ihrem Heimatland am größten gefeiert...

OSMC 2022 | A Full Success

OSMC 2022 | A Full Success

A Warm Welcome Finally the time has come! Our OSMC 2022 has started - this year without any restrictions. Thanks to Lukas and Markus, who took care of the planning like every year! Everything went flawlessly this time as well. We were very happy about all attendees...

Alle Beiträge

NETWAYS Chefs – Katja backt Lebkuchenmänner

Der erste Advent steht vor der Tür und bei uns in Nürnberg sind sogar schon die ersten Schneeflöckchen gefallen. Das habe ich mir direkt zum Anlass genommen, um meine ersten Plätzchen zu backen – Lebkuchenmänner!

Um Dich auch auf pünktlich auf die Adventszeit einzustimmen, zeig ich Dir heute Schritt für Schritt wie Du aus einfachen Zutaten diese niedlichen Lebkuchenmännchen zaubern kannst. Die sehen nicht nur zuckersüß aus, sondern schmecken auch genau so! 😋

Here we go:

 

Das Brauchst Du…

…für den Teig

  • 650 g Mehl
  • 250 ml Honig/Agavendicksaft
  • 120 g Zucker
  •  80 g Margarine
  • 2 Eier
  • 1 Päckchen Backpulver
  • 1 Päckchen Lebkuchengewürz

…für die Glasur

  • 200 g Puderzucker
  • 1 Eiweiß
  • Lebensmittelfarbe

 

 

Und so Geht’s Los

Als erstes gibst Du Butter, Zucker und Honig/Agavendicksaft in einen Topf und erwärmst die Zutaten auf mittlerer Temperatur. Die Masse darf auf keinen Fall kochen! Ist die Butter geschmolzen und eine homogene Masse entstanden, lässt Du das Ganze abkühlen.

      

Sobald die Masse ausgekühlt ist, kannst Du sie mit den restlichen Zutaten in eine Rührschüssel geben. Mit einem Knethaken vermengst Du alles, bis ein klebriger brauner Teig entstanden ist.

Jetzt muss der Teig ausgerollt werden. Streue dazu Mehl auf Deine Arbeitsfläche und gib den Teig darauf. Das kann etwas dauern, da die Masse sehr schwer und klebrig ist – also nicht wundern, das ist völlig normal.

 

Hast Du den ganzen Teig herausbekommen, streust Du nochmal großzügig Mehl darüber und rollst ihn maximal 5 mm dick aus. Optional auch etwas dünner, je nachdem wie Du Deine Lebkuchen gerne isst. Und jetzt wird endlich ausgestochen! Schnapp Dir Deine liebsten Förmchen und los geht’s!

       

Lege jetzt Deine Lebkuchen auf ein mit Backpapier ausgelegtes Blech. Achte unbedingt darauf, dass etwas Abstand zwischen den Lebkuchen ist, damit sie im Ofen nicht zusammenlaufen.

      

⏰ Backe sie bei 160° Heißluft für 12-15 min.

Lass sie vollständig auskühlen, bevor Du mit der Glasur beginnst.

 

Jetzt wird’s Bunt!

Das Beste kommt bekanntlich zum Schluss! Genau so ist es auch bei meinen Lebkuchenmännern. Sind sie komplett ausgekühlt, kannst Du mit dem Verzieren beginnen. Gib dazu ein Eiweiß in eine Rührschüssel und warte bis es steif geschlagen ist. Anschließend kommen noch 200 g Puderzucker hinzu und das Ganze wird so lange verrührt, bis eine gleichmäßige Masse entstanden ist.

Falls Du, so wie ich, bunt liebst, kannst Du Deine weiße Glasur jetzt auf verschiedene Schüsseln aufteilen und nach Belieben einfärben. Nimm Dir einen Spritzbeutel zur Hand, fülle eine Deiner bunten Glasuren ein und los geht’s!

💡 Tipp: Falls die Glasur auf den Lebkuchen nicht hält, liegt das daran, dass noch zu viel Restmehl auf der Oberfläche ist. Nimm Dir dazu einfach ein feuchtes Küchenpapier und wische den Lebkuchen kurz und vorsichtig ab. Danach hält die Glasur perfekt.

Lass Deine verzierten Lebkuchen jetzt noch für ein paar Stunden trocknen – danach kannst Du sie endlich genießen! 😋

Ich wünsche Dir jetzt ganz viel Spaß beim Nachbacken, gutes Gelingen eine schöne Adventszeit! 🕯

Katja Kotschenreuther
Katja Kotschenreuther
Marketing Manager

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Online Marketing Managerin kümmert sie sich neben der Optimierung unserer Websites und Social Media Kampagnen hauptsächlich um die Bewerbung unserer Konferenzen und Trainings. In ihrer Freizeit ist sie immer auf der Suche nach neuen Geocaches, bereist gern die Welt, knuddelt alle Tierkinder, die ihr über den Weg laufen und stattet ihrer niederbayrischen Heimat Passau regelmäßig Besuche ab.

Automate Icinga for Windows with Ansible

This article will cover how to automate the monitoring of your windows infrastructure with Ansible and Icinga for Windows. For that, I developed a new Ansible role which you can find here: https://github.com/DanOPT/ansible-role-ifw

The role will allow you to manage your infrastructure dynamically with an Inventory and group_vars file. It’s also possible to define PKI Tickets in the inventory and the support of the Self-Service API is coming soon. The parent as well as the zone of each host will be defined with the group name and their associated group variables.

The following topics will be covered:

  • How to organize your Windows infrastructure with an Inventory and group_vars file dynamically
  • Setup with On-Demand CSR Signing on the master
  • Setup with PKI Tickets for the client (agent or satellite) generated on the master
  • Coming soon

Prerequisites

This guide will not cover how to configure your Ansible host for WinRM connections. For that, there are already enough Blog Posts about that topic and the Ansible Documentation also covers it in detail (https://docs.ansible.com/ansible/latest/user_guide/windows.html).

What we will need:

  • Icinga2 master instance
    You will need an Icinga2 master instance. I will use Ubuntu 20.04 and the Icinga Installer (https://github.com/NETWAYS/icinga-installer) to deploy the instance.
  • Windows host
    For that, I will use a Windows Server 2012.
  • Ansible host
    Ansible host with remote access to the Windows hosts.

How to deploy your Icinga2 master instance

Configure the Netways extra repository:

wget -O – https://packages.netways.de/netways-repo.asc | sudo apt-key add –
echo „deb https://packages.netways.de/extras/ubuntu focal main“ | sudo tee /etc/apt/sources.list.d/netways-extras-release.list

Icinga Installer requires the Puppet repository. So we will also need to configure the repository with the following commands:

wget -O – https://apt.puppetlabs.com/DEB-GPG-KEY-puppet-20250406 | sudo apt-key add –
echo „deb http://apt.puppetlabs.com focal puppet7“ | sudo tee /etc/apt/sources.list.d/puppet7.list

Install Icinga2 master instance (including IcingaWeb2 and Director):

sudo apt update
sudo apt install icinga-installer
sudo icinga-installer -S server-ido-mysql

Do not forget to write down your Password and Username.

How to organize the Windows hosts of your infrastructure with an Inventory and group_vars file dynamically

For the organization of your Windows hosts, you will need an Inventory file and a group_vars/<zone-name> file. In the group variables file, we will define the parent node name(s) as well as the parent address(es). In the Inventory it is possible to define a PKI ticket as a host variable.

So if we have a simple setup like this:

The Inventory file would look like this:

[master]
windows-2012 ansible_host=10.77.14.229

[satellite]
windows-2012-2 ansible_host=10.77.14.230

The group name will be used to define the zone name of the parent. The parent node name and address will be defined in group_vars/master and group_vars/satellite. Here is an example of the master file:

ifw_parent_nodes:
  - 'i2-master'
  #- 'i2-master-2'
ifw_parent_address:
  - '10.77.14.171'
  #- '10.77.14.172'

The variables always have to be a list, even if only one master needs to be specified.

Setup with On-Demand CSR Signing on the master

For simplification I will only use one host in my Inventory and the group_vars/masters file I already described:

[master]
windows-2012 ansible_host=10.77.14.229

The most simple way to connect agents is to sign the certificates on the master. To achieve this the agent has to be connected and after that, we can sign them. The role has already all variables required, so we just need to run the Playbook:

---
- hosts: all
  roles:
    - ansible-role-ifw

Run the playbook with the following command:

$ ansible-playbook playbook.yml -i hosts
PLAY [all] ****************************************************************************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************************************************************************************************************************************************
ok: [windows-2012]

TASK [ansible-role-ifw : Create icinga-install.ps1 using Jinja2] **********************************************************************************************************************************************************************************************************
ok: [windows-2012]

TASK [ansible-role-ifw : Execute icinga-install.ps1] **********************************************************************************************************************************************************************************************************************
skipping: [windows-2012]

PLAY RECAP ****************************************************************************************************************************************************************************************************************************************************************
windows-2012 : ok=2 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0

After that, we can verify if a request has been made on the master with this command:

$ icinga2 ca list
Fingerprint | Timestamp | Signed | Subject
—————————————————————–|————————–|——–|——–
*****************************************************************| Nov 2 04:57:32 2022 GMT | | CN = windows-2012

Setup with PKI Tickets for the client (agent or satellite) generated on the master

It’s also possible to define a PKI ticket as a hosts variable in the Inventory (replace <pki-ticket>):

[master]
windows-2012 ansible_host=10.77.14.229 pki_ticket=<pki-ticket>

After that we need to set the variable ‚ifw_certificate_creation‘ to 1 in the Playbook:

---
- hosts: all
  vars:
    ifw_certificate_creation: 1
  roles:
    - ansible-role-ifw

Just run the Playbook and the agent should be connected to your master.

 

Coming soon

  • Self-Service API for Director
  • JEA Profile
  • Local ca.crt
  • Custom repository
Daniel Patrick
Daniel Patrick
Senior Systems Engineer

Daniel interessiert sich schon sein Leben lang für Linux-Distributionen, Programmieren und Technik. Im Bereich Linux konnte er bereits zwischen vier und fünf Jahre Berufserfahrung sammeln. Seit August 2022 arbeitet er für NETWAYS. Bei seinem letzten Arbeitgeber war er mitverantwortlich für das Leiten und Organisieren eines sechsköpfigen Teams, galt als Wissensträger und einer der ersten Ansprechpartner des Kunden, wenn es um technische Probleme ging. Nach der Arbeit hört er meistens auch nicht mit dem Arbeiten auf, sondern schraubt unentwegt an seinen Maschinen herum. In seiner Freizeit schaut er sich gerne gute Filme an und kümmert sich um seine zwei geliebten Katzen.

OSMC 2022 | A Full Success

A Warm Welcome

Finally the time has come! Our OSMC 2022 has started – this year without any restrictions. Thanks to Lukas and Markus, who took care of the planning like every year! Everything went flawlessly this time as well. We were very happy about all attendees and contributors who made this event to something unforgettable!

 

Our Workshop Day

At the beginning this year a workshop day opened the OSMC. The following workshops were offered:

  • Icinga Director and Director Branches Workshop
  • Kubernetes Workshop
  • Prometheus Workshop

The demand was high and two workshops were completely booked. The participants enjoyed the comprehensive theoretical and practical knowledge of our trainers.

If you are interested and would like to learn more about the topics, please check out our NETWAYS trainings, which take place all around the year.

 

 

Time to Check-In

Lukas, Katja and I welcomed about 200 guests. We made sure everything runs smoothly, answered questions and handed out everyone’s visitor badge. In addition, participants who attended a workshop the day before received a certificate from us. Everything went to the fullest satisfaction.

 

Our Camera Team

The camera team this time consisted of Björn, Nick, Justin and Jonada. They were responsible for recording the individual speaker talks and did a great job.

Soon you will find the recordings on our Youtube channel and also in the archives of our event website.

 

 

Networking and Fun

Between our speaker presentations, attendees had the opportunity to socialize, exchange ideas and get to know like-minded people better. There were different sponsor booths to get information about our sponsors‘ companies and of course merch like stickers and socks.

In addition, the Activity Area offered a nice change with an XXL version of „Connect 4“ and „Jenga“. Massages were also offered, which contributed to relaxation and well-being. Lots of delicious snacks and drinks were also provided – but that’s nothing new at our events. 😉

It was nice to see, that our community came together after a long time. Old acquaintances met again and I could feel how much they enjoyed these moments.

 

Let’s get Together

This year’s evening event took place again at KORN’S in Nuremberg. The location is absolutely amazing and convinces every time anew. It’s the perfect spot for a relaxed and convivial conclusion of the first conference day. Besides a buffet and drinks, there was something really special that awaited our attendees: a roulette table! The atmosphere was absolutely amazing and we received lots of positive feedback.

 

 

On the whole, these three OSMC days were again a full success:  attendees gained lots of valuable expert knowledge as well as new friendships. We thank everyone who participated and look forward to welcoming you again next year.

The final date is already set: November 7 – 9, 2023

The archives, including all photos, videos and the speakers‘ slides will soon be available at our website. Stay tuned!

 

For all of you who are already curious I have created a slider with lots of impressive, awesome and funny pictures to get an impression of OSMC 2022.

Enjoy!

Chantal Meinl
Chantal Meinl
Junior Account Manager

Chantal absolviert seit September 2022 ihre Ausbildung als Kauffrau im E-Commerce. Zuvor hatte sie uns in diesem Bereich bereits 4 Monate lang als Praktikantin unterstützt. Nach der Arbeit geh sie oft ins Krafttraining und falls es die Zeit erlaubt, zockt oder zeichnet sie noch gerne. Ansonsten verbringt sie gerne Zeit mit ihrem Freund und mit allen Tieren, die sie so finden kann.

NETWAYS stellt sich vor – Jan Schuppik

 

Name: Jan Schuppik

Alter: 28

Ausbildung: Fachinformatikerin für Anwendungsentwicklung

Position bei NETWAYS: Junior Developer

Bei NETWAYS seit: September 2021

 

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

Nachdem ich ein paar Jahre damit verbracht habe, mehrere Studiengänge auszuprobieren und mich in diesem Zuge auch noch selbst zu finden, bin ich letztendlich von der IT überzeugt worden. Als ich dann auf der Suche nach einer Ausbildung als Anwendungsentwickler war, wurde mir von einem Bekannten NETWAYS wärmstens empfohlen und nachdem das Vorstellungsgespräch nicht angenehmer sein hätte können, ist mir die Wahl der Ausbildungsstelle sehr leicht gefallen.

 

Was macht dir an deiner Arbeit am meisten Spaß?

Das ist schwer zu sagen, bisher hab ich noch nichts gefunden, was mir keinen Spaß macht. Die Gestaltung der Ausbildung ist einfach genial, es wird viel Wert darauf gelegt, dass wir eine umfangreiche Grundbildung bekommen. Das Eintauchen in neue, mich interessierende Themen empfinde ich als sehr erfüllend und das in einem so freundschaftlichen Umfeld.

 

Was machst du, wenn du nicht bei NETWAYS bist?

In meiner Freizeit beschäftige ich mich gern mit Musik, egal ob mit hören von Classic Rock bis Metal/-core (gibt wenig was ich gar nicht mag) oder damit selbst eine Klampfe oder Mikro in die Hand zu nehmen. Desweiteren bin ich gern in der Designrichtung unterwegs und Handwerklichen Tätigkeiten bin ich auch nicht abgeneigt.

 

Wie geht es in Zukunft bei dir weiter?

Auf Grund dessen, dass ich vor kurzem die Ausbildung angetreten habe, besteht mein nähere Zukunft daraus, erstmal drei Jahre Ausbildung zu absolvieren (falls ich es nicht schneller schaffe) und dabei herauszufinden welches Themengebiet mich am meisten begeistert. Das nächste Ziel nach der bestandenen Ausbildung ist es bei NETWAYS Berufserfahrung zu sammeln, weiter habe ich bislang nicht geplant.

Jan Schuppik
Jan Schuppik
Junior Developer

Jan wurde von seiner Selbstfindungsphase durch ein paar Studiengänge und eine Nebentätigkeit in der Gastronomie geführt, wodurch er letztendlich in der IT gelandet ist und unterstützt jetzt seit 2022 das Icinga-Team als Auszubildender. In seiner Freizeit beschäftigt er sich am liebsten mit kreativen Tätigkeiten, von Designen und Zeichnen, über Handwerkliches bis hin zur Musik, wozu er auch gern selbst eine Klampfe oder ein Mikro in die Hand nimmt.

Ansible Continuous Deployment without AWX/Tower/AAP

Why Ansible?

Ansible is a configuration management tool to automate tasks in your IT infrastructure. It offers a rather low barrier of entry, when compared to other tools. A local Ansible installation (i.e. on your machine) with SSH access to the infrastructure you want to manage is sufficient for getting started. Meaning, it requires no substantial additions to existing infrastructure (e.g. management servers or agents to install). Ansible also ships with an extensive standard library and has a large selection of modules to extend functionality.

Why Continuous Deployment?

Once a simple Ansible setup is up & running and things start to scale to more contributors, servers or services, it is usually necessary to automate the integration of code changes. By creating one or more central Ansible repositories, we create a single source of truth for our infrastructure. We shift to continuous integration, start testing and verifying changes to the code base.

The next logical step is then to use automate the deployment of this single source of truth, to make sure changes are applied in a timely/consistent manner. Infrastructure code that is not deployed on a regular basis tends to become riskier to deploy each day, since it’s better to discover errors promptly so that they can be traced back to recent code changes; and we all know that people make undocumented hand-crafted changes that are then overwritten and all goes up in flames. Thus we want shorter, more frequent cycles and consistent deployments to avoid our infrastructure code becoming stale and risky.

Why not AWX/Tower/AAP?

AWX (aka. Tower, now Ansible Automation Platform) aims to provide a continuous deployment experience for Ansible. Quote:

Ansible Tower(formerly ‚AWX‘) is a web-based solution that makes Ansible even more easy to use for IT teams of all kinds.

It offers a wide array of features for all your ‚Ansible at scale‘ needs, however it comes with some strings attached. Namely, it involves management overhead for smaller environments as it introduces yet another tool to install, learn, update and manage throughout its life cycle. Not only that but from version 18.0 onward the preferred way to install AWX is the AWX (Kubernetes) Operator. Meaning – preferably – we would need a Kubernetes instance laying around somewhere. Of course, there is always the option to use „unorchestrated“ Containers as an alternative, but that comes with its own obstacles.

Installation and management aside, there is also Red Hat’s upstream first approach to consider. Meaning, AWX is the upstream project of Ansible Tower and thus it might not be as ’stable‘. Furthermore, Red Hat does not recommend AWX for production environments. Quote:

The AWX team currently plans to release new builds approximately every 2 weeks. The AWX team will flag certain builds as “stable” at their discretion. Note that the term “stable” does not imply fitness for production usage or any kind of warranty whatsoever.

Obviously, there are alternatives to AWX/Ansible Tower. Rundeck allows for predefined workflows, these jobs can then be triggered from a Web GUI, API, CLI, or by schedule and works not just with Ansible. Semaphore offers a simple UI for Ansible to manage projects (environments, inventories, repositories, etc.) and includes an API for launching tasks. Puppet aficionados may already know Foreman, which is a great and battle-tested tool for provisioning machines. You can use the „Foreman Remote Execution“ to run your Playbooks and use Ansible callbacks to register new machines in Foreman. Here are some recommended videos on this topic:

– FOSDEM 2020, Foreman meets Ansible: https://www.youtube.com/watch?v=PQYCiJlnpHM
– OSCamp 2019, Ansible automation for Foreman (hosts): https://www.youtube.com/watch?v=Lt0MksAIYuQ

That being said, the premise was to avoid substantially extending any existing infrastructure. Any of the mentioned tools need at least an external database service (e.g. MariaDB, MySQL or PostgreSQL). With that in mind, this article will now describe alternative solutions for continuous deployment without AWX/Ansible Tower. It will show examples using the GitLab CI, however, the presented solutions should be adaptable to various CI/CD solutions.

Ansible Continuous Deployment via the Pipeline

For this article, we will assume a central Ansible Repository on an existing GitLab Server with some GitLab CI Pipeline already in place. Meaning, we might also have some experience with CI jobs in Containers.

Many (if not all) CI/CD solutions feature isolated jobs within Containers, which enables us to quickly spin up predefined execution environments for these jobs (e.g. pre-installed with various tools for testing). Furthermore, it is possible to use specific machines for specific jobs, or place certain machine in different network zones (e.g. a node that triggers something in production environment could be isolated from the rest).

Given this setup we will now explore two scenarios for Ansible Continuous Deployment via pipeline jobs. One based on SSH and the other based on HTTP (Webhooks).

The example Ansible repository follows a standard pattern and is safely stored in a git repository:

git clone git@git.my-example-company.com:ansible/ansible-configuration.git
cd ansible-configuration/

ls -l
ansible.cfg
playbooks/
roles/
inventory/
collections/
site.yml
requirements.yml

SSH

Since the basis for all Ansible deployments is SSH we will leverage this protocol to deploy our code. Fundamentally, there are two options to achieve this:

– Connect from a pipeline job to a central machine with Ansible already installed, download the code changes there and trigger a playbook
– Run an Ansible playbook directly in a pipeline job (i.e. a Container)

For this example we will generate a specific SSH Keypair that is then used in the pipeline. The public key needs to be added to the `authorized_keys` of any machines we want to connect to. Secrets such as the SSH private key can be managed directly in GitLab (CI Variables) or be stored in an external secret management tool (e.g. Hashicorp Vault). Don’t hardcode secrets in the Ansible code base or CI configuration.

# -t keytype (preferably use ed25519 whenever possible)
# -f output file
# -N passphrase
# -C comment

ssh-keygen -t ed25519 -f ansible-deployment -N '' -C 'Ansible-Deployment-Key'

Option A: via an Ansible machine

In this scenario, we connect from a CI job in the pipeline to a machine with Ansible already installed. On this machine we will clone the Ansible configuration and trigger a playbook. This article will refer to this machine as ‚central Ansible node‘, obviously a more complex infrastructure might need more of these machines (i.e. per network zone).

First, we need to copy the previously generated SSH Key onto the central Ansible node, so that we connect from the GitLab CI job. Second, we require a working Ansible setup on this node. Please note, that a detailed installation process will not be explained in this article, since the focus lies on the CI/CD part. We assume that this node has a dedicated user for Ansible is be able to successfully run the Ansible code.

# Copy public key for deployment on the central Ansible node
scp ansible-deployment.pub ansible@central-ansible-node.local
ssh ansible@central-ansible-node.local

# Authorize the public key for outside connections
cat 'ansible-deployment.pub' >> ~/.ssh/authorized_keys

# Install Ansible
pip3 install --user ansible # or ansible==version
# Further setup like inventory creation or dependency installation happens here...

At this point we assume, we can connect to our infrastructure and run Ansible playbooks at our leisure. Next we will create a GitLab CI job which do the following:

  • Retrieve the previously generated SSH private key from our secrets, so that we can connect to the central Ansible node
  • Connect to the central Ansible node and clone the repository there. We will use the GitLab’s CI job tokens for this
  • Create a temporary directory to isolate each pipeline job
  • Run a playbook via SSH on the central Ansible node
---
stages:
- deploy

variables:
CENTRAL_ANSIBLE_NODE: central-ansible-node.local
# Or you can provide a ssh_known_hosts file
ANSIBLE_HOST_KEY_CHECKING=False

deploy-ansible:
image: docker.io/busybox:latest
stage: deploy
before_script:
- mkdir -p ~/.ssh
# SSH_KNOWN_HOSTS is a CI variable to make sure we connect to the correct node
- echo $SSH_KNOWN_HOSTS ~/.ssh/known_hosts
# The SSH private key is a CI variable
- echo $SSH_PRIVATE_KEY > id_ed25519
- chmod 400 id_ed25519
script:
- TMPDIR=$(ssh -i id_ed25519 $CENTRAL_ANSIBLE_NODE "mktemp -d")
- ssh -i id_ed25519 $CENTRAL_ANSIBLE_SERVER "git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@git.my-example-company.com:ansible/ansible-configuration.git $TMPDIR"
- ssh -i id_ed25519 $CENTRAL_ANSIBLE_SERVER "ansible-playbook $TMPDIR/site.yaml"

This basic example can be extended in many ways. For example, CI variables could be used to control which Ansible playbook is executed, change which hosts or tags are included. Furthermore GitLab can also trigger jobs on a schedule. Some of the benefits of this approach are that it is rather easy to set up since it mirrors the local execution workflow, plus the deployment can be debugged and triggered on the central Ansible node.

However, we now have a central Ansible node to manage and we might need several in different network zones. Additionally the `mktemp` solution is a bit hacky and might need a garbage collection job (e.g. `tmpreaper`). The next solution will alleviate some of these issues.

Option B: directly via a Pipeline

In this scenario, Ansible executed directly in the CI pipeline job (i.e. a Container). It is recommended to use a custom pre-build Ansible Container Image, to make the jobs faster and more consistent. This Image may contain a specific Ansible version and further tools required for the given code. The Image can be stored in the GitLab Container Registry. Building and storing Container Images is outside the scope of this article. Here’s a small example of how it might look like:

cat Dockerfile.ansible.example

FROM docker.io/python:3-alpine
RUN pip install --no-cache-dir ansible
# ... Install further tools or infrastructure specifics here
# The image will be stored at registry.my-example-company.com:ansible/ansible-configuration/runner:latest

cat .gitlab-ci.yaml
---
stages:
- deploy

variables:
# Or you can provide a ssh_known_hosts file
ANSIBLE_HOST_KEY_CHECKING=False

deploy-ansible:
image: registry.my-example-company.com:ansible/ansible-configuration/runner:latest
stage: deploy
before_script:
# The SSH private key is a CI variable
- echo $SSH_PRIVATE_KEY > id_ed25519
- chmod 400 id_ed25519
script:
- ansible-playbook --private-key id_ed25519 site.yaml

This removes the need for a central Ansible node and the need for external garbage collection, since these CI jobs are ephemeral by default. That being said, if we have a more complex network setup we might need runners in these zones and a way to control which job is executed where.

HTTP (Webhooks)

In this scenario, we setup another central Ansible node that will run the playbooks, however, there won’t be a SSH connection from the CI job. Instead we will trigger a webhook on this central Ansible node. While this scenario is more complex it offers some benefits when compared to previously discussed options.

Since there are several ways to implement incoming webhooks, we will not view a specific implementation but discuss the concept. Interestingly enough, a webhook-based feature is currently in developer preview to be provided by Ansible. Event-Based-Ansible provides a webhook service that can trigger Playbooks.

In this example we have a service providing webhooks running on central-ansible-node.local on port 8080. This service is configured to run Ansible with various options which we can pass via a HTTP POST request. This request will certain data that controls the Ansible playbook.

cat trigger-site-yaml.json
{
"token": "$WEBHOOK_TOKEN",
"playbook": "site.yaml",
"limit": "staging"
}

cat .gitlab-ci.yaml
---
stages:
- deploy

variables:
CENTRAL_ANSIBLE_NODE: central-ansible-node.local:8080

deploy-ansible:
image: docker.io/alpine:latest
stage: deploy
before_script:
- apk add curl gettext
script:
# Replace the $WEBHOOK_TOKEN placeholder in the file with the real value from the CI variables
- envsubst < trigger-site-yaml.json > trigger-site-yaml.run.json
- curl -X POST -H "Content-Type:application/json" -d @trigger-site-yaml.run.json $CENTRAL_ANSIBLE_NODE

From a security standpoint we remove the need for reachable SSH ports, the central Ansible node now just accepts HTTP (or specific HTTP methods) secured by Tokens. Furthermore there now is a layer between our CI jobs and the Ansible playbooks which can be used to validate requests.

That being said, this extra layer could also be seen as a hurdle that might break. And beside the central Ansible node we now need to manage a service that provides these webhooks. However, in the future Event-Based-Ansible might alleviate some of these issues.

Conclusions

Deploying Ansible is quite flexible due to its simple operational model based on SSH. As we have seen, there are some low-effort alternatives to AWX/Tower that can be applied in various use cases. However, at some point there is a maintainability tradeoff. Meaning, even though AWX/Tower might not appear as stable or is sometimes tricky to operate, once an environment is large enough it might be a better option than custom creations. Probably not a satisfying conclusion for an article named „without AWX/Tower“, I agree.

Foreman presents an interesting alternative due to its myriad of other features that you get with an installation. Finally, Event-Based-Ansible could be very promising webhook-based solution when it comes to automated deployments. Starting simple and then pivoting to a more complex system is always an option.

References

Markus Opolka
Markus Opolka
Consultant

Markus war nach seiner Ausbildung als Fachinformatiker mehrere Jahre als Systemadministrator tätig und hat währenddessen ein Master-Studium Linguistik an der FAU absolviert. Seit 2022 ist er bei NETWAYS als Consultant tätig. Hier kümmert er sich um die Themen Container, Kubernetes, Puppet und Ansible. Privat findet man ihn auf dem Fahrrad, dem Sofa oder auf GitHub.