2016-12-27 131 views
0

我们使用Ansible来配置ec2实例,在其上部署我们的应用程序,然后基于该实例创建AMI,更新启动配置,以便自动调节小组总是推出新版本的应用程序。ec2中的元数据/块设备映射不正确的临时数据

我们针对不同的应用程序(diff实例大小,家庭等)重新使用了许多ansible的剧本。 这个运行的任务之一是检查实例元数据以确定是否存在任何临时设备,如果存在,请将它们挂载并将它们保存在/ etc/fstab和cloud-config中。

我们碰上与实例元数据类似于在此线程3年前描述的问题: https://forums.aws.amazon.com/thread.jspa?messageID=489889

现在我们正在做一些测试与t2.large情况下,如你所知,这种情况下,仅是EBS,但是当我们卷曲的实例元数据,我们得到的是有2个短暂的磁盘礼物: [email protected]:~$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/ ami ebs1 ebs2 ephemeral0 ephemeral1

的事情是,这些短暂的设备并不实际存在,所以,当我们的脚本试图坚持他们在cloud-config中,cloud-config最终成为一个破碎的yaml blob ....这是一个重大问题,因为它会导致我们er_data在实例启动时失败。

任何想法的人?

回答

0

如果这是亚马逊团队无法解决的已知问题,则可以解决该问题。

快速脚本来检查实际存在:

#!/bin/bash 

for MAPID in $(curl -s http://169.254.169.254/latest/meta-data/block-device-mapping/); do 
    BLKDEV=$(curl -s http://169.254.169.254/latest/meta-data/block-device-mapping/$MAPID/ | sed 's#^/dev/##' | sed 's/^sd/xvd/') 
    if blkid | grep -q $BLKDEV; then 
    echo $BLKDEV present 
    else 
    echo $BLKDEV not present 
    fi 
done 

c1.mediumt2.medium选中它。 t2输出:

$ curl -s http://169.254.169.254/latest/meta-data/block-device-mapping/ 
ami 
ebs1 
ephemeral0 
ephemeral1 
root 

$ ./test.sh 
xvda1 present 
xvdd present 
xvdb not present 
xvdc not present 
xvda1 present 
+0

是的,答案我已经从AWS支持团队得到的是基本上不使用元数据,使用lsblk代替。但总体思路是实例元数据是不可变的,是真相的源泉,为什么我们应该使用不同的东西? – sebamontini