а он ссылка на /dev/stdout

ЭТО ПРАВИЛЬНО

и так

это работает в дефолтном образе nginx

и файл on не будет создаваться?

access_log off; - у тебя выключает логи, если ты комментишь данную строчку и указываешь access_log on; то вероятнее всего у тебя будет писаться в лог /etc/nginx/on, потому тебе просто надо указать путь до файла как сказали выше

access_log off; - у тебя выключает логи, если ты комментишь данную строчку и указываешь access_log on; то вероятнее всего у тебя будет писаться в лог /etc/nginx/on, потому тебе просто надо указать путь до файла как сказали выше

так путь до файла же укказан как access_log /var/log/nginx/access.log main;

еще раз

у тебя образ чей?

если штатный, то ОНО ПО УМОЛЧАНИЮ ШЛЕТ В стдаут

т.к. /var/log/nginx/access.log ссылка на /dev/stdout

и ничего тебе менять не надо

и даже противопоказано

а если не штатный? Внутри Dockerfil сделать ссылку вручную?

а если не штатный, то я не телепат и не знаю что тебе нужно. Лучше - сделать как в штатном, если у тебя нет супервизора

если есть отдельный супервизор, то все сложнее, но все еще реализуемо

а от nginx такие логи: failed (111: Connection refused) while connecting to upstream,

а от nginx такие логи: failed (111: Connection refused) while connecting to upstream,

значит твой апстрим в конфиге куда ты хочешь проксировать трафик недоступен

значит твой апстрим в конфиге куда ты хочешь проксировать трафик недоступен

там указан адрес и порт контейнера с uwsgi

ну выходит что из контейнера где у тебя nginx твой контейнер с uwsgi недоступен 🙂

если локально то делай лучше link до него наверное и в апстримах просто имя указывай до контейнера а не ip

если локально то делай лучше link до него наверное и в апстримах просто имя указывай до контейнера а не ip

таки и было, имя контейнера с uwsgi и порт name_uwsgi:port

и такая хрень постоянно при остановоке:

ERROR: for docker_nginx_1 UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70) ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information. If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).

приходится каждый раз в top убивать процессы вручную

и занова собирать, почему не останавливается по нормальному?

тебе предложил вариант

нода не вывозит нагрузки

что за параметры у ноды? версии софта?

в htop ресурсы доступные

и что?

Docker version 18.09.7

и что?

как тогда она нагрузки не выдерживает, если нагрузки нет в htop?

ты не рассказал что за конфигурация

и при запуске docker-compose Cannot start service nginx: OCI runtime create failed: container with id exists:, хотя в docker ps ничего не было запущено

ты не рассказал что за конфигурация

nginx контейнер, redis, uwsgi

и php

и при запуске docker-compose Cannot start service nginx: OCI runtime create failed: container with id exists:, хотя в docker ps ничего не было запущено

зато может уже существовать до этого, если ты сбилдил ранее, смотри все контейнеры с ключом a ps -a

зато может уже существовать до этого, если ты сбилдил ранее, смотри все контейнеры с ключом a ps -a

тогда docker-compose up --build один раз делается? Потом только docker-compose up ?

Коллеги, кто-нибудь сталкивался с подобным поведением при docker push ? Server Version: 1.13.1 ps. Registry добавлен в настройках как insecure: https://paste.ubuntu.com/p/y853YBGFCJ/

тогда docker-compose up --build один раз делается? Потом только docker-compose up ?

ну у него состояние эфимерное вроде как, потому его надо пересоздавать если ты обновился попробуй почитать, что то есть вроде типо --force-recreat может щяс более знающие подскажут

@tfhx8 возможно такое docker-compose up --force-recreate --build

Да, при этом docker login и docker pull работают исправно =(

Коллеги, кто-нибудь сталкивался с подобным поведением при docker push ? Server Version: 1.13.1 ps. Registry добавлен в настройках как insecure: https://paste.ubuntu.com/p/y853YBGFCJ/

что такое 1.13?

а клиент какой?

а клиент какой?

это выхлоп docker info

$ docker info Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 3 Server Version: 1.13.1 Storage Driver: overlay2 Backing Filesystem: xfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: systemd Plugins: Volume: local Network: bridge host macvlan null overlay Swarm: inactive Runtimes: docker-runc runc Default Runtime: docker-runc Init Binary: /usr/libexec/docker/docker-init-current containerd version: (expected: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1) runc version: 9c3c5f853ebf0ffac0d087e94daef462133b69c7 (expected: 9df8b306d01f59d3a8029be411de015b7304dd8f) init version: fec3683b971d9c3ef73f284f176672c44b448662 (expected: 949e6facb77383876aeff8a6944dde66b3089574) Security Options: seccomp WARNING: You're not using the default seccomp profile Profile: /etc/docker/seccomp.json Kernel Version: 3.10.0-862.3.2.el7.x86_64 Operating System: CentOS Linux 7 (Core) OSType: linux

это выхлоп docker info

какой-то очень... обрезанный выхлоп. Но вообще 1.13 версия времен мамонта

О_О

центос. Тогда, значит, бекпорты могут быть

с этим все работает

docker --version Docker version 1.13.1, build 7f2769b/1.13.1

но можешь поставить из репы докера более свежий.... если хочешь

там все пакеты такие) центос ж) Думаешь беда в старой версии?

это не старая версия, а.... кхм... альтернативная.... в авторском видении центос

У меня перед регистри лоад балансер (AWS), думаю в нем беда

не пойму как отдебажить что происходит на клиенте (какие запросы и куда он шлет)

не пойму как отдебажить что происходит на клиенте (какие запросы и куда он шлет)

Если это натив, то, берём нативный дебаггер, тот же gdb, и поехали прямс консоли.

парни пытаюсь поднять докер образ для работы с php, пробую разные готовые имейджи ( php:latest , phpunit/phpunit:latest , phpdockerio/php71-cli:latest ) и везде результат один и тот же - контейнер сразу же умирает, в логе только Interactive mode enabled или Interactive shell , запускаю простой командой docker run --name php_test6 -d *ВЕРСИЯ* , дошёл до того что скачал голой образ centos который также не хочет подниматься ( docker run centos:7.6.1810 ) , также падает сразу же, а в логе вообще пустота, не пойму куда копать? есть мысли? старые контейнеры работают корректно

зашел внутри контейнера запустил uwsgi на другом порту по 0.0.0.0:1234 далее в этом же контейнере открываю этот адрес в браузере через links и он выдает error reading from socket

Это проблема с сетью или с докером глюки?

зашел внутри контейнера запустил uwsgi на другом порту по 0.0.0.0:1234 далее в этом же контейнере открываю этот адрес в браузере через links и он выдает error reading from socket

Не пользуй Линкс. Все у тебя не по феншую

на хз что за хрень такая)). Было все нормально. Последние 3 дня такая хрень

не пойму как отдебажить что происходит на клиенте (какие запросы и куда он шлет)

на клиенте ты и не узнАешь, куда балансер направляет запрос

парни пытаюсь поднять докер образ для работы с php, пробую разные готовые имейджи ( php:latest , phpunit/phpunit:latest , phpdockerio/php71-cli:latest ) и везде результат один и тот же - контейнер сразу же умирает, в логе только Interactive mode enabled или Interactive shell , запускаю простой командой docker run --name php_test6 -d *ВЕРСИЯ* , дошёл до того что скачал голой образ centos который также не хочет подниматься ( docker run centos:7.6.1810 ) , также падает сразу же, а в логе вообще пустота, не пойму куда копать? есть мысли? старые контейнеры работают корректно

перезагружаться пробовал? 😂

Не пользуй Линкс. Все у тебя не по феншую

причем внутри контейнера netstat показывает этот слушающйи порт, пробую чере 0.0.0.0 и 127.0.0.1 но ничего не происходит, в links висит и внизу надпись Request sent. Что то не дает запросу пройти. Толи какойто блокировщик докера толи еще что то

перезагружаться пробовал? 😂

а то, и сервис, и сервер ща рестартанул думаю обновление может поможет

ща попробую

на втором сервере тоже самое, docker run -d centos:7.6.1810 сразу умирает без каких либо претензий

может кто нить проверить? возможно общая проблема?

на втором сервере тоже самое, docker run -d centos:7.6.1810 сразу умирает без каких либо претензий

Что умирает ?

У него же баш в энтрипойнт

Так и задумано - конткйнер сделал свою работу - будет убит

Так и задумано - конткйнер сделал свою работу - будет убит

хм, а чтобы контейнер работал? хочу запускать тесты в отдельном контейнере, мне надо свой имейдж тогда полностью писать?

хм, а чтобы контейнер работал? хочу запускать тесты в отдельном контейнере, мне надо свой имейдж тогда полностью писать?

Для начала пойми - есть два режима работы. Контейнер как штука, которая выполнилась и все. И контейнер как сервис.

Разница по сути только в энтрипойнт

Для начала пойми - есть два режима работы. Контейнер как штука, которая выполнилась и все. И контейнер как сервис.

спасибо!

docker ps и docker ps -a показывает пустоту. Если открыть htop, то там куча процессов с nginx и uwsgi . Как такое может быть? Я же завершил все контейнеры?

docker ps и docker ps -a показывает пустоту. Если открыть htop, то там куча процессов с nginx и uwsgi . Как такое может быть? Я же завершил все контейнеры?

в каком они статусе?

в каком они статусе?

D

в htop