O docker-thin-pool do AWS ElasticBeanstalk ficando cheio e causando a reinstalação do sistema de arquivos como somente leitura?

Question

Não consigo descobrir como a AWS configura o "thin pool" do Docker no ElasticBeanstalk e como ele está sendo preenchido. Meu pool thin docker está se enchendo de alguma forma e fazendo com que meus apps travem quando tentam gravar no disco.

Isso é de dentro do contêiner:

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

O EBS possui, de fato, um disco de 25 GB distribuído para ele; 1.6 gb é o que du -sh / retorna.

Fora do EC2, ele começa inofensivamente ... (via 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

No entanto, o sistema de arquivos será montado novamente como somente leitura. via 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

Volte para fora em terra de instância do EC2, o Docker relata isso: (de 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

O LVS despeja esta informação:

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

O que é esse pool thin, por que ele é preenchido e como posso impedir isso? Além disso, se eu tiver mais de 20 GB de dentro do contêiner no meu / volume, por que ele interrompe novas gravações? Tanto quanto eu posso dizer que não está conectado a arquivos que meus programas estão escrevendo para.

Obrigado!

    

Answer 1

O .ebextensions sugerido por David Ellis funcionou para mim. Não consigo comentar sua resposta, mas queria acrescentar que você pode criar um novo volume de EBS em vez de usar um instantâneo. Para montar um volume de 40 GB do EBS, usei o seguinte:

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

Veja também esta documentação , que tem um exemplo de mapeamento de um novo volume de 100 GB do EBS para /dev/sdh .

O true no final significa "excluir ao terminar".

Eu criei um novo diretório .ebextensions contendo um arquivo ebs.config com o código acima e, em seguida, fechei esse diretório junto com meu Dockerrun.aws.json . Observe que o arquivo Dockerrun deve estar no nível superior do zip, não dentro de um subdiretório.

Para descobrir onde o Elastic Beanstalk está montando o volume, use lsblk na instância com falha. Também foi /dev/xvdcz para mim, então talvez esse seja o padrão.

    

Answer 2

Nós fomos atingidos pelo mesmo problema. A causa raiz parece ser o Docker não montando seu mecanismo de armazenamento (thin-provisioned devicemapper por padrão no Elastic Beanstalk) com as opções discard , que por sua vez preenchem os blocos até que ele quebre.

Não consegui encontrar uma solução definitiva para isso, mas aqui está uma solução alternativa (consulte esta comentário ) que eu consegui usar nas instâncias afetadas:

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

    

Answer 3

Eu segui as sugestões fornecidas na documentação da AWS e tudo está funcionando agora.
Mas eu tive que combinar duas soluções: aumentar o espaço e adicionar o cronjob para remover arquivos antigos. Aqui está o que eu fiz.

Primeiro, alterei o volume xvdcz para usar 50 GB em vez de 12 GB. Esse é o armazenamento que podemos ver em docker system info . No meu caso, estava sempre cheio porque eu carrego muitos arquivos todos os dias.

.ebextensions / blockdevice-xvdcz.config

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

Depois disso, adicionei um cronjob para limpar meus arquivos excluídos que não eram mais usados, mas o Docker ainda os mantinha por algum motivo. No meu caso, uma vez por dia é o suficiente, se você tiver mais uploads do que eu, você pode configurar o cronjob para executar quantas vezes você precisa.

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

Fonte: link

    

Answer 4

Eu bati minha cabeça contra este problema por mais de um dia e finalmente descobri.

A AWS está usando o backend devicemapper cria um volume SSD de 12 GB que é montado e usado para as imagens docker. Você tem que substituir o volume que montaria através do conceito de extensões de elasticbeanstalk e implantar via CLI (não há como fazer isso através de sua interface gráfica, infelizmente).

No diretório que você tem seu arquivo Dockerrun.aws.json , crie um diretório chamado .ebextensions e crie um arquivo que termine em .config dentro dele. Eu chamei o meu 01.correctebsvolume.config . Em seguida, coloque o seguinte conteúdo lá:

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

Eu ssh'ed em uma das minhas falhas diretamente e descobri que estava montando /dev/xvdcz . pode ser diferente para você. O snap-066cZZZZZZZZ precisa ser um ID de instantâneo válido. Eu criei uma imagem da AMI da instância com falha e usei a captura instantânea que ela criou no processo. O 40 é quantos GB o volume será, portanto, substitua o que você precisa. Eu não sei o que o true ou gp2 faz, mas eles vieram dos dados do dispositivo de bloco de imagem da AMI, então eu os mantive.

A mágica namespace e option_name vem de aqui na documentação.

    

Answer 5

Apenas aumentando o tamanho do disco não irá resolver o problema, será apenas erro mais tarde. AWS recomenda o mapeamento de um novo disco para o seu contêiner, de forma que qualquer arquivo de criação / exclusão de arquivos não afete a camada de pesquisa do Docker.

No momento, estou olhando para ele, ainda não testei, mas a solução que vejo é ter isso no meu 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

Aprecie quaisquer comentários.

    

Answer 6

seção Configuração do ambiente do AWS elasticbeanstalk docker como funciona:

For improved performance, Elastic Beanstalk configures two Amazon EBS storage volumes for your Docker environment's EC2 instances. In addition to the root volume provisioned for all Elastic Beanstalk environments, a second 12GB volume named xvdcz is provisioned for image storage on Docker environments.

If you need more storage space or increased IOPS for Docker images, you can customize the image storage volume by using the BlockDeviceMapping configuration option in the aws:autoscaling:launchconfiguration namespace.

For example, the following configuration file increases the storage volume's size to 100 GB with 500 provisioned IOPS:

Example .ebextensions/blockdevice-xvdcz.config

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

If you use the BlockDeviceMappings option to configure additional volumes for your application, you should include a mapping for xvdcz to ensure that it is created. The following example configures two volumes, the image storage volume xvdcz with default settings and an additional 24 GB application volume named sdh:

Example .ebextensions/blockdevice-sdh.config

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