DevOps propagiert einen Paradigmenwechsel: Softwareentwicklung und Betrieb arbeiten nicht gegeneinander, sondern miteinander. Dabei gewinnt Continuous Delivery zunehmend an Bedeutung.
Continuous Delivery (kontinuierliche Auslieferung/Übergabe) bezeichnet in der Softwareentwicklung eine Sammlung von Techniken, Prozessen und Werkzeugen, welche kurze Entwicklungszyklen mit häufigen Softwareupdates bis hin zum produktiven System ermöglicht. Dies wird ermöglicht durch eine weitgehend automatisierte "Delivery Pipeline" / "Deployment Pipeline" mit automatisierten Build-Prozessen, Auslieferungen, Installationen, Tests (Continuous Integration) und Deployments. Dabei werden häufig Virtualisierungslösungen eingesetzt, wie beispielsweise Docker.
Die folgenden Erläuterungen sind nur kurze Erinnerungsstützen und keine exakten Definitionen.
Scrum und Kanban sind die beiden wichtigsten Vorgehensmodelle für agile Softwareentwicklung.
Während Scrum beispielsweise durch das Time-Boxing und durch die Scrum-Rollen eine festgelegte Struktur definiert, ist Kanban flexibler, reaktionsschneller, fokussiert besser auf einzelne wichtige Features und passt so besser zu Continuous Delivery.
Siehe hierzu: Scrum, Kanban / Continuous, Kanban: Moving toward continuous delivery (Dan Radigan), Scrum Versus Kanban (Vandana Roy), So Long Scrum, Hello Kanban (Alex Salazar), What is Kanban?, Scrum vs Continuous Deployment (Matthias Marschall).
DevOps (Development + Operations):
DevOps vereint Development (= Entwicklung) und Operations (= Betrieb) und bezeichnet eine Organisationsform und einen Paradigmenwechsel: Entwicklung und Betrieb sind nicht wie früher getrennt, sondern arbeiten sehr eng zusammen. DevOps und Continuous Delivery verfolgen ähnliche Ziele und profitieren gegenseitig voneinander.
Siehe hierzu: DevOps bei Wikipedia, DevOps in Unternehmen etablieren (Jürgen Rühling), Die DevOps-Bewegung (Patrick Peschlow), What Is DevOps?.
Delivery Pipeline / Deployment Pipeline:
Der gesamte Prozess und zeitliche Ablauf vom Einchecken des Sourcecodes in das Versionskontrollsystem bis zur Inbetriebnahme in Produktion wird als Delivery Pipeline oder Deployment Pipeline bezeichnet.
Die einzelnen mehr oder weniger automatisiert nacheinander ausgeführten Schritte in der Pipeline können beispielsweise sein:
Dabei können die verschiedenen Testumgebungen dauerhaft eingerichtet sein oder für jeden Testlauf (automatisiert skriptgesteuert als "Infrastructure as Code") neu installiert werden, oder es werden entsprechende vorbereitete VMs oder Container gestartet.
Bei Fehlern während der Ausführung der Pipeline wird die Pipeline abgebrochen und der Entwickler erhält Feedback.
In Continuous-Integration-Systemen (CI) wird aus dem in das Versionskontrollsystem eingecheckten Sourcecode automatisch deploybare Software gebaut und zusammengestellt, die in einer Testumgebung deployt wird, in der dann automatisch Integrationstests ausgeführt werden. Im Falle eines Fehlers erhalten die Entwickler so sehr schnell Feedback.
Die Steuerung dieser Vorgänge übernimmt ein Continuous Integration Server wie z.B. Jenkins, Hudson, Go, Bamboo oder TeamCity.
Siehe auch: Continuous Integration bei Wikipedia und Continuous Integration (Martin Fowler).
Continuous Delivery (kontinuierliche Auslieferung/Übergabe):
Continuous Delivery ist eine Methodik, die eine Sammlung von Techniken, Prozessen und Werkzeugen beinhaltet, welche kurze Entwicklungszyklen mit häufigen Softwareupdates bis hin zum produktiven System ermöglicht (z.B. mehrmals pro Tag). Dies wird ermöglicht durch eine weitgehend automatisierte "Continuous Delivery Pipeline" / "Continuous Deployment Pipeline", also einen automatisierten Workflow mit Build-Prozessen, Auslieferungen, Installationen, Tests und Deployments.
Vorteile sind:
Siehe auch: Continuous Delivery bei Wikipedia, Continuous Delivery (Martin Fowler), Continuous Delivery (Eberhard Wolff).
Während bei "Continuous Delivery" möglichst alle Schritte außer dem Deployment in Produktion automatisiert ablaufen, wird beim "Continuous Deployment" auch dieser letzte Schritt vollautomatisch ausgeführt. Beim "Continuous Delivery" entscheidet ein Mensch, ob die neu gebaute Version in den Produktionsbetrieb übernommen wird. Beim "Continuous Deployment" geht jede erfolgreich gebaute Version automatisch in Produktion.
Siehe auch: Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment und Continuous Delivery / Deployment (Martin Fowler).
Infrastrukturautomatisierung: Installationen werden automatisch per Skript eingerichtet. Die Skripte können in einem Versionskontrollsystem verwaltet werden.
Beispiele für Tools für "Infrastructure as Code": Docker, Vagrant, Chef, Puppet, SaltStack, Ansible.
Das Konfigurationsmanagementtool ("KM-Tool") Vagrant unterstützt "Infrastructure as Code". Installationen (z.B. Testumgebungen) werden automatisch und reproduzierbar mit einfachen Skripten eingerichtet, üblicherweise in "virtuellen Maschinen (VM)" oder in "Docker-Containern" (s.u.). Die Skripte ("Vagrantfiles") können in einem Versionskontrollsystem verwaltet werden. Vagrant verwendet eine Ruby-DSL. Vagrant kann mit Chef oder Puppet kombiniert werden: Dann steuert Vagrant die VMs bzw. Container und Chef oder Puppet führen innerhalb der VMs und Container die Installationen aus.
Weiter unten finden Sie das einfache Einsteigerbeispiel MeinVagrantTomcat, bei dem per Vagrant mit wenigen Skriptzeilen mit VirtualBox eine VM mit Ubuntu-Linux, Java und einem Tomcat-Server eingerichtet und gestartet wird, in der eine einfache Hello-World-Webanwendung deployt und ausgeführt wird, die vom Host aus erreichbar ist.
Siehe auch: Vagrant-Homepage, Vagrant Boxes and Plugins, Vagrant Boxes bei HashiCorp, Vagrant und Docker (Golo Roden), Vagrant bei Wikipedia.
Das Konfigurationsmanagementtool Chef realisiert "Infrastructure as Code". Installationen werden automatisch per Skript eingerichtet. Die Skripte ("Recipes", organisiert in "Cookbooks") können in einem Versionskontrollsystem verwaltet werden. Chef verwendet eine Ruby-DSL. Chef unterscheidet zwischen "Resources" (alles Konfigurierbare und Installierbare), "Policies" (definieren die Beschaffenheit von Resources) und "Providers" (ermitteln und ändern den Zustand von Resources).
Während Chef prozedural arbeitet, setzt Puppet auf einen deklarativen Ansatz.
Siehe auch: Chef-Homepage, Learn Chef, "Infrastructure as Code" mit Chef (Martin Eigenbrodt), Chef-Cookbooks, Chef bei Wikipedia.
Das Konfigurationsmanagementtool Puppet realisiert "Infrastructure as Code". Installationen werden automatisch per Skript eingerichtet. Die Skripte ("Puppet manifests") können in einem Versionskontrollsystem verwaltet werden. Puppet verwendet eine Ruby-DSL und JSON-Datenstrukturen.
Während Chef prozedural arbeitet, setzt Puppet auf einen deklarativen Ansatz.
Siehe auch: Puppet-Homepage, Learning Puppet, Puppet bei Wikipedia.
Eine virtuelle Maschine ist die Simulation/Emulation eines anderen Rechnersystems auf einem Rechner. Zwischen dem Host-Rechner und dem virtuellen Gast-Rechner befindet sich ein Hypervisor als Abstraktionsschicht, welcher die Gast-Rechnerumgebung simuliert. Der Host und der Gast können mit verschiedenen Betriebssystemen betrieben werden. Es kann sogar eine völlig andere Hardware und CPU simuliert werden, was allerdings selten genutzt wird. Es können mehrere VMs auf einem Host betrieben werden.
Vorteile von VMs sind:
Siehe auch: Virtuelle Maschine bei Wikipedia.
Alternativ zu VMs gibt es "Container", z.B. die Docker Container (siehe unten).
Ein Hypervisor, auch Virtual Machine Monitor (VMM) genannt, bildet die Abstraktionsschicht, welche auf einem Host-Rechner Gast-VMs zur Verfügung stellt. Dabei werden von einigen Hypervisors sowohl als Host-Betriebssystem als auch als Gast-Betriebssystem viele Varianten von Windows, Linux und Mac OS sowohl in 32 bit als auch in 64 bit unterstützt.
Es wird zwischen zwei Hypervisor-Typen unterschieden:
Siehe auch: Hypervisor bei Wikipedia.
Alternativ zum Hypervisor-Konzept gibt es die "Operating-system-level Virtualization", z.B. mit Docker (siehe unten).
Oracle VirtualBox ist ein Typ-2-Hypervisor (hosted) und bietet Virtualisierung für verschiedene Betriebssysteme. Sowohl als Host-Betriebssystem als auch als Gast-Betriebssystem können viele Varianten von Windows, Linux und Mac OS sowohl in 32 bit als auch in 64 bit eingesetzt werden. Auf einem Rechner können mehrere VirtualBox-VMs gleichzeitig betrieben werden, begrenzt durch RAM-Speicher und Festplattenplatz.
VirtualBox bietet z.B.: Speicherung und Wiederherstellung von VMs per Snapshot, Cloning von VMs, Import und Export per Standard Open Virtualization Format (OVF), USB Support, Remote Display (VRDP, RDP).
Weiter unten finden Sie das einfache Einsteigerbeispiel MeinVagrantTomcat, bei dem per Vagrant eine VM mit VirtualBox eingerichtet und gestartet wird. Außerdem verwenden auch die auf Docker Toolbox basierenden Docker-Beispiele implizit VirtualBox.
Siehe auch: VirtualBox-Homepage, VirtualBox User Manual, VirtualBox bei Wikipedia.
Docker ist eine Virtualisierungslösung, die keinen Hypervisor einsetzt, sondern "Operating-system-level Virtualization" (= "Betriebssystemvirtualisierung") verwendet. Anders als die VM/Hypervisor-Lösungen zur Virtualisierung bietet Docker keine vollständige Virtualisierung in VMs, sondern stattdessen Linux-Container (per LXC oder Libcontainer, sowie chroot, Namespaces, Cgroups). Diese Container sind unabhängig voneinander, aber verwenden Teile des Linux-Kernels gemeinsam. Dadurch ist die Effizienz wesentlich höher als bei anderen Virtualisierungslösungen. Auf einer Hardware können wesentlich mehr Docker-Container betrieben werden als VMs.
Anders als VM/Hypervisor-Lösungen war Docker bis April 2016 auf Linux als Host-Basis angewiesen.
Auf Windows und Mac OS X konnte es nur mit einem zusätzlichen Linux-Layer installiert werden,
z.B. per Docker Toolbox
(enthält Boot2Docker und
Oracle VirtualBox).
Ähnliches gilt für das Gast-Betriebssystem: Nur Linux ist möglich. Der Gast verwendet den Linux-Kernel des Hosts.
Seit April 2016 gibt es Beta-Versionen von Docker for Mac and Docker for Windows, die als native Anwendungen laufen und ohne VirtualBox auskommen. Die Docker-Engine läuft unter einem Alpine-Linux auf einer virtuellen Maschine (Hyper-V bei Windows und xhyve in OS X).
Wichtige Elemente von Docker sind:
Vorteile von Docker sind (teilweise ähnlich wie für VMs):
In Docker.html finden Sie mehrere einfache Einsteigerbeispiele, bei denen per Docker Toolbox und Docker mit wenigen Skriptzeilen ein Docker-Container mit Linux, Java und einem Tomcat- oder WebLogic-Server eingerichtet und gestartet wird, in dem eine einfache Hello-World-Webanwendung deployt und ausgeführt wird, die vom Host aus erreichbar ist.
Siehe auch: Docker-Homepage, Docker-Tutorial, Docker User Guide, Understanding Docker, Docker bei Wikipedia, XWiki zu Docker, Docker Toolbox, Anwendungen mit Docker transportabel machen (Golo Roden), Mit Docker automatisiert Anwendungscontainer erstellen (Golo Roden), Renaissance der Container-Virtualisierung mit Docker (Martin Loschwitz), Docker: die Linux-Basics unter der Container-Haube (Brunk + Albert + Magnus), Getting to know Docker – a better way to do virtualization? (Mark Nelson).
Docker konkurriert mit dem auf App Container (appc) basierendem Rocket (rkt).
Amazon bietet verschiedene Dienste an, die sowohl Continuous Delivery wie auch den Produktivbetrieb effektiv unterstützen können:
Weitere im Zusammenhang mit Continuous Delivery wichtige Themen und Technologien:
Twelve-Factor App, Microservices im Zusammenspiel mit Continuous Delivery (Eberhard Wolff), Micro-Services mit Docker (Phillip Ghadir), Web-Apps in Docker-Umgebungen (Phillip Ghadir), Docker Microservice Basis mit Apache Tomcat (Roßbach + Schmidt), PaaS mit Red Hat OpenShift, PaaS mit Google App Engine (GAE/J), Git, GitHub, Gradle, Maven, Nexus, Artifactory, Jenkins, SonarQube, JBehave, Selenium, Gatling, ELK-Stack (Elasticsearch + Logstash + Kibana)
Als minimales Demobeispiel wird im Folgenden gezeigt, wie mit sehr wenigen Skriptzeilen eine einfache "Hello World"-Java-Webanwendung ("WAR") in einer VM installiert und gestartet werden kann.
Das Beispiel geht davon aus, dass als Host-Betriebssystem Windows verwendet wird. Es ist aber mit geringfügigen Anpassungen ebenso unter Linux und Mac OS X verwendbar.
Verwendet werden:
Führen Sie folgende Schritte durch:
Sehen Sie sich weiter oben die Erläuterungen an zu: Vagrant und VirtualBox.
Ein aktuelles
Java SE JDK und
Maven
müssen installiert sein.
Am besten installieren Sie auch einen
Git-Client,
den Sie früher oder später ohnehin benötigen werden, denn dann ist sichergestellt,
das ssh.exe zur Verfügung steht.
Stellen Sie sicher, dass nicht nur der cmd-Pfad zu git.exe, sondern auch der bin-Pfad zu ssh.exe
in der PATH-Environmentvariable eingetragen ist.
Überprüfen Sie:
java -version
javac -version
mvn -v
git --version
ssh
Downloaden Sie
VirtualBox 5.0.12 for Windows hosts (x86/amd64)
und führen Sie VirtualBox-5.0.12-104815-Win.exe aus.
Sehen Sie sich das VirtualBox User Manual an.
Überprüfen Sie:
"C:\Program Files\Oracle\VirtualBox\VBoxManage" -v
"C:\Program Files\Oracle\VirtualBox\VirtualBox"
Downloaden Sie
Vagrant Windows Universal (32 and 64-bit)
und führen Sie vagrant_1.7.4.msi aus.
Als Installationszielverzeichnis können Sie z.B. D:\Tools\Vagrant oder ein anderes Verzeichnis angeben.
Das Vagrant-bin-Verzeichnis wird in den PATH übernommen.
Sehen Sie sich an: Vagrant Getting Started.
Überprüfen Sie:
vagrant -v
vagrant
Sie können eine beliebige Webanwendungs-WAR-Datei deployen. Für dieses simple Beispiel wechseln Sie in ein beliebiges Projekte-Workspace-Verzeichnis (z.B. \MeinWorkspace) und erzeugen folgendermaßen mit Maven eine "Hello World"-WAR:
cd \MeinWorkspace
mvn archetype:generate -DinteractiveMode=false -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=de.meinefirma.meinprojekt -DartifactId=MeinVagrantTomcat
cd MeinVagrantTomcat
mvn package
dir target\*.war
Testen Sie, ob der gewünschte Port noch nicht anderweitig belegt ist:
netstat -an | find ":18080"
Erzeugen Sie im MeinVagrantTomcat-Projektverzeichnis die Skriptdatei: Vagrantfile
Vagrant.configure("2") do |config| config.vm.box = "ubuntu/trusty64" config.vm.network "forwarded_port", guest: 8080, host: 18080 config.vm.network "forwarded_port", guest: 8081, host: 18081 config.vm.provision "shell", path: "install_webapp.sh" end
Siehe hierzu die Vagrantfile-Doku. Statt "ubuntu/trusty64" können Sie auch eine andere Ubuntu-Box als Ausgangsbasis wählen, siehe Ubuntu-Boxen.
Erzeugen Sie im MeinVagrantTomcat-Projektverzeichnis die Skriptdatei: install_webapp.sh
#!/bin/sh apt-get update apt-get dist-upgrade -y apt-get install -y openjdk-7-jre-headless apt-get install -y tomcat7 cp /vagrant/target/MeinVagrantTomcat.war /var/lib/tomcat7/webapps/
Siehe hierzu die Ubuntu-apt-get-Doku und Debian-apt-get-Doku.
Sehen Sie sich die Verzeichnisstruktur an:
tree /F
Sie erhalten:
[\MeinWorkspace\MeinVagrantTomcat] |- [.vagrant] | '- ... |- [src] | '- [main] | '- [webapp] | |- [WEB-INF] | | '- web.xml | '- index.jsp |- [target] | |- MeinVagrantTomcat.war | '- ... |- install_webapp.sh |- pom.xml '- Vagrantfile
Führen Sie im MeinVagrantTomcat-Projektverzeichnis aus:
vagrant up
start http://localhost:18080
start http://localhost:18080/MeinVagrantTomcat
--> Sie erhalten die gewünschte "Hello World"-Webseite.
Mit vagrant halt können Sie Tomcat und die VM herunterfahren.
Mit vagrant destroy können Sie die VM komplett entfernen.
Sehen Sie sich auf der
Vagrant-Teardown-Dokuseite
die drei Optionen suspend, halt und destroy an.
Das "vagrant up"-Kommando dauert beim ersten Mal recht lange wegen der Downloads. Die folgenden Aufrufe gehen wesentlich schneller. Sehen Sie sich Ihre "VM-Boxen" an:
dir "C:\Users\%USERNAME%\.vagrant.d\boxes"
dir "C:\Users\%USERNAME%\VirtualBox VMs"
Kurzes Resümee:
vagrant ssh
Und testen Sie die üblichen Ubuntu-Linux-Shell-Kommandos, beispielsweise: help, dpkg -l, printenv, pwd, ls -la, ls /vagrant, ls /etc, ls /etc/profile.d, cat /etc/profile.d/vagrant_ruby.sh, echo $PATH, df, du -ah, free, ps -l, ps -f, ps -ef | grep -i MeinProgramm, pstree, exitAls minimales Demobeispiel wird im Folgenden gezeigt, wie mit sehr wenigen Skriptzeilen eine einfache "Hello World"-Java-Webanwendung in einem Docker-Container installiert und gestartet werden kann.
Das Beispiel geht davon aus, dass als Host-Betriebssystem Windows verwendet wird. Es ist aber auch an Mac OS X und Linux anpassbar.
Verwendet werden:
Führen Sie folgende Schritte durch:
Sehen Sie sich weiter oben die Erläuterungen an zu: Docker und Docker Toolbox.
Ein aktuelles
Java SE JDK,
Maven und ein
Git-Client
müssen installiert sein, letzteres damit ssh.exe zur Verfügung steht.
Stellen Sie sicher, dass nicht nur der cmd-Pfad zu git.exe, sondern auch der bin-Pfad zu ssh.exe
in der PATH-Environmentvariable eingetragen ist.
Überprüfen Sie:
java -version
javac -version
mvn -v
git --version
ssh
Sie können VirtualBox gemeinsam mit der Docker Toolbox installieren.
Empfehlenswerter ist jedoch, VirtualBox separat vorher zu installieren.
Downloaden Sie
VirtualBox 5.0.12 for Windows hosts (x86/amd64)
und führen Sie VirtualBox-5.0.12-104815-Win.exe aus.
Sehen Sie sich das VirtualBox User Manual an.
Überprüfen Sie:
"C:\Program Files\Oracle\VirtualBox\VBoxManage" -v
"C:\Program Files\Oracle\VirtualBox\VirtualBox"
Downloaden Sie die Windows-Variante der
Docker Toolbox,
z.B. in Version 1.9.1f.
Führen Sie DockerToolbox-1.9.1f.exe aus, und deaktivieren Sie während der Installation die beiden Installationsoptionen VirtualBox und Git.
Sehen Sie sich an: Docker-Toolbox-Installation.
Überprüfen Sie:
docker-machine -v
docker-machine
docker -v
docker
Überprüfen Sie, ob die VM "docker-vm" bereits existiert:
docker-machine ls
Falls sie noch nicht existiert, erzeugen Sie für Docker die VM "docker-vm":
docker-machine create --driver virtualbox docker-vm
docker-machine ls
docker-machine stop docker-vm
Erzeugen Sie zum Starten der Docker Machine beispielsweise im Verzeichnis \MeinWorkspace\MeinDockerMachine folgende Batchdatei: docker-machine-start.bat
docker-machine ls docker-machine start docker-vm docker-machine env --shell cmd docker-vm | find "DOCKER_" > docker-machine-env.bat call docker-machine-env.bat set DOCKER docker images docker ps -a
Testen Sie, ob die benötigten Ports noch nicht anderweitig belegt sind:
netstat -an | find ":2376"
netstat -an | find ":18080"
Damit vom Windows-Host aus auf die Webseite zugegriffen werden kann, wird per VBoxManage controlvm ein Port Forwarding vom VirtualBox-Linux-Layer zum Windows-Host konfiguriert. Rufen Sie auf:
docker-machine start docker-vm
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" controlvm docker-vm natpf1 "Tmct-18080,tcp,127.0.0.1,18080,,18080"
docker-machine stop docker-vm
Kontrollieren Sie das Ergebnis im GUI:
"C:\Program Files\Oracle\VirtualBox\VirtualBox.exe"
Klicken Sie links auf "docker-vm", oben auf "Ändern", dann auf "Netzwerk", "Erweitert" und "Port-Weiterleitung".
Sie können eine beliebige Webanwendungs-WAR-Datei deployen. Für dieses simple Beispiel wechseln Sie in ein beliebiges Projekte-Workspace-Verzeichnis (z.B. \MeinWorkspace) und erzeugen folgendermaßen mit Maven eine "Hello World"-WAR:
cd \MeinWorkspace
mvn archetype:generate -DinteractiveMode=false -DarchetypeArtifactId=maven-archetype-webapp -DgroupId=de.meinefirma.meinprojekt -DartifactId=MeinDockerTomcat
cd MeinDockerTomcat
mvn package
md dockerDirectory
copy /B target\MeinDockerTomcat.war dockerDirectory\MeinDockerTomcat.war
Wenn Sie nach
"tomcat" in der Docker Hub Registry
und nach
"docker tomcat" auf GitHub
suchen, erhalten Sie sehr viele Treffer sowohl für Dockerfiles als auch für Docker-Images.
Im Folgenden wird das tomcat-Docker-Image aus dem so genannten "official Repo" aus der Docker Hub Registry verwendet.
Es könnte direkt verwendet werden, ohne zusätzliches Dockerfile.
Aber hier soll ein eigenes Dockerfile erstellt werden, abgeleitet vom tomcat-Docker-Image.
Erzeugen Sie im Unterverzeichnis dockerDirectory die Datei: Dockerfile
FROM tomcat:8 MAINTAINER Mein Name <meine@email.adresse> ADD MeinDockerTomcat.war /usr/local/tomcat/webapps/ CMD ["catalina.sh", "run"]
Sehen Sie sich hierzu die Dockerfile Reference sowie die Doku zum tomcat-Docker-Image und das dazugehörende Dockerfile an.
Sehen Sie sich die Verzeichnisstruktur an:
tree /F
Sie erhalten:
[\MeinWorkspace\MeinDockerMachine] '- docker-machine-start.bat [\MeinWorkspace\MeinDockerTomcat] |- [dockerDirectory] | |- Dockerfile | '- MeinDockerTomcat.war |- [src] | '- [main] | '- [webapp] | |- [WEB-INF] | | '- web.xml | '- index.jsp |- [target] | |- MeinDockerTomcat.war | '- ... '- pom.xml
Wechseln Sie ins MeinDockerTomcat-Projektverzeichnis und starten Sie Docker Machine mit der oben erstellten Batchdatei:
cd \MeinWorkspace\MeinDockerTomcat
..\MeinDockerMachine\docker-machine-start.bat
Bauen und starten Sie den neuen Docker-Container:
docker build -t meintomcatimage dockerDirectory
docker run -it --rm -p 18080:8080 meintomcatimage
Zu den docker-Kommandozeilenparametern siehe docker build Usage, docker build Options und docker run Options.
Achten Sie darauf, dass zwischendurch
"INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive /usr/local/tomcat/webapps/MeinDockerTomcat.war"
angezeigt wird. Warten Sie bis
"INFO [main] org.apache.catalina.startup.Catalina.start Server startup"
gemeldet wird,
und sehen Sie sich an:
start http://localhost:18080
start http://localhost:18080/MeinDockerTomcat
--> Sie erhalten die gewünschte "Hello World"-Webseite.
Öffnen Sie ein weiteres Kommandozeilenfenster, führen Sie darin die generierte docker-machine-env.bat aus,
und testen Sie bei laufendem Container
docker-Kommandos und
docker-machine-Kommandos
(siehe auch Migrate from Boot2Docker to Docker Machine),
beispielsweise:
docker zur Anzeige der Docker-Kommandos.
docker info zur Anzeige von Docker-relevanten Systeminformationen.
docker images zur Anzeige der Docker-Images im lokalen Repository (inklusive der IMAGE-IDs).
docker ps -a zur Anzeige der Docker-Container (inklusive der CONTAINER-IDs).
docker diff <CONTAINER-ID> zur Anzeige von Unterschieden.
docker logs <CONTAINER-ID> zur Anzeige von Logs (z.B. von Daemons).
docker stats <CONTAINER-ID> zur Anzeige des CPU- und Memory-Verbrauchs.
docker stop <CONTAINER-ID> zum Beenden eines laufenden Docker-Containers.
docker rm <CONTAINER-ID> zum Löschen von nicht mehr benötigten Containern.
docker rmi <IMAGE-ID> zum Löschen von nicht mehr benötigten Images im lokalen Repository.
docker run -v ... zum Anbinden eines Volumes als "Shared Folder".
docker run -d ... zum Betreiben der Anwendung im Hintergrund als "Daemon".
docker cp Quelldatei <CONTAINER-ID>:/Zielpfad/Zieldateiname zum Kopieren einer Datei in den Container.
docker exec <CONTAINER-ID> ... zum Ausführen von Kommandos im Container.
docker exec -it <CONTAINER-ID> bash für ein Kommandozeilenfenster zum Container.
docker-machine zur Anzeige der docker-machine-Kommandos.
docker-machine ls zur Anzeige der Docker Machines und ihrer Stati.
docker-machine ssh docker-vm für SSH-Zugang zum VirtualBox-Linux-Layer.
Sie können dem "docker run ..."-Kommando hinter dem Image-Namen auch ein Kommando übergeben.
Dann wird das im Dockerfile in der letzten Zeile unter "CMD ..." angegebene Kommando nicht ausgeführt,
sondern stattdessen das von Ihnen per Kommandozeile übergebene Kommando.
So können Sie beispielsweise per "/bin/bash" zu einem bash-Terminal (Shell-Fenster / Kommandozeilenfenster)
im Container gelangen:
docker run -it --rm -p 18080:8080 meintomcatimage /bin/bash
Jetzt können Sie beliebige Linux-Kommandos im Container ausführen. Z.B. können Sie so den Tomcat auch manuell starten:
catalina.sh run
Sie können beim "docker run ..."-Kommando mit der -v-Option auch einen "Shared Folder" einrichten, also ein Verzeichnis, welches sowohl innerhalb des Containers als auch im Linux-Host erreichbar ist. Damit der Shared Folder auch im Windows-Host erreichbar ist, müssen Sie entweder einen Shared Folder in VirtualBox einrichten (siehe VBoxManage sharedfolder) oder ein Unterverzeichnis zu C:\Users\%USERNAME% verwenden. Letzteres macht folgende Kommandozeile (achten Sie genau auf Groß-/Kleinschreibung):
docker run -it --rm -v /c/Users/%USERNAME%/docker-shared:/home/docker/docker-shared -p 18080:8080 meintomcatimage /bin/bash
Beispielsweise können Sie in dem so gestarteten Container-Shell-Terminal im Shared Folder Dateien erzeugen:
cd /home/docker/docker-shared
echo yy > y.txt
ls -l
Gleichzeitig können Sie von einem Windows-Kommandozeilenfenster aus in dem Shared Folder Dateien erzeugen:
cd /D C:\Users\%USERNAME%\docker-shared
echo xx > x.txt
dir
Sehen Sie sich Ihre "VirtualBox-VM-Boxen" an:
dir "C:\Users\%USERNAME%\.docker\machine\machines"
dir "C:\Users\%USERNAME%\VirtualBox VMs"
Kurzes Resümee:
Weitere Docker-Beispiele finden Sie in Docker.