主页 / unix / 问题 / 433426
Accepted
pdns
Asked: 2018-03-26 06:34:18 +0800 CST

如何在自定义 FreeBSD AMI 上运行 userdata 脚本？

  • 772

我读到您只能在 EC2 AMI 上运行一次用户数据。如果您从 EC2 实例创建自定义 AMI，则无法在该自定义 AMI 上运行 userdata 脚本。在 Ubuntu 实例上，您可以删除 /var/lib/cloud/* ，创建自定义 AMI 并在自定义 AMI 上运行 userdata。我在 FreeBSD 上找不到 /var/lib/cloud/* 的等价物。

有没有办法在自定义 FreeBSD AMI 上运行 userdata 或创建 AMI 的替代方法，以便您可以再次运行 userdata 脚本？

Linux 有 #cloud-boothook，但对于 FreeBSD，我只发现 configinit 不能满足我的需要。我们在启动实例时从命令行将参数传递到 userdata 脚本。

freebsd amazon-ec2

2 个回答

  1. Best Answer

    AWS 上的 FreeBSD AMI 对 user_data 脚本的支持与其他 AMI 不同。正如您所指出的，它不支持#cloud-boothookuser_data 并忽略启动后传递的任何 user_data 。

    一个简单的解决方案如下：

    sed -i '' '/KEYWORD: *firstboot$/d' /usr/local/etc/rc.d/ec2_configinit

    这是一个技巧——您的实例现在将执行所有 user_data 脚本，即使是那些没有#cloud-boothook标签的脚本，但在我看来，它比脚本的默认行为要好得多。请注意，始终可以ec2_configinit通过在/etc/rc.conf.

    • 2

  2. 我提供我自己的答案，因为接受的答案非常粗略。

    更新：我认为接受的答案非常粗略，但最后，我还是在使用它，因为它最适合我。这里的其余部分只会提供一些其他人可能会觉得有用的背景。接受的答案最终对我最有效，因为：（1）它允许我始终执行 shell 脚本，（2）除了按照我在下面解释的方式处理用户数据文件之外，它不做任何其他事情，（ 3) 如果我愿意，我仍然可以在 rc.conf 中禁用它。

    问题是，即使在 Amazon Linux 上，用户数据脚本也只会在首次启动时执行，除非您使用 MIME 多部分/混合技巧。您可以查看它https://cloudinit.readthedocs.io/en/latest/topics/format.html但我给出了一个推动限制的示例：

    Content-Type: multipart/mixed; boundary="schnipp-schnapp"
MIME-Version: 1.0

--schnipp-schnapp
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [scripts-user, always]

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="user-data.sh"

#!/bin/bash
echo "Hello World." >> /etc/motd

--schnipp-schnapp
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="another.sh"

#!/bin/bash
echo "Kilroy was here." >> /etc/motd

--schnipp-schnapp
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="imput64-8503-small.jpg"

/9j/4AAQSkZJRgABAQEAlgCWAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcU
FhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgo
...
JFSUkfQjjHr9yT2T9SSSdLS15R/qM64pbLRUcsExOk6axzpxhiQATFSDIB6E68K/c6WlrzEoTypl
JoceL9zq7NbXis8oopa6RRNUQovmNlCM5IIzxQLkgkD0wQCAFLYaXzKkSSVEkzOZXqJJOUjsfXkf
cknJOMk++lpa9u+AGkJwsuJACiqCeJGm5pJiZJXBr4Sx04IfzZiS3I9r3/TQakADkD260tLWjxQk
hE9/tVFgPm8K/9k=

--schnipp-schnapp--

    我发现这两个脚本是按字母顺序执行的，而图像部分被忽略了。

    除非 FreeBSD AMI 维护者实现这个多部分的东西和它所涉及的所有东西

    • 文本/云-boothook
    • 文本/云配置
    • 文本/云配置存档
    • 文字/神社2
    • 文本/部分处理程序
    • 文本/新贵工作
    • 文本/x-include-once-url
    • 文本/x-include-url
    • 文本/x-shellscript

    为什么你想要 ec2-cloudinit 总是这样执行的所有其他事情？最终你是你自己的。

    自己获取用户数据并决定如何处理确实没有害处。以下是获取它的方法：

    fetch -q -o - http://169.254.169.254/latest/user-data

    所以，如果你想执行它，你可以把它放到 rc.local 中：

    fetch -q -o - http://169.254.169.254/latest/user-data |sh

    或者

    fetch -q -o /tmp/user-data.sh http://169.254.169.254/latest/user-data
mkdir 700 /tmp/user-data.sh
/tmp/user-data.sh

    真的没什么大不了的。不确定是否值得支持复杂的多部分结构。FreeBSD AMI 做得非常不同，而且更简单，而且可以说很好。

    • 如果它以 hash-bang #! 它将被保存并执行
    • 如果它以“>/var/tmp/here”开头，它将被写入指定的目的地
    • 如果它以“>>/var/tmp/here”开头，它将被附加到指定的目的地
    • 否则，它将被视为 shell 脚本的未压缩 tar 存档，展开，然后使用上述规则执行每个文件。

    由于它不是 AWS 标准，所以我不会理会它。只需有一个脚本并强制它在 rc.local 中执行，或者甚至不执行，只是检查以找到一些以某种方式控制行为的参数。

    • 1

相关问题