Past Meetup

Infrastruktur-Tests­­ mit Jenkingsfile & IaC mit Azure Resource Manager

This Meetup is past

11 people went

Microsoft

Holzmarkt 2 · Köln

How to find us

Microsoft Köln, Holzmarkt 2 50676 Köln Raum: SC 2

Location image of event venue

Details

Hallo Cloud-Natives,

bei unserem nächsten Meetup am 26. April werden Christopher und Julia uns mit den Themen Infrastruktur Tests mit Jenkingsfile für unsere DevOps Entwicklungsprozesse und Infrastructure as Code mit ARM auf Microsoft Azure Cloud bereichern.

Timeline:

18:00 - 19:00 Networking
19:00 - 20:00 IaC mit ARM
20:00 - 20:30 Pizza und Bier
20:30 - 21:30 Infrastruktur-Test mit Jenkinsfile
21:30 - 22:00 Diskussion und Ausklang

Abstract von Julia's & Christopher's Vorträge:

Infrastructure as Code with Azure Resource Manager (Julia Jauß, Microsoft Deutschland).

Das Microsoft Azure Portal ist ein idealer Einstieg, um sich mit den Möglichkeiten in der Azure Cloud vertraut zu machen und um Dinge auszuprobieren. Wenn die „Spielphase“ vorüber ist und eine komplexere Infrastruktur mit vielen Komponenten (wie virtuelle Computer, Speicher, virtuelles Netzwerk und Drittanbieterdienste) auf Azure provisioniert werden soll, sind automatisierte Deployments unumgänglich. Julia zeigt die zahlreiche Vorteile und Wege auf, wie man mithilfe von Infrastruktur als Code (ARM Templates) verschiedene Cloud-Dienste als Gruppe (wiederholt) bereitstellen und verwalten kann.

Infrastrutkur-Tests mit Jenkingsfile (Christopher J. Ruwe)

IT-Infrastruktur wird mittlerweile durch Konfigurations-Management-Systeme wie Puppet oder Ansible installiert und konfiguriert. Ist Infrastruktur durch Code beschrieben und wird Infrastruktur automatisch durch Code generiert und konfiguriert, spricht man von Infrastructure as Code.

Im dazugehörigen Entwicklungsprozess (DevOps!) findet man neben Code-Repositories Unit- und Integrations-Tests und Continuous Integration Systeme.

Ziel solcher CI-Systeme ist es, einen hohen Automatisierungsgrad zuerst für die Test-Prozeduren des Codes (Continuous Integration) bereitzustellen. In nachfolgender Ausbaustufe hat man das Ziel, zur Auslieferung geeignete Artefakte zu bauen (Continuous Delivery; bei Infrastruktur eher ungewöhnlich) und danach tatsächlich zu deployen (Continuous Deployment).

Zentral sind hier automatische Tests, denn nur wenn die Korrektheit des entwickelten Infrastruktur-Codes nachgewiesen ist, können die Entwickler die Verantwortung übernehmen, automatisch auszurollen und damit die Infrastruktur zu verändern.

In den letzten Jahren will man automatische Tests möglichst gemeinsam mit dem "tatsächlichen" Code entwickeln. Um hierfür ständige und kontinuierliche Tests zu unterstützen, wurden in in den letzten Jahren sogenannte CI-Pipelines entwickelt. Dabei wird eine einzelne Datei mit der Spezifikation eines Test-Workflows in das Repository gelegt und bei bestimmten, Operationen (zum Beispiel commit, pull request, merge) automatisch ausgeführt.

Oft wird die Pipeline durch den Repository-Provider bereitgestellt (etwa travis.ci (http://travis.ci/) in Verbindung mit github.com (http://github.com/), gitlab-ci bei gitlab.com (http://gitlab.com/)). Interessanter, weil vom Repository technisch entkoppelt, ist die Ausführung durch einen CI-Server. Dies ist beim CI-Server Jenkins das Jenkinsfile-Plugin. Hier können (in Groovy) programmatisch Aktionen spezifiziert werden, die bei bestimmten Operationen auf ein oder mehrere konfigurierten Repositories Aktionen durchführen.

Der Beitrag verschafft anhand einfacher Beispiele einen Überblick, wie man in einem Infrastruktur-Repository zuerst statisch syntaktische und stilistische Checks auf den Code durchführt, danach dynamisch den Code auf Test-Maschinen appliziert, den Erfolg dieser Operation prüft und schließlich auf den Test-Server mit rspec/serverspec Akzeptanz-Tests ausführt. Diese Operation führt ein Jenkinsfile zusammen. Es zeigt, wie Tests häufig und reproduzierbar im Repository ausgeführt und entwickelt werden können.

Als Beispiel dient Puppet-Code in einem Test-Framework, deren virtualisierte Test-Maschinen docker-Applikations-Container mit systemd verwenden (eine leicht schmutzige Lösung). Der Beitrag führt vor, wie sich der Ansatz auch auf andere Machine-Provider wie VMware, GCE, AWS und andere Konfigurations-Frameworks abstrahieren lässt.

#WeAreCologneCloud