☰

带有 args 的 cloud-init 脚本（参数化）

tag-icon • tag-icon deployment cloud-init
带有 args 的 cloud-init 脚本（参数化）

很长的故事

我正在准备用于安装的 cloud-init 脚本监控软件代理（免责声明：我是 MonitOwl 的创始人之一）。代理软件收集信息（如内存或网络统计信息）并将其发送到服务器。每个公司组都应该连接到自己的个性化服务器网址如：https://customer_name.example.org。

cloud-init 脚本用于Content-Type: multipart/mixed;从 github 下载代理、安装 systemd 服务以及安装 python 所需内容。目前我们使用它的方式如下：

# ec2-run-instances --user-data-file <our_generated_file>

对于我们的内部部署，我们使用 ansible（使用 VARS 参数化），但现在越来越多的人要求使用 cloud-init 脚本。

目标

我希望所有公司都有一个通用的 cloud-init 脚本，只需向服务器提供带有 URL 的参数即可。我希望将此 cloud-init 脚本放在我们的 github 存储库中，以使安装代理的体验更好。

问题

不幸的是，我发现的唯一方法是准备一个单独的脚本 -发电机这将创建带有硬编码 URL 的 cloud-init 脚本。有什么好方法可以实现我的目标吗？我不敢相信 canonical 在开发 cloud-init 时没有考虑参数化。

答案1

长话短说，cloud-init 可以使用通过元数据传递给它的 jinja 变量进行模板化。元数据随后传递给 cloud-init 实例，这里有一些很好的例子： https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html

请注意，您需要在创建实例时启用元数据。

要测试变量，您可以使用启用了元数据的实例之一。

[user@ubuntu-h~]$ cloud-init query -f "{{ sys_info.uname[1] }}"
ubuntu-h

那个“ubuntu-h”是从元数据中获取的，而不是从本地机器中获取的。

我个人必须根据 ec2 实例主机名生成 salt-minion 名称。可以使用特定于其应用程序或 runcmd 的模块。请注意模板和云配置的 shebang ↓

## template: jinja
#cloud-config
runcmd:
    - ["/bin/mkdir", "-p", "/data/salt/etc"]
    - ["/bin/ln", "-s", "/data/salt/etc", "/etc/salt"]
    - echo 'test.{{ sys_info.uname[1] }}.aws.local' >> /etc/salt/minion_id

### OR using the module salt-minion:

salt_minion:
    pkg_name: 'salt-minion'
    service_name: 'salt-minion'
    config_dir: '/data/salt/etc'
    conf:
        master: IP_ADDRESS
        id: test.{{ sys_info.uname[1] }}.aws.local
        root_dir: /data/salt
        pki_dir: /pki/minion
        conf_file: /data/salt/etc/minion
        log_file: /data/salt/log/minion
        log_level_logfile: info
    grains:
        role:
            - aws_staged

相关内容