In my dockerfile, for a Flask app, I have a set of commands that work as planned. The last line of my dockerfile is currently:
ENTRYPOINT [ "/bin/bash", "-c" ]
I need to launch some gunicorn instances for this image. So, I run the following commands in the terminal, outside the image.
$ docker run -itd --name running_name -p 5000:5000 image_name bash
If I run without bash, I'll just enter exit the container automatically after a few seconds...
$docker container exec -it running_name /bin/bash -c bash
Now that I'm in, I launch the gunicorn instances, and do docker exit. Because of exec, the instances are still running.
Is there a way to launch the gunicorn instances from docker run, without having to enter into the container?
I've tried ENTRYPOINT [ "gunicorn", "--bind", "0.0.0.0:5000" ]
but I still exit automatically
I've also tried substituting the last line for CMD gunicorn --bind 0.0.0.0:5000
and then do docker run -d --name run_name -p 5000:5000 image_name
I still exit automatically.
Edit: To reflect the possible answer below, here's my updated tries and extra information.
The following files are all at the same level of the directory structure.
In the api_docker.py file, I have:
app = Flask(__name__)
api = Api(app)
api.add_resource(<some_code>)
In the gunicorn.conf.py file, I have:
worker_class = "gevent"
workers = 2
timeout = 90
bind = "0.0.0.0:5000"
wsgi_app = "wsgi:app"
errorlog = "logging/error.log"
capture_output = True
loglevel = "debug"
daemon = True
enable_stdio_inheritance = True
preload = True
I've also tried removing the bind and wsgi_app rows, from this file.
In the dockerfile:
<some_code>
CMD ["gunicorn", "--conf", "gunicorn.conf.py", "--bind", "0.0.0.0:5000", "api_docker:app"]
I build successfully, and then I do:
docker run -d --name name_run -p 5000:5000 name_image
To solve this issue, I did the following:
daemon
, enable_stdio_inheritance
, and preload
from the conf file.timeout
and graceful timeout
parameters to 120.CMD ["gunicorn"]
.I think the most important change was that of point 1, namely the daemon to false(which is the default), not sure why though... I would guess that as a daemon process, the docker container would not monitor it correctly and just exit.