valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 00:55:19 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

various improvements on cloud deploy script docs (#32659)

Browse Source
This commit is contained in:
Andreas Lutro 2016-04-25 22:00:24 +02:00 committed by Nicole Thomas
parent bf85987d7c
commit 3b81031d5b
1 changed files with 77 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
doc/topics/cloud/deploy.rst
View File

@ -1,5 +1,5 @@
========================
OS Support for Cloud VMs
Cloud deployment scripts
========================
Salt Cloud works primarily by executing a script on the virtual machines as
@ -14,31 +14,39 @@ script. A stable version is included with each release tarball starting with
https://github.com/saltstack/salt-bootstrap
If you do not specify a script argument, this script will be used at the
default.
Note that, somewhat counter-intuitively, this script is referenced as
``bootstrap-salt`` in the configuration.
If the Salt Bootstrap script does not meet your needs, you may write your own.
The script should be written in bash and is a Jinja template. Deploy scripts
need to execute a number of functions to do a complete salt setup. These
functions include:
You can specify a deploy script in the cloud configuration file
(``/etc/salt/cloud`` by default):
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.
.. code-block:: yaml
A good, well commented, example of this process is the Fedora deployment
script:
script: bootstrap-salt
https://github.com/saltstack/salt-cloud/blob/master/saltcloud/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.
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
@ -61,6 +69,54 @@ 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-cloud/blob/master/saltcloud/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
====================