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

Version vom 18. März 2019, 21:53 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

((Jürgen Wachtel ist dran - 2.3.2019))

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” 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 Installationsbeschreibung

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

Konfiguration von Mail-Versand aus Container

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