Gestern, der 2018-03-17, wurde Gajim 1.0 veröffentlicht. Diese Version befand sich 5 Jahre in der Entwicklung und das Hauptaugenmerk war der Wechsel von Python 2 auf 3 und GTK 2 auf 3. Vom Äußerlichen hat sich nicht sooo viel geändert, aber ich hoffe mal das hier als nächstes die Hand angelegt wird, denn schön ist Gajim immer noch nicht so richtig. Aber es ist der beste und wichtigeste XMPP-Client, den es zur Zeit auf dem Desktop-Markt gibt. Eine Entscheidung, die ich als wichtig und gut empfinde, ist, dass das OTR-Plugin nicht portiert wurde und stattdessen der Fokus auf OMEMO gelegt wurde.

Ich wünsche dem Gajim-Projekt viel Erfolg auf ihrem Weg zu einem der besten XMPP-Clients, die es da draußen gibt.

Ein guter Freund von mir berichtete, dass er seit einem Docker-Update einen PostgreSQL-Container nicht mehr starten konnte, ihn deshalb löschen musste und dann seine Daten verloren gingen. Datenverlust ist nie lustig und aus diesem Grund will ich dem geneigten Leser einige Erfahrungen mit auf den Weg geben, die ich in den letzten anderthalb Jahren bei meinem Arbeitgeber sammeln konnte.

Container sind zustandslos und unveränderbar

Was heißt „zustandslos“?

Zwar verhält es sich nicht immer so, dass Container zustandslos und unveränderbar sind, aber man sollte sie dennoch so betrachten. Damit wird dann die Frage aufgeworfen, wenn der Zustand der Anwendung nicht im Container gespeichert wird, wo wird er dann gespeichert? Das Handbuch gibt hier zwei Möglichkeiten vor:

• Volumes
• Bind-mount

docker volumes

Volumes sind laut Dokumentation der präferierte Weg den Zustand eines Containers zu persistieren. Meine persönliche Erfahrung ist eine andere. Ich benutze lieber bind mounts, da hier keine Verwaltung von nöten ist. Volumes kann ich auch wesentlich einfacher aus Versehen löschen, ein Ordner im Dateisystem erfordert mehr Aufwand.

bind mounts

Mittels eines „bind mounts“ kann ich auf einem Linux-System einen Ordner auf einen anderen Ordner zeigen lassen, so dass beide über den selben Inhalt verfügen. So kann ein Ordner auf dem Hostsystem und in dem Docker-Container den selben Inhalt besitzen. Dadurch wird der Zustand des Containers außerhalb des Containers gespeichert und man kann ihn mit seinen regulären Werkzeugen sichern und beobachten.

Was heißt „unveränderbar“?

Nachdem ich nun den Zustand der Datenbank außerhalb des Containers speichere, gilt es die zweite Eigenschaft „unveränderbar“ (engl immuteable) zu betrachten. Es ist zwar möglich einen Container zu bearbeiten, aber spätestens wenn man diesen Container löscht oder einen zweiten anlegt, wird sich das rächen, da die Änderung weg ist. Willst du wirklich eine Änderung an einem Container vornehmen, empfiehlt es sich, das dem Container zugrunde liegende Abbild zu modifizieren und in ein eigenes abzuspeichern.

Aber ich kann doch nicht den Container löschen

Was mich am meisten verdutzt an der Aussage des Freundes war, dass das Löschen eines Containers so ein großer Akt ist. Auf Arbeit mache ich das ständig. Das liegt primär daran, dass wir mit docker-compose arbeiten und dies selbst für jeden kleinsten Dienst. Das Arbeiten mit compose hat den großen Vorteil, dass die Konfiguration der Docker Container in einer YAML-Konfigurationsdatei gespeichert ist und diese Datei über GIT versioniert ist.

Einen Dienst mit docker-compose einrichten

Privat benutze ich für ein Projekt odoo und verwende docker-compose für die Konfiguration der Anwendung. Hier meine komplette docker-compose.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

version: '2'
services:
  web:
    image: odoo:10.0
    depends_on:
      - db
    volumes:
      - ./data:/var/lib/odoo
      - ./config:/etc/odoo
      - ./addons:/mnt/extra-addons
    ports:
      - "127.0.0.1:18069:8069"
    environment:
      - HOST=db
      - USER=odoo
      - PASSWORD=somethingrandom
  db:
    image: postgres:9.6
    volumes:
        - ./postgres:/usr/local/var/lib/postgresql
    environment:
        - "PGDATA=/usr/local/var/lib/postgresql"
        - "POSTGRES_PASSWORD=somethingrandom"
        - "POSTGRES_USER=odoo"

Ich habe hier 2 Container definiert. Einmal den Container web für die Anwendung an sich, in diesem Fall habe ich mit image: odoo:10.0 ein Image aus dem Hub angegeben. Man könnte aber auch ein Dockerfile angeben, dann würde docker-compose zuerst das image bauen. Als nächstes habe ich mit depends_on definiert, dass der Container web von dem Container db abhängig ist. Das bedeuted auch, dass zuerst db gestartet wird und dann web. Ob die PostgreSQL-Datenbank so schnell hoch fährt, dass sie bereit ist, wenn die Anwendung sie benötigt ist unter Umständen nicht gegeben, kann also je nach Anwendungen zu Problemen führen und sollte im im Hinterkopf behalten werden. Im Fall von Odoo ist das allerdings kein Problem. Die Abhängigkeit bietet auch den Vorteil das compose einen Eintrag in der Datei /etc/hosts vornimmt, so dass man den Datenbank-Container mit seinem Namen referenzieren kann. Mit dem Eintrag volumes spezifiziere ich 3 bind mounts, die von dem lokalen Dateisystem in das Container Dateisystem zeigen. Über das Schlüsselwort ports kann ich Port-Weiterleitungen von dem Host-System in dem Container erstellen. Dabei sollte man beachten, dass man Ports immer lokal bindet und nicht auf allen Geräten zur Verfügung stellt. Über environment kann man zusätzliche Umgebungsvariablen in den Container reinreichen. Bei dem PostgreSQL-Image gibt es z.B. einige Variablen, mit denen man das Image konfigurieren kann.

Man startet die Komposition mit dem Befehl up:

1

$ docker-compose up

Wenn das System ordentlich hochfährt, kann man es mit STRG+C beenden und dann mit dem parameter -d starten, damit es im Hintergrund verschwindet:

1

$ docker-compose up -d

Will man die Dienste runterfahren, gibt es den Befehl down:

1

$ docker-compose down

Dabei werden sogar etwaige Container schon gelöscht. Aber da der komplette Zustand der beiden Container außerhalb im aktuellen Verzeichnis des Host-Systems gespeichert wird, ist das alles kein Problem.

Fazit

Alles in allem hoffe ich, dass ich darlegen konnte, wieso Container zustandslos (stateless) und unveränderbar (immuteable) sein sollen. Zusätzlich sollte man sich immer bei Docker überlegen, wo sich die Daten befinden. Es ist nämlich schnell und sehr leicht passiert, dass die Daten im Container sind, weil man sich das Image nicht genau angesehen hat oder sich auch einfach nicht überlegt hat, wo die Daten sein könnten.

In der letzten 2 Wochen gefühlt konstant in Dauerschleife.

Heute habe ich mir die Live Action Fassung von „Ghost in the Shell“ angesehen. Die Kurzzusammenfassung: Nettes Popcorn-Kino, aber bleibt weit hinter den Erwartungen zurück.

Die Handlung des Films ist generisches Science Fiction und bietet nicht die Tiefe, die ich von einem GITS-Franchise-Produkt gewohnt bin. Gerade die animierten Filme und Serien aus Japan bieten wesentlich mehr Tiefgang und sprechen auch die wichtigen Cyberpunk-Fragen an, I’m looking at you Solid Sate Society.

Die Charakter des Films sind nur ein Abklatsch dessen, was sie in dem Animé-Universum darstellen. Dazu muss ich allerdings etwas ausholen: „Public Security Section 9“ ist eine geheime Abteilung aus Spezialisten, die sich um die Abwehr von Gefahren aus dem „Cyberspace“ kümmert. Mein Punkt ist, dass alle Charaktere sehr viel Erfahrung haben mit dem was sie tun und das kommt im Animé auch so rüber. Im Film hingegen wissen die Charaktere zwar wie man mit Waffen umgeht, aber es wird nicht der Eindruck erweckt, dass es sich um gestandene Kriegs-Veteranen handelt. Den größten Beef habe ich mit dem Major, der nur eine leere Hülle seiner selbst ist. Im Quellmaterial ist der Major ein „Major Badass“, im Film hingegen wirkt sie eher schwach und verletzlich.

Auch wenn die Bilder sehr in das Universum passen, so wurden die besten Bilder aus dem Animé hier wiederverwendet in die Bildsprache des Films umgewandelt, was nicht sonderlich kreativ ist.

Mein Fazit: Mehr Sektion 9, weniger persönliche Geschichte, denn die ist im Quellmaterial auch nicht die größte Stärke. Auch wäre mehr Mut zur Kreativität besser gewesen, anstatt alle guten Szenen aus dem Animé einfach zu kopieren, das Franchise hätte das geboten. Ich kann nur Empfehlen, sich den ersten Film anzusehen, auch wenn die Veröffentlichung inzwischen 23 Jahre her ist, ist er keinen deut alt geworden. Das Thema ist immer noch hoch aktuell und zeigt wie visionär er gewesen ist.