FAKULTÄT INFORMATIK. Evaluation und Prototypische Umsetzung einer Cloud Infrastruktur mit Infrakit. Bachelorarbeit

Transkript

1 FAKULTÄT INFORMATIK Evaluation und Prototypische Umsetzung einer Cloud Infrastruktur mit Infrakit Bachelorarbeit vorgelegt von Benedikt Huber aus Landshut Eingereicht am:. Betreut von: Prof. Dr. Markus Mock

2

3 ERKLÄRUNG ZUR BACHELORARBEIT Huber, Benedikt Hochschule Landshut Fakultät Informatik Hiermit erkläre ich, dass ich die Arbeit selbständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.... (Datum)... (Unterschrift des Studierenden)

4

5 Danksagung Hiermit möchte ich mich bei allen bedanken, die durch ihre fachliche und persönliche Hilfe mich unterstützt und zum Gelingen dieser Bachelorarbeit beigetragen haben. Insbesondere gilt mein Dank Herrn Prof. Dr. Markus Mock, der mich bei der Anfertigung dieser Arbeit betreut hat und hilfreiche Anregungen gegeben hat. Ebenfalls möchte ich mich bei Anton Brass und Daniel Stahr, meinen beiden Betreuern des Unternehmens Iteratec GmbH ausdrücklich dafür bedanken, dass sie mir mit viel Geduld und Interesse zur Seite standen und ich zu jeder Zeit in ihnen kompetente Ansprechpartner fand. Daneben gilt mein Dank der Geschäftsleitung und den Mitarbeitern der Iteratec GmbH, die mir die Möglichkeit gaben, im Rahmen der Bachelorarbeit praktische Erfahrungen zu sammeln. Ein besonderer Dank gilt Herrn Nikolai Körber, der mich als Studienassistent unermüdlich während meines Studiums an der HAW-Landshut begleitete und mich bis zur Abgabe dieser Bachelorarbeit in unzähligen Situationen egal, ob es persönliche oder fachliche Fragen waren immer unterstützt hat.

6 Abstract Die Bachelorarbeit hatte zum Ziel, die Grundlagen eines Programms zur einfachen Erstellung und Benutzung einer DevOps orientierten Infrastruktur zu legen. Als repräsentative, zeitgemäße Infrastruktur zur Entwicklung, Speicherung und zum Test von Softwareprojekten wurde die Infrastruktur aus dem Studentenlabor des Unternehmens Iteratec GmbH (Gitlab, Jenkins, Nexus Repository Manager, Production-Server) als Vorlage verwendet. Die Aufgabe bestand darin, mit Hilfe von Infrakit - einem Infrastruktur Ochestrierungs Toolkit - diese Infrastruktur plattformunabhängig und flexibel einsetzbar zu machen. Um die Plattformunabhängigkeit zu unterstreichen, wurde eine Infrakit Plugin für virtuelle ServerInstanzen bei Softlayer angefertigt. Zudem wurden Bash-Skripte erstellt, mit denen die Infrastruktur gestartet werden kann. Als Resultat kann der gesamte Prozess des Startens und Installierens der Infrastruktur und den darauf laufenden DevOps Applikationen vollautomatisiert durchgeführt werden. Das Ergebnis dieser Arbeit ermöglicht eine einfache Einbindung in ein Programm zur abstrahierten Benutzung der Entwicklungs-Infrastruktur.

7 Inhaltsverzeichnis 1 Einleitung Was ist DevOps Welche Probleme versucht DevOps zu lösen? Automatisierbarkeit Skalierbarkeit Schnellerer Entwicklungsprozess Höhere Produktqualität Welche Automatisierungs-Tools gibt es? Phase 1: Entwicklung Phase 2: Build, Test, Deploy Phase 3: IT Operations (Betrieb) Infrakit Ziel von Infrakit Funktionsweise, Design von Infrakit Instance Plugin Group Plugins Flavor Plugins Alternativen/Konkurrenz zu Infrakit (AWS Cloud Formation) Iteratec SLab Aufgaben des SLabs DevOps Workflow im SLab Definition der Ziele Infrakit Instance Plugin für IBM Bluemix bzw. Softlayer Iteratec infrastruktur mit infrakit starten Entwicklung des Softlayer Instance Plugins Softlayer REST API Design/Features Tests/Performance Vorbereitung/Vorgehen zur Entwicklung des Plugins Infrakit Demo AWS Instance Plugin Bluemix, Softlayer Mit dem Instanz Plugin Docker auf Instanzen installieren...25

8 7.4.1 Golang Infrakit File Instance Plugin Dependencies softlayer-go Integration des Go Client CreateObject GetActiveTransactions ExecuteRemoteScript DeleteObject Testen des Plugins Automatisiertes Starten der dockerisierten Infrastruktur von Iteratec Probleme Diskussion und Ausblick Literaturverzeichnis Abbildungsverzeichnis Abkürzungsverzeichnis...35

9 1 Einleitung DevOps hat in den letzten Jahren eine immer größere Bedeutung bekommen. Viele IT Unternehmen sichern sich ihren Platz im Markt, indem sie den DevOps Ansatz erfolgreich umsetzen. Neben den offensichtlichen Vorteilen birgt dieser Ansatz auch Nachteile, wie eine hohe Einarbeitung in die vielen Tools, die benötigt werden. Besonders für neue Mitarbeiter eines Unternehmens stellt dies eine Herausforderung dar. Statt effektiver Arbeit verbringen sie ihre Arbeitszeit zunächst damit, sich mit den vielfältigen DevOps Tools vertraut zu machen. Hier besteht ein Verbesserungspotential in Form einer zentralisierten Applikation, die immer gleiche Tätigkeiten automatisiert (das Erstellen und Konfigurieren eines Neuen Projekts). Im Rahmen dieser Arbeit wird Infrakit[1], ein Infrastruktur Orchestrierungs Toolkit um automatisiert eine DevOps Infrastruktur zu starten und zu kontrollieren. 1 verwendet,

10 2 Was ist DevOps Wie schon in der Einleitung erwähnt, hat DevOps in den letzten Jahren eine immer bedeutendere Rolle eingenommen. Bei kleinen Projekten wird oft ohne darüber nachzudenken auf eine DevOps ähnliche Methode gesetzt, auch größere Unternehmen wie Google, Amazon, Facebook, Etsy und Netflix[2] schaffen sich mit DevOps erfolgreich einen Marktvorteil. Der Begriff DevOps ist eine Zusammensetzung aus Development (deutsch: Entwicklung) und IT Operations (deutsch: IT Betrieb). Er beschreibt eine engere und damit bessere Zusammenarbeit dieser Bereiche. Diese Definition ist jedoch sehr vage und aus ihr geht keine konkrete Beschreibung hervor, was DevOps ist. Es gibt keine allgemeine ganzheitliche Definition, seitdem der Begriff nach der ersten DevOpsDays[3] Konferenz 2009 an Popularität gewonnen hat. Amazon Web Services (AWS)[4] definiert DevOps wie folgt: DevOps ist eine Kombination von Denkweisen, Praktiken und Tools, mit denen Unternehmen schneller und einfacher Anwendungen und Services bereitstellen können. Die Weiterentwicklung und Verbesserung von Produkten gelingt damit in kürzerer Zeit als bei Unternehmen, die auf herkömmliche Prozesse für die Softwareentwicklung und Infrastrukturverwaltung bauen. Dank dieses Geschwindigkeitsvorteils können Unternehmen ihre Kunden besser bedienen und sich effektiver auf dem Markt durchsetzen[5]. Andere Definitionen beschreiben DevOps auf eine ähnliche Weise. Aus allen Definitionen geht hervor, dass es sich um eine Philosophie, Denkweise oder Konzepte handelt, mit Hilfe dieser die Zusammenarbeit zwischen dem Development und der IT Operations Abteilung eines Unternehmens verbessert werden soll. Um solche Konzepte zu realisieren, werden unterschiedliche Tools und Anwendungen genutzt. 2

11 Die Kombination aus den Konzepten und Tools optimieren die Softwareentwicklung und die Infrastrukturverwaltung soweit, dass das Softwareprodukt schneller weiterentwickelt und verbessert werden kann. Dies wiederum führt zu einer größeren Kundenzufriedenheit und damit zu einer besseren Marktpositionierung. DevOps erfüllt drei entscheidende Eigenschaften: 1. Automatisierbarkeit 2. Skalierbarkeit 3. Verbesserte Zusammenarbeit Alle drei Kriterien sind für den Erfolg bei größeren Projekten von wesentlicher Bedeutung. 2.1 Welche Probleme versucht DevOps zu lösen? Um die Aufgaben von DevOps zu beschreiben, muss etwas genauer auf die Prozesse von DevOps eingegangen werden. Die Produktion einer Software wird grob in drei Phasen unterteilt: Entwicklung, Test und Betrieb. Alle Phasen werden im Gegensatz zu herkömmlichen Ansätzen nicht getrennt voneinander durchlaufen, sondern die Phasen greifen direkt ineinander über. Das heißt: es wird ein neues Feature eines Produkts entwickelt, sobald das Feature getestet werden kann, wird es zu dem schon vorhandenen Produktcode hinzugefügt und getestet, also in die nächste Phase übergegangen. Falls Probleme/Bugs beim Testen des Produkts auftreten, kann davon ausgegangen werden, dass das neue Feature das Problem ausgelöst hat und es kann sofort nach einer Lösung gesucht werden. Damit kann das Problem sofort beseitigt werden. Diese Praxis wird auch als Continuous Integration (CI) bezeichnet. 3

12 Abbildung 1: Drei DevOps [ s/content/cisecuritychecking2.png] Phasen Automatisierbarkeit Eine Weiterentwicklung des Continuous Integration ist das Continuous Delivery (CD). Das CD erweitert das CI dahingehend, dass die Testphase standardisiert und automatisiert wird und bei Erfolg der Tests ein automatisches deployment (deutsch: Bereitstellng) in einer Test- und/oder Produktionsumgebung stattfindet. Zum Beispiel wird ein neues Feature entwickelt, automatisch zum schon vorhandenen Code hinzugefügt, getestet und in eine Betriebsumgebung deployed. Ein besonderes Merkmal von CD ist, dass jederzeit auf eine funktionierende Vorgängerversion gedowngraded werden kann, was den Prozess deutlich verlässlicher macht[6]. Die volle Automatisierung beschleunigt den gesamten Prozess vom Entwickeln über das Testen bis hin zum Betrieb maßgeblich. Durch CI/CD und vor allem durch die stärkere Zusammenarbeit der Entwicklung, Qualitätssicherung und Administration entsteht eine positive Feedback-loop[7]. Diese Feedback-loop führt zur schnelleren Entdeckung und Beseitigung von Bugs und damit zu einer 4

13 höheren Softwaresicherheit und -qualität. Außerdem läuft das Deployment und der Betrieb der Software reibungloser. Und zuletzt kann das Produkt besser auf die Bedürfnisse des Kunden angepasst werden Skalierbarkeit Unter Skalierbarkeit versteht man die Fähigkeit eines Systems, bei wachsenden Anforderungen erweitert werden zu können. Ein System wird skaliert, indem zusätzliche Hardware hinzugefügt oder die vorhandene Hardware aktualisiert wird, ohne dass große Änderungen an der Anwendung vorgenommen werden[8]. Aufgrund der Prinzipien des CI/CD ist der Prozess außerdem noch sehr gut skalierbar, da immer eine funktionsfähige Version der Software erhalten bleibt und dadurch paralell entwickelt und sehr effizient getestet werden kann Schnellerer Entwicklungsprozess Zusammenfassend führt DevOps dazu, dass nicht mehr große Softwareteile nach langer Entwicklungszeit zusammengesetzt und getestet werden müssen und Verbesserungen sowie Anpassungen nur noch schwer umzusetzen sind. Vielmehr wird dieser Prozess in kleine Teile aufgeteilt und die Software kann somit einfacher Schritt für Schritt erweitert, getestet und verbessert werden. Paralell zur Entwicklung der Software kann die Administration der unterliegenden Server besser auf die Anforderungen der Software eingehen und die Hardware anpassen und dadurch kann eine bessere Skalierbakeit garantieren werden. 5

14 2.1.4 Höhere Produktqualität All diese Vorteile führen letztendlich zu einem qualitativ besseren Produkt, das sogar schneller vom Kunden genutzt werden kann. 2.2 Welche Automatisierungs-Tools gibt es? Aus Gründen der großen Popularität von DevOps existiert eine Vielzahl an unterschiedlichsten Tools. Hier eine kleine repräsentative Auflistung von Tools, die das Konzept von DevOps umsetzen. Folgende Auflistung der Tools ist weder vollständig noch sind die aufgezählten Tools anderen zu bevorzugen. Sie wurden lediglich zur Nutzung in dieser Bachelorarbeit herangezogen und zum Teil sogar genutzt. Im folgenden werden sie nach den drei Phasen (Entwicklung, Test und Betrieb) aufgeteilt aufgezählt: Phase 1: Entwicklung Git ist einer der bekanntesten und weit verbeitetsten VCSs (Version Control System). Git ist außerdem kostenlos und opensource[9]. Github[10]/Bitbucket[11]/Gitlab[12] bieten Softwaredevelopment Plattformen an, um Code Repositories zu managen, auf die ein oder mehrere Entwickler ihren Code sammeln und verwalten. In Kombination mit Git ermöglicht solch ein Service, Entwicklern gleichzeitiges Arbeiten an einem Codeprojekt, indem alle Beteiligten eine lokale Version des gesamten Codes haben, erweitern können und bei Bedarf mit der Version auf der Softwaredevelopment Plattform angleichen (eng: merge) können. Die Versionsverwaltung und das Zusammenführen der verschiedenen Versionen übernimmt Git bzw. die Plattform. Die genannten Anbieter bieten unterschiedliche Dienste an: kostenlose/-pflichtige online Repositories, die von den Anbietern gehostet werden oder kostenlose/-pflichtige lokale Repositoryserver. Besonders für große Unternehmen kann es sinnvoll sein, einen eigenen oft lokalen Repositoryserver zu nutzen, da 6

15 1. die Verantwortung über die Sicherheit des Codes vom Unternehmen selber übernommen werden kann. 2. bei einer hohen Anzahl an Zugriffen auf die Softwaredevelopment Plattform durch eine lokale Lage ein finanzieller Vorteil oder ein Vorteil der Performance entstehen kann Phase 2: Build, Test, Deploy Der wohl wichtigste Teil von DevOps ist der CD/CI Teil einer DevOps orientierten Infrastruktur. Jenkins[13] ist beispielsweise eine Applikation, die das Konzept automatisiert umsetzt. Ein gewöhnlicher Workflow von Jenkins beinhaltet zum Beispiel folgende Schritte: Jenkins cloned sich den entwickelten Code von einem Code Repository, baut daraus ein Docker Image und deployed diesen in der gewünschten Umgebung. Das alles setzt nur einen Knopfdruck des Entwicklers voraus. Ein weiteres Tool, das im Rahmen von DevOps genutzt werden kann, ist Docker[14]. Als Beispiel kann eine entwickelte Sofware in einem Docker Container gestartet werden, wodurch alle Vorteile eines Containers genutzt werden können. Der Nexus Repository Manager[15] kann vielfältig eingesetzt werden, z.b. als lokale Alternative zu DockerHub, als privates Repository für Docker Container Phase 3: IT Operations (Betrieb) Mit Hilfe von Docker Compose[16] können mehrere Docker Container in einer bestimmten Reihenfolge gestartet werden. Docker-Compose ist besonders bei Applikationen sinnvoll, die sehr viele Docker Container nutzen. Docker Swarm[17] bietet die Möglichkeit komplexere Applikationen in mehreren Docker Containern zu kontrollieren und automatisch zu skalieren. Docker Swarm wird meist in Kombination mit Docker-Compose benutzt. 7

16 Kubernetes[18] ist ein weiteres Tool, dass zur Überwachung und Skalierung von Containern verwendet werden kann. Unter DevOps wird Kubernetes oft für Applikationen genutzt, die auf größeren Container Clustern laufen. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications[18]. Zu guter Letzt ist Infrakit[1] noch zu erwähnen, auf das in Punkt 3 eingegangen wird. Amazon Web Services[4] ist eine sichere Plattform für Cloud-Services, die Rechenleistung, Datenbankspeicherung, Bereitstellen von Inhalten und weitere Funktionen bietet, und das Wachstum eines Unternehmens unterstützt. Millionen von Kunden können damit Produkte der AWS Cloud nutzen sowie auf Lösungen zum Erstellen hochentwickelter Anwendungen mit großer Flexibilität, Skalierbarkeit und Zuverlässigkeit zurückgreifen[19]. Die IBM Cloud (Bluemix)[20] stellt eine nahtlose Integration in Public- und Private-CloudUmgebungen sicher. Die IBM Cloud bietet eine sichere, skalierbare und flexible Infrastruktur. Gerade branchenspezifische Unternehmenslösungen haben die IBM Cloud zu einem der Marktführer der Hybrid Clouds gemacht. Bluemix basiert auf den Services von Softlayer. Softlayer[21] ist ein Unternehmen, dass zu IBM gehört und IaaS (Infrastruture as a Service) anbietet. Die Anzahl der weltweit verteilten Datenzentren und Netzwerkknotenpunkten wächst stetig. Die Kunden von Softlayer reichen von Web Startups bishin zu Enterprise Unternehmen. IBM sieht vor, Softlayer Services und Produkte zunehmend in Bluemix zu integrieren[22]. 8

17 Siehe weitere DevOps Tools[23]: In der folgenden Grafik sind weitere DevOps Tools dargestellt: Abbildung 2: Periodensystem von DevOps Tools[ 9

18 3 Infrakit Infrakit[1] ist ein Infrastruktur Orchestrierungs Toolkit und wird hauptsächlich von den Entwicklern David Chung und Bill Farner[24] verwaltet. Es ist aus der Idee entstanden, die Installation von Docker Container auf unterschiedlichen Plattformen (AWS EC2, Terraform, Softlayer, ) zu vereinfachen. Genauer gesagt sollte ein Tool zur automatischen Aufbereitung oder Erzeugung einer Infrastruktur für Docker geschrieben werden. Um eine noch breitere und flexiblere Anwendung von Infrakit zu gewährleisten, wurde es so designed, dass es nicht nur für Docker Container, sondern für jegliche Art von Software einsetzbar ist. Das heißt Infrakit kann verschiedenste Clusterstrukturen auf unterschiedlichen Plattformen, Cloudprovidern oder anderen Umgebungen ausführen. Da Infrakit noch sehr jung ist, ist es für den aktiven Gebrauch in Produktionsumgebungen in Unternehmen nur bedingt geeignet. Aber die Grundfunktionalitäten sind schon vorhanden. Es wird stetig erweitert und verbessert, was unter anderem der Tatsache zu verdanken ist, dass es open source ist und jeder über das Github Repository zur Entwicklung beitragen kann. Das Besondere an Infrakit ist, dass es deklarativ ist, d.h. der Benutzer definiert, wie das Cluster aussehen soll und Infrakit setzt alles daran, den definierten Zustand zu erreichen. Es überprüft konstant, ob die Definition und der Zustand des Clusters übereinstimmen. Dadurch heilt Infrakit das Cluster automatisch, sobald ein Teil des Clusters nicht mehr so funktioniert wie vorgesehen. Ein Feature, das durch das deklarative Wesen von Infrakit begünstigt wird, bietet die Möglichkeit Rolling Updates durchzuführen, die durch eine einfache Änderung der Deklaration initiiert werden. Infrakit erneuert während eines Rolling Updates Stück für Stück das gesamte Cluster, um der neuen Deklaration gerecht zu werden. 3.1 Ziel von Infrakit Mit Infrakit soll man Low-Level Infrastruktur für jede mögliche Art von Cluster managen können. Infrakit soll ein Cluster so kompatibel und flexibel machen, wie ein Docker Container 10

19 eine Applikation flexibler und kompatibler macht. Zudem ist Infrakit primär ein Toolkit, es ist also erweiterbar und sehr flexibel einsetzbar. Demzufolge ist Infrakit nicht an Docker gebunden, es ist auch kein Konfigurations Management Programm und es ist vor allem keine Alternative zu Docker Swarm oder Kubernetes. Infrakit ist die Antwort auf die Frage, wie die unterliegende Infrastruktur gestartet und gemanaged wird, auf der Docker Swarm oder Kubernetes gesteuerte Applikationen laufen. 3.2 Funktionsweise, Design von Infrakit Infrakit selber ist nur ein Command Line Interface (CLI)[25] mit einer darunter liegenden Logik. Nativ versteht Infrakit nur das infrakit group default[26] Plugin. Es gibt drei Arten von Plugins: Group, Flavor und Instance Plugins. Abbildung 3: Die drei Arten von Plugins und Methoden[ 11 die dazugehörigen API

20 3.2.1 Instance Plugin Eine Art von Plugin wird Instance Plugin genannt. Je nach dem, welche Art von Instanz benutzt werden soll, werden verschiedene Instance Plugins eingesetzt. Zum Beispiel gibt es ein AWS EC2 Instance Plugin, das es Infrakit ermöglicht, EC2 Instanzen zu starten. Die Instance Plugins sind demnach für die Plattformunabhängigkeit verantwortlich. API Methoden[27]: Validate, Provision, Destroy, Label, Describe Group Plugins Das infrakit group default Plugin ist, wie der Name schon sagt, ein Group Plugin. Die Aufgabe von Group Plugins ist es, die Instanzen in Gruppen zu bündeln. Das Infrakit interne Group Plugin infrakit group default unterscheidet zwei Möglichkeiten von Gruppen: Zum einen Gruppen von Instanzen gleicher Art, zum anderen Gruppen von Instanzen, in denen jede Instanz einzigartig ist. Methoden der Group Plugins sind wie Abbildung 3 gezeigt[28]: CommitGroup (früher watch), FreeGroup (früher unwatch), DescribeGroup, DestroyGroup, InspectGroup, unwatch, destroy und update Flavor Plugins Die letzte Art von Plugin wird Flavor Plugin genannt. Dieses Plugin interagiert mit einer Instanz oder mit allen Instanzen einer ganzen Gruppe. Als Beispiel kann hier das infrakit flavor swarm Plugin herangezogen werden, das Docker Swarm in Infrakit einbindet, sodass beispielsweise auf einer Gruppe von EC2 Instanzen Docker Container in Swarm Mode gemanaged werden können. API Methoden[29]: Validate, Prepare, Healthy, Drain 12

21 Abbildung 4: Die Abbildung zeigt eine Beispiel Plugins[ Konfiguration verschiedener Aus technischer Sicht betrachtet sind Plugins Http-Server, die über Unix Sockets miteinander kommunizieren[30]. Dieser Aufbau zeigt die Natur von Infrakit als Toolkit und ermöglicht eine nahezu grenzenlose Erweiterbarkeit und Flexibilität. Alle Plugins können ein oder mehrere Konfigurations Dateien einlesen, um daraus die gewünschte Infrastruktur aufzubauen. Die Konfigurations Dateien beschreiben den Zustand der vollständig aufgebauten Infrastruktur, wodurch das deklarative Wesen von Infrakit entsteht. 13

22 Abbildung 5: zeigt eine Beispiel JSON Konfiguration in der alle drei Plugins konfiguriert werden[1]. 3.3 Alternativen/Konkurrenz Formation) zu Infrakit (AWS Cloud Wie schon in Punkt 3.1 erwähnt sind Docker Swarm, Kubernetes oder auch Terraform keine Alternativen zu Infrakit und deshalb auch keine Konkurrenz. Sie erfüllen schlicht einen anderen Zweck. Um den Unterschied dieser Applikationen zu Infrakit zu verdeutlichen, kann man sich die Frage stellen, wie die Infrastruktur, aus der das Cluster besteht, gestartet und gemanaged wird. Infrakit kann mit diversen Plugins sogar in Kombination mit solchen Tools genutzt werden, sodass das Ausmass der potentiellen Einsatzgebiete von Infrakit erst zur Geltung kommt. 14

23 Ein Tool, das eine ähnliche Funktionalität zur Verfügung stellt, ist AWS Cloud Formation[31]. Allerdings bietet Infrakit den Vorteil, nicht nur an AWS gebunden zu sein. Außerdem bietet Infrakit durch die flexible Erweiterbarkeit, potenziell mehr Anwendungsfälle und mehr Funkionalität. 15

24 4 Iteratec SLab SLab ist die Abkürzung von Studenten Labor. Iteratec ist das Unternehmen, mit dessen Hilfe diese Bachelorarbeit entstehen konnte. SLab ist eine Abteilung der Iteratec GmbH, die sich zum Ziel gesetzt hat, ein Netzwerk aus kompetenten und motivierten Studenten aufzubauen. Die Studenten im SLab profitieren von neuen Kontakten und Erfahrungen auf unterschiedlichen Gebieten der Informatik. Iteratec profitiert von potentiellem Nachwuchs und den internen Projekten, die die Studenten bearbeiten. Da im Projektalltag oft nicht genug Zeit zum Experimentieren und Forschen bleibt, haben wir das Studentenlabor (slab) gegründet. Dort wird nicht nur eine Vielzahl von internen Projekten umgesetzt, sondern wir widmen uns verschiedenen aktuellen Forschungsthemen und Innovationen. Die Studenten arbeiten in wechselnden Teams und werden dabei von erfahrenen Mitarbeitern unterstützt. Neben den Projekten gibt es auch Forschungsarbeiten (Bachelor- und Masterarbeiten), die in Zusammenarbeit mit anderen Firmen und verschiedenen Universitäten und Hochschulen durchgeführt werden.[32] 4.1 Aufgaben des SLabs Das Studenten Labor ist so aufgebaut, dass es sich nahezu selbstständig versorgt, d.h. die Studenten sind für die Infrastruktur, die sie benutzen, verantwortlich. Die Hauptaufgaben des SLabs bei Iteratec sind die Entwicklung von hilfreichen Webapps, Programmen, die den Workflow verbessern sollen sowie Programmen, die Iteratec intern nutzt. 4.2 DevOps Workflow im SLab Der derzeitige Workflow fängt beim Programmierer mit der Benutzung von Git an. Der so verwaltete Code wird auf ein Gitlab Repository gepushed. Das Zentrum des Workflows stellt 16

25 ein Jenkins Server dar, der den Code vom Gitlab Server unter Zuhilfenahme von Scripten baut, daraus ein Docker Image baut, der daraus entstandene Docker Container wird in einen Docker Repository (Nexus Repository Manager) geladen und von dort aus deployed Jenkins den neu entstandenen Container auf einen Deployment Server. Als Letztes kann dann das Programm, das in einem Docker Container läuft, über die URL des Deployment Servers angesprochen und getestet werden. Abbildung 6: Iteratec GmbH SLab DevOps Infrastruktur[33] 17

26 5 Definition der Ziele Der unter Punkt 4.2 genannte nach dem DevOps Ansatz gewählte Workflow ist eine sehr gute Möglichkeit schnell gute Software zu entwickeln, hat aber auch eine Schwachstelle. Neue Studenten beispielsweise haben einen nicht zu unterschätzenden Einarbeitungsaufwand, den es mit dieser Bachelorarbeit zu minimieren galt. Ziel dieser Arbeit war es Grundlagen zur Entwicklung eines Projekt Management Programms zu schaffen. Als Input dieses Projekt Management Programms dienen einige Projektparameter (z.b. Projektname, Deployment Server, Art des Projekts,...). Danach baut das Projekt Management Programm einen neuen Docker Container mit Jenkins, der um das gewünschte Projekt erweitert wurde. Dadurch läuft die Konfiguration von Jenkins voll automatisiert und es kann der gewünschte DevOps Workflow ohne Kenntnisse über Jenkins realisiert werden. Die restlichen Komponenten (Gitlab, Deployment Server) benötigen nur minimale Interaktionen des Programmierers. Bei jedem darauf folgenden build wird nun mehr nur noch ein Knopfdruck benötigt, um den gesamten Workflow (Gitlab Jenkins Nexus Deployment Server) zu durchlaufen. Daraus folgt, dass praktisch keine Einarbeitung für unerfahrene Studenten erforderlich ist. Als Grundlage solch eines Programms war eine flexible Infrastruktur gedacht, die mit Hilfe von Infrakit gewährleistet werden kann. Eine Infrastruktur, die von Infrakit gemanaged wird, ist gleichzeitig auch plattformunabhängig und kann deshalb sehr einfach vollständig oder nur teilweise in die Cloud ausgelagert werden. Der Hauptgrund für die Benuzung von Infrakit ist die sehr einfach Handhabung der Infrastruktur auch programmatisch. 18

27 5.1 Infrakit Instance Plugin für IBM Bluemix bzw. Softlayer Obwohl Infrakit noch recht neu ist, gibt es unter anderem schon Instance Plugins[34] für AWS, MaaS, Terraform und Vargrant. Im Rahmen dieser Arbeit galt es die Reihe an Instance Plugins um ein Plugin für Softlayer Instanzen zu erweitern. 5.2 Iteratec infrastruktur mit infrakit starten Nach Fertigstellung des Softlayer Instance Plugins wurde dieses für das Starten der Infrastruktur des SLabs von Iteratec genutzt. 19

28 6 Entwicklung des Softlayer Instance Plugins Um einheitlich mit Docker bzw. Infrakit zu bleiben, wurde das gesamte Plugin in der Programmiersprache Go geschrieben. Grundsätzlich ist es nicht notwendig, Plugins für Infrakit in Go zu verfassen, da ein Plugin nur über ein Unix Socket mit Infrakit kommunizieren können muss. Es bot sich in diesem Fall aber an Go zu verwenden, da die gleichen libraries - wie in anderen schon vorhandenen Plugins - benutzt werden konnten. 6.1 Softlayer REST API Zur programmatischen Ansprache der Ressourcen von Softlayer bietet Softlayer einige Webservices an, unter anderen auch eine RESTful Webservice[35]. Darüber hinaus existiert sogar ein Go Client für die REST API von Softlayer. Der Go Client abstrahiert und vereinfacht die Benutzung der API. Die Aufgabe des Plugins ist es, eine Virtual Server Instance (VSI)[36] von Softlayer zu starten. Um das umzusetzen, sind Parameter wie CPUs, RAM der VSI zu spezifizieren. Die benötigten Daten liest das Plugin aus einer JSON Konfigurations Datei und schickt so eine Order an Softlayer. Nach erfolgreicher Vollendung des Requests wird eine Response mit einer einzigartigen ID speziell für den Virtuellen Server empfangen. Softlayer bearbeitet dann diese Order und stellt eine Virtual Server Instance zur Verfügung. 6.2 Design/Features Neben der Grundfunktion Virtuelle Instanzen zu erzeugen, kann das Plugin direkt nach erfolgreicher Bereitstellung eines Virtuellen Servers ein Script auf dem neuen Server ausführen. Das Script wird dabei von einem Remote Server auf den Virtuellen Server geladen und ausgeführt. Die URL zu dem Script auf dem Remote Server wird ebenfalls aus der JSON Konfiguration des Plugins gelesen. 20

29 Die gesamte Funktionalität des neuen Virtuellen Servers und das Ausführen des Scripts kann über das CLI des Plugins über die Methode provision aufgerufen werden. Weiter besitzt das Plugin noch eine Methode validate, die zur Validierung der JSON Konfiguration gedacht ist. Das Plugin besitzt - ebenso wie alle anderen Infrakit Plugins - noch eine Methode describe, die eine kurze Beschreibung des aktuellen Zustands des Plugins gewährt. Nicht zu vergessen ist noch die Methode delete, die eine erzeugte Instanz wieder löscht. Alle aufgezählten Methoden sind über das CLI des Plugins ansprechbar bzw. das Group Plugin, falls eines benutzt wird, spricht diese Methoden ein oder mehrmals an. Die genannten Methoden funktionieren alle nach dem Prinzip: Die ID der anzusprechenden Instanz wird benutzt, um Daten von der Instanz zu bekommen (describe) oder an die Instanz zu schicken (delete). 6.3 Tests/Performance Diverse Tests des Plugins haben gezeigt, dass es in seltenen Fällen zu unvollständigen API Responses kommen kann. Die daraus resultierenden Fehler werden allerdings vom Plugin abgefangen und ein erneuter Versuch der gewünschten Aktion ist notwendig. Ein anderes Problem, das bei der Entwicklung des Plugins aufgetreten ist, ist dass das Plugin erfolgreich eine Order an Softlayer schicken kann, also eine Response mit der VSI ID bekommt, aber die Virtuelle Server Instance nicht sofort einsatzfähig ist. Die Verzögerung zwischen Order und Betriebereitschaft der Instance beträgt normalerweise weniger als fünf Minuten, eine Verzögerung von ca. 30 Minuten ist aber auch schon vorgekommen. Dadurch kann es vorkommen, dass beispielsweise eine describe Anfrage gesendet wird, diese aber eine Fehlermeldung zurückgibt, da die Server Instanz noch nicht betriebsbereit ist. Zur Vermeidung solcher Fehlermeldungen wurde ein periodischer Testmechanismus eingebaut, der erst dann eine positive Rückmeldung gibt, wenn keine Transaktionen mehr auf der VSI ausgeführt werden. 21

30 7 Vorbereitung/Vorgehen Plugins zur Entwicklung des Bei dem Vorgehen wurde das Prinzip divide and conquer angewandt. Deshalb wurde über viele kleine Wege, teilweise auch Umwege das Ziel erreicht. Die folgenden Abschnitte erläutern die wichtigsten Schritte: 7.1 Infrakit Demo Zuerst galt es sich mit der Toolkit Infrakit vertraut zu machen, was aufgrund der schnellen Weiterentwicklung von Infrakit schon die erste Hürde darstellte. Denn die Dokumentation von Infrakit war soweit veraltet, dass nicht immer offensichtlich war, ob die Information noch Gültigkeit hatte. Außerdem gab es am Anfang dieser Arbeit kaum Quellen wie Infrakit zu benutzten ist, oder wie Infrakit funktioniert. Nach einigen fehlgeschlagenen Versuchen wurde die Funktionsweise von Infrakit klar. Die einfachste Art Infrakit zu benutzen, besteht darin, Datei Instanzen mit Infrakit zu erstellen; die Anzahl dieser wird im Konfigurations Datei angegeben. Nach erfolgreicher Erstellung aller Datei Instanzen kann man durch Löschen einer Datei beobachten, wie Infrakit konstant versucht, den definierten Zustand zu erreichen und automatisch ein neue Datei zu erstellen. 7.2 AWS Instance Plugin Um Erfahrung mit Cloud Providern zu sammenln, empfielt es sich, das schon vorhandene Infrakit Instance Plugin für AWS EC2 Instancen zu testen und zu verstehen. AWS bietet 12 Monate kostenlose Benutzung von vielen verschiedenen Services an, natürlich in begrenzter Weise. Deshalb war die Erstellung eines AWS Accounts zum Testen ohne Kosten verbunden und dadurch recht attraktiv. 22

31 Um AWS und den Zusammenhang zu Infrakit besser verstehen zu können, ist es zu empehlen, alle drei Möglichkeiten auszuprobieren, EC2 Instanzen zu erstellen. Die erste und einfachste Option ist die Erstellung über das intuitiv zu bedienende Webinterface von AWS. Die AWS Dokumentation[37] stellt sehr gute kurze Guides zur Verfügung, um solche und ähnliche Services von AWS zu nutzen. Eine andere Option Services von AWS zu nutzen, ist über das CLI von AWS[38]. Um dieses benutzen zu können, bedarf es mehrerer Account spezifischer Daten wie einen Access-Key und einen Secure-Key[39]. Dadurch weiß das lokal installierte CLI, über welchen Account benötigte Services genutzt werden. Das CLI von AWS ist ebenfalls gut dokumentiert. Die letzte Option ist eine EC2 Instance über das Plugin infrakit instance aws zu starten. Auch hierzu werden die Account Daten benötigt, die aus den versteckten Dateien[40] des AWS CLIs gelesen werden können. Das Infrakit AWS Plugin stellt eine ganze Reihe Authentifizierungsmöglichkeiten zur Verfügung, so zum Beispiel können Access-Key und Secure-Key auch aus Umgebungsvariablen gelesen werden, was aus Sicherheitsgründen allerdings nicht empfohlen wird. 7.3 Bluemix, Softlayer Da Bluemix sowieso auf den Services und Produkten von Softlayer basiert, hat IBM entschieden Softlayer zunehmend in Bluemix zu integrieren. Die Integration führt dazu, dass es nicht mehr zwei unterschiedliche Accounts jeweils für die Bluemix Plattform und für Softlayer geben soll. Das Softlayer Control Panel soll in Zukunft nur noch über die Bluemix Console bedient werden[22]. Zum Zeitpunkt dieser Arbeit war der Prozess der Integration noch nicht weit fortgeschritten, was zu kleineren Problemen bei der Nutzung der Accounts führte. Beispielsweise war es im Bluemix Account nicht möglich, Serverinstanzen zu erstellen oder zu verwalten, hierzu musste das Softlayer Control Panel genutzt werden. 23

32 Außerdem konnte das kostenlose Kontingent im Gegensatz zu AWS nicht genutzt werden, um Serverinstanzen zu erstellen. Das Erstellen einer Virtuellen Server Instanz (VSI) im Softlayer Control Panel stellte sich als einfach heraus. Es werden einige Daten benötigt wie z.b. RAM, CPUs, SSD/Festplatten/SAN Speicher, Firewall,. Nach erfolgreichem Platzieren einer Order dauert es wenige Minuten bis die VSI betriebsbereit ist. Da Bluemix auf Cloud Foundry - ein open source Platform as a Service (PaaS) Projekt basiert, basiert[41] auch die CLI von Bluemix auf dem von Cloud Foundry. Das CLI von Bluemix kann nebem dem Webinterface genutzt werden, um Bluemix zu nutzen. Abbildung 7: Beziehung SoftLayer - Bluemix - OpenStack CloudFoundry [ Softlayer bietet eine Reihe an Webservices an, gleich ob SOAP oder REST, um Transaktionen wie das Platzieren einer Order durchzuführen. Um die Webservices nutzen zu können, werden ähnlich wie bei AWS - die User-ID und der passende API-Key benötigt, der im Softlayer Control Panel ausgelesen werden kann. Eine einfache Möglichkeit den RESTful Webservice zu 24

33 testen, ist über einen Webbrowser; nach Eingabe der persönlichen Daten in ein Popup-Fenster sollten Daten in JSON oder XML Format im Browserfenster auftauchen. Besser ist es jedoch einen Webservice mit Hilfe einer Programmiersprache anzusprechen. Im Fall dieser Arbeit bot sich Go an. Zum einen da Infrakit in Go implementiert ist, zum anderen da es einen Go Client gibt, der den RESTful Webservice von Softlayer nutzt. Dieser Go API Client[42] ermöglicht eine komfortable Nutzung der REST API von Softlayer. Das programmatische Platzieren einer Order zur Erstellung einer VSI gestaltet sich somit sehr einfach. 7.4 Mit dem Instanz Plugin Docker auf Instanzen installieren Folgender Abschnitt geht auf die Entstehung des Plugins ein und erläutert, wie es auf eine neue Virtuelle Server Instanz zugreifen kann Golang Da das gesamte Plugin in Go geschrieben ist, ist es notwendig sich mit dieser Sprache auseinanderzusetzen. Eine gute Möglichkeit, um ein Gefühl für Go zu bekommen, ist das Go Tutorial A tour of Go, das sowohl auf der Website[43] von Go als auch nach der Installation lokal zur Verfügung steht. Das Tutorial besteht aus einer Kombination von Erklärungen und interaktiven Übungen, wodurch man sich Schritt für Schritt mit der Sprache vertraut machen kann Infrakit File Instance Plugin Wenn man die Grundlagen der Sprache beherrscht, empfiehlt es sich, das infrakit-file-instance Plugin[44] direkt aus dem Code von Infrakit zu kopieren. Das ermöglicht es einem mit dem Plugin Code zu spielen und so ein tieferes Verständnis der Funktionsweisen zu bekommen. Das File Instance Plugin erzeugt lokale Dateien, die eine Instanz repräsentieren sollen. In die 25

34 erstellte Datei schreibt das Plugin die Konfiguration, die es zur Erstellung der Instanz genutzt hat. Dadurch versteht man besser, wie Infrakit Plugins eigentlich funktionieren Dependencies Trash[45] ist ein Vendor Management Tool, das automatisch einen Ordner mit allen benötigten Dependencies erstellt und so das Plugin unabhängig von anderem Code macht softlayer-go Der Go API Client[42] für Softlayer ist eine sehr hilfreiche Code Bibliothek, die die Benutztung der REST API von Softlayer komfortabel gestaltet. Mit Hilfe des Go Clients ähnelt die Verwendung der REST API anderen bekannten Softlayer SDKs[42] und verringert den Programmieraufwand auf ein Minimum. Außerdem deckt der Go Client die volle Funktionalität der REST API ab, d.h. man muss keine Kompromisse eingehen. Ein API Request ist immer wie folgt aufgebaut: Abbildung 8: Minimales Beispiel sofylayer-go[42] 26

35 7.4.5 Integration des Go Client Für die Integration des Go Clients in das Softlayer Instanz Plugin sind vier Methoden besonders wichtig: service := services.getvirtualguestservice(p.sess) Für alle folgenden Methoden gilt: p.sess stellt eine neue Session dar CreateObject vguest, err := service.mask("id;domain").createobject(&vguesttemplate) CreateObject() wird verwendet, um eine neue VSI anzufragen. vguesttemplate ist ein Datentyp, der alle Daten zur Erstellung der VSI enthält. Mask führt dazu, dass nur die übergebenen Werte id und domain zurück gegeben werden. Abbildung 9: Zeigt einen POST Request Die Abbildung 9 zeigt einen POST Request bestehend aus URL der REST API SoftLayer_Virtual_Guest, des angefragten Objekts das gewünschte Format der Response.json und die Maske? objectmask=id%3bdomain 27

36 GetActiveTransactions transactions, err = service.getactivetransactions() Abbildung 10: Zeigt einen GetActiveTransaktions Request GetActiveTransaktions() benutzt man, um zu überprüfen, ob Transaktionen auf einer VSI durchgeführt werden. Falls keine Transaktionen durchgeführt werden, ist die VSI in einem Zustand, indem sie neue Transaktionen durchführen kann, wie das Ausführen eines Remotescripts oder sie kann gelöscht werden ExecuteRemoteScript err = service.id(*vguest.id).executeremotescript(sl.string(init)) Um ein Remotescript auszuführen zu können, wird die Methode ExecuteRemoteScript() benötigt, wobei init die URL des Remotescripts und *vguest.id die ID der VSI ist. Abbildung 11: Bashscript hello_world.sh aus Github Repository ausgeführt DeleteObject success, err := service.deleteobject() DeleteObject() wird verwendet, um eine Anfrage zur Löschung einer existierenden VSI zu stellen. 28

37 7.4.6 Testen des Plugins Nach der Implementierung des Plugins empfielt es sich, dieses ausgiebig zu testen. Die obigen Bilder zeigen den Output eines Tests. Man kann erkennen, dass eine zeitliche Verzögerung zwischen dem ersten Request (eine neue VSI Order) und dem Ausführen des Remotescripts wenige Minuten vergehen. In dieser Zeit wird die VSI von Softlayer zur Verfügung gestellt. 7.5 Automatisiertes Starten der dockerisierten Infrastruktur von Iteratec Die zentrale Funktion des Softlayer Instanz Plugins ist, die Option Scripte also beliebigen Code auf einer VSI auszuführen. Docker erlaubt es einem mit einem Script[46] Docker automatisch zu installieren, dies vereinfacht die Nutzung von Docker ungemein. Da Docker sehr einfach zu benutzten ist (auch in einem Script) und ohnehin schon Docker Container für jede Komponente der gewünschten Infrastruktur existieren, ist Docker ein optimales Tool für diesen Usecase. 29

38 8 Probleme Die größte Schwierigkeit bei der Anfertigung dieser Arbeit war die Arbeit mit Infrakit. Da Infrakit zu Beginn der Bachelorarbeit noch sehr jung war, stellte es sich als eine Herausforderung dar, überhaupt an Informationen über die Funktionsweise Infrakits zu gelangen. Die Informationsquellen beschränkten sich auf schon vorhandenen Code, dazugehörige Dokumentation und zwei Videos der Entwickler. Aufgrund der schnellen Weiterentwicklung von Infrakit waren die Dokumentation und die Videos jedoch veraltet, was die Einarbeitung in ein Tool auf einem neuen Fachgebiet erheblich erschwerte. Durch Geduld und einige Versuche gelang es dann allerdings, sich mit Infrakit vertraut zu machen. 30

39 9 Diskussion und Ausblick Im Erstellen dieser Bachelorarbeit ist ein Softlayer Instanz Plugin entstanden, das Virtuelle Server Instanzen über den RESTful Webservice erzeugen kann. Es hat sich herausgestellt, dass Infrakit ein sehr flexibel einsetzbares Toolkit mit einem großen Potential ist. Denn Infrakit kann auch für andere Zwecke genutzt werden, z.b. beim Testen von Cluster Applikationen in unterschiedlichen Szenarien oder es können bewährte Infrastrukturen auf Infrakit JSON Dateien abgebildet werden und sehr einfach für anderen nutzbar gemacht werden. Obwohl sich Infrakit noch in der Anfangsphase befindet, lassen sich eine Vielfalt an Verwendungszwecken erkennen. Durch diese Arbeit wurde außerdem die Basis für eine einfach zu bedienende DevOps orientierte Infrastruktur gelegt. Auf dieser Basis kann beispielsweise ein Programm aufbauen, das in der Lage ist, automatisiert Projekte zu erstellen und die gesamte Infrastruktur zu konfigurieren. 31

40 10Literaturverzeichnis 1: David Chunger und Bill Farner, Github Repository docker/infrakit, 10 April 2017, 2: Gene Kim, The DevOps Handbook: How to Create World-Class Agility, Reliability and Security in Technology Organizations, 06 Oktober :,,, 4:, Amazon Webservice, 15 April 2017, 5:, DevOps Definition, 10 April, 6:, Continuous Delivery, 10 April, 7: jamesbetteley, 8 Principles of Continuous Delivery, 4 August 2011, 8: Microsoft, Was ist Skallierbarkeit?, 10 April 2017, 9:, git-scm, 15 April 2017, 10:, Built for developers, 15 April 2017, 11:, Code, Manage, Collaborate, 15 April 2017, 12:, The platform for modern developers, 15 April 2017, 13:, Jenkins, 15 April 2017, 14:, What is Docker, 15 April 2017, 15:, Nexus Repository Manager, 15 April 2017, 16:, Docker Compose, 15 April 2017, 17:, Swarm mode overview, 15 April 2017, 18:, Production-Grade Container Orchestration, 15 April 2017, 19:, Was ist AWS, 15 April 2017, 32

41 20:, Warum IBM computing/de/de/ Cloud?, 15 April 2017, 21:, Aout SoftLayer, 15 April 2017, 22: Kevin Hazard, The future of SoftLayer is bright. And it s Bluemix, 15 April 2017, 23: Drue Placette, 51 Best DevOps Tools for #DevOps Engineers, 15 April 2017, 24: David Chung, Bill Farner, Infrakit maintainers file, 15 April 2017, 25:, InfraKit CLI, 23 April 2017, 26:, InfraKit Group Plugin, 23 April , 27:, Instance plugin API, 23 April , 28:, Group plugin API, 23 April , 29:, Flavor plugin API, 23 April , 30:, Plugins, , 31:, AWS CloudFormation, April 15 April 2018, 32:, Das slab für pfiffige Studenten, 15 April 2017, 33: Benedikt Huber, SLab DevOps Infrastruktur, 15 April 2017, 34:, Example Instance Plugins, 23 April 2017, April 2017, 35:, REST, 15 April 2017, 36:, Getting started with VSIs, :, AWS-Dokumentation, 15 April 2017, 38:, AWS-Befehlszeilen-Schnittstelle, 15 April 2017, 33

42 39:, Getting Set Up with the AWS Command Line Interface, 15 April 2017, 40:, InfraKit.AWS, 23 April 2017, 41: Angel Tomala-Reyes, What is IBM Bluemix?, 15 April , 42:, softlayer-go, 15 April 2017, 43:, A Tour of Go, 15 April 2017, 44:, infrakit-file-instance, 23 April 45: Github Rancher, Trash - Go./vendor mana, 46:, Docker install script, 15 April 2017, , April 2017,

43 11Abbildungsverzeichnis Abbildung 1: Drei DevOps Phasen [ s/content/cisecuritychecking2.png]...4 Abbildung 2: Periodensystem von DevOps Tools[ Abbildung 3: Die drei Arten von Plugins und die dazugehörigen API Methoden[ Abbildung 4: Die Abbildung zeigt eine Beispiel Konfiguration verschiedener Plugins[ Abbildung 5: zeigt eine Beispiel JSON Konfiguration in der alle drei Plugins konfiguriert werden[1]...14 Abbildung 6: Iteratec GmbH SLab DevOps Infrastruktur[33]...17 Abbildung 7: Beziehung SoftLayer - Bluemix - OpenStack CloudFoundry [ Abbildung 8: Minimales Beispiel sofylayer-go[42]...26 Abbildung 9: Zeigt einen POST Request...27 Abbildung 10: Zeigt einen GetActiveTransaktions Request...28 Abbildung 11: Bashscript hello_world.sh aus Github Repository ausgeführt

44 12Abkürzungsverzeichnis SOAP VSI URL REST JSON SDK XML AWS ID CLI PaaS SSD RAM CPU SAN EC2 SLab IaaS CI CD VCS Simple Object Access Protocol Virtual Server Instancen Uniform Resource Locator Representational State Transfer JavaScript Object Notation Software Development Kit Extensible Markup Language Amazon Web Services Identifier Command Line Interface Platform as a Service Solide State Disc Random Access Memory Central Processing Unit Storage Area Network (Amazon) Elastic Compute Cloud Studenten Labor Infrastructur as a Service Continuous Integration Continuous Delivery Version Control System 36