Docker Volume Mappings

Als Vorbereitung auf einen Beitrag zum Thema Persistent Storage mit dem entsprechenden Netapp-Plugin möchte ich noch kurz darauf eingehen, wie man mit Bordmitteln ein persistentes Storage für einen Container bereitstellen kann.

Braucht man ein persistentes Storage oder nur ein Shared Storage für eine Applikation, welche in einem Docker Container läuft, kommt man fast nicht an Volume Mappings vorbei.

Mit Vollume Mappings kann man auf einem einfache Wege lokale Filesystem-Ressourcen in einem Container verfügbar machen.

Das Volume Mapping ist ähnlich anzuwenden wie das Device Mapping aus meinem letzten Artikel. Man muss lediglich beim startendes Containers die folgende Option mitgeben.

-v /lokales/verzeichnis/:/container/verzeichnis

Wie der Name Volume-Mapping schon verrät, mappt diese Option einfach das Verzeichnis vom Docker-Host in das Zielverzeichnis im Container.

Ein komplettes Kommando könnte so aussehen:

docker run -d -v /mnt/data01/www:/www nginx

„/mnt/data01/www“ könnte zB. eine gemountete LUN oder so sein. Der Ordner „www“ wird direkt als „/www“ im Container präsentiert, wo die Applikation dann entsprechend zugreifen kann.

Sichern sollte man das Verzeichnis am Docker-Host selbst.

Bis demnächst.

 

Liebe Grüße

Falk

Docker Device Mappings

Ich tauche im Moment ins letzte Jahrtausend ab und automatisiere Abläufe, welche nicht über IP Kommunikation abbildbar sind. 🙂

Der erste Pilot dafür lief auf einem Raspberry Pi:


Darauf lief ein Expect-Script, welches sich an der Minicom bediente und automatisch gewisse Sachen ausführte.

Jetzt wollten wir das Ganze auf einen Server bringen und das Ganze funktionierte nicht mehr wie vorher. Nach einiger Recherche kamen wir dahinter, dass am Raspberry eine aktuellere Version der Minicom installiert war.

Am Server läuft CentOs und irgendwie war ich unfähig, die Minicom auf das gleiche Release wie am Pi zu bringen. 🙁

Ich dachte kurz an Docker und schaute, ob man nicht die ttyUSB0 in den Container bringen kann. Ergebnis: ja, man kann. Und es ist einfacher als gedacht:

docker run --device=/dev/ttyUSB0 *Imagename*

Nachher taucht im Container die ttyUSB0 auf. Eigentlich nicht kompliziert, oder?

root@faadd9042d8b:/# ll /dev/tty*
crw-rw-rw- 1 root root   5, 0 Feb 20 08:20 /dev/tty
crw-rw---- 1 root   18 188, 0 Feb 20 08:41 /dev/ttyUSB0

Also schnell ein Ubuntu Image gestartet, die Minicom und Expect entsprechend installiert und schon lief es wieder.

Vielleicht ist es ja für jemanden nützlich …

Nachtrag:
Man kann auch die ttyUSB1 auf ttyUSB0 mappen.

--device=/dev/ttyUSB1:/dev/ttyUSB0

Dh. die ttyUSB1 vom Docker-Host wird im Container als ttyUSB0 nutzbar.

Liebe Grüße

Falk

IT Konferenzen 2017

Ich habe jetzt einmal die Liste der Konferenzen auf 2017 aktualisiert.

Hier also wieder die Liste vom letzten Jahr (Sortierung wertfrei :-))

IT Konferenzen 2017 weiterlesen

Ein eigenes Docker Container-Repository

Der erste Container läuft. Wunderbar.

Was funktioniert gleich so super mit Containern? Scale-Out? Unsere Clouddays werden gut besucht und unsere CloudDaysWebApp könnte mehr Ressourcen vertragen. Docker Hosts hätten wir zu genüge, nur wie bringen wie unseren Container dorthin?

Wir müssten irgendwie unseren Container ins „Docker Hub“ bringen. Nein besser, wir bräuchten ein eigenes Repository, ähnlich wie „Docker Hub“. Da wir nicht die ersten sind, die genau sowas brauchen, gibt es das schon. 🙂 Es nennt sich „Registry“ und (wie sollte es anders sein?) kommt als fertiger Container aus dem Docker Hub (Link hier).

Das Prinzip ist folgendes: Wir „pushen“ unsere Container ins Repository und können sie nachher von diversen anderen Hosts „pullen“.

Unser Setup sieht wie folgt aus:

Docker-Registry

Die Kommunikation zwischen den Docker-Hosts und der Docker-Registry ist mittels TLS gesichert. Damit das möglich ist, benötigen wir SSL-Zertifikate. Für unseren kleinen internen Testaufbau sind selbstausgestellte völlig ausreichend. Die Zertifikate werden wir mit Volume-Mappings in den Container bringen. Dafür legen wir zunächst einen Ordner an:

mkdir –p /docker_volumes/registry/certs
cd /docker_volumes/registry/certs

Hier generieren wir jetzt unsere Zertifikate. Mit dem folgenden Befehl kann man eigene Zertifikate erstellen. Wichtig ist dabei der „common name“. Hier muss unser Servername eingetragen werden. In unserem Fall „didata„.

openssl req -new -newkey rsa:2048 -sha256 -nodes -x509 -keyout docker_registry.key -out docker_registry.crt

Generating a 2048 bit RSA private key
   ............................................................................................+++
.....................+++
writing new private key to 'docker_registry.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:AT
State or Province Name (full name) []:Tyrol
Locality Name (eg, city) [Default City]:Innsbruck
Organization Name (eg, company) [Default Company Ltd]:DiData
Organizational Unit Name (eg, section) []:Operations
Common Name (eg, your name or your server's hostname) []:didata
Email Address []:my.name@company.org

Jetzt können wir unseren Registry-Container holen. Dabei mappen wir Port 5000 gerade durch und reichen das Verzeichnis /docker_volumes/registry/certs als /certs in den Container durch.

docker run -d -p 5000:5000 --restart=always --name registry -v /docker_volumes/registry/certs/:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/docker_registry.crt -e REGISTRY_HTTP_TLS_KEY=/certs/docker_registry.key registry:2

Da wir self-signed Zertifikate verwenden, müssen wir allen beteiligten Hosts mitteilen, dass die von uns erstellten Zertifikate vertrauenswürdig sind. Hierfür muss zunächst der folgende Ordner angelegt werden:

/etc/docker/certs.d/*repo-dns-name*:5000

In unserem Fall folgender:

mkdir -p /etc/docker/certs.d/didata:5000

Hier legen wir jetzt das CRT-File ab und nennen es „ca.crt“, also:

cp /docker_volumes/registry/certs/ docker_registry.crt /etc/docker/certs.d/didata:5000/ca.crt

Da wir in unserem konkreten Fall auch keinen DNS-Server haben, behelfen wir uns noch mit einem /etc/hosts-Eintrag:

echo "192.168.1.100  didata" >> /etc/hosts

Wenn jetzt unser Container läuft (docker ps), können wir einen ersten Test starten.

Wir taggen unseren CloudDaysWebApp-Container entsprechend um. Dafür suchen wir zunächst die Image-ID unseres Containers:

[root@Docker-Host01 CloudDays]# docker images
REPOSITORY                   TAG                 IMAGE ID           CREATED             VIRTUAL SIZE
clouddayswebapp               latest             03d3c462af38       16 seconds ago     133.9 MB
…
nginx                         latest             407195ab8b07       5 weeks ago         133.8 MB

Und setzen den folgenden Tag:

Docker tag –t *Image-ID* *Repo-DNS-Name*:5000/*Containername*

Also in unserem Beispiel:

docker tag –t 03d3c462af38 didata:5000/clouddays

Mit “docker push” können wir jetzt unseren Container in unser Repository hochladen. In unserem Beispiel lautet der Befehl:

docker push didata:5000/clouddays

Wenn das erfolgreich angeschlossen wurde, kann auf jedem anderen Docker-Host der Container gestartet werden, wenn denn folgende Kriterien erfüllt sind:

  • Das SSL-Zertifikat ist vertrauenswürdig
  • Die Namensauflösung funktioniert
  • Docker ist installiert

Damit das alles auf Anhieb funktioniert, habe ich ein prepare-host.sh erstellt:

### Add Docker-Repo to YUM:
cat >/etc/yum.repos.d/docker.repo <<-EOF
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

### Install Docker:
yum -y install docker-engine

### Enable Docker:
systemctl enable docker.service

### Docker-Registry Config:
###### 1. Create Folder
###### 2. Place Cert for Registry Service
###### 3. Reload Docker
###### 4. Set Host-Entry "didata" (registry-service)
mkdir -p /etc/docker/certs.d/didata:5000

cat > /etc/docker/certs.d/didata:5000/ca.crt <<-EOF

-----BEGIN CERTIFICATE-----
<Bitte Zertifikat einfügen.> :-)
-----END CERTIFICATE-----
EOF

systemctl restart docker

echo "192.168.1.100  didata" >> /etc/hosts

Damit ist alles Relevante installiert und konfiguriert. Nachdem ich gestern jedoch schon entsprechend darauf angesprochen wurde … Mit Puppet oder Chef geht das natürlich auch ganz wunderbar. Dazu vielleicht mal zu einem späteren Zeitpunkt mehr. 🙂

Sind alle Voraussetzungen erfüllt, können wir auf unseren Docker-Hosts den Container pullen und starten. Tatsächlich braucht es das pull nicht als eigenen Schritt. Wir können direkt docker run verwenden. In unserem Beispiel:

docker run -d -p 80:80 –-name CloudDays didata:5000/clouddays

Wenn alles richtig konfiguriert wurde, wird der Container jetzt laufen. Kontrolle wie immer mit „docker ps“.

Macht man das jetzt in der Cloud und aktiviert einen Load-Balancer, hat man eine 1A Lastverteilung ohne großen Aufwand.

 

Wir haben jetzt also einen Container und ein Repository. Den Container können wir in diesem Setup beliebig oft auf beliebig vielen Hosts deployen. Der nächste Artikel wird auf die angekündigte BaaS-Demo eingehen. 🙂

Eine kleine Webapplikation im Docker-Container

Wir beginnen diesmal mit einer kleinen Vorgeschichte:

Für unsere „Cloud Days“ bereiteten wir eine kleine Demo für unsere BaaS-Infrastruktur vor. Der einfachste Weg wäre hier einen Webserver zu deployen und eine kleine Website wiederherzustellen. Da das Ganze aber irgendwie so „2005“ ist, haben wir uns dagegen entschieden. 🙂

„Wollen wir nicht eine ganze Applikation in Form eines Containers wiederherstellen?“.

„Oh. Das klingt super“.

Vorgeschichte Ende – Also los…

Eine kleine Webapplikation im Docker-Container weiterlesen

IT Konferenzen 2016, eine Übersicht.

Das Jahr ist noch jung. Zeit sich mit den IT Konferenzen des Jahres zu beschäftigen.

Ich habe lange überlegt, welchen Banner ich hier verwende. Schlussendlich habe ich mich für den „#Operations„-Banner entschieden. Denn gerade Leute welche in diesem Bereich tätig sind, nehmen wahrscheinlich am meisten von solchen Veranstaltugen mit. Die letzten zwei Jahre durfte ich die EMEA VMworld besuchen und kam immer voller Ideen wieder zurück. Ähnlich ging es auch meinen Kollegen mit der Netapp Insight.

Hier also eine kleine Auswahl (ohne Sortierung) …

IT Konferenzen 2016, eine Übersicht. weiterlesen

Docker Container automatisch starten.

Hier noch ein kleiner Artikel über Containering. Aber dieses Thema macht den vorherigen Beitrag erst komplett. 🙂

Docker Container werden per Default nicht automatisch bei einem Reboot gestartet.

Möchten wir unseren WordPress-Container automatisch mit dem System-Boot starten, kann man dies mit dem Process Manager „systemd“ bewerkstelligen. Ich habe ehrlich gesagt einige Zeit gebraucht um das Ding zu konfigurieren, aber schlussendlich hat es funktioniert.

Docker Container automatisch starten. weiterlesen

Auf Tuchfühlung mit Docker.

Seit der Ankündigung von PhotonOS, auf der VMworld 2015, bin ich im Docker-Fieber.

Gut das wir aktuell ein Hosting für diesen Blog brauchten und so bot es sich an, mal auf Tuchfühlung mit Docker zu gehen. Heute kann ich (auch ein wenig stolz) verkünden, dass dieser WordPress-Blog in einem Container läuft. Ich möchte hier meine ersten Erfahrungen damit beschreiben.

Was ist Docker und welche „Probleme“ adressiert es eigentlich?

Auf Tuchfühlung mit Docker. weiterlesen