You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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!
The text was updated successfully, but these errors were encountered:
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:
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.
Uh oh!
There was an error while loading. Please reload this page.
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
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!
The text was updated successfully, but these errors were encountered: