DevOps im Startup

In agilen Umgebungen wie Startups sind starre Trennungen von Softwareentwicklung und IT Operations eher selten anzutreffen. Doch auch viele große Unternehmen wechseln immer öfter auf agile Prozesse und einem dazu passenden IT Umfeld. DevOps ermöglicht die Vernetzung der klassischen Silos. Durch die Einführung intelligenter und automatisierter Prozesse lässt sich die Auslieferung der Software und dessen Qualität erheblich steigern.

Die gängigen DevOps Prozesse und Tools decken die Bereiche Planung, Entwicklung, Build, Test, Release, Deployment, Operations und Monitoring ab. Welche Prozesse dabei automatisiert werden sollen und zu welchem Zeitpunkt hängt maßgeblich vom Reifegrad des Unternehmens und der verfügbaren Zeit ab. Dabei muss die DevOps Umgebung am Anfang nicht so perfekt optimiert sein wie bei Netflix deren Automatiserungsgrad einzigartig ist. Für die Einführung der Tools und Prozesse muss Zeit aufgewendet werden welche dann in der Entwicklung fehlt. Gerade bei Startups die noch ihr MVP (Minimum Viable Product) am Markt erproben wäre eine vollständige Automatisierung noch verfrüht. Dennoch hilft eine frühzeitige Einführung auch hier die Produktivität und Qualität zu erhöhen. Exemplarisch möchte ich die Umsetzung meines letzten Stacks für ein schnell wachsendes Startup Unternehmen beschreiben.

Ausgangslage und Anforderungen

Das MVP ist am Markt erprobt und das Team hat bereits einige Entwickler an Board. Die primären Anforderungen sind somit die Qualität der Software erhöhen, idealerweise durch Testautomatisierung und Code-Quality-Standards. Neue Features müssen jederzeit und von jedem Mitarbeiter getestet werden können bevor diese in die Produktionsumgebung kommen. Somit müssen mehrere Testumgebungen verfügbar sein. Im Hinblick auf weitere neue Entwickler sollen diese schnell produktiv sein. Außerdem müssen alle Umgebungen zur Nachstellung von Problemen gleichartig aufgesetzt und konfiguriert sein.

A fool with a tool is still a fool.

Ein weiteres wichtiges Kriterium ist eine einfache Wartbarkeit und Administration. Probleme und Anforderungen sollen nicht mit einem Zoo aus tausend Tools erschlagen werden. Dabei ist eine wichtige Frage welche Programme selber gehostet werden sollen und wo ein Zukauf bzw. ein SaaS Modell sinnvoll ist. Natürlich gilt es den Datenschutz bei letzterem zu wahren. Selber administrierte Tools müssen immer auf dem aktuellsten Softwarestand und mit sicheren Konfigurationen bestückt sein.

Tools

Ansible

Eines der zwei zentralen Tools ist hier Ansible geworden. In den sogenannten Playbooks und den Konfigurationsdateien lässt sich die gesamte Umgebung definieren. Ansible verfolgt dabei den Ansatz, dass der Endzustand beschrieben wird. Die Definition für den Applikationsserver sieht dann also beispielsweise wie folgt aus.

  • [AppServer]
    • Server1
    • Server2
  • [AppServer Installation]
    • nginx: installiert
    • PM2: gestartet
    • DatendankVerbindung: DbServerCluster

Ich nutze Ansible sogar um die Server direkt bei dem Cloud Anbieter aufzusetzen. Somit gibt es zwei Ansible Projekte. Ein Projekt um die gesamte Serverumgebung inkl. Datenbankservern, VPNs, Firewall Regeln, SSH-Keys und Object Storages zu verwalten und ein zweites Projekt welches dann für jeden Server die Software und deren Konfiguration beschreibt. Durch die einfache Konfiguration können somit innerhalb weniger Minuten beliebig viele gleichartige Integrations-/Testumgebungen aufgebaut werden. Alle Umgebungen werden außerdem automatisch in die Monitoring- (Icinga/Nagios) und Loggingumgebung (Graylog 2) eingebunden. Ich habe mich bewusst gegen Datadog und ähnliche SaaS Dienste entschieden weil die Administration und Konfiguration von Tools wie Graylog, Icinga, Elasticsearch und vielen mehr mit Ansible ein Kinderspiel ist. Wichtig sind hier nur zuverlässige und sichere Konfigurationsdefinitionen und sauber abgetrennte Netzwerkbereiche und Firewall Regeln.

Jenkins

Die zweite Zentrale Software ist Jenkins. Dieser löst Deploybot ab um mehr Kontrolle über den gesamten Release Prozess zu haben. Jenkins kümmert sich um mehrere Teile. Zum einen prüft er sämtliche Check-Ins die auf GitHub getätigt werden. Dies umfasst die Prüfung der Code Qualität (Linting, SonarQube, …). Zum anderen führt Jenkins Unit Tests durch, startet die API Tests mit postman bzw. newman und führt die User Acceptance Tests von Selenium aus. Abhängig von den gewählten Branches automatisiert Jenkins auch das Deployment. Sämtliche commits auf den develop branch führen zu einem Deployment auf die Integrationsumgebung. Alle master commits müssen von mindestens zwei Entwicklern und Jenkins selber geprüft werden und führen dann zu einem Deployment auf die Produktionsumegbung.

Jeder Entwickler hat darüber hinaus jederzeit die Möglichkeit beliebige Branches auf Testumgebungen zu deployen. Dabei kann außerdem festgelegt werden welche Testdaten initial in den Datenbankservern zur Verfügung gestellt werden. Die Testumgebungen werden darüber hinaus in gesonderten virtuellen Netzwerken aufgebaut.

Produktion als lokale Entwicklunsumgebung

Ansible funktioniert auch mit Vagrant. Sämtliche Konfigurationen die für die Serverumgebungen definiert sind funktionieren somit auch lokal. Jeder Entwickler hat daher eine Umgebung deren Softwarestände und Konfiguration 1:1 mit der Produktion übereinstimmen. Lediglich die Datenbank ist in den Entwicklungsumgebung lokal anstelle von dedizierten Servern. Die lokalen Umgebungen können jederzeit auf Knopfdruck neu erstellt werden und erhalten direkt Testdaten. Neue Mitarbeiter lassen sich somit innerhalb von ca. 30 Minuten arbeitsfähig einbinden!

Zusammenfassung

Durch die Automatisierung des Aufbaus der lokalen Entwicklungsumgebung bis hin zur vollständigen Serverumgebung und der Automatisierung der Deployments findet jeder Entwickler jederzeit gleichartige Umgebungen vor. Fehler können lokal nachgestellt werden und notwenige Konfigurationsänderungen werden versioniert und auditiert zentral verwaltet. Jeder Entwickler kann jederzeit Änderungen von Code und Infrastruktur nachvollziehen und überprüfen.

 

Bildquelle: pixabay.com

Hugo Shortcodes und Best Practices

Der statische Webseiten Generator Hugo ermöglicht schnelle und sichere Webseiten allerdings sind ein paar Fallstricke zu beachten. Ich habe meine Best Practices und nützliche Shortcodes in zwei Git Repositories zur Verfügung gestellt.

Hugo Best Practices

Das hugo-best-practices Repository beinhaltet eine Übersicht und viele Hilfen für den Umgang mit Hugo. Die Themen umfassen Verzeichnisstrukturen, Asset Optimierung und wichtige Tipps für Deployments, SEO und Performance. Alle Dokumente sind in englische Sprache erstellt damit die Community sich daran beteiligen kann.

Shortcodes

In dem hugo-shortcodes Repository gibt es eine Sammlung von nützlichen Funktionen für Hugo. Dies umfasst beispielsweise <figure> Blöcke mit automatischer Bildoptimierung.

Stackshare

Für meine Seite gibt es auch eine Übersicht der genutzten Tools auf stackshare.

 

Bildquelle: pixabay.com

WordPress zu Hugo

Etwas mehr als 1,5 Jahre ist es her, dass ich einen großen Teil meiner Webseiten zu WordPress migrierte. Jetzt sind sechs meiner Webseite mit Hugo erstellt. Dafür gibt es einige Gründe und auch ein paar Hindernisse.

Hugo

Zuerst ein kurzer Exkurs über Hugo. Hierbei handelt es sich um einen statischen Webseiten Generator welcher in der Programmiersprache Go geschrieben ist. Im Gegensatz zu WordPress liegen alle Daten und Inhalte in lokalen Dateien und nicht in einer Datenbank. Die Webseite wird vollständig aus diesen Daten generiert. Daraus ergeben sich direkt ein paar Vorteile. In der Ladezeit der Webseite fallen Datenbankabfragen und das Generieren der Inhalte raus. Statische Webseiten sind damit prinzipiell um Längen schneller als dynamisch generierte Webseiten. Außerdem sind statische Webseiten prinzipbedingt sicherer. Schadcode lässt sich nicht einfach über Sicherheitslücken in dem CMS System einschleusen. Ein großer Nachteil liegt aber darin, dass dynamische Inhalte schwieriger umzusetzen sind.

Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again. (Hugo Webseite)

Die Pro Seite

Wie oben beschrieben sind die Webseiten initial meistens extrem schnell und durch optimiertes Assetmanagemet nochmal deutlich schneller. Lediglich ein Theme in meinen Tests nutze ein externen und langsames CDN um viele Javascript Dateien nachzuladen.

Durch das Generieren der Webseiten bin ich nun komplett unabhängig von dem schnelllebigen PHP und der MySQL Datenbank. Die Inhalte werden nur bei neuen Beiträgen lokal neu generiert und dann hochgeladen (bzw. in Zukunft über meinen Buildserver).

Alle Inhalte kann ich in schlanken und übersichtlichen Markdown Dateien pflegen. Die relevanten Bilder für die Beiträge liegen im selben Ordner. Jedes Bild ist mit seiner maximalen Auflösung gespeichert. Shortcodes generieren die benötigten Größen beim Bauen. Dadurch muss nur eine Datei pro Projekt vorhanden sein. Die perfekte Auflösung ist bei einem Wechsel des Themes somit auch sicher (sofern das Original groß genug war…).

Jede Webseite kann als Ganzes Projekt bei GitHub, Bitbucket oder jedem anderen Versionsverwaltungssystem versioniert werden. Es gibt somit automatisch eine Historie. Bei vielen Providern können die Markdown Dateien auch direkt auf der Webseite betrachtet werden. Theoretisch lassen sich die Inhalte auch im GitHub Editor bearbeiten. Einige Projekte nutzen dies um die Dokumentation ihrer Software einfach zu ermöglichen.

Ich muss mich nicht mehr mit ständig aktualisierten WordPress Plugins und deren Hinweisen auf neue Pro Versionen herumärgern. Daten über meine Webseite laden nun auch nicht mehr bei fremden Anbietern. Durch die fehlenden Plugins (bzw. deren native Einbindung in Hugo) ist der Footprint trotz der vielen WordPress Optimierungen deutlich kleiner. Javascript Dateien von 24 auf 1 und CSS Dateien von 15 auf 4 auf einer meiner Webseiten.

Was gegen Hugo spricht

Hugo ist meiner Meinung nach nur für Nutzer welche sich mit Dateien, Kommandozeile, Versionsverwaltungssoftware und HTML wohl fühlen. Natürlich kann eine minimale Seite mit einem Standardtheme erstellt werden aber dann ist an Anpassungen nicht zu denken.

Viele Themes bei Hugo sind leider etwas älter. Also sie wurden erstellt vor den 0.3*/0.4 Versionen. Dadurch sind Features wie Assets Bundles und Minification nicht vorhanden. Ich musste bei JEDEM Theme selber Hand anlegen. Einige Themes hatten die Verkleinerung von Bildern nicht dabei. Bei anderen Themes fehlten grundlegende SEO Funktionen. Oft waren die CSS Dateien nicht minifiziert oder es wurden mehrere Dateien eingebunden. Ein Bundling ist bei neuen Hugo Versionen Standard. Das Theme muss dies aber berücksichtigen.

Fazit

Für technisch Interessierte oder Webmaster die optimale Webseiten bauen möchten ist Hugo eine spannende Wahl. Bei PageSpeed Insights von Google Developers sind hohe Punktzahlen quasi garantiert. Mit der Hilfe von bundling und minification in den neuen Versionen gibt es diese Features ohne npm, grunt, webpack oder andere Tools jetzt geschenkt. Die Toolchain beschränkt sich somit auf Hugo und gegenbenenfalls Cotinous Deployment Software wie Jenkins oder Deploybot.

WordPress ist für einen großen Teil der Seitenbetreiber natürlich weiterhin eine gute Wahl. Allerdings sollte man sich der Schwächen bewusst sein. Eine einfache Landing Page braucht kein komplettes CMS und jeder Plugin erhöht den Overhead und die Angriffsfläche eines CMS!

DevOps Phasen

Als Vorbereitung für eine Reihe über DevOps Prozesse und Tools habe ich mich mit den unterschiedlichen DevOps Modellen auseinandergesetzt. Daraus ist eine Zusammenfassung der Hauptkategorien und Unterkategorien entstanden. Als Quelle dienten diverse Hersteller und Webseiten. Die Tabelle enthält die gängigsten Modelle.

MilindTechWikipediaBlazeMeterBlazeMeter
PlanPlanCollaborateApplication lifecycle Management
Communication & ChatOps
Knowledge Sharing
CodeCreateBuildSCM / VCS
CI
BuildBuild
Database Management
TestVerifyTestTesting
Package
ReleaseRelease
DeployDeployDeployment
Configuration Management / Provisioning
Artefact Management
OperateConfigureRunCloud / IaaS / PaaS
Orchestration & Scheduling
Bi / Monitoring / Logging
MonitorMonitor

Quellen:

Bildnachweis: Wikipedia – DevOps – toolchain

Sensornetzwerke mit MySensors und pimatic

Wird pimatic (oder FHEM) für die Haussteuerung mit dem Raspberry Pi eingesetzt ergibt sich oft das Problem, dass die Sensoren nicht in direkter Nähe zum Raspberry Pi stehen. Möchte man beispielsweise in der Küche, im Badezimmer und im Schlafzimmer die Temperatur erfassen um damit Heizungen zu steuern sind verteilte Sensoren notwendig. Diese lassen sich mit Hilfe des MySensors Projektes einfach bauen.

MySensors

Bei MySensors handelt es sich um ein Opensource Framework für die Erstellung von IoT (Internet of Things) Anwendungen über Funkstrecken. Das MySensors Projekt stellt Software und Quellcode für viele Anwendungsszenarien zur Verfügung. Die Systeme sind dabei so erstellt, dass die Funkmodule alle Nachrichten in einem Mesh-Netzwerk weiter verteilen. Dadurch ist eine hohe Reichweite möglich.

Grundlegend gibt es in dem Netzwerk Nodes. Dabei ist zwischen Sensor- und Gateway-Nodes zu unterscheiden. Die Gateway-Nodes empfangen Daten und geben diese mittels Seriellem Protokoll oder über W-LAN an ein Steuersystem (Controller) weiter. In unserem Fall wird dies pimatic übernehmen. Die Sensor-Nodes sammeln die Daten der angeschlossenen Sensoren und schicken diese mittels Funkchip an ein Gateway. Die Sensor-Nodes sind dabei Arduinos (Nano, Micro oder selten Uno). Das Gateway ist entweder ein ESP8266 oder in diesem Artikel der Raspberry Pi (entweder mit pimatic Installation oder als eigenes System). Funkchips sind hierbei nRF24L01+ oder RFM69 Module. Beide sind jedoch nicht untereinander kompatibel! Die nRF24L01+ sind einfacher zu konfigurieren und preiswerter. Die RFM69 dementsprechend teurer und aufwändiger zu konfigurieren jedoch auch robuster und mit besserer Reichweite.

In diesem Artikel brauchen wir folgendes.

ACHTUNG: Im Standard ist die Kommunikation unverschlüsselt. Kritische Sensoren und Aktoren sollten daher nicht über die unverschlüsselte Standardkonfiguration laufen.

Raspberry Pi Gateway einrichten

Der Raspberry Pi muss mit dem Funkmodul verbunden werden. Hier gibt es eine ganze Menge an Kombinationsmöglichkeiten, einen Raspberry Pi 1, B, B+, 2, 3, … mit den diversen Modulen. Abhilfe schafft die Wiring Liste von MySensors.

Sind alle Kabel an der richtigen Stelle geht es an die Einrichtung der Software. In der aktuellen Lösung kann der hier beschriebene Code genutzt werden um einen virtuellen seriellen Gateway zu erstellen.

ALTERNATIVE: Sind bereits viele der GPIO Ports belegt oder soll eine eigene Lösung für MySensors gebaut werden dann kann ein Serial Gateway mit einem weiteren Arduino aufgebaut werden. Die Verkabelung erfolgt wie unten bei dem Arduino beschrieben. Danach ist dieser mit dem Code von der MySensors Serial Gateway Seite zu bestücken und mit dem Raspberry Pi über USB zu verbinden.

Arduino und Sensor vorbereiten

Als erstes muss der Arduino mit dem Funkmodul verbunden werden. Hierzu gibt es die Skizze auf der MySensors Seite unter NRF24L01+ & Arduino. Bei dem gewählten Arduino ist zu beachten, dass die reinen 5V Arduinos unbedingt einen Regulator auf 3.3V benötigen damit das Funkmodul nicht gebraten wird! Bei dem Arduino Nano sind 3.3V Ausgänge vorhanden, der Uno hat diese ebenfalls.

Sobald der Arduino angeschlossen ist erfolgt der Anschluss eines Sensors. Der einfach DS18B20 Temperatursensor ist unter den Beispielen auf der Webseite gelistet. Der Anschluss des kombinierten DHT22 ist jedoch auch sehr einfach. Die Skizze dazu findet sich unter dem Eintrag Air Humidity Sensor. Dort ist ebenfalls ein Arduino Sketch abgelegt mit dem das Netzwerk und der Sensor aktiviert werden.

Prüfen

Sind beide Arduinos bzw. die Kombination Arduino und Raspberry Pi eingerichtet sollte der Sensor Arduino an den PC angeschlossen werden. Über den „Serial Monitor“ der Arduino Entwicklungsumgebung können die Ausgaben überprüft werden. Da ggf. noch kein Controller angeschlossen ist (pimatic) erhält der Arduino noch keine eindeutige ID. Abhilfe schafft die folgende Definition am Anfang des DHT22 Programms.

#define MY_NODE_ID 14

Hiermit erhält der Arduino testweise die ID 14. Diese ist dann auch im Output zu erkennen. Der Output sollte ungefähr wie folgt sein.

[...]
4186 MCO:BGN:INIT OK,TSP=1
4202 TSF:MSG:SEND,14-14-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:23.9
T: 23.90
4210 TSF:MSG:SEND,14-14-0-0,s=0,c=1,t=1,pt=7,l=5,sg=0,ft=0,st=OK:47.4
H: 47.40
4217 MCO:SLP:MS=60000,SMS=0,I1=255,M1=255,I2=255,M2=255

Wenn das Gateway ebenfalls ein Arduino ist ergibt sich im „Serial Monitor“ der folgende Output.

0;255;3;0;9;TSF:MSG:READ,14-14-0,s=255,c=3,t=26,pt=1,l=1,sg=0:2
0;255;3;0;9;TSF:MSG:SEND,0-0-14-14,s=255,c=3,t=27,pt=1,l=1,sg=0,ft=0,st=OK:1
0;255;3;0;9;TSF:MSG:READ,14-14-0,s=1,c=1,t=0,pt=7,l=5,sg=0:23.9
14;1;1;0;0;23.9
0;255;3;0;9;TSF:MSG:READ,14-14-0,s=0,c=1,t=1,pt=7,l=5,sg=0:47.5
14;0;1;0;1;47.5

Sensor in pimatic einbinden

Die Einbindung in pimatic erfolgt mit dem Plugin „pimatic-plugin-mySensors“.

Probleme

Ich konnte die Verbindung nur zwischen zwei Arduino Uno Varianten herstellen. Mit einem geklonten Mini war leider keine saubere Kommunikation möglich. Bei einem Original sollten hier aber keine Probleme auftreten.