Select Page

NETWAYS Blog

Kleine Weihnachtspyramide mit Raspberry Pi

Noch einmal schlafen und dann ist Weihnachten. Passend dazu haben wir von NETWAYS ein kleines Experiment zum selber Nachbauen vorbereitet.

Es handelt sich um eine kleine Weihnachtspyramide, die sich mithilfe von Python Code und ein paar Bauteilen ein wenig bewegt und außerdem noch schön leuchtet. Fast wie ein kleiner Weihnachtsbaum für jeden IT-Begeisterten da draußen.

 

Das braucht Ihr

Bevor wir starten, benötigen wir ein paar Dinge. Zum einen brauchen wir einen Raspberry-Pi mit Raspberry-PI OS. Das Modell spielt hierbei keine Rolle. Außerdem werden drei farbige LEDs, ein Steckbrett, ein kleiner Servo-Motor, ein Taster, sowie zehn GPIO-Verbindungskabel benötigt.

 

Und so funktioniert’s

Wie Ihr das Ganze verbinden müsst, seht Ihr in der Abbildung unten:

Ganz wichtig: Ihr müsst in der Raspberry Pi Konfiguration unter Schnittstellen noch den GPIO-Fernzugriff erlauben!

Der Programmcode lässt die Pyramide nach links und rechts drehen und die LEDs leuchten.

“#!/usr/bin/python
import RPi.GPIO as GPIO
import time

LED = [[17, 22, 10],[10, 22, 17]]
x = 0
t1 = 8
servoPIN = 21

GPIO.setmode(GPIO.BCM)
GPIO.setup(t1, GPIO.IN, GPIO.PUD_DOWN)
GPIO.setup(servoPIN, GPIO.OUT)

pwm = 2.5
a = 2.5
p = GPIO.PWM(servoPIN, 50)
p.start(pwm)

for i in LED[0]:
GPIO.setup(i, GPIO.OUT)

try:
while True:
p.ChangeDutyCycle(pwm)
pwm += a
if pwm==12.5 or pwm==2.5:
a = -a
time.sleep(0.2)
p.ChangeDutyCycle(0)
for i in LED[x]:
GPIO.output(i, True)
time.sleep(0.2)
GPIO.output(i, False)
if GPIO.input(t1) == True:
x = 1-x

except KeyboardInterrupt:
p.stop()
GPIO.cleanup()”

 

Wie Ihr Eure Pyramide, die auf den Servomotor gesetzt wird, gestaltet, ist Euch selbst überlassen.

Wie das ganze aussehen könnte, seht Ihr hier:

Viel Spaß beim Ausprobieren und fröhliche Weihnachten!

Wenn Ihr wissen wollt, wie wir bei NETWAYS unsere Weihachtsfeier gefeiert haben, lest Euch doch unseren Blogpost zur Weihnachtsfeier durch.

Christoph Breit
Christoph Breit
Junior Consultant

Christoph ist seit Juli 2022 Teil der NETWAYS Professional Services Abteilung. Er absolvierte hier zunächst ein Praktikum und unterstützt sein Team ab September als auszubildender Fachinformatiker für Systemintegration. In seiner Freizeit bereist er gerne die Welt, ist als Basketballer sportlich unterwegs und sitzt auch mal gerne sowohl beim Zocken als auch beim Graphic- & Motion-Designen vorm PC.

Alle Jahre wieder, kommt der Advent of Code

…zumindest seit 2015. Bereits zum achten Mal haben Rätsel- und Programmierfreunde rund um die Welt in der Nacht vom 30. November auf den 1. Dezember dieses Jahr gebannt auf die Veröffentlichung des ersten Rätsels gewartet. Ihr habt davon noch nie gehört und wollt mehr über diesen kniffeligen Adventskalender wissen? Dann seid ihr hier und heute genau an der richtigen Stelle!

Advent of Was?

Der Advent of Code ist ein 25-tägiger Rätselspaß, der jährlich vom 1. Dezember bis einschließlich 25. Dezember stattfindet und einen täglich vor zwei neue Herausforderungen stellt, die es zu lösen gilt. Die Rätsel sind hierbei in eine weihnachtliche Rahmenhandlung eingebaut, sodass man durch den Advent hindurch beim Knobeln nebenbei noch eine Geschichte erzählt bekommt. Löst man jeden Tag beide Aufgaben, erhält man in Summe 50 Sterne. Außerdem schaltet man durch seine Lösungen nach und nach auf der Website ein Bild im ASCII-Stil frei und hat also zusätzlich so etwas wie einen klassischen Adventskalender, der als Motivation herhalten kann.

Ist man bei der Bearbeitung auch noch besonders schnell, kann man es auf die globale Rangliste schaffen und den Advent hindurch Punkte sammeln, was aber quasi ein Ding der Unmöglichkeit ist. Private Ranglisten, bspw. mit KollegInnen oder im Freundeskreis, sind hier die weniger frustrierende Alternative.

Mein tagesaktueller Adventskalender auf der Advent of Code Website

Mein aktueller Adventskalender auf der Advent of Code Website. Wie das Bild wohl in 17 Tagen aussehen wird?

Das Handwerkszeug

Wie genau man die Rätsel löst, bleibt jedem selbst überlassen. Die naheliegendste Lösung ist es, programmatische Ansätze in beliebigen, mehr oder weniger gängigen Programmiersprachen zu finden – es gibt jedoch auch glühende Anhänger von Tabellenkalkulationsprogrammen, die ihre täglichen Lösungen als Excel-Datei oder Google-Sheet veröffentlichen. Auch auf Papier, mittels Minecraft-Schaltungen oder in Factorio-Fabriken wurden bereits des Öfteren Lösungen gefunden.

Alle Rätsel vereint, dass es einen pro Teilnehmer individuellen ”Rätselinput” in Textform gibt, aus dem sich eine eindeutige Lösung extrahieren lässt – meist eine Zahlen- oder Buchstabenkombination oder das Ergebnis einer Berechnung. Zusätzlich gibt es immer zumindest 2-3 Beispiele, wie die Lösungen für hypothetische Eingaben aussehen würden, sodass man sich nicht zu 100% auf seine Fertigkeiten, ellenlange Textaufgaben lesen zu können, verlassen muss.

Zeit für etwas Neues

Viele Teilnehmer nutzen die sehr offen gestellten Aufgaben, um eine neue Programmiersprache auszuprobieren oder bestehende Kenntnisse zu vertiefen – so nutze ich die Gelegenheit bspw., um endlich einmal etwas nachhaltiger in Go reinzuschauen, anstatt einmal im Quartal ein paar Zeilen Code “zu verbrechen”. Auch einige unserer Azubis haben den Advent of Code für sich entdeckt und machen momentan ihre ersten Schritte in PHP, und wieder andere KollegInnen geben exotischen Sprachen eine Chance, von denen ich zuvor noch nie gehört habe. Aber auch wenn man keine Lust hat, von Grund auf etwas Neues zu lernen oder auszuprobieren, bietet der Advent of Code eine gute Möglichkeit zum winterlichen Gehirnjogging, bevor es abends auf den Weihnachtsmarkt geht.

Wenn es eucht jetzt direkt in den Fingern juckt und ihr im Hintergrund bereits den Texteditor eurer Wahl gestartet habt, entlasse ich euch an dieser Stelle in den Advent. Aber auch ansonsten kann ich nur sagen: Probiert’s doch mal aus!

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Ansible – Testing roles with Molecule

Ansible is a widely used and a 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.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

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
Manager Consulting

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.

NETWAYS Support Collector Roadmap

Den Support Collector konnte ich bereits in meinem letzten Blogpost vorstellen. Für alle die den Beitrag verpasst haben, hier kurz umrissen was es ist:
Bei dem Tool handelt es sich um einen von uns geschriebenen Datensammler, welche alle möglichen Support relevanten Daten von einem System sammelt und als ZIP verpackt. Das ZIP kann in Support Fällen an uns geschickt werden, damit wir uns einen Überblick über das System machen können.

Letzte Woche konnte mit Verzögerungen die Version 0.7.0 veröffentlich werden, welche nun auch Daten über die IcingaDB und Redis sammelt. Von Versionen bis hin zur Konfiguration und Service Status wird alles mit gesammelt.

Im Rahmen dieses Blogposts möchte ich euch einen kleinen Ausblick geben, welche möglichen Erweiterungen wir mit dem Support Collector noch abbilden möchten.

Systemweiter Datensammler

Zum aktuellen Stand sammelt der Support Collector Daten ein, speichert sie in eine Datei und verpackt dass alles zu einem großem ZIP. Das ganze passiert aber nur auf dem System auf welchen das Tool ausgeführt wird. Jetzt stehen wir natürlich vor dem “Problem” dass Icinga 2 Umgebungen über mehrere Systeme verteilt sein können. So kann es sein dass einfach nur die Datenbank auf einem anderen Host läuft oder dass sich irgendwo noch ein zweiter Master bzw. Satelliten befindet. Aus Sicht des Supports wäre es natürlich schön auch diese Daten mit abzufragen.
Die Umsetzung des eben beschriebenen Vorhabens ist noch nicht ganz klar, da es hier neben vielen Kleinigkeiten vor allem die Security zu beachten gilt. Da wir uns auch vorstellen können, dass nicht ein jeder es gut findet, wenn wir komplette Systeme scannen, wird diese Funktion auch nur optional. Unser Augenmerk liegt darauf, dass der Benutzer frei entscheiden kann, was er gesammelt haben möchte.

Statistiken

Mit den gesammelten Daten lassen Sich natürlich auch aussagekräftige Statistiken erstellen. Anhand von diesen Daten könnten wir von den einfachsten Statistiken wie “Welche Versionen werden wie oft genutzt”, bis hin zu komplexen Themen wie “Durchschnittliche Größe eines Systems” oder “Welche Hardware Specs für welche Icinga 2 Größe” erstellen. Allerdings ist auch hier noch nicht zu eindeutig wie die Umsetzung aussehen soll, da hier ebenfalls die Security und Anonymität eine große und wichtige Rolle spielen.

Mit den zwei Punkten welche ich hier angesprochen habe, konnte ich euch nur einen kleinen Einblick gegeben, was an Feature Ideen noch in Planung sind. Sollte euch etwas einfallen, was aus eurer Sicht sinnvoll wäre umzusetzen, könnt ihr gerne ein Feature Request im Git Repository eröffnen.

Tobias Bauriedel
Tobias Bauriedel
Assistant Manager Operations

Tobias ist ein offener und gelassener Mensch, dem vor allem der Spaß an der Arbeit wichtig ist. Bei uns hat er seine Ausbildung zum Fachinformatiker für Systemintegration abgeschlossen und arbeitet nun im NETWAYS Professional Services - Team Operations und entwickelt nebenbei Projekte für die NPS. In seiner Freizeit engagiert er sich ehrenamtlich aktiv bei der Freiwilligen Feuerwehr als Atemschutzgerätetrager und Maschinist, bereist die Welt und unternimmt gerne etwas mit Freunden.

Python – Generator

Wer schon einmal eine etwas größere Datei, bspw. 1Gb, mit dem Editor VIM geöffnet hat, der weis, wie lange dies dauern kann. Das kommt daher, dass diese Datei zunächst komplett in den Arbeitsspeicher geladen werden muss. So ähnlich verhält es sich, wenn in Python eine Variable “befüllt” wird, welche anschließend Speicherplatz im Arbeitsspeicher belegt. Bei der heutigen Hardware stellen 1 Gb große Variablen kein Problem dar, aber was passiert wenn diese deutlich größer sind und zusätzlich eine gute Performance benötigt wird? In diesem Fall empfiehlt es sich, auf einen Generator zurückzugreifen. Ein Generator liefert lapidar gesagt die Ergebnisse einer Funktion “häppchenweise” und nicht als riesiges Stück zurück. Syntaktisch unterscheidet sich ein Generator von einer “normalen” Funktion nicht großartig, wie hier zu sehen:

def a_function():
  yield x
  yield y
  yield z

Bei der Funktionsdefinition wird lediglich das Schlüsselwort return durch yield ersetzt. Der große Unterschied zu einer “normalen” Funktion dabei ist, dass sich die Funktion mit yield nicht sofort beendet. Somit erhält man, vereinfacht gesagt, ein Objekt (Iterator) als Rückgabewert, über das man iterieren kann.

Zur besseren Veranschaulichung eines Generators werde ich eine exemplarische Datenbankabfrage aufzeigen:

Hinweis: Ich habe eine Beispieldatenbank genommen.

“normale” Funktion
SELECT-Statement und anschließende Rückgabe des gesamten Ergebnisses:

def select_list():
    result = []

    db = mysql.connector.connect(host='127.0.0.1',
                                 user='thomas',
                                 password="4nD3r5on",
                                 db='employees')

    cursor = db.cursor()

    cursor.execute('select * from employees')

    for row in cursor:
        result.append(row)

    return result

Die Funktion “select_list()” liefert eine Liste zurück:

print(select_list())

[...]
(10016,'1961-05-02','Kazuhito','Cappelletti','M','1995-01-27'),
(10017,'1958-07-06','Cristinel','Bouloucos','F','1993-08-03'),
(10018,'1954-06-19','Kazuhide','Peha','F','1987-04-03'),
[...]

“generator” Funktion
Im Gegensatz zum obigen Beispiel wird keine Liste mit den Werten befüllt, sondern jeder Wert einzeln durch yield zurückgegeben:

def select_generator():
    db = mysql.connector.connect(host='127.0.0.1',
                                 user='thomas',
                                 password="4nD3r5on",
                                 db='employees')

    cursor = db.cursor()

    cursor.execute('select * from employees')

    for row in cursor.fetchmany(1000):
        yield row

Die Funktion “select_generator()” liefert keine Liste zurück, sondern einen Generator:

print(select_generator())

<generator object select_generator at 0x10ba165d0>

Durch anschließendes Iterieren des Generatorsobjektes werden die gewünschten Werte ausgegeben:

for row in select_generator():
        print(row)

[...]
(10016,'1961-05-02','Kazuhito','Cappelletti','M','1995-01-27'),
(10017,'1958-07-06','Cristinel','Bouloucos','F','1993-08-03'),
(10018,'1954-06-19','Kazuhide','Peha','F','1987-04-03'),
[...]

Wo liegt nun der Vorteil eines Generators? Das zeigt sich erst bei Benchmark-Tests, welche im folgenden Beispiel die Performance der jeweiligen Funktion aufzeigt. Die SELECT-Statements sind bei beiden Beispielen dieselbigen, werden aber nicht ausgegeben, es wird nur eine Variable initialisiert:
select_list()

print('Memory (Before): {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))
    
t1_start = perf_counter()
test_list = select_list()
t1_stop = perf_counter()
    
print('Memory (After) : {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

print("Elapsed time: {0} seconds".format(t1_stop-t1_start))

select_generator()

print('Memory (Before): {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

t1_start = perf_counter()
test_generator = select_generator()
t1_stop = perf_counter()

print('Memory (After) : {} Mb'.format(
    psutil.Process(os.getpid()).memory_info().rss / 1000000))

print("Elapsed time: {0} seconds".format(t1_stop-t1_start))

select_list():

Memory (Before): 11.776 Mb
Memory (After) : 124.960768 Mb
Elapsed time: 8.311030800000001 seconds

 

select_generator():

Memory (Before): 11.698176 Mb
Memory (After) : 11.718656 Mb
Elapsed time: 4.869999999934649e-07 seconds

Die Zahlen sprechen für sich. Beim Generator bleibt der Verbrauch des Arbeitsspeichers so gut wie unverändert, da dieser beim Ausführen des Codes nicht “alle Werte speichert”, sondern jeden einzelnen Wert ab dem Schlüsselwort yield zurückgibt. Dadurch ergibt sich auch die immense Geschwindigkeit.
An dieser Stelle ist noch zu erwähnen, dass alle Vorteile eines Generators verloren gehen, wenn man diesen in ein Liste umwandelt.

Quelle: https://media.giphy.com/media/yUrUb9fYz6x7a/giphy.gif

Philipp Dorschner
Philipp Dorschner
Technical Service Manager

Nach seiner Ausbildung zum Fachinformatiker bei der NETWAYS Professional Services GmbH wuchs das Interesse an Development und organisatorischen Themen. Heute unterstützt Philipp die Kollegen aus PS-Services als hybrider Mitarbeiter. Fünfzig Prozent seiner Zeit als Technical Service Manager und die anderen fünfzig Prozent als interner Entwickler. Als Ausgleich zu seiner Arbeit im Büro verbringt er seine Freizeit meistens beim Sport oder trifft sich mit Freunden.