Author Archives: Bill Nottingham
Author Archives: Bill Nottingham
We’re excited to announce the release of Ansible Tower 3.7, part of the Red Hat Ansible Automation Platform. Ansible Tower is the scalable execution framework of the Ansible Automation Platform, providing a REST API and UI framework that allows users to scale automation across their enterprise and integrate it into their processes and tools.
The focus of the Ansible Tower 3.7 release is on scalability of automation and improving the experience of our users.
These days automation often needs to work at large scales - both in terms of infrastructure, but also in terms of how many jobs are executed in parallel. With Ansible Tower 3.7 we have put in extra effort to handle job dependencies in a way that helps ensure your jobs aren’t blocked. By allowing project updates and inventory updates to happen while other jobs are running, we’ve eliminated many of the bottlenecks in job processing. This enables jobs to proceed faster and without the need to wait for each other.
Scale is not only about the IT technology itself, but also about users. As our customers Continue reading
As part of the release of Red Hat Ansible Automation Platform, we’re happy to announce the release of Red Hat Ansible Tower 3.6. Ansible Tower is the scalable execution framework of the Ansible Automation Platform, providing an API around automation that you can use to scale automation across your enterprise and integrate automation into your tools and processes.
Not all automation processes can proceed entirely without human input. In Ansible Tower 3.6, we’ve added pause and approval to Ansible Tower workflows to help enable more flexible automation. At any step in a workflow you can pause and wait for an approval from an administrator, or any other you delegate approval permissions to. Need to verify that your deployment was fully successful before updating the external DNS entries? Need to ensure that your developers won’t spin up 300 extra cloud servers when provisioning new dev environments? Now you can do that, integrated directly in Ansible Tower workflows.
Notifications were introduced in Ansible Tower 3.0, allowing the status of any job to be reported out via email, Slack, IRC, and more. In Ansible Tower 3.6, we’ve made the content Continue reading
As we continue to improve Red Hat Ansible Tower, we’ve focused on allowing you to automate in more flexible ways, no matter your deployment scenario. As part of this, we’ve introduced two new features: Instance Groups and Isolated Nodes. These new features allow you to use Ansible Tower automation more flexibly in ways that match both the structure of your organization and your infrastructure.
What is an instance group?
Ansible introduced Clusters in Ansible Tower 3.1. Tower Clusters allow you to add capacity to your Ansible Tower environment - the more nodes in your Tower Cluster, the more job execution capacity you have. If you have to run many jobs simultaneously, adding more nodes to the cluster lets you run them all without queueing.
However, this just gives you an additional mass of capacity. If you just have one group using a Tower instance, that may be enough. But we know that many Ansible Tower instances are shared among teams, groups, and organizations that may have different uses for their automation.
That’s why, in Ansible Tower 3.2, we created Instance Groups.
An Ansible Tower Instance group is a set of cluster nodes dedicated for a particular purpose. Continue reading
One of the new features we added in Red Hat Ansible Tower 3.2 was support for custom credentials. The idea of custom credentials is pretty simple. In addition to the built-in credentials supported by Ansible Tower such as SSH keys, username/password combos, or cloud provider credentials, we now let the user define their own credentials for storing securely in Ansible Tower and exposing to playbooks.
However, this simplicity belies real power, opening up many new ways to automate. Let's dive into the details.
To set up a custom credential, first you must define the custom credential Type.
Credential types consist of two key concepts - "inputs" and "injectors".
Inputs define the value types that are used for this credential - such as a username, a password, a token, or any other identifier that's part of the credential.
Injectors describe how these credentials are exposed for Ansible to use - this can be Ansible extra variables, environment variables, or templated file content.
Once you've defined a new Credential Type, you can then create any number of credentials that use that type. We'll go through examples to shed light on how this Continue reading
We're happy to announce that Red Hat Ansible Tower 3.2 is now generally available.
With Red Hat® Ansible® Tower 3.2, we're working to make sure you can automate more flexibly, and manage more globally across your enterprise. For more information:
Go get it now via local install, Vagrant, or Amazon AMI. Ansible Tower 3.2 is available for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 14.04, and Ubuntu 16.04. If you have any questions, or run into any issues, don't hesitate to contact us via the Red Hat Customer Portal.
We are excited to announce the release of Red Hat Ansible Tower 3.2 for availability soon. Our engineering team has been working hard to enable Ansible Tower to provide the best platform for managing, executing, and delegating your Ansible automation throughout your entire enterprise, whether you’re managing servers, applications, networks, and more.
With Ansible Tower 3.2, we’re continuing to innovate in two main areas:
To do that, we’ve enhanced several areas of Ansible Tower, and I’m happy to talk about them today.
With Ansible Tower 3.1, we built the first step of our integration with Red Hat Insights - allowing you to sync Insights remediation playbooks to Ansible Tower for use as needed. We’ve continued to enhance this integration in Ansible Tower 3.2. Now, we bring the ability to view Insights Actions directly in Ansible Tower. With this, you can more easily see your minor, major, and critical issues, and with just a few clicks, schedule remediation with Insights Plans.
Ansible facts give you powerful capabilities to adjust, branch, and conditionalize playbook execution Continue reading
For #AskAnsible posts, we interview Ansible experts on IT automation topics and ask them to share their direct experiences building automation solutions.
In this post, I’ve asked Matt Davis five questions about Ansible for Windows automation.
Matt Davis is a Senior Principal Software Engineer for Ansible, focused on Ansible's Windows support. He has over 20 years experience in software engineering, architecture and operations at companies large and small. An avid musician, maker and home hacker, Matt lives with his wife and daughter in Beaverton, Oregon. You can follow him on Twitter at @mattdavispdx.
1. How is Ansible for Windows different than System Center Configuration Manager (SCCM) or Powershell Desired State Configuration (DSC)?
Matt: SCCM is generally considered a legacy workstation-flavored management technology, dating from the mid 1990s (though many places use it for server management, too). It requires agents on the managed hosts, which must be installed, configured and kept up-to-date. SCCM executes many operations locally and asynchronously from the server, so it's often difficult to orchestrate interdependent changes across hosts, and to reason about the overall system state at any point in time as part of larger deployments.
DSC is a much more modern management technology, supporting both an Continue reading
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
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
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
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
When we talk about Ansible Tower, we talk about control, knowledge and delegation. But what does that mean?
In previous posts in this series, we've talked about the concept of 'control' for your automation and your inventory, and about the basics of security and delegation. Today we're going to show how Tower's security and delegation allows for simple self-service deployments for your users.
This is part of a series of posts about how Ansible and Ansible Tower enable you to manage your infrastructure simply, securely, and efficiently.
When we talk about Tower, we often talk in terms of control, knowledge, and delegation. But what does that mean? In previous posts in this series, we've talked about the concept of 'control', as it relates to both managing your infrastructure and managing your automation. Today we're going to explain delegation, and the security aspects that go into that.
We recently ran the 2016 version of our Ansible Community Survey. This is a survey of Ansible users and community members, regarding how they're using Ansible in their environments. We thought it would be useful to share some of the aggregate results. (As we did not ask for permission to distribute individual responses, we cannot make the raw data public.)
We had over 1,600 survey respondents, up from 1,300 when we last ran the survey in March of 2015.
How long have you been using Ansible? |
||
Answer Options |
Response Percent |
|
A month or less |
7.8% |
|
1-2 months |
7.3% |
|
2-6 months |
18.8% |
|
6-12 months |
18.6% |
|
over a year |
47.4% |
|
number of respondents |
1,625 |
Ansible continues to grow more veteran users - when surveyed in 2015, only 30% of respondents had used Ansible for more than a year.
What version(s) of Ansible are you currently running? |
||
Answer Options |
Response Percent |
|
pre-1.9.x |
5.0% |
|
1.9.x |
27.8% |
|
2.0.x |
41.6% |
|
2.1.x |
51.4% |
|
2.2/development |
6.7% |
|
number of respondents |
1,623 |
Note that respondents could pick multiple versions. All told, 80% of respondents have at least some usage of Ansible 2. Continue reading
We’ve been hard at work since the last release of Tower, listening to community feedback and working to create the best possible experience for Tower users. We are pleased to introduce Ansible Tower 3, evolving from Ansible’s simple, powerful and agentless automation and extending that power to your team and organization.
Tower 3 boasts an entirely reworked UI that makes it simpler and easier to use Tower to automate your environments and share your automation. On top of that, we’ve equipped this newest edition of Tower with a host of new features to speed productivity and visibility within your Tower workflows, managing complex deployments and scaling the power of automation.
These features include:
Expanded and Simplified Permissions
In prior releases of Tower, we operated on an implicit permissions system. For a user to be able to see, and run, a job, they needed permissions on not only the project that housed the Playbook, but also the inventory, and the credential used.
Now, with Tower 3, we’ve made things much simpler… if you have a job that you want a user or team to run, just give them Continue reading
AnsibleFest is returning to San Francisco on Thursday, July 28th, 2016 at the Westin St. Francis in Union Square. It's going to be a great opportunity to meet and connect with passionate Ansible users, developers and industry partners. Whether you're an experienced user or are just getting started, AnsibleFest is for you.
This year AnsibleFest will not be one to miss, featuring the latest and greatest updates on Ansible and Ansible Tower as well as use cases, technical deep dives and best practices.
As AnsibleFest continues to grow so does its offerings. For those who have never attended and for those wanting to know more, here are three things you won't want to miss:
1) Informative General Session
Kicking off AnsibleFest, this session will feature company updates, product roadmap and new directions as well as a featured customer presentation. Attendees can:
AnsibleFest is heading back to San Francisco on Thursday, July 28. You can expect all the usual highlights, like product roadmaps and Ask an Expert sessions. Plus, this year we're planning distinct tracks to give you exactly the type of information you need for wherever you are in your Ansible journey. Track themes will include use cases, best practices, and technical deep-dives into trending topics.
Do you have a story to share about how you're using Ansible?
Submit your abstract during our Call for Speakers - open until June 1. We'll select speakers and notify all participants by June 13.
To see examples of talks that have been accepted in the past, check out the recordings from our last two AnsibleFest events in London and San Francisco.
Then buy your tickets now during Super Early Bird pricing. This exclusive $299 pricing ends on May 31 and you won't find a better deal. If you're selected as a speaker, we'll refund your ticket amount.
See you in San Francisco!
WANT A TASTE OF ANSIBLEFEST? Watch presentations from AnsibleFest London 2016. |
This is the second in a series of posts about how Ansible and Ansible Tower enable you to manage your infrastructure simply, securely, and efficiently.
When we talk about Tower, we often talk in terms of Control, Knowledge, and Delegation. But what does that mean? In this series of blog posts, we'll describe some of the ways you can use Ansible and Ansible Tower to manage your infrastructure.
In our first blog post, we described how Ansible Tower makes it easy to control the way your infrastructure is configured via configuration definition and continuous remediation.
But controlling the configuration of your infrastructure is just one step. You also need control of the components of your infrastructure - your inventory. You need to do day-to-day management tasks on demand. And Ansible Tower makes those easy as well.
If you’ve used Ansible, you know about the basics of inventory. A static Ansible inventory is just an INI-style file that describes your hosts and groups, and optionally some variables that apply to your hosts and groups. Here's an example from the Ansible documentation.
{% raw %}[atlanta] host1 host2 [raleigh] host2 host3 [southeast:children] atlanta raleigh [southeast:vars] nameserver=dns.southeast.example. Continue reading
If you've been following recent security news, you may have heard of the Badlock vulnerability in the protocols used by the Microsoft Windows Active Directory infrastructure. This vulnerability could lead to a man-in-the-middle attacker intercepting traffic between a client and the Active Directory server, and then impersonating the client, gaining unauthorized access to resources.
|
More information can be found at http://badlock.org/ and the Red Hat Knowledgebase. |
Thanks to Ansible, however, patching your systems doesn't have to be complicated.
- hosts: all gather_facts: true become_method: sudo become_user: root vars: service_name: 'Debian': 'smbd' 'RedHat': 'smb' tasks: - name: check samba version shell: dpkg -l | grep -q samba when: ansible_os_family == 'Debian' register: samba_installed ignore_errors: True - name: update samba from apt if installed apt: name: samba state: latest update_cache: yes when: ansible_os_family == 'Debian' and samba_installed.rc == 0 notify: restart_samba - name: check samba version shell: rpm -q samba when: ansible_os_family == 'RedHat' register: samba_installed ignore_errors: True - name: update samba from yum if installed yum: name: samba state: latest update_cache: yes when: ansible_os_family == 'RedHat' and samba_installed.rc == 0 notify: restart_samba handlers: - name: restart_samba service: name: "{{ Continue reading
This is the first in a series of posts about how Ansible and Ansible Tower enable you to manage your infrastructure simply, securely, and efficiently.
When we talk about Tower, we often talk in terms of Control, Knowledge, and Delegation. But what does that mean? In this series of blog posts, we'll describe some of the ways you can use Ansible and Ansible Tower to manage your infrastructure.
The first step of controlling your infrastructure is to define what it is actually supposed to be. For example, you may want to apply available updates - here's a basic playbook that does that.
--- - hosts: all gather_facts: true become_method: sudo become_user: root tasks: - name: Apply any available updates yum: name: "*" state: latest update_cache: yes
Or you may have more detailed configuration. Here's an example playbook for basic system configuration.This playbook:
Configures some users
Installs and configures chrony, sudo, and rsyslog remote logging
Sets some SELinux parameters
Normally, we’d organize our configuration into Ansible roles for reusability, but for the purpose of this exercise we're just going to use one long playbook.
We'd want to apply this as part of our standard system configuration.
Continue reading
If you’re maintaining services on the internet, you know about the importance of keeping up to date with security patches as they come available. Today is no exception with the release of CVE-2016-0800, describing the ‘DROWN’ vulnerability in OpenSSL.
The key points of DROWN are that it can allow for passive decryption of encrypted traffic, via vulnerabilities in the obsolete SSLv2 protocol. Merely using SSLv2 for one service could cause the compromise the traffic of other services, even if they aren’t using SSLv2. More information can be found at http://www.drownattack.com/.
The Red Hat specific announcement can be found in the Red Hat Knowledgebase.
Obviously, this is a big deal, but patching your systems for DROWN doesn’t have to be a big deal, thanks to Ansible.
Here’s a sample playbook for Red Hat/Fedora/CentOS and Debian/Ubuntu systems (link to source):
- hosts: all gather_facts: true sudo: true tasks: - name: update openssl from apt if available apt: name=openssl state=latest update_cache=yes when: ansible_os_family == 'Debian' notify: restart_system - name: update openssl from yum if available yum: name=openssl state=latest update_cache=yes when: ansible_os_family == 'RedHat' notify: restart_system Continue reading
We’re happy to announce the release of Ansible Tower 2.4. In this release, we’ve focused on some core improvements for our customers operating in spaces like government and security who have specific needs around authentication and tracking, but we expect these features will be useful to much of our general user base as well.
No one wants to manage their users in multiple places, and many groups today use external providers for handling their identity and authentication. We’ve added support for pulling users and teams from either GitHub or Google Apps, using OAuth2. With this, you don’t need to add users directly to Tower - they can use the accounts they already have and are using in your organization.
Previously, for Enterprise users who have a standard corporate infrastructure Tower has included support for connecting to an LDAP or Active Directory server for user and team information. But not everyone exposes their LDAP for use with all internal services. With Tower 2.4, we’ve extended that enterprise authentication support to also include support for authenticating to a SAML 2.0 identity provider, and to authenticate against a RADIUS server. With this, Continue reading