Ansible for network engineers

Culture¶Many network engineers prefer to use the CLI for all things networking, like troubleshooting, ad-hoc operational configuration changes, and full-blown greenfield provisioning tasks.To harvest the full benefit of Ansible and Ansible AVD, you must learn to think differently and change your working methods.Ansible should be your first choice when changing your network configuration, whether small or big. The CLI should only be used for troubleshooting, i.e., viewing the state of your network or those urgent scenarios at 2 AM where you need to change something particular on just one or two devices, followed by proper configuration cleanup later.How does Ansible work?¶Before we can tell Ansible to do anything, Ansible needs to know about your network’s devices (or hosts).This is defined in the Ansible inventory. Per the official Ansible documentation, the inventory is a file type in either INI or YAML format, but other inventory sources can be used. In Ansible AVD, we use YAML format by default; hence the file is called inventory.yml, located in the Ansible AVD project folder (in this case, single-dc-l3ls):Please note that the example above is taken from the Ansible AVD Examples repository, specifically the Single-DC-L3LS.The exact name of the inventory file isn’t important but is provided to Ansible in the ansible.cfg file for the project or as ansible-playbook -i ./inventory.yml when later running Ansible.Inventories¶An example of a snippet of the inventory.yml file is shown below (a subset of an actual file for clarity).As stated earlier, this file is in YAML format.The hostnames specified in the inventory must exist either in DNS or in the hosts file on your Ansible host to allow successful name lookup and be able to reach the switches directly. To test this, you must be able to successfully ping the host, for example, ping dc1-spine1 from your Ansible host. Alternatively, if there is no DNS available, or if devices need to be reached using a fully qualified domain name (FQDN), define ansible_host to be an IP address or FQDN for each device - see dc1-spine1/2 below for an example:---all: children: FABRIC: children: DC1: children: DC1_SPINES: hosts: dc1-spine1: ansible_host: 172.16.1.11 dc1-spine2: ansible_host:

Release of Ansible or ansible-core. Release candidates allow the Ansible community to try out new features, test existing playbooks on the release candidate, and report bugs or issues they find.Ansible and ansible-core tag the first release candidate (RC1) which is usually scheduled to last five business days. If no major bugs or issues are identified during this period, the release candidate becomes the final release.If there are major problems with the first candidate, the team and the community fix them and tag a second release candidate (RC2). This second candidate lasts for a shorter duration than the first. If no problems have been reported for an RC2 after two business days, the second release candidate becomes the final release.If there are major problems in RC2, the cycle begins again with another release candidate and repeats until the maintainers agree that all major problems have been fixed.Development and maintenance workflowsIn between releases, the Ansible community develops new features, maintains existing functionality, and fixes bugs in ansible-core and in the collections included in the Ansible community package.ansible-core workflowThe Ansible community develops and maintains ansible-core on GitHub, with a workflow that looks like this:Developers add new features and bug fixes to the devel branch.Each new feature and each bug fix includes a changelog fragment describing the work.The development team backports bug fixes to one, two, or three stable branches, depending on the severity of the bug. They do not backport new features.Release engineers create a minor release for each maintained version every four weeks to ensure that the latest bug fixes are available to users.At the end of the development period, the release engineers impose a feature freeze and the work of creating a new release begins.We generally do not provide fixes for unmaintained releases of ansible-core, however, there can sometimes be exceptions for critical issues.For more information about adding features or fixing bugs in ansible-core see The Ansible Development Cycle.Generating changelogsWe generate changelogs based on fragments. When creating new features for existing modules and plugins or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for

'name=ncdu state=present'Remove ncdu package on all hosts[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'Build the directory structure for role named role1.[root@ansible-server test2]# ansible-galaxy init role1Dry-run p4.yml playbook[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --checkRun p4.yml playbook with password authentication for all hosts[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -kSummaryIn a world with technology that is continuously changing at a swift pace and growing incredibly fast at the same time, system administrators and devops engineers must think of different approaches on how to automate routine tasks and orchestrate large pools of servers.While there are many alternative to Ansible (Chef, Puppet) out there that do the same thing with some differences, Ansible managed to rise above all of them with its simplicity, improved security, and most important its smooth learning curve. Due to these qualities and fast adoption of Ansible, we created a tutorial full of examples so you can have an even more seamless first experience in working with Ansible.In this Ansible basics tutorial, we described ansible and talked a bit about its history. We mentioned the strong points of Ansible and the advantages that ansible can bring to automation and orchestration of infrastructures of different sizes. We defined the essential ansible used terms and defined the structure of Ansible playbooks. Thorough examples accompanied all information with detailed explanations.