commit
bd20d3c9be
4 changed files with 18 additions and 18 deletions
|
@ -12,7 +12,7 @@ What's an ad-hoc command?
|
|||
An ad-hoc command is something that you might type in to do something really
|
||||
quick, but don't want to save for later.
|
||||
|
||||
This is a good place to start to understand the basics of what ansible can do
|
||||
This is a good place to start to understand the basics of what Ansible can do
|
||||
prior to learning the playbooks language -- ad-hoc commands can also be used
|
||||
to do quick things that you might not necessarily want to write a full playbook
|
||||
for.
|
||||
|
@ -42,7 +42,7 @@ Parallelism and Shell Commands
|
|||
|
||||
Arbitrary example.
|
||||
|
||||
Let's use ansible's command line tool to reboot all web servers in Atlanta, 10 at a time. First, let's
|
||||
Let's use Ansible's command line tool to reboot all web servers in Atlanta, 10 at a time. First, let's
|
||||
set up SSH-agent so it can remember our credentials::
|
||||
|
||||
$ ssh-agent bash
|
||||
|
@ -84,7 +84,7 @@ is really small and conservative. You are probably going to want to talk to a l
|
|||
to crank this up. If you have more hosts than the value set for the fork count, Ansible will talk to them, but it will
|
||||
take a little longer. Feel free to push this value as high as your system can handle it!
|
||||
|
||||
You can also select what ansible "module" you want to urn. Normally commands also take a ``-m`` for module name, but
|
||||
You can also select what Ansible "module" you want to run. Normally commands also take a ``-m`` for module name, but
|
||||
the default module name is 'command', so we didn't need to
|
||||
specify that all of the time. We'll use ``-m`` in later examples to
|
||||
run some other :doc:`modules`.
|
||||
|
@ -99,7 +99,7 @@ Using the :ref:`shell` module looks like this::
|
|||
|
||||
$ ansible raleigh -m shell -a 'echo $TERM'
|
||||
|
||||
When running any command with the ansible *ad hoc* CLI (as opposed to
|
||||
When running any command with the Ansible *ad hoc* CLI (as opposed to
|
||||
:doc:`playbooks`), pay particular attention to shell quoting rules, so
|
||||
the local shell doesn't eat a variable before it gets passed to Ansible.
|
||||
For example, using double vs single quotes in the above example would
|
||||
|
@ -107,7 +107,7 @@ evaluate the variable on the box you were on.
|
|||
|
||||
So far we've been demoing simple command execution, but most Ansible modules usually do not work like
|
||||
simple scripts. They make the remote system look like you state, and run the commands necessary to
|
||||
get it there. This is commonly referred to as 'idempotence', and is a core design goal of ansible.
|
||||
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:
|
||||
|
@ -192,8 +192,8 @@ Deploy your webapp straight from git::
|
|||
|
||||
$ ansible webservers -m git -a "repo=git://foo.example.org/repo.git dest=/srv/myapp version=HEAD"
|
||||
|
||||
Since ansible modules can notify change handlers it is possible to
|
||||
tell ansible to run specific tasks when the code is updated, such as
|
||||
Since Ansible modules can notify change handlers it is possible to
|
||||
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.
|
||||
|
||||
|
@ -291,11 +291,11 @@ Both of these methods can be used at the same time, and ranges can also be passe
|
|||
.. seealso::
|
||||
|
||||
:doc:`intro_configuration`
|
||||
All about the ansible config file
|
||||
All about the Ansible config file
|
||||
:doc:`modules`
|
||||
A list of available modules
|
||||
:doc:`playbooks`
|
||||
Using ansible for configuration management & deployment
|
||||
Using Ansible for configuration management & deployment
|
||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
|
|
|
@ -26,7 +26,7 @@ Remote Connection Information
|
|||
Before we get started, it's important to understand how Ansible is communicating with remote
|
||||
machines over SSH.
|
||||
|
||||
By default, ansible 1.3 and later will try to use native
|
||||
By default, Ansible 1.3 and later will try to use native
|
||||
OpenSSH for remote communication when possible. This enables both ControlPersist (a performance feature), Kerberos, and options in ~/.ssh/config such as Jump Host setup. When using Enterprise Linux 6 operating systems as the control machine (Red Hat Enterprise Linux and derivatives such as CentOS), however, the version of OpenSSH may be too old to support Control Persist. On these operating systems, Ansible will fallback into using a high-quality python implementation of
|
||||
OpenSSH called 'paramiko'. If you wish to use features like Kerberized SSH and more, consider using Fedora, OS X, or Ubuntu as your control machine until a newer version of OpenSSH is available for your platform -- or engage 'accelerated mode' in Ansible. See :doc:`playbooks_acceleration`.
|
||||
|
||||
|
@ -39,14 +39,14 @@ When speaking with remote machines, Ansible will by default assume you are using
|
|||
While it may be common sense, it is worth sharing: Any management system benefits from being run near your machines you are being managed. If running in a cloud, consider running Ansible from a machine inside that cloud. It will work better than on the open
|
||||
intranet in most cases.
|
||||
|
||||
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.
|
||||
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
|
||||
```````````````````
|
||||
|
||||
Now that you've installed Ansible, it's time to get started with some basics/
|
||||
Now that you've installed Ansible, it's time to get started with some basics.
|
||||
|
||||
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``::
|
||||
|
@ -58,7 +58,7 @@ which you have your SSH key in ``authorized_keys``::
|
|||
This is an inventory file, which is also explained in greater depth here: :doc:`intro_inventory`.
|
||||
|
||||
We'll assume you are using SSH keys for authentication. To set up SSH agent to avoid retyping passwords, you can
|
||||
do::
|
||||
do:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -87,7 +87,7 @@ If you would like to access sudo mode, there are also flags to do that:
|
|||
# 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
|
||||
(The sudo implementation is changeable in Ansible's configuration file if you happen to want to use a sudo
|
||||
replacement. Flags passed to sudo (like -H) can also be set there.)
|
||||
|
||||
Now run a live command on all of your nodes:
|
||||
|
@ -135,7 +135,7 @@ logging on the control machine see `intro_config` document and set the 'log_path
|
|||
:doc:`intro_adhoc`
|
||||
Examples of basic commands
|
||||
:doc:`playbooks`
|
||||
Learning ansible's configuration management language
|
||||
Learning Ansible's configuration management language
|
||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
|
|
|
@ -144,7 +144,7 @@ In addition to the storing variables directly in the INI file, host
|
|||
and group variables can be stored in individual files relative to the
|
||||
inventory file.
|
||||
|
||||
These variable files are in YAML format. See `YAMLSyntax` if you are new to YAML.
|
||||
These variable files are in YAML format. See :doc:`YAMLSyntax` if you are new to YAML.
|
||||
|
||||
Assuming the inventory file path is::
|
||||
|
||||
|
|
|
@ -69,11 +69,11 @@ It's also ok to mix wildcard patterns and groups at the same time::
|
|||
|
||||
one*.com:dbservers
|
||||
|
||||
Most people don't specify patterns as regular expressions, but you can. Just start the pattern with a '~'.
|
||||
Most people don't specify patterns as regular expressions, but you can. Just start the pattern with a '~'::
|
||||
|
||||
~(web|db).*\.example\.com
|
||||
|
||||
While we're jumping a bit ahead, additionally, you can add an exclusion criteria just by supplying the "--limit" flag to /usr/bin/ansible or /usr/bin/ansible-playbook.
|
||||
While we're jumping a bit ahead, additionally, you can add an exclusion criteria just by supplying the "--limit" flag to /usr/bin/ansible or /usr/bin/ansible-playbook::
|
||||
|
||||
ansible-playbook site.yml --limit datacenter2
|
||||
|
||||
|
|
Loading…
Reference in a new issue