As well as sending configurations to your current systems, Salt can be used to manage virtual machines without regard to their location. These virtual machines may be cloud based or on-prem. Imagine this, you need to deploy a virtual machine to test website development. You can easily deploy the system, and once deployed the web server and current content can be delivered reliably with Salt, locally or to the cloud.
Salt Cloud is an additional suite of tools that can be deployed with or without an existing Salt Master. The Salt Master deploys as a dependency to Salt Cloud if not already present. Salt Cloud is used to manage virtual machine instances and, optionally, works with Salt delivering Salt Minion software and the address of the Salt Master as part of the VM deployment. In this chapter, we will
Install Salt Cloud.
Configure cloud providers.
Configure cloud profiles.
Deploy AWS cloud systems.
List cloud systems.
Delete cloud systems.
Installing Salt Cloud
For this demonstration, we will work with the Salt Master system adding in the Salt Cloud Python tools. We will use AWS for our cloud system. Free accounts are available for 12 months on AWS as well as other cloud platforms.
Installing the Salt Master using the option
-L from the bootstrap installer will also add Salt Cloud and the associated Python cloud libraries. If you did not include the option when installing the Salt Master, then you can install Salt Cloud easily from the command line. It will do no harm to try the install in any case. Once installed, the option
--version will show the version of Salt Cloud, whereas the option
-V displays the full version report. This is shown in Listing
12-1.
root@master:~# apt install salt-cloud
root@master:~# salt-cloud --version
salt-cloud 3003
root@master:~# salt-cloud -V
Salt Version:
Salt: 3003
Dependency Versions:
Apache Libcloud: 2.8.0
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.7.3
docker-py: Not Installed
gitdb: 2.0.6
gitpython: 3.0.7
Jinja2: 2.10.1
libgit2: Not Installed
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: 3.10.1
pygit2: Not Installed
Python: 3.8.5 (default, May 27 2021, 13:30:53)
python-gnupg: 0.4.5
PyYAML: 5.3.1
PyZMQ: 22.0.3
smmap: 2.0.5
timelib: Not Installed
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: ubuntu 20.04 focal
locale: utf-8
machine: x86_64
release: 5.4.0-74-generic
system: Linux
version: Ubuntu 20.04 focal
root@master:~# file $(which salt-cloud)
/usr/bin/salt-cloud: Python script, ASCII text executable
Listing 12-1Installing Salt Cloud on the Salt Master
Emphasizing the relationship with Python, Salt Cloud, as with the other subsystems, is written in Python.
Configuring Salt Cloud
Default configuration settings for Salt Cloud are displayed in the file /etc/salt/cloud. Changes to the defaults can be made with any .conf file placed in the /etc/salt/cloud.conf.d/ directory. This is the same idea as implemented with the Salt Minion and Salt Master, as we have already seen. Additionally, the Salt Cloud configuration requires a list of cloud providers and cloud profiles.
Cloud Providers
Cloud providers
describe how connections should be managed to your public and private clouds. This could even be
Vagrant should you want; however, for Vagrant to work, the host system that you have Vagrant installed on must be a Minion enrolled to the Salt Master that Salt Cloud runs on. I prefer to keep my host OS separate from any of my labs that it runs. For that reason, I will demonstrate Salt Cloud with AWS. In Listing
12-2, you will see a sample AWS provider configuration for AWS.
root@master:~# vim /etc/salt/cloud.providers.d/aws.conf
aws:
driver: ec2
id: <your aws id>
key: <your aws authentication key>
securitygroup: AllOpen
keyname: awslondon
private_key: /root/.ssh/awslondon.pem
location: eu-west-2
Listing 12-2AWS Cloud Provider
As is the normal, configuration files of this type are written in YAML. The dictionary aws configures the name of the provider. This can be any name, but aws does seem a useful name. The driver though has to be set to ec2 to use AWS as a cloud provider.
The
id and
key are obtained from your account details in AWS. Log in to you EC2 Console. From your account details from the top right of the AWS page, choose “
My Security Credentials.” From the Security Credentials page, select the tab “
Access keys (access key ID and secret access key).” From here you can create a new
id and
key that you use as authentication credentials. Having created a provider – and of course, we can have multiple providers within the same file or even different files – we can list configured providers. This is shown in the following command with output:
root@master:~# salt-cloud --list-providers
aws:
----------
ec2:
----------
This shows the provider that we have named
aws using the Salt Cloud driver
ec2. The driver
ec2 that we have selected in a Python module exists as a file called
ec2.py. In the following output from the Linux
find command, we see the Salt Cloud
module
that we reference but that in turn will use the
libcloud driver
ec2.py:
root@master:~# find /usr/lib -name 'ec2.py'
/usr/lib/python3/dist-packages/salt/cloud/clouds/ec2.py
/usr/lib/python3/dist-packages/libcloud/compute/drivers/ec2.py
Cloud Profiles
Salt
Cloud profiles
are configured within the
/etc/salt/cloud.profiles.d/ directory. Creating files with the
.conf extension in this directory will allow us to define profiles or templates used to provision virtual machine instances. The format will differ slightly depending on the cloud provider used. The
size attribute
is defined by available sizes from the provider, and the
image attribute
depends on the available images. Salt Cloud can deploy the Salt Minion software and configure the Salt Minion settings. The profile example in Listing
12-3 does not deploy the Salt Minion.
root@master:~# vim /etc/salt/cloud.profiles.d/profiles.conf
ubuntu:
#Ubuntu 20.04
provider: aws
image: ami-096cb92bb3580c759
size: t2.micro
ssh_username: ubuntu
deploy: False
del_all_vol_on_destroy: True
del_root_vol_on_destroy: True
Listing 12-3Example Profile Without Agent
This again is in YAML
format
, and we define the profile, which we have called
ubuntu. The
provider attribute
is used to link to our named provider,
aws. The
deploy attribute
defaults to True; we have explicitly set it to
False to prevent deployment of the Salt Minion for this profile. We will create another profile that
will deploy the same Ubuntu system and the Salt Minion. We append to the same file, adding the additional profile as shown in Listing
12-4.
root@master:~# vim /etc/salt/cloud.profiles.d/profiles.conf
ubuntu:
#Ubuntu 20.04
provider: aws
image: ami-096cb92bb3580c759
size: t2.micro
ssh_username: ubuntu
deploy: False
del_all_vol_on_destroy: True
del_root_vol_on_destroy: True
ubuntu-salt:
#Ubuntu20.04
provider: aws
image: ami-096cb92bb3580c759
size: t2.micro
ssh_username: ubuntu
ssh_interface: public_ips
del_all_vol_on_destroy: True
del_root_vol_on_destroy: True
minion:
master: 18.130.247.42
id: minion3
Listing 12-4Profile Deploying Salt Minion
Each profile needs a unique name. Here we set it to ubuntu-salt. We have added the attribute ssh_interface. This can be set to public_ips or private_ips and defines how the Salt Cloud system should connect when deploying the bootstrap installer. Using another AWS system for Salt Cloud, you can use private_ips; else, you will need public_ips to be able to connect from outside of AWS. We also add the Minion configuration within the deployment, setting the address of the Salt Master and the Minion ID to use. If we are deploying more than one system, I would not set the ID, allowing the Salt Minion to use the FQDN of the system.
To retrieve a list of profiles, we are able to use the
--list-profiles option with the argument of
all or the named provider to search. Listing
12-5 provides the configured AWS
profiles
.
root@master:~# salt-cloud --list-profiles aws
ubuntu:
----------
aws:
----------
ubuntu-salt:
----------
aws:
----------
Listing 12-5Listing Profiles from Salt Cloud
Managing Virtual Machine Instances Using Salt Cloud
Salt Cloud is much more than just this configuration. It allows for the creation and ongoing management of your virtual machine instances. These instances may be in-house or in the public cloud. Either way, they can be managed with the single command line tool salt-cloud.
Provisioning Virtual Machines
Our first port of call is to create or
provision
the virtual machine instances. To create a simple single virtual machine is really easy. The following demonstrates this but requires a working AWS account and configured profile:
root@master:~# salt-cloud -p ubuntu vm101
The option
-p is the profile we want to use, and the argument
vm101 is the name of the virtual machine instance that we are creating. The output will be quite verbose, and it takes a little time for the public IP address to be detected. Once complete, we are able to see the complete instance details. We can also create multiple instances at the same time, as shown in the following listing:
root@salt-cloud:~# salt-cloud -p ubuntu vm102 vm103
Later, we can review these settings, or the most important setting using the option
-Q (Listing
12-6).
root@master:~# salt-cloud -Q
aws:
----------
ec2:
----------
vm101:
----------
id:
i-03be1da36a64d23a0
image:
ami-096cb92bb3580c759
name:
vm101
private_ips:
172.31.35.36
public_ips:
18.133.76.113
size:
t2.micro
state:
running
vm102:
----------
id:
i-0d544b63e2042c74d
image:
ami-096cb92bb3580c759
name:
vm102
private_ips:
172.31.46.110
public_ips:
18.132.12.184
size:
t2.micro
state:
running
vm103:
----------
id:
i-050f48582978f46d7
image:
ami-096cb92bb3580c759
name:
vm103
private_ips:
172.31.42.236
public_ips:
3.8.166.121
size:
t2.micro
state:
running
Listing 12-6Query VM Instances
We can now see both the internal and public IP addresses of the three virtual machines. Outside of AWS we can connect using the public address and from inside we can use either address
.
Deleting Instances
When we are finished with the
instances, we can delete them as easily as they were created. The option
-d is used to delete the instances. Adding the additional option
-y enters yes to all prompts. The output in Listing
12-7 has been included allowing you to see that the instance name changes during the deletion to include DEL in the name.
root@salt-cloud:~# salt-cloud -yd vm101 vm102 vm103
aws:
----------
ec2:
----------
vm101:
----------
currentState:
----------
code:
32
name:
shutting-down
instanceId:
i-03be1da36a64d23a0
newname:
vm101-DEL0338e0f5bc0c43c48b7fbc3668b5b542
previousState:
----------
code:
16
name:
running
vm102:
----------
currentState:
----------
code:
32
name:
shutting-down
instanceId:
i-0d544b63e2042c74d
newname:
vm102-DEL1608407b409347d0863244db64f3e43a
previousState:
----------
code:
16
name:
running
vm103:
----------
currentState:
----------
code:
32
name:
shutting-down
instanceId:
i-050f48582978f46d7
newname:
vm103-DELd6ce01eaabd1431b8a07d4e600029a88
previousState:
----------
code:
16
name:
running
Listing 12-7Using Salt on New Minion
Summary
Being able to manage virtual machines with a simple interface without regard to the hosting system used is both desirable and deliverable when using Salt Cloud. In addition to this simplicity, installing the Salt Minion can be included as part of the instance creation, making the new systems manageable by Salt very quickly after the installation and adding to the reasons to use Salt as your main configuration management system.
