In this article, we will discuss what is ansible in DevOps and its use cases? If anyone asks you about ansible you can say simply this is an automation tool. But he/she can ask again there is a lot of automation tools like Jenkins, Nagios, Docker, Kubernetes so what is new in ansible? Simply you can say that all these tools are also automation tools, but it’s depended on you what kind of automation you want to achieve like if you want to automate your monitoring then use Nagios. If you want to automate your deployment and testing, then use Jenkins. Similarly, if you want to automate your configuration level task then use ansible.
Ansible is a software tool that provides simple but powerful automation for cross-platform computer support. It is primarily intended for IT professionals, who use it for application deployment, updates on workstations and servers, cloud provisioning, configuration management, intra-service orchestration, and nearly anything a systems administrator does on a weekly or daily basis. Ansible doesn’t depend on agent software and has no additional security infrastructure, so it’s easy to deploy.
Because Ansible is all about automation, it requires instructions to accomplish each job. With everything written down in simple script form, it’s easy to do version control. The practical result of this is a major contribution to the “infrastructure as code” movement in IT: the idea that the maintenance of server and client infrastructure can and should be treated the same as software development, with repositories of self-documenting, proven, and executable solutions capable of running an organization regardless of staff changes.
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.
Working in IT, you’re likely doing the same tasks over and over. What if you could solve problems once and then automate your solutions going forward?
Ansible is here to help.
Complexity kills productivity
Every business is a digital business. Technology is your innovation engine, and delivering your applications faster helps you win. Historically, that required a lot of manual effort and complicated coordination. But today, there is Ansible — the simple, yet powerful IT automation engine that thousands of companies are using to drive complexity out of their environments and accelerate DevOps initiatives.
How Ansible Works?
Ansible works by connecting to nodes and pushing out small programs called as ansible modules. Ansible then executes these modules over SSH by default and then remove them when finished.
The Ansible management node is the controlling node, which controls the entire execution of the Playbook. It’s the node from which you are running the installation, and the inventory file provides the list of the host where the modules need to be run. The management node makes ssh connection, and then it executes the modules on the host machines and installs the product. It removes the modules once they are installed. So that’s how ansible works.
Who uses Ansible?
1530 companies reportedly use Ansible in their tech stacks, including LaunchDarkly, Tokopedia, and ViaVarejo.
- Alibaba Travels.
Why Companies prefer 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.
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.
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.
We all know about Microsoft Azure very well and Ansible is helping this public cloud to automate things. Ansible’s library of Azure modules makes it easy to provision instances, networks, and complete Azure infrastructure whenever you need, and in any region you require. For example, the same simple Playbook language you use for application deployment and on-prem automation also provisions your Azure infrastructure, applying the correct configuration. So Azure deploys once and can use anywhere through the Ansible automation. Azure also uses this tool to scale its services and Ansible has modules for many different Azure capabilities, including.
Virtual Machine , Virtual Networks , Security Groups , Resource Groups
Ansible Automation & Architecture
Ansible is an SCM tool and is used to automate repetitive tasks that is usually done on a server. Ansible SCM tool consists 3 core subsystems: ACS (Ansible Control Server), Ansible Inventory and Ansible Playbooks. Before seeing a live example, it would be better to understand these Ansible terms and architecture a bit so can go with it.
NASA using Ansible
“ As a result of implementing Ansible we are better equipped to manage our environment. Ansible has allowed us to provide better operations and security to our clients. It has also increased our efficiency as a team.” — Jonathan Davila DevOps Lead, InfoZen
The Challenge Before Ansible
- Migrating 110 websites & apps to Amazon in 22 weeks.
- Everything was manual, following tasks documents. With time — started using shell scripts. Simple things were extremely burdensome.
How NASA is using Ansible?
To solve the problems that we had with a lack of centralized management and a diverse environment, they evaluated multiple solutions and decided on the implementation of Ansible Tower. They are now leveraging Ansible Tower to manage their environment in a very organized and scheduled way. As a result of their Ansible Tower implementation they achieved the following efficiencies:
NASA web app servers are being patched routinely and automatically through Ansible Tower with a very simple 10-line Ansible playbook.
• Ansible is also being used to remediate security issues and was leveraged to re-mediate both OpenSSL issues earlier this year. This not only saved their time but allowed them to quickly re-mediate a very daunting security issue.
Results after Ansible
As a result of implementing Ansible is better equipped to manage their environment. Ansible has allowed them to provide better operations and security to their clients. It increased their efficiency as a team.
• www.nasa.gov update window reduced from over 1 hour to 5 minutes or less
• Patching updates reduced from a multi-day process to a 45-minute process
• Near real-time RAM and Disk monitoring accomplished without agents
OS Account provisioning across the entire environment in less than 10 minutes
• Baselining our standard AMI’s went from 1 hour of manual configuration to becoming an invisible background process
• Application Stacks went from 1–2 hours to set up, to about 10 minutes per stack.