AWS EC2 UserData脚本无法在t3实例上触发 [英] AWS EC2 UserData Script Doesn't Fire on t3 instances
问题描述
我有一个漂亮的简单的用户数据脚本，该代码在Ubuntu上安装了CodeDeploy代理，然后向CloudFormation发出信号表示实例运行状况良好。我的堆栈是使用CloudFormation部署的，该应用程序设置了ASG，LaunchTemplate，TargetGroup等。目标实例类型为t3.small实例上的Ubuntu 18.04（ami-07ebfd5b3428b6f4d AMI）。我以前在不同的AMI上也遇到了同样的问题，但是升级到ami-07ebfd5b3428b6f4d似乎可以暂时解决它……工作了几周。
最近，我的ASG试图替换一些不正常的实例，但新实例没有出现。在进一步调查中，我发现我又回到了相同的问题-userdata脚本未触发。 cloud-init.log结尾于此行：
2020-03-20 01：23：56,741-util.py [ DEBUG]：运行命令['/ var / lib / cloud / instance / scripts / part-001']，允许的返回码[0]（shell = False，capture = False）
但是似乎挂在这里，系统日志中没有任何活动。日志中的该文件正确包含了脚本，并且如果我手动调用该脚本，则该脚本将成功执行（无需任何必要的交互）。
更改CloudFormation堆栈以改用t2实例解决了问题。我已经保留了t3的容量，所以我需要回到t3。
任何人的想法/想法？
根据评论进行更新。这是cloud-init-output.log的最后几行：
设置批准（2.20.9-0ubuntu7.12 ）...
安装新版本的配置文件/etc/init.d/apport ...
apport-autoreport.service是禁用的或静态的设备，而不是启动它。
设置ubuntu-standard（1.417.4）...
设置grub-pc（2.02-2ubuntu8.15）...
ESC [1; 24rESC [4lESC）0ESC [ mESC（BESC [1; 24rESC [HESC [JESC [1; 1HPackage configurationESC [3;2H┌───────────── -pc├────────────────┐ESC[4;2H│ESC[75C│ESC[5;2H│] GRUB引导程序以前已安装到不再存在noESC [8C│ESC[6;2H│]或其唯一标识符具有ch
<事实证明，非交互模式要求进行交互，不知道为什么会发生这种情况，或者为什么随后手动调用脚本没有表现出交互作用相同的提示。提示是
解决方法是修改脚本顶部，如下所示：
export DEBIAN_FRONTEND =非交互式
apt-get更新
apt-get -y升级
apt-get安装l awscli python-pip -y
pip install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz
apt-get自动删除
apt-get autoclean
I have a pretty simple userdata script that installs the CodeDeploy agent on ubuntu and then emits a signal to CloudFormation indicating the instance is healthy. My stack is deployed using CloudFormation, which sets up an ASG, LaunchTemplate, TargetGroup, etc. The target instance type is Ubuntu 18.04 (ami-07ebfd5b3428b6f4d AMI) on t3.small instances. I previously had the same problem on a different AMI, but upgrading to ami-07ebfd5b3428b6f4d seemed to fix it temporarily...it worked for several weeks.
Recently, my ASG tried to replace some unhealthy instances, and the new instances didn't come up. On further investigation, I discovered that I was back to having the same issue again - userdata script not firing. The cloud-init.log ends with this line:
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)
But seems to hang here with no activity in syslog. This file from the log correctly contains by script, and this script executes successfully (without any required interaction) if I invoke it manually.
Changing my CloudFormation stack to instead use t2 instances resolves the issue. I have reserved t3 capacity though, so I need to get back to t3.
Thoughts/ideas anyone?
Update based on comment. Here are the last few lines of 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
As it turns out, non-interactive mode was asking for interaction. No idea why this was the case, or why subsequently invoking the script manually didn't exhibit the same behavior. The hint was the garbled log message at the end of cloud-init-output.log (thanks @Marcin for the nudge on that).
The fix was to modify the top of the script to look like this:
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get -y upgrade
apt-get install awscli python-pip -y
pip install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz
apt-get autoremove
apt-get autoclean
这篇关于AWS EC2 UserData脚本无法在t3实例上触发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
