Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1/ 10
Ansible 407
This exam is based on Red Hat® Enterprise Linux® 7.3 and Ansible 2.3.
Ansible tips
If you decide to use Ansible, make sure you set the proper configurations in the /etc/ansible/ansible.cfg file. The bare minimum if you're using ssh keys (which I highly recommend) instead of using root is set the following settings:
host_key_checking = False
Ansible has two components: Ansible Core and Ansible Tower. Core provides the Ansible runtime that executes
playbooks (yaml files defining tasks and roles) against
inventories (group of hosts). Ansible Tower provides management, visibility, job scheduling, credentials, RBAC, auditing / compliance and more.
Ansible Tower uses an Ansible playbook to deploy itself. As such configuration
parameters or groupvars are stored in inventory file.
Configuring Ansible Hosts
Ansible keeps track of all of the servers that it knows about through a "hosts" file. We need to set up this file first before we can begin to communicate with our other computers.
On the server2, edit the /etc/ssh/sshd_config file and set the following options:
PasswordAuthentication no PubkeyAuthentication yes
Ansible basic commands
ansible -m ping all
ansible --list-hosts all
Ansible uses playbook to describe automation jobs and uses YAML – It is in human readable form
Ansible Galaxy is Ansible’s official community hub for sharing Ansible roles. A role is the Ansible way of bundling automation content and making it reusable.
Ansible Galaxy can help you: https://galaxy.ansible.com/
1. learn by example looking at the code other people have written and; 2. develop great playbooks by orchestrating roles that have been created by the community.
The thought process workflow - https://www.redhat.com/en/blog/developers-shortcut-
getting-started-ansible#
Ansible Basics
Ansible Engine – The Ansible runtime and CLI which executes playbooks. The engine runs on a management node, from where you want to drive automation. Playbook – A series or group of tasks that automate a process. Playbooks are written in YAML. Inventory – Determines what hosts you want to run playbook against. Inventories can be dynamic or static. Configuration – The configuration for Ansible is stored in ansible.cfg by default under /etc/ansible/ansible.cfg. It determines default settings for Ansible, where the inventory is located and much more. You can have many ansible.cfg files. Role – Ansible way to build re-usable automation components. A role groups together playbooks, templates, variables and everything needed to automate a given process in a pre-packaged unit of work. Ansible Galaxy – Ansible roles provided by the Ansible community. Not only can you get access to 1000s of roles, but you can share as well. Ansible Modules – Used in Ansible to perform tasks, install software, enable services, etc. Modules are provided with Ansible (core modules) and provided by the community. They are mostly written in python which is used by Ansible itself. Ansible Tower – API and UI for Ansible to handle scheduling, reporting, visualization and support teamwork for organizations running many playbooks across many teams. Ansible Complete Beginners Tutorial:
DONT MISS THIS IF YOU ARE SERIOUSLY INTERESTED TO LEARN "ANSIBLE" FROM BEGINNING. LINKS ARE ARRANGED TO MAKE YOU UNDERSTAND EASILY.
Spend few minutes and start working on Ansible. Make use of it, Share to your friends and groups.
https://keithtenzer.com/2017/11/09/ansible-getting-started-guide/ - read this
Also there are more other videos on Puppet, Openstack cloud, VCS Cluster.... For more free documents and tutorial videos, Like us on Facebook : https://www.facebook.com/learnitguide Subscribe on Youtube : https://www.youtube.com/learnitguide Follow us on Twitter : https://www.twitter.com/learnitguide Visit our Website : https://www.learnitguide.net
o Inventories o Modules o Variables o Facts o Plays o Playbooks o Configuration files Install and configure an Ansible control node o Install required packages o Create a static host inventory file o Create a configuration file Configure Ansible managed nodes o Create and distribute SSH keys to managed nodes o Configure privilege escalation on managed nodes o Validate a working configuration using ad-hoc Ansible commands Create simple shell scripts that run ad hoc Ansible commands Use both static and dynamic inventories to define groups of hosts Utilize an existing dynamic inventory script Create Ansible plays and playbooks o Know how to work with commonly used Ansible modules o Use variables to retrieve the results of running commands o Use conditionals to control play execution o Configure error handling o Create playbooks to configure systems to a specified state Use Ansible modules for system administration tasks that work with: o Software packages and repositories o Services o Firewall rules o File systems o Storage devices o File content o Archiving o Scheduled tasks o Security o Users and groups Create and use templates to create customized configuration files Work with Ansible variables and facts Create and work with roles Download roles from an Ansible Galaxy and use them Manage parallelism Use Ansible Vault in playbooks to protect sensitive data Use provided documentation to look up specific information about Ansible modules and commands
working with Ansible inventories including dynamic inventories, running ad-hoc Ansible commands, leveraging Ansible facts, creating Jinja2 templates, error handling, playbook tags, downloading a role from Ansible Galaxy and using Ansible vault to secure passwords.
Exam Tips
1. Use the ansible-playbook --limit parameter, to try out your playbook against a single host first before applying it to all your hosts. 2. Make sure you can run Ansible modules as ad-hoc commands. They can come handy when you want to undo the effects of running an erroneous playbook. 3. Use ansible-doc --list to look up a module that can achieve your goal and ansible- doc <module> to learn about the module parameters and example usage. 4.
Managed hosts are listed in an inventory, which also organizes those systems into groups for easier collective management. The inventory can be defined in a static text file, or dynamically determined by scripts that get information from external sources. A play performs a series of tasks on the host or hosts, in the order specified by the play. These plays are expressed in YAML format in a text file. A file that contains one or more plays is called a playbook.
NB: Tasks, plays, and playbooks should be idempotent.
In the following example, the host inventory defines two host groups, webservers and db-servers.
[webservers]
web1.example.com
web2.example.com
192.0.2.42
[db-servers]
db1.example.com
db2.example.com
Two host groups always exist:
• The all host group contains every host explicitly listed in the inventory.
• The ungrouped host group contains every host explicitly listed in the inventory that
isn't a member of any other group.
Overriding the Location of the Inventory
The /etc/ansible/hosts file is considered the system's default static inventory file.
The /etc/ansible/ansible.cfg configuration file is the default config file.
Because of the multitude of locations in which Ansible configuration files can be
placed, it can be confusing which configuration file is being used by Ansible, especially when multiple files exist on the control node. You can run the
# ansible --version command or use ansible servers --list-hosts -v
to clearly identify which version of Ansible is installed, and which configuration file is being used.
# ansible all -m ping
# ansible ltzservers -m ping – ltzservers is a hostgroup
# ansible all -i /home/mildred/install/inventory --list-hosts -v
Common ansible modules
File modules, such as copy (copy a local file to the managed host), get_url (download a file to the managed host), synchronize (to synchronize content like rsync), file (set permissions and other properties of a file), and lineinfile (make sure a certain line is or isn't in a file) Software package management modules, such as yum, dnf, apt, pip, gem, and so on System administration tools, such as service, to control daemons, and user, to o add, o remove and o configure users uri, which interacts with a web server and can test functionality or issue API requests
# Ad hoc commands pass arguments to modules using the -a option.
#Its always recommended to create an ansible user to be used on all hosts
# Source of key(s) to be installed: "/home/mildred/.ssh/id_rsa.pub"
NB: Always create a projects directory to distinguish between different tasks and add an inventory file for every project.
Roles
A role is a collection of tasks and templates (among other things, but those are the most common) focused on one very specific goal. For instance, you can have a role that installs nginx, another that deploys ssh keys for admins, etc…
Nginx role will install and configure nginx. Nothing else. It won’t create DNS entries, trim logs, add a ftp server or anything. It just installs nginx. Period.
Another one: Roles are a way to make code in playbooks reusable by putting the functionality into generalized "libraries" that can be then used in any playbook as needed.
Roles are a way to group tasks together into one container. You could have a role for setting up MySQL, another one for setting up Postfix etc.
A playbook defines what is happening where. This is the place where you define the hosts (hostgroups, see below) and the roles which will be applied to those hosts.
Inventories
An inventory is a list of hosts, eventually assembled into groups, on which you will run ansible playbooks. Ansible automatically puts all defined hosts in the aptly named group all. For instance, you could have hosts www1 and www2, assembled in group webservers, and later reference the group or individual hosts, depending on your needs.
Inventories can also come with variables applied to hosts or groups (including all).
Inventories can be dynamic. If the inventory file is executable, Ansible will run it and use its output as the inventory (note that, in this case, the format is not the same as static inventory).
You can of course have multiple inventories, segregated from each other. We will take advantage from this later on.
Playbooks
The last piece of the puzzle is the playbook. The playbook is the pivot between and inventory and roles. This is where you basically tell Ansible: please install roles foo, bar and baz on machines alice, bob and charlie.
# Playbooks consist of tasks which are executed in the order which they are listed in If a tasks fails Ansible will stop executing further tasks on that specific system.
Playbooks are written in YAML syntax which is a data serialization format like XML and JSON but much better human readable. A convention of YAML is to start every file with three dashes (—).
A simple Playbook which makes sure the user mikhail exists might look like this.
users.yml:
--- - hosts: all sudo: yes tasks: - name: Configure Users user: name=mikhail comment='Martin and Mildred’s son' group=admins groups=wheel
When run this playbook will make sure that the user mikhail is present, that his primary group will be admins and that he will be member of the group wheel. If this is not the case the system will ‘make it so’ and if it’s already the case it will do nothing, this is called ‘idempotent’ in configuration management lingo, it doesn’t matter how many times you run the command, the endstate will always be the same.
You can specify the inventory by pointing to either a file, a script, or a directory:
in command-line: ansible-playbook playbook.yml -i /path/to/inventory
The playbook directory is simply the one in which the playbook is stored.
in ansible.cfg:
inventory = /path/to/inventory NB: In order for that line in ansible.cfg to work it MUST be in the [defaults] section or ansible will refuse to use it
A play is a set of tasks or roles (or both) inside a playbook. In most cases (and examples) a playbook will contain only one single play. But you can have as many as you like. That means you could have a playbook which will run the role postfix on the hostgroup mail_servers and the role mysql on the hostgroup databases:
- hosts: mail_servers roles: - postfix
- hosts: databases roles: - mysql
AFAIK you have to provide the path to the playbook when invoking ansible-playbook. So ansible- playbook someplaybook.yaml would expect someplaybook.yaml to be in you current directory. But you can provide the full path: ansible-playbook /path/to/someplaybook.yaml
Note that the hosts file is known as the inventory file.
