0

The Future of Ansible Content Delivery

Everyday, I’m in awe of what Ansible has grown to be. The incredible growth of the community and viral adoption of the technology has resulted in a content management challenge for the project.

I don’t want to echo a lot of what’s been said by our dear friend Jan-Piet Mens or our incredible Community team, but give me a moment to take a shot at it.

Our main challenge is rooted in the ability to scale. The volume of pull requests and issues we see day to day severely outweigh the ability of the Ansible community to keep up with that rate of change.

As a result, we are embarking on a journey. This journey is one that we know that the community, both our content creators and content consumers, will be interested in hearing about.

This New World Order (tongue in cheek), as we’ve been calling it, is a model that will allow for us to empower the community of contributors of Ansible content (read: modules, plugins, and roles) to provide their content at their own pace.

To do this, we have made some changes to how Ansible leverages content that is not “shipped” with it. In short, Continue reading

0

Ansible 2.6: Your Time Has Come!

Guess what!? Another release has come upon us! Your time has come to upgrade to Ansible 2.6-”Heartbreaker.” Utilize some great updates to automate to your heart’s desire, and avoid being heartbroken. See what I did there? 

Let’s dive right into some of the changes.

Deprecation

One little bit of house cleaning before getting into the rest of the fun. The deprecated task option always_run has been removed, please use check_mode: no instead.

For any more information on behavioural changes from Ansible 2.5 to Ansible 2.6, please check out the Porting Guide.

Memory Utilization Improvements

In the development cycle of 2.6, we started to tackle a memory utilization problem that some of our users experienced in Dynamic Includes. In some cases, we have seen “roughly a drop of 50% memory consumption,” and in one scenario we had seen execution times of 21 seconds down to 8 seconds after the change was applied. Cool little bit, a bunch of these fixes were also back-ported to Ansible 2.5 as well as Ansible 2.4! In a future blog post, we plan to go into more detail of what was done to improve upon Dynamic Includes. Also, Continue reading

0

Ansible 2.5: Traveling space and time

Welcome to another Ansible release! Version 2.5–“Kashmir”–has a lot of great stuff to play around with, and we're excited to get it in your hands so you can try it out.

Some of the items in this release have been covered in depth in previous Feature Spotlights: AWS EC2 Dynamic inventory plugin, the new Loop keyword, and the all-new ec2_instance module. But those are just appetizers for all of the new things that are included in this release.

Fact Namespacing

In 2.5, we are introducing fact namespacing, which makes Ansible facts available under the ansible_facts namespace (i.e. ansible_facts.os_distribution) without the ansible_ prefix.

Facts will continue to be added into the main namespace directly, but there is now a configuration boolean to enable this. Today, it’s ”On” by default, in a future release, we’ll switch that to “Off”.

Module Blacklisting

We have added a configuration file that enables administrators to filter modules that should be excluded from being used in playbook runs. Operationally, this ensures administrators have more control over which Ansible Modules are approved for use.

New magic vars

Magic vars are variables that Ansible provides to playbook runs without having to be requested. Continue reading

0

Loop: Plays in the future, items in the past

Welcome to another episode of Feature Spotlight. In today's post, we'll quickly cover the loop keyword being introduced in Ansible 2.5.

Everyone knows the with_* syntax in playbooks.

For example:

- name: Test that with_list works with a list
  ping:
    data: ''
  with_list:
    - 'Hello World'
    - 'Olá Mundo'

In Ansible 2.5, we're introducing loop as a shorter, simpler keyword for playbooks.

Example:

- name: Test that loop works with a manual list
  ping:
    data: ''
  loop:
    - 'Hello World'
    - 'Olá Mundo'

It's a very minute change, and can easily be overlooked when skimming a playbook! However, when writing many lines of tasks in a playbook, why not save some potential muscle fatigue?

Let's be real, even if a playbook accomplishes a whole lot in 10 lines, that's still ten lines!

All joking aside, we wanted to make things simpler. It's much easier to remember loop than with_items or with_list.

The question after this very well may be, "What happens to with_first_found or with_dict or .... etc, etc, etc?

Well the idea here is to abstract out some of the magic that with_* really is.

Example:

- name: Test that loop works with a list via the list  Continue reading

0

Dynamic Inventory: Past, Present & Future

In Red Hat Ansible Engine 2.4, we made some changes to how inventory works. We introduced a new cli tool, and added an inventory plugin type.

The goal of this plugin type, was well, to make Ansible Engine even more pluggable. All kidding aside, we wanted to provide Ansible Engine content authors and Ansible Engine users a new way to visualize their target inventory.  Using the ansible-inventory command,  the targeted inventory will be listed with the details of the hosts in that inventory, and the hosts groups.

For example:

[thaumos@ecb51a545078 /]# ansible-inventory -i ~/Development/playbooks/inventory/prod.aws_ec2.yml --list
{
    "_meta": {
        "hostvars": {
            "ec2-5x-xx-x-xxx.us-west-2.compute.amazonaws.com": {
                "AmiLaunchIndex": 2,
                "Architecture": "x86_64",
                "BlockDeviceMappings": [
                    {
                        "DeviceName": "/dev/sda1",
                        "Ebs": {
                            "AttachTime": "2017-12-13T15:40:19+00:00",
                            "DeleteOnTermination": false,
                            "Status": "attached",
                            "VolumeId": "vol-0514xxx"
                        }
                    }
                ],
                "ClientToken": "",
                "EbsOptimized": false,
                "Hypervisor": "xen",
                "ImageId": "ami-0c2aba6c",
                "InstanceId": "i-009xxxx3",
                "InstanceType": "t2.micro",
                "KeyName": "blogKey",
                "LaunchTime": "2017-12-13T15:40:18+00:00",
                "Monitoring": {
                    "State": "disabled"
                },
                "NetworkInterfaces": [
                    {
                        "Association": {
                            "IpOwnerId": "amazon",
                            "PublicDnsName": "ec2-5x-xx-x-xxx.us-west-2.compute.amazonaws.com",
                            "PublicIp": "5x.xx.x.xxx"
                        },
                        "Attachment": {
                            "AttachTime": "2017-12-13T15:40:18+00:00",
                            "AttachmentId": "eni-attach-97c4xxxx",
                            "DeleteOnTermination": true,
                            "DeviceIndex": 0,
                            "Status": "attached"
                        },
                        "Description": "",
                        "Groups": [
                            {
                                "GroupId": "sg-e63xxxxd",
                                "GroupName": "blogGroup"
                            }
                        ],
                        "Ipv6Addresses":  Continue reading

0

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

0

Real-time Insights Into App Delivery with Ansible Tower Data in Splunk

 

Here at Ansible by Red Hat, we’re always looking for ways to make Ansible more useful when automating all the things.

That being said, most people know this UI when they see it:

When we ask Ansible users about their favorite tools, Splunk is a very common answer. Splunk software is at its most powerful when it is used to aggregate and correlate data from numerous sources across your environment. However, there hasn't been an easy way to use Splunk to analyze data from Ansible Tower job runs.

Not any longer. Today we’re happy to announce the result of our latest integration project - the Ansible Tower App for Splunk.

The value of analytics platforms such as Splunk, is the ability to collect and correlate machine data including environment events with the actions that caused them. Application lifecycle management teams need the ability to correlate deployment-related data (i.e. Tower job runs) with host events (i.e. system and service logs).

Picture the following scenario:
A development team is working to release a new version of their application. What is the easiest way for a team to validate the success of the application deployment process?

The Ansible Tower app for Splunk allows a team to deploy Continue reading

0

Integrating Atlassian Bitbucket Pipelines with Ansible Tower

Customers everywhere are using Ansible and Ansible Tower to deliver the promise of DevOps. Atlassian Bitbucket can be coupled with Ansible and Ansible Tower to create an application workflow. In this example workflow, a developer makes an update to their application, checks the code into source control, a continuous integration test passes, and it is automatically deployed by an orchestration system to the applicable systems.

One of the most popular requests we hear for Tower is to integrate with the Atlassian tool suite. Atlassian provides tools that allow developers to build many components of a CI/CD pipeline. From Bitbucket for code review, to JIRA as a ticketing system, and finally Hipchat to bring all of the teams involved in the pipeline to collaborate.

And, with Atlassian’s recent announcement of Bitbucket Pipelines, we are excited to demonstrate how Tower can now integrate these tools into a complete CI/CD pipeline environment.

Using our example workflow from above, let’s look at what this process looks like today-- without this integration. First, a developer checks in some code to Bitbucket Cloud, and a Pipelines job can build and test an artifact. Next, the developer would need to find the correct build, download it, and Continue reading