-
-
Notifications
You must be signed in to change notification settings - Fork 284
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
Kill container on app start fail #61
Comments
If you are using an orchestrator like Kubernetes, you can add some liveness probe that will restart the container if either nginx or uwsgi is not working. In any case, you can override the supervisor configuration file in your image to fit your needs! I've been myself thinking of an even more extreme solution for some time now: have a dedicated nginx container and a dedicated uwsgi container. This way, it is atomic. But I haven't done it because... this image simply works for our use case and is easily debuggable. |
Made the simple required steps to make image crash on app fail: |
Thanks for the discussion everyone! And thanks for the example @ReallyLiri. I implemented it here: #110 The only caveat is that currently, Supervisor terminates "cleanly", with a But for this specific issue, I hope that PR and the latest version of the image would handle it. |
Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues. |
I read this issue: tiangolo/uwsgi-nginx-flask-docker#3
It seems that setting
need-app = true
is not enough to kill the container, as supervisor keeps on restarting the app.Please consider adding
autoresetart=false
insupervisord.conf
section foruwsgi
, or to make these easily configurable in other some way.To have supervisor actually kill the container you'd have to set up some more configuration, see:
https://serverfault.com/questions/760726/how-to-exit-all-supervisor-processes-if-one-exited-with-0-result
The text was updated successfully, but these errors were encountered: