Как я понимаю ведение журнала ENTRYPOINT, используя Flask внутри Docker - PullRequest
Новая
       13

Как я понимаю ведение журнала ENTRYPOINT, используя Flask внутри Docker

0 голосов
/ 18 апреля 2020

Мой Docker контейнер запускает gunicorn, который указывает на «myapp.py», который использует flask. 

cat Dockerfile:

FROM python:3.7

<snip no important>

USER nobody
ENTRYPOINT ["/usr/sbin/flask-docker-entrypoint.sh"]
EXPOSE 8000

flask - docker - точку входа. sh : 

#!/bin/bash
/usr/local/bin/gunicorn myapp:app -c /local/gunicorn.conf.py

Все работает хорошо!

Docker В логе демона установлено значение 'json / file'. Я передаю журнал Gunicorn на стандартный вывод (версия 20 по умолчанию). Я могу отправлять журналы из myapp.py в «docker logs» с помощью простых операторов регистрации. Почему это так? 

ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
nobody       1     0  0 22:01 ?        00:00:00 /bin/bash /usr/sbin/flask-docker-entrypoint.sh
nobody      12     1  0 22:01 ?        00:00:00 /usr/local/bin/python /usr/local/bin/gunicorn myapp:app -c /external/
nobody      15    12  0 22:01 ?        00:00:00 /usr/local/bin/python /usr/local/bin/gunicorn myapp:app  -c /external/
nobody      57     0  7 22:44 pts/0    00:00:00 bash
nobody      62    57  0 22:44 pts/0    00:00:00 ps -e

flask - docker -входная точка. sh - это pid 1, чтобы протоколировать в стандартный вывод. Получить это. Все ли потомки pid, использующие точку входа, также наследуют возможность входа в stdout? Кажется, что gunicorn - это не pid 1, а myapp.py - это не pid 1, но оба они входят в стандартный вывод?

Спасибо

1 Ответ

1 голос
/ 18 апреля 2020

Поведение по умолчанию в Unix -подобных средах заключается в том, что процесс наследует stdout своего родителя (и stdin и stderr). Вы можете легко продемонстрировать это в своей локальной оболочке: 

#!/bin/sh
# This is script1
./script2

#!/bin/sh
# This is script2
echo hi there

$ ./script1
hi there
$ ./script1 > log
$ cat log
hi there

В последнем примере, если вывод script1 поступает на консоль или перенаправляется в файл журнала, когда он запускает script2 как подпроцесс, он наследует тот же стандартный вывод.

Причина gunicorn не в pid 1 в том, что у вас есть оболочка оболочки. Вы можете использовать встроенную оболочку exe c, чтобы заменить процесс оболочки тем, что он хочет запустить 

#!/bin/sh
exec /usr/local/bin/gunicorn myapp:app -c /local/gunicorn.conf.py

Если вам не нужно больше настраивать, это может быть Проще поместить команду прямо в Dockerfile. (CMD легче переопределить во время выполнения для выполнения таких операций, как получение отладочных оболочек, если вам нужно; это заменяет существующую строку ENTRYPOINT.) 

CMD ["gunicorn", "myapp:app", "-c", "/local/gunicorn.conf.py"]
...