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

Aus Civil Commons

Wechseln zu: Navigation, Suche
Zeile 168: Zeile 168:
  
 
<code>/etc/init.d/nginx restart</code>
 
<code>/etc/init.d/nginx restart</code>
 +
  
  
Zeile 177: Zeile 178:
  
 
===1.1===
 
===1.1===
- mit Postfix und Captcha<br />- zugreifbar über Reverse Proxy<br />- neues Data-Verzeichnis auf Data-Server<br />- auf Subdomains "share2", "publish2"
+
WordPress
 +
 
 +
===1.2===
 +
- mit Postfix in allen Images und Captcha<br />- zugreifbar über Reverse Proxy<br />- neues Data-Verzeichnis auf Data-Server<br />- auf Subdomains "share20", "publish20", "home20"
  
 
===2===
 
===2===
Zeile 183: Zeile 187:
  
 
===3===
 
===3===
WordPress
+
KnowAge (auf FIWARE) mit MRN-Daten explore
 
 
===3===
 
KnowAge mit MRN-Daten explore
 
  
 
===4===
 
===4===
OAuth2
+
OAuth2 (auf FIWARE)

Version vom 24. März 2019, 13:55 Uhr

docker lead.jpg


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 emoticon

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

...

sudo docker pull collabora/code

sudo docker run -t -d --network=host -p 127.0.0.1:9980:9980 -e 'domain=172\\.17\\.206\\.167' --restart always --cap-add MKNOD

collabora/code

sudo netstat -lnpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      705/systemd-resolve
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      908/sshd
tcp        0      0 127.0.0.1:9981          0.0.0.0:*               LISTEN      19752/loolwsd
tcp6       0      0 :::80                   :::*                    LISTEN      20306/apache2
tcp6       0      0 :::22                   :::*                    LISTEN      908/sshd
tcp6       0      0 :::9980                 :::*                    LISTEN      19752/loolwsd

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.

... emoticon 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 emoticon

Konfiguration von Mail-Versand aus Container

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

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 zur Verfügung, 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

NGINX Reverse Proxy

Gute Doku.

Installation von NGINX auf Ubuntu 18: Beschreibung


/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

WordPress

1.2

- mit Postfix in allen Images und Captcha
- zugreifbar über Reverse Proxy
- neues Data-Verzeichnis auf Data-Server
- auf Subdomains "share20", "publish20", "home20"

2

Collabora Office

3

KnowAge (auf FIWARE) mit MRN-Daten explore

4

OAuth2 (auf FIWARE)