Benötige Hilfe bei docker-compose und volumes

M

member1

Member
Ich möchte einen Container mit einer Custom-Software drin betreiben. Für die Software gibt es immer wieder Updates, die recht umfangreiche Konfiguration, bestehend aus dutzenden von Dateien, bliebe davon aber zunächst unberührt. Also lag der Gedanke nahe einen Container zu bauen der nur die Software enthält und ein Volume welches die Konfiguration (persistent) enthält.

Soweit ich das recherchiert habe kann man auf die Daten in einem Volume nur dann zugreifen (z.B. mit docker cp ...) wenn dieses in einem Container gemounted ist, wobei der Container nicht laufen muss. Also habe ich sowas für das befüllen bzw. updaten der Konfig gemacht:

Code: 
# create config volume (only needed once)
docker volume create my-config

# update configs into volume
docker container create --name temp -v my-config:/etc/service busybox
docker cp files/opt/service/configurations/ temp:/etc/service/
docker rm tmp

Dann wollte ich das Volume einfach in meiner docker-compose.yaml einbauen und nutzen:
YAML: 
# Defines a CUE Zipline

version: "3"

volumes:
  my-config:

services:
  service:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - APT_SERVUCE_VERSION
    image: "service:${APT_SERVICE_VERSION:-latest}"
    container_name: service
    volumes:
      - /var/log/service:/var/log/service
      - my-config:/etc/service:ro
    ports:
      - "12791:12791"

Aber beim "docker-compose up -d" nutzt er das Volume nicht, sondern baut ein neues mit dem Namen der yaml, gefolgt vom Volume-Namen!
Weiterhin habe ich das Problem das ich beim Build ja die Variable APT_SERVICE_VERSION mitgeben muss. Wenn ich
Code: 
docker-compose build ----build-arg APT_SERVICE_VERSION=1.1.10
mache, klappt der Build. Ein nachfolgendes "docker-compose up -d" jedoch versucht den Build nochmal zu machen (warum eigentlich?) und scheitert dann an der fehlenden Variablen. Das build-Kommando kennt auch keine build-arg Übergabe.
 
Moinsen,
bei docker & co bin ich leider sofort raus bei null Ahnung. ;)
Hier im Forum sind aber Menschen, die sich dahingehend super auskennen, etwa @Confluencer.
Vielleicht schaut ja von den Container-Profis hier nach erfolgtem Ausflug zum Badesee heute noch jemand mit einer guten Idee vorbei...
 
Man muss kein Named Volume verwenden. Man kann stattdessen auch einfach ein Bind verwenden, bei dem ein Host-Pfad in einen Container-Pfad gemountet wird.

Das ist ein Bind:
Code: 
   - /var/log/service:/var/log/service
Das ist ein Named Volume:
Code: 
   - my-config:/etc/service:ro

Wenn man ein extern erstelltes Named Volume verwenden will, dann muss man es als solches in seiner compose Datei einbinden:
Code: 
volumes:
  my-config:
    external:
      name: my-config

Ich persönlich würde auf der Syno ja eher zum Bind greifen.
 
Die build args können entweder als Sequence/List angegeben werden:
Code: 
      args:
        - "APT_SERVUCE_VERSION=was-auch-immer-der-Wert-ist"
oder als Map:
Code: 
      args:
        APT_SERVUCE_VERSION: "was-auch-immer-der-Wert-ist"
Wenn man mal nicht genau weiss was wie konfiguriert werden muss, lohnt sich immer ein Blick in die Compose file reference:
<https://docs.docker.com/compose/compose-file/build/>
<https://docs.docker.com/compose/compose-file/05-services/>
<https://docs.docker.com/compose/compose-file/07-volumes/>
 
Confluencer schrieb:
Wenn man ein extern erstelltes Named Volume verwenden will, dann muss man es als solches in seiner compose Datei einbinden:
Code: 
volumes:
  my-config:
    external:
      name: my-config
Zum Vergrößern anklicken....
AAAH! Danke, das mit dem "external" hatte ich mal irgendwo gelesen aber nicht in Zusammenhang gebracht. Dort stand das per "docker volume" erstellte Volumes nicht ohne weiteres mit per docker-compose erstellten Containern genutzt werden könnten. Jetzt ergibt das nen Sinn :)
 
Confluencer schrieb:
Die build args können entweder als Sequence/List angegeben werden:
Code: 
      args:
        - "APT_SERVUCE_VERSION=was-auch-immer-der-Wert-ist"
oder als Map:
Code: 
      args:
        APT_SERVUCE_VERSION: "was-auch-immer-der-Wert-ist"
Zum Vergrößern anklicken....
Hm, den Unterschied verstehe ich nicht. Ich habe jetzt eine .env Datei mit dem Inhalt (= Zuweisung) erstellt. Das klappt, das liest sowohl docker-compose beim build (der ja scheinbar keine Umgebungsvariablen verwenden kann) aber auch beim up.
 
Einziger Schönheitsfehler ist dieser Hinweis bei Nutzung von "external"
Code: 
WARN[0000] volume my-config: volume.external.name is deprecated in favor of volume.name
 
Hmm, ich hatte es direkt aus dem Beispiel der Compose Specification übernommen.

Dann pass mal folgend an:
Code: 
volumes:
  my-config:
    external: true
    name: my-config

Die Compose Specification vereint das v2 und v3 Schema. Docker compose v2 (=docker compose) ignoriert die Version der Compose Datei und wendet immer das aktuellste Schema Spezifikation an. Das allseites bekannt docker-compose (v1) is mittlerweile deprecated.
 
Zuletzt bearbeitet:
Klasse, nun funktioniert es ohne Warnung!

Aber ich bin etwas verwirrt. Also "docker-compose" ist nicht dasselbe wie "docker compose" ja? Und mit Version meinst Du das was man im Anfang eines docker-compose.yaml schreibt? Die dortige "version: "3" habe ich einfach nur abgetippt ohne mir darüber Gedanken zu machen :LOL:
 
Ich hatte vor dieser Initiative in der Tat die Konfigurationen local auf dem dockerhost liegen und ähnlich wie die logfiles in den Container gemounted. Hier hatte ich aber regelmäßig das Problem das Änderungen vom lokalen host filesystem nicht in den Docker übernommen wurden, oder umgekehrt. Das hat mich zum Wahnsinn getrieben, daher die Idee die Configs persistent auszulagern.

Eine andere Idee die mich dabei antreibt ist das ich das ganze Docker Zeugs gern in unseren Gitlab Server integrieren würde. Es müsste ja möglich sein das Image dort zu speichern, ggf. sogar über eine Pipeline dort bauen zu lassen? Die Configs stammen aus einem Gitlab repository und könnten ggf. einen ähnlichen Weg in ein Volume finden. Aber das ist Zukunftsmusik, ich muss erstmal das Docker-Zeugs besser verstehen...
 
member1 schrieb:
Also "docker-compose" ist nicht dasselbe wie "docker compose" ja?
Zum Vergrößern anklicken....
Korrekt. Das erst ist die alte v1, die nicht mehr weiterentwickelt wird. Das zweite ist ein cli-plugin und ist die v2 Version. Letzteres wird aktiv entwickelt.

Ursprünglich wurde v1 nicht von Docker entwickelt und hieß "Fig". Nachdem Docker es aufgekauft hat, wurde es in "docker-compose" umbenannt. Es war aber trotzdem irgendwie immer anders, da es als einziges in Python geschrieben war und nicht wie der Rest in Go. Das Cli-Plugin (v2) ist jetzt natürlich auch in Go.
member1 schrieb:
Und mit Version meinst Du das was man im Anfang eines docker-compose.yaml schreibt?
Zum Vergrößern anklicken....
Damit meine ich die Version des Compose Schemas, dass in der Datei verwendet wird. Es ist quasi der "Vertrag" der besagt wie das Dokument aufgebaut ist und welche Konfigurations-Elemente verwendet werden dürfen.
member1 schrieb:
Hier hatte ich aber regelmäßig das Problem das Änderungen vom lokalen host filesystem nicht in den Docker übernommen wurden, oder umgekehrt.
Zum Vergrößern anklicken....
Man muss schon darauf achten, dass die UID:GID des Verzeichnis/Datei Owners zur UID:GID passt, mit der im Container der Prozess ausgeführt wird. Bei einem Named Volume wird einem das i. d. R. abgenommen. Ein Container ist am Ende nicht viel anders als ein Prozess, der direkt auf dem Host ausgeführt wird, nur mit dem Unterschied das er isoliert ist und nur sehen und tun darf was ihm erlaubt wurde. Dazu kommt noch ein wenig Netzwerk + Storage Magie :)

Klar kann man das auch mit Gitlab machen. Man muss sich aber ein wenig mit Shared- und/oder Group- und Project-Runner auseinandersetzen. In der Regel hat man nicht nur einen Gitlab Runner, sondern etliche Group-Runner. Da stellt sich oft die Frage, wie mit Secrets umgegangen wird - in vielen Firmen ist es nicht complient Secrets als Gitlab CI/CD Secret zu speichern. Mach Dich am besten schlau was bei Euch erlaubt ist und was nicht, sonst kann man sich ziemlich schnell in die Nesseln setzen.
 
Vielen herzlichen Dank für die tollen Ausführungen @Confluencer, Leute wie Dich findet man leider (zu) selten im "Netz"! Top!
Ich werde mich also besser mehr an das von Docker selbst bereitgestellte "docker compose" halten.

Das mit Gitlab wäre erstmal eine Spielerei, genau wie Docker derzeit. Unsere Java-Entwickler nutzen bereits Gitlab-Runner zum bauen ihrer Artefakte, dort könnte ich mir, was Runner angeht etwas Wissen abziehen.
Wenn man Container ernsthaft betreibt kommt man kaum um K8s herum und das ist wieder ne ganz andere Liga. Compliance-Regeln gibt es bei uns derzeit so nicht, dafür sind wir wohl zu klein. Dennoch sind Kennwörter immer ein großes Ärgernis, auch ohne Compliance. Div. Gitlab-Projekte sind gespickt damit.
 
member1 schrieb:
Wenn man Container ernsthaft betreibt kommt man kaum um K8s herum und das ist wieder ne ganz andere Liga.
Zum Vergrößern anklicken....
Jepp && Jepp!! Man hat eine steile Lernkurve und muss spätestens alle 9 Monate seinen Cluster auf eine aktuellere Version migrieren und darf das dann alle 6-9 Monate planen und "nebenbei" durchführen. Dafür bekommt man aber auch deutlich mehr Flexibilität als mit Docker und nebenbei eine Ökosystem, dass selbst für die wildesten Szenarien eine Lösung bereithält.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Zurzeit aktive Besucher

Gesamt: 93 (Mitglieder: 5, Gäste: 88)

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
4.534
Beiträge
46.467
Mitglieder
4.170
Neuestes Mitglied
HomeJoe

Teilen

Zurück
Oben