Skip to content

Container's Entrypoint Feedback #395

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
stavros-k opened this issue May 7, 2023 · 3 comments
Closed

Container's Entrypoint Feedback #395

stavros-k opened this issue May 7, 2023 · 3 comments
Labels

Comments

@stavros-k
Copy link

stavros-k commented May 7, 2023

I was just peeking through the repo and mainly the entrypoint of the container before I install my instance,

I noticed that it prints specific env's in the .env file if the file does not exist.
But this whole section of creating the .env file is not really necessary in container setups.
It's useful for standalone setups so you keep things tidy, but for containers, you can just store those env's in the docker compose file (as you already do in order for this script to read them). (Docker compose also support sourcing a .env file itself if someone wants to store env's in the machine the container will run, so they can have docker-compose commited in a git repo)

Also, (AFAIK) the current script does not update the .env file, it only works the first time run, and won't update it on next runs.

My proposal is to remove this section and replace it with couple of checks of the bare minimum required variables (eg APP_KEY and DB details), with some warnings, that way PR's like #389 won't be needed.

Don't get me wrong! This "works" now, but .env does not reflect the actual values used by bookstack.
If I change a variable and restart the container .env will not be updated, but bookstack will pick up the change from the container's environment variable.

From Laravel's docs
https://laravel.com/docs/10.x/configuration

Any variable in your .env file can be overridden by external environment variables such as server-level or system-level
environment variables.


Another small thing is that APP_KEY is getting regenerated at every startup. While for docker environments is fine, in environments like kubernetes or docker swarm, if you have replicas generating APP_KEY different from each other it can lead to weird situations.
Might worth adding a flag to disable that, or only run it when APP_KEY is the default value of SomeRandomString

Thanks for all the work, you've done here!

@ssddanbrown
Copy link
Contributor

ssddanbrown commented May 7, 2023

Another small thing is that APP_KEY is getting regenerated at every startup. While for docker environments is fine [...]

Just a note on that, Ideally the APP_KEY should be persistent/stable since it is used in certain other persistent areas (Encrypting MFA credentials for example).

Currently I don't think the APP_KEY is being regenerated at every startup, although the script comments may make it seem like it is:

https://github.com/solidnerd/docker-bookstack/blob/74c3f232e2015ffd552515369306b6860bda1158/docker-entrypoint.sh#L105-L106C6

The use of the --show option on the command displays the key to stdout instead of applying modifications to any .env files.

@stavros-k
Copy link
Author

The use of the --show option on the command displays the key to stdout instead of applying modifications to any .env files.

Indeed the show does not modify it, didn't know that, thanks

@stale
Copy link

stale bot commented Jun 10, 2023

This issue has been automatically marked as stale because it has not had any activity for the last 30 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.

@stale stale bot added the stale label Jun 10, 2023
@stale stale bot closed this as completed Jun 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants