AWS ElasticBeanstalk докер-тонкий пул стає повноцінним і викликає повторне встановлення файлової системи як лише для читання?

Я не можу зрозуміти, як AWS встановлює свій «тонкий пул» Docker на ElasticBeanstalk і як він заповнюється. Мій тонкий пул докера якимось чином заповнюється і спричиняє збій моїх програм, коли вони намагаються записати на диск.

Це зсередини контейнера:

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

Насправді EBS має диск розміром 25 Гб; 1,6 гб - це те, що 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+ Гб вільного від контейнера, чому він зупиняє нові записи? Наскільки я можу сказати, він не пов'язаний з файлами, в які записуються мої програми.

Дякую!

.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для мене, тож, можливо, це стандарт.

Ми потрапили в той самий випуск. Першопричиною, здається, є те, що Докер не встановлює механізм зберігання даних (тонко передбачений devicemapperза замовчуванням в Elastic Beanstalk) з discardпараметрами, які, в свою чергу, заповнюють блоки, поки вони не ламаються.

Я не зміг знайти певного рішення цього питання, але ось вирішення (див. Цей коментар ), який я зміг використати для постраждалих примірників:

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

Після того, як я додав cronjob для очищення видалених файлів, які більше не використовувалися. Це було потрібно тому, що Докер все ще їх чомусь зберігав. У моєму випадку раз на день цього достатньо. Якщо у вас більше завантажень, ніж у мене, ви можете налаштувати 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 Конфігурація середовища документує, як це працює:

Для покращення продуктивності Elastic Beanstalk налаштовує два томи зберігання Amazon EBS для екземплярів EC2 вашого середовища Docker. На додаток до кореневого обсягу, передбаченого для всіх середовищ Elastic Beanstalk, для зберігання зображень у середовищах Docker передбачений другий об'єм об'ємом 12 Гб на ім'я xvdcz.

Якщо вам потрібно більше місця для зберігання даних або збільшений IOPS для Docker-зображень, ви можете налаштувати об'єм зберігання зображень, використовуючи параметр конфігурації BlockDeviceMapping в aws: автокаслінг: запуск простору імен.

Наприклад, наступний файл конфігурації збільшує об'єм пам’яті до 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бекенд і створює об'єм SSD об'ємом 12 Гб, який він монтує та використовує для зображень докер. Вам слід перекрити гучність, яку він зможе встановити через розширення розширення elabebestalstalk і розгорнути через 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

Я ssh'ed в один з моїх невдалих коробках безпосередньо і виявив, що це піднімається /dev/xvdcz. Для вас це може бути інакше. В snap-066cZZZZZZZZповинен бути дійсним знімок ID. Я створив зображення 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

Вдячні за будь-які коментарі.