Sergey Nivens - Fotolia

Write cloud-config automation scripts into the configuration file

Bypass the need for excess infrastructure, and put off the automation languages seminar -- you need to configure the cloud now. Fortunately, you can still do that.

Sometimes, an administrator wants to stand up a customized cloud-based server without a lot of supporting infrastructure or digging into a deep understanding of automation languages. The cloud-config technology in cloud-init provides a good degree of deployment automation without demanding several new technologies. It's in use at some of the biggest cloud providers, although you might not realize it.

Cloud-init is a package of scripts and utilities that handles early initialization of a cloud instance. Cloud-config is deployment that is driven by a configuration file. With cloud-config for cloud-init, the administrator can inject configuration and set up actions to be performed in the initial OS deployment, customizing it to fit specific requirements.

Write the configuration file to, for example, add users; install additional packages; create, modify and configure files; or call external scripts. The configuration file is formatted in YAML.

Cloud-config interweaves with version control, such as Git.

Cloud-config is supported by most major Linux OSes. Most major cloud providers, including DigitalOcean, Rackspace, AWS and Microsoft Azure, support it. This tutorial uses DigitalOcean to demonstrate cloud-config's setup.

Cloud-config tips

This tutorial guides an admin through how to manually create and insert a cloud-config configuration file, but it is also possible to use an API. The result is a VM configured to a server that has a secondary nonroot user with Secure Socket Shell (SSH) login capability installed with an Apache server.

Log in to the DigitalOcean interface, and select the option to create a new droplet, which is the vendor's parlance for VM. Expand the Select additional options tab, and select User data (see the figure). We'll place the cloud-config commands/file here.

DigitalOcean cloud configuration
Create a configuration file for an empty VM in DigitalOcean here.

The first line of the configuration file identifies the information as a cloud-config file: Enter #cloud-config. Comments are included in the file with # at the start of each comment line.

Build the cloud configuration to fit your needs, and paste it into this window. When the cloud provider builds the server, it will ingest the cloud-config data.

As with all YAML files, tabs in the file will break the configuration. Formatting is all-important.

This is a starting point for cloud-config and will help an administrator new to the technology build up a script over time. This approach requires that you delete and recreate the VM, but it will not cost much, as long as you remember to delete the droplets once finished.

Build the code a line at a time. If something breaks, you can revert to a working script by simply removing or commenting out the last line or command that was edited.

Cloud-config in action

It's time to start coding a configuration file for cloud-init.

1. Add a user.

#cloud-config

users:

  - name: stuart

    ssh-authorized-keys:

      - ssh-rsa <Public key>

    sudo: ['ALL=(ALL) NOPASSWD:ALL']

    groups: sudo

    shell: /bin/bash

This creates a user and uses precreated SSH keys. The other items set the desired shell -- bash, in this case -- and uses the sudo command to perform management tasks without needing to specify the user password.

It is possible to specify a hashed password for logging in. This is no longer considered secure and, therefore, definitely should not be used. Instead, use the SSH key method.

2. At time of publication, however, you can still log in via password, and even the root user can log in by default in most cloud configurations. This isn't ideal and should be disabled. An admin can configure these in the sshd_config file with the sed (sed = stream editor) command, in combination with the runcmd option. Within the /etc/sshd/sshd_config file, there are specific lines that must be altered.

The runcmd can also run equally arbitrary commands or call scripts. To enable the above, use the following entries on runcmd:

- sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config

    - sed -i 's|[#]*PasswordAuthentication yes|PasswordAuthentication no|g' /etc/ssh/sshd_config

Adding packages is equally as easy -- again, using the configuration items packages:. To install a web server, for example, it can be as simple as the following:

packages:

            - apache2

Specify multiple packages and groups if desired.

3. To update the server, ensure all the latest updates are installed. Once all packages are up to date, update the packages database, and perform package upgrades. This is as simple as:

package_upgrade: true

4. Once upgrades are complete, reboot your machine to ensure all changes have stuck. Add the following entry to the end of the configuration. This code is taken directly from the cloud-config examples:

power_state:

  timeout: 120

  delay: "+5"

  message: Rebooting in five minutes. Please save your work.

  mode: reboot

There are logs available to debug output stored in /var/log/, which will be called cloud-init.log and cloud-init-output.log. This is an incomplete glossary of potential commands. Additional commands are found in the manual. Use a version control system to manage all changes, build up the configuration file over time and ensure accuracy at each step in the process.

The full example code is shown below. Remember to use spaces, not tabs:

#cloud-config

users:

  - name: stuart

    ssh-authorized-keys:

      - ssh-rsa <SSH key>

    sudo: ['ALL=(ALL) NOPASSWD:ALL']

    groups: sudo

    shell: /bin/bash

packages:

      - apache2

runcmd:

   - sed -i -e '/^PermitRootLogin/s/^.*$/PermitRootLogin no/' /etc/ssh/sshd_config

   - sed -i 's|[#]*PasswordAuthentication yes|PasswordAuthentication no|g' /etc/ssh/sshd_config

Assuming all SSH keys are set up correctly on your local workstation, you should be able to log in and verify changes have been made.

The cloud-init documentation offers some useful, practical examples. It might take some time and tinkering to achieve the exact setup desired, but the entry point is much lower, which makes it attractive as a quick and easy solution to simple standardized configurations.

Dig Deeper on Systems automation and orchestration