OpenCloud - Docker Compose Hetzner VM
-
Gestern Abend habe ich mal damit angefangen, eine OpenCloud auf einer Hetzner VM zu deployen. Die Anleitung dazu findet man -> https://docs.opencloud.eu/docs/admin/getting-started/container/docker-compose
1. Versuch
Mein erster Versuch ging ganz ordentlich in die Hose. Ich hatte also alle vier Domains ordentlich konfiguriert, also mit A und AAAA Eintrag. Nur die Docker Container mochten das irgendwie überhaupt nicht, weil sie kein DNS mehr hatten. Ich habe dann nach langem Suchen raus gefunden, das Hetzner in der /etc/network/interfaces.d/50-cloud-init alles auf IPv6 getrimmt hat. Auch alle DNS-Server usw. Da ich auf diesem Gebiet nicht unbedingt der Experte bin und ich eigentlich schnelle Ergebnisse sehen wollte
, habe ich den Server einfach nochmal neu aufgesetzt, diesmal IPv4 only.
2. Versuch
So, das ganze nochmal als IPv4 only und die ganze Geschichte ging schon wesentlich besser voran. Ich habe mich weitestgehend an die Anleitung gehalten, außer das ich einen User angelegt habe, der die Docker Container deployed. Nachdem ich dann auch eine vernünftige DNS Auflösung hatte, ging das mit den LetsEncrypt Zertifikaten wie von Geisterhand
Die Anleitung ist sehr gut, auch für Einsteiger zu verstehen. Grundkenntnisse einer Serveradministration, sollte man aber schon drauf haben.
Die Pfade der Datenspeicherung angepasst und das Ganze deployt. Lief ohne Probleme auf Anhieb. Danach habe ich dann nftables eingerichtet, die offenen Ports sind 22, 80 und 443.
Danach, nachdem alles lief wie gewünscht, habe ich noch den Radicale Server aktiviert, auch dieser hat ein lokales Datengrab bekommen.
docker compose down docker compose up -d
Und auch das war erledigt. Kurzer Test mit Handy und Thunderbird - funktioniert alles wie erwartet.
Was mich dann noch verwundert hat, war dass das TLS Zertifikat nur einen 128-Bit-Schlüssel benutzt.
Die künstliche Intelligenz befragt, vieles ausprobiert, bis sie dann meinte das das in Traefik hardcodiert ist, das erst 128 benutzt wird (weil schneller). Sie meinte dann, da sollte ich einen HAProxy vorbauen usw. Das Thema durchblicke ich noch nicht 100%, so lass ich das erst mal wie es ist.
Ein normaler NGINX davor, wäre mir sowieso lieber, weil "das kennt man".
Ich war geizig, zum Testen habe ich einen CX22 benutzt, der aber hier für meine gedachte Anwendung (NC Ersatz für mich alleine) durchaus reichen könnte.
So, was bleibt auf der ToDo-Liste?
- IPv6 Integration
- NGINX vorschalten
- s3 Integration
Der NGINX würde auch das Problem mit AES_256 lösen
Fazit
Für den erfahrenen Admin ist das ruck zuck zu installieren. Läuft auch auf meiner 2vCPU (1 Benutzer) ausreichend schnell. Das werde ich aber die nächsten Tage sicherlich noch intensiv testen, wenn ich mal ein paar GB an Bildern verschiebe.
Das was ich als nächstes Testen möchte, das ich die Daten auf meiner Minio Instanz ablegen kann.
Feedback und Tipps immer gerne gesehen.
Der Post kann Werbelinks enthalten
-
Ich habe mich nochmal mit verschiedenen Aspekten der produktiven Installation beschäftigt. Auch ein wenig die KI befragt und dann ein paar Änderungen vorgenommen. Was hatte mich gestört? Traefik lief als root.
Um das zu ändern, habe ich das docker-compose.yml angepasst. Ich habe auch gleich mal auf die aktuelle Version angepasst.
services: traefik: image: traefik:v3.4.1 #3.3.1 container_name: traefik user: "1000:1001" # 1000 = dockeruser, 1001=docker group cap_add: - NET_BIND_SERVICE # erlaubt Ports <1024 restart: always networks: - opencloud-net ports: - "80:80" - "443:443" volumes: - ./certs:/certs # bind-mount acme.json - /var/run/docker.sock:/var/run/docker.sock:ro command: - "--log.level=${TRAEFIK_LOG_LEVEL:-ERROR}" # Let's Encrypt HTTP-01 Challenge - "--certificatesResolvers.http.acme.email=${TRAEFIK_ACME_MAIL:-example@example.org}" - "--certificatesResolvers.http.acme.storage=/certs/acme.json" - "--certificatesResolvers.http.acme.httpChallenge.entryPoint=http" - "--certificatesResolvers.http.acme.caserver=${TRAEFIK_ACME_CASERVER:-https://acme-v02.api.letsencrypt.org/directory}" # Dashboard - "--api.dashboard=true" # Entrypoints - "--entryPoints.http.address=:80" - "--entryPoints.http.http.redirections.entryPoint.to=https" - "--entryPoints.http.http.redirections.entryPoint.scheme=https" - "--entryPoints.https.address=:443" - "--entryPoints.https.transport.respondingTimeouts.readTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.writeTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.idleTimeout=3m" # Docker Provider - "--providers.docker.endpoint=unix:///var/run/docker.sock" - "--providers.docker.exposedByDefault=false" # Access Log - "--accessLog=true" - "--accessLog.format=json" - "--accessLog.fields.headers.names.X-Request-Id=keep" labels: - "traefik.enable=${TRAEFIK_DASHBOARD:-false}" - "traefik.http.middlewares.traefik-auth.basicauth.users=${TRAEFIK_BASIC_AUTH_USERS:-admin:$$apr1$$4vqie50r$$YQAmQdtmz5n9rEALhxJ4l.}" - "traefik.http.routers.traefik.entrypoints=https" - "traefik.http.routers.traefik.rule=Host(`${TRAEFIK_DOMAIN:-traefik.opencloud.test}`)" - "traefik.http.routers.traefik.middlewares=traefik-auth" - "traefik.http.routers.traefik.tls.certresolver=http" - "traefik.http.routers.traefik.service=api@internal" networks: opencloud-net: volumes: {}
Und hierzu
- ./certs:/certs # bind-mount acme.json
brauch es noch ein paar Anpassungen auf dem Host, also im Verzeichnis von wo wir deployen mit dem dockeruser!
mkdir -p ./certs touch ./certs/acme.json chmod 600 ./certs/acme.json chown 1000:1000 ./certs/acme.json # UID muss mit docker-compose user übereinstimmen
Das klappt jetzt hier einwandfrei.
dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ docker exec -it traefik id uid=1000 gid=1001 groups=1001
Sieht soweit gut aus
Die KI meint noch das hier
Wenn du maximale Sicherheit willst, kannst du langfristig docker-socket-proxy einsetzen. Er erlaubt Traefik nur lesenden Zugriff auf die Container-API:
→ Projektseite: Tecnativa/docker-socket-proxy
Das muss ich aber erst noch sacken lassen und mich etwas zu einlesen.
-
F FrankM verschob dieses Thema von Linux