mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Add lots of anchor tags.
This commit is contained in:
Michael DeHaan
parent
111b3578d6
commit
b0d5033386
6 changed files with 181 additions and 154 deletions
|
|
@ -35,6 +35,8 @@ and then we'll get going.
|
|||
.. contents::
|
||||
:depth: 2
|
||||
|
||||
.. _parallelism_and_shell_commands:
|
||||
|
||||
Parallelism and Shell Commands
|
||||
``````````````````````````````
|
||||
|
||||
|
|
@ -108,6 +110,7 @@ simple scripts. They make the remote system look like you state, and run the com
|
|||
get it there. This is commonly referred to as 'idempotence', and is a core design goal of ansible.
|
||||
However, we also recognize that running arbitrary commands is equally important, so Ansible easily supports both.
|
||||
|
||||
.. _file_transfer:
|
||||
|
||||
File Transfer
|
||||
`````````````
|
||||
|
|
@ -135,6 +138,7 @@ As well as delete directories (recursively) and delete files::
|
|||
|
||||
$ ansible webservers -m file -a "dest=/path/to/c state=absent"
|
||||
|
||||
.. _managing_packages:
|
||||
|
||||
Managing Packages
|
||||
`````````````````
|
||||
|
|
@ -163,6 +167,8 @@ does not have a module available for it, you can install
|
|||
for other packages using the command module or (better!) contribute a module
|
||||
for other package managers. Stop by the mailing list for info/details.
|
||||
|
||||
.. _users_and_groups:
|
||||
|
||||
Users and Groups
|
||||
````````````````
|
||||
|
||||
|
|
@ -177,6 +183,8 @@ exist::
|
|||
See the :doc:`modules` section for details on all of the available options, including
|
||||
how to manipulate groups and group membership.
|
||||
|
||||
.. _from_source_control:
|
||||
|
||||
Deploying From Source Control
|
||||
`````````````````````````````
|
||||
|
||||
|
|
@ -189,6 +197,8 @@ tell ansible to run specific tasks when the code is updated, such as
|
|||
deploying Perl/Python/PHP/Ruby directly from git and then restarting
|
||||
apache.
|
||||
|
||||
.. _managing_services:
|
||||
|
||||
Managing Services
|
||||
`````````````````
|
||||
|
||||
|
|
@ -204,6 +214,8 @@ Ensure a service is stopped::
|
|||
|
||||
$ ansible webservers -m service -a "name=httpd state=stopped"
|
||||
|
||||
.. _time_limited_background_operations:
|
||||
|
||||
Time Limited Background Operations
|
||||
``````````````````````````````````
|
||||
|
||||
|
|
@ -233,6 +245,8 @@ the remote nodes will be terminated.
|
|||
Typically you'll be only be backgrounding long-running
|
||||
shell commands or software upgrades only. Backgrounding the copy module does not do a background file transfer. :doc:`playbooks` also support polling, and have a simplified syntax for this.
|
||||
|
||||
.. _checking_facts:
|
||||
|
||||
Gathering Facts
|
||||
```````````````
|
||||
|
||||
|
|
@ -245,6 +259,8 @@ Its also possible to filter this output to just export certain facts, see the "s
|
|||
|
||||
Read more about facts at :doc:`playbooks_variables` once you're ready to read up on :doc:`playbooks`.
|
||||
|
||||
.. _limiting_hosts:
|
||||
|
||||
Limiting Selected Hosts
|
||||
```````````````````````
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,8 @@ The last file in the list is found and the others will be ignored.
|
|||
.. contents::
|
||||
:depth: 2
|
||||
|
||||
.. _getting_the_latest_configuration:
|
||||
|
||||
Getting the latest configuration
|
||||
````````````````````````````````
|
||||
|
||||
|
|
@ -31,6 +33,8 @@ default settings in Ansible.
|
|||
You may wish to consult the `ansible.cfg in source control <https://raw.github.com/ansible/ansible/devel/examples/ansible.cfg>_` for
|
||||
all of the possible latest values.
|
||||
|
||||
.. _environmental_configuration:
|
||||
|
||||
Environmental configuration
|
||||
```````````````````````````
|
||||
|
||||
|
|
@ -39,14 +43,20 @@ override any setting loaded from the configuration file. These variables are fo
|
|||
in the source tree if you want to use these. They are mostly considered to be a legacy system as compared to the config file, but
|
||||
are equally valid.
|
||||
|
||||
.. _config_values_by_section:
|
||||
|
||||
Explanation of values by section
|
||||
````````````````````````````````
|
||||
|
||||
.. _general_defaults:
|
||||
|
||||
General defaults
|
||||
----------------
|
||||
|
||||
In the [defaults] section of ansible.cfg, the following settings are tunable:
|
||||
|
||||
.. _action_plugins:
|
||||
|
||||
action_plugins
|
||||
==============
|
||||
|
||||
|
|
@ -59,6 +69,8 @@ different locations::
|
|||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details.
|
||||
|
||||
.. _ansible_managed:
|
||||
|
||||
ansible_managed
|
||||
===============
|
||||
|
||||
|
|
@ -73,6 +85,8 @@ The default configuration shows who modified a file and when::
|
|||
|
||||
This is useful to tell users that a file has been placed by Ansible and manual changes are likely to be overwritten.
|
||||
|
||||
.. _ask_pass:
|
||||
|
||||
ask_pass
|
||||
========
|
||||
|
||||
|
|
@ -82,6 +96,8 @@ This controls whether an Ansible playbook should prompt for a password by defaul
|
|||
|
||||
If using SSH keys for authentication, it's probably not needed to change this setting.
|
||||
|
||||
.. _ask_sudo_pass:
|
||||
|
||||
ask_sudo_pass
|
||||
=============
|
||||
|
||||
|
|
@ -92,6 +108,8 @@ sudoing. The default behavior is also no::
|
|||
|
||||
Users on platforms where sudo passwords are enabled should consider changing this setting.
|
||||
|
||||
.. _callback_plugins:
|
||||
|
||||
callback_plugins
|
||||
================
|
||||
|
||||
|
|
@ -102,6 +120,8 @@ different locations::
|
|||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
|
||||
.. _connection_plugins:
|
||||
|
||||
connection_plugins
|
||||
==================
|
||||
|
||||
|
|
@ -112,6 +132,8 @@ different locations::
|
|||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
|
||||
.. _display_skipped_hosts:
|
||||
|
||||
display_skipped_hosts
|
||||
=====================
|
||||
|
||||
|
|
@ -121,6 +143,8 @@ If set to `False`, ansible will not display any status for a task that is skippe
|
|||
|
||||
Note that Ansible will always show the task header for any task, regardless of whether or not the task is skipped.
|
||||
|
||||
.. _error_on_undefined_vars:
|
||||
|
||||
error_on_undefined_vars
|
||||
=======================
|
||||
|
||||
|
|
@ -132,6 +156,8 @@ typoed::
|
|||
If set to False, any '{{ template_expression }}' that contains undefined variables will be rendered in a template
|
||||
or ansible action line exactly as written.
|
||||
|
||||
.. _executable:
|
||||
|
||||
executable
|
||||
==========
|
||||
|
||||
|
|
@ -140,6 +166,20 @@ rare instances to /bin/bash in rare instances wehn sudo is constrained, but in m
|
|||
|
||||
#executable = /bin/bash
|
||||
|
||||
.. _filter_plugins:
|
||||
|
||||
filter_plugins
|
||||
==============
|
||||
|
||||
This is a developer-centric feature that allows low-level extensions around Ansible to be loaded from
|
||||
different locations::
|
||||
|
||||
action_plugins = /usr/share/ansible_plugins/action_plugins
|
||||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
|
||||
.. _forks:
|
||||
|
||||
forks
|
||||
=====
|
||||
|
||||
|
|
@ -151,24 +191,6 @@ is very very conservative::
|
|||
|
||||
forks=5
|
||||
|
||||
pattern
|
||||
=======
|
||||
|
||||
This is the default group of hosts to talk to in a playbook if no "hosts:" stanza is supplied. The default is to talk
|
||||
to all hosts. You may wish to change this to protect yourself from surprises::
|
||||
|
||||
hosts=*
|
||||
|
||||
Note that /usr/bin/ansible always requires a host pattern and does not use this setting, only /usr/bin/ansible-playbook.
|
||||
|
||||
poll_interval
|
||||
=============
|
||||
|
||||
For asynchronous tasks in Ansible (covered in :doc:`playbooks_async`), this is how often to check back on the status of those
|
||||
tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff
|
||||
between checking in frequently and providing a quick turnaround when something may have completed::
|
||||
|
||||
poll_interval=15
|
||||
|
||||
hash_behavior
|
||||
=============
|
||||
|
|
@ -184,6 +206,8 @@ official examples repos do not use this setting::
|
|||
|
||||
The valid values are either 'replace' (the default) or 'merge'.
|
||||
|
||||
.. _hostfile:
|
||||
|
||||
hostfile
|
||||
========
|
||||
|
||||
|
|
@ -192,6 +216,8 @@ to talk to::
|
|||
|
||||
hostfile = /etc/ansible/hosts
|
||||
|
||||
.. _host_key_checking:
|
||||
|
||||
host_key_checking
|
||||
=================
|
||||
|
||||
|
|
@ -200,15 +226,7 @@ implications and wish to disable it, you may do so here by setting the value to
|
|||
|
||||
host_key_checking=True
|
||||
|
||||
filter_plugins
|
||||
==============
|
||||
|
||||
This is a developer-centric feature that allows low-level extensions around Ansible to be loaded from
|
||||
different locations::
|
||||
|
||||
action_plugins = /usr/share/ansible_plugins/action_plugins
|
||||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
.. _jinja2_extensions:
|
||||
|
||||
jinja2_extensions
|
||||
=================
|
||||
|
|
@ -219,6 +237,8 @@ This is a developer-specific feature that allows enabling additional Jinja2 exte
|
|||
|
||||
If you do not know what these do, you probably don't need to change this setting :)
|
||||
|
||||
.. _legacy_playbook_variables:
|
||||
|
||||
legacy_playbook_variables
|
||||
=========================
|
||||
|
||||
|
|
@ -231,6 +251,8 @@ still enabled as of Ansible 1.4) can be disabled like so ::
|
|||
|
||||
legacy_playbook_variables = no
|
||||
|
||||
.. _library:
|
||||
|
||||
library
|
||||
=======
|
||||
|
||||
|
|
@ -241,6 +263,8 @@ This is the default location Ansible looks to find modules::
|
|||
Ansible knows how to look in multiple locations if you feed it a colon seperated path, and it also will look for modules in the
|
||||
"./library" directory alongside a playbook.
|
||||
|
||||
.. _log_path:
|
||||
|
||||
log_path
|
||||
========
|
||||
|
||||
|
|
@ -251,6 +275,8 @@ the user running Ansible has permissions on the logfile.
|
|||
|
||||
This behavior is not on by default.
|
||||
|
||||
.. _lookup_plugins:
|
||||
|
||||
lookup_plugins
|
||||
==============
|
||||
|
||||
|
|
@ -261,6 +287,8 @@ different locations::
|
|||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
|
||||
.. _module_name:
|
||||
|
||||
module_name
|
||||
===========
|
||||
|
||||
|
|
@ -270,6 +298,8 @@ it to 'shell'::
|
|||
|
||||
module_name = command
|
||||
|
||||
.. _nocolor:
|
||||
|
||||
nocolor
|
||||
=======
|
||||
|
||||
|
|
@ -278,6 +308,8 @@ If you dislike this behavior you can turn it off by setting 'nocolor' to 0::
|
|||
|
||||
nocolor=0
|
||||
|
||||
.. _nocows:
|
||||
|
||||
nocows
|
||||
======
|
||||
|
||||
|
|
@ -287,6 +319,31 @@ by setting 'nocows' to 1::
|
|||
|
||||
nocows=0
|
||||
|
||||
.. _pattern:
|
||||
|
||||
pattern
|
||||
=======
|
||||
|
||||
This is the default group of hosts to talk to in a playbook if no "hosts:" stanza is supplied. The default is to talk
|
||||
to all hosts. You may wish to change this to protect yourself from surprises::
|
||||
|
||||
hosts=*
|
||||
|
||||
Note that /usr/bin/ansible always requires a host pattern and does not use this setting, only /usr/bin/ansible-playbook.
|
||||
|
||||
.. _poll_interval:
|
||||
|
||||
poll_interval
|
||||
=============
|
||||
|
||||
For asynchronous tasks in Ansible (covered in :doc:`playbooks_async`), this is how often to check back on the status of those
|
||||
tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff
|
||||
between checking in frequently and providing a quick turnaround when something may have completed::
|
||||
|
||||
poll_interval=15
|
||||
|
||||
.. _private_key_file:
|
||||
|
||||
private_key_file
|
||||
================
|
||||
|
||||
|
|
@ -295,6 +352,8 @@ value here to avoid re-specifying --ansible-private-keyfile with every invocatio
|
|||
|
||||
private_key_file=/path/to/file.pem
|
||||
|
||||
.. _remote_port:
|
||||
|
||||
remote_port
|
||||
===========
|
||||
|
||||
|
|
@ -303,6 +362,8 @@ The default is the standard 22::
|
|||
|
||||
remote_port = 22
|
||||
|
||||
.. _remote_tmp:
|
||||
|
||||
remote_tmp
|
||||
==========
|
||||
|
||||
|
|
@ -315,6 +376,8 @@ setting::
|
|||
The default is to use a subdirectory of the user's home directory. Ansible will then choose a random directory name
|
||||
inside this location.
|
||||
|
||||
.. _remote_user:
|
||||
|
||||
remote_user
|
||||
===========
|
||||
|
||||
|
|
@ -323,6 +386,7 @@ always default to the current user::
|
|||
|
||||
remote_user = root
|
||||
|
||||
.. _sudo_exe:
|
||||
|
||||
sudo_exe
|
||||
========
|
||||
|
|
@ -332,6 +396,8 @@ the sudo implementation is matching CLI flags with the standard sudo::
|
|||
|
||||
sudo_exe=sudo
|
||||
|
||||
.. _sudo_flags:
|
||||
|
||||
sudo_flags
|
||||
==========
|
||||
|
||||
|
|
@ -341,6 +407,8 @@ will not need to change this setting::
|
|||
|
||||
sudo_flags=-H
|
||||
|
||||
.. _sudo_user:
|
||||
|
||||
sudo_user
|
||||
=========
|
||||
|
||||
|
|
@ -349,6 +417,7 @@ playbook. The default is the most logical: 'root'::
|
|||
|
||||
sudo_user=root
|
||||
|
||||
.. _timeout:
|
||||
|
||||
timeout
|
||||
=======
|
||||
|
|
@ -357,6 +426,8 @@ This is the default SSH timeout to use on connection attempts::
|
|||
|
||||
timeout = 10
|
||||
|
||||
.. _transport:
|
||||
|
||||
transport
|
||||
=========
|
||||
|
||||
|
|
@ -367,6 +438,8 @@ technology, and then will otherwise use 'paramiko'. Other transport options inc
|
|||
Users should usually leave this setting as 'smart' and let their playbooks choose an alternate setting when needed with the
|
||||
'connection:' play parameter.
|
||||
|
||||
.. _vars_plugins:
|
||||
|
||||
vars_plugins
|
||||
============
|
||||
|
||||
|
|
@ -377,6 +450,7 @@ different locations::
|
|||
|
||||
Most users will not need to use this feature. See :doc:`developing_plugins` for more details
|
||||
|
||||
.. _paramiko_settings:
|
||||
|
||||
Paramiko Specific Settings
|
||||
--------------------------
|
||||
|
|
@ -384,6 +458,8 @@ Paramiko Specific Settings
|
|||
Paramiko is the default SSH connection implementation on Enterprise Linux 6 or earlier, and is not used by default on other
|
||||
platforms. Settings live under the [paramiko] header.
|
||||
|
||||
.. _record_host_keys:
|
||||
|
||||
record_host_keys
|
||||
================
|
||||
|
||||
|
|
@ -393,12 +469,16 @@ instead. Setting it to False will improve performance and is recommended when h
|
|||
|
||||
record_host_keys=True
|
||||
|
||||
.. _openssh_settings:
|
||||
|
||||
OpenSSH Specific Settings
|
||||
-------------------------
|
||||
|
||||
Under the [ssh] header, the following settings are tunable for SSH connections. OpenSSH is the default connection type for Ansible
|
||||
on OSes that are new enough to support ControlPersist. (This means basically all operating systems except Enterprise Linux 6 or earlier).
|
||||
|
||||
.. _ssh_args:
|
||||
|
||||
ssh_args
|
||||
========
|
||||
|
||||
|
|
@ -409,6 +489,8 @@ If set, this will pass a specific set of options to Ansible rather than Ansible'
|
|||
In particular, users may wish to raise the ControlPersist time to encourage performance. A value of 30 minutes may
|
||||
be appropriate.
|
||||
|
||||
.. _control_path:
|
||||
|
||||
control_path
|
||||
============
|
||||
|
||||
|
|
@ -427,6 +509,8 @@ Ansible 1.4 and later will instruct users to run with "-vvvv" in situations wher
|
|||
and if so it is easy to tell there is too long of a Control Path filename. This may be frequently
|
||||
encountered on EC2.
|
||||
|
||||
.. _scp_if_ssh:
|
||||
|
||||
scp_if_ssh
|
||||
==========
|
||||
|
||||
|
|
@ -438,11 +522,15 @@ cause scp to be used to transfer remote files instead::
|
|||
There's really no reason to change this unless problems are encountered, and then there's also no real drawback
|
||||
to managing the switch. Most environments support SFTP by default and this doesn't usually need to be changed.
|
||||
|
||||
.. _accelerate_settings:
|
||||
|
||||
Accelerate Mode Settings
|
||||
------------------------
|
||||
|
||||
Under the [accelerate] header, the following settings are tunable for :doc:`playbooks_acceleration`
|
||||
|
||||
.. _accelerate_port:
|
||||
|
||||
accelerate_port
|
||||
===============
|
||||
|
||||
|
|
@ -452,6 +540,8 @@ This is the port to use for accelerate mode::
|
|||
|
||||
accelerate_port = 5099
|
||||
|
||||
.. _accelerate_timeout:
|
||||
|
||||
accelerate_timeout
|
||||
==================
|
||||
|
||||
|
|
@ -461,6 +551,8 @@ This setting controls the timeout for receiving data from a client. If no data i
|
|||
|
||||
accelerate_timeout = 30
|
||||
|
||||
.. _accelerate_connect_timeout:
|
||||
|
||||
accelerate_connect_timeout
|
||||
==========================
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ Ansible easily supports all of these options via an external inventory system.
|
|||
|
||||
For information about writing your own, see :doc:`developing_inventory`.
|
||||
|
||||
.. _cobbler_example:
|
||||
|
||||
Example: The Cobbler External Inventory Script
|
||||
``````````````````````````````````````````````
|
||||
|
||||
|
|
@ -71,6 +73,8 @@ And technically, though there is no major good reason to do it, this also works
|
|||
|
||||
So in other words, you can use those variables in arguments/actions as well.
|
||||
|
||||
.. _aws_example:
|
||||
|
||||
Example: AWS EC2 External Inventory Script
|
||||
``````````````````````````````````````````
|
||||
|
||||
|
|
@ -182,6 +186,8 @@ To see the complete list of variables available for an instance, run the script
|
|||
Note that the AWS inventory script will cache results to avoid repeated API calls, and this cache setting is configurable in ec2.ini. To
|
||||
explicitly clear the cache, you can run the ec2.py script with the '--refresh-cache' parameter.
|
||||
|
||||
.. _other_inventory_scripts:
|
||||
|
||||
Other inventory scripts
|
||||
```````````````````````
|
||||
|
||||
|
|
@ -202,6 +208,8 @@ it should be very obvious how to use them. The process for the AWS inventory sc
|
|||
If you develop an interesting inventory script that might be general purpose, please submit a pull request -- we'd likely be glad
|
||||
to include it in the project.
|
||||
|
||||
.. _using_multiple_sources:
|
||||
|
||||
Using Multiple Inventory Sources
|
||||
````````````````````````````````
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ Getting Started
|
|||
.. contents::
|
||||
:depth: 2
|
||||
|
||||
.. _gs_about:
|
||||
|
||||
About
|
||||
`````
|
||||
|
||||
|
|
@ -16,6 +18,8 @@ Playbooks are covered in a seperate section.
|
|||
This is basically about how to get going initially. Once you have this down, read :doc:`intro_adhoc` for some more
|
||||
detail, and then you'll be ready to dive into playbooks.
|
||||
|
||||
.. _remote_connection_information:
|
||||
|
||||
Remote Connection Information
|
||||
`````````````````````````````
|
||||
|
||||
|
|
@ -39,6 +43,8 @@ While it may be common sense, it is worth sharing: Any management system benefit
|
|||
|
||||
As an advanced topic, ansible doesn't just have to connect remotely over SSH. The transports are pluggable, and there are options for managing things locally, as well as managing chroot, lxc, and jail containers. A mode called 'ansible-pull' can also invert the system and have systems 'phone home' via scheduled git checkouts to pull configuration directives from a central repository.
|
||||
|
||||
.. _your_first_commands:
|
||||
|
||||
Your first commands
|
||||
```````````````````
|
||||
|
||||
|
|
@ -98,6 +104,8 @@ what you can do with different modules, as well as the Ansible
|
|||
also has powerful configuration management and deployment features. There's more to
|
||||
explore, but you already have a fully working infrastructure!
|
||||
|
||||
.. _a_note_about_host_key_checking:
|
||||
|
||||
A note about Host Key Checking
|
||||
``````````````````````````````
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ Installation
|
|||
.. contents::
|
||||
:depth: 2
|
||||
|
||||
.. _getting_ansible:
|
||||
|
||||
Getting Ansible
|
||||
```````````````
|
||||
|
||||
|
|
@ -11,6 +13,8 @@ You may also wish to follow the `Github project <https://github.com/ansible/ansi
|
|||
you have a github account. This is also where we keep the issue tracker for sharing
|
||||
bugs and feature ideas.
|
||||
|
||||
.. _what_will_be_installed:
|
||||
|
||||
Basics / What Will Be Installed
|
||||
```````````````````````````````
|
||||
|
||||
|
|
@ -18,6 +22,8 @@ Ansible by default manages machines over the SSH protocol.
|
|||
|
||||
Once ansible is installed, it will not add a database, and there will be no daemons to start or keep running. You only need to install it on one machine (which could easily be a laptop) and it can manage an entire fleet of remote machines from that central point. When Ansible manages remote machines, it does not leave software installed or running on them, so there's no real question about how to upgrade Ansible when moving to a new version.
|
||||
|
||||
.. _what_version:
|
||||
|
||||
What Version To Pick?
|
||||
`````````````````````
|
||||
|
||||
|
|
@ -36,6 +42,8 @@ For other installation options, we recommend installing via "pip", which is the
|
|||
If you wish to track the development release to use and test the latest features, we will share
|
||||
information about running from source. It's not neccessary to install the program to run from source.
|
||||
|
||||
.. _control_machine_requirements:
|
||||
|
||||
Control Machine Requirements
|
||||
````````````````````````````
|
||||
|
||||
|
|
@ -43,9 +51,10 @@ Currently Ansible can be from any machine with Python 2.6 installed (Windows isn
|
|||
|
||||
This includes Red Hat, Debian, CentOS, OS X, any of the BSDs, and so on.
|
||||
|
||||
.. _managed_node_requirements:
|
||||
|
||||
Remote Node Requirements
|
||||
````````````````````````
|
||||
Managed Node Requirements
|
||||
`````````````````````````
|
||||
|
||||
On the managed nodes, you only need Python 2.4 or later, but if you are are running less than Python 2.5 on the remotes, you will also need:
|
||||
|
||||
|
|
@ -77,6 +86,7 @@ On the managed nodes, you only need Python 2.4 or later, but if you are are runn
|
|||
Unix systems. If you need to bootstrap these remote systems by installing Python 2.X,
|
||||
using the 'raw' module will be able to do it remotely.
|
||||
|
||||
.. _from_source:
|
||||
|
||||
Running From Source
|
||||
+++++++++++++++++++
|
||||
|
|
@ -124,6 +134,8 @@ Now let's test things with a ping command:
|
|||
|
||||
You can also use "sudo make install" if you wish.
|
||||
|
||||
.. _from_yum:
|
||||
|
||||
Latest Release Via Yum
|
||||
++++++++++++++++++++++
|
||||
|
||||
|
|
@ -150,6 +162,8 @@ You can also build an RPM yourself. From the root of a checkout or tarball, use
|
|||
$ make rpm
|
||||
$ sudo rpm -Uvh ~/rpmbuild/ansible-*.noarch.rpm
|
||||
|
||||
.. _from_apt:
|
||||
|
||||
Latest Releases Via Apt (Ubuntu)
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
|
|
@ -171,6 +185,8 @@ Debian/Ubuntu packages can also be built from the source checkout, run:
|
|||
|
||||
You may also wish to run from source to get the latest, which is covered above.
|
||||
|
||||
.. _from_pip:
|
||||
|
||||
Latest Releases Via Pip
|
||||
+++++++++++++++++++++++
|
||||
|
||||
|
|
@ -185,6 +201,8 @@ Then install Ansible with::
|
|||
|
||||
Readers that use virtualenv can also install Ansible under virtualenv, though we'd recommend to not worry about it and just install Ansible globally. Do not use easy_install to install ansible directly.
|
||||
|
||||
.. _tagged_releases:
|
||||
|
||||
Tarballs of Tagged Releases
|
||||
+++++++++++++++++++++++++++
|
||||
|
||||
|
|
@ -194,131 +212,6 @@ Packaging Ansible or wanting to build a local package yourself, but don't want t
|
|||
|
||||
These releases are also tagged in the git repository with the release version.
|
||||
|
||||
Choosing Between Paramiko and Native SSH
|
||||
````````````````````````````````````````
|
||||
|
||||
By default, ansible 1.3 and later will try to use native SSH for remote communication when possible.
|
||||
This is done when ControlPersist support is available. Paramiko is however reasonably fast and makes
|
||||
a good default on versions of Enterprise Linux where ControlPersist is not available. However, Paramiko
|
||||
does not support some advanced SSH features that folks will want to use. In Ansible 1.2 and before,
|
||||
the default was strictly paramiko and native SSH had to be explicitly selected with -c ssh or set in the
|
||||
configuration file.
|
||||
|
||||
.. versionadded:: 0.5
|
||||
|
||||
If you want to leverage more advanced SSH features (such as Kerberized
|
||||
SSH or jump hosts), pass the flag "--connection=ssh" to any ansible
|
||||
command, or set the ANSIBLE_TRANSPORT environment variable to
|
||||
'ssh'. This will cause Ansible to use openssh tools instead.
|
||||
|
||||
If ANSIBLE_SSH_ARGS are not set, ansible will try to use some sensible ControlMaster options
|
||||
by default. You are free to override this environment variable, but should still pass ControlMaster
|
||||
options to ensure performance of this transport. With ControlMaster in use, both transports
|
||||
are roughly the same speed. Without CM, the binary ssh transport is signficantly slower.
|
||||
|
||||
If none of this makes sense to you, the default paramiko option is probably fine.
|
||||
|
||||
|
||||
Your first commands
|
||||
```````````````````
|
||||
|
||||
Now that you've installed Ansible, it's time to test it.
|
||||
|
||||
Edit (or create) /etc/ansible/hosts and put one or more remote systems in it, for
|
||||
which you have your SSH key in ``authorized_keys``::
|
||||
|
||||
192.168.1.50
|
||||
aserver.example.org
|
||||
bserver.example.org
|
||||
|
||||
Set up SSH agent to avoid retyping passwords:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ssh-agent bash
|
||||
$ ssh-add ~/.ssh/id_rsa
|
||||
|
||||
(Depending on your setup, you may wish to ansible's --private-key option to specify a pem file instead)
|
||||
|
||||
Now ping all your nodes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible all -m ping
|
||||
|
||||
Ansible will attempt to remote connect to the machines using your current
|
||||
user name, just like SSH would. To override the remote user name, just use the '-u' parameter.
|
||||
|
||||
If you would like to access sudo mode, there are also flags to do that:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# as bruce
|
||||
$ ansible all -m ping -u bruce
|
||||
# as bruce, sudoing to root
|
||||
$ ansible all -m ping -u bruce --sudo
|
||||
# as bruce, sudoing to batman
|
||||
$ ansible all -m ping -u bruce --sudo --sudo-user batman
|
||||
|
||||
(The sudo implementation is changeable in ansible's configuration file if you happen to want to use a sudo
|
||||
replacement. Flags passed dot sudo can also be set.)
|
||||
|
||||
Now run a live command on all of your nodes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ansible all -a "/bin/echo hello"
|
||||
|
||||
Congratulations. You've just contacted your nodes with Ansible. It's
|
||||
soon going to be time to read some of the more real-world :doc:`intro_adhoc`, and explore
|
||||
what you can do with different modules, as well as the Ansible
|
||||
:doc:`playbooks` language. Ansible is not just about running commands, it
|
||||
also has powerful configuration management and deployment features. There's more to
|
||||
explore, but you already have a fully working infrastructure!
|
||||
|
||||
A note about Connection (Transport) Modes
|
||||
`````````````````````````````````````````
|
||||
|
||||
Ansible has two major forms of SSH transport implemented, 'ssh' (OpenSSH) and 'paramiko'. Paramiko is a python
|
||||
SSH implementation and 'ssh' simply calls OpenSSH behind the scenes. There are additionally 'fireball' (an accelerated
|
||||
remote transport), 'local', and 'chroot' connection modes in Ansible that don't use SSH, but connecting by one of the two
|
||||
SSH transports is the most common way to manage systems. It is useful to understand the difference between the 'ssh'
|
||||
and 'paramiko' modes.
|
||||
|
||||
Paramiko is provided because older Enterprise Linux operating systems do not have an efficient OpenSSH that support
|
||||
ControlPersist technology, and in those cases, 'paramiko' is faster than 'ssh'. Thus, until EL6 backports a newer
|
||||
SSH, 'paramiko' is the faster option on that platform.
|
||||
|
||||
However, if you have a newer 'ssh' that supports ControlPersist, usage of the 'ssh' transport unlocks additional
|
||||
configurability, including the option to use Kerberos. For instance, the latest Fedora and Ubuntu releases
|
||||
all offer a sufficiently new OpenSSH. With ControlPersist available, 'ssh' is usually about as fast as paramiko.
|
||||
If you'd like even more speed, read about 'fireball' in the Advanced Playbooks section.
|
||||
|
||||
Starting with Ansible 1.2.1, the default transport mode for Ansible is 'smart', which means it will detect
|
||||
if OpenSSH supports ControlPersist, and will select 'ssh' if available, and otherwise pick 'paramiko'.
|
||||
Previous versions of Ansible defaulted to 'paramiko'.
|
||||
|
||||
A note about Host Key Checking
|
||||
``````````````````````````````
|
||||
|
||||
Ansible 1.2.1 and later have host key checking enabled by default.
|
||||
|
||||
If a host is reinstalled and has a different key in 'known_hosts', this will result in a error message until
|
||||
corrected. If a host is not initially in 'known_hosts' this will result in prompting for confirmation of the key,
|
||||
which results in a interactive experience if using Ansible, from say, cron.
|
||||
|
||||
If you wish to disable this behavior and understand the implications, you can do so by editing /etc/ansible/ansible.cfg or ~/.ansible.cfg::
|
||||
|
||||
[defaults]
|
||||
host_key_checking = False
|
||||
|
||||
Alternatively this can be set by an environment variable:
|
||||
|
||||
$ export ANSIBLE_HOST_KEY_CHECKING=False
|
||||
|
||||
Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this
|
||||
feature.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`intro_adhoc`
|
||||
|
|
|
|||
|
|
@ -71,6 +71,8 @@ You can also select the connection type and user on a per host basis::
|
|||
As mentioned above, setting these in the inventory file is only a shorthand, and we'll discuss how to store them in individual files
|
||||
in the 'host_vars' directory a bit later on.
|
||||
|
||||
.. _host_variables:
|
||||
|
||||
Host Variables
|
||||
++++++++++++++
|
||||
|
||||
|
|
@ -80,6 +82,8 @@ As alluded to above, it is easy to assign variables to hosts that will be used l
|
|||
host1 http_port=80 maxRequestsPerChild=808
|
||||
host2 http_port=303 maxRequestsPerChild=909
|
||||
|
||||
.. _group_variables:
|
||||
|
||||
Group Variables
|
||||
+++++++++++++++
|
||||
|
||||
|
|
@ -93,6 +97,8 @@ Variables can also be applied to an entire group at once::
|
|||
ntp_server=ntp.atlanta.example.com
|
||||
proxy=proxy.atlanta.example.com
|
||||
|
||||
.. _subgroups:
|
||||
|
||||
Groups of Groups, and Group Variables
|
||||
+++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
|
@ -127,6 +133,8 @@ variables to groups. These variables can be used by /usr/bin/ansible-playbook,
|
|||
If you need to store lists or hash data, or prefer to keep host and group specific variables
|
||||
separate from the inventory file, see the next section.
|
||||
|
||||
.. _splitting_out_vars:
|
||||
|
||||
Splitting Out Host and Group Specific Data
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
|
@ -166,6 +174,8 @@ directory will be loaded second.
|
|||
Tip: Keeping your inventory file and variables in a git repo (or other version control)
|
||||
is an excellent way to track changes to your inventory and host variables.
|
||||
|
||||
.. _behavioral_parameters:
|
||||
|
||||
List of Behavioral Inventory Parameters
|
||||
+++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue