【发布时间】:2020-07-01 04:34:52
【问题描述】:
我有一个漂亮的simple userdata script,它在 ubuntu 上安装 CodeDeploy 代理,然后向 CloudFormation 发出一个信号,表明该实例是健康的。我的堆栈是使用 CloudFormation 部署的,它设置了 ASG、LaunchTemplate、TargetGroup 等。目标实例类型是 t3.small 实例上的 Ubuntu 18.04 (ami-07ebfd5b3428b6f4d AMI)。我以前在不同的 AMI 上遇到过同样的问题,但升级到 ami-07ebfd5b3428b6f4d 似乎可以暂时解决它……它工作了几个星期。
最近,我的 ASG 尝试替换一些运行状况不佳的实例,但没有出现新实例。在进一步调查中,我发现我又遇到了同样的问题——用户数据脚本没有触发。 cloud-init.log 以这一行结尾:
2020-03-20 01:23:56,741 - util.py[DEBUG]: Running command ['/var/lib/cloud/instance/scripts/part-001'] with allowed return codes [0] (shell=False, capture=False)
但似乎挂在这里,系统日志中没有任何活动。日志中的这个文件正确地包含在脚本中,如果我手动调用它,这个脚本会成功执行(不需要任何交互)。
将我的 CloudFormation 堆栈改为使用 t2 实例可以解决该问题。我已经保留了 t3 容量,所以我需要回到 t3。
任何人的想法/想法?
根据评论更新。以下是 cloud-init-output.log 的最后几行:
Setting up apport (2.20.9-0ubuntu7.12) ...
Installing new version of config file /etc/init.d/apport ...
apport-autoreport.service is a disabled or a static unit, not starting it.
Setting up ubuntu-standard (1.417.4) ...
Setting up grub-pc (2.02-2ubuntu8.15) ...
ESC[1;24rESC[4lESC)0ESC[mESC(BESC[1;24rESC[HESC[JESC[1;1HPackage configurationESC[3;2H┌──────────────────────────┤ Configuring grub-pc ├──────────────────────────┐ESC[4;2H│ESC[75C│ESC[5;2H│ The GRUB boot loader was previously installed to a disk that is noESC[8C│ESC[6;2H│ longer present, or whose unique identifier has ch
【问题讨论】:
-
cloud-init-output.log显示了什么? -
@Marcin 添加到帖子末尾。最后一行出现乱码,但“GRUB 引导加载程序以前安装到一个不存在的磁盘”看起来很可疑。谢谢。
-
与 t2.micro 上的输出比较。
-
@Marcin 是的,这是最后几行。
-
不知道。我第一次看到这样的东西。检查那里的 t2.micro 上有什么。
标签: amazon-web-services ubuntu amazon-ec2 amazon-cloudformation aws-code-deploy