Run web-ui in a docker container?

By the way, I’m not using a USB “Drive” - I am fully aware of all the concerns you have listed. I am using a USB 3.1 connected HDD. Does that mitigate any of your cautions/concerns?

Unrelated but more importantly, when the container first starts up it does not run any scheduled backups until/unless I’ve manually logged into the Web UI (and I presume, run them.) I presume because I haven’t tried just logging in and back out and seeing if my backups are running then. Is there something in the container that would be causing this behavior? Or is this part of the app design?

I noticed you updated the container to the new Web UI. Any chance it will pass the DWE_PASSWORD environment variable through to Duplicacy to make it work on a headless box without the password: Trouble with the encryption password on a headless Linux box

Ah, awesome feature. Yes, of course, I will add it, test it, and push the update later today. Thank you for the tip!

Thinking about this — I don’t think any changes are needed in the container: you can just pass the environment variable to the container via -e params: e.g. -e DWE_PASSWORD="Password"

Long timer lurker, first time calling in. :smiley:

Any chance you can add the Arm build for this Docker image?

Good idea. Ill think how best to do it. Maybe just an environment variable that can be overridden.

  1. How does it look for the latest release? I.e. how does duplicacy_web know the URL for the current duplicacy CLI? Is there an URL alias that always points to a current version?

  2. Any chance to redirect where the duplicacy_web looks for duplciacy_cli? The ~/.duplciacy-web folder is a reasonable place to keep data that needs to be persisted (config, stats, etc) and is a good candidate for a docker volume but I don’t think it’s an appropriate place for helper executables. Those are not configuration but rather part of software bundle; I’d rather build them into the image as opposed to keeping them dangling in the under data directories and relying on duplicacy to download them. Users may not have an internet connection on the machine with docker so I would be a good idea to have complete image pre-baked; but I would not want to litter in config folder.

Like this: One Liner to Download the Latest Release from Github Repo · GitHub, plus the names of the executable files are standardised there so they can just be constants in :d:-web code.

That’s what I’m was actually trying to understand. If new CLI is released will the existing duplicay_web download a new one or will it keep using the existing one, the one that was current when _web was published?

And if it does download the new one – how often does it check for the new one? Only when the CLI is missing? Never? Every Launch? Every hour?

pinging @gchen for this one

Duplicacy Web Edition checks this url https://api.github.com/repos/gilbertchen/duplicacy/releases/latest to find out the latest CLI version. It only does this on start. But, you can fix the CLI version by setting cli_version in ~/.duplicacy-web/duplicacy.json. For example "cli_version": "2.2.0" will instruct Duplicacy Web Edition to run CLI 2.2.0 without checking the latest version on github.

2 Likes

How do you actually apply a license in the docker container?

I have purchased a license, and have an “activation code”

I have specified the --hostname and can see that there is a licenses.json file in the config, but the strings in it are much bigger than my activation code. I have tried putting it in the “license id”
in duplicacy.json but that doesn’t work. What do I do?

Go to the Backup page. On the left top corner you’ll see a link next to the localhost text that says Trial. Click on that link and you can enter your license code.

Ah thanks, that worked.

May I suggest something on the settings page about this as that’s where I would expect to see license status and a link to activate a new license.

1 Like

I’m having trouble with the duplicacy scheduler just stopping after a while. I just got back from vacation and found it hadn’t run since the day December 22. Checking the log I see this:

2019/12/22 04:13:09 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set
2019/12/22 04:13:09 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0
2019/12/22 04:13:09 Temporary directory set to /cache
2019/12/22 04:13:09 Schedule DailyBackup next run time: 2019-1223 03:00
2019/12/22 04:13:09 Duplicacy Web Edition 1.1.0 (818F2B)
2019/12/22 04:13:10 Duplicacy CLI 2.3.0
2019/12/23 03:00:01 Skipping schedule DailyBackup at time 2019-1223 03:00 as no encryption password has been provided
2019/12/23 03:00:01 Please open the web browser at 0.0.0.0:3875 to enter the encryption password
2019/12/23 03:00:02 Schedule DailyBackup next run time: 2019-1224 03:00

And then the last 3 lines repeated daily until now.

I’ve noticed this before, but then its started working again, presumably because I logged into the UI.

Ideally I’d like to make my duplicacy container run without me having to periodically log in to the UI. Is there something I can change?

Thanks!

You can pass the encryption password in an environment variable DWE_PASSWORD before running the web GUI.

really appreciate the effort by @saspus for the docker container and ofcourse @gchen for duplicacy itself.

may i please suggest that @saspus - please update the README for the docker container at Docker Hub to mention the (utterly important) fact that DWE_PASSWORD has to be set in order for schedules to run successfully without throwing the " Skipping schedule backup at time as no encryption password has been provided" error in the log. I found this out the hard way after looking at duplicacy-web.log and then searching in the forum. Appreciate it. Many users wouldn’t even know that their backups are not running on schedule.

Also @gchen it would be great if the next release of duplicacy-web could email the user if the schedule did not run due to such errors.

2 Likes

it would still make sense to make this and other expected environment variables declared in your Dockerfile

2 Likes

Hey,

This docker image doesn’t seem to be persistent when using docker-compose. There must be a mapping missing somewhere, because if I deploy a change to the docker compose file and then redeploy with a docker-compose up, i’m prompted to set a password again - this isn’t being persisted on a volume.

My docker-compose file:

  duplicacy:
image: erichough/duplicacy
hostname: gibson-docker-duplicacy
container_name: "duplicacy"
ports:
  - "3875:3875"
cap_drop:
  - ALL
environment:
  MACHINE_ID: 4132b8ec3b041b11fc64cf578c26294f
  DWE_PASSWORD: PASSWORDHERE
volumes:
  - /home/brett/docker/duplicacy/config:/etc/duplicacy
  - /home/brett/docker/duplicacy/cache:/var/cache/duplicacy
  - /home/brett:/storage
  - /etc/localtime:/etc/localtime:ro
  - /etc/timezone:/etc/timezone:ro
restart: always

Done! (some time back, actually), thank you for suggestion. I myself spent some time hunting down that env variable. I did not add it to the Dockerfile though because I’m not sure whether empty variable will be treated the same as absent one by Duplicacy_web.