AnsibleFest in NYC was an amazing day filled with everything Ansible. If you missed the presentations, we've compiled them all here.
Following up on my earlier post on Cumulus Linux networking concepts, I wanted to build on that information with a guide on configuring VLAN trunking. This would be useful in a number of different scenarios: supporting multiple (VLAN-backed) port groups on vSphere hosts, or connecting an Open vSwitch (OVS) bridge on a KVM or Xen hypervisor to multiple VLANs. You might also need to use a VLAN trunking configuration to connect a Cumulus Linux-powered switch to another switch.
For this configuration, I’m going to use the new VLAN-aware bridging functionality introduced in Cumulus Linux 2.5. There are two pieces involved in making this work:
Let’s look at each of these pieces individually.
In order to provide layer 2 (switched) connectivity between front-panel ports on a Cumulus Linux-powered switch, the ports have to be part of a bridge. In this case, we’ll create a VLAN-aware bridge, which simplifies the configuration (in my opinion). It’s a bit less “true” to the Linux way of doing things, but simpler.
Owing to its Debian roots, you’ll configure the bridge by either adding a stanza to /etc/network/interfaces
or Continue reading
At DockerCon 2015 in San Francisco, I had the opportunity to meet with a few vendors in the Docker ecosystem. Here are some notes from my vendor briefings.
StackEngine describes themselves as enterprise-grade container application management. They tout features like being able to compose Docker applications using a drag-and-drop interface, deploy containers across multiple hosts, and provide automation—all with the sort of controls that enterprise IT groups are seeking. That’s all well and good, but the key problem in my mind is that these are features Docker is seeking for themselves. Docker Compose offers the ability to specify applications. True, there’s no GUI (yet). Alas, StackEngine can translate their GUI application design into YAML, but it doesn’t comply with Docker Compose. Thus, it ends up being more competitive than complimentary, in my opinion. Docker Swarm and the upcoming Docker Network address some of StackEngine’s deployment functionality, and if Project Orca takes off as an official effort—well, let’s just say I hope that StackEngine has more planned. This is not to say that StackEngine isn’t a well-engineered solution offering real value; rather, this is to say that StackEngine appears to be, unfortunately, in the crosshairs for functionality Docker is aiming Continue reading
This is a liveblog for the DockerCon 2015 session titled “Scaling New Services: From Container Creation to Automated Deployments”. This session is being led by the Disney Systems Engineering team and will feature a discussion/demo involving Docker, Mesos, Chef, Consul, and HAProxy.
The session starts with an introduction by Alex Williams, founder of The New Stack, who quickly turns it over to the Disney staff—Brian Scott and Patrick O’Connor. Brian starts with an overview of all the various companies within Disney, and the challenges that breadth creates. He then discusses the role of Disney’s Systems Engineering team, and the responsibilities of the team. That includes managing infrastructure, both on-premises as well as cloud-based infrastructure.
So, why Docker? To improve the guest experience, Disney needs to be able to move fast. They want to get away from managing VMs and cattle to managing containers and micro-bots. Brian talks about issues with onboarding developers, battling configuration drifts, and similar challenges. Disney started on their Docker journey 6-10 months ago, and lots of teams are still exploring the use cases for Docker. Some teams are already using it in the CI pipeline, and other teams are evaluating production use cases. CI is a Continue reading
This is a liveblog from the day 2 general session at DockerCon 2015. I was running late from some early morning meetings (sorry folks), so I wasn’t able to catch the first part of the general session (about the first 15 minutes or so). Here’s what I was able to capture.
Chris Buckley, Director of DevOps at Business Insider, took the stage to provide an overview of how Business Insider (BI) started using Docker. Buckley provides some “lessons learned”:
This led BI to Fig (now Docker Compose), which led to a decrease in the time it took to get a development environment up and running. With the combination of Vagrant and Docker, BI was able to reduce that to just a couple of hours. When BI revisited production apps, they turned to use Upstart/SysV scripts for containers, but this wasn’t quite the right fit. BI turned back to Puppet, building a parameterized Puppet class to create containers, links, set environment options, and define dependencies on other containers/services starting first.
Before Docker, the workflow was developers to GitHub to Jenkins, which then pushed to Continue reading
This is a liveblog of the Docker Networking breakout session. This session is led by Madhu Venugopal and Jana Radhakrishnan, both formerly of Socketplane (and now with Docker following the acquisition). They are introduced by John Willis, also formerly of Socketplane and well-known within the DevOps community.
Some display issues plague the session at the beginning, so it appears that Murphy’s Law is back with a vengeance.
Madhu starts out the session with an overview of why networking (in particular Docker networking) is so important. Networking is vast and complex, and networking is an inherent part of distributed applications. Therefore, it’s important to make networking developer-friendly and application-driven. He shares a vision: “We’ll do for networking what Docker did for compute”. So what are the goals from this vision?
Libnetwork is a key part of this effort. It was open-sourced in April, with over 200 pull requests and 200 GitHub stars. Windows and FreeBSD ports are in progress. Libnetwork is part of the Docker 1.7 release with limited functionality, allowing users to test it before it is fully enabled in Continue reading
This is the “Top Secret Docker Session led by Gordon the Turtle,” which is really a session on Docker Plugins. However, since Docker Plugins were only announced this morning during the general session, the title for this session had to be obscured. On stage are ClusterHQ (Luke Marsden), Glider Labs (Jeff Lindsay), and Weaveworks (Alexis Richardson).
Marsden starts the session with a brief history of the Docker Plugins project, and how it grew out of Powerstrip. Marsden reiterates that he said Powerstrip would be successful if they would “throw it away” in 6 months. Four months later, the Docker Plugins project is now officially announced, and Powerstrip is no longer necessary.
Marsden next turns the stage over to Jeff Lindsay. Lindsay talks about why the Docker Plugins project is so important—every customer is unique, and customers want/need the freedom to choose the right solution to use the tools that best solve their particular problem(s).
Jeff Lindsay turns it over to Alexis Richardson, who outlines the core requirements for Docker Plugins. Richardson outlines 3 requirements, but he doesn’t have a slide that lists those requirements, so I couldn’t capture them. Plugins today are limited to storage and networking, but that isn’t Continue reading
This is a liveblog of the DockerCon 2015 session on resilient routing and discovery, part of the “Advanced Tech” track. Simon Eskilden (@Sirupsen on Twitter) from Shopify is the speaker for this session.
Not surprisingly (you’d understand this if you walked Eskilden’s presentation from DockerCon EU 2015), he starts out with a mention of the walrus (his favorite animal). Eskilden starts with a brief overview of Shopify (his employer) and Shopify’s production deployment of Docker (they’ve had Docker in production for over a year). Eskilden freely acknowledges that moving to a microservices-based architecture increases complexity and is not “free”. In order to help address the complexity brought on by microservices-based architectures, Eskilden wants to talk about resiliency, service discovery, and routing.
Eskilden reinforces that companies shouldn’t be implementing Docker solely for the sake of implementing Docker; it should be for a reason, a purpose (for him, it’s making sure Shopify’s services stay up and available). Resiliency is about building a reliable system from a bunch of unreliable components. Total availability is the availability per service to the power of the number of services. This means that the more services there are, the lower the total availability is. (To help Continue reading
This is a liveblog for the day 1 general session at DockerCon 2015, taking place this week (today and tomorrow, anyway) at the Marriott Marquis in San Francisco, CA. This is my first DockerCon, and I’m looking forward to picking up lots of new knowledge.
The general session starts with a video (cartoon) about something working in development but not in production, and how Solomon Hykes came up with the idea for containers and Docker. It’s a humorous, tongue-in-cheek production. As the video wraps up, Docker CEO Ben Golub takes the stage.
Golub starts with a personal story about the various startups for which he’s worked, and the importance of his “two fold test” (that it has global significance and that it is easy to explain when you go home for Thanksgiving). Maybe the Thanksgiving test didn’t quite make it, but Golub does think (naturally) that Docker has global significance. Golub says that Docker has become a fundamental part of how companies build, ship, and run distributed applications, and that Docker is a key part of how industries and cultures are being transformed. He attributes this success to the Docker community and the Docker ecosystem. Rightfully so, Golub credits the Continue reading