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