# Getting Started # Ansible concepts These concepts are common to all uses of Ansible. You should understand them before using Ansible or reading the documentation.
# Start automating with Ansible Get started with Ansible by creating an automation project, building an inventory, and creating a "Hello World" playbook. 1. Install Ansible. ``` bash pip install ansible ``` 2. Create a project folder on your filesystem. ``` bash mkdir ansible_quickstart && cd ansible_quickstart ``` Using a single directory structure makes it easier to add to source control as well as to reuse and share automation content. Continue getting started with Ansible by `building an inventory`.
`installation_guide` Installation guide with instructions for installing Ansible on various operating systems [Ansible Demos](https://github.com/ansible/product-demos) Demonstrations of different Ansible usecases [Ansible Labs](https://www.ansible.com/products/ansible-training) Labs to provide further knowledge on different topics `Ansible Communication Guide` Questions? Help? Ideas? Ask the community
# Building an inventory Inventories organize managed nodes in centralized files that provide Ansible with system information and network locations. Using an inventory file, Ansible can manage a large number of hosts with a single command. To complete the following steps, you will need the IP address or fully qualified domain name (FQDN) of at least one host system. For demonstration purposes, the host could be running locally in a container or a virtual machine. You must also ensure that your public SSH key is added to the `authorized_keys` file on each host. Continue getting started with Ansible and build an inventory as follows: 1. Create a file named `inventory.ini` in the `ansible_quickstart` directory that you created in the `preceding step`. 2. Add a new `[myhosts]` group to the `inventory.ini` file and specify the IP address or fully qualified domain name (FQDN) of each host system. ``` ini [myhosts] 192.0.2.50 192.0.2.51 192.0.2.52 ``` 3. Verify your inventory. ``` bash ansible-inventory -i inventory.ini --list ``` 4. Ping the `myhosts` group in your inventory. ``` bash ansible myhosts -m ping -i inventory.ini ``` > [!NOTE] > Pass the `-u` option with the `ansible` command if the username is different on the control node and the managed node(s).
ansible_output/ping_inventory_output.txt
Congratulations, you have successfully built an inventory. Continue getting started with Ansible by `creating a playbook`. ## Inventories in INI or YAML format You can create inventories in either `INI` files or in `YAML`. In most cases, such as the example in the preceding steps, `INI` files are straightforward and easy to read for a small number of managed nodes. Creating an inventory in `YAML` format becomes a sensible option as the number of managed nodes increases. For example, the following is an equivalent of the `inventory.ini` that declares unique names for managed nodes and uses the `ansible_host` field:
yaml/inventory_example_vms.yaml
## Tips for building inventories - Ensure that group names are meaningful and unique. Group names are also case sensitive. - Avoid spaces, hyphens, and preceding numbers (use `floor_19`, not `19th_floor`) in group names. - Group hosts in your inventory logically according to their **What**, **Where**, and **When**. What Group hosts according to the topology, for example: db, web, leaf, spine. Where Group hosts by geographic location, for example: datacenter, region, floor, building. When Group hosts by stage, for example: development, test, staging, production. ### Use metagroups Create a metagroup that organizes multiple groups in your inventory with the following syntax: ``` yaml metagroupname: children: ``` The following inventory illustrates a basic structure for a data center. This example inventory contains a `network` metagroup that includes all network devices and a `datacenter` metagroup that includes the `network` group and all webservers.
yaml/inventory_group_structure.yaml
A group can belong to multiple metagroups. For example, the `network` group can appear under both `datacenter` and `ops` metagroups:
yaml/inventory_group_structure_multi.yaml
Variables defined for a parent group's `group_vars` apply to hosts in the child groups, but values defined in a child group's `group_vars` override the parent values. For predictable inheritance, prefer defining each group under only one parent metagroup even though multiple parents are allowed. ### Create variables Variables set values for managed nodes, such as the IP address, FQDN, operating system, and SSH user, so you do not need to pass them when running Ansible commands. Variables can apply to specific hosts.
yaml/inventory_variables_host.yaml
Variables can also apply to all hosts in a group.
yaml/inventory_variables_group.yaml
`intro_inventory` Learn more about inventories in `YAML` or `INI` format. `variables_in_inventory` Find out more about inventory variables and their syntax. `vault` Find out how to encrypt sensitive content in your inventory such as passwords and keys.
# Creating a playbook Playbooks are automation blueprints, in `YAML` format, that Ansible uses to deploy and configure managed nodes. Playbook A list of plays that define the order in which Ansible performs operations, from top to bottom, to achieve an overall goal. Play An ordered list of tasks that maps to managed nodes in an inventory. Task A reference to a single module that defines the operations that Ansible performs. Module A unit of code or binary that Ansible runs on managed nodes. Ansible modules are grouped in collections with a `Fully Qualified Collection Name (FQCN)` for each module. Complete the following steps to create a playbook that pings your hosts and prints a "Hello world" message: 1. Create a file named `playbook.yaml` in your `ansible_quickstart` directory, that you created earlier, with the following content:
yaml/first_playbook.yaml
2. Run your playbook. ``` bash ansible-playbook -i inventory.ini playbook.yaml ``` Ansible returns the following output:
ansible_output/first_playbook_output.txt
In this output you can see: - The names that you give the play and each task. You should always use descriptive names that make it easy to verify and troubleshoot playbooks. - The "Gathering Facts" task runs implicitly. By default, Ansible gathers information about your inventory that it can use in the playbook. - The status of each task. Each task has a status of `ok` which means it ran successfully. - The play recap that summarizes results of all tasks in the playbook per host. In this example, there are three tasks so `ok=3` indicates that each task ran successfully. Congratulations, you have started using Ansible!
`playbooks_intro` Start building playbooks for real world scenarios. `working_with_playbooks` Go into more detail with Ansible playbooks. `playbooks_best_practices` Get tips and tricks for using playbooks. `vars_and_facts` Learn more about the `gather_facts` keyword in playbooks.
# Getting started with Ansible Ansible automates the management of remote systems and controls their desired state. Basic components of an Ansible environment include a control node, an inventory of managed nodes, and a module copied to each managed node. As shown in the preceding figure, most Ansible environments have three main components: Control node A system on which Ansible is installed. You run Ansible commands such as `ansible` or `ansible-inventory` on a control node. Inventory A list of managed nodes that are logically organized. You create an inventory on the control node to describe host deployments to Ansible. Managed node A remote system, or host, that Ansible controls.
introduction get_started_ansible get_started_inventory get_started_playbook basic_concepts
# Introduction to Ansible Ansible provides open-source automation that reduces complexity and runs everywhere. Using Ansible lets you automate virtually any task. Here are some common use cases for Ansible: - Eliminate repetition and simplify workflows - Manage and maintain system configuration - Continuously deploy complex software - Perform zero-downtime rolling updates Ansible uses simple, human-readable scripts called playbooks to automate your tasks. You declare the desired state of a local or remote system in your playbook. Ansible ensures that the system remains in that state. As automation technology, Ansible is designed around the following principles: Agent-less architecture Low maintenance overhead by avoiding the installation of additional software across IT infrastructure. Simplicity Automation playbooks use straightforward YAML syntax for code that reads like documentation. Ansible is also decentralized, using SSH with existing OS credentials to access remote machines. Scalability and flexibility Easily and quickly scale the systems you automate through a modular design that supports a large range of operating systems, cloud platforms, and network devices. Idempotence and predictability When the system is in the state your playbook describes, Ansible does not change anything, even if the playbook runs multiple times. Ready to start using Ansible? `Get up and running in a few easy steps`.