☰

Linux + docker 容器文件夹挂载到 OS 卷 + 如何知道真正的限制大小

tag-icon • tag-icon redhat docker containers disk-volume kafka
Linux + docker 容器文件夹挂载到 OS 卷 + 如何知道真正的限制大小

在里面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 docker 容器路径 -/var/lib/kafka/data被挂载到/var/kafka-data，当（/var/kafka-data，是 linux 操作系统的路径）

关于 -/var/kafka-data此挂载点文件夹已挂载到 OS 磁盘 - /dev/sdb而磁盘sdb大小为 - 1.8T byte

让我们总结一下：

/var/lib/kafka/datakafka docker 分区，并且/var仅100G

/var/kafka-data是挂载到 sdb 磁盘的分区（在 Linux 操作系统上）

我想问这个问题以防万一

假设在 kafka docker 分区上 - /var/lib/kafka/data，大小/var/../data大于100G

这是否意味着容器分区/var/lib/kafka/data仅限于100G??

或者/var在kafka docker 容器上限制到外部卷呢1.8T byte？

从 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
.
.
.

答案1

解决该问题的步骤如下（在聊天中讨论）：

  1. 检查相关容器的输出docker inspect。它会产生大量输出，需要考虑的关键部分是Binds和 Mounts部分。
  2. 看到挂载点已就位后，为了避免不匹配的挂载点隐藏实际的数据目标，我们检查容器中创建的文件是否在主机上可见。容器内的一个简单命令（如）就 date > /var/lib/kafka/data/test.txt足以达到目的，并在主机上可见/grid/kafka-data。
  3. 由于有可能 docker 以某种方式在主机上现有的卷挂载点之上挂载了某些东西（我从未见过这种情况，但当它很重要时最好再检查一次），我们在容器中创建一个 400 MiB 的测试文件，如下所示： dd if=/dev/zero of=/var/lib/kafka/data/test.bin count=400 bs=1M
  4. 检查df主机上的输出显示，数据传送到的卷的已用大小增加了约 400 MiB。由于这是针对“正确”挂载点（大小为 1.8T）显示的，因此我们确信写入文件的实际限制是 1.8T。
  5. 之后，测试文件test.bin和test.txt被删除，以避免不必要的文件和空间占用造成系统混乱。

相关内容