Analyse von Docker im Hinblick auf DevOps

Aus Winfwiki

Wechseln zu: Navigation, Suche

Fallstudienarbeit

Hochschule: Hochschule für Oekonomie & Management
Standort: Hamburg
Studiengang: Bachelor Wirtschaftsinformatik
Veranstaltung: Fallstudie / Wissenschaftliches Arbeiten
Betreuer: Prof._Dr._Uwe_Kern
Typ: Fallstudienarbeit
Themengebiet: Analyse von Docker im Hinblick auf DevOps
Autor(en): Jan Thurau, Marlon Rüscher, Dennis Bartuschat
Studienzeitmodell: Abendstudium
Semesterbezeichnung: SS16
Studiensemester: 2
Bearbeitungsstatus: begutachtet
Prüfungstermin: 17.6.2016
Abgabetermin: 5.6.2016


Thema der Seminararbeit: "Analyse von Docker im Hinblick auf DevOps"
Name der Autoren:
Hochschule und Studienort: FOM Hamburg


Inhaltsverzeichnis



1 Einleitung

1.1 Problemstellung

Diese Hausarbeit beschäftigt sich mit den Problemstellungen, denen sich vor allem IT-Unternehmen stellen müssen. Durch die zunehmende Verschmelzung bisher eigenständiger Bereiche und den daraus resultierenden Zielkonflikten entstehen neue Anforderungen innerhalb der Entwicklung und der Organisation bzw. an den Abläufen von Prozessen.

Die DevOps konzentrieren sich dabei auf die Bereiche der Softwareentwicklung und dem Softwarebetrieb. Die resultierenden Konflikte dieser beiden unmittelbar zusammen arbeitenden Bereiche gilt es durch Einsetzen verschiedener Techniken zu begegnen und zu lösen [1].

Die Softwareentwicklung innerhalb des Unternehmens entwickelt kontinuierlich neue Features für die eingesetzte Software. Sie hat auf Change-Requests agil zu reagieren, sich neuen Herausforderungen zu stellen sowie schnell und zuverlässig zu entwickeln. Verantwortlich für diese zunehmende Entwicklung einer agilen Abteilung ist die Tatsache des schnell wandelnden Marktes und den immer neuen Anforderungen durch Kunden und Technik. Diese Kunden nehmen eine schnelle Umsetzung der gestellten Aufgaben als positiv war [2].

Als ergänzende Abteilung ist der Softwarebetrieb zu nennen, der jedoch unterschiedliche Ziele verfolgt. Die Operations verfolgen das übergeordnete Ziel der Stabilität und Beständigkeit. Durch die Aufgabe, Softwareupdates in bestehende Produktivumgebungen zu implementieren und ein sicheres, ausfallsicheres System bereitzustellen, stellt jeder Change-Request ein potentielles Ausfallrisiko dar, dass jedoch mit den Anforderungen des Development vereinbar sein muss.

Während der Zusammenarbeit dieser Bereiche entstehen konkreten Probleme innerhalb der Plattformentwicklung, der Veröffentlichung neuer Features, des Testings und der Implementierung in Produktivumgebungen.

1.2 Ziel der Arbeit

Ziel der Arbeit ist es, mithilfe der Applikation “Docker” den entstehenden Problemen innerhalb der DevOps entgegenzuwirken. Des Weiteren wird analysiert, welche möglichen Anwendungsgebiete gebildet werden können, wie Docker sich hier einfügt, und wie durch den Einsatz bisherige Konflikte gelöst werden können. Bezogen wird dies auf konkrete Szenarien, denen ein grundlegender Überblick über die Thematik vorausgeht.

1.3 Methodischer Aufbau

Im Rahmen dieser Fallstudie werden nach der Einleitung die Grundlagen zu DevOps und Docker genauer erläutert. Im Anschluss werden die Anforderungen sowohl innerhalb der Entwicklung als auch im Betrieb definiert. Anschließend werden die Lösungskonzepte von Docker den Anforderungen gegenüber gestellt und um einen genauen Praxisbezug darzustellen, werden diese Konzepte innerhalb von fiktiven Szenarien angewendet. Es wird ebenfalls auf die Voraussetzungen der Implementierung sowie auf die Anbindung weiterer möglicher Dienste eingegangen. Anschließend wird die Installation sowie Konfiguration von Docker mithilfe von Codebeispielen beschrieben und die Verbindung zu Docker Compose aufgezeigt. Zum Schluss wird das Thema zusammengefasst und ein Ausblick für eine zukünftige Entwicklung dargestellt.

2 Grundlagen

Die Vermittlung des Grundlagenverständnisses ist Inhalt dieses Kapitels. Hier werden DevOps und Docker näher beleuchtet und bilden die Ausgangslage weitere Kapitel.

2.1 DevOps

Nachdem innerhalb der DevOps-Definition eine grundlegende Begriffsdefinition erfolgt, wird innerhalb der Zielsetzung näher auf das verfolgte Ziel sowie den konkreten Ansatz eingegangen.

2.1.1 Definition DevOps

Für die Definition des Begriffs DevOps werden unterschiedliche Definitionen benannt, die jedoch selbe Ziele verfolgen. DevOps beschreibt prinzipiell den Ansatz der Zusammenführung zweier Begrifflichkeit bzw. Abteilungen, die innerhalb der zunehmenden Vernetzung in prozessgetriebenen Unternehmen immer mehr verschmelzen. Dieser setzt sich aus der Softwareentwicklung (dem Development) und der Systemadministration (den Operations) zusammen. Hintergrund ist die steigende Notwendigkeit, den immer kürzer werdenden Entwicklungszyklen innerhalb der Softwareentwicklung bei gleichzeitiger Erhaltung des Qualitätsstandards gerecht zu werden.[3]

DevOps wird häufig in Zusammenhang mit agiler Softwareentwicklung gebracht, die einen Wandel innerhalb der Art und Weise der Software Entwicklung darstellt. Der Begriff beschreibt jedoch auch Veränderungen innerhalb der Unternehmenskultur sowie der Rollenverteilung bzw. den Deployment Chains, die durch diesen Ansatz resultieren [4]. Mit Deployment Chains wird ein Deploymentzyklus beschrieben, der alle notwendigen Schritte von der Anforderungsdefinition bis hin zum Deployment in das Produktivsystem beinhaltet.

Der entstehende Zielkonflikt innerhalb der Zusammenführung beider Abteilungen wurde vom belgischen Systemadministrator Patrick Debois erkannt, der durch grundlegende Ansätze und Maßnahmen den Grundstein für die 2009 erstmalig stattfindende DevOpsDays-Konferenz in Ghent legte. Hier wurden grundlegende Anregungen erstmalig öffentlich geäußert.

Zusammenfassend versucht der Ansatz von DevOps, entstehende Zielkonflikte innerhalb der Zusammenführung von Entwicklung (Development) und Administration (Operations) zu lösen, und stellt hierfür Anregungen und Tools zur Verfügung.

2.1.2 Zielsetzung

Die Softwareentwicklung verfolgt das Ziel, einen hohen Grad an Agilität zu gewährleisten, die es ermöglicht Anpassungen schnell vorzunehmen und auf neue Anforderungen schnell und dynamisch, reagieren zu können. Dies jedoch bei gleichzeitiger Erhaltung eines hohen Qualitätsstandards [3].

Durch das aus der Agilität und der schnellen Anpassung resultierende häufige Deployment ist ein Ziel die Automatisierung von wiederkehrenden Aufgaben wie Testing, Build-Prozessen und co. Dies soll die Komplexität minimieren, die Entwicklungsgeschwindigkeit erhöhen und die Fehleranfälligkeit senken [5]. Zudem entsteht der Vorteil, dass die Einarbeitung neuer Mitarbeiter leichter fällt, da keine Einführung in manuelle Deploymentschritte erfolgen muss.

Der Zielkonflikt entsteht hier bei Betrachtung des Ziels der Administration, die als großes Ziel die Ausfallsicherheit verfolgt. Hier erhöht jedes Deployment das Ausfallrisiko [6].

In den Grundlagen Patrick Debois werden bisherige Ansätze zur agilen Entwicklung beider Parteien vereint und in DevOps Methoden und - Prozessen definiert. Durch diverse Weiterentwicklungen, auch innerhalb von lokalen DevOps treffen, entsteht somit ein agiles Gesamtkonzept. Der Ansatz des Continous Delivery, dass die häufige Auslieferung hochqualitativer Software meint, wird durch den DevOps Ansatz begünstigt [5] .

Für die an der Entwicklung beteiligten Mitarbeiter bedeutet dies, dass Planung und Durchführung von Projekten zusammen mit Entwicklung und Administration erfolgen. Ziel muss es sein, schon während der Entwicklung möglichst nah am späteren Livesystem zu arbeiten. Durch den Einsatz von Virtualisierungstechnologien oder Tools wie bspw. Docker wird es ermöglicht, schon während der Entwicklung die Fehlertoleranz zu minimieren, da umgebungsbedingte Fehler bereits in der Entwicklungsumgebung ersichtlich werden. Dies begünstigt zum einen das von der Administration angestrebte Ziel, eine hohe Ausfallsicherheit zu gewährleisten, und auf der anderen Seite wird das Agilitätsziel der Entwicklung erfüllt.[5]

Zusammenfassend sind die Ziele von DevOps wie folgt definiert:

  • effektivere Zusammenarbeit zwischen Development, Operations und dem Qualitätsmanagement
  • Erhöhung der Softwarequalität, durch Nutzung von Dev-Ops Tools wie z.B. Docker oder Vagrant, oder auch automatisierter Tests (Erfüllung hoher Sicherheitsstandards, Funktionalität und Usability) [7]
  • Erhöhung der Geschwindigkeit innerhalb der Entwicklung, begünstig durch Tools wie z.B. Docker, sowie automatisierte Build und Deployment-Prozesse durch z.B. Jenkins
    • Basic Development (Deployment von Neu-Code)
    • Deploying Code in Production [8]
  • Minimieren der Komplexität innerhalb des Deployments und der Builds durch bereits definierte DevOps-Tools [9]

Die aufgeführte Grafik veranschaulicht einen DevOps Lebenszyklus von der Anforderungsdefinition bis zur reellen Implementierung in das Production System und fasst alle bisher benannten Ziele und Anforderungen zusammen.

Den Beginn der Grafik bildet die Abstimmung der Requirements, also die Definition der Anforderungen. Nach Bass sollen hier die Entwickler bereits stark mit in die Entscheidungsfindung und Problemlösung einbezogen werden. Das Development sollte in kleinen Teams mit nur bedingter Bevormundung erfolgen. Des Weiteren sind unit tests zu implementieren, deren Notwendigkeit in Kapitel 3.1.2 erneut aufgegriffen werden. Durch automatisierte Build Prozesse, die automatisiert erfolgen und den continuous integration Ansatz unterstützen, wird die Grundlage zum Deployment geschaffen. Ein nachfolgendes, automatisiertes Testing im Hinblick auf Funktionalität und Usability rundet diesen Schritt ab. Durch den Einsatz eines Toolgesteuerten, automatisierten Deploymentprozesses wird der continuous Integration Ansatz ebenfalls unterstützt und ermöglich ein sauberes Deployment der getätigten Änderungen. Abschließend wird innerhalb der Ausführung ein Monitoring empfohlen, deren Verhalten den Erfolg aufzeigt und im Fehlerfall eine schnelle Behebung unterstützt.

Abb. 1 Prozesse innerhalb des DevOps Lebenszyklus
Abb. 1 Prozesse innerhalb des DevOps Lebenszyklus

2.2 Docker

Docker wurde erstmalig im März 2013 im Hause dotCloud veröffentlicht. Docker macht es möglich, Anwendungen in Containern zu betreiben und damit voneinander zu kapseln. Während dies grundsätzlich auch mit jeder beliebigen Virtualisierungstechnologie (VMWare, KVM, Hyper-V) möglich ist, so bringt Docker entscheidende Vorteile mit.

Abb. 2 Funktionsweise VM
Abb. 2 Funktionsweise VM

Virtualisierungen in Virtual Machines (VMs) haben grundsätzlich den Nachteil, dass jede VM auch ein eigenes Gastbetriebssystem mitbringt, was neben erhöhtem CPU und Arbeitsspeicher-Verbrauch in einem großen Image resultiert. Es ist daher nicht so einfach, eine VM mit jemandem zu teilen.

Dieses Problem löst Docker dadurch, dass sich alle Container einen Kernel teilen und daher lediglich die Anwendung Teil des Containers ist.

Die Grundlage für das Verständnis der Nachfolgend erläuterten Architektur Dockers bildet das folgende Kapitel. Hier wird auf das verfolgte Grundkonzept Dockers eingegangen. Wie Softwareprojekte aufgesetzt werden und wo der Vorteil durch den Einsatz von Docker liegt, wird im Abschließenden Unterpunkt behandelt.

2.2.1 Grundkonzept Docker

Abb. 3 Funktionsweise Docker
Abb. 3 Funktionsweise Docker

“Docker is an open platform for developing, shipping, and running applications” [10]

Docker ermöglicht es, die eigentliche Applikation von der Infrastruktur zu separieren und diese wie eine Managed Application zu behandeln. Das eigentliche DevOps Ziel, schnellere Entwicklungszyklen zu ermöglichen, wird durch Docker ermöglicht. Durch den definierten Einsatzzweck den Code schneller zu delivern, ermöglicht es ein schnelleres, automatisiertes Testing, ein schnelleres deployment und verkürzt somit den Zyklus zwischen der Entwicklung und Implementierung im Produktivsystem.[11]

Dieses Konzept wird durch die Architektur aufgegriffen, die im nächsten Unterpunkt erläutert wird.

Ein weiteres Ziele Dockers ist es, eine Plattform zu schaffen, die es ermöglicht, in einer einheitlichen Entwicklungsumgebung, unabhängig vom verwendeten Endsystem, zu arbeiten. Dies verringert die umgebungsbedingte Fehleranfälligkeit beim deploy in Produktivsysteme, sowie die Einarbeitungszeit neuer Entwickler. Somit wird eine einheitliche Umgebung für alle beteiligten geschaffen, deren Wartung und Weiterentwicklung zentralisiert erfolgt.[11]

Des Weiteren soll der Austausch zwischen bereits fertiggestellten Teilapplikationen gefördert werden. Diese fertigen Container können über Docker Hub geteilt werden. Hierzu wird zunächst ein Image erzeugt, dass wiederum zur Verteilung bereitgestellt wird. Dies ermöglicht es, Ressourcen wiederzuverwenden und den Austausch einmalig erzeugter Container zu fördern. [11]


2.2.2 Docker Architektur

Abb. 4 Docker Architektur
Abb. 4 Docker Architektur

Die obige Grafik veranschaulicht den grundsätzlichen Aufbau der Docker Architektur. Alle nachfolgenden Erläuterungen wurden unter Verwendung der Quelle [11] erstellt.

Docker wird unter der Verwendung einer Client-Server Architektur betrieben. Hierbei spricht der Docker Client den sogenannten Docker Daemon an. Dieser übernimmt die Aufgabe des Controllers und ist dafür zuständig die jeweiligen Anfragen kontrolliert an die Container zu verteilen, sowie gleichzeitig den build- und run- Prozess zu gewährleisten. Docker Client und Daemon können beide auf dem selben System betrieben werden oder auch an einen ausgelagerten Daemon gekoppelt sein. Die Kommunikation zwischen Daemon und Client erfolgt in jedem Fall entweder über Sockets oder die RESTful API. [11]

Um die Architektur zu verstehen, ist zunächst die Klärung wichtiger Begrifflichkeit notwendig, die die obige Grafik veranschaulicht.

  • Docker Daemon
    • Der Docker Daemon stellt eine Umgebung bereit, in der Container gestartet werden können.
    • Die Kommunikation erfolgt hierbei nicht direkt mit dem User, sondern über den zwischengeschalteten Docker Client.
  • Docker client
    • Der Docker Client bildet das Interface zum User ab.
    • Der User hat hier die Möglichkeit, Befehle abzusetzen und so mit dem Daemon zu kommunizieren.

Innerhalb von Dockers Kernel gibt es einige zentrale Begriffe, die nun näher beleuchtet werden.

  • Dockerfile - Build Component
    • Die Dockefile gibt an, wie ein Image gebaut werden kann. Die wichtigsten Befehle sind dabei die folgenden:
      • FROM: ubuntu - gibt an, dass die Basis des zu bauenden Containers auf dem ubuntu Image basiert.
      • RUN echo "Hello World." - RUN führt einen beliebigen Befehl im Container aus und wird meist zur Installation oder Konfiguration der Software genutzt.
      • CMD ./start.bash - CMD gibt an, welcher Befehl beim Start des Containers ausgeführt werden soll.
Abb. 5 Layer-Struktur in Docker
Abb. 5 Layer-Struktur in Docker
  • Image
    • Ein Image ist das Dateisystem eines Containers.
    • Jedes Image besteht aus einer Vielzahl von verschiedenen Schichten, basierend auf einem Union File System. Docker verwendet den sog. "Copy-On-Write"-Ansatz, der dafür sorgt, dass bei einer Schreibaktion im Dockerfile ein neuer Layer angelegt wird, der die Veränderung zum vorherigen Image beinhaltet. Dieser Ansatz hat den Vorteil, dass ein Docker Layer immer sehr klein ist und einfach ausgetauscht bzw. aktualisiert werden kann.
  • Docker Registry - Distribution Component
    • Docker Images können öffentlich oder privat in einer Registry vorgehalten werden. Sie wird als Verteilungskomponente Dockers bezeichnet, da hier der Austausch zwischen fertigen Docker Images erfolgt. Als Beispiel wird hierfür Docker Hub benannt. Images können an eine solche Registry gepullt oder gepusht werden.
    • Durch die Verwendung des Docker Clients können verfügbare Images in das installierte Docker geladen und entsprechende Container erzeugt werden. DockerHub stellt innerhalb des Public Storage frei verfügbare Downloads zur Verfügung. Zur privaten Verwendung mit definierten User Gruppen ist die Verwendung des private storage vorgesehen, der eine entsprechende Zugriffsbeschränkung gewährleistet.
  • Docker Container - Run Component
    • Container können gestartet, gestoppt, verschoben oder gelöscht werden
    • Jeder Container wird als isolierte, sichere Applikationsplattform verstanden
    • Aus diesem Grund werden Docker Container als “run”-Komponente Dockers verstanden
    • Jeder Container wird aus einem Docker Image gebildet und beinhaltet alles, was eine lauffähige Applikation benötigt. Hierzu gehören Zugriff auf den shared Kernel, hinzugefügte Dateien und hinterlegte Meta-Daten. Konfigurationsdaten und Ablaufroutinen innerhalb des Startvorgangs eines solchen Containers werden innerhalb des Docker Images festgehalten.

Weitere Grundlegende mit Docker in Zusammenhang stehende Begriffe sind Docker Swarm und die Docker Machine. Sie stehen nicht in unmittelbarem Zusammenhang mit der Grundlegenden Nutzung Dockers, stellen jedoch im Unternehmensalltag eine gute Realisierbarkeit dar.

  • Docker Swarm - Clustering
    • Überblick
      • Ist eine native clusterlösung Dockers, die es ermöglicht, einen Pool von Hosts in eine nach außen als Einheit Sichtbaren virtuellen Host darzustellen.
      • Jedes Tool, das bereits mit einem Docker Damon kommuniziert, erhält durch Docker Swarm die Möglichkeit des transparenten skalierens. Dies wird durch die Verwendung der Docker standard API sichergestellt. Anwendungen wie z.B. Jenkins, Dokku, Krane werden hier unterstützt.
    • Erzeugen eines Swarm Clusters
      • Zu allererst wird das Docker swarm image geladen. Nach Konfiguration des Swarm Managers und der zugeordneten Nodes, ist dieser bereits lauffähig. Hierzu sind folgende Vorraussetzungen zu schaffen:
        • Öffnen des TCP-Ports der jeweiligen Nodes zur Kommunikation mit dem Swarm Manager.
        • Installation Dockers auf jedem Node.
        • installieren valider TLS Zertifikate um Sicherheit zu gewährleisten
        • Erfahrenen Administratoren und Anwendern wird die manuelle Konfiguration empfohlen. Docker Swarm bietet jedoch zusätzlich die Möglichkeit, einer installation via docker-machine. Dieser nimmt automatisiert Einstellungen vor, die zur Implementierung notwendig sind. Somit is es möglich, innerhalb Cloud basierter Umgebungen, im eigenen Datenzentrum oder auch in virtuellen Boxen eine schnelle und unkomplizierte Implementierung vorzunehmen.
  • Docker Machine
    • Überblick
      • Bietet die Möglichkeit der Installation unter Windows, Mac, AWS oder Digital Ocean
        Abb. 6 Docker Mac / Windows
        Abb. 6 Docker Mac / Windows
      • ermöglicht die Bereitstellung und Verwaltung von mehreren remote gesteuerten Docker hosts
      • stellt Swarm clusters bereit
      • Hierbei werden die hosts mit der Syntax von docker-machine gesteuert
        Abb. 7 Docker auf ausgelagerten Systemen
        Abb. 7 Docker auf ausgelagerten Systemen
      • die standard Kommando CLI wird hierbei, um die Syntax Dockers erweitert. Befehle wie z.B. “docker run hello-world” stehen nun umgebungsunabhängig zur Verfügung
      • ebenso können durch die Installation die Verwaltung mehrerer Docker hosts verwaltet werden. Hierbei ist jede Docker Instanz eine Kombination aus einem Docker Hosts und einem konfigurierten client
    • Der Unterschied zwischen Docker Engine und Docker Machine
      • Docker Engine ist die Komponente, die den Docker Daemon bereitstellt und am Ende die Container ausführt.
      • Abb. 8 Docker Engine Architektur
        Abb. 8 Docker Engine Architektur
      • Docker Machine hingegen bezeichnet ein Tool zur Verwaltung Docker basierter Hosts. Hierbei stehen Befehle der eigenen docker-machine CLI zur Verfügung. Machine ermöglicht es, auf einem oder mehreren virtuellen Systemen die Installation Dockers vorzunehmen - ebenso remote, wie lokal[11].


Nachdem nun grundsätzliche Begriffe erläutert wurden, kann auf die Implementierung Dockers eingegangen werden, nachdem die spezifischen Anforderungen innerhalb von Softwareprojekten erläutert wurden.

3 Anforderungen

Die IT hat mehrere Anforderungen zu erfüllen, diverse Prozesse zu durchlaufen und ein kontinuierliche Kontrolle ihrer Systeme durchzuführen. Sie stellt sich deswegen tagtäglich verschiedenen Problemen und Fehlern [12]. Innerhalb dieser Hausarbeit wird, der übersichthalber, zwischen den Anforderungen innerhalb der Entwicklung und des Betriebes unterschieden. Im Folgenden werden Verfahren und Methoden beschrieben, die erfüllt sein müssen, um eine vollkommende Softwarearchitektur darzustellen, eine permanente Integration von Neuerung innerhalb der Software zu gewährleisten und Problemen in der Software Entwicklung vorzubeugen.

3.1 Innerhalb der Entwicklung

3.1.1 Entwicklung

Bereits in der Entwicklung entstehen sogenannte “Bugs" bei der Softwareerstellung. Diese müssen schnellstmöglich ausgebessert werden, da solche ansonsten im weiteren Verlauf der Systemarchitektur große Probleme und viel Arbeit nach sich ziehen. Deshalb ist es wichtig bereits in einem solch frühen Stadium der Entwicklung auf gewisse Prozesse zu achten und Tests durchzuführen.

  • Platformentwicklung

Die größten Probleme treten durch die Entwicklung und den Betrieb in verschiedenen Umgebungen auf. Innerhalb des Systemmanagements entsteht das Problem, dass bei der Entwicklung nicht die gleichen Umgebungen vorhanden sind sind wie im Produktiv- oder Testingsystem [13]. Dadurch können Fehler nicht direkt erkannt werden und nehmen Zeit in Anspruch. Es muss deshalb schon bei der Entwicklung ein produktivgleiches System genutzt werden, um etwaige Fehler zu vermeiden.

  • Dokumentation

Die Dokumentation spielt in der Entwicklung eine sehr wichtige Rolle, sie dient zur Übersichtlichkeit der Systeme, sowie zur besseren Kommunikation. Die Systemvorraussetzung sowie Metadaten der Produktiv- und Entwicklungsumgebungen müssen dokumentiert und frei zugänglich gemacht werden.

3.1.2 Testing

Eine weitere Anforderung an die Entwicklung ist die Gewährleistung von Sicherheit und minimaler Systemfehler. Um dies erreichen, ist es von Vorteil verschiedene Testing-Methodiken einzusetzen, um die Software kontinuierlich auf Sicherheit und Fehler zu überprüfen. Diese Tests finden sind innerhalb des deployment Prozesses ein wichtiger Bestandteil die sowohl die kontinuierlichen Entwicklung als auch die Softwarebereitstellung betreffen. Der optimal Fall bietet die Möglichkeit, alle Tests automatisiert ohne Personal auszuführen, Protokolle zu erstellen und diese, je nach Themengebiet, sowohl der Entwicklung als auch dem Betrieb zur Verfügung zu stellen [14].

  • Unit Tests

Einer der meist genutzten und bekanntesten Tests sind die Unit Tests. Sie werden von Entwicklern erstellt und bilden den direkten Test für den auszuführenden Code. Für alle Funktionen, die die Software anbietet werden Tests benutzt, um Eingaben zu simulieren, Ergebnisse zu protokollieren und diese zu überprüfen. Die Unit Tests unterstützen somit die Modularität der Software, können jeden Teil des Codes überprüfen und können einfach durchgeführt werden, da sie einen klaren Ablauf haben [15].

  • Integrations Tests

Eine weitere Methode um die Software zu testen die Integrationstests. Eine treffende Definition wurde in dem Buch “Software Reliability” von Myers, 1976 getroffen: “Integration testing is the verification of the interfaces among system parts (modules, components, and subsystems)” [16]. Bei Integrationstests werden mehrere Teile der Software innerhalb eines komplexen Systems getestet. Diese Art von des Test wird durchgeführt, um die Komponenten miteinander zu testen und so die Qualität im Produktivsystem zu gewährleisten [17]. Schnittstellen werden hier gerne in Betracht bezogen, da diese für einen hohen Datenaustausch verantwortlich sind und eine Abhängigkeit somit unverzichtbar ist.

  • Statische Analyse

Die statische Code Analyse ist eine Methode um den Code der Software auf syntaktische Fehler sowie Fehlermuster zu testen. Dabei wird der komplette Code auf diese Fehler durchsucht, aber nicht abgeändert. Diese Methode wird in der Regel automatisch durchgeführt und verschiedene Tools können bereits bei der Entwicklung Anmerkungen aufzeigen. Neuste Tools können außerdem auf qualitative Codepassagen hinweisen wie duplizierten Code, Geschwindigkeitseinbußen oder ähnliches [18].

  • Dynamische Analyse

Eine weitere Analyse um die Software auf Fehler zu überprüfen ist die dynamische Analyse, die sich in Lasttest und Benchmarking aufteilt. Die Verfahren zeichnen sich dadurch aus, das die Software mithilfe von Lauftzeitparametern auf verschiedene Umgebungen und Eingaben des Benutzers getestet werden. Die Lasttest simulieren dabei die erhöhten Zugriffe auf die Software, zum Beispiel auf einem Webserver. Innerhalb dieses Testes werden die Anzahl und das Verhalten der Software protokolliert und anschießend ausgewertet. Das Benchmarking fungiert ähnlich wie der Lasttest, kann aber auch auf Teilprozess oder Komponenten angewendet werden, während sich Lasttest meist auf die komplette Software konzentrieren [19].

  • Nutzer Tests

Des Weiteren existieren Softwaretests, die sich eher auf das Verhalten der Nutzer in Bezug auf die Software konzentrieren. Diese werden in der folgenden Hausarbeit nicht weiter beleuchtet, da diese nicht im direkten Bezug von DevOps und automatisierten Deploymentprozessen stehen.

3.2 Innerhalb des Betriebs

3.2.1 Deployment

Die Veröffentlichung neuer Features in Deploymentsystemen, bilden die Schnittstelle zwischen Entwicklung und Betrieb. Das Ziel des Deployments ist unter anderem eine niedrige Downtime und eine automatisierte, einfache Möglichkeit, um neue Softwareveröffentlichung innerhalb des Produktivsystem zu platzieren. Ein weiter verbreitetes Deployment ist das sogenannte Blue-Green-Deployment. Mithilfe dieses Deployments ist es möglich ,die Downtime auf ein Minimum zu reduzieren. Bei diesem Verfahren werden zwei Produktionssysteme betrieben und am Ende des Deployments leite ein Controller von dem veralteten System auf das neue System um [20]. Der komplette Prozess von der Entwicklung bis hin zum Einsatz im Live System wird auch Deployment Pipeline gennant. Diese ist, wie in dem Zitat von Let Bass et al. beschrieben, die genaue Schnittstelle der Architektur und der angewandten Verfahren von DevOps - “The deployment pipeline is the place where the architectural aspects and the process aspects of DevOps intersect.”[21]. Sie teilte sich in die verschiedenen Phasen der Entwicklungsumgebung, die Continous Integration, betriebsbsnahe Testumgebung und die Betriebsumgebung auf.

Abb. 9 Deployment Pipeline
Abb. 9 Deployment Pipeline
  • Entwicklungs-Umgebung

In der Entwicklungsumgebung werden dann hauptsächlich Unit-Tests, das Debugging der Funktionen und das Profiling durchgeführt. In dieser Umgebung werden alle Neuerungen entwickelt und auf niedrigem Niveau getestet. Anschließend werden die entwickelten Bausteine in die Continous Integration übergeben.

  • Continous Integration

Hier werden die bereits aufgezeigten Tests durchgeführt und die Software auf Richtigkeit geprüft. Bei Fehlern und nicht bestandenen Tests werden diese an die Entwicklung zurückgegeben, um diese auszubessern.

  • Betriebsnahe Testumgebung (Testsystem)

Anschließend wird die Software in eine Betriebsnahe Testumgebung implementiert. Diese zeichnet sich durch die hohe Äquivalenz zu dem Produktivsystem aus. Innerhalb dieser Umgebung können auch Benutzer die Software ausgiebig testen, Lasttests können ausgeführt werden und das System kann überwacht werden.

  • Produktivsystem

In dem letzten Schritt des Deployments wird die Software auf das Produktivsystem verlagert. In diesem Stadium ist eine hohe Fehlerdiagnose von Nöten, eine Überwachung des Systems sollte vorhanden sein. Um eine hohe Elastizität des System zu gewährleisten, ist eine hohe Skalierbarkeit nahezu unvermeidbar [22].

3.3 Release

Am Ende der Deployment Pipeline wird das neue Stücke Software veröffentlicht. Dieser Teil wird auch Software-Release genannt und beschreibt den Zustand, dass alle neuen Features die Deploymet Pipeline durchlaufen haben und nun öffentlich erreichbar sind. In diesem Stadium ist das Deployment abgeschlossen. Darauf folgt das Monitoring und die Überwachung des Systems.

4 Integration von Docker

4.1 Voraussetzungen

Docker benötigt eine 64-bit Linux Umgebung mit einer Mindestversion des Kernels von 3.10 (erschienen am 30.06.2013). Weitere Laufzeit-Voraussetzungen stellen iptables (>=1.4), git (>=1.7), procps (oder ein ähnliches Paket, welches “ps” bereitstellt), xz utils (>=4.9) sowie korrekt konfigurierte cgroupfs[23].

Um Docker auf anderen Betriebssystemen wie Windows oder Mac OS X zu betreiben, wird eine virtuelle Maschine benötigt, welche die oben genannten Anforderungen erfüllt[23].

4.2 Lösungskonzepte

Docker zielt darauf ab, vorgehend im Detail erläuterte Probleme durch einen „Build – Ship – Run“-Approach zu lösen, und dadurch vor allem das Risiko sowie den Arbeitsaufwand von Deployments zu verringern [24].

Ein wichtiger Kern von Docker basiert darauf, dass Container sich nicht selbst verändern, und damit stateless sind. Daten, die in einer bestimmten Session generiert werden und für den Betrieb notwendig sind (zB. der Upload eines Fotos) dürfen nicht direkt im Container gespeichert werden[25]. Dies hat den Vorteil, dass Container jederzeit zerstört und neu erstellt werden können, ohne dass Laufzeitänderungen verloren gehen.

Sollte es notwendig sein, bestimmte Daten sessionübergreifend zu speichern, so sollten Data Volumes genutzt werden[25].

Einige der Lösungskonzepte, die durch Funktionalitäten und Tools von Docker abgedeckt werden, sind im folgenden durch die Verwendung von Beispielen in alltäglichen Szenarien näher dargestellt bzw. erläutert, um den Einsatzzweck bzw. die Notwendigkeit darzustellen.

4.2.1 Data Volumes

Data Volumes sind Verzeichnisse, die dafür geeignet sind, Dateien zu speichern, die entweder über die Lebenszeit eines Containers hinweg, oder in mehreren Containern zeitgleich zur Verfügung stehen. Data Volumes nutzen nicht das sonst von Docker genutzte Union File System, basieren also nicht auf Layern.

  • Data Volumes werden beim Start eines Containers initialisiert
  • Data Volumes können zeitgleich von mehreren Containern genutzt werden
  • Data Volumes basieren nicht auf Layern, Änderungen werden daher ohne Umweg direkt geschrieben
  • Data Volumes werden niemals automatisch gelöscht, auch dann nicht, wenn alle zugehörigen Container gelöscht werden

Der Nachteil an Data Volumes ist, dass die Dateien auf dem Hostsystem liegen; ein Container auf Host A kann also nicht auf das selbe Data Volume zugreifen wie ein Container auf Host B. Doch auch hierfür bietet Docker mit Plugins eine Lösung, in dem es möglich ist NFS, iSCSI und Fibre Channel Laufwerke in Container zu mounten [26].

Eine andere Möglichkeit zum Speichern von Daten ist durch den Einsatz von externen Anbietern wie bspw. AWS S3 oder Google Cloud Storage gegeben. Die Daten werden dann komplett bei einem externen Anbieter gespeichert, so dass man sich auch nicht um die Skalierung des Storagesystems kümmern muss.

4.2.2 Deployment

Grundsätzlich gibt es zwei Möglichkeiten beim Deployment: Entweder der Container wird anhand der Dockerfile live gebaut, oder es wird ein fertig gebautes Image gestartet. Da ein gebauter Container auf jedem Dockersystem lauffähig ist, wird ein Container meist auf einer „Build-Maschine“ gebaut, und dann in ein Repository gepusht.

Der große Vorteil liegt darin, dass der Container inklusive sämtlicher Abhängigkeiten der Applikation bereits vorliegt. Abhängigkeiten, die beim Livedeployment aufgelöst werden, stellen ein großes Risiko dar. Vor einiger Zeit wurden bspw. einige oft genutzte NodeJS Pakete aus den Repositories entfernt [27], was dafür sorgte dass sich davon abhängige Anwendungen nicht mehr bauen ließen. Fällt dieses Problem beim Aktualisieren der Abhängigkeiten während der Entwicklung auf, kann ohne größere Probleme Abhilfe geschaffen werden. Werden diese Abhängigkeiten live beim Deployment geholt, so schlägt mindestens das Deployment fehl und in Folge dessen, je nach Prozess, mit dem Resultat einer Downtime.

Durch das Layer-Konstrukt von Docker Images besteht jedes Images aus mehreren Layern, die je die Änderungen zum vorherigen Layer repräsentieren. Das Verändern eines Containers resultiert daher nur in einem zusätzlichen Layer, welcher diese Änderung beschreibt [28].

Zum Starten eines Containers wird folgender Befehl genutzt:

docker run IMAGE:tag COMMAND

Um einen Container auf Basis des "ubuntu" Images zu starten, und anschließend "Hello world." ausgeben zu lassen, ist demnach der folgende Befehl notwendig:

Abb. 10 Screenshot - Run ubuntu
Abb. 10 Screenshot - Run ubuntu

Da Docker das Image noch nicht lokal vorliegen hatte ("Unable to find image 'ubuntu:latest' locally") hat Docker die hinterlegten Registries abfragt, das Image dort heruntergeladen und anschließend gestartet. Wird der Befehl zu einem späteren Zeitpunkt erneut ausgeführt, so verwendet Docker direkt die bereits existierenden lokalen Images.

Abb. 11 Screenshot - Run ubuntu image exists
Abb. 11 Screenshot - Run ubuntu image exists

Sollte es erwünscht sein, die aktuelle Version des Images zu laden, so kann dies mit dem folgenden Befehl realisiert werden:

Abb. 12 Screenshot - Pull ubuntu
Abb. 12 Screenshot - Pull ubuntu

Anschließend verwendet docker run automatisch die neuere Version, sofern nicht explizit eine bestimmte Version angegeben wird.

4.2.3 Skalierbarkeit

4.2.3.1 Szenario

Die Firma Moebel123 GmbH ist der Möbelbranche tätig und betreibt einen Webshop zum Verkauf ihrer Möbel im Internet. Als Software wird ein bekanntes Shopsystem verwendet und als Produktivserver werden zwei Linuxserver, mit einem LoadBalancer zur Lastverteilung, genutzt. In letzter Zeit schaltet Firma Moebel123 Werbung im Fernsehen und die Besucherzahlen ihres Webshop steigen kurzzeitig in beachtliche Höhen. Die Besucherzahlen steigen teilweise auch so außergewöhnlich hoch, dass die zwei Linuxserver die Zugriffe nicht bearbeiten können und es zu ausbleibenden Responses kommt. Der IT Betrieb will reagiert auf diese Gegebenheit der Werbeschaltungen und hängt kurzfristig neue Server an das System. Dadurch wird eine höhere Rechnerleistung gewährleistet, was die gleichzeitige Bearbeitung mehrerer Besucher ermöglicht. Um Serverkosten zu sparen, soll der Betriebszeitraum jedoch so gering wie möglich gehalten werden. Das Problem dabei ist, dass bei jeder Werbeschaltung mindestens ein Mitarbeiter einen oder mehrere Server konfigurieren, mit an das Netz hängt und somit einen hohen personellen Aufwand verursacht.

4.2.3.2 Lösung

Innerhalb dieses Szenarios können mit der Nutzung eines Loadbalancers und Docker die verfügbaren Resourcen kurzfristig erhöht werden. Ein weiteren Vorteil kann ein Verwaltungssystem bieten, indem es bei einer hohen Auslastung die Docker-Maschinen automatisch startet (zum Beispiel bei einer Auslastung von 80%) und nach Abfall der Besucherzahlen wieder stoppt. Der personelle Aufwand entfällt komplett, da lediglich weitere Container gestartet werden müssen.

Da jeder Container nach dem Docker-Prinzip „immutable“, also unveränderbar, sein sollte, ist sog. Autoscaling relativ einfach zu realisieren, da beim Skalieren, abgesehen von dem sich auf der Registry befindlichen Image, keine weiteren laufzeitgenerierten Daten übertragen werden müssen. Es müssen lediglich ein Loadbalancer, sowie ein Verwaltungssystem eingesetzt werden. Der Loadbalancer reicht den Traffic an X Instanzen weiter, während das Verwaltungssystem die Last auf den einzelnen Docker-Maschinen überwacht und dann je nach Auslastung der Instanzen Container startet oder stoppt.

Zur Registrierung der Worker-Instanzen am Load-Balancer gibt es verschiedene Service-Registration Ansätze:

Entweder der Container registriert sich beim Start vollautomatisch am Load Balancer und steht ihm damit zur Verfügung (und de-registriert sich beim Stop), oder aber die Registrierung wird von der Verwaltungsinstanz übernommen, welche den Start des Containers initiiert.

Des weiteren existieren sogenannte Container Clouds die, begünstigt durch den Einsatz von Docker Swarm, einfach zu implementieren sind. Zahlreiche große Anbieter bieten zur einfacheren Verwendung solche Container Clouds, darunter sind, unteranderem:

  • AWS Elastic Container Cloud
  • Google Container Engine
  • Carina by Rackspace
  • Kubernetes

Durch die weitere Abstrahierung ist es somit jedem Entwickler möglich, komplett ohne Administrationskentnisse eine automatisch skalierende Umgebung aufzubauen.

Am Beispiel von GCE (Google Container Engine, basierend auf Kubernetes) wird einfach ein Load Balancer sowie ein Container Cluster angelegt. Um Kubernetes die Skalierung des Clusters zu übergeben wird einfach Autoscaling aktiviert, sowie min/max Anzahl der Container konfiguriert. Kubernetes übernimmt dann das automatische Starten und Stoppen von Containern basierend auf bspw. dem CPU Auslastung der Container [29]. Auch das zero-Downtime Deployment wird von Kubernetes abstrahiert, in dem bei einem Update ein Container nach dem anderen auf das neue Image aktualisiert wird [30].

4.2.4 Sicherheit

4.2.4.1 Szenario

Die Firma Hosting123 GmbH ist in der Hostingbranche tätig und betreibt verschiedene Contentmanagement- und Shopsysteme für mehrere Kunden. Um an Serverkosten zu sparen, sind auf einem Server immer mehrere Systeme installiert und auf verschiedene Ordner verteilt. Bei einem neuen Software Release der Systeme erneuert ein Mitarbeiter die jeweiligen Versionen der Systeme manuell auf dem Server.

Wenn nun ein sogenannter Exploit, also eine Sicherheitslücke, veröffentlicht wird und damit Dritte Zugriff auf das Dateisystem des Servers bekommen, sind bei der Firma Hosting123 GmbH alle Systeme, die auf dem gleichen Server installiert sind, nicht mehr sicher und sensible Daten könnten gelöscht bzw. ausgelesen werden. Somit ist die Sicherheit aller Kunden auf dem gleichen befindlichen Server nicht mehr gewährleistet und die Firma Hosting123 GmbH kann nicht für eine 100% Sicherheit der Systeme garantieren.

4.2.4.2 Lösung

An dieser Stelle ist es ratsam die Systeme auf den Servern in Docker Container auszulagern, um alle Systeme sauber voneinander zu trennen und eine hohe Sicherheit zu gewährleisten. Denn durch die Docker Container sind die Systeme so kapselt, dass von einem Container nicht auf den ausführenden Server und Services zugegriffen werden kann. Zusätzlich ist es möglich die Resourcen der Kunden so zu beschränken, dass Überlastungen eines einzelnen Kunden andere Kunden nicht betreffen.

Docker Container nutzen die Kernel Namespace Features und starten jeden Container in seinem eigenen Namespace. Dadurch kann ein Container weder Prozesse eines anderen sehen noch verändern. Jeder Container erhält seinen eigenen Netzwerkstack, und kann nur bei entsprechender Konfiguration mit anderen Containern kommunizieren. Ein weiteres Kern-Feature in Bezug auf die Sicherheit sind Control Groups, welches es ermöglichen verfügbare Resourcen wie CPU, Memory und Disk I/O pro Container zu limitieren. Gegen Übergriffe unter verschiedenen Containern ist Docker damit ähnlich gut geschützt wie virtuelle Maschinen – lediglich Kernel-Exploits könnten hier einen Ausbruch ermöglichen. Die mit Abstand größte Gefährdung geht jedoch von Diensten auf dem Hostsystem aus, da von dort aus über den Docker Daemon Zugriff auf alle Container besteht. Es ist daher ratsam, auf dem Hostsystem ausschließlich den Docker Daemon sowie einen SSH-Server zu betreiben und sämtliche anderen Dienste in Container zu verlagern [31].

4.2.5 Employee Onboarding

4.2.5.1 Szenario

Die Firma Apps123 GmbH ist spezialisiert auf verschiedenste Applikationen für mehrere Betriebssysteme. Die Apps123 GmbH führt die zu erstellenden Applikationen immer in Projekten durch und ist dafür bekannt die vorgegebenen Anforderungen schnell durchzuführen. Dementsprechend sind während der Projektphase viele Arbeitskräfte nötig, um die Applikationen in der vorgegebenen Zeit umzusetzen. Die Agentur ist auf Freiberufler angewiesen und muss somit immer neue Mitarbeiter in die Entwicklungsumgebung integrieren. Durch die Konfiguration entsteht viel Zeitaufwand, da die Entwicklungsumgebung erst erklärt und aufgesetzt werden muss. Zu Projektbeginn ist deshalb ein Systemadministrator pro Freiberufler circa 2 Stunden beschäftigt.

4.2.5.2 Lösung

Die Firma Apps123 kann in diesem Szenario durch den Einsatz von Docker die Zeit des Employee Onboardings sehr stark minimieren. Durch die Verwendung von Docker können neue Mitarbeiter schnell und einfach in Projekte integriert werden, ohne viel Zeit mit der Konfiguration zu verbringen.

Docker unterstützt das Employee Onboarding von Programmierern dadurch, dass keine aufwändige Konfiguration von allen Services notwendig ist, sondern nur der Docker Daemon installiert werden und anschließend Container gestartet werden müssen. Sofern das Livesystem auch auf Docker basiert, so sollten die Livecontainer auch zur Entwicklung genutzt werden, so dass das Auftreten des "works-on-my-machine"-Problem auf ein Minimum reduziert werden kann. Inkonsistenzen zwischen dem Entwicklungs- und Livesystem gehören damit der Vergangenheit an. [32]

4.2.6 Platformunabhängigkeit

4.2.6.1 Szenario

Die Firma Software123 GmbH entwickelt Softwarekomponenten für verschiedene Großkunden. Die Kunden brauchen für ihre Systeme Softwarelösungen, die in kleine Komponenten aufgeteilt sind. Die Software123 GmbH entwickelt diese auf ihren Entwicklungsystemen und stellt diese dann dem Kunden bereit, der diese integriert. Getestet wird sowohl auf den lokalen Entwicklungsumgebungen, als auch auf einem Entwicklungsystem. Dadurch, dass auf den Endgeräten der Mitarbeiter aber verschiedene Betriebssysteme installiert sind, lässt sich nicht überall eine produktionssystemnahe Software erstellen. Die Komponenten werden zwar fertig entwickelt, bei der Integration in das Produktivsystem entstehen jedoch Fehler, die während der Entwicklung nicht aufgetreten sind und somit dort nicht reproduziert werden können.

4.2.6.2 Lösung

Mithilfe von Docker kann bei diesem Szenarien sehr viel Zeit beim Integrieren der Softwarekomponenten gespart werden. Docker bietet die Möglichkeit, dass innerhalb der Entwicklung die gleichen Systemvorraussetzungen vorhanden sind wie in dem Produktionssystem. Des Weiteren können automatisierte Tests in einer Umgebung gestartet werden, die auf Basis der Container des Livesystems erstellt wird. Damit lassen sich auch Differenzen zwischen Staging- und Liveumgebung minimieren.

Zur Erleichterung der Benutzung von Docker auf Hostsystemen, die die Anforderungen aus 4.1 nicht direkt erfüllen, stellt Docker mit „docker-machine“ ein Tool bereit, welches den Setup-Prozess einer entsprechend vorkonfigurierten VM in Virtualbox komplett automatisiert. [33]

Docker-Machine provisioniert dazu im Grunde nur eine VM mit vorinstallierter Docker Engine und stellt anschließend sicher, dass alle vom Docker Client benötigten Umgebungsvariablen korrekt gesetzt sind und auf den von der Engine bereitgestellten Daemon in der VM zeigen[33].

Da der Docker Client ausschließlich über eine HTTP API mit dem Daemon kommuniziert, ist es über docker-machine aber nicht nur möglich, einen lokal-virtualisierte Docker Daemon bereitzustellen. Es kann analog auch dazu genutzt werden, den docker Client mit einem Daemon auf einem remote verfügbaren Server zu verknüpfen. Durch die HTTP-Verbindung muss hier sichergestellt sein, dass der remote Daemon die notwendigen Ports bereitstellt[33].

4.2.7 Logging in Docker

Da sämtliche von einem Container zur Laufzeit geschriebenen Daten beim Updaten des Containers verloren gehen, sollten Logdateien nicht im Container selbst gespeichert werden. Auch Data Volumes bieten sich nicht immer an, wenn mehrere Container zeitgleich das selbe Logfile beschreiben möchten. Eine häufige Lösung ist hier ein zentralisiertes Log-Management System, beispielsweise mit einem ELK-Stack.

ELK steht für:

  • Elasticsearch, was die Datenhaltung übernimmt und als Suchserver fungiert
  • Logstash kümmert sich darum, dass die Logfiles eingelesen und in den Suchserver geladen werden
  • Kibana sorgt für die Auswertung bzw. Visualisierung der Logdaten

Die Vorteile eines zentralisierten Log-Management Systems liegen vor allem darin, dass durch Elasticsearch auch große Logmengen schnell durchsucht werden können. In Kombination mit Docker ist es außerdem möglich, die Logdateien von mehreren Containern zeitgleich zu durchsuchen, so dass nicht einzeln jeder Container durchforstet werden muss. Ein weiterer Vorteil liegt darin, dass die Logdateien auch nach einem Austausch des Containers weiter zugänglich sind [34].

Mit Logspout können Logs von Docker direkt an Logstash übergeben werden, über das dann an Elasticsearch geschrieben wird [35]. Es ist lediglich notwendig, dass die Anwendung im Container die Logs an STDOUT bzw. STDERR überträgt [36].

4.2.8 Configuration Management

Ein Problem im DevOps Bereich ist die Dokumentation von Änderungen. Auf Servern, die viele Anwendungen gleichzeitig bereitstellen ist es schwierig, einen Überblick über alles zu haben. Vor allem müssen Änderungen an den Konfigurationen dokumentiert werden.

Docker Images sind immutable und damit nicht veränderbar. Um die Konfiguration zu verändern, muss also die Dockerfile angepasst werden und ein neuer Container gebaut werden. Damit ist sofort auch die Dokumentation über den Konfigurationsstand des Containers vorhanden. Sofern man eine Versionsverwaltung für die Dockerfiles nutzt, auch eine vollwertige History / Versionierung über den Konfigurationsstand.

Zur Dokumentation darüber, welcher Container auf welchem Server gestartet ist, lässt sich Docker mit einem Configuration Management System wie Chef / Puppet kombinieren [37].

5 Anwendung von Docker

5.1 Installation

Docker stellt ein Installationsscript bereit, welches per curl heruntergeladen und dann mit der Shell ausgeführt werden muss. Der Installationsprozess dauert dann höchstens ein paar Minuten. Die einzige zusätzliche Abhängigkeit ist mit „curl“ gegeben, welche jedoch in jeder Minimaldistribution enthalten sein sollte und andernfalls mit einem Einzeiler nachinstalliert werden kann.

$ curl -fsSL https://get.docker.com/ | sh

Zum Test der Konfiguration kann mit folgendem Befehl der „hello-world“ Container gestartet werden:

$ docker run hello-world

[38]

5.2 Konfiguration

5.3 Docker Compose

Docker Container sind grundsätzlich immer nur für eine Aufgabe zuständig. Da Anwendungen jedoch meist aus mehreren Komponenten bestehen, bestehen diese meist aus mehreren Containern.

Ein Webshop besteht heutzutage bspw. möglicherweise aus folgenden Containern, welche je ein- oder mehrfach vorhanden sein können:

  • Load Balancer
  • Webserver
  • Datenbank
  • Storage (Artikelbilder o.Ä.)
  • Cacheserver
Abb. 13 Beispiel einer docker-compose.yml
Abb. 13 Beispiel einer docker-compose.yml

Damit beim Deployment nicht alle Container einzeln gestartet werden müssen, stellt Docker mit docker-compose eine Lösung zum Starten von multi-container Anwendungen bereit. Die Konfiguration der einzelnen Services wird dafür in einer docker-compose.yml Datei im Projekt beschrieben, die im Beispiel so aussehen könnte:

Statt „docker run“ direkt auszuführen wird dann „docker-compose up“ gestartet.

6 Zusammenfassung

6.1 Fazit

Abschließend ist zu sagen, dass der Einsatz von DevOps mittlerweile in Betrieben, die einen Entwicklungs- und einen Betriebsbereich haben, unverzichtbar ist. Die Methoden und Tools, die die DevOps für die Koordination und das Deployment benutzen sind sehr hilfreich bei der Zusammenarbeit von Teams und der Veröffentlichung von neuer Software.

Die Analyse von Docker im Bezug auf DevOps hat ergeben, dass Docker verschiedene Probleme wie Skalierbarkeit, Sicherheit und Plattformunabhängigkeit beseitigen kann und somit ein interessante und empfehlenswerte Software für DevOps darstellt. Auch die Automatisierung und die Konfiguration von Serverkomponenten kann optimal mit Docker abgebildet werden. Da Docker schnell und einfach benutzt werden kann ist es eine Software, die bereits in vielen Unternehmen zum Einsatz kommt und durchaus zu empfehlen ist.

Schlussendlich ist Docker aber nur eines von vielen Tools, dass den DevOps dabei hilft die Teams bei der Entwicklung und im Betrieb zu unterstützen. Docker allein ist nicht die vollkommene Lösung für den optimalen Deploymentprozess, es werden weitere Tools wie Jenkins und Vagrant empfohlen um die Veröffentlichung von Software Releases zu erhöhen und zu beschleunigen.

6.2 Ausblick

Docker ist eine Software, die durch ihre große Community profitiert. Es werden regelmäßig Sicherheitsupdate erstellt und die Software wird kontinuierlich weiterentwickelt. Dadurch lässt sich abschließend sagen, dass die Software in der Zukunft immer mehr an Bedeutung gewinnen und durch die Weiterentwicklung vermutlich noch mehr Themengebiete abdecken wird.

7 Fußnoten

  1. Vgl. Hasselbring (2015)
  2. Vgl. Peschlow (2012)
  3. 3,0 3,1 Vgl. Bass et al. (2015), Seite 39
  4. Vgl. Bass et al. (2015), Seite 68 ff.
  5. 5,0 5,1 5,2 Vgl. Bass et al. (2015), Seite 45 ff.
  6. Hasselbring (2015)
  7. Vgl. Bass et al. (2015), Seite 40
  8. Vgl. Bass et al. (2015), Seite 41
  9. Vgl. Bass et al. (2015), Seite 37
  10. Docker Architecture (2016)
  11. 11,0 11,1 11,2 11,3 11,4 11,5 Vgl. Docker Architecture (2016)
  12. IT Management Präsentation und Vorlesung FOM - Dörte Jaskotka
  13. Vgl. Heinlein (2011)
  14. Vgl. Hamill (2005)
  15. Vgl. Fowler (2007)
  16. Myers (1976)
  17. Vgl. Myers (1979)
  18. Vgl. Rixner (2009)
  19. Sneed et al. (2009)
  20. Vgl. Fowler (2010)
  21. Bass et al. (2015)
  22. Vgl. Hasselbring (2016)
  23. 23,0 23,1 Vgl. Docker Installing Binaries (2016)
  24. Vgl. What is Docker (2016)
  25. 25,0 25,1 Vgl. Mike Metral (2015)
  26. Vgl. Docker Volumes (2016)
  27. Vgl. npm (2016)
  28. Vgl. Docker Images Containers (2016)
  29. Vgl. Kubernetes Autoscale (2016)
  30. Vgl. Kubernetes Updates (2016)
  31. Vgl. Docker Security (2016)
  32. Vgl. But It Works on My Machine!
  33. 33,0 33,1 33,2 Vgl. Docker Machine (2016)
  34. Vgl. Nathan LeClaire (2015)
  35. Vgl. Gilder Labs (2016)
  36. Vgl. Docker Logs (2016)
  37. Vgl. Docker using Chef (2016)
  38. Vgl. Docker Linux (2016)

8 Verzeichnisse

8.1 Abkürzungverzeichnis

BegriffBeschreibung
RESTful Representational State Transfer
API Application Programming Interface
VM Virtual Machine
CMD Command line interface
HTTP Hypertext Transfer Protocol
iSCSI internet Small Computer System Interface
CLI Command Line Interface
SSH Secure Shell

8.2 Literaturverzeichnis

Peschlow (2012) Patrick Peschlow (2012): "Die DevOps-Bewegung. Was ist das eigentlich und was bedeutet es für uns?" In: Javamagazin 1.2012. codecentric AG
Hasselbring (2015) Wilhelm Hasselbring (2015): "DevOps. Softwarearchitektur an der Schnittstelle zwischen Entwicklung und Betrieb". URL: http://eprints.uni-kiel.de/29215/1/2015-07-10Architekturen.pdf, Abruf am 16.05.2016 (PDF; 2.614 KB).
Heinlein (2011) Heinlein (2011): "DevOps: Neue Arbeitsweise und Selbstverständnis in der IT". URL: https://www.heinlein-support.de/slac/2011/vortrag/devops-neue-arbeitsweise-und-selbstverstaendnis-in-der-it, Abruf am 18.05.2016
Hamill (2005) Paul Hamill (2005): "Unit Test Frameworks". S. 2-5
Fowler (2007) Martin Fowler (2007): "Mocks Aren’t Stubs". URL: http://martinfowler.com/articles/mocksArentStubs.html, Abruf am 18.05.2016
Myers (1976) G.J. Myers (1976): "Software Reliability" John Wiley & Sons, New York
Myers (1979) G.J.Myers (1979): "The Art of Software Testing" John Wiley & Sons, New York
Rixner (2009) Philipp Rixner (2009): "Was ist statische Code Analyse?". URL http://www.fh-wedel.de/~si/seminare/ws08/Ausarbeitung/11.ca/codeanalyse.html, Abruf am 18.05.2016
Sneed et al. (2009) Harry Sneed, Manfred Baumgartner, Richard Seidl: "Der Systemtest - Von den Anforderungen zum Qualitätsnachweis". 3. Aufl. Carl Hanser Verlag, 2011, ISBN 978-3-446-42692-4.‌
Fowler (2010) Fowler, Martin (2010): "BlueGreenDeployment". URL http://martinfowler.com/bliki/BlueGreenDeployment.html, Abruf am 19.05.2016
Bass et al. (2015) Len Bass, Ingo Weber, Liming Zhu (2015): “DevOps: A Software Architect’s Perspective”, Addison-Wesley 2015, ISBN 978-0-13-404984-7
Hasselbring (2016) Wilhelm Hasselbring (2016): "Microservices for Scalability". URL: https://icpe2016.spec.org/fileadmin/user_upload/documents/icpe_2016/ICPE2016keynote_WillyHasselbring.pdf, Abruf am 19.05.2016 (PDF; 2.465 KB).
Docker Survey (2016) The Docker Survey (2016): "Evolution of the Modern Software Supply Chain". URL https://goto.docker.com/Docker-Survey-2016.html, Abruf am 19.05.2015 (PDF; 501 KB)
Docker Architecture (2016) Docker, Inc. (2016): "Understand the architecture", https://docs.docker.com/engine/understanding-docker/, Abruf 22.05.2016
Docker Installing Binaries (2016) Docker, Inc. (2016): "Installation from Binaries", https://docs.docker.com/engine/installation/binaries/, Abruf 03.05.2016
Docker Machine (2016) Docker, Inc. (2016): "Docker Machine", https://docs.docker.com/machine/, Abruf 03.05.2016
What is Docker (2016) Docker, Inc. (2016): "What is Docker ?", https://www.docker.com/what-docker, Abruf 03.05.2016
Mike Metral (2015) Mike Metral (2015): "Docker best practices: data and stateful applications". URL https://getcarina.com/docs/best-practices/docker-best-practices-data-stateful-applications/, Abruf 03.05.2016
npm (2016) npm, Inc (2016): "kik, left-pad, and npm". URL http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm, Abruf 03.05.2016
Docker Images Containers (2016) Docker, Inc. (2016): "Understand images, containers, and storage drivers". URL https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/, Abruf 14.05.2016
Docker Security (2016) Docker, Inc. (2016): "Docker Security". URL https://docs.docker.com/engine/security/security/, Abruf 14.05.2016
Kubernetes Autoscale (2016) Kubernetes (2016), "kubectl autoscale". URL http://kubernetes.io/docs/user-guide/kubectl/kubectl_autoscale/, Abruf 14.05.2016
Kubernetes Updates (2016) Kubernetes (2016), "Rolling update". URL http://kubernetes.io/docs/user-guide/rolling-updates/, Abruf 14.05.2016
Docker Linux (2016) Docker, Inc. (2016): "Install Docker". URL https://docs.docker.com/linux/step_one/, Abruf 14.05.2016
Docker Volumes (2016) Docker, Inc. (2016): "Manage data in containers". URL https://docs.docker.com/engine/userguide/containers/dockervolumes/, Abruf 15.05.2016
Nathan LeClaire (2015) Nathan LeClaire. (2015): "Automating Docker Logging: ElasticSearch, Logstash, Kibana, and Logspout". URL http://nathanleclaire.com/blog/2015/04/27/automating-docker-logging-elasticsearch-logstash-kibana-and-logspout/, Abruf 17.05.2016
Docker Logs (2016) Docker, Inc. (2016): "Logs". URL https://docs.docker.com/engine/reference/commandline/logs/, Abruf 17.05.2016
Gilder Labs (2016) Glider Labs (2016): "Logspout". URL https://github.com/gliderlabs/logspout, Abruf 17.05.2016
Docker using Chef (2016) Docker, Inc. (2016): "Using chef". URL https://docs.docker.com/engine/admin/chef/, Abruf 17.05.2016

8.3 Tabellenverzeichnis

8.4 Abbildungverzeichnis

Abb.-Nr.AbbildungQuelle
1Prozesse innerhalb des DevOps LebenszyklusBass et al. (2015), Seite 48
2Funktionsweise VMWhat is Docker ? (2016)
3Funktionsweise DockerWhat is Docker ? (2016)
4Docker ArchitekturDocker Architecture (2016)
5Layerstruktur von DockerDocker Images Containers (2016)
6Docker Mac / WindowsDocker Machine (2016)
7Docker auf ausgelaerten SystemenDocker Machine (2016)
8Docker Engine Architektur von DockerDocker Machine (2016)
9Deployment PipelineHasselbring (2015), Folie 9
10Screenshot - Run ubuntu
11Screenshot - Run ubuntu image exists
12Screenshot - Pull ubuntu
13Beispiel einer docker-compose.yml

9 Anhänge

Persönliche Werkzeuge