2018-03-14 20:44:21 +01:00
.. _installation_guide:
.. _intro_installation_guide:
2020-01-16 17:30:26 +01:00
Installing Ansible
===================
2012-03-07 17:35:18 +01:00
2020-01-16 17:30:26 +01:00
This page describes how to install Ansible on different platforms.
Ansible is an agentless automation tool that by default manages machines over the SSH protocol. Once installed, Ansible does
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.
2013-12-26 20:35:37 +01:00
2013-10-03 02:46:59 +02:00
2020-01-16 17:30:26 +01:00
.. contents ::
:local:
2013-10-05 00:14:54 +02:00
2020-01-16 17:30:26 +01:00
Prerequisites
--------------
2012-03-08 19:36:47 +01:00
2020-01-16 17:30:26 +01:00
You install Ansible on a control node, which then uses SSH (by default) to communicate with your managed nodes (those end devices you want to automate).
2013-09-29 19:13:05 +02:00
2019-02-08 20:40:10 +01:00
.. _control_node_requirements:
2013-10-05 00:14:54 +02:00
2020-01-16 17:30:26 +01:00
Control node requirements
^^^^^^^^^^^^^^^^^^^^^^^^^
2013-02-16 22:06:30 +01:00
2020-01-16 17:30:26 +01:00
Currently Ansible can be run from any machine with Python 2 (version 2.7) or Python 3 (versions 3.5 and higher) installed.
2018-06-26 20:09:23 +02:00
This includes Red Hat, Debian, CentOS, macOS, any of the BSDs, and so on.
2020-01-16 17:30:26 +01:00
Windows is not supported for the control node.
2015-09-08 15:17:38 +02:00
2019-10-08 19:46:38 +02:00
When choosing a control node, bear in mind that any management system benefits from being run near the machines being managed. If you are running Ansible in a cloud, consider running it from a machine inside that cloud. In most cases this will work better than on the open Internet.
2015-09-08 15:17:38 +02:00
.. note ::
2018-06-26 20:09:23 +02:00
macOS by default is configured for a small number of file handles, so if you want to use 15 or more forks you'll need to raise the ulimit with `` sudo launchctl limit maxfiles unlimited `` . This command can also fix any "Too many open files" error.
2015-09-08 15:17:38 +02:00
2016-03-15 03:33:46 +01:00
.. warning ::
2020-01-16 17:30:26 +01:00
Please note that some modules and plugins have additional requirements. For modules these need to be satisfied on the 'target' machine (the managed node) and should be listed in the module specific docs.
2016-03-15 03:33:46 +01:00
2013-10-05 00:14:54 +02:00
.. _managed_node_requirements:
2013-08-08 15:14:56 +02:00
2020-01-16 17:30:26 +01:00
Managed node requirements
^^^^^^^^^^^^^^^^^^^^^^^^^
2013-09-29 19:13:05 +02:00
2020-01-16 17:30:26 +01:00
On the managed nodes, you need a way to communicate, which is normally SSH. By
default this uses SFTP. If that's not available, you can switch to SCP in
:ref: `ansible.cfg <ansible_configuration_settings>` . You also need Python 2 (version 2.6 or later) or Python 3 (version 3.5 or
2018-04-18 22:04:47 +02:00
later).
2012-03-08 19:36:47 +01:00
2012-08-13 20:51:36 +02:00
.. note ::
2018-04-18 22:04:47 +02:00
* If you have SELinux enabled on remote nodes, you will also want to install
libselinux-python on them before using any copy/file/template related functions in Ansible. You
2018-04-25 20:18:52 +02:00
can use the :ref: `yum module<yum_module>` or :ref: `dnf module<dnf_module>` in Ansible to install this package on remote systems
2018-04-18 22:04:47 +02:00
that do not have it.
2013-08-08 15:14:56 +02:00
2020-01-16 17:30:26 +01:00
* By default, Ansible uses the Python interpreter located at :file: `/usr/bin/python` to run its
2018-04-18 22:04:47 +02:00
modules. However, some Linux distributions may only have a Python 3 interpreter installed to
:file: `/usr/bin/python3` by default. On those systems, you may see an error like::
2013-08-08 15:14:56 +02:00
2018-04-18 22:04:47 +02:00
"module_stdout": "/bin/sh: /usr/bin/python: No such file or directory\r\n"
2013-03-18 04:26:57 +01:00
2018-04-25 20:18:52 +02:00
you can either set the :ref: `ansible_python_interpreter<ansible_python_interpreter>` inventory variable (see
2018-04-18 22:04:47 +02:00
:ref: `inventory` ) to point at your interpreter or you can install a Python 2 interpreter for
2018-04-25 20:18:52 +02:00
modules to use. You will still need to set :ref: `ansible_python_interpreter<ansible_python_interpreter>` if the Python
2018-04-18 22:04:47 +02:00
2 interpreter is not installed to :command: `/usr/bin/python` .
2016-10-26 00:27:40 +02:00
2019-10-03 22:57:30 +02:00
* Ansible's :ref: `raw module<raw_module>` , and the :ref: `script module<script_module>` , do not depend
on a client side install of Python to run. Technically, you can use Ansible to install a compatible
2018-04-25 20:18:52 +02:00
version of Python using the :ref: `raw module<raw_module>` , which then allows you to use everything else.
2018-04-18 22:04:47 +02:00
For example, if you need to bootstrap Python 2 onto a RHEL-based system, you can install it
2020-01-16 17:30:26 +01:00
as follows:
2015-10-15 19:35:07 +02:00
2018-04-18 22:04:47 +02:00
.. code-block :: shell
2016-10-26 00:27:40 +02:00
Become plugins (#50991)
* [WIP] become plugins
Move from hardcoded method to plugins for ease of use, expansion and overrides
- load into connection as it is going to be the main consumer
- play_context will also use to keep backwards compat API
- ensure shell is used to construct commands when needed
- migrate settings remove from base config in favor of plugin specific configs
- cleanup ansible-doc
- add become plugin docs
- remove deprecated sudo/su code and keywords
- adjust become options for cli
- set plugin options from context
- ensure config defs are avaialbe before instance
- refactored getting the shell plugin, fixed tests
- changed into regex as they were string matching, which does not work with random string generation
- explicitly set flags for play context tests
- moved plugin loading up front
- now loads for basedir also
- allow pyc/o for non m modules
- fixes to tests and some plugins
- migrate to play objects fro play_context
- simiplify gathering
- added utf8 headers
- moved option setting
- add fail msg to dzdo
- use tuple for multiple options on fail/missing
- fix relative plugin paths
- shift from play context to play
- all tasks already inherit this from play directly
- remove obsolete 'set play'
- correct environment handling
- add wrap_exe option to pfexec
- fix runas to noop
- fixed setting play context
- added password configs
- removed required false
- remove from doc building till they are ready
future development:
- deal with 'enable' and 'runas' which are not 'command wrappers' but 'state flags' and currently hardcoded in diff subsystems
* cleanup
remove callers to removed func
removed --sudo cli doc refs
remove runas become_exe
ensure keyerorr on plugin
also fix backwards compat, missing method is attributeerror, not ansible error
get remote_user consistently
ignore missing system_tmpdirs on plugin load
correct config precedence
add deprecation
fix networking imports
backwards compat for plugins using BECOME_METHODS
* Port become_plugins to context.CLIARGS
This is a work in progress:
* Stop passing options around everywhere as we can use context.CLIARGS
instead
* Refactor make_become_commands as asked for by alikins
* Typo in comment fix
* Stop loading values from the cli in more than one place
Both play and play_context were saving default values from the cli
arguments directly. This changes things so that the default values are
loaded into the play and then play_context takes them from there.
* Rename BECOME_PLUGIN_PATH to DEFAULT_BECOME_PLUGIN_PATH
As alikins said, all other plugin paths are named
DEFAULT_plugintype_PLUGIN_PATH. If we're going to rename these, that
should be done all at one time rather than piecemeal.
* One to throw away
This is a set of hacks to get setting FieldAttribute defaults to command
line args to work. It's not fully done yet.
After talking it over with sivel and jimi-c this should be done by
fixing FieldAttributeBase and _get_parent_attribute() calls to do the
right thing when there is a non-None default.
What we want to be able to do ideally is something like this:
class Base(FieldAttributeBase):
_check_mode = FieldAttribute([..] default=lambda: context.CLIARGS['check'])
class Play(Base):
# lambda so that we have a chance to parse the command line args
# before we get here. In the future we might be able to restructure
# this so that the cli parsing code runs before these classes are
# defined.
class Task(Base):
pass
And still have a playbook like this function:
---
- hosts:
tasks:
- command: whoami
check_mode: True
(The check_mode test that is added as a separate commit in this PR will
let you test variations on this case).
There's a few separate reasons that the code doesn't let us do this or
a non-ugly workaround for this as written right now. The fix that
jimi-c, sivel, and I talked about may let us do this or it may still
require a workaround (but less ugly) (having one class that has the
FieldAttributes with default values and one class that inherits from
that but just overrides the FieldAttributes which now have defaults)
* Revert "One to throw away"
This reverts commit 23aa883cbed11429ef1be2a2d0ed18f83a3b8064.
* Set FieldAttr defaults directly from CLIARGS
* Remove dead code
* Move timeout directly to PlayContext, it's never needed on Play
* just for backwards compat, add a static version of BECOME_METHODS to constants
* Make the become attr on the connection public, since it's used outside of the connection
* Logic fix
* Nuke connection testing if it supports specific become methods
* Remove unused vars
* Address rebase issues
* Fix path encoding issue
* Remove unused import
* Various cleanups
* Restore network_cli check in _low_level_execute_command
* type improvements for cliargs_deferred_get and swap shallowcopy to default to False
* minor cleanups
* Allow the su plugin to work, since it doesn't define a prompt the same way
* Fix up ksu become plugin
* Only set prompt if build_become_command was called
* Add helper to assist connection plugins in knowing they need to wait for a prompt
* Fix tests and code expectations
* Doc updates
* Various additional minor cleanups
* Make doas functional
* Don't change connection signature, load become plugin from TaskExecutor
* Remove unused imports
* Add comment about setting the become plugin on the playcontext
* Fix up tests for recent changes
* Support 'Password:' natively for the doas plugin
* Make default prompts raw
* wording cleanups. ci_complete
* Remove unrelated changes
* Address spelling mistake
* Restore removed test, and udpate to use new functionality
* Add changelog fragment
* Don't hard fail in set_attributes_from_cli on missing CLI keys
* Remove unrelated change to loader
* Remove internal deprecated FieldAttributes now
* Emit deprecation warnings now
2019-02-11 18:27:44 +01:00
$ ansible myhost --become -m raw -a "yum install -y python2"
2013-03-08 23:09:28 +01:00
2020-01-16 17:30:26 +01:00
.. _what_version:
Selecting an Ansible version to install
---------------------------------------
Which Ansible version to install is based on your particular needs. You can choose any of the following ways to install Ansible:
* Install the latest release with your OS package manager (for Red Hat Enterprise Linux (TM), CentOS, Fedora, Debian, or Ubuntu).
* Install with `` pip `` (the Python package manager).
2020-02-17 17:53:16 +01:00
* Install from source to access the development (`` devel `` ) version to develop or test the latest features.
2013-10-28 16:55:25 +01:00
2020-02-17 17:53:16 +01:00
.. note ::
2020-02-19 22:17:42 +01:00
You should only run Ansible from `` devel `` if you are modifying the Ansible engine, or trying out features under development. This is a rapidly changing source of code and can become unstable at any point.
2020-01-16 17:30:26 +01:00
Ansible creates new releases two to three times a year. Due to this short release cycle,
minor bugs will generally be fixed in the next release versus maintaining backports on the stable branch.
Major bugs will still have maintenance releases when needed, though these are infrequent.
.. _installing_the_control_node:
2013-10-05 00:14:54 +02:00
.. _from_yum:
2020-01-16 17:30:26 +01:00
Installing Ansible on RHEL, CentOS, or Fedora
----------------------------------------------
2017-12-01 11:19:08 +01:00
On Fedora:
.. code-block :: bash
$ sudo dnf install ansible
On RHEL and CentOS:
.. code-block :: bash
$ sudo yum install ansible
2012-08-13 20:51:36 +02:00
2020-05-16 03:29:05 +02:00
RPMs for RHEL 7 and RHEL 8 are available from the `Ansible Engine repository <https://access.redhat.com/articles/3174981> `_ .
2013-04-26 11:08:13 +02:00
2019-05-23 18:31:12 +02:00
To enable the Ansible Engine repository for RHEL 8, run the following command:
2012-08-13 20:51:36 +02:00
2018-04-05 19:46:46 +02:00
.. code-block :: bash
2019-11-06 20:33:17 +01:00
$ sudo subscription-manager repos --enable ansible-2.9-for-rhel-8-x86_64-rpms
2019-05-23 18:31:12 +02:00
To enable the Ansible Engine repository for RHEL 7, run the following command:
.. code-block :: bash
2019-11-06 20:33:17 +01:00
$ sudo subscription-manager repos --enable rhel-7-server-ansible-2.9-rpms
2016-10-30 04:27:15 +01:00
2020-05-16 03:29:05 +02:00
RPMs for currently supported versions of RHEL and CentOS are also available from `EPEL <https://fedoraproject.org/wiki/EPEL> `_ .
2012-05-10 06:58:27 +02:00
2020-05-16 03:29:05 +02:00
Ansible version 2.4 and later can manage older operating systems that contain Python 2.6 or higher.
2012-03-17 22:00:41 +01:00
2013-10-05 00:14:54 +02:00
.. _from_apt:
2020-01-16 17:30:26 +01:00
Installing Ansible on Ubuntu
----------------------------
2012-03-18 17:55:18 +01:00
2018-08-13 21:54:14 +02:00
Ubuntu builds are available `in a PPA here <https://launchpad.net/~ansible/+archive/ubuntu/ansible> `_ .
2013-05-28 18:32:14 +02:00
2020-01-16 17:30:26 +01:00
To configure the PPA on your machine and install Ansible run these commands:
2013-05-28 18:32:14 +02:00
2013-05-28 18:25:44 +02:00
.. code-block :: bash
2013-05-28 18:12:33 +02:00
2018-12-05 15:14:48 +01:00
$ sudo apt update
$ sudo apt install software-properties-common
2018-09-17 15:59:20 +02:00
$ sudo apt-add-repository --yes --update ppa:ansible/ansible
2018-12-05 15:14:48 +01:00
$ sudo apt install ansible
2012-04-18 01:54:23 +02:00
2019-05-10 02:09:41 +02:00
.. note :: On older Ubuntu distributions, "software-properties-common" is called "python-software-properties". You may want to use `` apt-get `` instead of `` apt `` in older versions. Also, be aware that only newer distributions (i.e. 18.04, 18.10, etc.) have a `` -u `` or `` --update `` flag, so adjust your script accordingly.
2014-07-14 17:42:49 +02:00
2013-08-16 23:02:35 +02:00
Debian/Ubuntu packages can also be built from the source checkout, run:
2012-05-10 06:58:27 +02:00
2012-08-13 20:51:36 +02:00
.. code-block :: bash
2013-10-28 23:04:16 +01:00
$ make deb
2012-04-18 01:54:23 +02:00
2020-01-16 17:30:26 +01:00
You may also wish to run from source to get the development branch, which is covered below.
2013-08-16 23:02:35 +02:00
2020-01-16 17:30:26 +01:00
Installing Ansible on Debian
----------------------------
2016-10-30 04:24:43 +01:00
Debian users may leverage the same source as the Ubuntu PPA.
Add the following line to /etc/apt/sources.list:
.. code-block :: bash
deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main
Then run these commands:
.. code-block :: bash
2017-01-31 20:58:23 +01:00
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
2018-12-05 15:14:48 +01:00
$ sudo apt update
$ sudo apt install ansible
2016-10-30 04:24:43 +01:00
2018-12-05 15:14:48 +01:00
.. note :: This method has been verified with the Trusty sources in Debian Jessie and Stretch but may not be supported in earlier versions. You may want to use `` apt-get `` instead of `` apt `` in older versions.
2014-02-10 22:13:10 +01:00
2020-01-16 17:30:26 +01:00
Installing Ansible on Gentoo with portage
-----------------------------------------
2014-09-19 23:48:11 +02:00
.. code-block :: bash
$ emerge -av app-admin/ansible
2020-01-16 17:30:26 +01:00
To install the newest version, you may need to unmask the Ansible package prior to emerging:
2014-09-19 23:48:11 +02:00
.. code-block :: bash
$ echo 'app-admin/ansible' >> /etc/portage/package.accept_keywords
2020-01-16 17:30:26 +01:00
Installing Ansible on FreeBSD
-----------------------------
2014-02-10 22:13:10 +01:00
2018-09-11 22:55:21 +02:00
Though Ansible works with both Python 2 and 3 versions, FreeBSD has different packages for each Python version.
So to install you can use:
2014-02-10 22:13:10 +01:00
.. code-block :: bash
2018-09-11 22:55:21 +02:00
$ sudo pkg install py27-ansible
or:
.. code-block :: bash
$ sudo pkg install py36-ansible
2014-02-10 22:13:10 +01:00
You may also wish to install from ports, run:
.. code-block :: bash
$ sudo make -C /usr/ports/sysutils/ansible install
2018-09-11 22:55:21 +02:00
You can also choose a specific version, i.e `` ansible25 `` .
Older versions of FreeBSD worked with something like this (substitute for your choice of package manager):
.. code-block :: bash
$ sudo pkg install ansible
2015-04-02 22:30:37 +02:00
.. _on_macos:
2014-04-15 22:11:46 +02:00
2020-01-16 17:30:26 +01:00
Installing Ansible on macOS
---------------------------
2014-04-15 22:11:46 +02:00
2020-01-16 17:30:26 +01:00
The preferred way to install Ansible on a Mac is with `` pip `` .
2014-04-15 22:11:46 +02:00
2020-02-12 16:06:23 +01:00
The instructions can be found in :ref: `from_pip` . If you are running macOS version 10.12 or older, then you should upgrade to the latest `` pip `` to connect to the Python Package Index securely. It should be noted that pip must be run as a module on macOS, and the linked `` pip `` instructions will show you how to do that.
2014-04-15 22:11:46 +02:00
2020-08-04 20:39:24 +02:00
.. note ::
If you have Ansible 2.9 or older installed, you need to use `` pip uninstall ansible `` first to remove older versions of Ansible before re-installing it.
2020-03-23 18:34:23 +01:00
If you are installing on macOS Mavericks (10.9), you may encounter some noise from your compiler. A workaround is to do the following::
$ CFLAGS=-Qunused-arguments CPPFLAGS=-Qunused-arguments pip install --user ansible
2015-01-28 10:23:03 +01:00
.. _from_pkgutil:
2020-01-16 17:30:26 +01:00
Installing Ansible on Solaris
-----------------------------
2015-01-28 10:23:03 +01:00
Ansible is available for Solaris as `SysV package from OpenCSW <https://www.opencsw.org/packages/ansible/> `_ .
.. code-block :: bash
# pkgadd -d http://get.opencsw.org/now
# /opt/csw/bin/pkgutil -i ansible
2015-03-24 11:27:12 +01:00
.. _from_pacman:
2020-01-16 17:30:26 +01:00
Installing Ansible on Arch Linux
---------------------------------
2015-03-24 11:27:12 +01:00
Ansible is available in the Community repository::
$ pacman -S ansible
2019-01-15 14:53:04 +01:00
The AUR has a PKGBUILD for pulling directly from GitHub called `ansible-git <https://aur.archlinux.org/packages/ansible-git> `_ .
2015-03-24 11:27:12 +01:00
2015-07-25 00:08:26 +02:00
Also see the `Ansible <https://wiki.archlinux.org/index.php/Ansible> `_ page on the ArchWiki.
2018-11-07 16:54:00 +01:00
.. _from_sbopkg:
2020-01-16 17:30:26 +01:00
Installing Ansible on Slackware Linux
-------------------------------------
2018-11-07 16:54:00 +01:00
Ansible build script is available in the `SlackBuilds.org <https://slackbuilds.org/apps/ansible/> `_ repository.
Can be built and installed using `sbopkg <https://sbopkg.org/> `_ .
Create queue with Ansible and all dependencies::
# sqg -p ansible
2020-01-16 17:30:26 +01:00
Build and install packages from a created queuefile (answer Q for question if sbopkg should use queue or package)::
2018-11-07 16:54:00 +01:00
# sbopkg -k -i ansible
2018-12-12 20:17:43 +01:00
.. _from swupd:
2020-01-16 17:30:26 +01:00
Installing Ansible on Clear Linux
---------------------------------
2018-12-12 20:17:43 +01:00
Ansible and its dependencies are available as part of the sysadmin host management bundle::
$ sudo swupd bundle-add sysadmin-hostmgmt
Update of the software will be managed by the swupd tool::
$ sudo swupd update
2013-10-05 00:14:54 +02:00
.. _from_pip:
2020-01-16 17:30:26 +01:00
Installing Ansible with `` pip ``
--------------------------------
2013-03-16 15:21:04 +01:00
2020-03-23 18:34:23 +01:00
Ansible can be installed with `` pip `` , the Python package manager. If `` pip `` isn't already available on your system of Python, run the following commands to install it::
2013-03-16 15:21:04 +01:00
2019-04-04 04:35:59 +02:00
$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ python get-pip.py --user
2012-08-07 02:53:33 +02:00
2020-08-04 20:39:24 +02:00
.. note ::
If you have Ansible 2.9 or older installed, you need to use `` pip uninstall ansible `` first to remove older versions of Ansible before re-installing it.
2019-04-04 04:35:59 +02:00
Then install Ansible [1]_ ::
2012-08-13 20:51:36 +02:00
2020-02-12 16:06:23 +01:00
$ python -m pip install --user ansible
2016-10-30 04:27:15 +01:00
2019-04-04 04:35:59 +02:00
In order to use the `` paramiko `` connection plugin or modules that require `` paramiko `` , install the required module [2]_ ::
2020-02-12 16:06:23 +01:00
$ python -m pip install --user paramiko
2019-04-04 04:35:59 +02:00
If you wish to install Ansible globally, run the following commands::
$ sudo python get-pip.py
2020-03-23 18:34:23 +01:00
$ sudo python -m pip install ansible
2018-06-06 05:57:07 +02:00
.. note ::
2019-06-13 16:27:23 +02:00
Running `` pip `` with `` sudo `` will make global changes to the system. Since `` pip `` does not coordinate with system package managers, it could make changes to your system that leaves it in an inconsistent or non-functioning state. This is particularly true for macOS. Installing with `` --user `` is recommended unless you understand fully the implications of modifying global files on the system.
2019-04-04 04:35:59 +02:00
.. note ::
Older versions of `` pip `` default to http://pypi.python.org/simple, which no longer works.
Please make sure you have the latest version of `` pip `` before installing Ansible.
If you have an older version of `` pip `` installed, you can upgrade by following `pip's upgrade instructions <https://pip.pypa.io/en/stable/installing/#upgrading-pip> `_ .
2012-03-18 17:41:00 +01:00
2020-08-04 20:39:24 +02:00
Upgrading Ansible from version 2.9 and older to version 2.10 or later
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2020-07-31 19:13:54 +02:00
2020-08-04 20:39:24 +02:00
Starting in version 2.10, Ansible is made of two packages. You need to first uninstall the old Ansible version (2.9 or earlier) before upgrading.
If you do not uninstall the older version of Ansible, you will see the following message, and no change will be performed:
2020-07-31 19:13:54 +02:00
.. code-block :: console
Cannot install ansible-base with a pre-existing ansible==2.x installation.
Installing ansible-base with ansible-2.9 or older currently installed with
pip is known to cause problems. Please uninstall ansible and install the new
version:
pip uninstall ansible
pip install ansible-base
...
As explained by the message, to upgrade you must first remove the version of Ansible installed and then install it
to the latest version.
.. code-block :: console
$ pip uninstall ansible
$ pip install ansible
2020-03-23 18:34:23 +01:00
.. _from_pip_devel:
Installing the development version of Ansible
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. note ::
You should only run Ansible from `` devel `` if you are modifying the Ansible engine, or trying out features under development. This is a rapidly changing source of code and can become unstable at any point.
2020-08-04 20:39:24 +02:00
.. note ::
If you have Ansible 2.9 or older installed, you need to use `` pip uninstall ansible `` first to remove older versions of Ansible before re-installing it.
2020-03-23 18:34:23 +01:00
The development version of Ansible can be directly installed from GitHub with pip::
$ python -m pip install --user https://github.com/ansible/ansible/archive/devel.tar.gz
2017-08-04 06:33:13 +02:00
2020-03-23 18:34:23 +01:00
Replace `` devel `` in the URL mentioned above, with any other branch or tag on GitHub to install that version::
$ python -m pip install --user https://github.com/ansible/ansible/archive/stable-2.9.tar.gz
See :ref: `from_source` for instructions on how to run Ansible directly from source, without the requirement of installation.
.. _from_pip_venv:
Virtual Environments
^^^^^^^^^^^^^^^^^^^^
2020-08-04 20:39:24 +02:00
.. note ::
If you have Ansible 2.9 or older installed, you need to use `` pip uninstall ansible `` first to remove older versions of Ansible before re-installing it.
2020-03-23 18:34:23 +01:00
Ansible can also be installed inside a new or existing `` virtualenv `` ::
$ python -m virtualenv ansible # Create a virtualenv if one does not already exist
$ source ansible/bin/activate # Activate the virtual environment
$ python -m pip install ansible
2017-08-04 06:33:13 +02:00
2016-10-30 04:27:15 +01:00
.. _from_source:
2020-01-16 17:30:26 +01:00
Running Ansible from source (devel)
-----------------------------------
2016-10-30 04:27:15 +01:00
2020-02-17 17:53:16 +01:00
.. note ::
2020-02-19 22:17:42 +01:00
You should only run Ansible from `` devel `` if you are modifying the Ansible engine, or trying out features under development. This is a rapidly changing source of code and can become unstable at any point.
2020-02-17 17:53:16 +01:00
2019-04-04 04:35:59 +02:00
Ansible is easy to run from source. You do not need `` root `` permissions
to use it and there is no software to actually install. No daemons
2020-02-17 17:53:16 +01:00
or database setup are required.
2016-10-30 04:27:15 +01:00
.. note ::
2020-01-16 17:30:26 +01:00
If you want to use Ansible Tower as the control node, do not use a source installation of Ansible. Please use an OS package manager (like `` apt `` or `` yum `` ) or `` pip `` to install a stable version.
2016-10-30 04:27:15 +01:00
2017-05-28 10:42:50 +02:00
To install from source, clone the Ansible git repository:
2016-10-30 04:27:15 +01:00
.. code-block :: bash
2018-11-09 02:43:43 +01:00
$ git clone https://github.com/ansible/ansible.git
2016-10-30 04:27:15 +01:00
$ cd ./ansible
2019-04-04 04:35:59 +02:00
Once `` git `` has cloned the Ansible repository, setup the Ansible environment:
2017-05-28 10:42:50 +02:00
2016-10-30 04:27:15 +01:00
Using Bash:
.. code-block :: bash
$ source ./hacking/env-setup
Using Fish::
2018-04-05 20:51:55 +02:00
$ source ./hacking/env-setup.fish
2016-10-30 04:27:15 +01:00
If you want to suppress spurious warnings/errors, use::
$ source ./hacking/env-setup -q
2019-04-04 04:35:59 +02:00
If you don't have `` pip `` installed in your version of Python, install it::
2016-10-30 04:27:15 +01:00
2019-04-04 04:35:59 +02:00
$ curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py
$ python get-pip.py --user
2016-10-30 04:27:15 +01:00
2017-02-15 15:58:09 +01:00
Ansible also uses the following Python modules that need to be installed [1]_ :
2016-10-30 04:27:15 +01:00
2017-02-15 15:58:09 +01:00
.. code-block :: bash
2020-03-23 18:34:23 +01:00
$ python -m pip install --user -r ./requirements.txt
2016-10-30 04:27:15 +01:00
2020-01-16 17:30:26 +01:00
To update Ansible checkouts, use pull-with-rebase so any local changes are replayed.
2016-10-30 04:27:15 +01:00
.. code-block :: bash
$ git pull --rebase
2017-01-09 18:11:39 +01:00
.. code-block :: bash
$ git pull --rebase #same as above
2016-10-30 04:27:15 +01:00
$ git submodule update --init --recursive
Once running the env-setup script you'll be running from checkout and the default inventory file
2019-04-04 04:35:59 +02:00
will be `` /etc/ansible/hosts `` . You can optionally specify an inventory file (see :ref: `inventory` )
other than `` /etc/ansible/hosts `` :
2016-10-30 04:27:15 +01:00
.. code-block :: bash
$ echo "127.0.0.1" > ~/ansible_hosts
$ export ANSIBLE_INVENTORY=~/ansible_hosts
2020-01-16 17:30:26 +01:00
You can read more about the inventory file at :ref: `inventory` .
2016-10-30 04:27:15 +01:00
Now let's test things with a ping command:
.. code-block :: bash
$ ansible all -m ping --ask-pass
2016-11-08 22:36:28 +01:00
You can also use "sudo make install".
2016-10-30 04:27:15 +01:00
2020-01-16 17:30:26 +01:00
.. _tagged_releases:
Finding tarballs of tagged releases
-----------------------------------
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
Packaging Ansible or wanting to build a local package yourself, but don't want to do a git checkout? Tarballs of releases are available on the `Ansible downloads <https://releases.ansible.com/ansible> `_ page.
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
These releases are also tagged in the `git repository <https://github.com/ansible/ansible/releases> `_ with the release version.
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
.. _shell_completion:
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
Ansible command shell completion
--------------------------------
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
As of Ansible 2.9, shell completion of the Ansible command line utilities is available and provided through an optional dependency
called `` argcomplete `` . `` argcomplete `` supports bash, and has limited support for zsh and tcsh.
You can install `` python-argcomplete `` from EPEL on Red Hat Enterprise based distributions, and or from the standard OS repositories for many other distributions.
For more information about installing and configuration see the `argcomplete documentation <https://argcomplete.readthedocs.io/en/latest/> `_ .
Installing `` argcomplete `` on RHEL, CentOS, or Fedora
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-04-23 20:54:39 +02:00
On Fedora:
.. code-block :: bash
$ sudo dnf install python-argcomplete
On RHEL and CentOS:
.. code-block :: bash
$ sudo yum install epel-release
$ sudo yum install python-argcomplete
2020-01-16 17:30:26 +01:00
Installing `` argcomplete `` with `` apt ``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-04-23 20:54:39 +02:00
.. code-block :: bash
$ sudo apt install python-argcomplete
2020-01-16 17:30:26 +01:00
Installing `` argcomplete `` with `` pip ``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-04-23 20:54:39 +02:00
.. code-block :: bash
2020-03-23 18:34:23 +01:00
$ python -m pip install argcomplete
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
Configuring `` argcomplete ``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
There are 2 ways to configure `` argcomplete `` to allow shell completion of the Ansible command line utilities: globally or per command.
2019-04-23 20:54:39 +02:00
Globally
2020-01-16 17:30:26 +01:00
"""""""""
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
Global completion requires bash 4.2.
2019-04-23 20:54:39 +02:00
.. code-block :: bash
$ sudo activate-global-python-argcomplete
2020-01-16 17:30:26 +01:00
This will write a bash completion file to a global location. Use `` --dest `` to change the location.
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
Per command
"""""""""""
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
If you do not have bash 4.2, you must register each script independently.
2019-04-23 20:54:39 +02:00
.. code-block :: bash
$ eval $(register-python-argcomplete ansible)
$ eval $(register-python-argcomplete ansible-config)
$ eval $(register-python-argcomplete ansible-console)
$ eval $(register-python-argcomplete ansible-doc)
$ eval $(register-python-argcomplete ansible-galaxy)
$ eval $(register-python-argcomplete ansible-inventory)
$ eval $(register-python-argcomplete ansible-playbook)
$ eval $(register-python-argcomplete ansible-pull)
$ eval $(register-python-argcomplete ansible-vault)
2020-01-16 17:30:26 +01:00
You should place the above commands into your shells profile file such as `` ~/.profile `` or `` ~/.bash_profile `` .
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
`` argcomplete `` with zsh or tcsh
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2019-04-23 20:54:39 +02:00
2020-01-16 17:30:26 +01:00
See the `argcomplete documentation <https://argcomplete.readthedocs.io/en/latest/> `_ .
2019-04-23 20:54:39 +02:00
2017-05-28 10:42:50 +02:00
.. _getting_ansible:
Ansible on GitHub
2020-01-16 17:30:26 +01:00
-----------------
2017-05-28 10:42:50 +02:00
You may also wish to follow the `GitHub project <https://github.com/ansible/ansible> `_ if
2019-04-04 04:35:59 +02:00
you have a GitHub account. This is also where we keep the issue tracker for sharing
2017-05-28 10:42:50 +02:00
bugs and feature ideas.
2012-03-09 20:39:29 +01:00
.. seealso ::
2018-03-14 20:44:21 +01:00
:ref: `intro_adhoc`
2012-03-11 20:34:21 +01:00
Examples of basic commands
2018-03-14 20:44:21 +01:00
:ref: `working_with_playbooks`
2012-03-11 20:34:21 +01:00
Learning ansible's configuration management language
2018-06-15 17:14:01 +02:00
:ref: `installation_faqs`
Ansible Installation related to FAQs
2018-07-21 15:48:47 +02:00
`Mailing List <https://groups.google.com/group/ansible-project> `_
2012-03-31 15:55:37 +02:00
Questions? Help? Ideas? Stop by the list on Google Groups
`irc.freenode.net <http://irc.freenode.net> `_
#ansible IRC chat channel
2012-03-11 20:34:21 +01:00
2018-08-31 18:12:12 +02:00
.. [1] If you have issues with the "pycrypto" package install on macOS, then you may need to try `` CC=clang sudo -E pip install pycrypto `` .
2019-04-04 04:35:59 +02:00
.. [2] `` paramiko `` was included in Ansible's `` requirements.txt `` prior to 2.8.