News

"cloudscale_ch.cloud" Ansible collection

In addition to Terraform, Ansible is one of the most popular IT orchestration tools. At cloudscale.ch, we use Ansible internally to, for example, manage our network components and almost the whole cloud infrastructure. It goes without saying that we also endeavor to make the configuration and operation of cloud resources as simple as possible for our customers, too.

With Ansible 2.10, development and maintenance of community plug-ins were outsourced to what are known as "collections". Many plug-ins found a new home in the "community.general" collection, while for others, such as the cloudscale.ch integration, development was split into separate source code repositories and organizations to allow faster development and individual release cycles. Today, there are already about 75 self-organized collections for Ansible 2.10.

Our own "cloudscale_ch.cloud" Ansible collection provides us with several advantages at once: on the one hand, we are able to replicate extensions to our API in our plug-ins within a short period of time, and on the other hand, it is easier to test our plug-ins in an automated manner independently of the rest of the Ansible project.

The suitable version for any requirement

With releases every three weeks, Ansible 2.10 also contains the latest releases of the collections, which means that the most recent version of "cloudscale_ch.cloud" is always automatically supplied and installed with the official Ansible package. If you would like to use a specific feature scope outside this release cycle, you can take matters into your own hands with ansible-galaxy and use the preferred version of our collection with your existing Ansible version.

For reasons of traceability, we recommend that you create a requirements.yml file to maintain an overview of all external collections and roles:

collections:
  - name: cloudscale_ch.cloud
    version: 1.3.0

The collection can then be installed as usual via ansible-galaxy:

ansible-galaxy collection install -r requirements.yml

Please note that existing playbooks will continue to work without adjustments. It is only essential to use the "fully qualified collection name" (FQCN) for plug-ins that have been newly added since Ansible 2.10. At the same time, there is no reason not to make a general switch to FQCN in existing playbooks, too.

Without FQCN as before:

- cloudscale_server:
    name: web1.example.com
    ...

Or with FQCN:

- cloudscale_ch.cloud.server:
    name: web1.example.com
    ...

Example 1: Network management with subnets

The network API was integrated into version 1.2.0 of our collection. Subnets can now also be managed with the most recent version 1.3.0, which allows the creation of new subnets as well as the adjustment of the gateway IP and DNS servers for existing subnets:

- name: Ensure network exists
  cloudscale_ch.cloud.network:
    name: Private in LPG1
    zone: lpg1
    auto_create_ipv4_subnet: false

- name: Ensure subnet exists
  cloudscale_ch.cloud.subnet:
    cidr: 10.11.0.0/16
    gateway_address: 10.11.0.1
    dns_servers:
      - 10.11.0.2
      - 10.11.0.3
    network:
      name: Private in LPG1
      zone: lpg1

Example 2: Objects Users

The module for Objects Users management was already added with version 1.1.0 of our collection (and therefore also in Ansible 2.10.0), thus enabling, for example, the automated creation of a backup configuration using our Object Storage:

- name: Create a backup user
  cloudscale_ch.cloud.objects_user:
    display_name: backup for ACME
    tags:
      customer: ACME Inc.
  register: res_object_user

- name: Configure S3cfg
  template:
    src: s3cfg.j2
    dest: ~/.s3cfg

In the s3cfg.j2 template, we use the keys returned by the module:

# {{ ansible_managed }}
[default]
access_key = {{ res_object_user.keys.access_key }}
secret_key = {{ res_object_user.keys.secret_key }}
check_ssl_certificate = True
guess_mime_type = True
host_base = objects.lpg.cloudscale.ch
host_bucket = objects.lpg.cloudscale.ch
use_https = True

Example 3: Floating IPs

Existing modules have also undergone improvements, which mean that it is now possible to create Floating IPs idempotently. This was implemented by means of an additional name parameter. To ensure backwards compatibility, this parameter is currently still optional. It will only become mandatory to specify this parameter from the next major version of our collection onwards.

- name: Start cloudscale.ch server
  cloudscale_ch.cloud.server:
    name: mx1.example.com
    image: debian-10
    flavor: flex-2
    ssh_keys: ssh-rsa XXXXXXXXXX...XXXX ansible@cloudscale-ch
    zone: lpg1
  register: server

- name: Request Floating IPs for my server
  cloudscale_ch.cloud.floating_ip:
    name: mx1.example.com
    ip_version: "{{ item }}"
    reverse_ptr: mx1.example.com
    server: "{{ server.uuid }}"
  with_items:
    - 4
    - 6

Ansible and our "cloudscale_ch.cloud" collection provide you with a powerful, yet simple tool to create and operate a larger-scale cloud infrastructure quickly and transparently. And for everyone who (like us) is committed to open source: the source code of our collection is available on GitHub under GPLv3.

Proud to be part of the Ansible universe,
Your cloudscale.ch team