Änderungen

Aus Civil Commons

Wechseln zu: Navigation, Suche

Civil Commons:Roadmap 2020 - Docker Technologie

65 Byte hinzugefügt, 18:30, 28. Dez. 2018
keine Bearbeitungszusammenfassung
[[Datei:docker_lead.jpg|260x146px]]
 
__TOC__
 
==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/ 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.
Das zur Erstellung des Images genutzte Dockerfile:
# -----------------------------------------------------------------------------<br># This is base image of Ubuntu LTS with SSHD service.<br>#<br># ... basierend auf https://github.com/art567/docker-ubuntu-sshd <br># von Art567, Sep 20th, 2015 (https://github.com/art567/docker-ubuntu-sshd)<br>#<br># Autor: Stephan Frenzel<br># Datum: 28.12.2018<br>#<br># Erfordert: Docker (http://www.docker.io/)<br>#<br># Vor Erstellung des Images sollten unbedingt die Passwoerter der Benutzer <br># "root" und "master" geaendert werden - s.u. "passwdfile".<br># -----------------------------------------------------------------------------<br><br>$ # Base system is the latest LTS version of Ubuntu.<br>from ubuntu<br><br>$ # Make sure we don't get notifications we can't answer during building. env DEBIAN_FRONTEND = noninteractive<br><br>$ # Bereitstellung des Start-Scripts<br>$ # Bei Bearbeitung des Skripts unter Windows aufpassen, dass sich nicht CRLF einschleichen <br># (Unix erwartet nur LF);<br>$ das Skript waere dann unter Unix nicht ausfuehrbar und der Container <br># wuerde nicht starten.<br>add ./start /start<br><br>$ # Download and install everything from the repos.<br>run apt-get -q -y update && \<br> apt-get -q -y install apt-utils && \<br> apt-get -q -y install openssh-server && \<br> mkdir /var/run/sshd<br><br>$ # Falls im Rahmen von Tests Dateien bearbeitet werden sollen - der Editor "nano"<br>run apt-get -q -y install nano<br><br>$ # Passwort fuer "root" festlegen - vor Erstellung des Images aendern!<br>run echo 'root:secret' >> /root/passwdfile<br><br>$ # User "master" anlegen - mit "sudo"-Recht<br>run useradd -m -G sudo master<br><br>$ # Passwort fuer "master" festlegen - vor Erstellung des Images aendern!<br>run echo 'master:secret' >> /root/passwdfile<br><br>$ # Passwoerter fuer "root" und "master" setzen<br>run chpasswd -c SHA512 < /root/passwdfile && \<br> rm /root/passwdfile<br><br>$ # Port 22 is used for ssh<br>expose 22<br><br>$ # Assign /data as static volume.<br>volume ["/data"]<br><br>$ # Executable-Flag des Start-Scripts setzen<br>run chmod +x /start<br><br>$ # Starting sshd - kann im Fall von Problemen im "docker run" ueberschrieben werden<br>cmd ["/start"]<br><br>$ # Stand 28.12.2018 ist dieses Dockerfile ueberarbeitet aber noch nicht wieder getestet -<br>$ # es koennen aber nur Kleinigkeiten sein ;-)  
Das in dem Dockerfile referenzierte Script "start":
#!/bin/bash<br>#<br>#------------------------------------------------------------<br># ubuntussh /start script<br># Authors: Art567<br># Updated: Sep 20th, 2015<br>#------------------------------------------------------------<br>#<br># Run OpenSSH server in daemon mode<br>/usr/sbin/sshd -D
<br />Anweisung zur Erstellung des Images:
 # !/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 -it -p 2222:22 --name=ubuntussh1 --rm ubuntussh /bin/bash Dieser Container ist zugänglich über den Port 2222 des Docker-Hosts - z.B. des zur Entwicklung genutzten Windows-Rechners.<br /> (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:
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 ueber eine eigene Adresse und Port 22 auf den Container zugegriffen werden.
Hinweis: Diese Uebung ging von der Der Erstellung dieses Images lag die Fragestellung auszugrunde: 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 - 28.12.2018))
BdB_Heidelberg, Bibliothek_KH, DAI_Makerspace_Projekt, Graphiken KF, Landfried, N_E_U_Project, Projekt_BdB_Heidelberg, Projekt_Civil_Commons, Projekt_Landfried, Projekt_OG, Team_UIEG_Heidelberg, Team_UIEV_Heidelberg, UIEG_Heidelberg, UIEV_Heidelberg, Bürokrat, Administrator, Widget-Bearbeiter
955
Bearbeitungen