Wurde früher noch "Infrastructure as Code" konfiguriert, gilt heute "Software Defined *" und deshalb "Infrastructure is Code". Solcher wird aber entwickelt (DevOps!) und dann sollte dieser mit etablierter Methodik (Tests!) einer Verifikation zugeführt werden.
Dies ist aber immer noch schwach ausgeprägt. Praktisch motiviert durch Nachweispflichten im regulierten Finanz- und Identitätsumfeld entwickelt der Beitrag einen Überblick über Testmethodik, -ausführung und -Pipelining (Beispiele Puppet, InSpec und Jenkinsfile). Am Beispiel von Kubernetes liveness-probes wird gezeigt, wie dann Testen konzeptionell gegen Monitoring konvergiert und die Lücke von Tests nach Ops in DevOps schließt.
Vorkenntnisse
* Besucher sollten verstehen, dass Softwaresysteme aus verteilten Komponenten zusammengesetzt werden und dass neben Applikationen/Services auch Infrastrukturelemente (Storage, Netzwerk, Firewall) dazu gehören und immer öfter auch durch Code definiert sind.
* Ein grundsätzliches Verständnis von CI-Prozessen ist erforderlich, um darauf aufbauend eine etablierte Methodik auf den Anteil Software Defined Infrastructure ausdehnen zu können.
* Kenntnisse über CI-Server oder -Pipelines, Software wie Puppet oder Ansible oder Container-Manager wie K8s oder Docker-Swarm sind nicht erforderlich – es geht um die Methodik.
Lernziele
* Besucher sollen die Motivation für kontinuierliche Tests auf die Infrastruktur-Komponenten eines verteilten Systems kennenlernen.
* Sie sollen erfahren, wie Methodik, Aufbau und Pipelining von Tests um den Infrastrukturanteil erweitert und wie Tests ins Monitoring aufgenommen werden können.
* Sie sollen anhand einiger Beispiele einen Überblick über mögliche Instanzierungen der Prinzipien sowie Alternativen gewinnen.
* Die Ansätze sind breit verwendbar, prinzipiell unabhängig davon, ob für das Deployment der mutable (Puppet, Ansible) oder der immutable (Applikations-Container) Fall gewählt wird.
* Der Vortrag konzentriert sich auf die Methodik und hebt auf Einzeltechnologien nur als Beispiel und zur Illustration eines übergreifenden Prinzips ab.
// Referent
Christopher J. Ruwe
hat in und nach seinem Studium der BWL festgestellt, dass er doch lieber etwas Vernünftiges hätte lernen sollen und danach parallel zum Beruf Informatik an der Fern-Uni Hagen aufgesattelt. Im Beratungsalltag als DevOps-Consultant und -Engineer (offiziell) oder als Systemarchäologe (eigentlich) wäre er doch lieber Gärtner geworden. Man könnte dann Rosen züchten ...