¿AWS ElasticBeanstalk docker-thin-pool se llena y provoca el remontaje del sistema de archivos como de solo lectura?

No puedo entender cómo AWS configura su 'grupo delgado' de Docker en ElasticBeanstalk y cómo se está llenando. Mi grupo delgado de docker se está llenando de alguna manera y haciendo que mis aplicaciones se bloqueen cuando intentan escribir en el disco.

Esto es desde el interior del contenedor:

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

El EBS, de hecho, tiene un disco de 25GB asignado; 1.6 gb es lo que du -sh /regresa.

Afuera en EC2, comienza de manera bastante inocua ... (a través de 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

Sin embargo, el sistema de archivos pronto se volverá a montar como de solo lectura. a través de 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

De vuelta en EC2 instancia-tierra, Docker informa esto: (desde 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 volca esta información:

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

¿Qué es este grupo delgado, por qué se llena y cómo evito que lo haga? Además, si tengo más de 20 GB libres dentro del contenedor en mi / volumen, ¿por qué detiene las nuevas escrituras? Por lo que puedo decir, no está conectado a archivos en los que están escribiendo mis programas.

¡Gracias!

Lo .ebextensionssugerido por David Ellis funcionó para mí. No puedo comentar su respuesta, pero quería agregar que puede crear un nuevo volumen de EBS en lugar de usar una instantánea. Para montar un volumen EBS de 40 GB, utilicé lo siguiente:

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

Consulte también esta documentación , que tiene un ejemplo de asignación de un nuevo volumen EBS de 100 GB /dev/sdh.

Al truefinal significa "eliminar al terminar".

Creé un nuevo .ebextensionsdirectorio que contiene un ebs.configarchivo con el código anterior, luego comprimí ese directorio junto con mi Dockerrun.aws.json. Tenga en cuenta que el archivo Dockerrun debe estar en el nivel superior del zip, no dentro de un subdirectorio.

Para encontrar dónde Elastic Beanstalk está montando el volumen, utilícelo lsblken la instancia anómala. También fue /dev/xvdczpara mí, así que tal vez ese es el estándar.

Nos golpeó el mismo problema. La causa raíz parece ser que Docker no está montando su motor de almacenamiento (provisto devicemapperpor defecto en Elastic Beanstalk) con las discardopciones, que a su vez llena los bloques hasta que se rompe.

No pude encontrar una solución definitiva para esto, pero aquí hay una solución (ver este comentario ) que pude usar en las instancias afectadas:

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

Seguí las sugerencias proporcionadas en la documentación de AWS y todo está funcionando ahora.
Pero tuve que combinar dos soluciones: aumentar el espacio y agregar cronjob para eliminar archivos antiguos.
Esto es lo que hice.

Primero, cambié el volumen xvdczpara usar 50 GB en lugar de 12 GB. Ese es el almacenamiento que podemos ver docker system info. En mi caso, siempre estaba lleno porque subo muchos archivos todos los días.

.ebextensions / blockdevice-xvdcz.config

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

Después agregué un cronjob para limpiar mis archivos eliminados que ya no se usaban. Fue requerido porque Docker todavía los guardaba por alguna razón. En mi caso, una vez al día es suficiente. Si tiene más cargas que yo, puede configurar el cronjob para que se ejecute cuantas veces lo necesite.

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

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

La sección acoplable AWS elasticbeanstalk Configuración del entorno documenta cómo funciona:

Para mejorar el rendimiento, Elastic Beanstalk configura dos volúmenes de almacenamiento de Amazon EBS para las instancias EC2 de su entorno Docker. Además del volumen raíz aprovisionado para todos los entornos de Elastic Beanstalk, se aprovisiona un segundo volumen de 12 GB denominado xvdcz para el almacenamiento de imágenes en entornos Docker.

Si necesita más espacio de almacenamiento o IOPS aumentadas para las imágenes de Docker, puede personalizar el volumen de almacenamiento de imágenes mediante la opción de configuración BlockDeviceMapping en el espacio de nombres aws: autoscaling: launchconfiguration.

Por ejemplo, el siguiente archivo de configuración aumenta el tamaño del volumen de almacenamiento a 100 GB con 500 IOPS aprovisionados:

Ejemplo .ebextensions / blockdevice-xvdcz.config

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

Si usa la opción BlockDeviceMappings para configurar volúmenes adicionales para su aplicación, debe incluir una asignación para xvdcz para asegurarse de que se cree. El siguiente ejemplo configura dos volúmenes, el volumen de almacenamiento de imágenes xvdcz con la configuración predeterminada y un volumen de aplicación adicional de 24 GB llamado sdh:

Ejemplo .ebextensions / blockdevice-sdh.config

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

Me golpeé la cabeza contra este problema durante más de un día y finalmente lo descubrí.

AWS está utilizando el devicemapperbackend y crea un volumen SSD de 12 GB que se monta y utiliza para las imágenes de la ventana acoplable. Debe anular el volumen que montaría a través del concepto de extensiones elasticbeanstalk e implementar a través de la CLI (desafortunadamente no hay forma de hacerlo a través de su GUI).

En el directorio donde tiene su Dockerrun.aws.jsonarchivo, cree un directorio llamado .ebextensionsy luego cree un archivo que termine .configdentro de él. Yo llamé al mío 01.correctebsvolume.config. Luego ponga los siguientes contenidos allí:

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

Me metí en uno de mis fallos en caja directamente y descubrí que se estaba acumulando /dev/xvdcz. Se puede ser diferente para usted. Las snap-066cZZZZZZZZnecesidades a ser un ID instantánea válida. Creé una imagen AMI de la instancia anómala y utilicé la instantánea que creó en el proceso. Esta 40es la cantidad de GB que tendrá el volumen, así que sustituya lo que necesita. No sé qué hacer trueo gp2hacer, pero vinieron de los datos del dispositivo de bloqueo de imagen AMI, así que los guardé.

La magia namespaceya option_nameviene de aquí en la documentación.

El simple aumento del tamaño del disco no resolverá el problema, solo se producirá un error más tarde. AWS recomienda asignar un nuevo disco a su contenedor para que cualquier archivo de creación / eliminación no afecte a la capa de encuestas de Docker.

Actualmente lo estoy buscando, aún no lo he probado, pero la solución que encuentro es tener esto en mi 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

Agradezco cualquier comentario.