Infrastruktur mit Qualität

Docker Container mit serverspec testen - Teil 2

2015-04-16T00:00:00+02:00

Vor einiger Zeit hatten wir in einem Post gezeigt, welche Möglichkeiten existieren, um Container mit Serverspec zu testen. Zu diesem Zeitpunkt waren die Möglichkeiten im Großen und Ganzen in Ordnung, aber sicherlich nicht einfach zu handhaben. Nur durch eigene Erweiterungen von serverspec mit einem experimentellem nsenter-Backend war das Testen von Docker-Container sinnvoll möglich.

Seitdem hat sich im Projekt Serverspec einiges getan. Zum einen gibt es nun Resource Types für Docker-Container und -Images. Damit lassen sich auf einem Docker-Host die Eigenschaften von lokal liegenden Images und laufenden Containern prüfen. Zum anderen wurde das Docker-Backend so erweitert, dass auch über den API-Call von docker exec Prüfkommandos in einem laufenden Container mit ausgeführt werden können. Zeit, sich das Ganze im Detail anzuschauen.

Resource Types

Bei Resource Types handelt es sich um die Zielobjekte, die man in einem describe-Block beschreibt. So sind z.B. die bekannten file, process, port usw. Resource Types. Es gibt zwei Typen, die Docker-Objekte beschreiben, beide beziehen ihre Daten aus dem API-Call zu docker inspect. D.h. alles was ein inspect-Aufruf an Metadaten liefert, kann auch mit serverspec abgefragt werden.

docker_image

Bei Images ist natürlich erstmal interessant, dass es lokal vorliegt, um gestartet werden zu können. Meistens kommt ein Image aus einer Registry, ggf. hat man aber auch andere Lieferwege - z.B. aus der eigenen Buildchain per Tarball auf die Zielmaschine - implementiert. Das kann man testen:

Gemfile

source 'https://rubygems.org'
ruby '2.1.5'

gem 'serverspec', '~> 2'
gem 'docker-api'

.rspec

--color
--format documentation

spec/localhost/fedora_21_spec.rb

require 'serverspec'

set :backend, :exec

describe docker_image 'fedora:21' do
  it { should exist }
end

$ bundle install --path vendor
$ bundle exec rspec --pattern spec/localhost/\*_spec.rb

Docker image "fedora:21"
 should exist

Finished in 0.13116 seconds (files took 0.34526 seconds to load)
1 example, 0 failures

Wenn gerade kein Ruby auf dem eigenen Rechner installiert ist, kann dies natürlich auch im Container erledigt werden. Damit die Docker Resource Types funktionieren, muss eine Docker-CLI und funktionierender Docker Host installiere sein.

$ docker run -v $(pwd):$(pwd) \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /usr/local/bin/docker:/usr/local/bin/docker \
 --workdir=$(pwd) -ti --rm ruby:2.1.5 \
  /bin/bash -c "bundle install --path vendor ; bundle exec rspec --pattern spec/localhost/fedora_21_spec.rb"

Um an die inspect-Daten heranzukommen, gibt es zwei Alternativen, hier am Beispiel der Systemarchitektur. Entweder verwendet man den inspection-Matcher, der eine komplette Map zurückliefert, aus der Teile testet. Oder man gibt den zu testenden Schlüssel als Parameter mit und prüft das Ergebnis. Beide Alternativen sind sinnvoll, so kann man z.B. bei der zweiten Variante auch mit regulären Ausdrücken testen.

describe docker_image 'fedora:21' do
  its(:inspection) { should_not include 'Architecture' => 'i386' }
  its(['Architecture']) { should eq 'amd64' }
end

$ bundle exec rspec
(...)
Docker image "fedora:21"
  inspection
    should not include {"Architecture" => "i386"}
  ["Architecture"]
    should eq "amd64"
(...)

Welche Eigenschaften sind an einem Docker-Image interessant, was kann sinnvoll getestet werden?

Ein Maintainer sollte gesetzt sein, z.B. kann man dort einen Schlüssel einbauen, der anzeigt, dass dieses Image aus der eigenen Build-Chain stammt, und nicht von extern kommt.
Good Practise für ist es, einen ENTRYPOINT zu verwenden, um Nutzung und einzuschränken und Falsch-Nutzung zu vermeiden.
Für Service-Container sollten bestimmte Ports exposed werden.
Bestimmte Environment-Parameter müssen vorhanden sein, sonst funktionieren Skripte oder Konfigurationen nicht.

Zum Beispiel hier ein Demo-Dockerfile:

FROM fedora:21
MAINTAINER My Private Build Chain

ENV MYAPP_VERSION 47.11

EXPOSE 80

ENTRYPOINT ["/bin/entrypoint"]

Gebaut:

$ docker build -t testimage .
(...)
Successfully built aeb232471f6f

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED              VIRTUAL SIZE
testimage           latest              aeb232471f6f        54 seconds ago       241.3 MB

Mit einer passenden Spec ist die Überprüfung schnell implementiert:

describe docker_image 'testimage' do
  it { should exist }
  its(['Author']) { should eq 'My Private Build Chain' }
  its(['Entrypoint']) { should_not eq '' }
  its(['Entrypoint']) { should_not eq '/bin/entrypoint' }
  its(['Config.Env']) { should include /MYAPP_VERSION=47\.11/ }
  its(['Config.ExposedPorts']) { should include /80\/tcp/ }
  its(['Config.ExposedPorts']) { should_not include /22\/tcp/ }
end

Ergibt:

$ bundle exec rspec --pattern spec/localhost/\*_spec.rb

Docker image "testimage"
  should exist
  ["Author"]
    should eq "My Private Build Chain"
  ["Entrypoint"]
    should not eq ""
  ["Entrypoint"]
    should not eq "/bin/entrypoint"
  ["Config.Env"]
    should include /MYAPP_VERSION=47\.11/
  ["Config.ExposedPorts"]
    should include /80\/tcp/
  ["Config.ExposedPorts"]
    should not include /22\/tcp/

Finished in 0.12227 seconds (files took 0.35186 seconds to load)
7 examples, 0 failures

Es ist also sehr einfach bestimmte Qualitätsnormen der Docker-Images zu überprüfen. Manche Dinge sollen unbedingt enthalten sein, und andere Einstellungen, z.B. einen offenen SSH-Port, sind ehr unerwünscht.

docker_container

Dasselbe gibt es natürlich auch für Container. Hier wird es interessanter, weil wir in der Lage sind, Laufzeitaspekte zu berücksichtigen. Das fängt mit einem laufenden Container an:

describe docker_container 'testcontainer' do
  it { should exist }
  it { should be_running }
end

Ohne einen Container mit dem Namen gestartet zu haben, läuft die Spec in zwei Fehler. Also kann die Spec mit dem folgenden Befehl erfüllt werden:

$ docker run -tdi --name testcontainer fedora:21 /bin/bash
$ bundle exec rspec --pattern spec/localhost/\*_spec.rb

Docker container "testcontainer"
 should exist
 should be running

Finished in 0.13791 seconds (files took 0.39023 seconds to load)
2 examples, 0 failures

Mit den gleichen Inspection-Ausdrücken können nun Container Checks implementiert werden. Serverspec unterstützt noch einen weiteren Ausdruck have_volume für die Prüfung von Volumes:

describe docker_container 'testcontainer' do
  it { should have_volume('/mnt', '/tmp') }
end

Ausgeführt:

$ docker run -tdi --name testcontainer -v /tmp:/mnt fedora:21 /bin/bash
$ bundle exec rspec --pattern spec/localhost/\*_spec.rb

Docker container "testcontainer"
  should have volume "/mnt", "/tmp"

Finished in 0.10888 seconds (files took 0.35251 seconds to load)
1 example, 0 failures

Einer nach dem anderen...

Ein Nachteil dieser Resource Types liegt darin, das nur ein Image oder Container auf einmal geprüft werden kann. In einer Teststufe der Build chain ist das in Ordnung, weil in der Regel nur ein Image oder Container gebaut wird. In Produktions- oder Staging-Systemen besteht ggf. der Wunsch, alle Container eines bestimmten Typs auf einmal zu prüfen: z.B. "Alle Container, die web* heissen, sollen nur Port 443 exposen und nicht privilegiert ablaufen."

Das ist in der Form nicht mit den aktuellen Resource Types von Serverspec möglich. Eine alternative Variante ist in Containerspec implementiert. Dort wird cucumber an Stelle von rspec verwendet, um in der Gherkin-Syntax Prüffälle zu formulieren.

Damit lassen sich mehrere Images bzw. Container auf einmal prüfen:

Scenario: NGINX Container
  When there is a running container named like 'nginx.*'
  Then it should run on image 'nginx:1.7.8'
  And containers should not expose port '80'
  And containers should expose port '443' on host port '8443'
  And container volume '/etc/nginx/sites-enabled' should be mounted
  And container volume '/var/log/nginx' should not be mounted

Der Ausdruck "When there is a running container..." selektiert alle laufenden Container mit bestimmten Eigenschaften, hier z.B. einen Container-Namen der auf "nginx.*" matcht. Ein ausführlicheres Beispiel ist im Github-Wiki hinterlegt.

Docker-Backend

Mit den obigen Resource Types ist das Docker-Setup auf dem Host spezifizierbar. Im nächsten Schritte möchten wir aber auch gerne innerhalb von laufenden Containern Specs ausführen. Dabei hilft eine Erweiterung des Docker-Backends. Es kennt zwei Modi:

Wenn docker_image gesetzt ist, wird ein Image geprüft. Das hatten wir im Blog-Post schon beschrieben.
Wenn docker_container gesetzt ist, wird ein laufender Container geprüft. Dazu werden die Befehle mit docker exec in den Container gebeamt und ausgeführt.

Hier ein Beispiel, um Container zu testen. Wir möchten den Namen des Containers als Environmentvariable mitgeben, also brauchen wir einen angepassten spec_helper.rb. Damit das Docker-Backend läuft, müssen vorher noch abhängige Pakete installiert werden (s. Gemfile).

$ bundle exec serverspec-init
Select number: 1
Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/sample_spec.rb
 + spec/spec_helper.rb
 + Rakefile
 + .rspec

Der Spec-Helper sieht dann so aus:

[root@localhost ~]# cat spec/spec_helper.rb
require 'serverspec'

set :backend, :docker

set :docker_container, ENV['TARGET']

Damit können wir beim rake spec-Aufruf ein TARGET=xyz vorstellen und so den Containernamen (oder ID) mitgeben, der wir testen möchten.

Als Beispiel nehmen wir den laufenden Fedora21-Testcontainer von oben, mit einer Demo-Spec:

# cat spec/localhost/sample_spec.rb
require 'spec_helper'

describe package('httpd') do
  it { should be_installed }
end

$ TARGET=testcontainer rake spec
(...)
Package "httpd"
  should be installed (FAILED - 1)

Failures:

  1) Package "httpd" should be installed
     On host `localhost'
     Failure/Error: it { should be_installed }
       expected Package "httpd" to be installed

     # ./spec/localhost/sample_spec.rb:4:in block (2 levels) in <top (required)>'`

Finished in 0.34612 seconds (files took 0.29735 seconds to load)
1 example, 1 failure

Klar, das Paket httpd ist noch nicht installiert. Wir holen es nach:

$ docker attach testcontainer
bash-4.3# yum install -y httpd
(...)
Complete!
bash-4.3# <CTRL-P> + <CTRL-Q>

Damit läuft die Spec durch:

$ TARGET=testcontainer bundle exec rspec --pattern spec/localhost/\*_spec.rb

Package "httpd"
  should be installed

Finished in 0.50143 seconds (files took 0.5923 seconds to load)
1 example, 0 failures

Nachteilig ist und bleibt, dass die für die Tests notwendigen Binaries im Container vorhanden sein müssen. Das trifft mittlerweile selbst bei Distributionen nur noch teilweise zu. Ein fedora:21 hat erstmal kein netstat, so kann port nicht geprüft werden. Ein debian:wheezy kennt kein ps, usw. Für die White-Box-Testbarkeit sollten also diese Tools nachinstalliert werden.

Schwierig wird es, wenn das Image statisch gelinkte Binaries als Applikationen beinhaltet (z.B. aus der Go-Welt), und auf ein "klassisches" Linux-Userland verzichtet. Dann müssen die Tools ggf. als Volume mit eingemountet werden, um den Container testbar zu machen.

Fazit

Das Thema Testing und Docker wird langsam rund :) Wir haben ausreichend Möglichkeiten, einen Docker-Host durchzutesten, und mit dem erweiterten Docker-Backend von Serverspec nun auch die laufenden Container. D.h. einer Test-Driven Infrastructure mit Docker steht nun nichts mehr im Weg.

Buildchains führen seit einger Zeit automatisierte Tests mit dem Applikationcode aus. Viele Unternehmen, die Konfigurationsmanagement-Tools einsetzen lassen in Buildchains diesen Code ebenfalls Unit-testen.

Beim Einsatz von Docker kommt Buildchains eine neue Aufgabe zu: Sie produzieren nicht mehr nur Anwendungscode, sie produzieren Infrastrukturen. Und diese Infrastruktur-Artefakte lassen sich genau so gut testen, wie die Anwendung selbst.

Viel Spaß beim Ausprobieren wünschen:

Andreas und Peter

Docker Microservice Basis mit Apache Tomcat implementieren

2014-12-19T00:00:00+01:00

Das Docker-Ökosystem ist die ideale Umgebung, um Microservices zu implementieren. Die Ideen ist, verschiedene Services auf einem Rechner isoliert von einander bereitzustellen. Ähnlichkeiten zu der heute verbreiteten Virtualisierung existieren, aber ohne die Abhängigkeiten zu einem bestimmten Hersteller oder dem Overhead der Ablaufplattform. In diesem Post werden verschiedene Weg zur Verwendung eines eigenen Java- und Tomcat-Image beschrieben.

Die Docker-Container nutzen einfach den Linux-Kernel und können in verschiedenen Umgebungen anpassbar betrieben werden. Die Leichtigkeit beruht auf den schon lange vorhandenen Linux API's, wie Namespaces, CGroups, Capabilities oder SELinux. Docker fügt neben einem Rest-Service noch die Definition eines austauschbaren Image-Formats hinzu. Das Teilen von vorgefertigter Software ist nun also mit Docker wirklich Realität. Damit das Teilen auch platzsparend ist, kommt ein Layered Filesystem zum Einsatz. Docker liefert Schnittstellen und besitzt Plugins, die Raum für eigene Erweiterungen bieten. Alles ist OpenSource und wird von einer aktiven Community entwickelt. Das bringt jeden Entwickler und Administrator schnell zum Schwärmen. Es befeuert die Idee, eine kontrollierte Umgebung von der Entwicklung bis in die Produktion zu nutzen. Microservices lassen sich so einfacher realisieren und orchestrieren. Der Begriff Microservice ist schwer zu fassen, die 12 Factor Rules bieten eine erste Orientierung für die Entwicklung. Wichtiger Punkt ist, dass die Software in möglichst unabhängigen und autarken Einheiten bereitgestellt wird.

Die Begriffe Microservice, Continuous Delivery-Pipeline und Docker berauscht also gerade die IT. Alles in kleine Funktionseinheiten spalten, wird als Heilmittel für die Ablösung der kostenträchtigen aktuellen IT gepriesen. Wir wollen schneller, zuverlässiger und preiswerter liefern und damit den Wunsch nach unkomplizierten Änderungen endlich befriedigen. Schöne neue Welt, aber Hand auf Herz. Die IT-Welt ist komplex und die bestehenden Systeme beherrschen unsere tägliches Handeln mehr als uns lieb ist. Wer das Glück hat, in seinem Projekt schon jetzt einen Blick in die IT-Zukunft wagen zu können, der kann allerdings nun aus dem Vollen schöpfen. Das Docker-Ökosystem bietet jede Menge neuer exotischer Verführungen.

Eine Übersicht über den aktuellen Stand könnt Ihr im Entwickler Magazin Spezial Vol.2: Docker nachlesen. Hier haben viele unserer Kollegen und wir verschiedene Aspekte von Docker erklärt und berichten vom wirklichen Einsatz.

Also ran ans Werk!

Bereitstellen von Java- und Apache Tomcat Docker-Images

Eine Entwicklungsumgebung für Java mit Apache Tomcat aufzusetzen, kann von vielen Tücken begleitet sein. Schnell kommt das Setup einer DB und weitere Backends hinzu. Das Aufsetzen einer einheitlichen Umgebung im Team und die Integration neuer Mitglieder ist leider oft eine zeitaufwendige Geschichte. Schnelle Auslieferung bedeutet auch schnelles handeln im Team, im Code, in der Entwicklungsumgebung und in der Produktion. Hier hilft nur die Automatisierung und Standardisierung voranzutreiben. Docker kann hier helfen, die Infrastruktur mehr als Code zu begreifen. Viele vorgefertigte Images stehen auf dem Docker-Hub schon bereit. Ein Test-Setup einer fremden Komponente kann also schnell erfolgen. Eine Herausforderung bleibt es allerdings, den eigenen individuellen Code schnell mit den bereitgestellten Services zu verheiraten oder ein eigenes Services-Images zu realisieren.

Das Experiment: Ein Java-Image für Dev und Ops bereitstellen

Auf dem Docker-Hub existieren natürlich viele Java-Images. Allerdings basieren sie oft auf dem falschem Betriebssystem, enthalten nicht die richtige Java Version oder sie sind schlicht zu groß.

Im folgenden entsteht eine Basis, die ein eigenes Java-Images erzeugt.

Mit minimaler Größe, damit ein schneller Download möglich ist.
Für den Apache Tomcat 8 reicht ein Java-Runtime.
Java Anwendungen und Werkzeuge sollen nutzbar sein.

Als minimales Betriebssystem ohne alles reicht für Java die Distribution Busybox völlig aus. Mit Hilfe von curl ist so schnell ein Oracle JRE-Tarball extrahiert und bereitgestellt.

jre8/Dockerfile

# Busybox with a Java installation
FROM progrium/busybox
MAINTAINER Peter Rossbach <peter.rossbach@bee42.com>

# Install cURL
RUN opkg-install curl

# Java Version
ENV JAVA_VERSION_MAJOR 8
ENV JAVA_VERSION_MINOR 25
ENV JAVA_VERSION_BUILD 17
ENV JAVA_PACKAGE       server-jre
ENV JAVA_CHECKSUM      c3ec171fac394c584a0a5cecb1731efd

# Download, verify and extract Java
RUN curl -kLOH "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" \
http://download.oracle.com/otn-pub/java/jdk/${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-b${JAVA_VERSION_BUILD}/${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz \
  && echo "${JAVA_CHECKSUM}  ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz" > ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz.md5.txt \
  && md5sum -c ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz.md5.txt \
  && gunzip ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar.gz \
  && tar -xf ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar -C /opt \
  && rm ${JAVA_PACKAGE}-${JAVA_VERSION_MAJOR}u${JAVA_VERSION_MINOR}-linux-x64.tar* \
  && ln -s /opt/jdk1.${JAVA_VERSION_MAJOR}.0_${JAVA_VERSION_MINOR} /opt/jdk

# Set environment
ENV JAVA_HOME /opt/jdk
ENV PATH ${PATH}:${JAVA_HOME}/bin

VOLUME [ "/opt/jdk"]

ENTRYPOINT ["java"]
CMD ["-version"]

Nicht vergessen beim Download von fremden Quellen, die Prüfsumme zu überprüfen. Mit diesem jre8/Dockerfile lässt sich nun der Java-Container schnell erzeugen und testen:

$ mkdir -p jre8
$ vi jre8/Dockerfile
...
$ docker build -t infrabricks/ex-java:jre-8 jre8
$ docker run --rm infrabricks/ex-java:jre-8
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
$ docker images |grep "infrabricks/java"
infrabricks/java                                          jre-8                    96860db18ac9        8 seconds ago       160.3 MB

Voila!

JDK gefällig

Wenn ein Java Development-Kit gewünscht wird, kann dies analog erstellt werden.

Dazu müssen im Dockerfile folgenden Veränderung erfolgen:

jdk8/Dockerfile

...
ENV JAVA_PACKAGE       jdk
ENV JAVA_CHECKSUM      e145c03a7edc845215092786bcfba77e
...

Das Erzeugen des Images und der Tests geschieht analog.

$ mkdir -p jdk8
$ vi jkd8/Dockerfile
...
$ docker build -t infrabricks/ex-java:jdk-8 jdk8
$ docker run --rm infrabricks/ex-java:jdk-8
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
$ docker run --rm --entrypoint=/bin/sh -ti -v `pwd`:/data infrabricks/java:jdk-8
$ ls /opt/jdk/bin
ControlPanel    jarsigner       javafxpackager  jcmd            jhat            jmc.ini         jstat           orbd            rmiregistry     unpack200
appletviewer    java            javah           jconsole        jinfo           jps             jstatd          pack200         schemagen       wsgen
extcheck        java-rmi.cgi    javap           jcontrol        jjs             jrunscript      jvisualvm       policytool      serialver       wsimport
idlj            javac           javapackager    jdb             jmap            jsadebugd       keytool         rmic            servertool      xjc
jar             javadoc         javaws          jdeps           jmc             jstack          native2ascii    rmid            tnameserv
$ du -s /opt/jdk1.8.0_25
322308  /opt/jdk1.8.0_25
$ exit
$ docker images |grep "infrabricks/java"
infrabricks/java                                          jre-8                    96860db18ac9        22 minutes ago      160.3 MB
infrabricks/java                                           jdk-8                    fbf0c4b72d14        8 seconds ago      331.3 MB

In der Auflistung wird deutlich, welch große Mengen Plattenplatz die visuellen Tools, libs, Quellen und Dokumentationen eines JDK's benötigen! In der Produktion sollte dieser Overhead nur selten notwendig sein, oder?

Apache Tomcat Image - Ontop

Auf der Basis des Java-Images kann nun die Bereitstellung des Tomcats erfolgen:

tomcat8/Dockerfile

FROM infrabricks/ex-java:jre-8
MAINTAINER Peter Rossbach <peter.rossbach@bee42.com>

ENV TOMCAT_MINOR_VERSION 8.0.15
ENV CATALINA_HOME /opt/tomcat

RUN curl -O http://archive.apache.org/dist/tomcat/tomcat-8/v${TOMCAT_MINOR_VERSION}/bin/apache-tomcat-${TOMCAT_MINOR_VERSION}.tar.gz && \
 curl http://archive.apache.org/dist/tomcat/tomcat-8/v${TOMCAT_MINOR_VERSION}/bin/apache-tomcat-${TOMCAT_MINOR_VERSION}.tar.gz.md5 | md5sum -c - && \
 gunzip apache-tomcat-*.tar.gz && \
 tar xf apache-tomcat-*.tar && \
 rm apache-tomcat-*.tar && mv apache-tomcat* ${CATALINA_HOME} && \
 rm -rf ${CATALINA_HOME}/webapps/examples \
  ${CATALINA_HOME}/webapps/docs ${CATALINA_HOME}/webapps/ROOT \
  ${CATALINA_HOME}/webapps/host-manager \
  ${CATALINA_HOME}/RELEASE-NOTES ${CATALINA_HOME}/RUNNING.txt \
  ${CATALINA_HOME}/bin/*.bat ${CATALINA_HOME}/bin/*.tar.gz

WORKDIR /opt/tomcat
EXPOSE 8080
EXPOSE 8009
VOLUME [ "/opt/tomcat" ]

ENTRYPOINT [ "/opt/tomcat/bin/catalina.sh" ]
CMD [ "run"]

Die Standard-Distribution des Tomcats wird gesäubert. Dann werden die entsprechenden Ports preisgegeben und der Startbefehl für den Tomcat gesetzt.

$ mkdir -p tomcat8
$ vi tomcat8/Dockerfile
...
$ docker build -t infrabricks/ex-tomcat:8 tomcat8
$ docker run --rm --entrypoint=/opt/tomcat/bin/version.sh infrabricks/ex-tomcat:8

Die erste Anwendung - Hello Status

Die folgende Status-Anwendung kann nun implementiert und eingebunden werden.

index.jsp

<%@ page session="false" %>
<%
java.text.DateFormat dateFormat =
new java.text.SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
%>
<html>
<body>
<h1>Docker Tomcat Status page</h1>

<ul>
<li>Hostname : <%= java.net.InetAddress.getLocalHost().getHostName() %></li>
<li>Tomcat Version : <%= application.getServerInfo() %></li>
<li>Servlet Specification Version : <%= application.getMajorVersion() %>.<%= application.getMinorVersion() %></li>
<li>JSP version : <%=JspFactory.getDefaultFactory().getEngineInfo().getSpecificationVersion() %></li>
<li>Now : <%= dateFormat.format(new java.util.Date()) %></li>
</ul>
</body>
</html>

Die einfach Anwendung kann nun mittels zip zu einem WAR-File verpackt werden und gegebenenfalls als Volume eingebunden werden.

$ mkdir -p status/webapp
$ cd status/webapps
$ vi index.jsp
...
$ zip -r ../status.war .
$ cd ../..
$ CID=$(docker run -d -v `pwd`/status/webapp:/opt/tomcat/webapps/status) infrabricks/ex-tomcat:8
$ docker logs $CID
18-Dec-2014 17:45:18.678 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version:        Apache Tomcat/8.0.15
18-Dec-2014 17:45:18.681 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          Nov 2 2014 19:25:20 UTC
18-Dec-2014 17:45:18.682 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number:         8.0.15.0
18-Dec-2014 17:45:18.683 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Linux
18-Dec-2014 17:45:18.683 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            3.16.7-tinycore64
18-Dec-2014 17:45:18.687 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64
...

Ausführen kann man die Anwendung mittels curl. Wenn ein Browser-Zugriff gewünscht ist, muss der Tomcat-Port mit der Option -p 8080:8080 von außen erreichbar gemacht werden.

$ IP=$(docker inspect --format '' ${CID})
$ curl -s http://$IP:8080/status/index.jsp


<html>
<body>
<h1>Docker Tomcat Status page</h1>

<ul>
<li>Hostname : a222c4e3f231</li>
<li>Tomcat Version : Apache Tomcat/8.0.15</li>
<li>Servlet Specification Version : 3.1</li>
<li>JSP version : 2.3</li>
<li>Now : 2014/12/17 16:06:32</li>
</ul>
</body>
</html>

Nutzung der Tomcat Manager Webapp

Der Zugriff auf die Manager Anwendung des Tomcats kann nur mit entsprechender Autorisierung erfolgen. Die Konfiguration erfolgt hier durch die folgenden Dateien:

tomcat8/conf/tomcat-users.xml

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users xmlns="http://tomcat.apache.org/xml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
version="1.0">

  <role rolename="manager-script"/>
  <user username="manager" password="tomcat" roles="manager-script"/>
</tomcat-users>

Die Anbindung ist etwas aufwendiger, da nur Verzeichnisse in einen Container eingebunden werden können. Es wird also ein Startskript benötigt, das vor dem Start des Containers die Datei verlinkt oder kopiert.

tomcat8/bin/tomcat.sh

#!/bin/sh
ln -s /opt/bootstrap/conf/tomcat-users.xml /opt/tomcat8/conf/tomcat-users.xml
${CATALINA_HOME}/bin/catalina.sh run

Die Integration in den Tomcat geschieht durch die Anbindung eines Volumes.

$ mkdir -p tomcat8/bin
$ vi tomcat8/bin/tomcat.sh
...
$ chmod -x tomcat8/bin/tomcat.sh
$ docker run -d \
 -v `pwd`/status/webapp:/opt/tomcat/webapps/status \
 -v `pwd`/tomcat8:/opt/bootstrap \
 --entrypoint=/opt/bootstrap/tomcat.sh \
 infrabricks/ex-tomcat:8
$ CID=$(docker ps -lq)
$ IP=$(docker inspect --format '' ${CID})
$ curl -u manager:tomcat http://$IP:8080/manager/text/list
OK - Listed applications for virtual host localhost
/status:running:0:status
/manager:running:0:manager

Natürlichen lassen sich ähnliche Tomcat-Erweiterungen ins Verzeichnis /opt/bootstrap/lib einbinden oder andere Konfigurationen austauschen. Im Git Projekt infrabricks docker-simple-tomcat8 ist ein erweitertes Skript zu finden. Ein weiteres Projekt einer echten Infrabricks Tomcat-Line ist in der Realisierung. Dort entsteht eine ganzen Tomcat-Familie, die auf verschiedenen Java- und Tomcat-Versionen besteht.

Tricks

Docker Container Overlay

Wenn die JDK-Tools in einem Tomcat benötigt werden, lassen sich diese einfach von JDK-Image übernehmen. Das geht problemlos, auch ohne dass der Tomcat von diesem Images abgeleitet werden muss.

$ docker run --name jdk8 infrabricks/ex-java:jdk-8
$ docker run -d \
 --volumes-from jdk8 \
 -v `pwd`/status/webapp:/opt/tomcat/webapps/status \
 infrabricks/ex-tomcat:8
$ CID=$(docker ps -lq)
$ docker exec $CID jstat -gc 1 5000  
$ docker exec -ti $CID /bin/sh
...

Das JDK-Image exportiert mit der Angabe VOLUME [ "/opt/jdk" ] die Java-Installation. Mit der Angabe von --volumes-from lässt sich einfach die vorhandene JRE-Installation überblenden. Layered Filesysteme sind schon ein Segen für die Entwicklung von Infrastruktur.

Happy debugging!!

Docker Composition: Tomcat als Data-Container nutzen

Wenn man die vollständige Freiheit über die Wahl der Java-Distribution haben möchte, kann man als Alternative den Tomcat als Data-Container liefern. Auf der Basis von progrium/busybox lässt sich das schnell erzeugen und die Installation als Volume freigeben.

Mit folgenden Änderungen auf dem bestehenden tomcat8/Dockerfile entsteht ein Tomcat Data-Container.

tomcat8-volume/Dockerfile

FROM progrium/busybox
MAINTAINER Peter Rossbach <peter.rossbach@bee42.com>

# Install wget
RUN opkg-install curl

ENV TOMCAT_MINOR_VERSION 8.0.15
ENV CATALINA_HOME /opt/tomcat

RUN curl -O http://archive.apache.org/dist/tomcat/tomcat-8/v${TOMCAT_MINOR_VERSION}/bin/apache-tomcat-${TOMCAT_MINOR_VERSION}.tar.gz && \
curl http://archive.apache.org/dist/tomcat/tomcat-8/v${TOMCAT_MINOR_VERSION}/bin/apache-tomcat-${TOMCAT_MINOR_VERSION}.tar.gz.md5 | md5sum -c - && \
gunzip apache-tomcat-*.tar.gz && \
tar xf apache-tomcat-*.tar && \
rm apache-tomcat-*.tar && mv apache-tomcat* ${CATALINA_HOME} && \
rm -rf ${CATALINA_HOME}/webapps/examples \
${CATALINA_HOME}/webapps/docs ${CATALINA_HOME}/webapps/ROOT \
${CATALINA_HOME}/webapps/host-manager \
${CATALINA_HOME}/RELEASE-NOTES ${CATALINA_HOME}/RUNNING.txt \
${CATALINA_HOME}/bin/*.bat ${CATALINA_HOME}/bin/*.tar.gz

VOLUME [ "/opt/tomcat" ]

CMD [ "/bin/true" ]

Start des Data Containers Tomcats auf der Basis des JDK's:

$ docker build -t infrabricks/ex-tomcat:8-volume tomcat8-volume
$ docker run --name tomcat8 infrabricks/ex-tomcat:8-volume
$ docker run -d -p 8080:8080 \
 --volumes-from tomcat8 \
 -v `pwd`/status/webapp:/opt/tomcat/webapps/status \
 --entrypoint /opt/tomcat/bin/catalina.sh \
 infrabricks/ex-java:jdk-8 run

Mit diesem Muster lassen sich nun sehr effizient und schnell verschiedene Java-Versionen mit einer Anwendung testen. Natürlich spricht auch nichts dagegen, einfach einen Apache Tomcat lokal auszupacken und diesen direkt als Volume zu nutzen.

Quick and Dirty

$ T_V=8.0.15
$ T_URL=http://archive.apache.org/dist/tomcat/tomcat-8
$ curl -O ${T_URL}/v${T_V}/bin/apache-tomcat-${T_V}.tar.gz
$ tar xzf apache-tomcat-${T_V}.tar.gz
$ docker run -d -p 8080 \
 -v `pwd`/apache-tomcat-${T_V}:/opt/tomcat \
 -v `pwd`/status/webapp:/opt/tomcat/webapps/status \
  --entrypoint /opt/tomcat/bin/catalina.sh \
 infrabricks/ex-java:jdk-8 run

Ein flexibleres tscratch.sh-Script für diese Anwendung, findet ihr im Beispiel Projekt zu diesem Post.

Fazit

Mit dieser Docker Tomcat Basis kann nun der Start für die eigenen Webapps oder REST-Microservices gewagt werden. In einer der nächsten Post wird ein entsprechendes REST-Beispiel vorgestellt und im folgenden schrittweise zu einer eigenen Microservice-Plattform weiterentwickelt.

Java-Installationen für die Produktion sollten auf einem minimalen Base-Image beruhen.
Alle Downloads sollten mit Checksum validiert werden.
Das vorgestellte Tomcat Basis-Image lässt sich sehr einfach mit eigenen Konfigurationen, Anwendungen und Libs erweitern.
Die Komposition von verschiedenen Containern macht den Test und die Entwicklung einfacher.
Jede der gezeigten Varianten hat seinen Nutzen. Die reine Docker-Images-Lehre immer alles in ein auslieferbares Image zu packen ist richtig, aber während der Entwicklung und Test nicht immer die flexibelste und schnellste Lösung.
WARNUNG: Um die visuellen Java-Tools zu nutzen, kann es sein, dass ein Ubuntu Host mit X11 und ein Debian Base Image mit entsprechenden X-Libs benötigt wird Running Docker gui apps.

In diesem Sinne, viel Spaß beim Probieren oder selber Gestalten.

Peter

Docker-Container mit Serverspec testen

2014-09-10T00:00:00+02:00

Nachdem wir in diversen Posts vor einiger Zeit Serverspec für Server und VMs vorgestellt haben, brauchen wir jetzt natürlich auch noch eine sinnvolle Verbindung zu Docker. Die Frage ist also, wie kann man innerhalb von Containern eine Spezifikation prüfen?

Dazu gibt es natürlich mehrere Möglichkeiten.

SSH

Die aus Serverspec-Sicht einfachste Art besteht darin, den Container als Zielhost anzugeben, mit dem sich Serverspec dann regulär per SSH verbinden kann. Für serverspec macht es keinen Unterschied, ob es sich um echte Hardware, eine VM oder einen Container handelt.

Das wiederum führt aber zu größeren Umbauarbeiten im Container, da man nun neben dem eigentlichen Service, den man laufen lassen möchte, noch einen SSH-Daemon benötigt. Beispielsweise lässt sich die Integration mehrere Services innerhalb eines Containers mit Supervisor.d umsetzen.

Letzen Endes muss man an der Stelle aber eigentlich die Grundlagen-Entscheidung treffen, wie der eigene Container ausgestaltet sein soll: Als Microservice, ausschließlich mit dem Zielprozess, oder als VM-Ersatz mit mehreren Services inklusive sshd.

Fazit: Falls die Antwort "VM-Ersatz" lautet, stellt der SSH-Zugang für Serverspec die einfachste Möglichkeit dar. Falls der Microservice-Ansatz geplant ist, müssen wir uns andere Zugangsmöglichkeiten anschauen.

Zur Build-Zeit

Man kann den Serverspec-Aufruf natürlich auch zur Build-Zeit in das Dockerfile platzieren. Dabei lassen sich die Spezifikationsfiles per "ADD"-Befehl einsetzen, über "RUN" wird serverspec dann ausgeführt und schreibt das Ergebnis in eine Datei, zur späteren Einsicht. Die Spezifikationsdateien und die Ergebnisdatei dürfen auch auf einem Docker Volume liegen, um das ganze z.B. von außen steuern zu können.

Am Beispiel:

$ mkdir serverspec-docker-test
$ cd serverspec-docker-test
$ mkdir spec.d
$ cd spec.d
$ serverspec --init

$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile

$ vim Dockerfile

Hier setzen wir in den Dockerfile folgendes ein:

FROM ubuntu:14.04

RUN sudo apt-get -yqq update

RUN sudo apt-get -yqq install ruby1.9.3

RUN sudo gem install rake -v '10.3.2' --no-ri --no-rdoc
RUN sudo gem install rspec -v '2.99.0' --no-ri --no-rdoc
RUN sudo gem install specinfra -v '1.21.0' --no-ri --no-rdoc
RUN sudo gem install serverspec -v '1.10.0' --no-ri --no-rdoc

ADD ./spec.d /opt/spec.d

RUN ( cd /opt/spec.d; rake spec )

CMD /bin/bash

Jetzt den Container bauen (gekürzter Auszug):

$ docker build .
Sending build context to Docker daemon 7.168 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu:14.04
 ---> c4ff7513909d
Step 1 : RUN sudo apt-get -yqq update
 ---> Running in bc2eb91c00ff
[...]
Removing intermediate container bc2eb91c00ff
Step 2 : RUN sudo apt-get -yqq install ruby1.9.3
[...]
Step 3 : RUN sudo gem install rake -v '10.3.2' --no-ri --no-rdoc
[...]
Step 4 : RUN sudo gem install rspec -v '2.99.0' --no-ri --no-rdoc
[...]
Step 5 : RUN sudo gem install specinfra -v '1.21.0' --no-ri --no-rdoc
[...]
Step 6 : RUN sudo gem install serverspec -v '1.10.0' --no-ri --no-rdoc
[...]
Step 7 : ADD ./spec.d /opt/spec.d
[...]
Step 8 : RUN ( cd /opt/spec.d; rake spec )
 ---> Running in 1f880efa0c71
/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb
dpkg-query: no packages found matching httpd
FFhttpd: unrecognized service
FFFF

Failures:

  1) Package "httpd" should be installed
     On host ``
     Failure/Error: it { should be_installed }
       dpkg-query -f '${Status ..'

[...]

Finished in 0.32489 seconds
6 examples, 6 failures

[...]

/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb failed
2014/09/06 18:35:10 The command [/bin/sh -c ( cd /opt/spec.d; rake spec )] returned a non-zero code: 1

Natürlich schlägt das Beispiel des Serverspec Generators fehl, da der Container kein httpd enthält. Es ist halt die Demo-Spezifikation des Befehls serverspec-init, aber man sieht den Aufruf. In der Übersicht sieht das ganze so aus:

Vorteile:

Man muss nichts an serverspec ändern, außer es im Container zu installieren.
Es passt zum Ablauf in Build-Chains: Beim Bau des Containers wird eine Spezifikation geprüft. Das Ergebnis kann von außen nachgeschaut werden, bei Failures stoppt die Build-Chain.
Bei aufeinander aufbauenden Images (z.B. FROM rossbachp/tomcat8:latest) kann man den darunterliegenden Containerinhalt auf Korrektheit prüfen, wenn man sich nicht darauf verlassen möchte.

Nachteile:

Man muss serverspec (und Abhängigkeiten, inkl. ruby) im Container installieren, obwohl man es zur Laufzeit nicht mehr braucht. D.h. eigentlich sollten die Pakete nach erfolgreichem Spec-Lauf wieder deinstalliert werden, inkl. eine squashen des Docker Images.
Man kann nur statische Aspekte der Betriebssystem-Installation prüfen, z.B. Dateien, Verzeichnisstrukturen, Pakete, Kernel-Einstellungen.
Dynamische Aspekte des Service, z.B. läuft der Service, horcht der Port, usw. können nicht getestet werden, da der Zielprozess ja noch gar nicht läuft.

Fazit: Wem es reicht, innerhalb der Buildchain statische Aspekte seines Docker Containers zu prüfen, ist hiermit gut bedient.

Mit serverspec und dem Docker-Backend

Serverspec (bzw. SpecInfra) besitzt in seiner Architektur einen Backend-Teil. In diesem Backend wird unterschieden, wie die Spec-Kommandos auf dem Ziel ausgeführt werden soll (Beispiel: SSH). Seit SpecInfra v0.4.0 gibt es ein Docker-Backend, das wiederum auf dem docker-api gem aufbaut.

Es nimmt ein existierendes Image und ändert darin den "CMD"-Aufruf so ab, dass nicht der im Image definierte Zielprozess gestartet wird, sondern der Prüfbefehl, den serverspec gerade ausführen möchte. Der Container wird gestartet, der Befehl ausgeführt, das Ergebnis zurückgeliefert und von Serverspec bearbeitet.

Wir probieren es aus. Als erstes installieren wir das docker-api gem, dabei wird mkmf aus ruby-dev vorausgesetzt:

$ cd serverspec-docker-test

$ sudo apt-get install ruby-dev
[...]

$ sudo gem install docker-api
Building native extensions.  This could take a while...
Fetching: archive-tar-minitar-0.5.2.gem (100%)
Fetching: docker-api-1.13.2.gem (100%)
Successfully installed json-1.8.1
Successfully installed archive-tar-minitar-0.5.2
Successfully installed docker-api-1.13.2
3 gems installed
Installing ri documentation for json-1.8.1...
Installing ri documentation for archive-tar-minitar-0.5.2...
Installing ri documentation for docker-api-1.13.2...
Installing RDoc documentation for json-1.8.1...
Installing RDoc documentation for archive-tar-minitar-0.5.2...
Installing RDoc documentation for docker-api-1.13.2...

Dann muss Serverspec mitgeteilt werden, dass statt SSH ein Docker-Container geprüft wird, und auch, welcher Container es sein soll. Das ganze spielt sich in der Datei spec_helper.rb ab:

require 'serverspec'

# - - - - - Docker einbauen (statt Exec-Helper)- - - - -
include SpecInfra::Helper::Docker
# - - - - - Docker einbauen (statt Exec-Helper)- - - - -
include SpecInfra::Helper::DetectOS

RSpec.configure do |c|
  # - - - - - Image setzen - - - - -
  c.docker_image = '9590610349ba'
  # - - - - - Image setzen - - - - -

  if ENV['ASK_SUDO_PASSWORD']
    require 'highline/import'
    c.sudo_password = ask("Enter sudo password: ") { |q| q.echo = false }
  else
    c.sudo_password = ENV['SUDO_PASSWORD']
  end
end

Und ausführen:

$ rake spec
/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb
FFFFFF

Failures:

  1) Package "httpd" should be installed
[...]  

Finished in 1 minute 13.09 seconds
6 examples, 6 failures
[...]

Den ersten Unterschied den man bemerkt, ist der deutlich höhere Zeitaufwand zum prüfen. Schließlich wird für jeden Prüfbefehl (das können mehrere je describe-Block der Spec sein) ein neuer Container instanziiert.

Ein Nachweis gelingt indirekt über docker ps -a:

$ sudo docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS                        PORTS               NAMES
16643fab8e17        9590610349ba        "/bin/sh -c 'netstat   13 seconds ago      Exited (1) 12 seconds ago                         mad_goldstine
[...]

In der COMMAND-Spalte sieht man z.B. die Ausführen des netstat-Kommandos aus der Spec (port(80), it { should be_listening }). Es handelt sich um eine bereits abgelaufenen Container, da er nach Beendigung des Serverspec-Prüfkommandos natürlich gestoppt ist.

Vorteile:

Man muss serverspec im Container nicht installieren, es reicht die Installation auf dem Host.

Nachteile:

Das Setzen der Container-ID im spec_helper ist in dieser Form unschön, d.h. man benötigt weiteren Code um z.B. Ziel-Images abzufragen oder als Parameter entgegen zu nehmen.
Es lassen sich wieder nur statische Aspekte prüfen, da der eigentliche Zielprozess nicht ausgeführt, sondern durch serverspec ersetzt wird.

Fazit: Schon besser, da der Container so ohne Serverspec-Overhead auskommt. Aber es lässt sich immer noch kein laufender Service prüfen.

nsenter

Die nächste Stufe besteht darin, in einen laufenden Container hineinzuschauen und dabei die Spec auszuführen.

Hierbei hilft nsenter. Die Installation ist im Blogeintrag von Alexander Berresch sehr schön beschrieben. nsenter liegt auch als Docker-Container von @jpetazzo vor. Wir wählen die manuelle Installationsvariante:

$ curl --silent https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf-
$ cd util-linux-2.24
$ ./configure --without-ncurses
$ make nsenter
$ sudo cp nsenter /usr/local/bin

Eine genaue Beschreibung von nsenter führt an der Stelle zu weit, dafür sei auf die Blogeinträge verwiesen. In a nutshell: nsenter startet einen neuen Prozess und setzt ihn in die Namespaces eines existierenden Containers.

Wir starten einen Container und ermitteln seine Prozess-ID.

Vorsicht: Die Spaces zwischen den geschwungenen Klammern bei .State.Pid gehören da nicht hin, aber ohne Space werden sie vom Markup verschluckt.:

$ docker run -tdi ubuntu:14.04
2c67dc16c6f0c1d90e53f5836b7c1de461578b63f903fd4454fafb32b02706f8

$ PID=$(docker inspect --format '{ { .State.Pid }}'  2c67dc16c6f0c1d90e53f5836b7c1de461578b63f903fd4454fafb32b02706f8)
$ echo $PID
9452

Dann wird nsenter ausgeführt. Die Parameter stehen für die Namespaces, die der neue Prozess erben soll:

$ sudo nsenter --target $PID --mount --uts --ipc --net --pid '/bin/sh'
# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 19:16 ?        00:00:00 /bin/bash
root        29     0  0 19:23 ?        00:00:00 /bin/sh
root        30    29  0 19:23 ?        00:00:00 ps -ef

D.h. man erhält eine Shell, die in der Prozessliste auch sichtbar ist (PID 1=Containerprozess, PID 29=über nsenter gestartetes /bin/sh).

Nun könnte man serverspec ausführen, wenn es vorhanden wäre. Leider hat die neue Shell den Mount-Namespace des Containers geerbt, und damit nur Zugriff auf das Dateisystem innerhalb Containers und serverspec liegt außerhalb.

Um dennoch etwas testen zu können, verwenden wir das gebaute Image aus dem ersten Beispiel, in dem ruby und serverspec installiert wurde, also das Images mit der ID 9590610349ba.

$ docker run -tdi 9590610349ba
c84aaa2adeadda9f1ea1fe080110e25b5d68b151aadbe4706ad0538208d82cc9
$ PID=$(docker inspect --format ' { {.State.Pid }} ' c84aaa)
$ echo $PID
9680

Dann kann man über nsenter einen neuen Prozess im Container starten und serverspec ausführen:

$ sudo nsenter --target $PID --mount --uts --ipc --net --pid '/bin/bash'

root@c84aaa2adead:/# cd /opt/spec.d/

root@c84aaa2adead:/opt/spec.d# rake spec
/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb
dpkg-query: no packages found matching httpd
FFhttpd: unrecognized service
FFFF
[...]

Finished in 0.21691 seconds
6 examples, 6 failures

Das liefert ebenfalls Fehler, da der HTTP-Server nicht installiert ist. Da wir die Spezifikation aber in einem laufenden Container hineingebeamt und gestartet haben, können auch dynamische Aspekte des Zielservice mit abgeprüft werden.

Das ganze kann man natürlich auch abkürzen und in den nsenter Aufruf packen:

$ sudo nsenter --target $PID --mount --uts --ipc --net --pid -- /bin/bash -c 'cd /opt/spec.d && rake'

Vorteile:

Dynamische Aspekte sind in der Spec nun auch prüfbar, da man sich zur Laufzeit auf einen Container aufschalten kann.

Nachteile:

Die Installation von nsenter auf dem Docker Host ist notwendig.
Serverspec muss im Container installiert sein.

Fazit: Hier ergeben sich noch nicht soviele Vorteile gegenüber der Variante mit dem Docker-Backend in Serverspec.

nsenter + serverspec

Jetzt bleibt noch die Möglichkeit, nsenter in serverspec, genaugenommen im Projekt specinfra, als Backend zu integrieren. Serverspec unterstützt das aktuell noch nicht, wir probieren es als Prototyp.

Dabei wird eine neue Backend-Klasse Nsenter implementiert und registriert. Sie erhält einen Parameter, die nsenter_pid, damit das Backend weiss, wo der Container liegt.

$ cd
$ mkdir nsenter-proto
$ cd nsenter-proto
$ git clone https://github.com/serverspec/specinfra
Cloning into 'specinfra'...
remote: Counting objects: 5305, done.
Receiving objects: 100% (5305/5305), 628.18 KiB | 473.00 KiB/s, done.
remote: Total 5305 (delta 0), reused 0 (delta 0)
Resolving deltas: 100% (2810/2810), done.
Checking connectivity... done.
$ cd specinfra/lib/specinfra
$ vi backend.rb

.. anfügen ..
require 'specinfra/backend/nsenter'

$ vim helper/backend.rb

... den Typ 'Nsenter' einfügen ...

module SpecInfra
  module Helper
    ['Exec', 'Nsenter', 'Ssh', 'Cmd', 'Docker', 'WinRM', 'ShellScript', 'Dockerfile', 'Lxc'].each do |type|

$ vim configuration.rb

... den Konfigurationsparameter `nsenter_pid` ans `Array VALID_OPTIONS_KEYS` anfügen ...

module SpecInfra
  module Configuration
    class << self
      VALID_OPTIONS_KEYS = [
        :path,
[...]
        :request_pty,
        :nsenter_pid,

# Eine Prototyp-Version von nsenter für specinfra liegt als gist vor
# https://gist.github.com/aschmidt75/bb38d971e4f47172e2de
$ curl https://gist.githubusercontent.com/aschmidt75/bb38d971e4f47172e2de/raw/350f9419159ffba282496f90232110e06b77cf69/specinfra_nsenter_prototype >backend/nsenter.rb

# das neue gem muss gebaut werden, der falsche wercker.yml link stört.
$ cd ../..
$ rm wercker.yml
$ touch wercker.yml

# Das Gem-Build kommando verlässt sich auf git ls-files, also added wir es
# im lokalen Repository

$ git add .
$ git commit -m "added nsenter backend"

# das wird gebaut und installiert.
$ gem build specinfra.gemspec --force
  Successfully built RubyGem
  Name: specinfra
  Version: 1.27.0
  File: specinfra-1.27.0.gem

$ sudo gem install specinfra-1.27.0.gem
Successfully installed specinfra-1.27.0
1 gem installed
Installing ri documentation for specinfra-1.27.0...
Installing RDoc documentation for specinfra-1.27.0...

Dazu erstellen wir eine kleine Spezifikation und starten ein Docker-Image:

$ cd
$ cd nsenter-proto
$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile

Zu Testzwecken wird die Spezifikation verkleinert:

  $ vim spec/localhost/httpd_spec.rb

require 'spec_helper'

describe package('apache2') do
  it { should be_installed }
end

Ein Image wird gestartet, wir brauchen die PID:

$ docker run -tdi ubuntu:14.04
9367d023570d4670ca1d12aa431bb826a131a1dcc0b02797a90372489d7927a6
vagrant@docker-workshop:~/nsenter-proto$ docker inspect -f '{ { .State.Pid }}' 9367d0
15344

Der spec_helper wird auf nsenter umgestellt, und die PID 15344 wird mitgegeben:

$ vim spec/spec_helper.rb

require 'serverspec'

# - - - - - NSENTER verwenden - - - - -
include SpecInfra::Helper::Nsenter
# - - - - - nach problemen mit DetecOs
# wird hier Debian explizit gesetzt - - -
include Serverspec::Helper::Debian

RSpec.configure do |c|

  # - - - - - PID für NSENTER aus Environment - - - - -
  c.nsenter_pid = ENV['NSENTER_PID']

  if ENV['ASK_SUDO_PASSWORD']

Der spannende Moment beginnt:

$ NSENTER_PID=15344 rake spec
/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb
nsenter_exec! sudo dpkg-query -f '${Status}' -W apache2 | grep -E '^(install|hold) ok installed$'
F

Failures:

  1) Package "apache2" should be installed
     On host ``
     Failure/Error: it { should be_installed }
       sudo dpkg-query -f '${Status}' -W apache2 | grep -E '^(install|hold) ok installed$'
       expected Package "apache2" to be installed
     # ./spec/localhost/httpd_spec.rb:4:in `block (2 levels) in <top (required)>'

Finished in 0.02865 seconds
1 example, 1 failure

Die Debug-Ausgabe nsenter_exec! zeigt, dass das neue nsenter-Backend aufgerufen wird. Die spec liefert natürlich Fehler, weil der Apache nicht installiert ist.

Wir einem Docker attach kommen wir in den laufenden Container und installieren das httpd Package nach:

$ docker attach 9367


root@9367d023570d:/# apt-get update -yqq
root@9367d023570d:/# apt-get -yqq install apache2
Preconfiguring packages ...
[...]

[CRTL-P], [CTRL-Q] drücken, um zu detachen

Und die Spec erneut ausführen:

$ NSENTER_PID=15344 rake spec
/usr/bin/ruby1.9.1 -S rspec spec/localhost/httpd_spec.rb
nsenter_exec! sudo dpkg-query -f '${Status}' -W apache2 | grep -E '^(install|hold) ok installed$'
.

Finished in 0.05324 seconds
1 example, 0 failures

Das hat funktioniert.

Vorteile:

Wenn nsenter als Backend in serverspec integriert wäre, könnte man so sehr einfach laufende Container testen, d.h. mit allen statischen und dynamischen Aspekten.
serverspec muss nicht im Container installiert sein, es reicht wenn die Prüfkommandos im Container funktionieren.

Nachteile:

Der Aufruf von serverspec klappt nur noch als Root bzw. mit sudo-Rechte auf nsenter.
Es wird nsenter als zusätzliches Paket auf dem Host benötigt.
Die Integration der Prozess-PID in spec_helper erfordert noch geeignete Wrapper.

Fazit: Whew, what a ride. In a nutshell: Don't try this at home!

Der Prototyp hat zwar in Bezug auf Ubuntu und den Apache2-Package-Test funktioniert, er besitzt aber noch keine Testabdeckung und deckt sicherlich nicht alle Eventualitäten ab. Wenn nsenter als regulär installierbares Paket in die Package-Repositories der Distributionen aufgenommen wird und Serverspec ggf. ab Version 2.X ein nsenter-backend mitbringt, kann das ein sinnvoller Weg sein, um Container zu testen.

Testbarkeit: Gegeben!

Insgesamt sieht die Testbarkeit von Container-Images über serverspec gar nicht schlecht aus.

Zumindest die statischen Aspekte lassen sich über den Ansatz im Dockerfile und mit dem Docker-Backend von serverspec gut abtesten.
Wer Container als VM-Ersatz betreibt, hat in der Regel volle Testbarkeit über den SSH-Zugang.
Sobald die Entwicklung um nsenter fortgeschritten ist lässt sich die volle Testbarkeit sicherlich auch für den Microservice-Container-Ansatz erreichen.
Um auf einer Maschine unterschiedliche Projekte und Versionen der Testinfrastruktur ablaufen zu lassen empfehlen wir eine DockerInDocker Installation zu überlegen.

Viel Spaß beim Ausprobieren!

Andreas & Peter

Docker-Hosts mit Puppet provisionieren und testen

2014-07-24T00:00:00+02:00

Die ersten Schritte mit Docker gestalten sich durch boot2docker recht einfach, so hat man schnell eine Spielwiese erstellt, um die Funktionalität ausprobieren zu können. Aber spätestens wenn Docker-Container im Test- oder Produktionssystem live gestellt werden sollen, stellt sich die Frage nach dem reproduzierbaren Aufsetzen eines Docker-Hosts.

Da wir für dieses Beispiel gar nicht so viele Dinge zu installieren, bzw. konfigurieren haben, ist ein leichtgewichtiges Tool wie z.B. Ansible oder SaltStack naheliegend. Viele Unternehmen setzen allerdings seit geraumer Zeit auf Puppet, das allgemein bekannt sein dürfte.

Um die Hürde nicht zu hoch zu legen und zuviel Veränderung auf einmal anzubringen, bauen wir dieses Beispiel mit Puppet auf. Um die Installation testbar zu bekommen, empfiehlt sich der Einsatz von serverspec. Wer noch nicht so vertraut mit ServerSpec ist, sollte unseren Einführungs- Post dazu kurz lesen.

Vagrant/Docker-Provisioner

Vagrant bietet selber einen Docker-Provisioner an. Dieser ist nicht zu verwechseln mit dem Docker-Provider, der Docker als Backend verwendet, damit Vagrant Container anstelle von VMs startet. Der Provisioner hingegen ist in der Lage, Docker auf der gestartetem VM zu installieren, mit Images zu bestücken und daraus Container zu starten. Die Konfiguration des Docker-Servers ist davon noch ausgenommen.

Das ist schon eine gute Abkürzung auf dem Weg in Richtung Reproduzierbarkeit, sie hängt allerdings auch davon ab, wie weit Vagrant in der Continuous Delivery Kette zum Einsatz kommt. Wenn z.B. das Livesystem auf einer Virtualisierung beruht, die nicht durch ein Vagrant-Backend unterstützt wird, kommt man mit dem Docker-Provisioner an der Stelle nicht weiter. Dann werden Entwicklungs- und vielleicht auch Testsystem nachvollziehbar bestückt, beim Sprung auf das Livesystem ergibt sich ein Bruch.

Puppet-Modul für Docker

Eine mögliche Lösung ist, Puppet für die Installation und Konfiguration des Docker-Servers zu verwenden. Ein Puppet-Modul kann getestet werden, lässt sich in Vagrant über den Puppet-Provisioner integrieren und auf allen Stages der Delivery-Chain nutzen.

Wenn man in der PuppetForge nach Docker sucht, wird man schnell bei dem Modul von Gareth Rushgrove fündig. Damit lässt sich Docker installieren, in Teilen konfigurieren, Images lassen sich herunterladen und Container können gestartet werden.

Und wir möchten die Installation natürlich mit Serverspec's testen, um nachhaltig zu beweisen das wir korrekt provisioniert haben.

Alle Schritte können mit dem Github-Repository aschmidt75/docker-testing-playground nachvollzogen werden. Im Text finden sich in den Abschnitten (Git-Tag)-Einträge, die auf Tags im Repository verweisen. So lassen sich einzelne Stände nachvollziehen.

Los geht's!

Mit der leere VM beginnen ...

Wir starten mit einem einfach Vagrant-Konfiguration, das eine einzelne VM auf Basis Ubuntu 14.04 aufbaut. Da wir auf einen fest benannten Paketstand aufsetzen möchten, führen wir kein Update durch. Sinnvoll ist es, hier genau das Image mit Werkzeugen wir z.B. Packer selber zu bauen und vorzuhalten, das man für den Betrieb der eigenen Plattform haben möchte.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "trusty64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/20140723/trusty-server-cloudimg-amd64-vagrant-disk1.box"

  config.vm.define "docker-test1", primary: true do |s|
  end

end

(Git-Tag v1)

Wer das ganze schnell ausprobieren möchte, kann sich den Code von github auschecken:

$ git clone https://github.com/aschmidt75/docker-testing-playground

Die einzelnen Stationen sind getagged, d.h. den obigen Stand v1 erhält man mit:

$ git checkout tags/v1
Note: checking out 'tags/v1'.
....
HEAD is now at 456090f... moved to test cmd

... Serverspec-Basis dazugeben ...

Die VM können wir mit vagrant up starten, wir sind aber noch nicht so richtig weit gekommen. Um unsere Installation testbar zu machen, benötigen wir serverspec. Es gibt ein Vagrant-Plugin für Serverspec, allerdings ist das Zusammenspiel mit verschiedenen Versionen von serverspec, Vagrant und dem Plugin noch nicht ideal. Außerdem möchten wir Serverspec-Spezifikation auch später ohne Vagrant weiterverwenden können. Von daher installieren wir mit einem Shell Provisioner Serverspec plus Abhängigkeiten und gehen davon aus, dass wir unsere Specs über eine Synced-Folder in die VM reinreichen. Bei den gems geben wir zumindest für serverspec, specinfra, rspec und rake feste Versionen an. Die beiden Projekte serverspec und specinfra sind aktuell sehr in der Entwicklung, also aufgepasst mit der Repoduzierbarkeit!

$ mkdir spec.d
$ vi Vagrantfile

    s.vm.synced_folder "spec.d/", "/mnt/spec.d"
(...)
    # install & run serverspec
    s.vm.provision 'shell', inline: <<EOS
( sudo gem list --local | grep -q serverspec ) || {
    sudo gem install rake -v '10.3.2'
    sudo gem install rspec -v '2.99.0'
    sudo gem install specinfra -v '1.21.0'
    sudo gem install serverspec -v '1.10.0'
}
cd /mnt/spec.d
rake spec

EOS

(Git-Tag v2)

Die Vagrant VM muss wg. des Mounts neu gestartet und provisioniert werden:

$ vagrant reload
$ vagrant provision
(...)
==> docker-test1: Running provisioner: shell...
    docker-test1: Running: inline script
==> docker-test1: stdin: is not a tty
==> docker-test1: Successfully installed specinfra-1.21.0
==> docker-test1: Successfully installed net-ssh-2.9.1
(...)
==> docker-test1: rake aborted!
==> docker-test1: No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
==> docker-test1: (See full trace by running task with --trace)

... Spezifikation formulieren ...

D.h. serverspec wurde installiert, aber da keine Specs vorhanden sind, kann der rake spec-Aufruf natürlich noch nichts tun. Wir legen uns auf dem Host über serverspec-init eine leere Spezifikations-Hülle hin, das HTTP-Beispiel wird durch das ersetzt, was wir testen wollen:

$ cd spec.d
$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

 + spec/
 + spec/localhost/
 + spec/localhost/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile
$ rm spec/localhost/httpd_spec.rb
$ vim spec/localhost/docker_spec.rb

require 'spec_helper'

describe 'It should have docker installed' do
end

(Git-Tag v3)

Ein vagrant provision zeigt nun:

 vagrant provision
==> docker-test1: Running provisioner: shell...
    docker-test1: Running: inline script
==> docker-test1: stdin: is not a tty
==> docker-test1: Running provisioner: shell...
    docker-test1: Running: inline script
==> docker-test1: stdin: is not a tty
==> docker-test1: /usr/bin/ruby1.9.1 -S rspec spec/localhost/docker_spec.rb
==> docker-test1: No examples found.
==> docker-test1:
==> docker-test1: Finished in 0.00006 seconds
==> docker-test1: 0 examples, 0 failures

Im Spec-File können wir jetzt ausdrücken, wie Docker installiert sein sollte, z.B. so:

$ vim spec.d/spec/localhost/docker_spec.rb

und den leeren describe-Block ersetzen durch:

describe 'It should have docker installed' do
    describe package 'lxc-docker-1.1.1' do
        it { should be_installed }
    end

    describe group 'docker' do
        it { should exist }
    end

    describe file '/var/run/docker.sock' do
        it { should be_socket }
        it { should be_owned_by 'root' }
        it { should be_grouped_into 'docker' }
    end

    describe command 'docker -v' do
        its(:stdout) { should match '^Docker version 1\.1\.1.*' }
    end
end

Das entspricht der Standardinstallation über das Repository von Docker, zumindest für die Version 1.1.1, die wir haben möchten. Ein vagrant provision zeigt nun eine Menge Fehler, da ja noch nichts installiert ist.

$ vagrant provision
(...)
Finished in 0.10243 seconds
5 examples, 5 failures

Failed examples:

rspec ./spec/localhost/docker_spec.rb:5 # It should have docker installed Package "lxc-docker-1.1.1" should be installed
rspec ./spec/localhost/docker_spec.rb:9 # It should have docker installed Group "docker" should exist []
rspec ./spec/localhost/docker_spec.rb:13 # It should have docker installed File "/var/run/docker.sock" should be socket
rspec ./spec/localhost/docker_spec.rb:14 # It should have docker installed File "/var/run/docker.sock" should be owned by "root"
rspec ./spec/localhost/docker_spec.rb:15 # It should have docker installed File "/var/run/docker.sock" should be grouped into "docker"
(...)

(Git-Tag v4)

... Das Puppet-Modul hinzufügen ...

Wir möchte Docker über Puppet und das Puppetmodul aus der Forge installieren, d.h. es lohnt sich auch, das als Serverspec auszudrücken, um es dann umzusetzen. Die aktuelle Version ist 1.1.3:

$ vim spec.d/spec/localhost/puppet_spec.rb
(..einfügen..)
require 'spec_helper'

describe package 'puppet' do
    it { should be_installed }
end

describe 'It should have the garethr-docker module' do
    describe file '/etc/puppet/modules/docker' do
        it { should be_directory }
        it { should be_mode '755' }
    end

    describe command 'puppet module list' do
        its(:stdout) { should match 'garethr-docker.*1\.1\.3' }
    end
end

Ein vagrant provision zeigt nun natürlich noch mehr Fehler an. Wir beheben das ganze, indem das Vagrantfile um einen Shell-Provisioner-Abschnitt ergänzt wird, der über puppet das Modul nachinstalliert, solange es noch nicht vorhanden ist. Wir wählen auch hier gezielt eine feste Version aus:

$ vi Vagrantfile
    # install puppet module for docker
    s.vm.provision "shell", inline:
        'sudo su - -c "( puppet module list | grep -q garethr-docker ) || puppet module install -v 1.1.3 garethr-docker"'

    # install & run serverspec
(...)

$ vagrant provision
(...)
==> docker-test1: Running provisioner: shell...
    docker-test1: Running: inline script
==> docker-test1: stdin: is not a tty
==> docker-test1: stdin: is not a tty
==> docker-test1: Notice: Preparing to install into /etc/puppet/modules ...
==> docker-test1: Notice: Downloading from https://forge.puppetlabs.com ...
==> docker-test1: Notice: Installing -- do not interrupt ...
==> docker-test1: /etc/puppet/modules
==> docker-test1: └─┬ garethr-docker (v1.1.3)
==> docker-test1:   ├── puppetlabs-apt (v1.5.1)
==> docker-test1:   ├── puppetlabs-stdlib (v4.3.0)
==> docker-test1:   └── stahnma-epel (v0.1.0)
(...)
Finished in 1.11 seconds
9 examples, 5 failures

Failed examples:
(...)

(Git-Tag v5)

... und Docker über Puppet installieren lassen

Im Serverspec-Teil sind allerdings die vier Examples für Puppet grün, nur die Docker-Examples sind rot. Also müssen wir jetzt Docker installieren. Dazu bauen wir ein Puppet-Modul, welches über den Puppet-Provisioner in Vagrant ausgerollt wird. Erst einmal eine leere Hülle:

$ mkdir puppet.d
$ mkdir puppet.d/manifests
$ mkdir puppet.d/modules
$ vim puppet.d/manifests/default.pp
(..einfügen..)

notify { "Running puppet apply on $hostname": }

$ vi Vagrantfile
(..einfügen..)

    # provision the node
    s.vm.provision :puppet, :options => "--verbose" do |puppet|
        puppet.manifests_path = "puppet.d/manifests"
        puppet.module_path = "puppet.d/modules"
        puppet.manifest_file = "default.pp"
    end

    # install & run serverspec
(...)

Da der Puppet-Provisioner intern über Vagrant einen Synced-Folder erzeugt, müssen wir die VM reloaden, danach kann provisioniert werden:

$ vagrant reload
(...)
$ vagrant provision
(...)
==> docker-test1: Running provisioner: puppet...
==> docker-test1: Running Puppet with default.pp...
==> docker-test1: stdin: is not a tty
(...)
==> docker-test1: Notice: Compiled catalog for vagrant-ubuntu-trusty-64 in environment production in 0.03 seconds
(...)
==> docker-test1: Info: Applying configuration version '1405518114'
==> docker-test1: Notice: Running puppet apply on vagrant-ubuntu-trusty-64
==> docker-test1: Notice: /Stage[main]/Main/Notify[Running puppet apply on vagrant-ubuntu-trusty-64]/message: defined 'message' as 'Running puppet apply on vagrant-ubuntu-trusty-64'
==> docker-test1: Info: Creating state file /var/lib/puppet/state/state.yaml
==> docker-test1: Notice: Finished catalog run in 0.03 seconds

(...)

(...Fehler von serverspec, weil Docker noch nicht installiert ist...)

(Git-Tag v6)

Damit fehlt jetzt "nur" noch das was eigentlich wollten, nämlich Docker auch zu installieren :-) Das geht mit dem Modul aus der Puppetforge sehr einfach. Wir implementieren ein Modul, bestehend aus Subklassen install, run in eigenen .pp-Dateien und der Abhängigkeit. Im install-Bereich kommt die Docker-Klasse ins Spiel, wo die Konfiguration des Servers gesetzt werden kann.

$ mkdir -p puppet.d/modules/docker_host/{manifests,templates}
$ vi puppet.d/modules/docker_host/manifests/init.pp
class docker_host {
  notify { 'in docker_host': }

  class { 'docker_host::install': }

  class { 'docker_host::run': }

  Class['docker_host::install'] -> Class['docker_host::run']
}
$ vi puppet.d/modules/docker_host/manifests/install.pp
include 'docker'

class docker_host::install {
  class { 'docker':
    version       => '1.1.1',
    manage_kernel => false,
    tcp_bind      => 'tcp://127.0.0.1:2375',
    socket_bind   => 'unix:///var/run/docker.sock',
  }
}
$ vi puppet.d/modules/docker_host/manifests/run.pp
class docker_host::run {
}
$ vi puppet.d/manifests/default.pp
(...einfügen..)
class { 'docker_host': }

(Git-Tag v7)

Ein vagrant provision dauert nun schon etwas länger, da Docker nun auch installiert wird:

==> docker-test1: Notice: Running puppet apply on vagrant-ubuntu-trusty-64
==> docker-test1: Notice: /Stage[main]/Main/Notify[Running puppet apply on vagrant-ubuntu-trusty-64]/message: defined 'message' as 'Running puppet apply on vagrant-ubuntu-trusty-64'
==> docker-test1: Notice: /Stage[main]/Docker::Install/Package[cgroup-lite]/ensure: ensure changed 'purged' to 'present'
==> docker-test1: Notice: /Stage[main]/Docker::Install/Apt::Source[docker]/Apt::Key[Add key: A88D21E9 from Apt::Source docker]/Apt_key[Add key: A88D21E9 from Apt::Source docker]/ensure: created
==> docker-test1: Notice: in docker_host
==> docker-test1: Notice: /Stage[main]/Docker_host/Notify[in docker_host]/message: defined 'message' as 'in docker_host'
==> docker-test1: Notice: /Stage[main]/Docker::Install/Apt::Source[docker]/Apt::Pin[docker]/File[docker.pref]/ensure: created
==> docker-test1: Notice: /Stage[main]/Docker::Install/Apt::Source[docker]/File[docker.list]/ensure: created
==> docker-test1: Info: /Stage[main]/Docker::Install/Apt::Source[docker]/File[docker.list]: Scheduling refresh of Exec[apt_update]
==> docker-test1: Info: /Stage[main]/Docker::Install/Apt::Source[docker]/File[docker.list]: Scheduling refresh of Exec[Required packages: 'debian-keyring debian-archive-keyring' for docker]
==> docker-test1: Notice: /Stage[main]/Docker::Install/Apt::Source[docker]/Exec[Required packages: 'debian-keyring debian-archive-keyring' for docker]: Triggered 'refresh' from 1 events
==> docker-test1: Notice: /Stage[main]/Apt::Update/Exec[apt_update]: Triggered 'refresh' from 1 events
==> docker-test1: Notice: /Stage[main]/Docker::Install/Package[docker]/ensure: ensure changed 'purged' to 'present'
==> docker-test1: Info: /Stage[main]/Docker::Service/File[/etc/default/docker]: Filebucketed /etc/default/docker to puppet with sum ce88dab1dcba6f92903120b9beba2521
==> docker-test1: Notice: /Stage[main]/Docker::Service/File[/etc/default/docker]/content: content changed '{md5}ce88dab1dcba6f92903120b9beba2521' to '{md5}c44278611ed762b2de4b5b78cda333e6'
==> docker-test1: Info: /Stage[main]/Docker::Service/File[/etc/default/docker]: Scheduling refresh of Service[docker]
==> docker-test1: Info: /Stage[main]/Docker::Service/File[/etc/init.d/docker]: Filebucketed /etc/init.d/docker to puppet with sum d9d2305259b22bfbc1086939a23df23a
==> docker-test1: Notice: /Stage[main]/Docker::Service/File[/etc/init.d/docker]/ensure: removed
==> docker-test1: Info: /Stage[main]/Docker::Service/File[/etc/init.d/docker]: Scheduling refresh of Service[docker]
==> docker-test1: Notice: /Stage[main]/Docker::Service/Service[docker]: Triggered 'refresh' from 2 events
==> docker-test1: Notice: Finished catalog run in 148.66 seconds

... und die Specs ...

==> docker-test1: /usr/bin/ruby1.9.1 -S rspec spec/localhost/docker_spec.rb spec/localhost/puppet_spec.rb
(...)
==> docker-test1: Finished in 0.9264 seconds
==> docker-test1: 9 examples, 0 failures

Fertig!

9 Examples, 0 Failures: geschafft. Wir haben jetzt eine virtuelle Maschine, die

Puppet und das Docker-Modul beinhaltet,
ein lauffähigen Docker-Server über Puppet installiert hat und
das ganze mit Hilfe von Serverspec testbar macht.

Wenn man die Serverspec-Ausgabe detailliert mitverfolgen möchte, hilft ein --format-Eintrag im Rakefile:

$ vi spec.d/Rakefile
RSpec::Core::RakeTask.new(:spec) do |t|
  t.pattern = 'spec/*/*_spec.rb'
  t.rspec_opts = '--format documentation'
end

Damit kann man serverspec bei der Arbeit zusehen, allerdings kann die Ausgabe mit steigendem Umfang der Spec auch recht lang werden. Zu Debugging-Zwecken lohnt es sich allerdings sehr.

Wir können jetzt damit fortfahren, die Spezifikation wasserdicht zu machen, und alle Einstellungen, die wir über das Puppet-Modul in die Docker-Konfiguration einbringen können, auch abzutesten. Das werden wir nicht im Detail erläutern, wer mag, checkt sich den Master-Branch aus und schaut sich die Specs an.

Am Ende haben wir die Basis für eine vollautomatische und nachvollziehbare Installation eines Docker-Hosts.

Andreas & Peter

Docker entschlüsselt: Netzwerk-Teil 2

2014-07-11T00:00:00+02:00

Im ersten Teil von "Docker entschlüsselt: Netzwerk" haben wir gesehen, wie der Docker-Daemon Netzwerkinterfaces, die docker0-Bridge und die Kommunikation der Container nach außen und untereinander managed.

Im zweiten Teil sollen nun die Grundlagen geschaffen werden, damit Docker-Container auch über Host-Grenzen hinweg kommunizieren können. Dafür gibt es mehrere Möglichkeiten (z.B. die Default-Bridge docker0 an ein externes Interface anzuschließen oder das iptables-Regelwerk zu erweitern), wir wählen diejenige, welche mit der Standardkonfiguration des Docker-Daemon funktioniert.

Der Plan: Eine neue Bridge anlegen

Ziel ist es, auf zwei virtuellen Maschinen je einen Docker Container zu instanziieren. Dieser Container wird mit einem neuen eth1 Netzwerkinterface versorgt, das über eine eigene br1 Netzwerk-Bridge mit einem eth1 Netzwerkinterface des Hosts verbunden ist:

Voraussetzungen

Um ein solches Setup schnell aufzusetzen, empfiehlt sich die Kombination aus Vagrant und Virtualbox. Als Basis kann dafür unser DockerBox - Projekt auf github dienen. Dazu das passende Vagrantfile für zwei VMs auf Basis Ubuntu:

Vagrant.configure("2") do |config|
  # https://vagrantcloud.com/stamm/trusty64-dockeattr_reader :attr_names
  config.vm.box = "trusty64"
  config.vm.box_url = "http://cloud-images.ubuntu.com/vagrant/trusty/current/trusty-server-cloudimg-amd64-vagrant-disk1.box"

  config.vm.define "docker-test1", primary: true do |s|
    s.vm.network "private_network", ip: "192.168.77.5"
    s.vm.provider "virtualbox" do |vb|
      vb.customize [ 'modifyvm', :id, '--nicpromisc2', 'allow-all']
      vb.gui = false
      vb.customize [ "modifyvm", :id, "--memory", "512"]
      vb.customize [ "modifyvm", :id, "--cpus", "1"]
    end
  end

  config.vm.define "docker-test2", primary: true do |s|
    s.vm.network "private_network", ip: "192.168.77.6"
    s.vm.provider "virtualbox" do |vb|
      vb.customize [ 'modifyvm', :id, '--nicpromisc2', 'allow-all']
        vb.gui = false
        vb.customize [ "modifyvm", :id, "--memory", "512"]
        vb.customize [ "modifyvm", :id, "--cpus", "1"]
        end
  end
end

Das besondere liegt in der Definition eines zusätzlichen Netzwerkinterfaces eth1, dass im weiteren in den Promisc-Mode geschaltet wird:

 s.vm.network "private_network", ip: "192.168.77.5"
 s.vm.provider "virtualbox" do |vb|
       vb.customize [ 'modifyvm', :id, '--nicpromisc2', 'allow-all']

Auf der Seite des Hosts wird dazu eine Host-Only Bridge erzeugt (z.B. vnet1), an dem diese virtuellen Netzwerkinterfaces angeklemmt sind.

Nach Starten der VMs kann man sich das Ergebnis anschauen:

$ vagrant up
....
$ vagrant ssh docker-test1
....
$ ip addr show
...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
    link/ether 08:00:27:a5:83:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.5/24 brd 192.168.77.255 scope global eth1
       valid_lft forever preferred_lft forever

In den beiden VMs werden nun noch Pakete, u.a. docker, nach installiert:

$ sudo apt-get -y update
$ sudo apt-get -y install curl git openssl ca-certificates make bridge-utils arping
$ sudo apt-get install -y docker.io
$ sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker

Alternativ kann die DockerBox eingesetzt werden, dort muss nur das Paket bridge-utils nachinstalliert werden.

Um mit dem Docker-Containern zu experimentieren, ziehen wir das Ubuntu-Image:

$ sudo -i
~# docker pull ubuntu:latest

Und instanziieren einen neuen Docker-Container, lassen ihn im Vordergrund geöffnet.

~# docker run -t -i ubuntu:latest /bin/bash

Um das Ziel zu erreichen, benötigt jeder Container ein neues Netzwerkinterface. Außerdem soll auf den VMs eine neue Bridge existieren, die an das VM-Interface mit dem privaten Netzwerk angeschlossen ist.

Den größten Teil dieser Arbeit kann dabei Pipework übernehmen.

Pipework

Bei pipework handelt es sich um ein Shell-Skript, das sich um genau diese Aufgaben kümmert:

Anlegen einer Bridge auf dem Host
Anlegen eines Netzwerkinterfaces im Container, zugeordnet zu dessen Namenspace
Anlegen eines (Peer-)Netzwerkinterfaces auf dem Host, verknüpft zum Interface im Container
Anklemmen des Host-Interfaces an die Bridge

Dabei versteht es sich mit der Linux Bridge und Open vSwitch und bietet weitreichende Möglichkeiten.

Auf den VMs kann pipework folgendermassen installiert werden:

$ sudo -i
~# git clone https://github.com/jpetazzo/pipework
~# cd pipework

Um einen Container mit einem neuen Netzwerkinterface zu versorgen, brauchen wir jeweils seine Container ID.

~# docker ps
....
~# CID=<Container-ID einsetzen>

Jetzt geben wir dem Container ein neues Interface, mit einer IP-Adresse

~# ./pipework br0 $CID 192.168.77.10/24
# bzw. auf der zweiten VM:
~# ./pipework br0 $CID 192.168.77.20/24

In der (noch offenen, s.o.) Container-Shell lässt sich das nachprüfen:

$ ip addr show eth1
20: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether be:fc:f1:47:02:2a brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.10/24 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::bcfc:f1ff:fe47:22a/64 scope link
       valid_lft forever preferred_lft forever

D.h. pipework hat uns ein passendes Interfaces erzeugt und mit einer IP versorgt. Auf dem Host lässt sich der Zustand der Bridge anzeigen:

~# brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.0800273bcbbb   no    pl5330eth1

Es ist zu sehen, dass auf der docker0-Bridge ein veth-Interface angebunden ist (im Container: eth0), und auf der neuen br0-Bridge ein anderes virtuellees-Interface, das im Container dem neuen eth1 entspricht. Pipework vergibt dabei Interface-Namen, die mit "pl" prefixed sind.

Anzeige der Bridge-/Interface-Struktur

Mit einem Ruby-Skript lässt sich der Zusammenhang zwischen Bridges, Interfaces auf dem Host und in den Container anzeigen:

~# git clone https://github.com/aschmidt75/docker-network-inspect
~# cd docker-network-inspect/lib/
~# ./docker-network-inspect.rb $CID
CONTAINER 6437709a4ea2
+ PID 5330
+ INTERFACES
 + lo (1)
 + eth0 (5)
  + HOST PEER veth6166 (6)
   + BRIDGE
 + eth1 (8)
  + HOST PEER pl5330eth1 (9)
   + BRIDGE br0

Container über VM-Grenzen verbinden

Um die Container auf den beiden VMs miteinander sprechen zu lassen, wird eine Verbindung der beiden neuen Bridges notwendig. Dazu liegen auf den VMs die Host-Interfaces (eth1) bereit. Wichtig ist, dass diese Interfaces und die Interfaces der Container im selben Subnetz liegen (hier: 192.168.77.0/24)

In den VMs verbinden wir das jeweilige eth1 mit der Bridge br0

~# brctl addif br0 eth1
~# brctl show br0
bridge name bridge id       STP enabled interfaces
br0     8000.0800273bcbbb   no      eth1
                            pl5330eth1

Im Container selber lässt sich nun die IP des jeweils anderen Docker-Containers auf der anderen VM anpingen:

Tipp: Auf die richtige IP in der jeweiligen VM achten!

Im Docker-Container auf der docker-test1-VM hilft folgender Test:

~# ping 192.168.77.20
PING 192.168.77.20 (192.168.77.20) 56(84) bytes of data.
64 bytes from 192.168.77.20: icmp_seq=1 ttl=64 time=0.364 ms
64 bytes from 192.168.77.20: icmp_seq=2 ttl=64 time=0.524 ms
^C
--- 192.168.77.20 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.364/0.444/0.524/0.080 ms

Im Docker-Container auf der docker-test2-VM hilft folgender Test:

~# ping 192.168.77.10
PING 192.168.77.10 (192.168.77.10) 56(84) bytes of data.
64 bytes from 192.168.77.10: icmp_seq=1 ttl=64 time=0.401 ms
64 bytes from 192.168.77.10: icmp_seq=2 ttl=64 time=0.675 ms
^C
--- 192.168.77.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.401/0.538/0.675/0.137 ms

Fazit

Das automatische Verlinken von Docker-Containern ist im Docker-Daemon aktuell nur auf demselben Host möglich. Das Verbinden von Containern über Hostgrenzen hinweg ist zur Zeit noch etwas manueller Aufwand. Wir dürfen gespannt sein, wann das Docker-Team bzw. die Community auch hier eine Lösung anbieten werden.

Wer das obige Setup automatisiert aufsetzen möchte, findet in meinem Network Playground mit dem Simple-Setup eine vorbereitete Lösung zum Ausprobieren.

Im Prinzip ist man mit Pipework in der Lage, komplexere Netzwerkarchitekturen aufzubauen. Einen weiteren Schritt in Richtung Netzwerkvirtualisierung und Software-Defined Network stellt Open vSwitch dar. Das werden wir im nächsten Post weiter beleuchten.

Andreas

Docker entschlüsselt: Netzwerk

2014-07-06T00:00:00+02:00

Wenn man mit Docker experimentiert, kann man außerordentlich schnelle Erfolge erzielen. Der Docker-Daemon sorgt im Hintergrund dafür, dass viele notwendige Dinge wie Dateisysteme und Netzwerk einfach geregelt sind. So wundert man sich auch nicht, dass ein neu gebauter Container Netzwerkzugriff ins Internet hat, um z.B. Pakete zu installieren.

Aber wie funktioniert das eigentlich genau? In diesem Post möchten wir das Thema Netzwerk mit Docker ein wenig beleuchten.

Die Beispiele gehen von einem Ubuntu 14.04 LTS mit installiertem und lauffähigem Docker aus. Der boot2docker Post erklärt, wie man mit Hilfe von boot2docker schnell eine Docker-Spielwiese aufbauen kann. Da im Tiny Linux zur Zeit das Tooling für das Netzwerk fehlt, haben wir uns entschlossen lieber direkt eine eigene Linux Installation mit Vagrant und Virtualbox aufzusetzen. Unser Projekt dockerbox erfüllt diesen Zweck.

Das Netzwerk im Docker-Container

Wenn man einen einfachen Container mit einer Shell als Prozess startet, kann man im Container und auf dem Host nachschauen, was sich netzwerktechnisch dort abspielt:

~# docker run -t -i ubuntu /bin/bash
root@4de56414033f:/# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
37: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether e2:47:24:55:de:d4 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e047:24ff:fe55:ded4/64 scope link
       valid_lft forever preferred_lft forever

D.h. es gibt ein Loopback-Interface und ein eth0-Netzwerkinterface im Docker Container. Das eth0-Interface hat auch bereits eine IP-Adresse aus der Default-Range 172.17.0.0/16, nämlich die .2. Damit der Container "nach draußen" sprechen kann, benötigt er eine Route aus seiner Umgebung heraus über den Host ins Internet. Mit dem Befehl ip kann man sich Routen auch im Container anzeigen lassen. Man sieht, dass es eine entsprechende Default-Route mit der IP 172.17.42.1 angelegt ist:

root@4de56414033f:/# ip ro show
default via 172.17.42.1 dev eth0
172.17.0.0/16 dev eth0  proto kernel  scope link  src 172.17.0.2

root@4de56414033f:/# ping www.infrabricks.de
PING github.map.fastly.net (185.31.17.133) 56(84) bytes of data.
64 bytes from github.map.fastly.net (185.31.17.133): icmp_seq=1 ttl=61 time=46.2 ms
64 bytes from github.map.fastly.net (185.31.17.133): icmp_seq=2 ttl=61 time=46.8 ms
64 bytes from github.map.fastly.net (185.31.17.133): icmp_seq=3 ttl=61 time=44.5 ms
^C
--- github.map.fastly.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 44.555/45.891/46.823/0.968 ms

Was ist eigentlich die Bridge `docker0`? ...

Auf dem Host kümmert sich der Docker-Daemon um die Netzwerk-Magic. Bei Installation wird eine Linux Network Bridge docker0 angelegt. Eine Bridge erscheint erstmal wie ein eigenes Netzwerkinterfaces, im Fall von docker0 besitzt diese Bridge sogar eine eigene IP-Adresse. Man kann sich eine Bridge vorstellen wie das virtuelle Äquivalent eines Hardware-Switches, aber ohne eigene Logik (die ein Switch hätte). Andere Netzwerkinterfaces können an eine Bridge angeschlossen werden, und der Kernel (das Modul bridge) leitet Pakete, die auf beliebigen Interfaces ankommen an alle angeschlossenen Interfaces weiter.

Mit dem ip-Kommando kann man die Bridge als Interface (mit ihrer IP) sehen:

~# sudo ip addr show docker0
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 16:69:e4:75:45:86 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever

Das Tool brctl zeigt die Interfaces an, die an die Bridge angeschlossen sind. Es stammt aus dem Paket bridge-utils.

~# sudo brctl show
bridge name bridge id       STP enabled interfaces
docker0     8000.1669e4754586   no      vethc3cd

In der letzten, rechten Spalte werden die an die Bridge angeschlossenen Interfaces angezeigt. Das sieht zugegebermaßen etwas seltsam aus, ein veth-Interface. Man kann sich die Details anzeigen lassen:

~# sudo ip addr show vethc3cd
38: vethc3cd: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master docker0 state UP group default qlen 1000
    link/ether 76:c0:d8:ea:50:4d brd ff:ff:ff:ff:ff:ff
    inet6 fe80::74c0:d8ff:feea:504d/64 scope link
       valid_lft forever preferred_lft forever

Es handelt sich quasi um ein virtuelles Kabel, das an der Bridge hängt (in der ersten Ausgabezeile zu sehen, master docker0). Dieses Interface ist damit die Gegenstelle des eth0-Interface im Containers. Das lässt sich auch mit Linux-Bordmitteln herausfinden, wir bemühen die Statistik-Funktion von ethtool und finden heraus:

~# sudo ethtool -S vethc3cd
NIC statistics:
     peer_ifindex: 37

ethtool zeigt an, dass der Index des Peers zu vethc3cd den Identifier 37 trägt. Und das ist genau die ID, die im Container selber beim eth0 angezeigt wird (s.o.). D.h. es ergibt sich folgendes Bild:

Das veth-Interface auf dem Host und das eth-Interface im Container sind wie die beiden Seiten derselben (Netzwerk-)Medaille. Alles was der eine transportiert, sieht der andere auch, nur in verschiedenen Container- bzw. Namespace-Ebenen. So trennt Docker das äußere Host-Interface vom inneren Container-Interface.

Anschluss in die Welt da draußen

Mit dem Kommando brctl kann man sehen, dass nur ein Interface auf der Bridge angeschlossen ist, nämlich das veth...-Interface. Allerdings ist das Netzwerk-Interface des Hosts (im Diagramm das obere eth0) nicht an der Bridge angeklemmt. Das wäre auch möglich, braucht aber einige weitere Voraussetzungen und Umbauarbeiten, die z.B. im Blog von @jpetazzo beschrieben sind.

Wie also kann der Container Pakete ins Internet schicken und die Antworten erhalten? Der Docker-Daemon baut dafür auf dem Host einen Automatismus mit Hilfe von iptables auf. In der Prerouting- und Routing-Chain wird klar, dass ein Paket nach außen geroutet werden soll.

~# sudo /sbin/iptables -L -n -t nat
[....]

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  172.17.0.0/16       !172.17.0.0/16

In der Postrouting-Chain gibt es einen Masquerade-Eintrag. Dabei setzt der Host Paketen, die für die Außenwelt bestimmt sind, die eigene IP des ausgehenden Interfaces ein, sodass die Antworten später auch zurückgeroutet werden können.

Mit dem Aufruf eines traceroute-Tools (hier mtr-tiny, kann auch ein anderes Tool sein) im Docker-Container sieht man, dass alle Netzpakete automatisch über die IP des Hosts geroutet werden, die an der docker0-Bridge hängt (172.17.42.1). Da die Bridge nicht am eth0 des Host hängt, gibt es keine direkten Weg nach draußen. Aber das IP-Masquerade und das Routing auf dem Host sorgen dafür, dass der nächste (2.) Hop die eth0 auf dem Host ist (10.0.2.2). Danach geht es weiter über die Netzinfrastruktur, an der der Host hängt.

root@4de56414033f:/# apt-get install mtr-tiny
root@4de56414033f:/# mtr www.infrabricks.de
                                     My traceroute  [v0.85]
2ad667affd45 (0.0.0.0)                                                 Thu Jul  3 16:37:37 2014
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                       Packets               Pings
 Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 172.17.42.1                                       0.0%     6    0.1   0.1   0.1   0.3   0.0
 2. 10.0.2.2                                          0.0%     6    0.4   0.5   0.4   0.9   0.0
 3. ???
 ...
11. ???
12. github.map.fastly.net                             0.0%     5   44.1  44.1  43.9  44.4   0.0

Kommunikation zwischen den Docker-Containern auf dem selben Host

Da alle Docker-Container auf derselben Bridge docker0 lokalisiert sind, können sie darauf uneingeschränkt untereinander kommunizieren. Das Prinzip wurde in der LINK-Funktionalität vom Docker-Daemon weiter ausgebaut.

Ein zweiter Container erhält eine neue IP und ist der in der Lage, den ersten zu erreichen:

~# docker run -t -i ubuntu /bin/bash
root@2e2d98cf5c43:/# ip addr show eth0
39: eth0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 16:47:b2:34:b1:87 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.5/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::1447:b2ff:fe34:b187/64 scope link
       valid_lft forever preferred_lft forever
       root@2e2d98cf5c43:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.091 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.080 ms
^C
--- 172.17.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.080/0.090/0.099/0.007 ms

Das funktioniert, weil der Docker-Daemon in Default-Verhalten keine iptables-Sperren auf der Bridge einrichtet, d.h. alle Container können untereinander und mit dem Host auf allen offenen Ports kommunizieren.

Falls man das aus Sicherheitsgründen nicht möchte, kann man dieses Verhalten ändern. Dabei sorgt eine andere Default-Policy im iptables dafür, das Pakete verworfen werden, außer es wird explizit erlaubt.

Docker-Container für die Aussenwelt erreichbar machen

Die Link-Funktionalität von Docker macht das einfach sehr einfach zugänglich, da man Container anhand ihres Namens und einer Port-Nummer untereinander verknüpfen kann:

Im Dockerfile hat man mit EXPOSE die Möglichkeit, einen lokalen Port des Containers auf dem Host weiterzuleiten, sodass er auch von außen erreichbar ist. Da die docker0-Bridge aber nicht mit dem Host-Interface verbunden ist gibt es auch hierbei einen iptables-Mechanismus.

Alternativ kann man im docker run-Befehl direkt eine Weiterleitung einrichten. Das Beispiel zeigt, wie ein Container mit einer Weiterleitung gestartet wird, ein Netcat-Listen Prozess hört auf dem inneren Container-Port 80.

~# docker run -t -i -p 80:8000 ubuntu /bin/bash
root@e5d717bdfc32:/# nc -l 0.0.0.0 80

Falls nc nicht installiert ist, hilft ein apt-get install netcat.

Auf dem Host kann man sich die Weiterleitung von Docker anzeigen lassen (docker port). Über netstat sieht man, dass der Docker-Daemon auf dem weitergeleiteten Port hört:

~# docker port 28096eac487b 80
0.0.0.0:8000
~# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
[...]
tcp6       0      0 :::8000                 :::*                    LISTEN      6062/docker.io

Und auf dem Host wurde eine iptables Forward-Regel eingerichtet, damit der Traffic, der vom Host-Interface ankommt, über die Bridge an den Container gerichtet werden kann:

~# sudo /sbin/iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  0.0.0.0/0            172.17.0.2           tcp dpt:80

Im Detail ...

Der Docker-Daemon sorgt hinter den Kulissen dafür, dass alle drehenden Teile auch richtig zusammenarbeiten. Bei der normalen Arbeit mit Docker muss man sich darum selten kümmern. Mit Docker ist man aber auch in der Lage, komplexere Netzwerk-Setups zu simulieren und damit eine Docker-Umgebung produktionsreif aufzubauen.

Wer das ganze im Detail nachlesen möchte, ist auf der Docker.io Dokumentation-Seite zu Advanced Networking gut aufgehoben.

Im nächsten Schritt werden wir Container über Hostgrenzen hinweg verbinden und damit die Grundlage für ein skalierfähige und ausfallsichere Umgebungen zu schaffen. Jede Menge Posts erscheinen nun zum Thema Docker bzw. Linux Networking. Lukas Pustina zeigte in seinem Post wie einfach es ist, hundert Docker Container auf einem Host zu starten. Jason Edelman schreibt regelmässig über das Thema Networking und sein Artikel über Docker mit Open vSwitch zu verbinden, gibt viele Anregungen.

Das Thema Software Defined Networks ist komplex, aber nun gibt es endlich eine interessante praktische Verwendung für jeden von uns Docker-Interessierten.

Andreas & Peter

Docker mit boot2docker starten

2014-06-30T00:00:00+02:00

Das Projekt Docker schlägt seit den ersten Lebenszeichen Mitte letzten Jahres zunehmend höhere Begeisterungswellen. Docker verspricht einen schnellen Start in die Welt der DevOps, flexiblen Konfiguration und stabilen Images. All dies sind für uns sehr wichtige Voraussetzungen, um Infrastruktur testbar zu machen. Grund genug für uns, das ganze unter die Lupe zu nehmen und Euch einfache Anleitungen zum Ausprobieren an die Hand zu geben. Wie kann man am einfachsten mit Docker auf dem eigene Rechner durchstarten?

Erste Schritte mit Docker

Docker ermöglicht es, die eigenen Prozesse in leichtgewichtige Linux Container einzupacken. Am besten kann man die Wirkung als eine fettreduzierte Virtualisierung beschreiben. Wer Docker direkt probieren möchte, kann das Online Tutorial nutzen. Eine eigene Installation ist für einen echten Docker-Einsatz allerdings unerlässlich. Damit dies auf dem eigenen Rechner zuverlässig gelingt, empfiehlt sich die lokale Installation mit dem Projekt boot2docker.

Mit der Hilfe von Boot2Docker wird auf dem eigene Windows oder Mac eine virtuelle Maschine mit einer Basis-Docker Tiny Linux Installation installiert. Eine Voraussetzung ist die Installation einer aktuellen Version von VirtualBox. Weiterhin wird die Docker Client CLI und eine boot2docker Management CLI installiert. So läßt sich anschliessend sehr bequem sämtliche Administration ohne lästiges einloggen via ssh vom eigenen Rechner erledigen. Docker selbst benötigt Zugang zu dem Cloud Images Registry von Docker Inc. Von dort werden die Betriebsysteme und Container geladen. Aktuell befinden sich dort schon mehr als 15.000 vorgefertigte Container für die unterschiedlichsten Einsatzzwecke. Die Qualität ist unterschiedlich und vor dem Einsatz lohnt sich ein Blick in die Sourcen des Containers. Die Konfiguration eines Container befindet sich in der Datei Dockerfile. Als Basis Images lohnt ein Blick auf die Phusion Baseimage zu werfen.

Die grössten Unterschiede zwischen Vagrant und Docker sind:

	Vagrant	Docker
Nutzung	Entwicklung	Entwicklung und Betrieb
Speicherung	Dauerhaft	Flüchtig und braucht externe Volumes
Anzahl der Services	viele	meist einer
Tools	cli	cli und REST Service
Programmierung	Ruby	Bash & Go, Java, Ruby, JavaScript, Scala, ...
Technik	Virtualisierung	LXC

Installation von boot2docker

Boot2docker hilft dabei, ein für Docker passendes Linux mit Virtualbox auf Windows oder OS X zu installieren. Mit der Version 1.0 liegt die Installation nun als fertiges Package vor. Als Voraussetzung muss VirtualBox in der Version >4.3.12 installiert sein. Eine leistungsfähige Internet-Verbindung, die schnell den Transfer von mehr als 1GB Daten erlaubt, ist hier wirklich hilfreich. Eine Live-Demo mit unbekannten langsamen WiFi-Netzen oder Mobiles hat der Demo-Gott hier nicht vorgesehen. Denn zum Start müssen neben den Images für die Virtualisierung noch die Basis-Images für Docker geladen werden. Also ist genügend Zeit für ein bisschen Lesen im Netz oder eine Unterhaltung mit den Kollegen.

Neben der VM wird auf dem Host ein lokaler Docker-Client installiert, damit ohne Login auf dem Linux alle Docker-Befehle genutzt werden können. Nach der Installation von boot2Docker kann geprüft werden, ob der Docker-Client auf dem Host verfügbar ist.

$ docker version
Docker version 1.0.1, build 990021a

Die eigene Docker-Testumgebung wird mit dem Befehl boot2docker init erzeugt. Dabei wird eine neue virtuelle Maschine in der VirtualBox erstellt. Der Start der Umgebung erfolgt mit boot2docker up. Wichtig ist, dass man nun den Docker-Client auf der eigenen Maschine auf der gestarteten VM mit einer Export-Anweisung konfiguriert. Die Anweisung befindet sich am Ende der Ausgabe des Kommandos. Nun kann die Fernsteuerung von Docker in der VM beginnen. Dies ist möglich, da Docker ein HTTP REST API besitzt und alle Steuerungen darüber erfolgen. Neben der Shell Client gibt es diverse Docker Integrationen für Ruby, Go, Php, Java, Scala oder Groovy.

$ boot2docker up
2014/06/22 19:12:29 Waiting for VM to be started...
..^[[C.....
2014/06/22 19:12:50 Started.
2014/06/22 19:12:50 To connect the Docker client to the Docker daemon, please set:
2014/06/22 19:12:50     export DOCKER_HOST=tcp://192.168.59.103:2375

$ export DOCKER_HOST=tcp://192.168.59.103:2375

Nun stehen alle Docker Kommandos auf dem eigenen Mac- oder Windows-Rechner zur Verfügung. Ohne Problem lässt sich nun über das Docker REST API die gesamte Docker-Installation fernsteuern.

$ docker images
REPOSITORY           TAG                   IMAGE ID            CREATED             VIRTUAL SIZE
busybox              buildroot-2013.08.1   d200959a3e91        2 weeks ago         2.489 MB
busybox              ubuntu-14.04          37fca75d01ff        2 weeks ago         5.609 MB
busybox              ubuntu-12.04          fd5373b3d938        2 weeks ago         5.455 MB
busybox              buildroot-2014.02     a9eb17255234        2 weeks ago         2.433 MB
busybox              latest                a9eb17255234        2 weeks ago         2.433 MB

Folgende docker-Kommandos können nun ausgeführen werden:

$ docker
Usage: docker [OPTIONS] COMMAND [arg...]
 -H=[unix:///var/run/docker.sock]: tcp://host:port to bind/connect to or unix://path/to/socket to use

A self-sufficient runtime for linux containers.

Commands:
    attach    Attach to a running container
    build     Build an image from a Dockerfile
    commit    Create a new image from a container's changes
    cp        Copy files/folders from the containers filesystem to the host path
    diff      Inspect changes on a container's filesystem
    events    Get real time events from the server
    export    Stream the contents of a container as a tar archive
    history   Show the history of an image
    images    List images
    import    Create a new filesystem image from the contents of a tarball
    info      Display system-wide information
    inspect   Return low-level information on a container
    kill      Kill a running container
    load      Load an image from a tar archive
    login     Register or Login to the docker registry server
    logs      Fetch the logs of a container
    port      Lookup the public-facing port which is NAT-ed to PRIVATE_PORT
    pause     Pause all processes within a container
    ps        List containers
    pull      Pull an image or a repository from the docker registry server
    push      Push an image or a repository to the docker registry server
    restart   Restart a running container
    rm        Remove one or more containers
    rmi       Remove one or more images
    run       Run a command in a new container
    save      Save an image to a tar archive
    search    Search for an image in the docker index
    start     Start a stopped container
    stop      Stop a running container
    tag       Tag an image into a repository
    top       Lookup the running processes of a container
    unpause   Unpause a paused container
    version   Show the docker version information
    wait      Block until a container stops, then print its exit code

Mit dem Befehl boot2docker ssh ist die Einwahl auf die VM möglich.

$ boot2docker ssh
Warning: Permanently added '[localhost]:2022' (RSA) to the list of known hosts.
                        ##        .
                  ## ## ##       ==
               ## ## ## ##      ===
           /""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
           \______ o          __/
             \    \        __/
              \____\______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
boot2docker: 1.0.0
             master : 16013ee - Mon Jun  9 16:33:25 UTC 2014
docker@boot2docker:~$

Nun ist eine direkte Interaktion mit allen Containern und Prozessen auf der Linux VM möglich. Weitere Linux Packages für Monitoring, Logging und andere Services können genutzt werden. Natürlich kann nun das Netzwerk für die Kooperation mit anderen Maschinen und Services erweitert werden. Eine Freigabe von Docker Container Ports auf dem Mac lässt sich mit dem Script boot2docker-fwd erledigen.

In der Liste der boot2docker Befehle finden sich die üblichen Verdächtigen zum Management der VM:

$ boot2docker --help
Usage: boot2docker [<options>] <command> [<args>]

boot2docker management utility.

Commands:
    init                    Create a new boot2docker VM.
    up|start|boot           Start VM from any states.
    ssh [ssh-command]       Login to VM via SSH.
    save|suspend            Suspend VM and save state to disk.
    down|stop|halt          Gracefully shutdown the VM.
    restart                 Gracefully reboot the VM.
    poweroff                Forcefully power off the VM (might corrupt disk image).
    reset                   Forcefully power cycle the VM (might corrupt disk image).
    delete                  Delete boot2docker VM and its disk image.
    config|cfg              Show selected profile file settings.
    info                    Display detailed information of VM.
    ip                      Display the IP address of the VM's Host-only network.
    status                  Display current state of VM.
    download                Download boot2docker ISO image.
    version                 Display version information.
...

Die Basis von boot2docker ist aktuell der Linux Kernel 3.14.1 mit AUFS und Docker 1.0.1. Es besteht die Möglichkeit, ein eigenes Image für die VirtualBox zu erstellen.

Start des ersten Docker-Containers

In der VM oder auf der eigenen Maschine können nun Docker Container administriert, erzeugt, gestartet, gestoppt oder wieder gelöscht werden.

$ docker run ubuntu uname -a
Unable to find image 'ubuntu' locally
Pulling repository ubuntu
e54ca5efa2e9: Download complete
511136ea3c5a: Download complete
d7ac5e4f1812: Download complete
2f4b4d6a4a06: Download complete
83ff768040a0: Download complete
6c37f792ddac: Download complete
Linux 321d285612ef 3.14.1-tinycore64 #1 SMP Mon Jun 9 16:21:23 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Das Erzeugen eines eigenen Images kann mit einem Dockerfile definiert werden.

$ mkdir -p hello
$ cd hello
$ vi Dockerfile

Dockerfile

FROM ubuntu

CMD ["echo", "Hello", " Docker"]

Mit dem Befehl docker build wird nun in der VM ein Image produziert und kann mit docker run gestartet werden.

$ docker build -t boot/hello .
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon
Step 0 : FROM ubuntu
 ---> e54ca5efa2e9
Step 1 : CMD ["echo", "Hello", "Docker"]
 ---> Running in 8dedcb96f9c0
 ---> 891601c49719
Removing intermediate container 8dedcb96f9c0
Successfully built 891601c49719
$ docker run boot/hello
Hello Docker

Nun ist die Basis für eigene Docker-Experimente gelegt. Die Integration in die eigenen Projekte, erweiterten Möglichkeiten für Tests oder ein vereinfachter Zugriff auf diverse Backends sind erste Kandidaten. Es gibt enorme Möglichkeiten und eine Suche im öffentlichen Image-Register lohnt sich.

Wir starten nun eine kleine Serie, zur Entschlüsselung von Docker für DevOps. Damit wollen wir die Chancen und Risiken dieser wunderbaren neuen Technologie aufzeigen und diskutieren.

Peter

Security-Tests mit serverspec

2014-06-12T00:00:00+02:00

Sichere Systeme zu bauen und zu betreiben ist eine kontinuierliche Herausforderung. Ein erster Ansatz ist, Sicherheitsaspekte zu spezifizieren und testbar zu machen. Serverspec besitzt eine Reihe von nützlichen Eigenschaften, um dem Ziel näher zu kommen.

Durch die deklarative rspec-Syntax ist es möglich, Infrastrukturspezifikationen zu verfassen, die sicherheitsrelevante Aspekte, wie etwa Berechtigungen, beschreiben. Und das ganze wird natürlich auf Knopfdruck testbar.

You should_not ...

Eine praktische Eigenschaft ist dabei, Eigenschaften ausdrücken, die eben nicht vorliegen sollten. Dazu bietet rspec das Schlüsselwort should_not an, wie z.B. in

describe file '/etc/ssh/sshd_config' do
  its(:content) { should_not contain(/PermitRootLogin Yes/) }
end

Security-Tests beziehen sich natürlich nicht nur auf Eigenschaften von Dateien, sondern auf viel mehr, beispielsweise:

Pakete: Manche Pakete sollten besser nicht installiert sein (Beispiel: sendmail)
Dienste: Service sollten nicht laufen, und auch nicht enabled sein. Andere sollten auf jeden Fall laufen (z.B. iptables)
Die Dateiberechtigungen betreffen vor allem World-Rechte und Ausführbarkeit. Die sollten stark eingeschränkt sein.
Dateien sollten nur den Nutzer gehören, die sie zur Ausführung benötigen.
Manche User sollten keine Shell haben.
(NFS-)Mounts, die nur als Dateiablage dienen, sollten auch nicht ausführbar sein.
Services die Ports öffnen, sollten dies nur auf bestimmten IPs tun.
Konfigurationsdateien für Services wie bspw. Apache sollten sichere Einstellungen beinhalten, z.B. aktuelle SSL Cipher Suites
Die Zertifikate und Schlüssel müssen die richtigen sein, z.B. auch mit hoher Schlüsselstärke
... und vieles mehr.

Das lässt sich ganz gut mit serverspec beschreiben.

Pakete

Um auszudrücken, dass eine Menge an Paketen nicht installiert sein sollte, kann man z.B. mit einem Iterator über eine Liste wandern und einen describe-Block aufbauen (Beispiel mit Paketnamen für RedHat bzw. CentOS):

%W( bluetooth cups isdn tftp autofs ).each do |pkgname|
  describe package pkgname do
    it { should_not be_installed }
  end
end

Ähnliches mit Services (sowohl Negativ- als auch Positiv-Beispiele):

%W( sendmail ).each do |s|
  describe service s do
    it { should_not be_enabled }
    it { should_not be_running }
  end
end

%W( iptables ).each do |s|
  describe service s do
    it { should be_enabled }
    it { should be_running }
  end
end

Nutzer ohne Shell

Hier lässt Linux mehrere Varianten zu, eine ist /bin/nologin. Puppet erhält beispielsweise einen eigenen Laufzeitnutzer, der sollte aber ebenfalls keine Shell besitzen und wird besser mit /bin/false eingerichtet.

describe user 'apache' do
  it { should have_login_shell '/bin/nologin' }
end
describe user 'puppet' do
  it { should have_login_shell '/bin/false' }
end

NFS-Mounts

NFS-Mounts, die nur zur Ablage von Dateien verwendet werden, sollten mit dem no-executable-Flag gemountet werden:

describe file('/') do
  it { should be_mounted.with(
    :options => { :noexec => true }
  ) }
end

Konfigurationsdateien am Beispiel Apache

Zur Absicherung einer Webserver-Konfiguration wie bspw. dem Apache gehören mehrere Dinge. Wir möchten z.B. sicherstellen, dass SSL-relevante Parameter vorhanden sind, dass die Zertifikats- und Schlüsseldateien existieren und die richtigen sind (z.B. anhand des CommonNames). Letzteres können wir durch ein Serverspec command erreichen, was openssl ausführt um das Zertifikat auszulesen und anzuzeigen. Im Block selber verwenden wir Matcher, um den Inhalt zu prüfen.

  describe file "/etc/ssl/mykey.crt" do
    it { should be_file }
    it { should be_mode         '644' }
    it { should be_owned_by     'root' }
    it { should be_grouped_into 'root' }
  end

  describe command 'openssl x509 -in /etc/ssl/mykey.cert -text' do
    it { should return_exit_status 0 }
    its(:stdout) { should match /Subject:.*example.com/ }
  end

Und wir möchten gerne die Schlüsselstärke der SSL-Schlüssel verifizieren und schauen, ob der Schlüssel selber valide ist:

describe command "openssl rsa -in /etc/ssl/mykey.key -check" do
  its(:stdout) { should match /^RSA key ok$/ }
  it { should return_exit_status 0 }
end

SSL-Zertifikate als Ressourcen beschreiben

Nun ist der Aufruf von openssl und das heraus-greppen der gewünschten Informationen zwar möglich, aber leider etwas umständlich. Hier wünsche ich mir eher so etwas wie:

describe sslcertificate 'xyz.crt' do
  its(:subject) { should match /.../ }
  its(:key_strength) { should be_at_least 2048 }
  its(:validity) { should ... }
end

describe rsakey 'xyz.key' do
  it { should be_valid }
  it { should be_restricted_to 'root' }
end

Das funktioniert in serverspec nur mit einem eigenen Resource Type. In einem der folgenden Posts machen wir uns an die Implementierung einer solchen Erweiterung von serverspec.

Andreas

Docker 1.0 steht bereit

2014-06-09T00:00:00+02:00

Die freudige Neuigkeit für alle Entwickler und Administrator ist, dass nun Docker 1.0 bereitsteht. In nur 15 Monaten hat sich Docker von einer Idee zu einer gewaltigen neuen IT-Technologie Bewegung entwickelt. Im Rahmen der ersten DockerCon 2014 in San Fransisco können sich die sicherlich überglücklichen Teilnehmer und wir darauf freuen, nun ohne Beta-Einschränkungen in die Produktion zu gehen.

Die großen Internet Firmen wie eBay, Yelp, Spotify und Baidu nutzen Docker schon eine Weile sehr erfolgreich. Alle Projekte berichten über außerordentliche Erfolge ihrer Komponenten mit Docker, die zuverlässiger, schneller und effektiver zu installieren sind. Der Graben zwischen Entwicklung, Administration und der wirklichen Produktion scheint nun durch das Docker Container Managmenent überwindbar. Eine Anwendung in einem Docker Container, kann sehr einfach zwischen verschiedenen Umgebungen, lokal auf echtem Eisen, auf einer Virtualisierungsplattform oder in der Cloud gestartet werden und das ohne Veränderung. Das Leben für uns DevOps hat eine neue Baustelle. Bin sehr gespannt, wie sich die riesigen bestehenden Tanker mit diesem Betriebsmodell schneller und leistungsfähiger umgestalten lassen. Es wird eine große Herausforderung, sich für die Zukunft wettbewerbsfähig aufzustellen.

Docker Inc., die Firma und Treiber dieser Entwicklung, sind aus dem Unternehmen DotCloud hervorgegangen. Die neue Firma hat aktuell einen strengen Fokus die Docker Technologie weiterzuentwicklen und zu vermarkten. Die Ankündigung, dass Docker nun fester Bestandteil des Red Hat 7 Release sein wird hilf da sicherlich. Die Integration mit bestehenden Virtualisierungslösungen ist auf einem gutem Weg, aber vielleicht gibt es ja bald neue Wege mit Docker.

Die Eigenschaften des aktuellen Docker 1.0 Ökosystems sind:

Alle aktuellen Linux Distributionen werden unterstützt:
- Red Hat
- Debian
- Ubuntu
- Fedora
- CentOS
- Gentoo
- Suse
- Arch
Plug-in Schnittstellen zur Kontrolle der Ausführung und zu den Dateisystemtreibern.
Mit boot2docker macht es möglich Docker direkt mit Mac OS X und Windows zu betreiben.
Die Dokumentation ist aktualisiert.
Docker Inc liefert ein nun kompletes Trainingmaterialen und kommerziellen Support
Integration mit Docker Hub, der andere wichtige Dienst für den Betreib mit Docker.

Von Docker sind mittlerweile mehr als drei Million Downloads erfolgt. Immer mehr Startups und DevOps bringen neue Ideen für Erweiterungen des noch jungen Ökosystems hervor. Vermutlich laufen jetzt schon 100.000 Docker Container weltweit und es werde noch sehr viele folgen. Aktuell stehen mehr als 14.000 fertige Container im offiziellen Docker Hub Registry bereit. Das Docker Release 1.0 ist ein konsequenter nächster Schritt, eine Continous Delivery Pipeline bis in die Produktion sicher, nachvollziehbar und zuverlässig zu realisieren. Docker wird mit seinen Containern schon sehr bald Enterprise und Startup Projekte sehr erfolgreich machen.

Wir werden in diesem Blog bald ausführlich mit dem Thema Docker mit Qualität entwickeln, auseinandersetzen.

Der blaue Wal legt nun richtig los....

Peter

infrataster und serverspec: Blackbox- und Whitebox-Testing

2014-05-22T00:00:00+02:00

Für Infrastrukturtest bieten sich verschiedene Verfahren an. Aus der Softwareentwicklung sind Blackbox - und Whitebox-Tests bekannt. Bei der ersten Variante wird das, was man testen möchte ausschließlich von außen (als Black Box) betrachtet, und das Verhalten der Komponenten wird über seine Schnittstellen gegenüber einer Spezifikation bewertet.

Whitebox ...

Bei Whitebox-Tests fließen Detailinformationen der zu testenden Komponente ein, d.h. man muss also in die Komponente hereinschauen können, um den Test durchzuführen.

In den letzten Posts über serverspec haben wir uns mit Whitebox-Testing beschäftigt. Hier beschreiben wir in einer Spezifikation den Detailaufbau eines Servers, und serverspec prüft für uns diese Dinge ab. Dazu muss serverspec natürlich in/auf den Server schauen.

Wenn der Server beispielsweise einen Webservice bereitstellt, können wir mit serverspec prüfen,

ob die Pakete für Middleware und Applikation installiert sind,
ob die Applikation ihre Konfigurationsdateien besitzt,
und diese korrekt sind,
ob der Service startet und einen Netzwerkport belegt,
und vieles mehr.

Damit ist nur leider nicht gesagt, dass der Webservice auch wie gewünscht funktioniert. Mit dem Whitebox-Test haben wir nur die Grundlagen abgeprüft, die überhaupt erst einmal notwendig sind.

Man könnte im nächsten Schritt mit einem Tool wie curl oder wget innerhalb des Servers einen HTTP-Call absetzen und das Ergebnis prüfen. Die Funktionsfähigkeit kann von außen betrachtet aber immer noch scheitern, etwa weil die Netzwerkkonfiguration nicht stimmt oder iptables den Zugriff verhindert.

... und Blackbox

Das wiederum lässt sich mit einem Test von außen abprüfen. Wenn ein anderer Server den Service abfragt und ein korrektes Ergebnis erhält, kann man schon eher sicher sein, dass alles korrekt ist.

Da serverspec erweiterbar ist, lassen sich prinzipiell auch Blackbox-Tests durchführen. Ein einfaches - allerdings unschönes - Beispiel nutzt das Kommandozeilentool curl um einen HTTP-Call zu platzieren und Daten aus der Ausgabe zu prüfen:

describe command 'curl http://appserver:8080/test' do
  it { should return_exit_status 0 }
  its(:stdout) { should match /^success$/ }
end

Das sollte funktionieren, wandelt aber den deklarativen Ansatz von serverspec in einen imperativen um: Wir beschreiben nicht eine Webresource, sondern konstruieren ein command, um sie abzufragen. Vor allem wenn beim curl-Aufruf Parameter übergeben werden, vielleicht noch über HTTP POST, wird der Einzeiler länger und unschöner.

Geschmacksprobe: Infrataster

Glücklicherweise gibt es ein Projekt, das den Blackbox-Ansatz in rspec-Art und Weise umsetzt, Infrataster. Dies ist eine Erweiterung auf rspec, die verschiedene Typen einführt um Calls abzusetzen und das Ergebnis abzuprüfen. Dabei werden Webcrawler-Frameworks aus der Ruby-Welt eingesetzt um dennoch bei einer lesbaren Testspezifikation bleiben zu können.

Das sieht dann beispielsweise so aus:

describe server(:app) do
    describe http('http://appserver:8080/test') do
        it "responds content including 'success'" do
            expect(response.body).to include('success')
        end
    end
end

Hier wird im äußeren describe-Block der zu testenden Server angegeben (:app, s.u.), im inneren Block die Ressource (appserver:8080/test), und die Expectations, z.B. bezüglich der Rückgabe.

Infrataster kann dabei die Rückgabe auch detaillierter prüfen, etwa ob bestimmte Response-Header gesetzt sind, hier, ob der Content-Type text/html entspricht:

        it "responds as 'text/html'" do
            expect(response.headers['content-type']).to match(%r{^text/html})
        end

Außerdem kann man bei Konstruktion des Calls auch Parameter mitgeben, z.B.

    describe http(
            'http://appserver:8080/foo/app',
            method:   :get,
            params:   {'foo'   => 'bar'},
            headers:  {'USER'  => 'VALUE'}
    ) do
    ...
    ...

Damit lassen sich Webservices auch von außen gut testen. Weitere Post zeigen die Verdrahtung zu den Zielservern (":app"), die Nutzung von Proxies, wie Infrataster aufgebaut ist, und wie man damit ein reales Testszenario aufsetzt.

Beides zusammen, FTW!

Weder Blackbox- noch Whitebox-Tests sind für sich genommen ausreichend. Wenn innerhalb der Komponente alles in Ordnung ist (Whitebox) heisst das nicht automatisch, dass ihr Verhalten nach außen wie gewünscht funktioniert.

Umgekehrt kann man aus einem fehlschlagenden Blackbox-Test noch nicht ermitteln, woran es eigentlich scheitert, d.h. der Fehler ist erkennbar, aber nicht lokalisierbar.

Um Infrastrukturkomponenten qualitativ testen zu können, sind sowohl White- als auch Blackbox-Tests sehr sinnvoll. Hier ist die Kombination von serverspec und Infrataster wirksam und empfehlenswert!

Andreas

serverspec mit Vagrant verbinden

2014-05-09T00:00:00+02:00

Eine späte Integration der eigenen Software in die Produktionsumgebung rächt sich meistens. Der Kundennutzen muss immer früher sicher hergestellet werden. Jede Änderung soll geschwindt in die Produktion, um dort zu beweisen, ob diese Eigenschaft den gewünschten Nutzen wirklich bietet. Natürlich soll kein Fehler in die Produktion gelangen. Die Änderungen müssen überprüft werden und durch verschiedene aufeinander aufbauende Umgebungen die Qualität sicher gestellt werden. Um so eher dies gelingt, um so schneller kann eine gezielte Korrektur erfolgen.

Das Ziel sollte es sein eine Deployment Pipeline zu installieren [Jez Humble, David Farley: "Continuous Delivery", 2011 Pearson Education]. Damit das Feedback schnellst möglich gelingt, ist es ratsam schon früh die Integration in die Produktionumgebung zu realisieren und die Teilinstallation am eigenen Arbeitsplatz zu überprüfen. Dieser Artikel beschreibt die Erstellung einer Apache Httpd -Installation mit Vagrant und [Virtualbox](http://www.virtualbox.org. Die Besonderheit ist der Einsatz von serverspec zur Valdierung der Provisionierung.

Der Plan ist, einen Apache httpd Service in einer CentOS 6.5 Box aufzusetzen und sicherzustellen, dass der Webserver wirklich läuft. Als ersten Schritt wird ein entsprechendes Basis CentOS 6.5 Image mithilfe von Vagrant auf die lokale Virtualbox installieren. Damit also die folgenden Schritte praktisch nachvollzogen werden können, bedarf es einer entsprechende Installation von Vagrant und Virtualbox auf dem System. Entsprechende Anleitungen dazu befinden sich auf den Websites der beiden OpenSource Projekte.

Ein gesichertes Betriebssystem für die eigene Vagrant Box zu bekommen ist nicht einfach. Zum guten Gelingen und notwendigen Beitrag der Sicherheit, sollten man diese Installation lieber selbst in die Hand nehmen. Mit den Projekten Packer oder Veewee kann dies komfortabel für verschiedene Betriebssysteme, virtuelle Plattformen und Clouds umgesetzt werden. Eine gute Kenntnis der Installation von Betriebssystemen und viel Geduld, führt dann langsam zum Ziel. Natürlich gibt es auch fertige Boxen. Für Vagrant gibt es neben dem Cloud Angebot Vagrant Cloud natürlich auch eine freie Sammlung Vagrantbox. Eine sehr einfache und leicht nachzuvollziehende CentOS 6.5 Installation wird von 2Creatives bereitgestellt. Die Box wird regelmässig aktualisiert und steuert sehr direkt die Management Schnittstelle von Virtualbox an. Die Box kann nun mit folgendem Vagrant-Befehl auf der eigenen Maschine bereitgestellt werden:

$ mkdir apache-specbox
$ cd apache-specbox
$ vi Vagrantfile

Mit dem folgenden Vagrant Konfiguration wird die CentOS-Box von 2creatives geladen, ein privates Netzwerk zusätzlich geschaffen, der Ressourcenbedarf festgelegt und der Name apacheSpecbox der neuen Virtualbox-Node vergeben.

# -*- mode: ruby -*-
# vi: set ft=ruby :
## Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "2creatives/centos65-x86_64-20140116"
  config.vm.box_url = "https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box"
  config.vm.box_download_checksum_type="sha256"
  config.vm.box_download_checksum = "84eda9c4f00c86b62509d1007d4f1cf16b86bccb3795659cb56d1ea0007c3adc"

  config.vm.define :apacheSpecbox do |c|
    c.vm.network "private_network", ip: "192.168.33.10"
    c.vm.host_name = "apacheSpecbox.example.com"
    c.vm.provider "virtualbox" do |vb|
         vb.gui = false
         vb.customize [ "modifyvm", :id, "--memory", "512"]
         vb.customize [ "modifyvm", :id, "--cpus", "1"]
         vb.name = "apacheSpecbox"
  end

end

Dann ein:

$ vagrant up

Die Voraussetzungen für eine Apache httpd Installation sind also nun gegeben. Als nächsten Schritt könnte man mit dem Befehl vagrant ssh sich auf die neue apacheSpecbox anmelden und den Apache mit dem Package Manager manuell installieren. Allerdings wären das gleich mehrere Verstöße der guten Sitten. Alles und damit ist wirklich ALLES gemeint, muss durch entsprechende Programmierung automatisch nachvollzogen und prüfbar sein. Hmm, welche Anforderungen muss soll die Installation eines Apaches den wirklich erfüllen? Wie kann man durch ein Werkzeug die Überprüfung formulieren und ausführbar machen? Genau an dieser Stelle beginnt dann die Suche im Netz, nach Ideen und Lösungen. Seit nunmehr zwei Jahren gibt es das kleine Projekt serverspec von Gosuke Miyashita, das sich als Antwort auf diese Fragen entpuppt.

Damit die Installation wiederholbar ist und dokumentiert wird, wird ein Gemfile erzeugt und mit dem ruby bundler die Installation gestartet.

$ vi Gemfile

## Gemfile
ruby '2.1.1'

source 'https://rubygems.org'

gem 'serverspec'

$ bundle install
$ serverspec-init
$ rake

Mit dem Kommando serverspec-init wird die Testumgebung zur Prüfung der Installation erzeugt. Das Werkzeug serverspec kann für verschiedene Unix Plattformen und Windows genutzt werden. Es kann remote via ssh oder lokal mit der jeweiligen Shell ausgeführt werden. Schön ist, dass der Generator gleich eine Variante für den ssh-Zugang einer Vagrant Box generieren kann. Wie für die Aufgabe gemacht, wird gleich eine Apache httpd-Testspezifikation mitgeneriert.

$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 1

Vagrant instance y/n: y
Auto-configure Vagrant from Vagrantfile? y/n: y
 + spec/
 + spec/apacheSpecbox/
 + spec/apacheSpecbox/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile
###

Eine Überprüfung der Node zeigt, dass der Apache noch nicht installiert ist. Stimmt!

$ rake spec
/usr/bin/ruby -S rspec spec/apacheSpecbox/httpd_spec.rb
FFFFFF
...viele Fehlermeldungen...

Finished in 0.99715 seconds
6 examples, 6 failures

Ein Blick auf die Spezifikation spec/apacheSpecbox/httpd_spec.rb zeigt die Anforderungen. Das httpd-Package soll installiert sein. Der httpd soll als OS-Service konfiguiert werden. Wie gewohnt soll der Apache unter dem Port 80 erreichbar sein.

## spec/apacheSpecbox/httpd-spec.rb
require 'spec_helper'

describe package('httpd') do
  it { should be_installed }
end

describe service('httpd') do
  it { should be_enabled   }
  it { should be_running   }
end

describe port(80) do
  it { should be_listening }
end

describe file('/etc/httpd/conf/httpd.conf') do
  it { should be_file }
end

Zum Erreichen dieses Ziels, muss die Node nun provisioniert werden. Vagrant bringt eine Vielzahl von entsprechenden Plugins für Ansible, Chef, Puppet, Saltstack oder Shell gleich mit. Zur Umsetzung der Anforderungen reicht der Shell-Provisioner erstmal völlig aus. Durch folgende Änderungen in der Datei Vagrantfile kann dies schnell implementiert werden.

# -*- mode: ruby -*-
# vi: set ft=ruby :
## Vagrantfile

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "2creatives/centos65-x86_64-20140116"
  config.vm.box_url = "https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box"
  config.vm.box_download_checksum_type="sha256"
  config.vm.box_download_checksum = "84eda9c4f00c86b62509d1007d4f1cf16b86bccb3795659cb56d1ea0007c3adc"

  config.vm.define :apacheSpecbox do |c|
    c.vm.network "private_network", ip: "192.168.33.10"
    c.vm.host_name = "apacheSpecbox.example.com"
    c.vm.provider "virtualbox" do |vb|
         vb.gui = false
         vb.customize [ "modifyvm", :id, "--memory", "512"]
         vb.customize [ "modifyvm", :id, "--cpus", "1"]
         vb.name = "apacheSpecbox"
    end

    c.vm.provision "shell",
         inline: <<SCRIPT
echo I am provisioning...
yum -y install httpd
date > /etc/vagrant_provisioned_at
SCRIPT

    end

end

Mit dem Befehl vagrant provision wird nun die Provisionierung ausgeführt. Ein erneuter Test zeigt, dass nun der Apache durch die Packages zwar installiert ist, aber er weder gestartet, noch als Service angemeldet ist. Weiterhin fehlt das Package nc, damit serverspec die Tests auf dem Port durchführen kann. Weiterhin wäre es auch schön, wenn der httpd Server auch den richtigen ServerName bekommt. Durch eine Modifikation unseres kleinen Inline Provisinierungsskripts lässt sich das schnell erledigen.

   c.vm.provision "shell",
         inline: <<SCRIPT
echo I am provisioning...
yum -y install httpd nc
sed -i 's/#ServerName www.example.com:80/ServerName apacheSpecbox.example.com:80/g' /etc/httpd/conf/httpd.conf
chkconfig httpd on --level 2345
service httpd restart
date > /etc/vagrant_provisioned_at
SCRIPT

Mit der nächsten Provisionierung gelingt nun die Verifikation. Unser Ergebnis ist das erstmal Grün!

$ vagrant provision
$ rake spec
/usr/bin/ruby -S rspec spec/apacheSpecbox/httpd_spec.rb
.......

Finished in 0.99715 seconds
6 examples, 0 failures

Die Validierung bringt zu Tage, dass die Basisanforderungen erfüllt und überprüft werden können. Weiterhin sind alle Schritte der Installation und der Testausführung beschrieben. Eine wiederholbare Testprozedur für die Apache httpd Installation ist implementiert. Als Verfahren sind die Test vor der Implementierung umgesetzt worden. Eine noch bessere Integration von Serverspec und Vagrant existiert im Projekt vagrant-serverspec plugin.

Die Installation des Plugin erfolgt mit folgendem Befehl:

$ vagrant plugin install vagrant-serverspec

Die Integration als Vagrant Provisioner erfolgt im Konfigurations-Block des Nodes apacheSpecbox

## Vagrantfile
    c.vm.provision :serverspec do |spec|
       spec.pattern = 'specs/apacheSpecbox/*_spec.rb'
    end

Für die Ausführung dieser Variante bietet sich an, die gesamte Provisionierung einfach zu wiederholen. Dazu zerstören man den aktuellen Node und setzen diesen komplette neu auf. Mithilfe des Plugins werden nun unsere Test sofort ausgeführt. Volia!

$ vagrant destroy apacheSpecbox
$ vagrant up apacheSpecbox
# look at results

Leider ist die Version von Serverspec im Plugin veraltet. Deshalb raten ist zur Zeit die direkten Installation der bessere Weg. Die Gestaltung von flexiblen Testspecs ist damit zukunfsträchtiger. Ein wichtiger erster Schritt für die Bereitstellung von testgetriebener Infrastruktur ist vollbracht. Ein Testfirst-Ansatz für die Infrastruktur ist also ohne wesentlichen Aufwand möglich. Eine inkrementellere Arbeitsweise für die Erstellung von Systemen leicht umsetzbar.

Nun geht es an die Verbesserung des Erreichten. In diesem Blog wird es dazu noch viel zu lesen geben.

Peter

serverspec standalone betreiben

2014-05-07T00:00:00+02:00

Nachdem wir im letzten Post allgemein vorgestellt haben, was man mit serverspec machen kann, wollen wir die ersten Beispiele in eine ausführbare Form bringen, sodass man damit weiter experimentieren kann.

Voraussetzungen

Um den Post nicht zu groß aufzubauen und nicht zu viele Abhängigkeiten einzuführen, benötigen wir nur eine Serverinstanz, auf der wir lokal testen. Das kann eine VM oder auch das eigene Notebook sein. Auch wenn serverspec mit vielen Betriebssystemen umgehen kann, sind Debian- oder Redhat-Distros zum Spielen am einfachsten. Die Beispiele gehen von CentOS-6.5 mit englischem Locale aus.

Es läuft einfacher, wenn die Instanz auf Repos im Internet zugreifen kann, es geht aber auch offline bzw. mit lokalen Mirrors. Das ist durchaus hilfreich in Umgebungen, in denen nicht jeder Server Zugriff nach außen hat und auch (noch) keine lokalen Mirros aufgesetzt sind.

Eine weitere Voraussetzung ist eine lauffähige Ruby- und rubygems-Installation ab Version 1.8.7. Diese wird in der Regel von den Linux-Distributionen in den eigenen Paketrepositories mitgeliefert. Also:

$ sudo yum install -y ruby rubygems

oder bei Debian

$ sudo apt-get install ruby1.9.3 rubygems

Installation von serverspec

Online

Natürlich ist die online-Installation am einfachsten. serverspec liegt als gem-Paket bei rubygems.org vor, und darüber werden abhängige Pakete erkannt und mit installiert.

$ sudo gem install serverspec rake --no-ri --no-rdoc
Successfully installed net-ssh-2.9.0
Successfully installed rspec-core-2.14.8
Successfully installed diff-lcs-1.2.5
Successfully installed rspec-expectations-2.14.5
Successfully installed rspec-mocks-2.14.6
Successfully installed rspec-2.14.1
Successfully installed highline-1.6.21
Successfully installed specinfra-1.11.0
Successfully installed serverspec-1.6.0
Successfully installed rake-10.3.1
10 gems installed

Was machen die Pakete:

diff-lcs findet Unterschiede bspw. in Arrays
net-ssh ist eine Ruby-Library zum SSH-Connect zu anderen Hosts
rspec-* sind alle Pakete für RSpec (www.rspec.info)
highline für etwas Farbe im Kommandozeilenleben
specinfra ist das Serverspec-Backend mit einer Abstraktion für verschiedene Betriebssysteme mit deren Kommandos.
serverspec das eigentliche Serverspec-Frontend, das wir benutzen wollen.

Offline

Die Offlineinstallation ist auch kein Problem, dazu ziehen wir uns die notwendigen Pakete von rubygems und kopieren sie auf die Serverinstanz. Wer mag, setzt sich eine eigenen rubygems-Mirrorserver auf.

$ for i in diff-lcs-1.2.5 net-ssh-2.9.0 highline-1.6.21 bundler-1.6.2 rake-10.3.1 rspec-core-2.14.8 rspec-expectations-2.14.5 rspec-mocks-2.14.6 rspec-2.14.1 specinfra-1.11.0 serverspec-1.6.0; do
  wget http://rubygems.org/downloads/${i}.gem
done;

Dann lokal installieren:

$ sudo gem install --local --no-ri --no-rdoc rake-10.3.1.gem bundler-1.6.2.gem diff-lcs-1.2.5.gem rspec-core-2.14.8.gem rspec-expectations-2.14.5.gem rspec-mocks-2.14.6.gem rspec-2.14.1.gem net-ssh-2.9.0.gem highline-1.6.21.gem specinfra-1.11.0.gem serverspec-1.6.0.gem
Successfully installed rake-10.3.1
Successfully installed bundler-1.6.2
Successfully installed diff-lcs-1.2.5
Successfully installed rspec-core-2.14.8
Successfully installed rspec-expectations-2.14.5
Successfully installed rspec-mocks-2.14.6
Successfully installed rspec-2.14.1
Successfully installed net-ssh-2.9.0
Successfully installed highline-1.6.21
Successfully installed specinfra-1.11.0
Successfully installed serverspec-1.6.0
11 gems installed

Init!

Um mit den eigenen Specs loszulegen, bringt serverspec ein Skript serverspec-init mit, um eine Art Vorlage zu generieren, die erstmal lauffähig ist. Das rufen wir in einem leeren Verzeichnis auf, und beantworten einige Fragen:

$ mkdir myspecs
$ cd myspecs
$ serverspec-init

Hier müssen wir entscheiden, wo die zu testende Instanz liegt. Entweder greift serverspec per ssh darauf zu, oder man testet die eigene Instanz (local). Das wollen wir in unserem Fall auch tun, für Unix:

$ serverspec-init
Select OS type:

  1) UN*X
  2) Windows

Select number: 1

Select a backend type:

  1) SSH
  2) Exec (local)

Select number: 2

Die leere Vorlage

Serverspec hat das folgende für uns erzeugt:

 + spec/
 + spec/localhost/
 + spec/localhost/httpd_spec.rb
 + spec/spec_helper.rb
 + Rakefile

Wofür braucht man was?

*_spec.rb

Das sind die eigentlichen Spezifikationsfiles, wo die Tests lagern. Bei der Zusammenstellung ist man frei: Ein _spec.rb für hunderte Tests (nicht sinnvoll) oder für jeden Tests ein eigenes _spec.rb (auch nicht sinnvoll). In den nächsten Posts werden wir hierfür eine sinnvolle Struktur aufzubauen.

Rakefile

Rake ist quasi das "make" für ruby. Es automatisiert Vorgänge und dient uns hier als "Glue", um die rspec-basierten Tests anzustarten. Man könnte auch rspec direkt ausführen, allerdings biegt das für uns generierte Rakefile einige Dinge für die Ausführung richtig. In der Standardversion werden einfach alle Dateien im spec/ Unterverzeichnis (und den darunter liegenden Verzeichnissen) aufgegriffen, die auf _spec.rb enden.

spec_helper.rb

Der Spec-Helper wird von den Testcases verwendet ("require") und schafft einige Voraussetzungen. Interessant sind z.B. das Erkennen von Betriebssystemen (include .... DetectOS) sowie (falls noch notwendig) das abfragen eines Passworts für sudo.

http_spec.rb

Die leere Vorlage ist gar nicht so leer, sie enthält nämlich ein Beispiel für einen funktionierenden Webserver, die wir einfach verwenden werden. Geprüft wird:

dass ein OS-Paket installiert wurde (hier: httpd, passt auf RHEL),
dass der Service automatisch gestartet wird und aktuell läuft,
dass ein Port geöffnet ist und
dass eine Konfigurationsdatei mit bestimmten Inhalte vorliegt.

Das sieht dann so aus:

require 'spec_helper'

describe package('httpd') do
  it { should be_installed }
end

describe service('httpd') do
  it { should be_enabled  }
  it { should be_running  }
end

describe port(80) do
  it { should be_listening }
end

describe file('/etc/httpd/conf/httpd.conf') do
  it { should be_file }
  it { should contain "ServerName localhost" }
end

Die Syntax ist sehr einfach und fast natürlichsprachlich. Es besteht aus mehreren Blöcken, die bestimmte Aspekte (package, service, port, file) beschreiben. In den Blöcken liegen dann Match-Ausdrücke, die bestimmte Konditionen abprüfen

Erster Testrun

Wir lassen "die spec" einfach mal laufen und schauen, was passiert:

$ sudo rake spec
Failures:

  1) Package "httpd" should be installed
     Failure/Error: it { should be_installed }
       rpm -q httpd
       package httpd is not installed
       expected Package "httpd" to be installed
     # ./spec/localhost/httpd_spec.rb:4

  2) Service "httpd" should be enabled
  ....

  ....

Finished in 0.05863 seconds
6 examples, 6 failures

Failed examples:

rspec ./spec/localhost/httpd_spec.rb:4 # Package "httpd" should be installed
rspec ./spec/localhost/httpd_spec.rb:8 # Service "httpd" should be enabled
rspec ./spec/localhost/httpd_spec.rb:9 # Service "httpd" should be running
rspec ./spec/localhost/httpd_spec.rb:13 # Port "80" should be listening
rspec ./spec/localhost/httpd_spec.rb:17 # File "/etc/httpd/conf/httpd.conf" should be file
rspec ./spec/localhost/httpd_spec.rb:18 # File "/etc/httpd/conf/httpd.conf" content should match /ServerName localhost/
/usr/bin/ruby -S rspec spec/localhost/httpd_spec.rb failed

Wir sehen, dass eigentlich alles fehlschlägt. Klar, denn noch haben wir nichts installiert bzw. provisioniert.

Red, Green, Refactor

Gemäß dem Testdriven-Zyklus sind wir jetzt im "Red" angelangt. Wir haben einen Testcase, der einen Zielzustand beschreibt. Unsere Infrastruktur- Tests schlagen fehl, also machen wir uns daran, diese grün zu bekommen.

Disclaimer: Natürlich wählt man hierzu am besten ein Provisionierungswerkzeug, also Salt, Chef, Puppet, ... Um den Post einfach zu halten werden wir hier manuell installieren, das Umformen (z.B. ein Provisioner für Vagrant) bleibt dann für den "Refactor"-Schritt :-)

Das erste ist die Installation des Pakets.

$ sudo yum install -y httpd

Wir lassen die spec noch einmal laufen und sehen:

$ sudo rake spec
...
...
Finished in 0.0678 seconds
6 examples, 4 failures

Failed examples:

rspec ./spec/localhost/httpd_spec.rb:8 # Service "httpd" should be enabled
rspec ./spec/localhost/httpd_spec.rb:9 # Service "httpd" should be running
rspec ./spec/localhost/httpd_spec.rb:13 # Port "80" should be listening
rspec ./spec/localhost/httpd_spec.rb:18 # File "/etc/httpd/conf/httpd.conf" content should match /ServerName localhost/
/usr/bin/ruby -S rspec spec/localhost/httpd_spec.rb failed

Oben hatten wir noch 6 Failures, jetzt nur noch 4. Es wird. Als nächstes sollte httpd.conf konfiguriert werden. Wir fügen dort localhost ein:

$ sudo vi /etc/httpd/conf/httpd.conf
....
ServerName localhost:80
...

Ein erneuter Test:

$ sudo rake spec
6 examples, 3 failures

Failed examples:

rspec ./spec/localhost/httpd_spec.rb:8 # Service "httpd" should be enabled
rspec ./spec/localhost/httpd_spec.rb:9 # Service "httpd" should be running
rspec ./spec/localhost/httpd_spec.rb:13 # Port "80" should be listening

Nur noch 3 Failures. Als nächstes sollte der Service laufen und automatisch gestartet sein:

$ sudo chkconfig --add httpd
$ sudo chkconfig --level 345 httpd on
$ sudo service httpd start

Und so ist das Endresultat:

$ sudo rake spec
/usr/bin/ruby -S rspec spec/localhost/httpd_spec.rb
......

Finished in 0.05298 seconds
6 examples, 0 failures

Damit sind wir "green".

What's next?

Jetzt können wir unsere Tests spezifizieren und auf einem konkreten Server ausführen. Mit dieser Basis können wir spielen und neue Tests einbauen. Eine gute Übersicht dessen was möglich ist, gibt die Seite Resource Types

In einer etwas realistischeren Arbeitsumgebung wird es aber viele Server geben, die sich in Gruppen einteilen lassen (Webserver, Applikationsserver, ...). Und vermutlich haben wir mehrere Umgebungen (Test, Live, ...), die sich in Teilen unterscheiden.

All das lässt sich auch mit serverspec abdecken, die nächsten Posts zeigen, wie :-)

Andreas

serverspec: Server spezifizieren und testen

2014-04-25T00:00:00+02:00

In der Softwareentwicklung sind Spezifikation und Testen fester Bestandteil des Arbeitsweise. Unit-Testing und Test Driven Development haben in der modernen Entwicklung ihren festen Platz, ob agil oder nicht. Bei der Bereitstellung von IT Infrastruktur, also Netzwerk, Storage und Compute sieht es dagegen noch eher klassisch aus: Appliances und Server werden aufgebaut und übergeben, und wenn technische Einzelheiten nicht funktionieren, wird nachgearbeitet.

Bei der Bereitstellung von virtuellen Maschinen sieht es schon etwas besser aus. Hier haben Elemente aus der Test Driven Infrastruktur Einzug gehalten. VMs entstammen entweder einem Image oder einer strukturierten Installation (z.B. Kickstart), und sie erhalten ihre Konfiguration über entsprechende Werkzeuge wie Salt, Ansible oder Puppet.

Aber auch diese Werkzeuge benötigen ihre Konfigurationen, die - je nach Werkzeug - eher gecoded als "spezfiziert" aussehen. Puppet als Beispiel bietet eine deklarative DSL, aber eine größere Puppetinstallation inkl. PuppetDB und/oder Hiera, Module und deren Abhängigkeiten besitzt eine eigene Komplexität. Und die muss durch erfahrene Infra-Coder gemanaged werden.

Wie soll das Endergebnis aussehen?

An welcher Stelle in der Bereitstellungskette wird eigentlich genau beschrieben, "wie" das Endergebnis aussehen soll? Und mit welcher Sprache?

Ruby-Entwickler kennen mit rspec, cucumber und gherkin Möglichkeiten, (Code-)Funktionalität zu spezifizieren. Die sieht dann - je nach verwendetem Framework - auch natürlich-sprachlich aus. Dasselbe gibt es nun auch für IT-Infrastruktur, im speziellen: Servern.

serverspec

Serverspec ist ein Werkzeug, um RSpec-Testfälle für Server formulieren und ausführen zu können. Dabei wird das Endergebnis spezifiziert und getestet. D.h. es ist egal, mit welchem Konfigurationsmanagementtool ein Server aufgesetzt wurde oder ob er sogar manuell installiert wurde, serverspec testet allein den aktuellen Zustand.

Wie sieht so etwas aus? Ein paar Beispiele:

Es sollten User da sein.

describe user 'vagrant' do
  it { should exist }
  it { should belong_to_group 'sudo' }
  it { should have_home_directory '/home/vagrant' }
end

Dateien sollten vorhanden sein, mit bestimmten Inhalten

describe file '/home/vagrant/.ssh/authorized_keys' do
  it { should be_file }
  it { should be_mode 600 }
  it { should contain('vagrant@precise64') }
  it { should be_owned_by 'vagrant' }
  it { should be_grouped_into 'vagrant' }
end

Prozesse sollten laufen, Ports sollten offen sein

describe process 'sshd' do
  it { should be_running }
end

describe port(22) do
  it { should be_listening.with 'tcp' }
end

An den einfachen Beispielen lässt sich die Funktionsweise von serverspec gut zeigen. Eine Spezifikation besteht aus mehrere Blöcken, worin ein bestimmter Aspekt (User, File, Process, Port, ...) beschrieben ist. Die Ausdrücke im Block selber findet sich sog. RSpec Expectations und Matchers, d.h. Ausdrücke die für den jeweiligen Aspekt erfüllt sein sollen. Wie funktioniert nun das Testen selber?

Wie arbeitet serverspec?

Serverspec kann je nach Modus unterschiedlich arbeiten: Lokal, per SSH auf einen entfernten Host oder z.B. mit Vagrant Plugins in eine virtuelle Maschine. Dabei werden Kommandos zusammengebaut, um die "Rohdaten" einer Expectation abzufragen und gegen den Matcher zu prüfen. Das klingt eher abstrakt, von daher ein konkretes Beispiel:

describe file '/home/vagrant/.ssh/authorized_keys' do
  it { should be_mode 600 }

Es soll also geprüft werden, ob die authorized_keys den Mode 600 besitzt. Serverspec wird daraus diese Schritte bauen:

Eine Verbindung zum Ziel vorbereiten (z.b. per SSH)
ein Kommando konstruieren, das für das Betriebssystem des Servers passt, also:
- sudo stat -c %a /home/vagrant/.ssh/authorized_keys | grep -- \^600\$
das Kommando ausführen, das Ergebnis abholen und vergleich.

In diesem Fall wird vom grep der Exitcode verwendet, die einfachste Möglichkeit. Bei anderen Abfragen können auch reguläre Ausdrücke eingesetzt werden.

Und so sieht es aus, wenn man es ausführt: /usr/bin/ruby -S rspec spec/node/simple_spec.rb .... Finished in 0.95 seconds 4 examples, 0 failures

Das war jetzt ein kleines Beispiel, wie man mit serverspec Aspekte einer Serverinstallation spezifizieren und testen kann. Serverspec bietet aktuell ca. 30 dieser Aspekte - genannt Resource Types - an, um vielfältige Dinge zu testen. Die Bandbreite reicht von Repositories, Prozessen, Netzwerk, Dateien, User und Gruppen bis zu Mounts und Filesystemen.

Wofür ist das gut?

Die Frage ist gar nicht so leicht zu beantworten, es hängt nämlich davon ab, was für ein Unternehmen man ist, und welcher Art von Einschränkungen man ggf. unterliegt. Aber es gibt Mehrwert für fast alle Vorhaben. Die drei wichtigsten Gründe für die Verwendung von Tests in der Infrastruktur-Entwicklung sind:

Qualität: Die Deployment Pipeline kann um eine zusätzliche Qualitätsstufe erweitert werden, die nicht nur die Artefakte auf dem Weg durch die Pipeline testet, sondern auch das Endergebnis.
Auditierbarkeit: Zur Unterstützung eines IT-Audits lässt sich eine natürlichsprachliche Spezifikation der Serverlandschaft verfassen und automatisiert testen.
Regressionstest: Auch Server lassen sich nun nach Veränderungen (z.B. Deployments oder anderen Changes) regressionstesten.

Wie geht's weiter?

Jetzt haben wir nur an der Oberfläche gekratzt, aber hoffentlich Interesse geweckt. Weitere Blogposts werden sich detailliert mit Serverspec befassen.

Andreas

Herzlich Willkommen zum Blog

2014-04-23T00:00:00+02:00

Dies ist ein Blog über IT-Infrastruktur und den aufkommenden Trend "Infrastruktur als Code".

Im Zuge der Virtualisierung und der Open Source Entwicklung werden viele Aspekte von IT-Infrastruktur kontinuierlich erweitert und neu definiert. Komplexität und Vielfält hinsichtlich Werkzeuge und auch der darunterliegenden Technologien nehmen täglich zu.

IT-Infrastrukturen werden auch nicht mehr manuell betrieben. Es entstehen ablauffähige Prozeduren, die installieren, migrieren und prüfen. Diese Pipelines sind in der Softwareentwicklung schon seit längerem bekannt, und dort versuchen Entwickler schon seit mehr als 20 Jahren durch frühzeitiges Testen ein umfassenderes Feedback ihrer Änderungen zu bekommen. Weitreichende Maßnahmen zur Qualitätssicherung gehören dort zum Standard.

Wir müssen nun das Thema der Qualität auch in der Infrastrukturentwicklung neu definieren.

Gerade die OpenSource Projekt sind hierbei ein wichtiger Motor für die Verbreitung und Quelle der Inspiration mehr Qualität zu realisieren. Notwendigerweise müssen sie deshalb grosse Teile ihrer Implementierungen konsequent testen. Ständige Veränderungen, neue Teamkonstellation und kurze Produktionszyklen bestimmt den Alttag. Qualitätsmängel werden von Kunden und Produktverantwortlichen schnell entdeckt und wenig geschätzt. Im Bereich der Infrastruktur betreten wir mit diesem Thema meist noch Neuland.

In diesem Blog beginnen wir nun die testgetriebene Vorgehensweise für die Entwicklung der Infrastruktur zu adaptieren. Hierbei werden wir bestehende Techniken, Werkzeuge und Vorgehensweisen vorstellen und empfehlen.

Viele Grüße und viel Spaß wünschen:

Peter Roßbach

Andreas Schmidt

Infrastruktur mit Qualität

Docker Container mit serverspec testen - Teil 2

Resource Types

docker_image

docker_container

Einer nach dem anderen...

Docker-Backend

Fazit

Docker Microservice Basis mit Apache Tomcat implementieren

Bereitstellen von Java- und Apache Tomcat Docker-Images

Das Experiment: Ein Java-Image für Dev und Ops bereitstellen

JDK gefällig

Apache Tomcat Image - Ontop

Die erste Anwendung - Hello Status

Nutzung der Tomcat Manager Webapp

Tricks

Docker Container Overlay

Docker Composition: Tomcat als Data-Container nutzen

Fazit

Docker-Container mit Serverspec testen

SSH

Zur Build-Zeit

Mit serverspec und dem Docker-Backend

nsenter

nsenter + serverspec

Testbarkeit: Gegeben!

Docker-Hosts mit Puppet provisionieren und testen

Vagrant/Docker-Provisioner

Puppet-Modul für Docker

Mit der leere VM beginnen ...

... Serverspec-Basis dazugeben ...

... Spezifikation formulieren ...

... Das Puppet-Modul hinzufügen ...

... und Docker über Puppet installieren lassen

Fertig!

Docker entschlüsselt: Netzwerk-Teil 2

Der Plan: Eine neue Bridge anlegen

Voraussetzungen

Pipework

Anzeige der Bridge-/Interface-Struktur

Container über VM-Grenzen verbinden

Fazit

Docker entschlüsselt: Netzwerk

Das Netzwerk im Docker-Container

Was ist eigentlich die Bridge docker0? ...

Anschluss in die Welt da draußen

Kommunikation zwischen den Docker-Containern auf dem selben Host

Docker-Container für die Aussenwelt erreichbar machen

Im Detail ...

Docker mit boot2docker starten

Erste Schritte mit Docker

Installation von boot2docker

Start des ersten Docker-Containers

Security-Tests mit serverspec

You should_not ...

Pakete

Nutzer ohne Shell

NFS-Mounts

Konfigurationsdateien am Beispiel Apache

SSL-Zertifikate als Ressourcen beschreiben

Docker 1.0 steht bereit

Der blaue Wal legt nun richtig los....

infrataster und serverspec: Blackbox- und Whitebox-Testing

Whitebox ...

... und Blackbox

Geschmacksprobe: Infrataster

Beides zusammen, FTW!

serverspec mit Vagrant verbinden

serverspec standalone betreiben

Voraussetzungen

Installation von serverspec

Online

Offline

Init!

Die leere Vorlage

*_spec.rb

Rakefile

spec_helper.rb

http_spec.rb

Erster Testrun

Was ist eigentlich die Bridge `docker0`? ...