AWS ElasticBeanstalk 도커 씬 풀이 가득 차서 파일 시스템을 읽기 전용으로 다시 마운트합니까?

AWS가 ElasticBeanstalk에서 Docker 'thin pool'을 설정하는 방법과 채워지는 방법을 알 수 없습니다. 도커 씬 풀이 어떻게 든 채워져 디스크에 쓰려고 할 때 앱이 중단됩니다.

이것은 컨테이너 내부에서 온 것입니다.

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

실제로 EBS에는 25GB 디스크가 할당되어 있습니다. 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 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

이 얇은 수영장은 무엇이며 왜 채워졌으며 어떻게하지 못하게됩니까? 또한 / 볼륨의 컨테이너 내부에서 20GB 이상의 여유 공간이 있으면 왜 새 쓰기를 중지합니까? 내가 알 수있는 한 내 프로그램이 쓰는 파일에 연결되어 있지 않습니다.

감사합니다!

.ebextensions데이비드 엘리스에 의해 제안 나를 위해 일했다. 그의 답변에 대해서는 언급 할 수 없지만 스냅 샷을 사용하는 대신 새 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파일을 포함하는 새 디렉토리를 만든 다음 해당 디렉토리를 my와 함께 압축했습니다 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을 추가하여 오래된 파일을 제거하는 두 가지 솔루션을 결합해야했습니다.
여기 내가 한 일이 있습니다.

먼저 xvdcz12GB 대신 50GB를 사용 하도록 볼륨 을 변경했습니다 . 그것이 우리가 볼 수있는 스토리지입니다 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 도커 섹션 환경 구성 문서 작동 방식 :

성능 향상을 위해 Elastic Beanstalk는 Docker 환경의 EC2 인스턴스에 대해 두 개의 Amazon EBS 스토리지 볼륨을 구성합니다. 모든 Elastic Beanstalk 환경에 프로비저닝 된 루트 볼륨 외에도 xvdcz라는 두 번째 12GB 볼륨이 Docker 환경의 이미지 스토리지에 프로비저닝됩니다.

Docker 이미지에 더 많은 저장 공간 또는 증가 된 IOPS가 필요한 경우 aws : autoscaling : launchconfiguration 네임 스페이스의 BlockDeviceMapping 구성 옵션을 사용하여 이미지 스토리지 볼륨을 사용자 정의 할 수 있습니다.

예를 들어, 다음 구성 파일은 500 개의 프로비저닝 된 IOPS로 스토리지 볼륨의 크기를 100GB로 늘립니다.

예 .ebextensions / blockdevice-xvdcz.config

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

BlockDeviceMappings 옵션을 사용하여 응용 프로그램에 대한 추가 볼륨을 구성하는 경우 xvdcz에 대한 맵핑을 포함하여 작성되도록하십시오. 다음 예는 기본 설정을 가진 이미지 스토리지 볼륨 xvdcz와 sdh라는 추가 24GB 응용 프로그램 볼륨을 구성합니다.

예 .ebextensions / blockdevice-sdh.config

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

나는이 문제에 대해 하루 이상 머리를 치고 마침내 알아 냈습니다.

AWS는 devicemapper백엔드를 사용 중이며 도커 이미지에 마운트하고 사용하는 12GB SSD 볼륨을 생성합니다. 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

나는 실패한 박스 중 하나에 직접 ssh'ed하고 그것이 장착되고 있음을 발견했다 /dev/xvdcz. 그것은 수 있습니다 당신을 위해 다를 수. snap-066cZZZZZZZZ필요는 유효한 스냅 샷 ID가 될 수 있습니다. 장애가 발생한 인스턴스의 AMI 이미지를 생성하고 프로세스에서 생성 한 스냅 샷을 사용했습니다. 는 40당신이 필요로 대체 할 수 있도록, 볼륨이 얼마나 많은 GB입니다. 내가 알고 무엇을하지 않습니다 true또는 gp2않지만, 내가 그들을 계속 그들이 그렇게는 AMI 이미지 블록 장치 데이터에서왔다.

마법 namespace과 option_name에서 오는 여기 문서한다.

디스크 크기 만 늘리면 문제가 해결되지 않고 나중에 오류가 발생합니다. AWS는 파일 생성 / 삭제 파일이 Docker Poll Layer에 영향을 미치지 않도록 새 디스크를 컨테이너에 매핑 할 것을 권장합니다.

나는 현재 그것을 찾고 있는데 아직 테스트하지는 않았지만 내가 만난 해결책은 이것을 내 장치에 가지고 있습니다.

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

의견을 보내주십시오.