Today, we’re excited to share with you another round of speakers selected by the DockerCon Community Review Committee. Once again, we’d like to thank everyone who took the time to both submit and review the proposals for DockerCon 2016 !
Everyone should have received notification of their submission status. If you submitted to the CFP and have not heard from us, please reach out firstname.lastname@example.org.
Use Case Track
Docker in Production, look no hands !!!
with Scott Coulton , Solution Architect at HealthDirect
In this session we will talk about HealthDirect’s journey with Docker. We will follow the life cycle of a container through our CD process to its home in our swarm cluster with just a git commit thanks to configuration management. We will cover the CD process for Docker, Docker swarm, Docker networking and service discovery. The audience will leave with a solid foundation of how to build a production ready swarm cluster (A github repo with code will be given). They will also have the knowledge of how to implement a CD framework using Docker.
Thinking Inside the Container: A Continuous Delivery Story
with Maxfield Stewart , Engineering Manager at Riot Games
Riot builds a lot of software. At the start of 2015 we were looking at 3000 build jobs over a hundred different applications and dozens of teams. We were handling nearly 750 jobs per hour and our build infrastructure needed to grow rapidly to meet demand. We needed to give teams total control of the “stack” used to build their applications and we needed a solution that enabled agile delivery to our players. On top of that, we needed a scalable system that would allow a team of four engineers to support over 250. We built an integrated Docker solution using Jenkins that accepts docker images submitted as build environments by engineers around the company . Our “containerized” farm now creates over 10,000 containers a week and handles nearly 1000 jobs at a rate of about 100 jobs an hour.
In this occasionally technical talk, we’ll explore the decisions that led Riot to consider Docker, the evolutionary stages of our build infrastructure, and how the open source and in-house software we combined to achieve our goals at scale. You’ll come away with some best practices, plenty of lessons learned, and insight into some of the more unique aspects of our system (like automated testing of submitted build environments, or testing node.js apps in containers with Chromium and xvfb).
with Josh Corman , CTO at Sonatype and John Willis at Docker, Inc.
This presentation will show the combination of two ideas that can create 2 to 3 order of magnitude efficiencies in service delivery. We will discuss an example used in an insurance company that has experienced these increases. Josh Corman will present the concept of using Open Source and Toyota Supply Chain principles as a weapon for eliminating operational costs of service delivery. By applying first order principles like fewer suppliers (e.g, less logging frameworks) and image manifests (i.e., bill of materials) he will show how an organization can cut down on bugs and issue resolution times. John Willis will then cover how these principles fit like peanut butter and chocolate when used in an immutable delivery model based on Docker. This presentation was the third highest rated session at the 2015 Devops Enterprise Summit.
Containers will not fix your broken culture (and other hard truths)
with Bridget Kromhout , Principal Technologist at Pivotal
Containers will not fix your broken culture. Microservices won’t prevent your two-pizza teams from needing to have conversations with one another over that pizza. No amount of industrial-strength job scheduling makes your organization immune to Conway’s Law. Does this mean that devops has failed? Not in the slightest. It means that while the unscrupulous might try to sell us devops, we can’t buy it. We have to live it; change is a choice we make every day. Making thoughtful decisions about tools and architecture can help. Containers prove to be a useful boundary object, and deconstructing systems to human-scale allows us to comprehend their complexity. We succeed when we share responsibility and have agency, when we move past learned helplessness to active listening. But there is no flow chart, no checklist, no shopping list of ticky boxes that will make everything better. “Anyone who says differently is selling something”, as The Princess Bride teaches us. Part rant, part devops therapy, this talk will explain in the nerdiest of terms why CAP theorem applies to human interactions too, how oral tradition is like never writing state to disk, and what we can do to avoid sadness as a service.
Efficient Parallel Testing with Docker
with Laura Frank , Codeshipper at Codeship
Fast and efficient software testing is easy with Docker. We often use containers to maintain parity across development, testing, and production environments, but we can also use containerization to significantly reduce time needed for testing by spinning up multiple instances of fully isolated testing environments and executing tests in parallel. This strategy also helps you maximize the utilization of infrastructure resources. The enhanced toolset provided by Docker makes this process simple and unobtrusive, and you’ll see how Docker Engine, Registry, Machine, and Compose can work together to make your tests fast.
The Dockerfile explosion and the need for higher level tools
with Gareth Rushgrove , Senior Software Engineer at Puppet Labs
Dockerfiles are great. They provide a zero-barrier-to-entry format for describing a single Docker image which is immediately clear to anyone reading them. But with that simplicity comes problems that become apparent as your adoption of Docker gathers pace.
- Dockerfiles can inherit from other docker images, but images are not Dockerfiles.
- Dockerfile provides no built-in mechanism for creating abstractions, so as usage grows identical or similar instructions can be duplicated across many files.
- The Docker APi exposes a build endpoint, but the API is very coarse, taking Dockerfile as the transport rather than exposing the individual instructions.
- Dockerfiles are just that, files. So they can come from anywhere.
- The one layer per line in a Dockerfile limitation can lead to an explosion of layers, which fail to take advantage of the promised space and performance benefits .
This talk will discuss the triggers for when managing Dockerfiles ad hoc becomes a problem, including the passing of time and scaling teams and organisations usage of Docker. Included in the talk are strategies for managing Dockerfile sprawl, multiple examples from the Docker community of attempts to abstract away from Dockerfile, and why that might not always be the best approach. I will speculate wildly and show experiments which look to address some of the issues discussed.
Dockerizing CS50: From Cluster to Cloud to Appliance to Container
with David Malan , Gordon McKay Professor of the Practice of Computer Science in the School of Engineering and Applied Sciences at Harvard University
CS50 is Harvard University’s introduction to the intellectual enterprises of computer science and the art of programming for majors and nonmajors alike. The course is Harvard’s largest, with 800 students in Cambridge, as well as Yale University’s largest, with 300 students in New Haven. The course is also edX’s largest MOOC, with 700,000 registrants online.
Prior to 2008, the course relied on a load-balanced cluster of Linux machines on campus on which students had shell accounts with which to write and debug code. In 2008, we moved the course into the cloud, replicating that infrastructure with virtual machines (VMs) using Amazon EC2. And in 2009, we moved those VMs back on campus using VMware ESX. Our goals were both technical and pedagogical. As computer scientists, we wanted more control over our course’s infrastructure. As teachers, we wanted easier access to our students’ work as well as the ability to grow and shrink our infrastructure as problem sets’ computational requirements demanded.
In 2011, though, we replaced our centralized infrastructure with the CS50 Appliance, a client-side VM for students’ own laptops and desktops. Not only did the appliance enable us to provide students with more familiar graphical interfaces, it also enabled us to provide students with their own local servers. Moreover, the appliance ensured that the course’s workload no longer required constant Internet access, particularly of students abroad. And the appliance alleviated load on the course’s servers, with execution of students’ programs now distributed across students’ own CPUs.
In 2015, we began to Dockerize the course, replacing the CS50 Appliance with CS50 IDE, a web-based equivalent based on Cloud9, underneath which is a container for each student. We also began to migrate the course’s own web apps to Docker. Among our goals were to ease deployment, isolate services, and equip the course’s developers with identical environments.
We present in this talk what we did right, what we did wrong, and how we did both.
Community Theater Lightning Talks
Sports, Data and Docker
with Daniel Willis, Student at Durham Middle School
Hi, my name is Daniel Willis and I am a 13 year old student. I want to tell you a story of how I turned my love of sports into a love of data science which eventually lead me to Docker. With the help of my dad I started learning R and statistics around baseball data. Then I learned how to use Docker to create images that not only used a lot of different tools and packages I needed, but also allowed me to store a hundred years worth of baseball statistics into one Docker image. If you follow my instructions during the presentation you will be able to win any argument about your favorite baseball hero in less than 5 minutes. For example, with one “docker run” command I will prove statistically that Mariano Rivera from the NY Yankees, is the greatest relief pitcher who ever lived.
Mobycraft – Docker in 8-bit
with Aditya Gupta
Mobycraft is a Minecraft client-side mod to manage and visualize Docker containers in Minecraft. This mod can be installed in any standard Minecraft client and allow young kids to learn Docker fundamentals in a fun way. It allowed Aditya, a 13-year old boy to apply his Minecraft modding skills to pick up Docker concepts such as Engine, Machine, Swarm, and Remote API. In the process, he also picked up some Gradle and Maven skills.A new custom Minecraft block and structure was created to show multiple containers running in a multi-host environment. Each container can be started and stopped from Minecraft. Several Docker commands are exposed as Minecraft commands. A new Minecraft dimension, with custom look and feel, was created for containers.
More advanced Docker concepts such as containers running on multiple cloud, a heat map of Docker containers and visual grouping of containers is planned. Come to this talk to see this Minecraft mod in action and how you can contribute.
So easy, a ten year old can do it
with Zeph Gardler
Docker focuses on simplicity. In this session we will here how, Zeph, a 10 year old boy went from asking his dad a simple question, to deploying Docker containers to help search for a cancer cure and to build worlds. We’ll hear how the simplicity of Docker inspired him to learn more, and now as an 11 year old, he has moved on to programming his own containerized applications to process vital data streams from public APIs.
Join us at DockerCon 2016
We strongly recommend that you register soon to secure your pass. Each previous edition of DockerCon has sold out in advance.
For those who have submitted speaking proposals: if your talk proposal gets accepted for DockerCon, we’re more than happy to provide a refund on your purchased ticket.
Learn More about Docker
- New to Docker? Try our 10 minonline tutorial
- Share images, automate builds, and more with a free Docker Hub account
- Read the Docker1.10 Release Notes
- Subscribe toDocker Weekly
- Sign up for upcoming Docker Online Meetups
- Attend upcomingDocker Meetups
- Register for DockerCon 2016
- Watch DockerCon EU 2015 videos
- Start contributing to Docker