What is Ansible?
Ansible is a simple way to automate apps and infrastructure. It includes Application Deployment, Configuration Management and Continuous Delivery. It runs on many Unix-like systems, and can configure both Unix systems as well as Microsoft Windows.
1537 companies reportedly use Ansible in their tech stacks, including LaunchDarkly, Tokopedia, and ViaVarejo.
Top Industries that use Ansible
Looking at Ansible customers by industry, we find that Computer Software (36%) and Information Technology and Services (9%) are the largest segments.
NetApp, a data management technology company, sought to improve the speed and efficiency of its IT service delivery. The company automated manual, repetitive management processes and streamlined storage provisioning using Red Hat Ansible Automation and Red Hat OpenShift Container Platform. As a result, NetApp has dramatically reduced delays and human errors — eliminating hundreds of hours of manual work — and accelerated application delivery times from weeks to minutes.
As an active open source participant and a long-time user of Red Hat software, NetApp decided to pilot Red Hat Ansible Engine, part of Red Hat Ansible Automation, in its NTP update project to eliminate repetitive manual tasks in configuration management. Ansible Engine is an agentless automation platform based on a powerful yet human-readable language that communicates with existing systems, applications, and tools. NetApp’s corporate IT team has used Ansible Engine to automate dozens of previously manual processes and continue to streamline its processes. “Red Hat Ansible Automation was well-suited to templating the configuration files we needed for our NTP update to speed and automate the project. Once we saw what it could do, we started to see automation opportunities everywhere,” said Fox. To address its dynamic storage provisioning challenge, NetApp combined Trident, an open source project it hosts and leads, with Red Hat OpenShift Container Platform, a solution for advanced application creation and delivery automation across private, public, and hybrid infrastructures. Trident lets applications that are provisioned and managed using the Kubernetes container orchestration engine — included in OpenShift — use storage resources on demand.
i. ACCELERATED INFRASTRUCTURE MAINTENANCE
ii. REDUCED DELIVERY TIME FROM WEEKS TO MINUTES
About BinckBank: BinckBank is an online bank for investors based in Amsterdam and is ranked among the top five investment banks in Europe and the market leader in the Netherlands and Belgium. BinckBank has more than 760,000 accounts with offices in the Netherlands, Belgium, France and Italy and 590 employees.
Ansible is quite fun to use right away. As soon as you write five lines of code it works. With SSH and Ansible I can send commands to 500 servers without having even used the servers before.” — Mark Maas, Unix/Linux Systems Administrator Binck Bank
How is BinckBank using Ansible?
We have 600 UNIX servers in house. We have a lot of specialty environments that we need to create while at the same time managing our production environment. Ansible is quite fun to use right away — as soon as you write five lines of code it works. SSH makes it all so easy because it is text-based, making it really powerful when combined with Ansible. With SSH and Ansible I can send commands to 500 servers without having even used the servers before. We are experimenting with monitoring networks. We use NAGIOS. NAGIOS is an example of a technology doing something extremely well — monitoring networks — while leaving the fixing to Ansible. NAGIOS can see a server is busy in the middle of the night, send a message to Cobbler to create a few more servers on a virtual platform and then start Ansible to make servers into web servers, enhancing the capability of your website with more servers. You can literally wake up to more sales this way. Ansible is the glue that connects monitoring, scripting and server installation. Ansible glues it all together and now you have a self-healing network. You can link to NAGIOS so Ansible can check way more than what you can script. The whole fun of Unix is that the output of one command is the input for another.
What are your results with Ansible?
From an IT standpoint I can show other people that if we install a production and testing environment with Ansible it will be done right. Unless you do the work by hand there is always the question — did you install correctly? With Ansible you can be assured without a shadow of a doubt that an installation is correct. Ansible makes it easier to trust my own work and my servers’ work. Ansible gives me peace of mind on a much bigger scale.
6 Things You (Maybe) Don’t Know About Ansible.
1. Ansible can be used to manage more than just servers
Most Ansible playbooks are used to configure and manage servers. Web servers, database servers, and so on. But anything with an SSH interface or an API can be managed with Ansible, too. For example we have modules to talk to cloud platforms, Citrix NetScaler and F5 load balancers, and other networking equipment. These modules are really helpful for tasks like multi-server rolling upgrades or other complicated orchestration tasks that need coordination with your broader networking environment.
You can also implement custom connection plugins for those really weird or legacy devices. There are a number of lesser-known ones shipped with Ansible, including methods to “connect to” a chroot environment and LXC containers. (Kermit connection plugin, anyone?)
2. You can mix on-premise and cloud inventories easily
You’re probably familiar with Ansible inventory files. They are simple text files describing your inventory of hosts. They usually look like this:
Ansible also has a series of cloud inventory sources to dynamically retrieve the latest list of servers from Amazon, Azure, Rackspace, and more. But what if you have a mixed environment? You can create a directory, say, called inventory/ and put both static inventory files (like above) and cloud inventory scripts together, and run your playbooks against the mixed inventory, by specifying the directory name as your inventory file.
Ansible Tower also has built-in mechanisms to handle mixing cloud and static inventory.
3. You can write playbooks in JSON (if you really want to!)
We chose YAML as the text file format for Ansible playbooks because it’s easily readable and writable by both humans and machines: it’s a nice middle ground that remains 100% machine parsable but not too verbose and structured for general consumption like, say, XML. But, because JSON is a subset of YAML, you can write playbooks in JSON format as well! Here’s a simple playbook in YAML:
And here’s the equivalent playbook in JSON:
Personally, I think YAML is easier to work with than JSON, but this feature may have some interesting possibilities if you are dynamically generating playbooks or playbook content for some reason. Your mileage may vary!
4. Ansible can be used to manage Windows machines
One of the extra connection plugins that we’ve built allows you to run PowerShell scripts on Windows, using the WinRM protocol. We wanted to add Windows support to Ansible but we didn’t want to require Windows admins to do unnatural things like install Python and SSH on the managed machines. We have a small but growing library of Windows modules, too.
5. Ansible has a rich plugin infrastructure
There are a lot of ways to extend Ansible. The most common way is to write a custom module, but there are also a series of interesting Python plugin interfaces that you can use to build custom behavior beyond just modules:
- Dynamic Inventory Sources: If you have a custom CMDB or another source of truth about your environment, you can easily write a custom inventory plugin to pull hosts and groups directly from your existing database.
- Callback Plugins: Callback plugins are very powerful, and can be used to trigger notifications such as posting messages to chat tools, signal monitoring events, or react in flexible ways to basically any event during a playbook run.
- If you find yourself dealing with complicated data structures in your playbooks, you may want to look into custom filter plugins or lookup plugins. Both allow you to manipulate data in various ways (limited only by Python!) and can greatly simplify your playbook by offloading logic to a small Python plugin. A lot of the common Jinja2 filters and iterators you probably use every day are implemented as plugins.
- All of these plugins will work with Tower, as well!
6. You have a lot of control over how a playbook runs
Playbooks always run from the top to the bottom in Ansible, which is fine once your playbook is fully tested and running in production. But what about during development? It is sometimes convenient to skip certain sections of a playbook, or step through your tasks one by one to examine the results on a live system. You can do this with a couple of ansible-playbook command-line options.