Closed MarkusTieger closed 1 year ago
Because you are mounting over an existing directory inside the container you will lose the original content, the .dat and config file. Using default volumes will result into this. Using named volumes like in the example compose file will prevent this from happening. Example compose file: docker-compose.yml
Another possible solution would be to copy the files over from the container into the directory before you start the container with those mounts.
Yes, copying works, but i do not like that solution. -> I guess i have to do it after every update or does it update itself?
In short and probably not technically correct. Default volumes, the ones you are using which are created on the fly when starting the container. They are created on the first container launch and mapped into the container overwriting whatever is there. Resulting in an empty folder.
What is written to that volume after that launch will be maintained. That's why I suggested to use named volumes, they are already created before the launch of the container so the container can place it's file onto that mounted volume. Like I said, not the technically correct explanation but this is what happens.
-> I guess i have to do it after every update or does it update itself?
No, once created it will be maintained.
I see 2 solutions to support default volumes out of the box, of which I like none:
I save the files in another location inside the container and modify the entrypoint script to copy files over on initial run, then on subsequent runs check if the files exist to not do that every container launch. Main reason I don't like this option is that it brings additional bloat.
You could also download them on the initial run but then you can't run it without internet access.
My goto would be a named volume or extract the files yourself (from container or iventoy package). I'd love to get other angles/views/experiences on this approach of course.
For what it's worth i simply ran the container locally with unmapped data directory... then copied out the .dat and db files to the mapped persistant data folder and it's been working a treat ever since. I've tried forcing an update over the container and data has been persistant too.
I made a custom Dockerfile which moves the iventoy.dat to /app, and in /app/data i created a symlink "../iventoy.dat" on the mount point, and after an update i can just rebuild the Docker image.
version: "3.9"
services:
iventoy:
image: ziggyds/iventoy:1.0.19
hostname: iventoy
container_name: iventoy-dev
restart: unless-stopped
privileged: true #must be true
ports:
- "26000:26000"
- "16000:16000"
- "10809:10809"
- "67:67/udp"
- "69:69/udp"
volumes:
- ./_docker-data/iso:/app/iso
- config:/app/data
- ./_docker-data/log:/app/log
environment:
- AUTO_START_PXE=true # optional, true by default
- TZ=Asia/Shanghai
volumes:
config:
driver: local
driver_opts:
type: none
device: ./_docker-data/config/
o: bind
it works for me...
Kinda silly. No docker-compose files work like this... If this is truly needed, putting some notes in the ReadMe seems fairly important, since this is a very unusual way to have to run a container.
The following error appears when trying to start it using docker:
My Compose-File:
Edit: "netstat -tulnp" (net-tools installed using apt) doesn't show the ports binded and the web interface is inaccessible too.