Как грамотно настроить общий ресурс между контейнерами?

Question

[Игорь]

Коллеги, здравствуйте!

# Development configuration
version: "3.7"

services:

  # Php application
  app:
    container_name: rapp.app
    restart: on-failure
    build:
      context: .
      dockerfile: ./docker/php/Dockerfile-dev
    volumes:
      - ./:/www/
      - ./docker/php/log:/var/log
      - ./docker/php/usr/local/etc/php/conf.d:/usr/local/etc/php/conf.d
      - type: bind
        source: ./images
        target: /www/images
    depends_on:
      - db
    links:
      - db
    expose:
      - 9000
    environment:
      PHP_INI_SCAN_DIR: ":/usr/local/etc/php/conf.d"
      TZ: "Europe/Moscow"

...

  # Nginx api admin server
  nginx-images:
    container_name: rapp.nginx-images
    restart: on-failure
    image: nginx:latest
    volumes:
      - ./docker/nginx/dev/nginx.conf:/etc/nginx/nginx.conf
      - ./docker/nginx/dev/sites-enabled/vhost-images.conf:/etc/nginx/sites-enabled/vhost-images.conf
      - type: bind
        source: ./images
        read_only: true
        target: /www/images
    ports:
      - 127.0.0.100:8013:80
    depends_on:
      - app
    expose:
      - 80
    command: ["nginx", "-g", "daemon off;"]

Я хочу иметь общую папку между двумя контейнерами.
С помощью данной конфигурации я добился некоторых результатов.
Я имею общий ресурс в виде папки с изображениями.

Но проблема в том, что сервис nginx-images блокирует файл и я не могу изменить его из сервиса app

Получаю сообщение об ошибке.

Warning: unlink(/www/images/1/categories/385d87d3d566437ca99b1161e93d78db-5e406295b30e1.jpeg): Device or resource busy

Есть вероятность что дело не в конфигурации, а nginx что-то делает с моим файлом.

Comments

[Игорь]

Обнаружил, при остановке контейнера nginx-images проблем не наблюдается. Но это же очевидно.

Я пошел дальше, в конфиге nginx изменил корневую папку. Запустил контейнер.
Снова проблем нет. Файлы не блокируются.

Неужели nginx ставит эксклюзивную блокировку на раздаваемый файл?

[Сергей]

Игорь, уверен, докер ни при чём.
Можно легко проверить создав два образа, в которых происходит только чтение файла с общей папки без лочек.

[Игорь]

Сергей, У меня до этого не было проблем, но и я не выполнял unlink файла.

Контейнер номер 1.
В нем я пытаюсь удалить файл

Контейнер номер 2.
Установлен только nginx, который только и делает, что раздаёт статику.

У них общая директория
Условно: /www/images

Самое забавное, что если в браузере не запрашивать изображение, то Контейнер номер 1 без проблем удаляет файл и нет не каких блокировок. Стоит мне в браузере просмотреть это изображения — все, больше я не могу удалить этот файл с контейнера номер 1.

[Игорь]

# Php application
  app:
    container_name: rapp.app
    restart: on-failure
    build:
      context: .
      dockerfile: ./docker/php/Dockerfile-dev
    volumes:
      - ./:/www/
      - ./docker/php/log:/var/log
      - ./docker/php/usr/local/etc/php/conf.d:/usr/local/etc/php/conf.d
      - ./images:/www/images:rw
    depends_on:
      - db
    links:
      - db
    expose:
      - 9000
    environment:
      PHP_INI_SCAN_DIR: ":/usr/local/etc/php/conf.d"
      TZ: "Europe/Moscow"

# ls -l
total 0
-rwxr-xr-x 1 root root  27384 Feb 10 03:10 9d38dd5b8c9e8707913fefe56c889304-5e409f7ccba8c.png
-rwxr-xr-x 1 root root 222764 Feb 10 04:25 ce0f1f370e9884e65e8cc911cb8b93a9-5e40b11173598.jpeg
-rwxr-xr-x 1 root root 222764 Jan  1  1970 ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg
#
#
# unlink ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg
unlink: cannot unlink 'ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg': Device or resource busy

# Nginx api admin server
  nginx-images:
    container_name: rapp.nginx-images
    restart: on-failure
    image: nginx:latest
    volumes:
      - ./docker/nginx/dev/nginx.conf:/etc/nginx/nginx.conf
      - ./docker/nginx/dev/logs/nginx-images:/var/log/nginx
      - ./docker/nginx/dev/sites-enabled/vhost-images.conf:/etc/nginx/sites-enabled/vhost-images.conf
      - ./images:/www/images:ro
    ports:
      - 127.0.0.100:8013:80
    depends_on:
      - app
    expose:
      - 80
    command: ["nginx", "-g", "daemon off;"]

# ls -l
total 0
-rwxr-xr-x 1 root root  27384 Feb 10 00:10 9d38dd5b8c9e8707913fefe56c889304-5e409f7ccba8c.png
-rwxr-xr-x 1 root root 222764 Feb 10 01:25 ce0f1f370e9884e65e8cc911cb8b93a9-5e40b11173598.jpeg
-rwxr-xr-x 1 root root 222764 Jan  1  1970 ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg
#
#
# unlink ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg
unlink: cannot unlink 'ce0f1f370e9884e65e8cc911cb8b93a9-5e40c760c0e92.jpeg': Read-only file system

[Сергей]

Игорь, ну, так, очевидно, что nginx блокирует файл. Как именно - не знаю, это зависит от файловой системы и тех операций, что выполняет nginx. То же самое было бы и без докера, будь эти сервисы соседями на одном сервере.

[Игорь]

Сергей, Круг подозреваемых сужается.
Осталось выяснить, что же делает с моими файлами nginx.

[Сергей]

Я бы начал с "open_file_cache off" в конфиге nginx

[Игорь]

Сергей, Так он же по дефолту off

[Игорь]

server {
    listen                          80;
    client_max_body_size            208M;
    access_log                      /var/log/nginx/images.access.log combined;
    error_log                       /var/log/nginx/images.error.log error;

    location ~ \.(jpg|jpeg|png)$ {
        root                        /www/images;
    }
}

[Сергей]

А какая всё-таки файловая система, где хранятся images? Не NTFS случайно? Или может это SMB Share (CIFS)? На них, насколько я знаю, открытые файлы нельзя удалить.
Ну, и хорошо бы убедиться, что это именно nginx держит эти файлы с помощью чего-то вроде lslocks (внутри контейнера), ведь есть некоторая вероятность, что в используемом контейнере имеется что-то кроме просто nginx.

[Игорь]

Сергей, Файловая система

# df -T
Filesystem     Type          1K-blocks      Used Available Use% Mounted on
overlay        overlay        61255652   2408348  55705972   5% /
tmpfs          tmpfs             65536         0     65536   0% /dev
tmpfs          tmpfs           1018508         0   1018508   0% /sys/fs/cgroup
grpcfuse       fuse.grpcfuse 124372988 113400172  10972816  92% /www
/dev/sda1      ext4           61255652   2408348  55705972   5% /etc/hosts
shm            tmpfs             65536         0     65536   0% /dev/shm
tmpfs          tmpfs           1018508         0   1018508   0% /proc/acpi
tmpfs          tmpfs           1018508         0   1018508   0% /sys/firmware
#

Файлы лежат в /www
Аналогичная в другом контейнере.

Что касается lslocks, он не чего не показал.

Замечу, работаю под Windows 10 pro
Linux containers

[Игорь]

Контейнер в котором находятся изображения
Debian GNU/Linux 10

Контейнер в котором находятся приложение
Ubuntu 18.04.3 LTS

[Игорь]

Сергей, Вы были правы!

В точку
open_file_cache max=100;

Параметр был включен в контексте http.

Выключил
open_file_cache off;

Теперь изображения не блокируются.

[Сергей Соколов]

Просто интересно, как на исходную ситуацию с лочкой файлов NGINX'ом повлияло бы использование вместо маунта папки хоста, полноценного docker Volume?

[Игорь]

OnYourLips,

Логи не надо в тома: они должны быть в stderr/stdout
Конфиги не надо в тома: они должны быть в образе.

Это для разработки.

[Игорь]

OnYourLips, Что-то типа?

RUN ln -sf /dev/stdout /var/log/nginx/access.log \
	&& ln -sf /dev/stderr /var/log/nginx/error.log

[Игорь]

OnYourLips,

access_log                      /dev/stdout combined;
error_log                        /dev/stdout error;

[Сергей]

OnYourLips, конфиги в образ запекать не стоит. Их как раз желательно мапить извне. Почему - детально описано в рамках концепции "12 factor app".

[Игорь]

Сергей, да, согласен.
Это как раз я использую в своем проекте, для разработки.

[Игорь]

Для разработки активно используется Тома.

[Игорь]

OnYourLips, объясните, какие проблемы вызовет фактическое использование файлов конфигурации с помощью томов?

[Сергей]

OnYourLips, где и какие именно строки я пропустил? Я же в свою очередь советую почитать про ConfigMap, это может устранить недопонимание.

Answer 1

[Игорь]

Из документации

Тома, преимущества использования.

• Резервное копирование
  
• Управление с помощью Docker CLI
  
• Тома работают как на Linux, так и на Windows контейнерах.
  
• Тома можно более безопасно разделить между контейнерами
  
• Драйверы томов позволяют хранить тома на удаленных хостах или в облаке, шифровать содержимое томов или добавлять другие функции.
  

Это подходит для моей задачи.
Я работаю над RESTful API и было бы глупо использовать один и тот же сервер для раздачи изображений.
По моему мнению, для раздачи статики лучше выделить отдельный контейнер.

Что касается моей проблемы.
Да, действительно, как я и предполагал в самом начале, nginx блокировал файл.

Отдельное спасибо пользователю Сергей
Его комментарии

Игорь, ну, так, очевидно, что nginx блокирует файл. Как именно - не знаю, это зависит от файловой системы и тех операций, что выполняет nginx. То же самое было бы и без докера, будь эти сервисы соседями на одном сервере.
-------------------------------------------------------------------------------
Я бы начал с "open_file_cache off" в конфиге nginx

Попал в самое сердце проблемы.

Параметр open_file_cache по умолчанию имеет значение off
Но в моём случае он был включен и мел параметры отличные от off

Что касается самого параметра open_file_cache
Синтаксис: open_file_cache off;
open_file_cache max=N [inactive=время];
Умолчание:
open_file_cache off;
Контекст: http, server, location
Задаёт кэш, в котором могут храниться:

• дескрипторы открытых файлов
  
• информация об их размерах и времени модификации
  
• информация о существовании каталогов
  

Всем спасибо.