As mentioned in an earlier post I’d been working on two new Ansible modules; for imgadm(1M) and vmadm(1M). So here I want to demonstrate these new modules which will be part of Ansible 2.3.

imgadm⌗

The imgadm module allow for managing both images and data sources. Let’s start by adding a new data source:

- name: Add datasets.at source
  imgadm:
    source: 'http://datasets.at/'
    state: present

And we can remove it just as easily:

- imgadm: source='http://datasets.at/' state=absent

But let’s import an image:

- name: Import minimal-64-lts image
  imgadm:
    uuid: '3c999bae-d419-11e6-adea-e730a3c335c6'
    state: present

Which after a short while returns:

TASK [Import minimal-64-lts image] *****************************************************
ok: [calafate-gz] => {"changed": false, "state": "present", "uuid": "3c999bae-d419-11e6-adea-e730a3c335c6"}

Of course we can use standard Ansible syntax for targeting all images:

 - imgadm: uuid='*' state=vacuumed

Of course since Ansible attempts to provide idempotency, it won’t download anything unless it needs to ensure the correct state.

More examples and documentation is available here.

vmadm⌗

The imgadm module was merely warming up for this larger module which allows for creating new zones/VMs and managing their state.

For example in order to create a new zone and ensure it’s running we can define an Ansible task:

  - name: Create Ansible dev zone based on SmartOS
    vmadm:
      alias: ansible-dev
      state: running
      image_uuid: 70e3ae72-96b6-11e6-9056-9737fd4d0764
      autoboot: yes
      max_physical_memory: 1024
      hostname: 'ansible-dev'
      dns_domain: 'office.jasper.la'
      resolvers: [172.16.40.255]
      nics:
        - nic_tag: 'admin'
          gateway: 172.16.40.2
          ip: 172.16.40.19
          netmask: 255.255.255.0
          primary: yes
      customer_metadata:
        'root_authorized_keys': "ssh-rsa [...]"
        'ansible_pubkey': "ssh-rsa [...]"
        'user-script': '/usr/sbin/mdata-get root_authorized_keys > ~root/.ssh/authorized_keys; /usr/sbin/mdata-get ansible_pubkey >> ~root/.ssh/authorized_keys'

Which after a minute or so results in a freshly provisioned zone, ready for use with Ansible:

TASK [Create Ansible dev zone based on SmartOS] ********************************
changed: [calafate-gz] => {"changed": true, "name": "ansible-dev", "state": "running", "uuid": "1d8e1396-77d9-ce61-ee00-9e87c1410b1b"}

And we can ensure a zone is shutdown or even rebooted as well:

- vmadm:
    alias: ansible-dev
    state: restarted

Again it’s possible to operate on all VMs by using the uuid='*' syntax:

- name: Ensure all zones are running
  vmadm:
    uuid: '*'
    state: running

There are currently two things left to do in this module, which is to support more options that vmadm itself supports; there are just so many! Furthermore I want to have a way to update an existing VM, analogue to vmadm update $UUID indestructable_zoneroot=false.

Conclusion⌗

Thanks to these modules it’s now possible to manage the entire lifecycle of SmartOS zones and VMs. While it was already possible to script things with vmadm, integrating it into Ansible makes it a heck of a lot easier to manage multiple SmartOS nodes with the same tools as I use to manage zones.

On a related note, one can now manage the timezone settings in SmartOS instances with the timezone module.

If you want to try out these modules (imgadm, vmadm and the updated timezone module), you can wait for Ansible 2.3 or download the files from GitHub and store them in your local library/ folder.