AWS ElasticBeanstalk docker-thin-pool变满并导致将文件系统重新挂载为只读吗？

我无法弄清楚AWS如何在ElasticBeanstalk上设置其Docker``瘦池''以及如何填充它。我的docker精简池正在以某种方式填满并导致我的应用程序尝试写入磁盘时崩溃。

这是来自容器内部的：

>df -h
>     /dev/xvda1                  25G  1.4G   24G   6%

实际上，EBS确实分配了25GB的磁盘。1.6 GB是du -sh /返回的内容。

在EC2的外部，它足够无害地启动了...（通过lvs）

LV          VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
docker-pool docker twi-aot--- 11.86g             37.50  14.65

但是，文件系统将很快重新安装为只读。通过dmesg：

[2077620.433382] Buffer I/O error on device dm-4, logical block 2501385
[2077620.437372] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error -28 writing to inode 4988708 (offset 0 size 8388608 starting block 2501632)
[2077620.444394] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error     [2077620.473581] EXT4-fs warning (device dm-4): ext4_end_bio:329: I/O error -28 writing to inode 4988708 (offset 8388608 size 5840896 starting block 2502912)

[2077623.814437] Aborting journal on device dm-4-8.
[2077649.052965] EXT4-fs error (device dm-4): ext4_journal_check_start:56: Detected aborted journal
[2077649.058116] EXT4-fs (dm-4): Remounting filesystem read-only

在EC2实例域中，Docker报告了这一点：（来自docker info）

Pool Name: docker-docker--pool
Pool Blocksize: 524.3 kB
Base Device Size: 107.4 GB
Backing Filesystem: ext4
Data file:
Metadata file:
Data Space Used: 12.73 GB
Data Space Total: 12.73 GB
Data Space Available: 0 B
Metadata Space Used: 3.015 MB
Metadata Space Total: 16.78 MB
Metadata Space Available: 13.76 MB
Thin Pool Minimum Free Space: 1.273 GB

LVS转储此信息：

  --- Logical volume ---
  LV Name                docker-pool
  VG Name                docker
  LV UUID                xxxxxxxxxxxxxxxxxxxxxxxxxxxx
  LV Write Access        read/write
  LV Creation host, time ip-10-0-0-65, 2017-03-25 22:37:38 +0000
  LV Pool metadata       docker-pool_tmeta
  LV Pool data           docker-pool_tdata
  LV Status              available
  # open                 2
  LV Size                11.86 GiB
  Allocated pool data    100.00%
  Allocated metadata     17.77%
  Current LE             3036
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

这个精简池是什么，为什么会填满，如何阻止它呢？另外，如果我的/卷上的容器内部有20 GB以上的可用空间，为什么它会停止新写操作？据我所知，它没有连接到我的程序正在写入的文件。

谢谢！

.ebextensionsDavid Ellis 的建议对我有用。我无法评论他的答案，但我想补充一点，您可以创建一个新的EBS卷，而不必使用快照。要安装40GB EBS卷，我使用了以下命令：

option_settings:
  - namespace: aws:autoscaling:launchconfiguration
    option_name: BlockDeviceMappings
    value: /dev/xvdcz=:40:true

另请参阅本文档，其中包含将新的100GB EBS卷映射到的示例/dev/sdh。

将true在最后的手段“删除终止”。

我创建了一个.ebextensions包含ebs.config上述代码的文件的新目录，然后将该目录与我的目录一起压缩Dockerrun.aws.json。请注意，Dockerrun文件必须位于zip的顶层，而不是子目录中。

要查找Elastic Beanstalk在何处安装卷，请lsblk在发生故障的实例上使用。/dev/xvdcz对我来说也是如此，所以也许这就是标准。

我们也遇到了同样的问题。根本原因似乎是Docker没有使用选项安装其存储引擎（devicemapper默认情况下在Elastic Beanstalk中是自动精简配置的），这些discard选项反过来会填满块直到损坏。

我无法找到一个确定的解决方案，但是这是一个我可以在受影响的实例上使用的变通方法（请参阅此评论）：

docker ps -qa | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/

我遵循了AWS文档上提供的建议，并且现在一切正常。
但是我不得不结合两种解决方案：增加空间并添加cronjob以删除旧文件。
这就是我所做的。

首先，我将卷更改xvdcz为使用50GB而不是12GB。那就是我们可以看到的存储空间docker system info。就我而言，它总是满的，因为我每天都会上传很多文件。

.ebextensions / blockdevice-xvdcz.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:50:true

在我添加了cronjob来清理不再使用的已删除文件之后。这是必需的，因为Docker由于某些原因仍保留它们。就我而言，每天一次就足够了。如果您的上传数量超过我，则可以将cronjob配置为运行所需的次数。

.ebextensions / cronjob.config

files:
    "/etc/cron.d/mycron":
        mode: "000644"
        owner: root
        group: root
        content: |
            0 23 * * * root /usr/local/bin/remove_old_files.sh

     "/usr/local/bin/remove_old_files.sh":
        mode: "000755"
        owner: root
        group: root
        content: |
            #!/bin/bash
            docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ sudo fstrim /proc/Z/root/
            exit 0

 commands:
    remove_old_cron:
        command: "rm -f /etc/cron.d/*.bak"

来源：https : //docs.aws.amazon.com/pt_br/elasticbeanstalk/latest/dg/create_deploy_docker.container.console.html#docker-volumes

AWS elasticbeanstalk docker部分的Environment Configuration记录了其工作原理：

为了提高性能，Elastic Beanstalk为您的Docker环境的EC2实例配置了两个Amazon EBS存储卷。除了为所有Elastic Beanstalk环境预配置的根卷外，还为Docker环境中的映像存储预配置了另一个12GB的卷xvdcz。

如果您需要更多存储空间或增加Docker映像的IOPS，可以使用aws：autoscaling：launchconfiguration命名空间中的BlockDeviceMapping配置选项来自定义映像存储卷。

例如，以下配置文件使用500个预配置的IOPS将存储卷的大小增加到100 GB：

示例.ebextensions / blockdevice-xvdcz.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:100::io1:500

如果使用BlockDeviceMappings选项为应用程序配置其他卷，则应包括xvdcz的映射以确保已创建它。以下示例配置两个卷，具有默认设置的图像存储卷xvdcz和一个名为sdh的附加24 GB应用程序卷：

示例.ebextensions / blockdevice-sdh.config

option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvdcz=:12:true:gp2,/dev/sdh=:24

我花了一天多的时间解决这个问题，终于弄明白了。

AWS正在使用devicemapper后端并创建一个12GB的SSD卷，将其安装并用于Docker映像。您必须覆盖通过elasticbeanstalk扩展概念安装的卷，并通过CLI进行部署（不幸的是，无法通过其GUI进行此操作）。

在拥有Dockerrun.aws.json文件的目录中，创建一个名为的目录.ebextensions，然后创建一个以该文件结尾的文件.config。我打电话给我01.correctebsvolume.config。然后在其中放置以下内容：

option_settings: - namespace: aws:autoscaling:launchconfiguration option_name: BlockDeviceMappings value: /dev/xvdcz=snap-066cZZZZZZZZ:40:true:gp2

我直接把一个失败的盒子塞进盒中，发现它正在安装/dev/xvdcz。您可能会有所不同。该snap-066cZZZZZZZZ需求是一个有效的快照ID。我创建了失败实例的AMI映像，并使用了它在流程中创建的快照。卷的大小40为多少GB，所以请替换您需要的卷。我不知道什么true或gp2做什么，但是它们来自AMI图像块设备数据，因此我保留了它们。

魔术namespace和option_name来自这里的文件中。

仅仅增加磁盘的大小并不能解决问题，稍后只会出错。AWS建议将新磁盘映射到您的容器，以使任何创建文件/删除文件都不会影响Docker Poll层。

我目前正在查看它，尚未进行测试，但是遇到的解决方案是在我的blockdevice.config上安装它

commands:
  01mount:
    command: "mount /dev/sdh /tmp"
option_settings:
  aws:autoscaling:launchconfiguration:
    BlockDeviceMappings: /dev/xvda=:16:true:gp2,/dev/xvdcz=:12:true:gp2,/dev/sdh=:12:true:ephemeral0

感谢任何评论。