dotenv Umstellung about docker-homelab HOT 25 CLOSED

Die Idee ist grundsätzlich gut. Auf das mit den .env im gleichen Verzeichnis bin ich auch schon gestoßen. Hätte nämlich gern ein Installer geschrieben.

Ich würde ein neuen Branch eröffnen in dem wir die Sachen erst mal erstellen und in der Summe dann umstellen.

from docker-homelab.

Das ist auch eine gute Idee, somit könnte dann den Containername und den Pfad als Variable setzen.

from docker-homelab.

Es sollten jetzt alle notwenigen compose Dateien umgestellt worden sein.

from docker-homelab.

Ich hatte auch schon begonnen, zB. die Domain oder der Host Volumepfad als Variable aufgenommen. Meine Idee war es diese zentral in das root Verzeichnis von docker-homelab abzulegen.

Leider ist es bisher nur möglich wenn die env_file im gleichen Verzeichnis wie docker-compose befinden.

Bsp: docker-compose.yaml

    env_file:
      - ../.env

├── .env
└── traefik
    ├── config
    │   ├── ACME
    │   │   └── acme.json
    │   ├── dynamic.yml
    │   └── traefik.toml
    ├── docker-compose.yaml
    └── README.md

from docker-homelab.

Ich bin aktuell dabei die Dateien umzuschreiben, für alle Anwendungen.
Norrodar/docker-homelab/env-migrate

Wenn ich durch bin erstelle ich einen PR auf den env-migrate Branch von @cbirkenbeul. Müsste dann noch gegengecheckt werden.

from docker-homelab.

@Norrodar

Die Variable TZ ist nicht mehr nötig, da diese von dem Host in den Container gemountet wird. zB calibre

Weiterhin wäre eine globale Volume Variable vom Vorteil.

Sample.env
DOCKER-HOMELAB-VOLUME=/var/docker

Docker-compose

- ${DOCKER-HOMELAB-VOLUME}/calibre/config:/config

from docker-homelab.

@mr-bolle
Danke. Die TZ Var ist mit tatsächlich schon aufgefallen, hab es aber erstmal stupide durchgezogen.

Globale Variable hatte ich verworfen, da es ja keine 'globale' env-Datei geben kann und ich fand es u.a. auch wichtiger, den kompletten Pfad auf dem Host anpassen zu können. Hm..

from docker-homelab.

Vielleicht wäre ein bash Script die Lösung, welche den Pfad und die Domain in den jeweiligen Service Pfad übernimmt. Ich stelle mir es aktuell etwas umständlich vor, für jeden Service diese Variablen manuell anzupassen.

Nur mal so als Idee, ich hatte bisher noch keine Zeit mir dies anzusehen.

from docker-homelab.

Alles gut, ich bin über Hinweise, Ratschläge und dergleichen sehr dankbar! (:

Das Script müsste eh in jede einzelne env-Datei reingucken und die globale Variable anpassen.
Was man machen könnte ist das Aufsplitten der Volume-Variable:
Sample.env

DOCKER-HOMELAB-PATH=/var/docker
APP_VOL=/calibre/config  # Pfad unterhalb von /var/docker

Docker-compose
- ${DOCKER-HOMELAB-PATH}${APP_VOL}:config

Wirklich schön ist das aber nicht. In den env-Dateien lassen sich aber auch keine Variablen verwenden, sodass man sagen könnte:
${APP_VOL} = ${DOCKER-HOMELAB-PATH}/calibre/config

Edit: Oder doch? Sodass es später in der compose-datei umgesetzt wird?

Was evtl. noch eine Idee wäre: Den Containernamen als Variable setzen und verwenden. Sodass im aktuellen Beispiel das '/config' hardcoded ist - das dürfte sich ja, egal bei welcher Installation, nicht unbedingt unterscheiden.
Sample.env

DOCKER-HOMELAB-PATH=/var/docker
CONTAINER_NAME=calibre

Docker-compose
- ${DOCKER-HOMELAB-PATH}/${CONTAINER_NAME}/config:config

from docker-homelab.

Also für mich wäre nur die Variante nutzbar, wenn der gesamte Host-Pfad anpassbar ist, da ich keine Volumes nutze sondern lokale Verzeichnisse neben der docker-compose des jeweiligen Projekts reinmounte. So habe ich die Daten pro Projekt in einem Verzeichnis. Also es wäre schön, wenn wir in den env Dateien pro Mountpoint eine Variable nutzen würden.

Also bspw.:
nextcloud/.env

DB_DATA=./db 
FILES=./data

from docker-homelab.

Würde es nicht auch funktionieren, wenn du den Host nicht einfach '.' setzt?
DOCKER-HOMELAB-PATH=.

Würde dann ergeben:
./containername/db
./containername/data

from docker-homelab.

Ich hab Bitwarden testweise vollmodular umgesetzt. Was haltet ihr davon?
Norrodar/docker-homelab/env-migrate/bitwarden_rs

from docker-homelab.

Sieht für mich so aus, als hättest du alles aus der docker-compose in die env Datei platziert 😆 für mein Verständnis wäre das bisschen zu viel.

from docker-homelab.

@dvogt23 was wären denn die Variablen deiner Wahl?
APP_NAME scheint im ersten Moment vielleicht überflüssig, verhindert aber Wiederholung(sfehler) und bietet die Möglichkeit die Bezeichnung für Traefik anzupassen. Ist dann auch update-unabhängig. Der Traefik-Block lässt sich so dann auch ganz easy in eine neue compose kopieren, ohne weitere Anpassungen.
Daher auch die Einteilung nach "unbedingt", "optional" und "gar nicht" ändern. :)

from docker-homelab.

Eine wirklich tolle Idee ist die Traefik Service Namen als Variable zu übernehmen, das hilft ungemein 👍

Ich finde es auch etwas fehleranfällig und unübersichtlich, alle Variablen in die ENV auszulagern.
Weiterhin bin ich immer noch der Überzeugung das eine Trennung Domain + Service Sub-Domain hilfreich wäre.

`

• UNBEDINGT ANPASSEN
  DOMAIN_URL=example.com

• OPTIONAL ANPASSBAR
  SUBDOMAIN=bitwarden
  `

      - "traefik.http.routers.${APP_NAME}-http.rule=Host(`${SUBDOMAIN}.${DOMAIN_URL}`)
      - "traefik.http.routers.${APP_NAME}.rule=Host(`${SUBDOMAIN}.${DOMAIN_URL}`)

from docker-homelab.

@mr-bolle deine Domainaufspaltung gefällt mir, sollten wir so übernehmen.

Wirklich fehleranfälliger sollte es eigentlich nicht sein, ob man nun die Variable in der ENV oder im compose falsch belegt, macht keinen Unterschied. Die Trennung zwischen Konstrukt und Inhalt ist eben der Vorteil. Wer weiß denn schon, welche Variable der Nutzer brauch und welche nicht? Und das seine Einstellungen bei einem Update nicht überschrieben werden? Das müsste dann für jedes Projekt diskutiert werden.
Übersichtlichkeit ist wirklich so eine Sache. Die richtige Variablenbezeichnung ist wichtig, sowie entsprechende Kommentare. Die Sektionen (unbedingt ändern, optional änderbar, nicht ändern) sollte da schon etwas Struktur reinbringen. Die Readmes müssten noch um die zu ändernden Variablen angepasst werden. Dann sollte doch alles klar sein, mMn.

from docker-homelab.

Wenn zB. der TRAEFIK_ENTRYPOINTS geändert werden soll, muss dieser in jeder DOTENV Datei gemacht werden, und auch dynamic.yaml muss angepasst werden. Wenn jemand auf die Idee kommt, ist die Fehlersuche schwieriger als bisher.

Ich würde vorschlagen wir starten erst mal mit den unbedingt und optionalen Variablen und nehmen das Volume mount in optional rein. Ich habe mal einen Pull Request in deiner Repo angelegt :)

from docker-homelab.

Ich hab in meine Repo mal bitwarden_rs angepasst.
https://github.com/Norrodar/docker-homelab/tree/env-migrate/bitwarden_rs

Im Grunde hab ich fast alle Traefik-Variablen rausgeworfen, bis auf Traefik-An/Aus, TLS-An/Aus und die (Sub-)Domain.

Ich nutze Github nicht sonderlich oft, gibt es kein vernünftiges Diskussionsboard?

from docker-homelab.

Hi, ich finde es ausreichend und auch sehr übersichtlich👌

Leider kenne ich hier auch keine besser Möglichkeit in github zu kommentieren als über solche Postings.

from docker-homelab.

Wenn einer Rocketchat mit Traefik funktionsfähig hätte könnte man das als Diskussionsboard bzw. Kommunikationboard nutzen.

from docker-homelab.

@cbirkenbeul könnte bei https://gitter.im einen Chat eröffnen.

b2t:
Viell. wäre ein Kompromiss die notwendigen Variablen (welche auch immer: mMn domain, volumes) in die .env Datei auszulagern und die anderen Variablen in der compose Datei mit default Werten zu besetzen, i.e.:

    ...
    image: traefik:${IMAGE_TAG:-latest}
    ...

So könnten die Leute, die andere Werte benötigen, es überschreiben.

from docker-homelab.

Ja, das mit dem Überladen hätte man vorher wissen müssen :D So erübrigt sich ja die gesamte Diskussion über Sinn und Unsinn. Danke.
Ich habe mir dafür ein python-script geschrieben, welches gesetzte Variablen als Defaultwert einträgt.
Es hat sich auch herausgestellt, dass die Variablen nur als Wert verwendet werden können und auch keine Verschachtelungen unterstützen - nur so am Rande. ;)

from docker-homelab.

Ich habe mal angefangen. Im ersten Step mal wikijs umstellt. Kann bei Gelegenheit einer mal schauen ob da noch Probleme drin sind? Danke.

from docker-homelab.

Ich habe mal angefangen. Im ersten Step mal wikijs umstellt. Kann bei Gelegenheit einer mal schauen ob da noch Probleme drin sind? Danke.

postgres mit einem 's' und der postgres_user fehlt in der env. Einfach mal docker-compose config schauen ob die variablen korrekt übernommen wurden.

from docker-homelab.

Danke für den Tipp. Damit kann man es gut testen. Dann werde ich mich mal an die anderen Container wagen.

from docker-homelab.