Salt, the Open Source DevOps platform from SaltStack has great support for deploying VMs across multiple clouds using salt-cloud. Salt-cloud bootstraps machines with the Salt agent, connects them to the master and you’re ready to roll. But deploying an application in the cloud is always more than just a VM.

Cloud Automation in DevOps

Whilst writing “multi-cloud what are the options” last year, I realised there was a gap. For a developer, you have a range of options, jClouds for Java, Apache Libcloud for Libretto for Go. But there is still a gap, to deploy infrastructure, declarative tools can give a more consistent approach, without having to write an application to deploy a load balancer. Hashicorp Terraform provides a great solution, but without any abstraction between clouds and with little support for the main 3 platforms.

State modules for Cloud

In 2016.11.4, the current stable release of Salt, there is support for declarative infrastructure management in Amazon Web Services only, there are no modules for managing Azure Resource Manager for example, or Google Compute Platform.

In the develop branch of Salt, I’ve contributed 4 new execution modules and 3 new state modules for managing infrastructure across 50+ cloud platforms using SLS states and the Salt CLI. These are based on the existing support and functionality offered in Apache Libcloud 2.0.

So what can I do now?

1- DNS Management

The often forgotten problem in infrastructure, if you were to entirely place your DNS infrastructure in a single platform your application could be taken offline by an outage. DNS already has a built-in failover solution in NS records, so with suitable registrar nameserver records, you can propagate your DNS to multiple cloud platforms with a single state file. Or you could use SLS templating to set the A records to a new server. You can also access the DNS API using the execution module and call cloud-specific functions like multi-value records in Route53.

Apache Libcloud already supports 28 DNS providers.

2- Object Storage

Apache Libcloud supports S3, Google Storage, Azure Blobs, Ceph and OpenStack Swift as well as many other storage platforms.

Using the Salt CLI, you can query any of your configured storage platforms, looking at containers (or buckets), objects and metadata.

You can upload or download storage objects to any of your minions, using the same command for every storage platform.

Storage objects and containers can be synced between minions, clouds and masters using the libcloud_storage state module.

The execution module can be used to copy files between storage APIs, as a backup or failover site.

3- Load balancer management

Apache Libcloud has native support for Application Load Balancers, covering Amazon’s ELB and ALB services, as well as the Google Compute Engine. Using the libcloud_loadbalancer state module, you can deploy ALB’s across multiple clouds

Cloud-specific parameters, such as session-persistence algorithms or ramp up/down scheduling can still be accessed through the SLS states or via the execution module. All states can be combined with either multiple clouds, multiple cloud accounts (such as GCP projects).

4- VM Management

Apache Libcloud offers a compute (IaaS) abstraction API covering every major cloud platform in the world (around 50).

The libcloud_compute execution module gives users access to query VMs, detachable storage volumes, keypairs, networks and locations across any of these clouds.

Accessing Cloud-specific features

Some cloud APIs have additional methods that are prefixed with ex_ in Apache Libcloud, these methods are part of the non-standard API but can still be accessed from the Salt modules for libcloud_compute, libcloud_storage, libcloud_loadbalancer and libcloud_dns. The extra methods are available via the extra command, which expects the name of the method as the first argument, the profile as the second and then accepts a list of keyword arguments to pass onto the driver method, for example, accessing permissions in Google Storage objects:

$ salt myminion libcloud_storage.extra ex_get_permissions google container_name=my_container object_name=me.jpg --out=yaml

or accessing a platform specific argument, such as the GCP region

$ salt myminion libcloud_storage.create_balancer my_balancer 80 http profile1 ex_region=us-east1

$ salt myminion libcloud_storage.list_container_objects my_bucket profile1 ex_prefix=me_

Extended parameters can be passed to the specific cloud, for example you can specify the region with the Google Cloud API, because create_balancer can accept a ex_region argument. Adding this argument to the state will pass the additional command to the driver.