stable-diffusion-webui-docker
stable-diffusion-webui-docker copied to clipboard
[Feature] Docker style entrypoint for auto
This issue addresses PR https://github.com/AbdBarho/stable-diffusion-webui-docker/pull/157 I would like to discuss here about a need to clean up some things about docker.
First of all, I believe that docker should be treated as wrapper around original app providing proper environment and tools to easily maintain and setup application.
One of main things is separation between CMD (which should be treated like commandline to start original app without docker), and ENTRYPOINT which should be place where docker related stuff is prepared (like things from mount.sh file in this very repository).
I've prepared simple ENTRYPOINT script that starts smaller scripts from entrypoint.d directory and allows to better "decorate" container before original application starts.
Also there is unclear for me what are current expectations after https://github.com/AbdBarho/stable-diffusion-webui-docker/pull/157#issuecomment-1286418811 - whether shall I close this PR or leave it like it is right now?
Best regards
First of all, I believe that docker should be treated as wrapper around original app providing proper environment and tools to easily maintain and setup application.
agree
One of main things is separation between CMD (which should be treated like commandline to start original app without docker), and ENTRYPOINT which should be place where docker related stuff is prepared (like things from mount.sh file in this very repository).
true
I've prepared simple ENTRYPOINT script that starts smaller scripts from entrypoint.d directory and allows to better "decorate" container before original application starts. Also there is unclear for me what are current expectations after https://github.com/AbdBarho/stable-diffusion-webui-docker/pull/157#issuecomment-1286418811 - whether shall I close this PR or leave it like it is right now?
What "scares" me in #157 is that it is too boilerplate-y, also, I prefer to exit on error rather than start incorrectly, It should fail if a file is not a script, it should fail if its not executable, and it should fail if one the scripts fails. Maybe like:
set -ceuxo pipefail
find /docker/docker-entrypoint.d/ -follow -type f -print | sort -V | while read -r f; do
set -ceuxo pipefail
"$f"
done;
exec "$@"
it is too boilerplate-y Universal "devil you know". It is mostly based on ENTRYPOINT used in
nginximages. Most of entrypoint scripts I've encountered do not give much flexibility when extending image. Here you can add other small scripts that run between any two existing ones without the need to rewrite entire entrypoint script from scratch (providing original set of scripts in entrypoint.d directory was not a mess to start with).
Also following code is not possible in /bin/sh.
set -ceuxo pipefail
Maybe it's only my paranoia, but I do not trust set -ceuxo pipefail blindly. Curious why? https://mywiki.wooledge.org/BashFAQ/105 and because I've spent too many hours debugging somebody else's code I know things mentioned there will eventually happen sooner or later :-)
@DevilaN if you have any other alternatives that do not require checking every single command manually, I am glad to learn, otherwise, might as well just write the app in go
@AbdBarho, sorry but there is no other alternatives I know about. I prefer scripts to be small, easy to maintain and well planned. This lowers possibility of failures, but nonetheless this does not guarantee bulletproof entrypoint scripts, and I don't think that there is anything that would.
(Who knows... maybe in some near feature there will be Stable Diffusion for computer code, and it would be a matter of prompt: docker entrypoint script, bulletproof, trending on gitstation, in camelcase style, greg rutkowski negative prompt: copy-paste, stack overflow, tabspace, spaghetti code, vt80, powershell ;-) )
Newly implemented entrypoint.sh conflicts with this request, so I won't push it.