Add more explanation to "As a workaround, you can create a symlink to your config.json file and then mount the symlink in the container."

[stevemarksd]

Is your feature request related to a problem? Please describe.

I'm always frustrated when there is no clear way to "As a workaround, you can create a symlink to your config.json file and then mount the symlink in the container.". I have no idea how it should be symlink, from where to where, what kind of symlink (hard/soft...). A simple example would help.

Needs to symlink the .docker folder, the config file? etc

Describe the solution you'd like

No idea how to use config as explained here: https://containrrr.dev/watchtower/usage-overview/

Describe alternatives you've considered

No idea where needs to be symlinked.

Additional context

[github-actions]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[piksel]

You can name your link anything, it should point at your normal config.json and be a symlink (not a hardlink).

Example:

ln -s ~/.docker/config.json ~/.docker/config-linked.json

docker run -d \
  --name watchtower \
  -v /home/<user>/.docker/config-linked.json:/config.json \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower container_to_watch

[simskij]

mklink -s ~/.docker/config.json ~/.docker/config-linked.json

and on linux, you'd do ln -s instead.

[piksel]

Ehm, that was just a typo. Too much powershell shenanigans recently....

[marksteward]

I'm reasonably sure this doesn't work. If the target of the symlink changes inode, docker doesn't rebind. The only way I know of is to mount the directory containing the config file, and then symlink /config.json to the file within that.

[piksel]

I tried testing it just now, and I couldn't get any editor to change the inode (tried vscode and vim using "backup" and "writebackup"). Not sure what is going on. But I also think that the intended solution was supposed to be a hard link, since the reason for why it would work is that the file would have an additional inode ref, meaning that replacing the file would sever the link. This in turn would cause editors to not use the replace method of writing to the file. At least, that is how I interpeted it.

But yeah, I cannot reproduce the problem at all right now, so... 🤷‍♀️

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MerlinChiodo]

You can name your link anything, it should point at your normal config.json and be a symlink (not a hardlink).

Example:

ln -s ~/.docker/config.json ~/.docker/config-linked.json

docker run -d \
  --name watchtower \
  -v /home/<user>/.docker/config-linked.json:/config.json \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower container_to_watch

So, I'm opening this up again, because i face the same issues.
So in this example we talk about the real container to watch, as example: any other container than watchtower... because watchtower isn't a good example in the dokumentation. Am I right?
Like:

docker run -d \
--name any_other_container \
-v /home/<user>/.docker/config-linked.json:/config.json \
-v /var/run/docker.sock:/var/run/docker.sock \
<dockerhub_or_private_name>/<registry_name>:<tag> container_to_watch

[piksel]

@MerlinChiodo
No, like

docker run -d \
  --name watchtower \
  -v /home/<user>/.docker/config-linked.json:/config.json \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower <dockerhub_or_private_name>/<registry_name>:<tag>

(in the original example, it was container_to_watch)

[simskij]

If anyone has a suggestion on how to rephrase the docs to make it clearer, PRs are welcome. ✨

[Podesta]

I believe the real issue is not on how to make the instructions clearer, but rather that the proposed solution simply does not work. I've done a couple of tests, as I need to refresh the azure token to access a private azure container registry with the machine's service principal.

1. By directly mounting a symlink, or soft-link, with the config.json, as proposed, it does not work, because the symlink gets dereferenced the time the container starts. So any changes made to the file that is linked with the symlink, does not get represented on the container. The file on the container is a normal file, representing the state of the file that was linked to at start time, not a link.
2. By using a hardlink, as proposed a couple messages up by @piksel, it also doesn't work. Once the inode of the file it was linking to changes (as the original file gets overwritten), the link between them gets broken. Hardlinks are actual links to the same thing, with both of them sharing the inode. If the inode of one of them changes, they are no longer linked.
3. If you mount a folder, and inside the folder there is a symlink, then the symlink actually gets copied into docker as a symlink. But its link is the host one, so it would not link to anything valid, unless, of course, you mounted the host path that it links to, to docker.

The only viable solution, from what I could test, is mounting a folder and passing the DOCKER_CONFIG env.

[piksel]

@Podesta

1 and 2: How are you refreshing the token? The file can be overwritten without changing the inode. I couldn't find a way to make vscode or vim use the "replace" method of writing changes to a file without explicitly forcing it.

3: I think the idea was to mount the folder (.docker) and then symlink the config inside the container, but you can just override the config path with an arg/env variable instead (which was your solution at the end, yeah).

[Podesta]

We are not manually editing the file. We are refreshing the token with the azure cli, by running az acr login --name <REGISTRY_NAME> every couple of hours (the token duration). I believe, under the hood, the azure cli is just invoking the docker login command. I believe the docker command does not edit the file, instead creating a new one and overwriting the last one, but I'm not sure on the specifics of which syscalls they are using.

But you can confirm this by calling docker login. Even without changing the credentials, and the file contents being exactly the same, the inode still changes, as I believe they are indeed just creating a new file. With file editors, I think it's pretty rare that they change the inode of the file by editing them.