What is ansible?
Ansible is the IT automation engine that helps you end repetitive tasks, speed productivity and scale your efforts.
How Ansible works
In Ansible, there are two categories of computers: the control node and managed nodes. The control node is a computer that runs Ansible. There must be at least one control node, although a backup control node may also exist. A managed node is any device being managed by the control node.
Ansible works by connecting to nodes (clients, servers, or whatever you’re configuring) on a network, and then sending a small program called an Ansible module to that node. Ansible executes these modules over SSH and removes them when finished. The only requirement for this interaction is that your Ansible control node has login access to the managed nodes. SSH keys are the most common way to provide access, but other forms of authentication are also supported.
Benefits of Using Ansible :
- Agentless: As long as a connection can be SSHed and it has Python, it can be configured with Ansible; No agent/software or additional firewall ports are required to install on our client or host systems for automation. Also, we don’t have to worry about setting up and managing the infrastructure.
2. Simple: As we’ve seen, Ansible uses a very simple syntax written in YAML known as playbooks — YAML (Yet Another Markup Language) is a human-readable data serialization language. We don’t need special coding skills to code and understand playbooks. It is very easy to install and execute tasks in order.
3. Modular: Ansible is modular as we require only one program per script. This way, we can spread our programs across different servers.
4. Efficient: Not requiring any extra software on our servers means that there is more space for our resources.
5. Powerful and flexible: Having powerful features gives us the capability to model even complex IT workflows in lesser time, along with managing infrastructure, networks, operating systems, and services that are already in use.
The “inventory” is a configuration file where you define the host information. In the above /etc/ansible/hosts example, we declared two servers under test-hosts.
In most cases — especially in enterprise environments — you should use Ansible playbooks. A playbook is where you define how to apply policies, declare configurations, orchestrate steps and launch tasks either synchronously or asynchronously on your servers. Each playbook is composed of one or more “plays”. Playbooks are normally maintained and managed in a version control system like Git. They are expressed in YAML (Yet Another Markup Language).
Playbooks contain plays. Plays are essentially groups of tasks that are performed on defined hosts to enforce your defined functions. Each play must specify a host or group of hosts. For example, using:
– hosts: all
…we specify all hosts. Note that YML files are very sensitive to white spaces, so be careful!
Tasks are actions carried out by playbooks. One example of a task in an Apache playbook is:
- name: Install Apache httpd
A task definition can contain modules such as yum, git, service, and copy.
A role is the Ansible way of bundling automation content and making it reusable. Roles are organizational components that can be assigned to a set of hosts to organize tasks. Therefore, instead of creating a monolithic playbook, we can create multiple roles, with each role assigned to complete a unit of work. For example a webserver role can be defined to install Apache and Varnish on a specified group of servers.
Handlers are similar to tasks except that a handler will be executed only when it is called by an event. For example, a handler that will start the httpd service after a task installed httpd. The handler is called by the [notify] directive. Important: the name of the notify directive and the handler must be the same.
Templates files are based on Python’s Jinja2 template engine and have a .j2 extension. You can, if you need, place contents of your index.html file into a template file. But the real power of these files comes when you use variables. You can use Ansible’s [facts] and even call custom variables in these template files.
As the name suggests, you can include custom-made variables in your playbooks. Variables can be defined in five different ways:
1. Variables defined in the play under vars_files attribute:
2. Variables defined in <role>/vars/apache-install.yml
3. Variables passed through the command line:
# ansible-playbook apache-install.yml -e "http-port=80"
4. Variables defined in the play under vars
vars: http_port: 80
5. Variables defined in group_vars/ directory
## PLAYBOOK TO INSTALL AND CONFIGURE APACHE HTTP ON Servers
- hosts: all
- name: Install Apache httpd
yum: pkg=httpd state=installed
- Start Httpd
- name: Start httpd
service: name=httpd state=started
You run the playbook from your Ansible Server. The following command has been run from within the path where our apache-playbook.yml playbook is stored:
# ansible-playbook apache-install.yml --ask-pass -u "ansibleadmin"
Use cases of Ansible
Your apps have to live somewhere. If you’re PXE booting and kickstarting bare-metal servers or VMs, or creating virtual or cloud instances from templates, Ansible and Red Hat® Ansible® Tower help streamline the process.
Centralizing configuration file management and deployment is a common use case for Ansible, and it’s how many power users are first introduced to the Ansible automation platform.
When you define your application with Ansible and manage the deployment with Ansible Tower, teams are able to effectively manage the entire application lifecycle from development to production.
Creating a CI/CD pipeline requires buy-in from numerous teams. You can’t do it without a simple automation platform that everyone in your organization can use. Ansible Playbooks keep your applications properly deployed (and managed) throughout their entire lifecycle.
When you define your security policy in Ansible, scanning and remediation of site-wide security policy can be integrated into other automated processes and instead of being an afterthought, it’ll be integral in everything that is deployed.
Configurations alone don’t define your environment. You need to define how multiple configurations interact and ensure the disparate pieces can be managed as a whole. Out of complexity and chaos, Ansible brings order.
ARISTA CLOUD NETWORKING
Arista’s software driven cloud networking model is helping to redefine cloud architectures as data centers adapt to achieve better agility and economy. Arista enables the use of standard provisioning and automation systems such as Ansible through our open Linux approach, bringing Net-Ops and Dev-Ops unification.
Arista has been committed to open standards and to modern software from the inception of the company. We believe that innovation within these frameworks drives customer success and permits our customers to build true multi-vendor networks. Our customers want choices, not proprietary lock-in.
Arista Networks and Ansible have partnered to bring the strength and agility of Ansible to your network. Arista is built on extensibility and continues to leverage third-party integrations like Ansible to help you get the most out of your switch.
- Arista modules leverage the syntax of the running configuration — mirroring the syntax with which most network engineers are familiar.
- Ansible can communicate with your Arista switch using using CLI or eAPI. The CLI-based connection utilizes SSH to securely manage your device.
- Leverages existing EOS CLI or TACACS users which provides built-in authorization.
- Add vEOS instances and a build tool like Jenkins to create an end to end continuous testing solution.
- Arista EOS modules include: eAPI, command, config and template.
The combined Ansible and Arista solution provides:
- Improved speed and accuracy
- No third-party EOS extensions required
- No additional switch configuration required
- Complete control of your configuration with idempotency built in
- Make intelligent, dynamic decisions in your playbooks
- Enables continuous compliance of EOS configuration
INCREASING CLOUD EFFICIENCY WITH ANSIBLE AND ANSIBLE TOWER
INDUSTRY : Government
ORGANISATION : The National Aeronautics and Space Administration (NASA) is the agency of the United States government that is responsible for the nation’s civilian space program and for aeronautics and aerospace research.
INTEGRATION : Cloud/AWS
USE CASES : Configuration Management
ISSUE: Increase efficiency, cloud migration
CHALLENGE : NASA needed to move roughly 65 applications from a traditional hardware based data center to a cloud-based environment for better agility and cost savings. The rapid timeline resulted in many applications being migrated ‘as-is’ to a cloud environment. This created an environment spanning multiple virtual private clouds (VPCs) and AWS accounts that could not be easily managed. Even simple things, like ensuring every system administrator had access to every server, or simple patching, were extremely burdensome.
SOLUTION : Leverage Ansible Tower to manage and schedule the cloud environment.
RESULTS :As a result of implementing Ansible Tower, NASA is better equipped to manage its AWS environment. Tower allowed NASA to provide better operations and security to its clients. It has also increased efficiency as a team. By the numbers:
- Updating nasa.gov went from over 1 hour to under 5 minutes
- Patching updates went from a multi-day process to 45 minutes
- Achieving near real-time RAM and disk monitoring (accomplished without agents)
- Provisioning OS Accounts across entire environment in under 10 minutes
- Baselining standard AMIs went from 1 hour of manual configuration to becoming an invisible and seamless background process
- Application stack set up from 1–2 hours to under 10 minutes per stack
ABOUT THE CUSTOMER
The National Aeronautics and Space Administration (NASA) is the agency of the United States government that is responsible for the nation’s civilian space program and for aeronautics and aerospace research.