AWS ElasticBeanstalk docker-thin-pool переполняется и вызывает перемонтирование файловой системы как доступной только для чтения?

В .ebextensions предложенный Дэвидом Эллисом работал у меня. Я не могу комментировать его ответ, но я хотел добавить, что вы можете создать новый том EBS вместо использования снимка. Чтобы смонтировать том EBS объемом 40 ГБ, я использовал следующее:

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

Смотрите также эта документация, в котором есть пример сопоставления нового тома EBS объемом 100 ГБ с /dev/sdh.

В true в конце означает «удалить при завершении».

Я создал новый .ebextensions каталог, содержащий ebs.config файл с приведенным выше кодом, затем заархивировал этот каталог вместе с моим Dockerrun.aws.json. Обратите внимание, что файл Dockerrun должен находиться на верхнем уровне zip-архива, а не внутри подкаталога.

Чтобы найти место, где крепится том Elastic Beanstalk, используйте lsblk на отказавшем экземпляре. Это также /dev/xvdcz для меня, так что, может быть, это стандарт.

У нас возникла та же проблема. Основная причина заключается в том, что Docker не монтирует свой механизм хранения (с тонким предоставлением devicemapper по умолчанию в Elastic Beanstalk) с discard options, который, в свою очередь, заполняет блоки до тех пор, пока не сломается.

Я не смог найти однозначного решения для этого, но вот обходной путь (см. этот комментарий), который я смог использовать на затронутых экземплярах:

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

Я последовал предложениям, представленным в документации AWS, и теперь все работает.
Но мне пришлось объединить два решения: увеличить пространство и добавить cronjob для удаления старых файлов.
Вот что я сделал.

Сначала поменял громкость xvdcz использовать 50 ГБ вместо 12 ГБ. Это хранилище, которое мы видим на docker system info. В моем случае он всегда был заполнен, потому что я каждый день загружаю много файлов.

.ebextensions / blockdevice-xvdcz.config

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

После того, как я добавил задание cron для очистки удаленных файлов, которые больше не использовались. Это было необходимо, потому что Docker по какой-то причине все еще хранил их. В моем случае достаточно одного раза в день. Если у вас больше загрузок, чем у меня, вы можете настроить задание cron на запуск столько раз, сколько вам нужно.

.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 Конфигурация среды документы, как это работает:

Для повышения производительности Elastic Beanstalk настраивает два тома хранения Amazon EBS для экземпляров EC2 вашей среды Docker. В дополнение к корневому тому, предоставленному для всех сред Elastic Beanstalk, второй том размером 12 ГБ с именем xvdcz выделен для хранения образов в средах Docker.

Если вам нужно больше места для хранения или увеличенное количество операций ввода-вывода в секунду для образов Docker, вы можете настроить объем хранилища образов с помощью параметра конфигурации BlockDeviceMapping в пространстве имен aws: autoscaling: launchconfiguration.

Например, следующий файл конфигурации увеличивает размер тома хранилища до 100 ГБ с 500 предоставленными IOPS:

Пример .ebextensions / blockdevice-xvdcz.config

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

Если вы используете опцию BlockDeviceMappings для настройки дополнительных томов для вашего приложения, вы должны включить отображение для xvdcz, чтобы гарантировать его создание. В следующем примере настраиваются два тома: том для хранения изображений xvdcz с настройками по умолчанию и дополнительный том приложения объемом 24 ГБ с именем sdh:

Пример .ebextensions / blockdevice-sdh.config

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

Я бился головой об этой проблеме больше суток и наконец понял ее.

AWS использует devicemapper backend и создает том SSD объемом 12 ГБ, который монтирует и использует для образов докеров. Вы должны переопределить том, который он будет монтировать с помощью концепции расширений elasticbeanstalk, и развернуть через интерфейс командной строки (к сожалению, нет способа сделать это через их графический интерфейс).

В каталоге у вас есть 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 должен быть действительным идентификатором снимка. Я создал образ AMI отказавшего экземпляра и использовал снимок, который он создал в процессе. В 40 сколько ГБ будет в томе, поэтому подставьте то, что вам нужно. Я не знаю что true или gp2 есть, но они взяты из данных устройства блока изображений AMI, поэтому я их сохранил.

Магия namespace и option_name родом из Вот в документации.

Простое увеличение размера диска не решит проблему, позже произойдет ошибка. AWS рекомендует сопоставить новый диск с вашим контейнером, чтобы любой файл создания / удаления не влиял на уровень опроса Docker.

Я сейчас смотрю на него, я еще не тестировал, но решение, с которым я столкнулся, имеет это на моем 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

Ценю любые комментарии.