3

Long Story

I'm preparing cloud-init scripts for instaling monitoring software agent (disclaimer: I'm one of the founders of MonitOwl). The agent software collect information (like memory or network stats) and send it to server. Each company group should connect to own personalized server URL like: https://customer_name.example.org.

The cloud-init script is a Content-Type: multipart/mixed; that downloads agent from github, install systemd service and install python requirements. Currently we use it like:

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

For our internal deployments we use ansible (parametrized with VARS) but now more and more people ask for cloud-init script.

Goal

I would like to have one common cloud-init script for all companies and just provide argument with URL to server. I would like to put this cloud-init script in our github repository, to make the experience of installing agent even better.

Problem

Unfortunately the only way I found is to prepare a separate script - generator that will create the cloud-init script with hardcoded URL inside. Is there any nice way to accomplish my goal? I cannot believe that canonical didn't think about parametrization when developing cloud-init.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
neutrinus
  • 1,125
  • 7
  • 18
  • user-data string or user-data-file? [User configurability](http://cloudinit.readthedocs.org/en/latest/topics/capabilities.html#user-configurability) – Brian Oct 23 '14 at 20:40
  • @Brian: --user-data-file, take a look at our [current](https://github.com/whitehats/monitowl-agent/blob/master/cloudinit-gen.sh) implementation – neutrinus Oct 24 '14 at 19:18

1 Answers1

1

Long story short cloud-init can be templatized using jinja variables passed to it via the Metadata. Metadata then passed to the cloud-init instance, there are some good examples here: https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html

Please note that you will need to enable Metadata on instance creation.

To test the variables you may use one the the instances with metadata enabled.

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

That "ubuntu-h" was taken from metadata, not from the local machine.

Personally I had to generate salt-minion name based of the ec2 instance hostname. One could use module specific for it's application or runcmd. Please note shebang for template as well as for cloud-config ↓

## 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
Dmitriy Kupch
  • 471
  • 2
  • 6