Support _FILE convention for secret mounted into file as environment variable

[gilgougnot]

While using docker compose, I would like the image to support the _FILE convention.
This allow us to have the secret into a local file, mounted as a top level secret objet and injected into an environment variable following the <ENV_NAME>_FILES convention to build the secret:
https://docs.docker.com/build/building/secrets/#target

docker compose file would look like this:

`volumes:
datasets:

services:
wikidocs:
image: zavy86/wikidocs:2
container_name: wikidocs
restart: unless-stopped
environment:
SECRET_FILE: /run/secrets/docker_wikidocs_secret
env_file:
- path: "~/.wikidocs/docker/default.env"
required: false
volumes:
- datasets:/var/lib/wikidocs/datasets
ports:
- "3210:3210"
secrets:
- source: docker_wikidocs_secret
mode: 0444
networks:
- wikidocs-network

secrets:
docker_wikidocs_secret:
file: ~/.wikidocs/docker/.env.secret

networks:
wikidocs-network:
driver: bridge`

[Zavy86]

can you open an issue for your two ideas?

[MLuc24]

Not supported today, and the reason is structural rather than an oversight: the image has no entrypoint script to implement the convention in. The Dockerfile sets the value as a plain variable —

ENV SECRET=wikidocs-insecure-secret-to-be-changed

— and then execs the app directly:

CMD ["node", "/app/backend/dist/backend/src/main.js"]

The _FILE convention is normally a few lines in an entrypoint that reads ${VAR}_FILE and exports VAR before handing off. With no entrypoint present, adding it means either introducing that shim or handling _FILE where the backend reads its config — both small, but a deliberate addition either way.

Until then you can get the same result from your compose file without any code change, by supplying the entrypoint yourself:

entrypoint: ["/bin/sh", "-c", "export SECRET=$$(cat $$SECRET_FILE); exec node /app/backend/dist/backend/src/main.js"]

The doubled $$ is compose escaping so the substitution happens in the container rather than at compose-parse time. Your secrets: block and SECRET_FILE variable stay exactly as you have them.

Worth noting in favour of the request that the image ships a real default for that variable rather than leaving it unset, so anyone who does not override it is running on a known value — which is a decent argument for making the file-based path first-class rather than something each user wires up themselves.

[Zavy86]

please reply into the issue