Cloud-Init bootstrap

Cloud images are operating system templates and every instance starts out as an identical clone of every other instance. It is the user data that gives every cloud instance its personality and cloud-init is the tool that applies user data to your instances automatically.

Kowabunga Kahuna comes with pre-bundled cloud-init templates which are then deployed into /etc/kowabunga/templates configuration directory.

Supporting both Linux and Windows targets, they come with the usual:

• meta_data.yml file, providing various metadata information, that can be further reused by Kowabunga agents.
• network_config.yml file, allowing for proper automatic network stack and interfaces configuration.
• user_data.yml file, providing a sequence of actions to be applied post (initial) boot, as described in its standard documentation.

Note that all these files are based on Go Templates. They are used by Kahuna to generate instance-specific configuration files and bundled into an ISO9660 image (stored on Ceph backend), ready to be consumed by OS, and written/updated each time a computing instance is being created/updated.

Linux Instances

Most of Linux distributions these days natively support cloud-init standard. As long as you’re virtual machines boots up with an associated emulated CD-ROM ISO9660 image aside, you’re good to go.

Note that Kowabunga cloud-init template natively provide the following post-actions:

• Setup network interfaces, DNS and gateway.
• Set instance hostname and FQDN.
• Update package repositories.
• Install basic packages, including QEMU agent.
• Set initial root password.
• Provision service user, ready to further bootstrap instance.
• Adds a /usr/bin/kw-meta wrapper script, friendly use to Kowabunga instance metadata retrieval.
• Wait for Internet connectivity/access.

Microsoft Windows Instances

Microsoft Windows OS is a different story than Linux as there’s no default cloud-init implementation bundled.

One can however cope with such limitation thanks to the Cloudbase-Init project which provide cloud-init compatibility and is the “The Quickest Way of Automating Windows Guest Initialization”. It supports Windows 8+ and Windows Server 2012+ OS variants.

Its usage implies a much more complex approach than Linux targets as it requires you to first build up your private custom Windows disk image template, extending it with cloudbase-init.conf configuration file.

Once your image has been built, Kowabunga cloudbase-init supports all options from the NoCloud engine.

Note that Kowabunga cloudbase-init template natively provide the following post-actions:

• Setup network interfaces, DNS and gateway.
• Set instance hostname and FQDN.
• Install basic packages, including NuGet, Paket, PsExec, OpenSSH.
• Set PowerShell as SSH default shell.
• Update firewall rules.
• Set OS password security policy.
• Set initial root password.
• Provision service user, ready to further bootstrap instance.

From there on, you’ll get a ready-to-be-consumed Windows instance, which deployment can be further automated thanks to Ansible over SSH or any other provisioning tool or scripts.

It is then your responsibility to provide the Microsoft Windows license key (your Windows instance will anyway automatically shutdown after an hour if not).

Shall you be willing to temporarily bypass such mechanism, you can do so with such an Ansible playbook for instance:

---
- hosts: windows

  vars:
    ansible_connection: ssh
    ansible_shell_type: powershell
    ansible_user: admin
    ansible_password: "SECURE_ADMIN_PASSWORD"

  tasks:
    - name: Accept EULA
      ansible.windows.win_shell: "PsExec.exe -accepteula"
      ignore_errors: true

    - name: Disable WLM
      ansible.windows.win_shell: "PsExec.exe \\\\127.0.0.1 -s -i sc config WLMS start=disabled"

    - name: Reboot hosts
      ansible.windows.win_shell: "shutdown /r"