Author Archives: TIm Gerla
Author Archives: TIm Gerla
During the second installment of our webinar series about Ansible Tower features, we highlighted system tracking, a functionality which was just added to Tower with our 2.2. release.
System Tracking was created to give administrators the necessary tools to audit and verify that machines are in compliance. Use the tool to see how a machine has changed over time, or compare machines in your cluster to see how they are different.
For example, you may need to determine whether a set of machines had a security patch applied, or determine when a patch was applied. The System Tracking tools can help you do that. They can also help you evaluate your infrastructure for compliance against specific requirements, and periodically examine machines for unexpected changes.
When you run a scan, you’ll be able to see packages, services, and Ansible facts side-by-side for comparison. All differences in Ansible facts are highlighted in red for easy reference.
You can also expand this function by writing your own Ansible module that gathers the custom facts you want to see. Simply implement a module that returns the “ansible_facts” key, as described in the Ansible documentation.
Our goal with system tracking was to empower you Continue reading
Ansible is a very flexible and extensible automation tool, and it can be used in a lot of different environments that may not fit your preconceived notions of Ansible as an SSH-based tool to configure Linux and Unix systems. Here are a few other things you can do with Ansible, and a few ways to further customize and configure how your automation works. I hope these tips are useful! If you have any of your own to share, feel free to send us a tweet @ansible!
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.
A few weeks ago at AnsibleFest in NYC, we did something a little bit different: we assembled a panel of networking experts and had a very interesting discussion about some of the challenges and opportunities around networking automation. With representatives from Cisco, Cumulus, World Wide Technologies, and Network to Code, we dug into some of the reasons to automate your network, the technical and organizational challenges, and we reviewed some of the new Ansible modules being written for various networking components. Network automation is an exciting and early area for us, and we are looking forward to what the future holds.
Be honest. How many of you are still logging directly into the systems that you administer, via SSH, and changing things? I am. It’s a hard habit to break, but it’s one worth breaking. Luckily I don’t have very many servers of my own to manage, but changing things manually, instead of modeling those things in a language of automation is a sure way to build up technical debt and regret it later.
It’s been a long time since I’ve done any sort of system administration as my day job. But I talk to Ansible customers on a daily basis, and I have seen all sorts of environments: simple, complicated, small, large, well-managed, and poorly-managed. But one constant that I see throughout is increasing complexity and scale. Even for small shops with a few users, today’s platforms for data management, cloud hosting, and containers require a lot more distinct machines under management for their operation than the good old days when a couple of bare-metal LAMP servers could run a full web application.
Many people have written about the exponential growth in computing: from the early days of mainframes hosting hundreds of users and applications, to a single server rack Continue reading