- Create some instructions and a decent README
- basic instructions done, need to expand
- remove some markdown specific features for readability on dh and plaintext
- Create an advanced example with proxy, volume and docker network considerations
- Remove pwgen generated password for deluged from build logs and images hosted on docker-hub
- removed password generation from build phase
-
docker pull still gets the pass from built image, ONBUILD is of no use in this case - redo echo user:pwgen -1 8:10 >> auth into a script in Dockerfile, then let user docker exec?
- deluged-pass.sh done, placed in /opt/deluge/config/ and linked to /usr/bin
- Find some best practices on handling secrets in docker containers?
- moved password generation to to script, only other way involves added software
- Find a solution to file ownership without adding chown scripts with COPY/ADD?
- Already an entrypoint.sh in testing :(
- trying to make the simplest posible su-exec chown and exec script
- the correct way is still passing --build-arg on docker build or editing Dockerfile
is --user and config files from outside a solution(chown scripts are looking better and better)- not worth it, easier edditing Dockerfile or entrypoint.sh
- Is usage viable on a NAS appliance?
- Synology Rackstation works perfectly, what about devices cheaper than my car?
- Remove a couple more packages after build layer and start using --virtual-package in apk?
- no need for apk --virtual-package, readability is fine
- removed a couple of packages
- removed build files
- Define more volumes in Dockerfile or let it be?
- should we define all 3? Should we also set move on complete to true, for volumes on cow fs?
- should we create a separate volume for ssl cert?
- Is there to much metadata in the image via ENV and LABEL?
- generating reverse proxy templates works without a problem (nginx, caddy), but is it of use to anyone else?
- Define sane config location (/opt/deluge/config works nicely)
- Set ENV in a way, that enables manual Dockerfile edditing
- Test how deluged handles unexpected shutdown
- torrent.state and pid related stuff works after power off
- no need for any kind of init, since deluged is well behaved
- still tini looks really nice (and is in all recent docker versions), should implement anyway?
- should we let user decide, since docker create --init works without a hitch?
- Setting deluged configuration values:
- Using deluged-console like we are supposed to
- When starting deluged, give it some time, before setting values
- Separate commands, so even on failure of one, others values get set
- Enable debug for first run
- Shut down deluged with deluge-console not kill!!
- Exit codes make build fails on docker-hub :( :(
- Performance testing with docker network drivers
- works as expected on default (legacy bridge)
- works as expected on vlan and macvlan
- no difference measured on container and host deluged on 1gb and 10gb
- we were lucky and tested when ubuntu 17.04 came out
- set insane connection numbers and it was suprisingly stable, gj libtorrent and deluge guys
- udp works as advertised
- dht works as advertised
- Figure out compiling just the needed modules with python setuptools