Docker 1.9.1 hängt mit Docker Toolbox auf Windows

diese Woche ist das Problem aufgetreten, dass auf den Entwicklerrechnern Docker Container einfach hängen geblieben sind und nicht mehr reagiert haben. Die Umgebung war ein Windows® 7 Prof mit Docker Toolbox. Der Fehler trat beim Starten einer docker-compose Konfiguration mit 4 Containern (zwei JBoss, zwei PostgreSQL) auf. Auch ein docker-compose stop oder rm -f war bei dem hängenden Container nicht mehr möglich. Windows zeigte an, dass ein Prozessor bei 100% ausgelastet ist.

Bei einigen Entwicklern hat es funktioniert, bei anderen nicht. Wie sich herausstellte, war bei Ersteren die Version 1.9.0 der Toolbox installiert, bei denen Zweiten eine Version 1.9.1.

Nach der Analyse des Problems, habe ich dann den Issue #18180 gefunden. Dort sind diverse Vorschläge dokumentiert, wie man das Problem lösen kann. In unserem Fall hat es geholfen den storage driver von docker engine auf overlay zu ändern. Wir haben dazu das Script (start.sh) hinter Docker Quickstart angepasst und bei der Erzeugung des Virtualbox Images mit dem Namen “default” noch folgenden Parameter angegeben:

... --engine-storage-driver overlay ...

Dies kann man aber auch direkt auf der Konsole machen, indem man die alte Maschine erst löscht und dann neu mit dem Treiber overlay anlegt:

docker-machine rm default
docker-machine create -d virtualbox --engine-storage-driver overlay default

Veränderungen

in letzter Zeit gab es bei mir einige Veränderungen. Angefangen hat es damit, dass ich überlegt habe, was ich wohl in nächster Zeit gern machen würde.

Über die Jahre habe ich von Programmierung, über Projektmanagement und Teamleitung bis hin zur Infrastruktur in vielen Bereich gearbeitet, mich weitergebildet und Erfahrungen gesammelt. Mich interessiert die Softwareentwicklung und ich bin froh, diesem Interesse auch beruflich nachgehen zu können. Insbesondere faszinieren mich die kleinen Dinge. Bausteine die je nach Problemstellung flexibel zusammengesetzt werden können Dazu gehören natürlich die Grundlagen der Softwareentwicklung (Test Driven Development, Software Craftsmanship) auch moderne methodische Ansätze (agile, lean, Domain Driven Design, Continuous Delivery), kleine Tools (vert.x, Ratpack, Spring BootGradle – ich benutze meist Java/JVM) und offene Herangehensweisen. Im Kern geht es mir darum, die Geschwindigkeit bei der Umsetzung zu erhöhen, ohne das wirklich Stress entsteht. Deshalb halte ich den Zeitpunkt für wichtig, wann etwas gemacht wird. Auch schnelle Iterationen über Ideen und nicht erst über die Umsetzung halte ich für zielführend.  Damit verbunden ist eine enge Zusammenarbeit von Fachbereich,  Entwicklungsabteilung und möglichst auch des Benutzers. Die schnelle Verifikation dieser Ideen ist wichtig – möglichst im Tagesrhythmus,  wenn nicht gar schneller –  um den wirklichen Nutzen eines Produktes zu finden. Interdisziplinäre Teams (Business/Development/Operating/QA  – vielleicht BusDevOps 🙂 ) sind dafür äusserst hilfreich.

Seit einigen Jahren halte ich nun Vorträge (Docker, Microservices, Component Management) und gebe Workshops (Coderetreat, Continuous Delivery). Ich engagiere mich in der Entwicklergemeinschaft und bin Präsident der Java User Group Switzerland geworden. Meine Frau und ich haben zusammen die Weiterbildungstagung “Open Source an Schulen 2015” organisiert. Zusammen mit Geza (aka @infinitary)  bereite ich den  SoCraTes Day Switzerland vor.

Der grösste Schritt war aber sicherlich, mich selbstständig zu machen: 2015 habe ich die Nautsch Gmbh gegründet. Wir sind interessiert an Kunden, die mit uns in einem partnerschaftlichen Verhältnis an Lösungen erarbeiten möchten und dabei an neuen Sichtweisen interessiert sind. Die Grösse des Unternehmens spielt eine untergeordnete Rolle. Ich persönlich habe Erfahrungen sowohl im Start-Up Umfeld als auch in sehr grossen Unternehmen gesammelt. Wenn Sie also einen Partner für die Umsetzung einer Idee suchen, intern ein Team aufbauen wollen und einen Trainer suchen, oder einfach technische Unterstützung benötigen,  helfe ich gern weiter! Sie erreichen mich am besten per E-Mail:

info@nautsch.com

Software Chirurgie

Auf der Fahrt nach Budapest zur CraftConf 2015  hatten meine Frau und ich eine intensive Diskussion über den Begriff “Software Craftmanship” und wie er wohl für das passt was wir in der Software-Entwicklung machen. Es fehlten ihr die Kopfarbeit und die Voraussetzungen bzw. Ausbildung, welche notwendig sind, um in diesem Bereich erfolgreich zu arbeiten. Die Begriffe Handwerker (im Deutschen noch ganz besonders), Architekt und Ingenieur passten nicht so richtig. Wobei ich zugeben musste, dass der Letztere wohl am besten sei. Da wir in der Softwareentwicklung (noch) keine eigenen Begriffe für unsere Tätigkeiten haben, bedienen wir uns Worten aus gekannten Bereichen. Seit der ersten Konferenz über Software Engineering 1968  leihen wir uns die Definitionen aus dem Bauingenieurwesen aus. Die Wahl dieser Metaphern kann aber nur eine Annäherung sein – zu gross sind die Unterschiede. Die physischen Gesetze wie man sie z.B. beim Brücken- oder Häuserbau vorfindet, gibt es in unserem Bereich nicht. Das Serien-Produktionsproblem die es in anderen Ingenieurs-Disziplinen wie z.B. bei der Serienproduktion im Autobau auftritt – bei uns nicht vorhanden. Kopieren ist einfach.

Und dann kam der Vortrag “Beyond Features: Rethinking Agile Planning and Tracking” von Dan North und seine Frage ob wohl der Begriff der Chirurgie (engl. : surgery) besser passen könnte. Seine Überlegungen, dass ein operativer Eingriff mi­ni­mal­in­va­siv ausgeführt werden soll, passt sehr gut auf die derzeitigen Bestrebungen im Bereich von Agile, Software Craftmanship und Lean, eine Lösung einfach zu halten und nur die Dinge zu bauen, die wirklich benötigt werden.

Hier ein paar Punkte die mir in diesem Zusammenhang durch den Kopf gehen und welche jedem erfahrenen Softwareentwickler bekannt vorkommen könnten:

  • chirurgische Eingriffe müssen schnell ausgeführt werden
  • ein Chirurg muss neben einer fundierten Ausbildung gute handwerkliche Fähigkeiten vorweisen können
  • es gibt einfache und sehr komplizierte Operationen
  • Komplikationen sind keine Seltenheit und man muss situativ reagieren können
  • es ist schwierig die Dauer einer Operation im Vorfeld abschätzen zu können, insbesondere dann, wenn etwas Neues versucht wird oder der Eingriff kompliziert ist
  • ein Team von unterschiedlichen Experten arbeitet zusammen
  • die Qualität der Arbeit hängt stark von den Fähigkeiten der Ärzte ab
  • die Umgebung hat einen entscheidenden Einfluss – im Fall einer Operation muss der Raum sauber sein, die Instrumente müssen bereit liegen und die Maschinen (hoffentlich nicht veraltet) müssen funktionieren
  • es kommen Fehler vor (Instrumente verbleiben im Körper, das falsche Bein wird amputiert)
  • neue Techniken können eine enorme Bereicherung und ganz neue Möglichkeiten bieten
  • Ärzte müssen sich ein Leben lang weiterbilden (oder möchte jemand von einem Arzt operiert werden, der noch mit dem Wissen aus seinem Studium in den 90igern arbeitet?)
  • kommt ein Arzt zu einem Unfallort muss er improvisieren können
  • es bleiben Narben
  • am liebsten geht man zu den besten Ärzten, aber wenn es schnell gehen muss oder man keine Krankenversicherung hat, nimmt man den Arzt, der verfügbar ist
  • es gibt Scharlatane die Heilung versprechen
  • mit jedem Eingriff lernt man hinzu, bekommt Routine und trotz viel Erfahrung kann man es immer noch besser machen

Meiner Meinung nach kann aber die Analogie zur Chirurgie nur eine Metapher bleiben. Aber ich finde sie hat etwas.

Auch ich habe das Bild eines Arztes schon oft verwendet. Insbesondere dann, wenn ich mit unerfahreneren  Softwareentwicklern gearbeitet habe. Bei aller Theorie muss man immer im Auge behalten, dass das Ergebnis im Vordergrund stehen muss. Ein Arzt der an einen Unfallort kommt, findet dort nicht die idealen Bedingungen vor wie im Operationssaal. Trotzdem ist es seine Pflicht einem verletzten Menschen zu helfen. Und genau so ist es auch in der Softwareentwicklung. Es bringt nichts nur über die Schönheit unser Implementierung oder den richtigen Aufbau unserer Applikation zu philosophieren, wenn man für den Kunden keinen Nutzen erzeugen kann oder zu spät mit einer Lösung kommt. Im schlimmsten Fall ist der Patient tot. Im Fokus muss stehen, WAS gemacht werden muss um zu helfen – das WIE sollte man dabei aber nicht aus den Augen verlieren.

Wer gern etwas mehr Hintergrund zur Wichtigkeit von Metaphern haben möchte, dem sei das Buch “Leben in Metaphern: Konstruktion und Gebrauch von Sprachbildern” von George Lakoff und Mark Johnson empfohlen.

Auf jeden Fall werde ich versuchen richtige Chirurgen zu treffen und darüber zu sprechen. Schlussendlich bin ich in dem Bereich ein Laie. Und wenn sonst jemand Interesse hat: Einfach melden.

 

docker, golang and “Hello World” via HTTP

After reading the article “Create The Smallest Possible Docker Container” by Adriaan de Jonge I was wondering how long I need to install golang (again), write and build the server and get it running in a docker container. It took me ~30 minutes .

An interesting point is this the size of this container:

ollin/helloworldhttp                 latest                fd9ead3df193        16 minutes ago      4.072 MB

It’s only ~4 MB.

The virtual size of a small JRE  is ~386 MB (without any server):

seansummers/openjdk-7-jre-headless   latest                2cafc2975f19        7 months ago        386.6 MB

Adding a repository into /etc/apt/sources.list.d without python-software-properties installed

Here is an easy solution to install a new repository into /etc/apt/sources.list.d (e.g. ubuntu) without using the python-software-properties package. I found this in the relateiq/oracle-java8 Dockerfile . This example installs the Oracle JDK via the webupd8 java ppa.

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886

and then the installation:

apt-get update
# auto accept oracle jdk license
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections
apt-get install -y oracle-java8-installer

Spring Boot running in 2 min

Spring Boot 1.0.1 is released. I wanted to find the fastest way to get a spring boot app running. The usual “Hello world” was created and running in around 2 minutes. For the creation of the initial project files I used lazybones. The project template uses gradle as build tool. So I had to install gradle too. And the easiest way to install lazybones and gradle is gvm.

Install gvm:

curl -s get.gvmtool.net | bash
source "//.gvm/bin/gvm-init.sh"

Install gradle and lazybones:

gvm install gradle
gvm install lazybones

Create a project with the name “mycrm” with the template “spring-boot-actuator”:

lazybones create spring-boot-actuator mycrm

Change into project directory and build the runable jar:

cd mycrm
gradle bootRepackage

Run the application:

java -jar build/libs/spring-boot-sample-actuator-1.0.0.jar &

Get the hello world 🙂

wget -O - localhost:8080 | less

Done.