Linux + папка контейнера докеров, подключенная к тому ОС + как узнать реальный ограниченный размер

внутри docker-compose.yml мы настроили следующий том

image: confluentinc/cp-kafka:latest
volumes:
  - /grid/kafka-data:/var/lib/kafka/data

.

docker-compose ps
               Name                           Command            State                     Ports
-------------------------------------------------------------------------------------------------------------------
kafka-node_kafka_1            /etc/confluent/docker/run   Up      0.0.0.0:9092->9092/tcp

из моего понимания - путь к контейнеру докеров kafka - / var / lib / kafka / data монтируется в / var / kafka-data , когда ( / var / kafka-data - это путь к ОС Linux)

О программе - / var / kafka-data эта папка точки монтирования монтируется на диск ОС - / dev / sdb , а размер диска sdb - 1,8 ТБ байт

Итак, подводим итоги:

/ var / lib / kafka / data раздел докеров kafka и / var только 100G

/ var / kafka-data - это раздел, который смонтирован на sdb-диск (в ОС Linux)

Я хочу спросить этот вопрос на всякий случай

Допустим, раздел докеров kafka - / var / lib / kafka / data , размер / var /../ data больше затем 100 ГБ

Означает ли это, что раздел контейнера / var / lib / kafka / data ограничен 100 ГБ ??


Или / var в контейнере докеров kafka ограничено Внешним томом, который составляет 1,8 ТБ байт ?

Со стороны контейнера kafka мы имеем:

# df -h /var
Filesystem      Size  Used Avail Use% Mounted on
overlay         101G  7.5G   94G   8% /


df -h  /var/lib/kafka/data/
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/os-rhel_root   101G  7.5G   94G   8% /var/lib/kafka/data

Находясь снаружи от контейнер - в реальной ОС Linux у нас есть

df -h

Filesystem                Size  Used Avail Use% Mounted on
/dev/mapper/os-rhel_root  50G  5.3G   45G   11% /
devtmpfs                  12G     0  12G    0% /dev
tmpfs                     12G   156K  12G   1% /dev/shm
/dev/sdb                  1.8T   77M  1.8T   1% /grid/kafka-data
/dev/sda1                 492M  158M  335M  32% /boot
/dev/mapper/os-rhel_var   106G   11G   96G  10% /var
tmpfs                      26G     0   26G   0% /run/user/1005
tmpfs                      26G   20K   26G   1% /run/user/0
overlay                   101G  7.5G   94G   8% /var/lib/docker/overlay2/8411835673dfedd5986093eb771582dac7317d99f431b832f3baea8ea1aa3e4d/merged
shm                        64M     0   64M   0% /var/lib/docker/containers/629aefd21b6042ebfbf1a0a08a882b2f1865137edfb4b2b02f5c9a1681d895e4/mounts/shm
overlay                   101G  7.5G   94G   8% /var/lib/docker/overlay2/b4677bed14050337580958bc903bbb733d9464ca8bfc46124c3c506dc064867d/merged
.
.
.
2
задан 6 November 2019 в 15:04
1 ответ

Шаги для разрешения этого вопроса были следующим образом (обсуждены в чате):

  1. Проверка вывода docker inspect для рассматриваемого контейнера. Это производит большой вывод, ключевые роли для рассмотрения Binds и Mounts разделы.
  2. видевший монтирование на месте, чтобы не иметь несоответствие монтирует сокрытие фактических данных destionations, мы делаем проверку, чтобы видеть, что файлы, которые создаются в контейнере, видимы на хосте. Простая команда в контейнере как date > /var/lib/kafka/data/test.txt достаточна для цели и становится видимой под /grid/kafka-data на хосте.
  3. Как существует немного шанса, что так или иначе докер смонтировал, что что-то выше существующего объема монтируется на хосте (я никогда не видел, что, но то, когда это - важное, могло бы лучше проверить дважды), мы создаем тестовый файл 400 мебибайт в контейнере следующим образом: dd if=/dev/zero of=/var/lib/kafka/data/test.bin count=400 bs=1M
  4. Проверка эти df вывод на хосте показывает увеличение используемого размера ~400 мебибайт для объема, в который перешли данные. Поскольку это отображено для "корректной" точки монтирования (с 1.8T размер), мы уверены, что фактический предел для записи файлов 1.8T.
  5. Впоследствии, тестовые файлы test.bin и test.txt удалены, чтобы не создавать помехи системе ненужными файлами и использованием пространства.
0
ответ дан 3 December 2019 в 13:39

Теги

Похожие вопросы