I am looking forward to meet LISP people at the 32c3’s LISP assembly. The last days I played a bit with different Scheme implementations including CHICKEN scheme. The main feature of CHICKEN is that it compiles the Scheme code to C and then creates dynamic libraries and binaries with the C compiler. I thought that combining these binaries with a minimal Docker container could give me a very small deployment. So here are my steps:

In Racket I want to iterate over my buckets in Amazon S3. They are located in different regions. So how do I get my bucket’s location/region? In the API Reference there is a call GET Bucket location. I use Greg’s AWS library for Racket and this library authenticates its calls with signature version V4. But V4 requires the user to know the region to correctly sign the request. So I need to know the region to ask Amazon S3 for the region where the bucket is located. Otherwise Amazon S3 responds with an error:

<?xml version="1.0" encoding="UTF-8"?>
<Error>
 <Code>AuthorizationHeaderMalformed</Code>
 <Message>The authorization header is malformed; the region 'us-east-1'
is wrong; expecting 'eu-central-1'</Message>
 <Region>eu-central-1</Region>
 <RequestId>XXXX</RequestId>
 <HostId>XXXX>
</Error>

After some search on the net I found a post on Stackoverflow that helped to solve that issue: If I use the URL format (instead of the normally used virtual host format) I could get the location of any bucket. Every region responds with a LocationConstraint answer.

Therefore a code snippet for Racket could be:

(define (get-bucket-location bucket)
  (parameterize
      ([s3-path-requests? #t])
    (define xpr (get/proc (string-append bucket "/?location") read-entity/xexpr))
    (and (list? xpr)
         (= (length xpr) 3)
         (third xpr))))

For example:

> (get-bucket-location "my-bucket-somewhere")
"eu-central-1"

PS: I think official Amazon S3 documentation could be a bit more verbose on the issues with GetBucketLocation and signature V4.

Update: Greg added a bucket-location function to his great library

I got a Raspberry Pi 2 Model B to play with. I used Raspbian image as operating system. I was wondering how difficult it is to get Racket running on the Raspberry Pi. I downloaded the Unix source + built packages tarball from Racket’s homepage because I only wanted to compile the core of Racket. After unpacking the tarball I was suprised that the instructions were quite short:

From this directory (where the `configure' file is), run the following
commands:

  mkdir build
  cd build
  ../configure
  make
  make install

Between make and make install I had to wait for about 40 minutes but then everything was fine and I could even use DrRacket on the Raspberry Pi:

DrRacket on Raspberry Pi

Very nice and easy to get Racket running on ARM.

PS: Because the Raspberry Pi 2 Model B has an ARMv7 processor the binary runs on my Jolla smart phone as well.

I started to use AWS for some projects recently. But I only use few of their services. From time to time I look into some of there services and wonder if they are useful for my tasks. I looked into AWS Lambda, "… a compute service that runs your code in response to events and automatically manages the compute resources for you, making it easy to build applications that respond quickly to new information." Nowadays these “lambda functions” could be written in NodeJS or Java. When I was looking for a roadmap of the supported languages I found an interesting blog post by Ruben Fonseca. He explaind how to run Go code on AWS Lambda.

I tried the same with Racket and wrote a short Racket programm test.rkt:

#lang racket/base

(display (format "Hello from Racket, args: ~a~%" (current-command-line-arguments)))

Then I used raco to create a binary test:

raco exe --orig-exe test.rkt

I took the NodeJS wrapper from Ruben’s blog post and put it in a file main.js:

var child_process = require('child_process');

exports.handler = function(event, context) {
  var proc = child_process.spawn('./test', [ JSON.stringify(event) ], { stdio: 'inherit' });

  proc.on('close', function(code) {
    if(code !== 0) {
      return context.done(new Error("Process exited with non-zero status code"));
    }

    context.done(null);
  });
}

Then I put both files in a zip archive, created a new AWS Lambda function, uploaded the zip file and invoked the function:

Invocation of AWS Lambda function

Fine!

PS: Only question is: When is AWS Lambda coming to the region eu-central-1, located in Frankfurt?

Upate (2016–03–15): AWS Lambda is now available in the EU (Frankfurt) region!

Heute benötigte ich eine Ersatzpatrone für meinen Lexmark-Drucker. An der Aufreißlasche prangen Ausrufezeichen und der Hinweis: “Attention: Updated License Terms”.

Lizenzbedingungen? Für eine Druckerpatrone? Also mal ein Blick aufs Kleingedruckte:

Bitte vor dem Öffnen lesen. Durch das Öffnen der Verpackung oder die Verwendung der mitgelieferten patentierten Kassette erklären Sie sich mit der folgenden Lizenz-Vereinbarung einverstanden. Diese patentierte Tonerkassette wird zu einem Sonderpreis verkauft und unterliegt der Patenteinschränkung, dass sie nur einmal verwendet wird. Nach ihrer erstmaligen Verwendung verpflichten Sie sich, sie zur Wiederaufbereitung und/oder zum Recylcing nur an Lexmark zurückzugeben. Die Tonerkassette funktioniert nach der Abgabe einer bestimmten Tonermenge nicht mehr. Wenn sie ersetzt werden muss, kann sie noch Resttoner enthalten. Die Kassette ist zusätzlich so konzipiert, dass die Informationen zur Kassettenkompatibilität im Druckerspeicher automatisch aktualisiert werden. Auf diese Weise kann die Verwendung gefälschter Kassetten und/oder bestimmer Drittprodukte eingeschränkt werden. Durch die Installation der beiliegenden Kassette gestatten Sie Lexmark, diese Änderungen vorzunehmen. Wenn Sie mit den vorgenannten Bedingungen nicht einverstanden sind, geben Sie die ungeöffnete Verpackung an Ihren Händler zurück. Nicht im Rahmen dieser Bestimmungen verkaufte Ersatztonerkassetten sind unter www.lexmark.com erhältlich.

Irgendwie ja auch ein bisschen putzig, wie um einen Alltagsgegenstand wie Toner so ein Bohei gemacht wird. Zwei Gedanken kommen mir da in den Sinn: 1. Es verfestigt sich mein Eindruck, dass das Patentsystem recht nahe an kaputt ist. 2. Unternehmen, die so etwas machen, sollten weniger Geld für Juristen, Patentanwälte ausgeben und das Geld eher in coole Produkte investieren.

Am 13. Januar 2015 fand in Frankfurt das bereits dritte Docker-Meetup statt, hier einige Notizen von mir dazu.

Neues zum Them Orchestrierung

Peter Rossbach hat in einem munteren Vortrag einige Neuerungen aus dem “Docker Universum” zum Thema Orchestrierung vorgestellt. Unter anderem Docker Machine, Docker Swarm, Docker Compose (ehemals fig.sh, das wohl aufgrund von Aussprachemehrdeutigkeiten umbenannt wurde) etc. Ein sehr interessanter Überblick, insbesondere da Peter auch die ganzen Sachen immer mal angefasst und ausprobiert hat. Im Kern scheint es mir jedoch so zu sein, als wäre die Frage nach “Was nimmt man am besten, um Docker auf einer oder mehreren Maschinen im Produktivbetrieb zu nutzen?” noch recht in Bewegung. Für mich kristallisiert sich für meine Anwendungsfälle da bisher noch keine überzeugende Lösung heraus. Was ich jedoch einmal testen werde ist das fig.sh bzw. Docker Compose, da man damit eigentlich sehr schön in einem YAML-Dokument mehrere Container und ihre Abhängigkeiten darstellen kann.

Docker Linking

Erkan Yanar hat in einem Einsteigervortrag die Grundlagen von Links zwischen Containern vorgestellt. Hier scheint die Entwicklung auch noch in Bewegung zu sein, insbesondere Links über mehrere Hosts hinweg scheinen doch noch nicht so ganz einfach handzuhaben zu sein (vorgestellt wurden Ambassador-Ansätze mit socat und anderes).

Besonders erhellend fand ich den Hinweis, dass ab Docker Version 1.3 nun bei Links zwischen den Containern die /etc/hosts auch nach Neustarts von gelinkten Containern immer deren richtige IP-Adresse erhält, wohingegen die Umgebungsvariablen nur die Ursprungs-IP-Adressen enthalten (also ein klares “Verlasst Euch nicht auf die Umgebungsvariablen!”).

Netzwerken mit Docker

Andreas Schmidt stellte eine ganze Reihe von Varianten vor, mit denen man die Container im Netzwerk auf unterschiedliche Arten und Weisen verknoten kann. Soweit ganz interessant, aber nicht meine “Liga”, wo ich mich gut auskenne.

Fazit

Bei Docker in Bezug auf Orchestrierung und Container-Linken gibt es recht viel Bewegung und für mich kristallisieren sich die überzeugenden Konzepte noch nicht so richtig heraus, um damit in eine Produktivumgebung zu gehen. Im Bereich der Entwicklung und der Tests nutze ich die Container von Docker schon recht gerne, bei Produktiv-Umgebungen schreckt mich die Vielzahl an Werkzeugen und zum Teil auch die Komplexität doch noch etwas.

Jedenfalls wieder ein gutes Meetup mit Ideen und Anregungen. Ich finde das schon sehr außergewöhnlich (besonders wenn man es mit anderen Branchen vergleicht), dass sich Leute zum Austauschen über Technologie treffen, Vorträge vorbereiten etc.

Links zu den Folien

• Peter Rossbach, Docker Orchestation
• Andreas Schmidt, Docker Networking

Dieses Jahr habe ich mich einmal aufgerafft und bin das erste mal zum Congress des CCC nach Hamburg gefahren. Im Folgenden ein paar Eindrücke:

Bisher hatte ich meine Blog-Einträge auf zwei Blogs aufgeteilt, eines mit mehr technischen (und zum Teil englischen Texten) und dieses hier mit deutschen Texten. Ich denke, ich werde das auf dieses eine Blog hier konzentrieren. Das reduziert doch etwas den Verwaltungsaufwand. Ich habe die Texte vom nun etwas still gelegten Blog hier herüber kopiert.

Ein Bekannter bat mich, einmal von meinen Erfahrungen mit Docker zu berichten. Also hier als Blog-Post dazu. Ich werde nicht beschreiben, was genau Docker ist und wie es funktioniert. Hierzu gibt es mittlerweile schon eine Reihe von guten Quellen (bspw. auf der Docker-Homepage, in der c’t war in Heft 17 (Seiten 146–151) auch eine ganz gute Einführung enthalten).

A few days ago I wanted to build Firefox OS’ newest release for a friend. Because I did not wanted these GB of code, binaries etc. on my notebook I fired up an Ubuntu image on Microsoft Azure. I feared that at a certain point in the build process I may had to download everything to my local machine and therefore I installed Docker via a simple

sudo apt-get install docker.io

Then I started the build process as laid out on Mozilla’s Developer Network. But, during downloading the source code (that’s about 12 GB of Git repositories from Mozilla and Android), I got a “no more space left on device”. That was strange: I had a 100 GB volume attached to the VM and enough space and inodes left. After some searching I asked on the IRC channel and got a good hint: “What’s your storage driver?”

Well, I thought that it’s AUFS; I wanted to add “as usual” because AUFS was available on my notebook from the beginning. But a docker.io info gave me:

$ sudo docker.io info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-8:1-131188-pool
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 291.5 Mb
 Data Space Total: 102400.0 Mb
 Metadata Space Used: 0.7 Mb
 Metadata Space Total: 2048.0 Mb
Execution Driver: native-0.1
Kernel Version: 3.13.0-29-generic
WARNING: No swap limit support

I then learned that somehow the DeviceMapper driver only allows a certain amount of diffs and I reached that amount with my build process. (Maybe it’s possible to relax that restriction but I do not know how.)

I learned as well that the Ubuntu cloud image that is provided by Microsoft Azure doesn’t have AUFS support. Therefore Docker uses the DeviceMapper storage driver instead. After I installed the AUFS support I could export the images, change the storage driver and import the images again.

It would be nice seeing the Docker documentation being more detailed on those storage drivers.

(Update 2014–10–23) Thanks to this blog post from Iron.io I found some documentation of the devicemapper storage driver. It is located in the Repository.