Speaker Lineup for AnsibleFest London

Featuring speakers from Industrial Light and Magic, Atlassian, Cisco and more! 

We're happy to share our speaker lineup for AnsibleFest London on Thursday, February 18th at InterContinental London - The O2. Our one-day user conference brings together hundreds of Ansible users, developers and industry partners to share best-practices, case studies and Ansible news.

With yet another record setting amount of submissions, our engineering team had their work cut out for them. We took each submission, anonymized them to remove any speaker/company/product information, and sent them off to our team of engineers for blind review. We then picked out a well-rounded agenda from the highest scoring talks. 

Stay tuned for additional speakers announcements leading up to the event.

Deploying a Mesos Based Visual Effects Studio with Ansible

Aaron Carey, Production Engineer, Industrial Light and Magic
Jim Vanns, Senior Production Engineer, Industrial Light and Magic 

Industrial Light and Magic is leveraging Ansible to deploy a Mesos cluster from scratch on multiple cloud platforms, build its application docker images and deploy them as services. This presentation will look at how ILM is using tags to manage services dynamically, and the steps taken to make it work across different cloud providers.

Continue reading

Webinar Q&A: Docker Networking

Using Docker with macvlan Interfaces

In this post, I’m going to show you how to use macvlan interfaces with Docker for networking. The use of macvlan interfaces presents an interesting networking configuration for Docker containers that may (depending on your use case) address issues with the standard Linux bridge configuration.

Macvlan interfaces, if you’re unfamiliar with them, are a (somewhat) recent addition to the Linux kernel that enables users to add multiple MAC address-based logical interfaces to a single physical interface. These logical interfaces must reside in the same broadcast domain as the associated physical interface, which means that Docker containers attached to macvlan interfaces also will be in the same broadcast domain as the associated physical interface. In other words, the Docker containers will be on the same network as the host—no IPTables rules, no Linux bridge, just attached directly to the host’s network. This introduces some interesting possibilities (and potential challenges), but I’ll save that discussion for a future post.

Right now, macvlan supported is implemented via an unsupported Docker Network plugin hosted on GitHub. However, I suspect that the macvlan functionality found in this plugin will find its way into the core of Docker Network, and probably sooner rather than later.

You’ll Continue reading

Ansible Galaxy 2.0 Launches

Here’s a quick run-down:

Organizations

There really should be a drum roll playing as you read this, because this feature has been at the top of everyone’s wish list for as long as Galaxy has been around. But here it is… Organizations now have a home in Galaxy. Yes, you can import roles into an organization!

How, you ask? Just click the import button. Really. That’s it. The role will be imported exactly as the repository appears in GitHub. If the role belongs to ‘acmeco’ in GitHub, then it will appear under ‘acmeco’ in Galaxy.

You can import any repositories from GitHub where you are a collaborator or owner. Log in as yourself, and import your roles or your organization’s roles.

Existing roles prior to Galaxy 2.0 have not been changed. To move a role from your username to an organization, delete the role and import it again.

Semantic URLs

Sharing links to your content in Galaxy now makes sense with user-friendly URLs that include GitHub username or organization and Continue reading

Ansible Galaxy 2.0 Launches

Here’s a quick run-down:

Organizations

There really should be a drum roll playing as you read this, because this feature has been at the top of everyone’s wish list for as long as Galaxy has been around. But here it is… Organizations now have a home in Galaxy. Yes, you can import roles into an organization!

How, you ask? Just click the import button. Really. That’s it. The role will be imported exactly as the repository appears in GitHub. If the role belongs to ‘acmeco’ in GitHub, then it will appear under ‘acmeco’ in Galaxy.

You can import any repositories from GitHub where you are a collaborator or owner. Log in as yourself, and import your roles or your organization’s roles.

Existing roles prior to Galaxy 2.0 have not been changed. To move a role from your username to an organization, delete the role and import it again.

Semantic URLs

Sharing links to your content in Galaxy now makes sense with user-friendly URLs that include GitHub username or organization and Continue reading

Recap: Docker at SCALE 14x

Unikernel Systems Joins Docker

Looking Ahead: My 2016 Projects

Almost every year since 2012, I’ve been publishing a list of projects/goals for the upcoming year (here’s the original list for 2012, then 2013, I skipped 2014, and here’s the list for 2015). In this post, I’m going to share with you the list of projects/goals for 2016.

Here’s the list for 2016. For some of the items below, I’m also going to include a stretch goal, something I’ll aim toward but won’t count against myself if I don’t actually attain it.

1. Complete a new book (again). In addition to actually completing the new network automation book I’m writing with Jason Edelman and Matt Oswalt (it’s available now as an Early Access edition), I have another book project lined up that I intend to finish and get published in 2016.

2. Make more open source contributions. I failed this one miserably last year (see last year’s report card), but I am intent on making this one happen. Over time, I expect that this will just be part of who I am, but until then I’m going to explicitly call it out. Since I’m not a programmer (not yet, may never be), these contributions will have Continue reading

Laura Frank Explains Why She Spoke at DockerCon EU 2015

Your Docker Agenda for SCALE 14x

2016: The Tipping Point for DevOps

Ahhh, a new year.

While 2015 was certainly a big year for us as we joined the Red Hat family, in many ways we’re still right at home with our roots deeply planted in the ways of open source. That means we’re listening (as we always do) to our customers and community members about what what they see as their problems to solve and goals to achieve in the year ahead. 

Here’s a bit of what we see:

• DevOps! It’s everywhere! If ever there was a buzzword to officially deserve the “jumped the shark” label, this might just be it. General understanding of DevOps as a practice that can potentially accelerate IT project delivery has permeated most IT departments, from the smallest of businesses to the most daunting of large enterprises, sometimes from the grassroots level, and sometimes from the top down.  

• Thankfully, along with this recognition, people are increasingly recognizing that DevOps isn’t simply tools -- that building a healthy organizational culture is a significant part of their journey. Many organizations are beginning to recognize that it’s not a lightswitch, or a flat-out reorg. The idea that small wins can matter when bringing DevOps practices into your Continue reading

2016: The Tipping Point for DevOps

Ahhh, a new year.

While 2015 was certainly a big year for us as we joined the Red Hat family, in many ways we’re still right at home with our roots deeply planted in the ways of open source. That means we’re listening (as we always do) to our customers and community members about what what they see as their problems to solve and goals to achieve in the year ahead. 

Here’s a bit of what we see:

• DevOps! It’s everywhere! If ever there was a buzzword to officially deserve the “jumped the shark” label, this might just be it. General understanding of DevOps as a practice that can potentially accelerate IT project delivery has permeated most IT departments, from the smallest of businesses to the most daunting of large enterprises, sometimes from the grassroots level, and sometimes from the top down.  

• Thankfully, along with this recognition, people are increasingly recognizing that DevOps isn’t simply tools -- that building a healthy organizational culture is a significant part of their journey. Many organizations are beginning to recognize that it’s not a lightswitch, or a flat-out reorg. The idea that small wins can matter when bringing DevOps practices into your Continue reading

Multi-Machine Vagrant Environments with JSON

In this post I’d like to show you how to use a JSON-formatted data file to create and configure multi-machine Vagrant environments. This isn’t a new idea, and certainly not anything that I came up with or created. I’m simply presenting it here as an alternative option to the approach of using YAML with Vagrant for multi-machine environments (some people may prefer JSON over YAML).

If you’re unfamiliar with Vagrant, I’d start with my introduction to Vagrant. Then I’d recommend reviewing my original article on using YAML with Vagrant, followed by the updated/improved method that addresses a shortcoming with the original approach. These earlier posts will provide some basics that I’ll build on in this post.

To use a JSON-formatted data file as an external data source for Vagrant, the code in the Vagrantfile looks really similar to the code you’d use for YAML:

# -*- mode: ruby -*-
# # vi: set ft=ruby :
# Specify minimum Vagrant version and Vagrant API version
Vagrant.require_version '>= 1.6.0'
VAGRANTFILE_API_VERSION = '2'
# Require JSON module
require 'json'
# Read YAML file with box details
servers = JSON.parse(File.read(File.join(File.dirname Continue reading

Docker 1.10 Release Candidate Now Available: Important Tips on Updating Engines and Migrating Images to New IDs

Technology Short Take #59

Welcome to Technology Short Take #59, the first Technology Short Take of 2016. As we start a new year, here’s a collection of links and articles from around the web. Here’s hoping you find something useful to you!

Networking

• Nir Yechiel posted an article on using the Cumulus VX QCOW2 image with Fedora and KVM. Cumulus VX, if you aren’t aware, is a community-supported virtual appliance version of Cumulus Linux aimed at helping folks preview and test “full-blown” Cumulus Linux (which, of course, requires compatible hardware).
• NAPALM (Network Automation and Programmability Layer with Multivendor support) looks like a really cool tool. I haven’t yet had the opportunity to work with it, but it is definitely something I’d like to explore in more detail. Here’s an article on an effort to add Cisco IOS support to NAPALM. Gabriele (the author of that post) also has a nice article on some resources to get you started with network automation.
• Using Python and Netmiko for network automation is the topic of this post by Colin McAlister. This is a good introductory post, and one that I plan to leverage as I dive deeper into these tools.
• Kuryr (the OpenStack project to allow Docker Continue reading

An Improved Way to use YAML with Vagrant

In this post, I’d like to share with you an improved way to use YAML with Vagrant. I first discussed the use of YAML with Vagrant in a post on simplifying multi-machine Vagrant environments, where I simply factored out variable data into an external YAML file. The original approach I described had (at least) one significant drawback, though, which this new approach adddresses.

(By the way, this “improved” way is probably just a matter of better coding. I’m not an expert with Ruby, so Ruby experts may look at this and find it to be quite obvious.)

Here’s the original snippet of a Vagrantfile that I shared in that first Vagrant/YAML post:

# -*- mode: ruby -*-
# # vi: set ft=ruby :
# Specify minimum Vagrant version and Vagrant API version
Vagrant.require_version ">= 1.6.0"
VAGRANTFILE_API_VERSION = "2"
# Require YAML module
require 'yaml'
# Read YAML file with box details
servers = YAML.load_file('servers.yaml')
# Create boxes
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
# Iterate through entries in YAML file
servers.each do |servers|
config.vm.define servers["name"] do |srv|
 Continue reading

Five Reasons to Speak at DockerCon 2016

Docker Job Market Heating Up

Ansible 2.0 Has Arrived

After a year of work, we are extremely proud to announce that Ansible 2.0 has been released and is now generally available. This is by far one of the most ambitious Ansible releases to date, and it reflects an enormous amount of work by the community, which continues to amaze me. Approximately 300 users have contributed code to what has been known as “v2” for some time, and 500 users have contributed code to modules since the last major Ansible release.

Why Did We Start V2?

There are many pitfalls to refactoring software, so why did we decide to tackle such a major project? At the time we started the work on v2, Ansible was approximately three years old and had recently crossed the 1,000 contributor mark. This huge rate in growth also resulted in a degree of technical debt in the code, which was beginning to show as we continued to add features.

Ultimately, we decided it was worth it to take a step back and rework some aspects of the codebase which had been prone to having features bolted on without a clear-cut architectural vision. We also rewrote from scratch much of the code which was responsible Continue reading

Ansible 2.0 Has Arrived

After a year of work, we are extremely proud to announce that Ansible 2.0 ("Over the Hills and Far Away") has been released and is now generally available. This is by far one of the most ambitious Ansible releases to date, and it reflects an enormous amount of work by the community, which continues to amaze me. Approximately 300 users have contributed code to what has been known as “v2” for some time, and 500 users have contributed code to modules since the last major Ansible release.

Why Did We Start V2?

There are many pitfalls to refactoring software, so why did we decide to tackle such a major project? At the time we started the work on v2, Ansible was approximately three years old and had recently crossed the 1,000 contributor mark. This huge rate in growth also resulted in a degree of technical debt in the code, which was beginning to show as we continued to add features.

Ultimately, we decided it was worth it to take a step back and rework some aspects of the codebase which had been prone to having features bolted on without a clear-cut architectural vision. We also rewrote from scratch much Continue reading