Getting Started: Installing a Tower Cluster
In this Getting Started blog post, we cover how to install Ansible Tower by Red Hat as a clustered environment. If you haven’t already, check out our previous post that outlines the steps on how to install Tower on a single node.
What’s Different with Clusters?
With the addition of Clustering with Tower 3.1, Tower users now have the ability to install Tower as a clustered install rather than just doing an all-in-one install. Clustering is sharing load between hosts. Each node should be able to act as an entry point for UI and API access. This should enable Tower administrators to use load balancers in front of as many nodes as they wish and maintain good data visibility.
Installing Tower in a cluster only has two differences from a standard all-in-one Tower install:
- A separate physical or virtual machine to house an external database
- A different method of editing your inventory file
If you are preparing to install Tower, consider what function Tower will serve for you. If you are deploying Tower in a production environment, you should be using a clustered installation able to provide highly available Tower instances and use an external DB, either as a Continue reading
Q&A: Fast Application Deployment with Ansible and F5 BIG-IP
The following post contains answers to questions asked during our webinar about Fast Application Deployment with Ansible and F5 Big-IP.
Q: How can we define BIG-IP in one sentence? What is its significance in DevOps?
F5 BIG-IP is an API-enabled application delivery platform supporting a full seven layers of traffic and security services. It's not a tool that will make DevOps easier per-se, but the BIG-IP has (historically) been difficult to administer in an automated way. These Ansible modules are intended to make it less difficult so that you can drive your BIG-IP devices via code (Ansible) instead of by having to manually configure it via the Web UI.
Q: Is there documentation that details all the F5 modules being presented in the webinar?
The documentation is in two places:
- The official list of F5 modules can be found in Ansible docs.
- The upstream/community developer docs are on the F5 readthedocs page or you can find many technical resources at F5 devcentral. The latest virtual appliance that you will find are the 13.x branch of BIG-IP module.
There will be documentation on these modules once the modules are released with Ansible version 2.4. For sample Playbooks on Continue reading
Five Questions: Network Automation
Welcome to a new series where we interview Ansible experts on IT automation and ask them to share their direct experiences building automation solutions, as well as any insights they have regarding the state of the industry.
In this post, I’ve asked Peter Sprygada and Eric McLeroy five questions about network automation.
Peter Sprygada is a Senior Principal Engineer at Ansible by Red Hat where he brings over 20 years experience building and operating global network infrastructures. He holds two patents in network configuration automation and currently leads the Ansible network engineering team that focuses on building and integrating network automation capabilities into Ansible. Formerly Peter was responsible for building and leading the Arista EOS+ Extensibility Engineering team where he focused on applying DevOps methodologies to enhancing network operations. Prior to that, he held senior network engineering and operations roles at various organizations including Cisco. You can follow him on twitter at @privateip.
Eric McLeroy is a Senior Solutions Architect for Ansible by Red Hat focused on networking use cases. Eric has over 10 years in networking in large scale environments working with a large variety of systems from routers, switches, load balancers, etc. He holds multiple industry certifications and Continue reading
Getting Started: Tower Projects and Inventories
Welcome to another post in our Getting Started series. In our previous post, we discussed how you can equip your Ansible Tower instance with users and credentials.
In this post, we will discuss how to set up projects and inventories in your Ansible Tower instance.
What Is A Tower Project?
Tower projects are a logical collection of Ansible Playbooks that are set up with each other based on what they might be doing or which hosts they might interact with.
Playbooks can be managed within Tower projects by either adding them manually to the project base path on your Tower server, (/var/lib/awx/projects) or by importing them from a source control management system (SCM) that is supported by Tower. Examples of SCMs supported by Tower are Git, Subversion and Mercurial. Managing your projects with an SCM is recommended to ensure that only users with assigned access to the repository can change the Playbook before execution, and for the extra layer of accountability and change control it provides. If your Playbooks are managed by an SCM, update options can be selected to “update on launch”, “delete on update” and “clean”.
If you select “update on launch", Tower will sync each Continue reading
Ansible + Windows Webinar Q&A
The Ansible Ask an Expert webinar series continues to be one of the most popular series we’ve ever hosted. During these Q&A style webinars, our Ansible experts take questions from the audience about specific topics.
In April, we covered Ask an Expert: Windows. We’ve compiled the questions and answers below for your reference.
Interested in more? Our next Ask an Expert: Windows webinar is scheduled for August 10th at 2PM EDT. Register here.
Q: Any update on support for Windows machine as the control machine? This would make a lot of sense for Windows-only administrators who don't use Linux all the time.
A: There are several technical limitations that prevent the Ansible controller from running as a native Win32 application. However, Ansible does work under the new Windows Subsystem for Linux on Windows 10. While we don't officially support it for production workloads (nor does Microsoft), it does work quite well for developing and testing Ansible content.
Q: Is it possible to manage MySQL under Windows with Ansible?
A: Yes, the MySQL modules can manage Windows-hosted MySQL the same way as Linux-hosted MySQL. The modules themselves still need to actually run on a Linux/Mac host, but they're usually run from Continue reading
Core Engine and Windows Updates in Ansible 2.3
Although the majority of the features added to Ansible 2.3 were networking related, that’s not all folks!
There were several significant changes around module management, the Core engine, and Microsoft Windows support we’d love to show off.
For full details on the release, check out the changelog here.
Module Management
In prior releases, Ansible was organized in two separate module repositories: Ansible-modules-core and Ansible-modules-extras.
The intent was to differentiate the repositories in terms of code quality, feature enablement, and supportability of the modules. We believe we’ve developed a better process.
At the launch of 2.3, Ansible has moved to a metadata-based system for modules. Ansible modules now include an ANSIBLE_METADATA Block which specifies a support category: Core, Curated or Community.
- Core - supported and maintained by the Ansible engineering team
- Curated - supported and maintained by the Ansible engineering team and Ansible by Red Hat partners
- Community - supported and maintained by the Ansible community
In the new system, modules will be following a specific process per category.
Core modules
Modules that the Ansible engineering team directly maintain, and will ship with Ansible. These modules also receive slightly higher priority for pull requests. Any issues that are opened Continue reading
Automating F5 Big-IP Using Ansible webinar
The following blog contains answers to all questions asked during the Automating F5 BIG-IP using Ansible webinar.
Interested in exploring other Ansible webinars? Register for one of our upcoming webinars or watch an on-demand webinar.
Q: Can you pass the BIG-IP username and password by variable? Also, is there a way to mask the password in the Playbooks or manually feed the credentials as the Playbooks run? How can we ensure security here given that administrative passwords are clear text in the Playbooks themselves?
Yes, the BIG-IP username and password can be passed as a variable by referencing them from the inventory file or even provide them during runtime on the cli -- although this would show them in the process list if you did a 'ps'. You can also specify them in a vars_prompt; this would prevent them from being shown in 'ps'. The downside here is that this would limit the amount of automation you can provide because running the Playbook would require that either be typed in or specified with '-e' ('-e' auto fills vars_prompts that match). The recommended way is to get the vars from a secure location. Ansible provides Vault, Continue reading
Top Reasons To Attend AnsibleFest London 2017
I remember the first AnsibleFest I attended – it was San Francisco 2014. I had been with Ansible for a week and had flown out to meet some of my new colleagues.
As a user of Ansible for the past year, I'd discovered how cheery and helpful the community was. "Newbies" dropping by the IRC channel on Freenode were always helped out, no matter how simple the question. The community spirit is something many people comment on when first using Ansible.
I remember meeting core engineer Brian Coca for the first time at that AnsibleFest too, also a recent joiner to the company. Brian was asked that morning if he'd give a talk, a request he calmly accepted as if he'd been asked to make a cup of tea. Top tip – never miss a talk given by Brian, you will learn something new!
Later, during the happy hour, I talked with lots of attendees, many just wanting to tell us how much they'd enjoyed the day. It was great to see the open source community feel extending to our full day conferences.
Two and half years later and I still see that community spirit day in, day out. Only now it's Continue reading
Don’t Miss our Self-Healing Networks Session at the Red Hat Summit
One of my favorite technology catch phrases is “all technology fails”, but when thinking about the network that thought becomes a very scary one. Yes, while all technology does fail, you will always do your best to not have the network be one of those. The concept of healing networks from a conceptual standpoint (the will to want to detect an issue and fix it as soon as possible) is not a new one, as network monitoring is always at the front of any network engineer's mind. We are just fortunate in this day and age to be able to take advantage of newer tools that provide better solutions. Ansible to the rescue!
If you are attending the Red Hat Summit, please make sure not to miss the Discovery Zone session entitled “Self-Healing Networks with Ansible” on Thursday, May 4th at 10:15AM.
In this presentation we will cover topics, such as:
- Why Capturing Metrics from Your Network is Important
- Defining Failure States
- Auto-Remediation versus Remediation (if remediation is the optimal course of action)
- How Are The “Small" Guys Doing It?
- Best Use Cases for Ansible Core and Ansible Tower
- How Can Consulting Services help?
At the end of this session, Continue reading
Getting Started: Tower Users and Credentials
In our previous Getting Started blog post, we discussed how to install Ansible Tower in your environment.
Now we’ll discuss how you can equip your Tower host with users and credentials.
To begin, let’s cover the essentials: setting up your user base and creating credentials for appropriate delegation of tasks.
How To Set Up A User Base
Building your user base will be the first thing you’ll need to do to get started with Tower. The user base can be broken into three easily-defined parts:
1. User: Someone who has access to Tower with associated permissions and credentials.
2. Organization: The top level of the user base - a logical collection of users, teams, projects and inventories.
3. Team: A subdivision of an organization - provides the means to set up and implement role-based access schemes as well as to delegate work across organizations.
Understanding User Types
There are three types of users that can be defined within Tower:
- Normal User: A user that is given no special permissions from the beginning - they must be granted to them by a system administrator.
- System Auditor: A user who will have view access only within Tower.
- System Administrator: A user who has the Continue reading
Announcing Ansible Container 0.9
The Ansible Container team is proud to announce the 0.9 release of the Ansible Container project. Key new features of the 0.9 release include:
Tighter integration with Ansible roles
Ansible roles are a great way to describe microservices; roles that are "common" between multiple services map well to container image layers and service-specific roles are easy for teams to maintain. We decided to make that concept clearer in the way Ansible Container works. We ditched the main.yml playbook and replaced it with a per-service list of roles in container.yml.
Tighter integration with Kubernetes in OpenShift Origin and Red Hat OpenShift Container Platform
We've built brand new Kubernetes and OpenShift modules for Ansible, and are already using them in Ansible Container. We've also restructured the container.yml syntax to more naturally support Kubernetes and OpenShift concepts out of the box, then fall back to the comparatively simpler Docker ecosystem. Instead of trying to bolt Kubernetes features into the Docker Compose style schema, we have dedicated OpenShift/Kubernetes configuration for resources like Persistent Volume Claims. This will allow end users to transfer existing Ansible roles into Kubernetes/OpenShift and have Ansible Container manage the deployment lifecycle.
Putting more tools into the Continue reading
Ansible + Networking Webinar Q&A
The Ansible Ask an Expert webinar series continues to be one of the most popular series we’ve ever hosted. During these Q&A style webinars, our Ansible experts take questions from the audience about specific topics.
In March, we covered Ansible + Networking. We’ve compiled the questions and answers below for your reference.
Interested in more? Our next Ask an Expert: Networking webinar is scheduled for July 19 at 11AM EDT. Register here.
Q: Persistent connection optimization really applies to devices that do not use a REST API with support for long-lived access tokens (as opposed to cookies)?
A: That's correct. The persistent connection framework is designed to work with SSH based connections, which include CLI and NETCONF connection methods.
Q: Do you know if it's in the roadmap to ship Ansible Tower with jobs out-of-the-box for the most common tasks performed with Red Hat products? For example, deploy a jboss EAP, install OS packages, and stuff like that?
A: Assuming you are talking about "canned" Playbooks here. In most cases, each of the individual products would curate and maintain Playbooks for use and are distributed by the individual products (since there are support implications). The Ansible distribution does not include Continue reading
What’s New in Ansible Tower 3.1
Ansible Tower 3.1 adds a variety of new features that make it easier than ever to share and scale IT automation. Tower now includes multi-Playbook workflows to streamline jobs, clustering to easily scale-out Tower instances, enhanced search and more.
For this post, we asked members of the Tower engineering team to highlight what’s new with the latest release and share what they're most excited about.
Engineered for the enterprise
Tim Cramer, Senior Director of Engineering, shares a quick overview of the Tower 3.1 enhancements designed to help teams harness the power of Ansible automation across servers, applications, environments and networks:
Scale-out clustering
Matt Jones, Principal Software Engineer, explains how scale-out clustering enables you to support a larger number of Tower jobs:
Multi-Playbook workflows
Chris Meyers, Senior Software Engineer, describes how Tower's new multi-Playbook workflows promote greater re-use of existing job templates and allow you to build a CI/CD testing workflow:
And more...
“One of the things we are most excited about in Ansible Tower 3.1 is localization. This is the first release of Tower that has been localized. Tower is now available in Japanese and French. We went through a lot of thought as to where we wanted Continue reading
Network Device Authentication with Ansible 2.3
In a recent post, Coming Soon: Networking Features in Ansible 2.3, one of the key features to be introduced is a new connection framework. This new connection framework supports persistent SSH connections for modules that communicate with network devices via two methods:
1) the tried and true CLI method
2) the newly included NETCONF method
With the new connection framework, the network modules are currently undergoing a transformation with regards to how credentials are supplied. In Ansible versions 2.0 to 2.2, network modules support providing connection credentials as top-level arguments in the module.
If you want to build a task using the ios_command Ansible module the credentials used to authenticate to the device could be provided as top level arguments. The following example demonstrates the simplest form of passing credentials to modules in order to authenticate to the remote device:
ios_command:
commands: show version
host: “{{ inventory_hostname }}”
username: cisco
password: cisco
In some cases, such as with configuration modules, additional authentication details are required. In order to enter configuration mode, the Playbook tasks must first enter “enable” mode and, in some cases, supply an enable-mode password. Notice the additional two arguments (authorize and auth_pass) added to Continue reading
Getting Started: Tower Installer
Welcome to the first in our series of blog posts for Getting Started with Ansible Tower. This series covers basic installation and functions of Tower and an overview of how to use Tower to implement IT automation.
To get started with Tower, you must first learn to install and stand up a single host. Future posts will cover other types of configurations, such as a redundant installation with an external database. For this post, we’ll be highlighting RHEL 7 and Ubuntu LTS.
Install Tower in 4 Simple Steps:
Run these steps as root (su -).1. Download the latest Tower edition
If you haven’t already, visit this link to the trial page to have a download link sent to you. If you would like, our AMIs for AWS and our vagrant image are found there as well. If you have network restrictions, contact Ansible Sales and they can send you the bundled installer.
Note: We are currently working on a bundled installer for Ubuntu LTS, so the standard installer will install for Ubuntu.
2. Unpack the file (tar xzvf towerlatest)
$ tar xzvf towerlatest ansible-tower-setup-3.1.0/ ansible-tower-setup-3.1.0/group_vars/ ansible-tower-setup-3.1.0/group_vars/all ...
-tar xzvf towerbundlelatest
$ tar xzvf Continue reading
Introducing Ansible Tower 3.1
We're excited to announce the release of Ansible Tower 3.1. Our engineering team has been hard at work on enhancing Ansible Tower to allow teams to harness the power of automation across servers, applications, environments, and networks, and with Ansible Tower 3.1, we've brought together a variety of enhancements that allow your teams to automate more processes, more frequently, and more easily analyze the results of your automation across the enterprise
Model complex processes with multi-Playbook workflows
Ansible brought simple, agentless automation to IT. But some IT processes don't lend themselves to being automated in a single Playbook - if you're provisioning environments, you may want to handle basic provisioning, default configuration, and application deployment differently. And once you've automated those tasks, you want to reuse those tasks in different ways, or in different environments. Plus, what if a deployment goes wrong? You may need to back your environment out to the last known good state.
To solve these issues, we developed Tower workflows. With Tower workflows, you can chain together any number of Playbooks together into a workflow, with each workflow step potentially using a different Playbook, inventory, set of credentials, and more. Easily launch one or more Continue reading
Introducing Ansible Tower 3.1
We're excited to announce the release of Ansible Tower 3.1. Our engineering team has been hard at work on enhancing Ansible Tower to allow teams to harness the power of automation across servers, applications, environments, and networks, and with Ansible Tower 3.1, we've brought together a variety of enhancements that allow your teams to automate more processes, more frequently, and more easily analyze the results of your automation across the enterprise
Model complex processes with multi-Playbook workflows
Ansible brought simple, agentless automation to IT. But some IT processes don't lend themselves to being automated in a single Playbook - if you're provisioning environments, you may want to handle basic provisioning, default configuration, and application deployment differently. And once you've automated those tasks, you want to reuse those tasks in different ways, or in different environments. Plus, what if a deployment goes wrong? You may need to back your environment out to the last known good state.
To solve these issues, we developed Tower workflows. With Tower workflows, you can chain together any number of Playbooks together into a workflow, with each workflow step potentially using a different Playbook, inventory, set of credentials, and more. Easily launch one or more Continue reading
Networking Features Coming Soon in Ansible 2.3
It’s been a year since the first networking modules were developed and included in Ansible 2.0. Since then, there have been two additional Ansible releases and more than 175 modules added, with 24 networking vendor platforms enabled. With the fantastic efforts from the community and our networking partners, Ansible has been able to add more and more features for networking use cases. In the forthcoming Ansible 2.3 release, the focus on networking enablement now turns to increasing performance and adding connection methods that provide compatibility and flexibility.
Looking ahead to Ansible 2.3, the most notable additions planned are:
- Persistent connections framework
- The network_cli connection plugin
- The netconf connection plugin
Why are these features important?
Since Ansible 2.0, the primary focus for networking enablement has been to help increase the number of third-party devices that have modules included by default. As this list grows (we expect to have even more platforms and modules in Ansible 2.3), Ansible and Ansible Tower continue to be trusted components of critical networking production deployments.
The development of these plugins further demonstrates the value and investment Ansible and the community have made into networking infrastructure enablement. As we approach the Ansible Continue reading
Ansible Is 5 Years Old Today!
Five years ago today, Michael DeHaan created this commit:
commit f31421576b00f0b167cdbe61217c31c21a41ac02
Author: Michael DeHaan
Date: Thu Feb 23 14:17:24 2012 -0500
Genesis.
When you create something you intend to release as open-source software, you never know if it will be something others are actually interested in using (much less contributing to).
Michael invited me to join Ansible when it was just over a year old as a project, and I have seen it grow from an already wildly popular project into something used by people around the world. The thing that makes Ansible the strongest though, by far, is its community of users and contributors. So join us in wishing Happy Birthday by sharing how you innovate with Ansible!
Tweet #AnsibleBirthday
Ansible Community – 2016 Year in Review
It's time again for the annual Ansible community review. Time flies. Our upward trajectory generally continued from 2014 and 2015 through 2016, and our growth continued to bring new challenges and new opportunities.
Let's start again, as we do every year, with a look at the numbers.
Debian Popcon
Debian’s Popularity Contest is an opt-in way for Debian users to share information about the software they’re running on their systems.
Caveats abound with this graph -- but even though it represents only a small sample of the Linux distro world, it’s useful because it’s one of the few places where we can really see an apples-to-apples comparison of install bases of the various tools. Because Ansible is agentless, we compare the Ansible package to the server packages of other configuration management tools. (Chef does not make a Debian package available for Chef server.)
We see that Ansible has continued its steady growth through the end of 2016, nearly doubling its Popcon install base again in 2016.
Github Stars
Ansible continued in 2016 to extend its already significant lead in GitHub Stars over other tools in the configuration management space, passing the 20k mark in December 2016.
