Civil Commons:Roadmap 2020 - Docker Technologie: Unterschied zwischen den Versionen

Aktuelle Version vom 18. Juni 2019, 13:06 Uhr

Docker im Rahmen der Roadmap 2020

Im November/Dezember 2018 gab es mehrere intensive Gesprächsrunden zu der Frage, welches die nächsten Schritte auf dem Weg zur nächsten Generation unserer Infrastruktur im Rahmen der Roadmap 2020 sein sollen (Beteiligte waren u.a. Jaro Eiermann, Jasper Schmidt, Christian Mürner - "Begeisterhaus", Stephan Frenzel, Jürgen Wachtel - Kybeidos / Lernkonzept). Konkret ging es u.a. um die Frage, ob wir ein Labor mit eigener Hardware aufbauen - mit der Folge, dass wir uns dann zunächst mit Fragen der Virtualisierung hätten beschäftigen müssen - z.B. auf Basis von OpenStack (https://www.openstack.org/). Die Alternative dazu war es, von Anfang an eine Cloud-Plattform zu nutzen und direkt mit der Bereitstellung der geplanten Dienste (Wiki, File Sharing, ...) zu beginnen.

Zwei Argumente sprachen dafür, die zweite Option zu wählen:

1. Ein Labor auf Basis eigener Hardware warf die Frage auf, in welchen Räumen (mit welcher Netzanbindung, welchen Sicherheitsmaßnahmen, ...) die Server stehen sollten; wir hätten absehbar mehrere Wochen mit administrativen Prozessen verbracht.
2. Ein noch stärkeres Argument aber war: Beim Fachaustausch Geoinformation am 29.11.2018 hat die Digitalagentur Heidelberg gemeinsam mit NEC die Pläne vorgestellt, am Digital Hub kurpfalz@bw eine FIWARE-Infrastruktur verfügbar zu machen. Im Rahmen von FIWARE bieten die sg. FIWARE Labs die Möglichkeit, eine Server-Images bzw. Container zu hosten.

Ein eigenes Labor aufzubauen hätte bedeutet, an Themen zu arbeiten, die im Rahmen von FIWARE schon - u.a. durch NEC - überzeugend gelöst sind.

Wir haben uns daher dafür entschieden, direkt am Aufbau der geplanten Dienste zu arbeiten - und das bedeutete, damit zu beginnen, uns die Docker-Technologie zu erschließen. Docker ist aus unserer Sicht die Technologie der Wahl, wenn es darum geht, eine Plattformen bereitzustellen, die auf dem Konzept von (Micro)Services aufbauen - mit den einschlägigen Vorteilen hoher Granularität und Skalierbarkeit.

Eine konkrete Fähigkeit, die wir uns auf Basis der Docker-Technologie erschließen wollen, ist die kurzfristige Bereitstellung von Services wie Wikis, File-Sharing-Plattformen usw. für neue Zielgruppen, Initiativen, Organisationen.

Im Folgenden sammeln wir im Rahmen der Erschließung von Docker zunächst unsere Notizen - zu Docker generell und zur Bereitstellung von Services auf Basis von Docker. Diese Notizen sollen zu detaillierten Anleitung zur Installation und zum Betrieb der Docker-Infrastruktur und zur Bereitstellung der Services ausgearbeitet werden.

Ubuntu LTS with SSH

... im Folgenden eine Anleitung zur Erstellung eines Images, das ein Ubuntu Linux LTS mit SSH-Zugang bereitstellt - basierend auf:  https://github.com/art567/docker-ubuntu-sshd

Das zur Erstellung des Images genutzte Dockerfile:

# -----------------------------------------------------------------------------
# This is base image of Ubuntu LTS with SSHD service.
#
# ... basierend auf https://github.com/art567/docker-ubuntu-sshd 
# von Art567, Sep 20th, 2015 (https://github.com/art567/docker-ubuntu-sshd)
#
# Autor: Stephan Frenzel
# Datum: 28.12.2018
#
# Erfordert: Docker (http://www.docker.io/)
#
# Vor Erstellung des Images sollten unbedingt die Passwoerter der Benutzer 
# "root" und "master" geaendert werden - s.u. "passwdfile".
# -----------------------------------------------------------------------------

# Base system is the latest LTS version of Ubuntu.
from ubuntu

# Make sure we don't get notifications we can't answer during building.
env DEBIAN_FRONTEND = noninteractive

# Bereitstellung des Start-Scripts
# Bei Bearbeitung des Skripts unter Windows aufpassen, dass sich nicht CRLF einschleichen 
# (Unix erwartet nur LF); das Skript waere dann unter Unix nicht ausfuehrbar und der Container 
# wuerde nicht starten.
add ./start /start

# Download and install everything from the repos.
run apt-get -q -y update && \
    apt-get -q -y install apt-utils && \
    apt-get -q -y install openssh-server && \
    mkdir /var/run/sshd

# Falls im Rahmen von Tests Dateien bearbeitet werden sollen - der Editor "nano"
run apt-get -q -y install nano

# Passwort fuer "root" festlegen - vor Erstellung des Images aendern!
run echo 'root:secret' >> /root/passwdfile

# User "master" anlegen - mit "sudo"-Recht
run useradd -m -G sudo master

# Passwort fuer "master" festlegen - vor Erstellung des Images aendern!
run echo 'master:secret' >> /root/passwdfile

# Passwoerter fuer "root" und "master" setzen
run chpasswd -c SHA512 < /root/passwdfile && \
    rm /root/passwdfile

# Port 22 is used for ssh
expose 22

# Assign /data as static volume.
volume ["/data"]

# Executable-Flag des Start-Scripts setzen
run chmod +x /start

# Starting sshd - kann im Fall von Problemen im "docker run" ueberschrieben werden
cmd ["/start"]

# Stand 28.12.2018 ist dieses Dockerfile ueberarbeitet aber noch nicht wieder getestet -
# es koennen aber nur Kleinigkeiten sein 

Das in dem Dockerfile referenzierte Script "start":

#!/bin/bash
#
#------------------------------------------------------------
# ubuntussh /start script
# Authors: Art567
# Updated: Sep 20th, 2015
#------------------------------------------------------------
#
# Run OpenSSH server in daemon mode
/usr/sbin/sshd -D

Anweisung zur Erstellung des Images:

docker build -t ubuntussh

Erstellen und Ausfuehren des Containers auf Basis des Images:

docker run -p 2222:22 --name=ubuntussh1 --rm ubuntussh

Dieser Container ist zugänglich über den Port 2222 des Docker-Hosts - z.B. des zur Entwicklung genutzten Windows-Rechners. (Das ist nochmal zu testen - SF - habe letztlich mit der Variante "--network host" gearbeitet - s.u.)

Erstellen eines Containers und Aufruf mit Shell - z.B. bei Problemen mit dem "start"-Script:

docker run -it -p 2222:22 --name=ubuntussh1 --rm ubuntussh /bin/bash

SSH-Zugang zum Container mit den angelegten Usern nun z.B. mit:

- ssh root@ -p 2222
- ssh master@ -p 2222

Erstellen und Ausfuehren eines Containers mit einer IP-Adresse im externen Netzwerk des Docker-Hosts:

docker run --network host --hostname ubuntussh1 --name=ubuntussh1 --rm ubuntussh

... und Shell-Zugang zu diesem Container:

docker exec -it ubuntussh1 /bin/bash

Die vergebene IP-Adresse kann nun angezeigt werden durch:

hostname -I

Nun kann in gewohnter Weise auch über eine eigene Adresse und Port 22 auf den Container zugegriffen werden.

Hinweis: Der Erstellung dieses Images lag die Fragestellung zugrunde: Kann ich auf Basis von Docker ein "eigenständiges" Image erstellen? Es entspricht letztlich nicht dem Docker-Konzept, dass jeder (Mikro)Service seine eigene externe IP-Adresse bekommt und Shell-Zugriff bietet. Vielmehr sollten Services, die nicht extern zugreifbar sein sollen, im Netzwerk des Docker-Hosts isoliert werden.

FIWARE Keyrock

... hat Jürgen Wachtel Stand 1.4.2019 am Laufen ... Dokumentation ist hier zu ergänzen.

MySQL

Wir haben bei unseren Tests die Erfahrung gemacht, dass mehrere Container mit MySQL auf einem Docker-Host sich gerne ins Gehege kommen. Aus diesem Grund und weil's schlanker ist, werden wir einen Container mit MySQL bereitstellen, in dem dann alle Systeme, die eine Datenbank brauchen, ihre Daten ablegen.

Erwartungsgemäß ist die Bereitstellung eines MySQL-Containers denkbar einfach:

https://hub.docker.com/_/mysql

docker pull mysql
docker run --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:latest

Nextcloud

Nextcloud auf Docker Hub

Installation Nextcloud mit nginx-Reverse-Proxy

2019-03-17

Installation auf Ubuntu 18, das Hyper-V-virtualisiert unter Windows 10 läuft ... erstmal problemlos, aber:

Im Ergebnis habe ich eine Ubuntu mit der IP 172.17.206.173 und mit einer virtuellen Docker-Netzwerkkarte unter der IP 172.17.0.2.

172.17.206.173 ist vom Windows Host aus sichtbar, 172.17.0.2 aber (erwartunsgemäß) nicht.

Nach „sudo docker pull nextcloud” und "docker run -d -p 8080:80 nextcloud" kann ich auf dem Docker-Host ein „wget 172.17.0.2“ machen, auf Port 80 von 172.17.206.173 allerdings kommt nichts an.

Die Container bedienen also die virtuelle Netzwerkkarte von Docker aber nicht die nach außen sichtbare Netzwerkkarte des Docker-Hosts.

… „--network=host“ löst das Problem; ich dachte nur, das sei der Standard – das Docker die angegebenen Ports auf der IP-Adresse des Docker-Hosts bedient – statt die Container unter einer IP zu verstecken, die von außen nicht sichtbar ist – naja, kann sein, das ist eine Voreinstellung, die der Sicherheit dient.

Bleibt nur die Frage: Ist mein Verständnis richtig, dass ich das auch durch einen Reverse-Proxy lösen kann?

Jürgen:

Brigde! Du musst ein eigenen virtuellen Netzwerkadapter erstellen, den als publik definieren und die VM auf diesen virtuellen Netzwerkadapter Konfigurieren.

Collabora

Blog-Beitrag mit Installationsanleitung

noch ein (sehr ausführlicher) Blog-Beitrag mit Installationsanleitung

...

Bluespice Mediawiki

https://hub.docker.com/_/mediawiki

https://hub.docker.com/r/knsit/bluespice

Installationsanleitung Bluespice 3

Setup:Portal

Bluespice Download

Lösungsansatz

Für Bluespice gibt es kein "offizielles" Docker Image und keine wirklich überzeugende Installationsanleitung. Es sollte aber möglich sein, von dem Docker Image von MediaWiki ein Bluespice Docker Image abzuleiten - einfach indem man das MediaWiki-Archiv gegen ein Bluespice-Archiv austausch.

Also versuchen wir erstmal, das Docker Image von Mediawiki zu installieren.

2019-03-18

sudo docker pull mediawiki

sudo docker run --name mediawiki-1-31 --network=host -p 8080:80 -d mediawiki

   > WARNING: Published ports are discarded when using host network mode
   ... hmm - das Thema mit dem Netzwerk, s.o.; für den Moment ignorieren wir das.

... Mediawiki ist im Browser aufrufbar und der Installationsdialog läuft fehlerfrei durch; am Ende des Installationsdialogs wird die "LocalSettings.php" erstellt und muss nur noch in den Container hochgeladen werden.

Schau'n wir uns den Container erstmal an:

sudo docker exec -i -t <container/b883b28be5a8> bash

... und laden dann die LocalSetting.php hoch:

sudo docker cp /home/ccom/LocalSettings.php <container/b883b28be5a8>:/var/www/html/LocalSettings.php

... läuft

2019-04-06

Für die Installation von Bluespice 3 sind anstelle der entsprechenden Anweisungen bzgl. MediaWiki die folgenden Anweisungen in das Dockerfile aufzunehmen:

# Install zip and unzip
RUN apt-get update && apt-get install zip unzip

ENV BLUESPICE_ZIP_FILE BlueSpice-free-3.0.1.zip

#RUN mkdir /var/www/html
ADD ${BLUESPICE_ZIP_FILE} /var/www/html/${BLUESPICE_ZIP_FILE}

RUN unzip /var/www/html/${BLUESPICE_ZIP_FILE} "bluespice/*" -d /var/www/html \
    && mv /var/www/html/bluespice/* /var/www/html \
    && rm -r /var/www/html/bluespice \
    && chown -R www-data:www-data /var/www/html/extensions /var/www/html/skins /var/www/html/cache /var/www/html/images \
    && rm /var/www/html/${BLUESPICE_ZIP_FILE}

Neben dem Dockerfile ist das Zip-Archiv mit Bluespice bereitzustellen.

... Erstellen des Images:

sudo docker build --tag bluespice .

... Erstellen des Containers:

sudo docker run --name bluespice -p 8080:80 -d mediawiki-20190406

... Command line des laufenden Containers:

sudo docker exec -i -t  bash

... dann antwortet auf Port 8080 des Dockerhosts Bluespice mit dem Installationsdialog.

Bluespice bietet im Installationsdialog nicht die Verwendung einer "integrierten" Datenbank (SQLite o.ä.) an. Es muss für Bluespice also eine MySQL/MariaDB bereitgestellt werden.

Konfiguration von Mail-Versand aus Container

... z.B. über einen Office365-Account:

Hier ist eine angemessen einfache Lösung wohl die Verwendung der Utility sSMTP:

https://www.kuerbis.org/2018/05/mailversand-mit-php-aus-einem-docker-container/

http://linuxpitstop.com/install-ssmtp-to-send-emails-to-gmail-and-office3655/

https://docs.j7k6.org/ssmtp-office-365/

... eine besonders gute Beschreibung - Installation Ubuntu unter Hyper-V und Installation, Text sSMTP:

https://decatec.de/home-server/linux-einfach-e-mails-senden-mit-ssmtp/

... und hier ein Beispiel (bzgl. WordPress), wie sSMTP im Dockerfile installiert wird:

https://github.com/xgodon/RIG/blob/master/dockerized-apps/wordpress/Dockerfile

... erfolgreich getestet (Ubuntu unter Hyper-V, noch außerhalb Docker)

sudo nano /etc/ssmtp/ssmtp.conf

 #
 # Config file for sSMTP sendmail  #
 # The person who gets all mail for userids < 1000
 # Make this empty to disable rewriting.
 root=info@civilcommons.eu

 # The place where the mail goes. The actual machine name is required no
 # MX records are consulted. Commonly mailhosts are named mail.domain.com
 mailhub=smtp.office365.com:587

 # Where will the mail seem to come from?
 rewriteDomain=civilcommons.eu

 # The full hostname
 #hostname=info@civilcommons.eu
 hostname=192.168.137.40

 # Are users allowed to set their own From: address?
 # YES - Allow the user to specify their own From: address
 # NO - Use the system generated From: address
 FromLineOverride=YES

 AuthUser=info@civilcommons.eu
 AuthPass=********
 UseTLS=YES
 UseSTARTTLS=YES

sudo nano /etc/ssmtp/revaliases

 # sSMTP aliases
 #
 # Format:       local_account:outgoing_address:mailhub
 #
 # Example: root:your_login@your.domain:mailhub.your.domain[:port]
 # where [:port] is an optional port number that defaults to 25.
 root:info@civilcommons.eu:smtp.office365.com:587
 ccom:info@civilcommons.eu:smtp.office365.com:587

echo -n 'Subject: test\n\nTesting ssmtp' | sendmail -v sfrenzel@kybeidos.de

 [<-] 220 DB7PR04CA0019.outlook.office365.com Microsoft ESMTP MAIL Service ready at Sun, 24 Mar 2019 19:35:17
   +0000
 [->] EHLO 192.168.137.40
 [<-] 250 SMTPUTF8
 [->] STARTTLS
 [<-] 220 2.0.0 SMTP server ready
 [->] EHLO 192.168.137.40
 [<-] 250 SMTPUTF8
 [->] AUTH LOGIN
 [<-] 334 VXNlcm5hbWU6
 [->] aW5mb0BjaXZpbGNvbW1vbnMuZXU=
 [<-] 334 UGFzc3dvcmQ6
 [<-] 235 2.7.0 Authentication successful
 [->] MAIL FROM:<info@civilcommons.eu>
 [<-] 250 2.1.0 Sender OK
 [->] RCPT TO:<sfrenzel@kybeidos.de>
 [<-] 250 2.1.5 Recipient OK
 [->] DATA
 [<-] 354 Start mail input; end with .
 [->] Received: by 192.168.137.40 (sSMTP sendmail emulation); Sun, 24 Mar 2019 19:35:18 +0000
 [->] From: "Civil Commons" <info@civilcommons.eu>
 [->] Date: Sun, 24 Mar 2019 19:35:18 +0000
 [->]
 [->] .
 [<-] 250 2.0.0 OK <DB6PR07MB34805AC3E5BCE181980C278BCD5D0@DB6PR07MB3480.eurprd07.prod.outlook.com> 
   [Hostname=DB6PR07MB3480.eurprd07.prod.outlook.com]
 [->] QUIT
 [<-] 221 2.0.0 Service closing transmission channel

Docker-Entwicklungsumgebung unter Windows

Auch unter Windows sollte man einen virtualisierten Linux-Server als Docker-Host aufsetzen.

Das minimale Linux, das mit Docker-für-Windows installiert wird, ist definitiv nicht zu empfehlen.

Als Umgebung zur Bereitstellung virtueller Maschinen steht in Windows 10 Hyper-V zur Verfügung.

Auf unserer Nextcloud steht unter "https://share.civilcommons.eu/remote.php/webdav/Urban%20Data%20Space%20-%20Projekt/Digital%20Service%20Package/Development/Building%20Development%20Environment/HowTo_InstallLocalUbuntu_WIN10HYPERV_V02.txt" eine gute Anleitung, wie ein Linux-Server mit eigenem Netzwerk-Switch und statischer IP-Adresse aufgesetzt werden kann.

Falls bei der Installation noch keine statische IP angegeben wurde - der folgende Link beschreibt, wie's im Nachhinein konfiguriert werden kann:

Ubuntu 18 Static IP

s.a. https://decatec.de/home-server/ubuntu-server-als-hyper-v-gastsystem-installieren-und-optimal-einrichten/

NGINX Reverse Proxy

Hier eine sehr gute und knappe Doku. wie NGINX als Reverse-Proxy aufgesetzt wird.

Installation von NGINX auf Ubuntu 18: Beschreibung

Nach Anpassung der Konfiguration ...

/etc/init.d/nginx restart

Migration

1

MySQL, Nextcloud (ohne Collabora Office) und Bluespice 3 (mit Extensions) auf Docker

- noch ohne Übernahme von Content

1.1

Prüfung, ob WordPress mit UserPro-Plugin unproblematisch zu installieren ist

1.2

- mit Mailversand (sSMTP) in allen Images und Captcha in MediaWiki
- zugreifbar über Reverse Proxy
- neues Data-Verzeichnis von Nextcloud auf Data-Server
- auf Subdomains "share20", "publish20", "home20"

1.3

- ab hier alte Server "Read-only"
- Übernahme von Content auf neue Server (Move von Nextcloud-Verzeichnissen, Export/Import von MediaWiki-Content)

2

Collabora Office

3

KnowAge (auf FIWARE) mit MRN-Daten explore

4

Authentifizierung über OAuth2 - wobei idealerweise der OAuth2-Server ein Keyrock auf FIWARE ist.