mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 17:09:03 +00:00
261 lines
7.3 KiB
ReStructuredText
261 lines
7.3 KiB
ReStructuredText
========================
|
|
Cloud deployment scripts
|
|
========================
|
|
|
|
Salt Cloud works primarily by executing a script on the virtual machines as
|
|
soon as they become available. The script that is executed is referenced in the
|
|
cloud profile as the ``script``. In older versions, this was the ``os``
|
|
argument. This was changed in 0.8.2.
|
|
|
|
A number of legacy scripts exist in the deploy directory in the saltcloud
|
|
source tree. The preferred method is currently to use the salt-bootstrap
|
|
script. A stable version is included with each release tarball starting with
|
|
0.8.4. The most updated version can be found at:
|
|
|
|
https://github.com/saltstack/salt-bootstrap
|
|
|
|
Note that, somewhat counter-intuitively, this script is referenced as
|
|
``bootstrap-salt`` in the configuration.
|
|
|
|
You can specify a deploy script in the cloud configuration file
|
|
(``/etc/salt/cloud`` by default):
|
|
|
|
.. code-block:: yaml
|
|
|
|
script: bootstrap-salt
|
|
|
|
|
|
Or in a provider:
|
|
|
|
.. code-block:: yaml
|
|
|
|
my-provider:
|
|
# snip...
|
|
script: bootstrap-salt
|
|
|
|
|
|
Or in a profile:
|
|
|
|
.. code-block:: yaml
|
|
|
|
my-profile:
|
|
provider: my-provider
|
|
# snip...
|
|
script: bootstrap-salt
|
|
|
|
|
|
If you do not specify a script argument in your cloud configuration file,
|
|
provider configuration or profile configuration, the "bootstrap-salt" script
|
|
will be used by default.
|
|
|
|
|
|
Other Generic Deploy Scripts
|
|
============================
|
|
If you want to be assured of always using the latest Salt Bootstrap script,
|
|
there are a few generic templates available in the deploy directory of your
|
|
saltcloud source tree:
|
|
|
|
.. code-block:: bash
|
|
|
|
curl-bootstrap
|
|
curl-bootstrap-git
|
|
python-bootstrap
|
|
wget-bootstrap
|
|
wget-bootstrap-git
|
|
|
|
|
|
These are example scripts which were designed to be customized, adapted, and
|
|
refit to meet your needs. One important use of them is to pass options to
|
|
the salt-bootstrap script, such as updating to specific git tags.
|
|
|
|
|
|
Custom Deploy Scripts
|
|
=====================
|
|
|
|
If the Salt Bootstrap script does not meet your needs, you may write your own.
|
|
The script should be written in shell and is a Jinja template. Deploy scripts
|
|
need to execute a number of functions to do a complete salt setup. These
|
|
functions include:
|
|
|
|
1. Install the salt minion. If this can be done via system packages this method
|
|
is HIGHLY preferred.
|
|
2. Add the salt minion keys before the minion is started for the first time.
|
|
The minion keys are available as strings that can be copied into place in
|
|
the Jinja template under the dict named "vm".
|
|
3. Start the salt-minion daemon and enable it at startup time.
|
|
4. Set up the minion configuration file from the "minion" data available in
|
|
the Jinja template.
|
|
|
|
A good, well commented example of this process is the Fedora deployment
|
|
script:
|
|
|
|
https://github.com/saltstack/salt/blob/develop/salt/cloud/deploy/Fedora.sh
|
|
|
|
A number of legacy deploy scripts are included with the release tarball. None
|
|
of them are as functional or complete as Salt Bootstrap, and are still included
|
|
for academic purposes.
|
|
|
|
Custom deploy scripts are picked up from ``/etc/salt/cloud.deploy.d`` by
|
|
default, but you can change the location of deploy scripts with the cloud
|
|
configuration ``deploy_scripts_search_path``. Additionally, if your deploy
|
|
script has the extension ``.sh``, you can leave out the extension in your
|
|
configuration.
|
|
|
|
For example, if your custom deploy script is located in
|
|
``/etc/salt/cloud.deploy.d/my_deploy.sh``, you could specify it in a cloud
|
|
profile like this:
|
|
|
|
.. code-block:: yaml
|
|
|
|
my-profile:
|
|
provider: my-provider
|
|
# snip...
|
|
script: my_deploy
|
|
|
|
You're also free to use the full path to the script if you like. Using full
|
|
paths, your script doesn't have to live inside ``/etc/salt/cloud.deploy.d`` or
|
|
whatever you've configured with ``deploy_scripts_search_path``.
|
|
|
|
|
|
Post-Deploy Commands
|
|
====================
|
|
|
|
Once a minion has been deployed, it has the option to run a salt command.
|
|
Normally, this would be the :py:func:`state.apply <salt.modules.state.apply_>`,
|
|
which would finish provisioning the VM. Another common option (for testing) is
|
|
to use :py:func:`test.ping <salt.modules.test.ping>`. This is configured in the
|
|
main cloud config file:
|
|
|
|
.. code-block:: yaml
|
|
|
|
start_action: state.apply
|
|
|
|
|
|
This is currently considered to be experimental functionality, and may not work
|
|
well with all cloud hosts. If you experience problems with Salt Cloud hanging
|
|
after Salt is deployed, consider using Startup States instead:
|
|
|
|
http://docs.saltstack.com/ref/states/startup.html
|
|
|
|
|
|
Skipping the Deploy Script
|
|
==========================
|
|
|
|
For whatever reason, you may want to skip the deploy script altogether. This
|
|
results in a VM being spun up much faster, with absolutely no configuration.
|
|
This can be set from the command line:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-cloud --no-deploy -p micro_aws my_instance
|
|
|
|
|
|
Or it can be set from the main cloud config file:
|
|
|
|
.. code-block:: yaml
|
|
|
|
deploy: False
|
|
|
|
|
|
Or it can be set from the provider's configuration:
|
|
|
|
.. code-block:: yaml
|
|
|
|
RACKSPACE.user: example_user
|
|
RACKSPACE.apikey: 123984bjjas87034
|
|
RACKSPACE.deploy: False
|
|
|
|
|
|
Or even on the VM's profile settings:
|
|
|
|
.. code-block:: yaml
|
|
|
|
ubuntu_aws:
|
|
provider: my-ec2-config
|
|
image: ami-7e2da54e
|
|
size: t1.micro
|
|
deploy: False
|
|
|
|
|
|
The default for deploy is True.
|
|
|
|
In the profile, you may also set the script option to ``None``:
|
|
|
|
.. code-block:: yaml
|
|
|
|
script: None
|
|
|
|
|
|
This is the slowest option, since it still uploads the None deploy script and
|
|
executes it.
|
|
|
|
|
|
Updating Salt Bootstrap
|
|
=======================
|
|
Salt Bootstrap can be updated automatically with ``salt-cloud``:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-cloud -u
|
|
salt-cloud --update-bootstrap
|
|
|
|
|
|
Bear in mind that this updates to the latest **stable** version from:
|
|
|
|
https://bootstrap.saltstack.com/stable/bootstrap-salt.sh
|
|
|
|
To update Salt Bootstrap script to the **develop** version, run the following
|
|
command on the Salt minion host with ``salt-cloud`` installed:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-call config.gather_bootstrap_script 'https://bootstrap.saltstack.com/develop/bootstrap-salt.sh'
|
|
|
|
Or just download the file manually:
|
|
|
|
.. code-block:: bash
|
|
|
|
curl -L 'https://bootstrap.saltstack.com/develop' > /etc/salt/cloud.deploy.d/bootstrap-salt.sh
|
|
|
|
|
|
Keeping /tmp/ Files
|
|
===================
|
|
When Salt Cloud deploys an instance, it uploads temporary files to /tmp/ for
|
|
salt-bootstrap to put in place. After the script has run, they are deleted. To
|
|
keep these files around (mostly for debugging purposes), the --keep-tmp option
|
|
can be added:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-cloud -p myprofile mymachine --keep-tmp
|
|
|
|
|
|
For those wondering why /tmp/ was used instead of /root/, this had to be done
|
|
for images which require the use of sudo, and therefore do not allow remote
|
|
root logins, even for file transfers (which makes /root/ unavailable).
|
|
|
|
|
|
Deploy Script Arguments
|
|
=======================
|
|
Custom deploy scripts are unlikely to need custom arguments to be passed to
|
|
them, but salt-bootstrap has been extended quite a bit, and this may be
|
|
necessary. script_args can be specified in either the profile or the map file,
|
|
to pass arguments to the deploy script:
|
|
|
|
.. code-block:: yaml
|
|
|
|
aws-amazon:
|
|
provider: my-ec2-config
|
|
image: ami-1624987f
|
|
size: t1.micro
|
|
ssh_username: ec2-user
|
|
script: bootstrap-salt
|
|
script_args: -c /tmp/
|
|
|
|
|
|
This has also been tested to work with pipes, if needed:
|
|
|
|
.. code-block:: yaml
|
|
|
|
script_args: | head
|