When I first started learning about Docker a year ago and exploring its use I had trouble finding great documentation and examples—even today many describe simple use cases that ultimately aren’t production ready. Productionizing applications with Docker containers requires adjusting to their ephemeral nature and single-process focus. This presents challenges to applications with data persistence needs or multi-process architectures.
Search Results for: docker
This is the in-depth tutorial for the discussion started here about creating a build farm using Jenkins with Docker containers as the build slaves. When we’re done, you should have a fully functional Jenkins environment that provisions build slaves dynamically, running on your local environment and ready for you to productionize.
In the last blog post we discussed taking more control of our Jenkins Docker image by wrapping the Cloudbees image with our own Dockerfile. This empowered us to set some basic defaults that we previously passed in every time we ran `docker run`. We also took the opportunity to define where to place Jenkins logs and how to use Docker exec to poke around our running container.
In the previous post I walked through creating a full set of Docker images to deploy Jenkins in containers. We don’t deploy our production Jenkins server in containers just yet, although we fully intend to. The real value my team has gained from this work is the ability to quickly spin up Jenkins test environments. These environments can be used to test plugins in isolation or create reproduction cases for problems we’re encountering.
If you’re just joining us, start out with this introductory post about our move to continuous delivery on League and how we found the tech stack to best solve our problems.
Thinking inside the container means building inside one as well. Today I’d like to open up the box on how my team is currently combining Jenkins and Docker to serve Riot Engineering teams. In the most recent post, I promised I would soon discuss the actual build slave and Jenkins configuration directly.
Over the past several months I’ve published six articles that discuss using Docker and Jenkins to containerize a build farm. Recently, I went on the road to tell the story at DockerCon 2016 and gathered a tremendous amount of amazing feedback. In fact, the best part of this whole experience has been the conversations we’re having with folks encountering similar challenges. In this short post, I’d like to accomplish two things: share the video of my DockerCon talk, and respond to requests we’ve received to consolidate my articles into a single place.
Our names are Kyle Allan and Carl Quinn, and we work on the infrastructure team here at Riot. Welcome to the second blog post in our multi-part series describing in detail how we deploy and operate backend features around the globe. In this post, we are going to dive into the first core component of the deployment ecosystem: container scheduling.
Containers have taken over the world, and I, for one, welcome our new containerized overlords.
My name is Jonathan McCaffrey and I work on the infrastructure team here at Riot. This is the first post in a series where we’ll go deep on how we deploy and operate backend features around the globe. Before we dive into the technical details, it’s important to understand how Rioters think about feature development. Player value is paramount at Riot, and development teams often work directly with the player community to inform features and improvements.