AWS ElastikBeanstalk docker-ince-havuz dolu ve dosya sisteminin salt okunur olarak yeniden monte edilmesine neden olur?

AWS'nin Docker'ın 'ince havuzunu' ElastikBeanstalk üzerine nasıl ayarladığını ve nasıl doldurulduğunu anlayamıyorum. Docker ince havuzum bir şekilde dolduruyor ve diske yazmaya çalıştığımda uygulamalarımın çökmesine neden oluyor.

Bu konteynerin içinden:

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

EBS aslında 25GB'lık bir diske sahiptir; 1.6 gb du -sh /geri döner.

EC2 dışında, yeterince zararsız bir şekilde başlıyor ... (üzerinden 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

Ancak, dosya sistemi yakında salt okunur olarak yeniden bağlanacaktır. dmesg aracılığıyla:

[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 örneği karasının iç Arkaya, Docker bu raporları: (dan 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 bu bilgiyi atar:

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

Bu ince havuz nedir, neden dolduruyor ve bunu nasıl durdurabilirim? Ayrıca, / birimimdeki kapsayıcıdan 20+ GB boş alanım varsa, neden yeni yazmaları durduruyor? Anlayabildiğim kadarıyla, programlarımın yazdığı dosyalara bağlı değil.

Teşekkür ederim!

.ebextensionsDavid Ellis tarafından önerilen benim için çalıştı. Cevabı hakkında yorum yapamıyorum, ancak anlık görüntü kullanmak yerine yeni bir EBS birimi oluşturabileceğinizi eklemek istedim. Bir 40GB EBS birimi bağlamak için aşağıdakileri kullandım:

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

100 GB'lık yeni bir EBS birimini eşleme örneği olan bu belgelere de bakın /dev/sdh.

trueUç vasıtası ile "sona silme".

Yukarıdaki kodu .ebextensionsiçeren bir ebs.configdosya içeren yeni bir dizin oluşturdum , sonra bu dizini benim ile birlikte sıkıştırdım Dockerrun.aws.json. Dockerrun dosyasının bir alt dizinin içinde değil, zip dosyasının en üst düzeyinde olması gerektiğini unutmayın.

Elastik Beanstalk'un birimi nereye monte ettiğini bulmak lsblkiçin başarısız örnekte kullanın . Benim için de öyleydi /dev/xvdcz, belki de standart budur.

Aynı sorundan etkilendik. Temel neden Docker'ın depolama motorunu ( devicemapperElastik Beanstalk'ta varsayılan olarak ince ayarlı) monte etmemesi gibi görünüyor discard, bu da blokları kırılana kadar dolduruyor.

Buna kesin bir çözüm bulamadım, ancak burada etkilenen örneklerde kullanabildiğim bir geçici çözüm var ( bu yoruma bakın ):

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

AWS dokümantasyonu ile ilgili önerileri takip ettim ve şimdi her şey çalışıyor.
Ama iki çözümü birleştirmek zorunda kaldım: alanı artırmak ve eski dosyaları kaldırmak için cronjob eklemek.
İşte yaptığım şey.

İlk olarak, ses seviyesini xvdcz12GB yerine 50GB kullanacak şekilde değiştirdim . Gördüğümüz depolama alanı bu docker system info. Benim durumumda her zaman doluydu çünkü her gün çok sayıda dosya yüklüyorum.

.ebextensions / blockdevice-xvdcz.config

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

Artık kullanılmayan silinmiş dosyalarımı temizlemek için bir cronjob ekledikten sonra. Bu gerekliydi çünkü Docker onları hala bir nedenden dolayı sakladı. Benim durumumda günde bir kez yeterli. Benden daha fazla yüklemeniz varsa, cronjob'ı kaç kez ihtiyacınız olduğunu çalıştıracak şekilde yapılandırabilirsiniz.

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

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

AWS rubberbeanstalk docker bölümü Çevre Yapılandırması nasıl çalıştığını belgeler:

Daha iyi performans için, Elastik Beanstalk Docker ortamınızın EC2 bulut sunucuları için iki Amazon EBS depolama birimini yapılandırır. Tüm Elastik Beanstalk ortamları için sağlanan kök birimine ek olarak, Docker ortamlarında görüntü depolaması için xvdcz adlı ikinci bir 12GB birim de sağlanır.

Docker görüntüleri için daha fazla depolama alanına veya artırılmış IOPS'ye ihtiyacınız varsa, aws: autoscaling: launchconfiguration ad alanında bulunan BlockDeviceMapping yapılandırma seçeneğini kullanarak görüntü depolama birimini özelleştirebilirsiniz.

Örneğin, aşağıdaki yapılandırma dosyası depolama biriminin boyutunu 500 ayrılan IOPS ile 100 GB'a çıkarır:

Örnek .ebextensions / blockdevice-xvdcz.config

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

Uygulamanız için ek birimler yapılandırmak için BlockDeviceMappings seçeneğini kullanırsanız, oluşturulmasını sağlamak için xvdcz için bir eşleme eklemeniz gerekir. Aşağıdaki örnek, iki birimi, varsayılan ayarlarla görüntü depolama birimi xvdcz ve sdh adlı ek 24 GB uygulama birimini yapılandırır:

Örnek .ebextensions / blockdevice-sdh.config

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

Bir gün boyunca bu soruna karşı başımı yedim ve sonunda anladım.

AWS devicemapperarka ucu kullanıyor ve docker görüntüleri için monte ettiği ve kullandığı 12GB SSD birimi oluşturuyor. Flexiblebeanstalk uzantıları kavramı aracılığıyla monte edeceği hacmi geçersiz kılmanız ve CLI aracılığıyla dağıtmanız gerekir (maalesef GUI'leri aracılığıyla bunu yapmanın bir yolu yoktur).

Eğer varsa dizinde Dockerrun.aws.jsondosyayı, adlı bir dizin oluşturun .ebextensionsve sonra bir dosya oluşturmak içinde biter o .configonun iç. Benimkini aradım 01.correctebsvolume.config. Sonra aşağıdaki içeriği oraya koyun:

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

Başarısız kutumlardan birine doğrudan ssh'ed ve monte edildiğini gördüm /dev/xvdcz. Bu olabilir sizin için farklı olacak. snap-066cZZZZZZZZİhtiyaçlar geçerli bir anlık kimliği olması. Başarısız örneğin AMI görüntüsünü oluşturdum ve işlemde oluşturduğu anlık görüntüyü kullandım. 40İhtiyacınız ne yerine bu yüzden, hacim olacak kaç GB olabilir. Bildiklerimi yok trueya gp2, ama ben onları muhafaza yüzden onlar, AMI görüntü blok aygıt verilerinden geldi.

Sihirli namespaceve option_namegelen burada belgelerinde.

Sadece diskin boyutunu artırmak sorunu çözmeyecek, daha sonra hata verecektir. AWS, herhangi bir dosya oluşturma / silme dosyasının Docker Anket Katmanını etkilememesi için kabınızla yeni bir diskin eşlenmesini önerir.

Şu anda bakıyorum, henüz test etmedim ama karşılaştığım çözüm benim blockdevice.config üzerinde

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

Herhangi bir yorum için teşekkür ederiz.