BarCamp 2019 - UCS and Docker 101

Preface:

On February 1st, 2019 we had a BarCamp as part of the Univention Summit 2019. Several topics were discussed and the summary will be made available here. The summaries are in german and should be translated later. Further discussion and additions are welcome.

Summary:

UCS and Docker 101

  • Einführung in den Ablauf: Slide von Univention
  • Komponenten:
    • “docker pull” für Download von Images auf die UCS Instanz
    • auf dieser Basis wird der Docker Container gestartet
    • “docker proxy” als Service stellt die Netzwerkverbindungen auf dem Docker Bridge Interface (virtuelles, lokales Netzwerk-Interface) bereit
    • Webservices werden über eine vom App Center konfigurierte Apache Reverse Proxy Konfiguration veröffentlicht
  • Aus der Diskussion:
    • Anwendungen mit eigenem Konfigurations- und Management-Zyklus können sich den Docker Mechanismen (z.B. OwnCloud, Nextcloud, Wordpress), hier muss im Image/Container durch den App Hersteller die Ablage des Customizings ausserhalb des Images im nativen Dateisystem vorgesehen sein
  • Wünsche / Feedback:
    • UMC sollte auf einem anderen Port laufen können, um über HTTPS/Port443 nur Dienste für Endanwender bereit zu stellen
    • Reverse Proxy Konfiguration: Apps nicht nur unter FQDN/APP bereit stellen können, sondern auch unter APP.DOMAIN (SNI)
    • Dokumentation:
      • der Univention-spezifischen Tools, z.B. “univention-app” für Administratoren
    • Ablage der Daten & Sizing/Partitionierungsempfehlungen (/var/lib/univention-appcenter/APP/data)
    • Benennung der laufenden Container nicht über die generierten Namen, sondern auf Basis des Namens der App
    • bessere Partitionierung der App Appliances, z.B. Auslagern der Datenbank und Nutzdaten auf eigene Partitionen
    • Heruntergeladene, nicht mehr benötigte Images löschen (docker system prune -a)

this is already possible through the construct with the configure_host scripts. I am doing this for the Mattermost and Minio apps. Of course it would be desirable to have builtin functionality for this.

+1
Here a lot is currently left to the app maintainer. I tried experimenting with some ucr variables to influence the bind mounts the app is using. this was due to the timing when ucr variables were written through the settings dialogue not practical unfortunately.

IMHO docker images should me “read only” to the admin. A good docker container does not rely on users changing settings inside of the container. everything should be done through env variables (which then could still be picked up in a startup script and lead to additional packages to be installed).

1 Like
Mastodon