Ansible is an IT automation tool. It can configure systems, deploy software, and orchestrate more advanced IT tasks such as continuous deployments or zero downtime rolling updates.
Ansible’s main goals are simplicity and ease-of-use. It also has a strong focus on security and reliability, featuring a minimum of moving parts, usage of OpenSSH for transport (with other transports and pull modes as alternatives), and a language that is designed around auditability by humans–even those not familiar with the program.
We believe simplicity is relevant to all sizes of environments, so we design for busy users of all types: developers, sysadmins, release engineers, IT managers, and everyone in between. Ansible is appropriate for managing all environments, from small setups with a handful of instances to enterprise environments with many thousands of instances.
Ansible manages machines in an agent-less manner. There is never a question of how to upgrade remote daemons or the problem of not being able to manage systems because daemons are uninstalled. Because OpenSSH is one of the most peer-reviewed open source components, security exposure is greatly reduced. Ansible is decentralized–it relies on your existing OS credentials to control access to remote machines. If needed, Ansible can easily connect with Kerberos, LDAP, and other centralized authentication management systems.
This documentation covers the current released version of Ansible and also some development version features. For recent features, we note in each section the version of Ansible where the feature was added.
Ansible releases a new major release of Ansible approximately every two months. The core application evolves somewhat conservatively, valuing simplicity in language design and setup. However, the community around new modules and plugins being developed and contributed moves very quickly, adding many new modules in each release.
Ansible Lightbulb 新版本是 Red Hat Ansible Automation Platform Workshops
The Ansible Lightbulb project is an effort to provide a content toolkit and educational reference for effectively communicating and teaching Ansible topics.
inventories/ production/ hosts # inventory file for production servers group_vars/ group1.yml # here we assign variables to particular groups group2.yml host_vars/ hostname1.yml # here we assign variables to particular systems hostname2.yml
staging/ hosts # inventory file for staging environment group_vars/ group1.yml # here we assign variables to particular groups group2.yml host_vars/ stagehost1.yml # here we assign variables to particular systems stagehost2.yml
library/ # if any custom modules, put them here (optional) module_utils/ # if any custom module_utils to support modules, put them here (optional) filter_plugins/ # if any custom filter plugins, put them here (optional)
site.yml # master playbook webservers.yml # playbook for webserver tier dbservers.yml # playbook for dbserver tier
files/ # here we assign files for simple plays plays/ # here we assign plays as the entrance tasks/ # here we assign tasks for plays to call
roles/ common/ # this hierarchy represents a "role" tasks/ # main.yml # <-- tasks file can include smaller files if warranted handlers/ # main.yml # <-- handlers file templates/ # <-- files for use with the template resource ntp.conf.j2 # <------- templates end in .j2 files/ # bar.txt # <-- files for use with the copy resource foo.sh # <-- script files for use with the script resource vars/ # main.yml # <-- variables associated with this role defaults/ # main.yml # <-- default lower priority variables for this role meta/ # main.yml # <-- role dependencies library/ # roles can also include custom modules module_utils/ # roles can also include custom module_utils lookup_plugins/ # or other types of plugins, like lookup in this case
webtier/ # same kind of structure as "common" was above, done for the webtier role monitoring/ # "" fooapp/ # ""
Expect a 1.25x - 7x speedup and a CPU usage reduction of at least 2x, depending on network conditions, modules executed, and time already spent by targets on useful work. Mitogen cannot improve a module once it is executing, it can only ensure the module executes as quickly as possible.
One connection is used per target, in addition to one sudo invocation per user account. This is much better than SSH multiplexing combined with pipelining, as significant state can be maintained in RAM between steps, and system logs aren’t spammed with repeat authentication events.
A single network roundtrip is used to execute a step whose code already exists in RAM on the target. Eliminating multiplexed SSH channel creation saves 4 ms runtime per 1 ms of network latency for every playbook step.
Processes are aggressively reused, avoiding the cost of invoking Python and recompiling imports, saving 300-800 ms for every playbook step.
Code is ephemerally cached in RAM, reducing bandwidth usage by an order of magnitude compared to SSH pipelining, with around 5x fewer frames traversing the network in a typical run.
Fewer writes to the target filesystem occur. In typical configurations, Ansible repeatedly rewrites and extracts ZIP files to multiple temporary directories on the target. Security issues relating to temporary files in cross-account scenarios are entirely avoided.
The effect is most potent on playbooks that execute many short-lived actions, where Ansible’s overhead dominates the cost of the operation, for example when executing large with_items loops to run simple commands or write files.
The strategy key is optional. If omitted, the ANSIBLE_STRATEGY=mitogen_linear environment variable can be set on a per-run basis. Like mitogen_linear, the mitogen_free and mitogen_host_pinned strategies exists to mimic the free and host_pinned strategies.
pre_tasks: - name: some pre-task shell: echo 'this task is the last, but would be executed before roles, and before tasks'
$ # The following example contains a shell-prompt to indicate the venv and relative path $ git clone git@github.com:sirkubax/ansible-for-learnXinYminutes.git user@host:~/$ cd ansible-for-learnXinYminutes user@host:~/ansible-for-learnXinYminutes$ source environment.sh $ $ # First lets execute the simple_playbook.yml (venv) user@host:~/ansible-for-learnXinYminutes$ ansible-playbook playbooks/simple_playbook.yml
$ source environment.sh $ # Now we would run the above playbook with roles (venv) user@host:~/ansible-for-learnXinYminutes$ ansible-playbook playbooks/simple_role.yml
roles/ some_role/ defaults/ # contains default variables files/ # for static files templates/ # for jinja templates tasks/ # tasks handlers/ # handlers vars/ # more variables (higher priority) meta/ # meta - package (role) info
{% for item in loop_items %} this line item is {{ item }} {% endfor %}
$ source environment.sh $ # Now we would run the above playbook with roles (venv) user@host:~/ansible-for-learnXinYminutes$ ansible-playbook playbooks/simple_role.yml --tags apache2
# check part of this playbook: playbooks/roles/sys_debug/tasks/debug_time.yml - local_action: shell date +'%F %T' register: ts become: False changed_when: False
- name: Timestamp debug: msg="{{ ts.stdout }}" when: ts is defined and ts.stdout is defined become: False
# get first item of the list {{ some_list | first() }} # if variable is undefined - use default value {{ some_variable | default('default_value') }}
# Try (this would fail) $ ansible-playbook playbooks/vault_example.yml
# in ansible.cfg set the path to your secret file $ vi ansible.cfg ansible_vault_password_file = ~/.ssh/secure_located_file
#or use env $ export ANSIBLE_VAULT_PASSWORD_FILE=~/.ssh/secure_located_file
$ ansible-playbook playbooks/vault_example.yml
# encrypt the file $ ansible-vault encrypt path/somefile
# view the file $ ansible-vault view path/somefile
# check the file content: $ cat path/somefile
# decrypt the file $ ansible-vault decrypt path/somefile
$ etc/inv/ec2.py --refresh $ ansible -m ping all -i etc/inv/ec2.py
vi ansible.cfg # set this to: callback_whitelist = profile_tasks
vi ansible.cfg
# if set to a persistent type (not 'memory', for example 'redis') fact values # from previous runs in Ansible will be stored. This may be useful when # wanting to use, for example, IP information from one group of servers # without having to talk to them in the same playbook run to get their # current IP information. fact_caching = jsonfile fact_caching_connection = ~/facts_cache fact_caching_timeout = 86400
