Give Codeship’s CI/CD Platform a Try

Want to learn more?

Recently at Codeship, we’d been experiencing issues with our Docker registry provider. Over the past few months, we have unfortunately been passing on some stability issues with Quay.io to our customers. Due to a lack of resilience in the face of dependency downtime, we have been failing to start some of our customers builds.

This blog post explains how we decided upon that course of action and then how we delivered and validated an implementation.

Understanding the Problem

First off, why does downtime for Quay.io lead to builds not being started? We use Quay.io to store an important part of the Codeship Pro system. This component is a Docker image that contains our build agent. jet, our CLI tool for running Pro builds on your local machine, runs on the same engine as this build agent during a hosted Codeship Pro build.

When your build hook arrives, we allocate it with an appropriately sized machine. This machine has a copy of the build agent on it. However, this is loaded onto the machine when we create the machine image itself. We build our Codeship Pro build machines with Amazon Machine Images (AMIs). When provisioning our fleet, we boot from this base AMI.

At Codeship, we like to be nimble and ship updates to our build agent regularly. Our release cadence for our Docker host AMI is too slow to keep up with the agent’s release cycle. Also building AMIs is a slow process, certainly slower than building and shipping a Docker image. So we like to pull the latest build agent image the moment we pair your build hook with an instance.

Keeping these components decoupled is useful both for frequent updates to our build agent and the ability to build and test new Docker updates in isolation.

The downside of this process is that we are dependent on our Docker registry provider to be fully operational at the start of every build. The first failsafes we put in place were retries with exponential back-off. This served us well on the Pro platform for a long time. However, degraded performance from Quay.io was more frequent, sometimes for a relatively long period of time.

The number of API (HTTP 500) errors that we experienced from quay.io over the last 60 days.

Fixing the Problem

We started with identifying our desired outcomes and success criteria, and then did some high-level implementation discovery before launching into execution.

Outcomes

We mitigate the impact of degraded performance from our registry providers (as much as possible) on our customers. Builds should not fail to start because a single registry provider is not operational.

High-level implementation details

We would identify and promote a new registry provider as our primary provider and Quay.io would become our failover provider.

We wanted to isolate this new behavior and responsibility to a single system (previously it existed in two places).

Success criteria

We can still ship a canary release.

If we purposefully degrade the performance of our primary registry provider, then our customers’ builds should not be impacted.

Planning implementation

We then set to planning out the specifics and fleshing out more implementation details. Who was our new primary registry provider going to be? Where was this logic going to live? Where was it not going to live? Where in the system needed refactoring to accommodate this change? Did we have and could we leverage any existing components in our system? And so on…

The last part of the formula is quite interesting. This is the bit where we purposefully break something, pause for dramatic effect, and then hopefully sigh in relief as everything resumes as normal in a quiet anticlimax.

To create this moment of chaos, my colleague did something simple. He deleted the build agent from our ECR registry. Knowing this error would be classified as a failure, we expected a failover to occur. Once we found the courage to squint through our tightly clenched eyes, we found everything to be still operating as we had hoped.

Blue: the number of attempted pulls from ECR Red: the number of attempted pulls from quay.io

The metrics above show the behavior of a real failover test in production. The blue stacked line represents an attempt to pull from ECR, where the red stacked line is an attempt to pull from quay.io.

Just after 15:30, I deleted the image from ECR and let the system deal with the issue for 15 minutes before restoring the image. We continued to attempt ECR, but the moment there’s a failure, we fall back to Quay.io. That’s why you see a mixture of blue and red while the “outage” is occurring. I performed this failover just for the blog post, as the previous metrics we had just weren’t pretty enough.

Going forward at Codeship, it will now become policy to add a bit of “self-inflicted chaos” to all of our releases, so that we can feel confident we’re doing our utmost to keep the chaos away from your builds.

Subscribe via Email

Over 60,000 people from companies like Netflix, Apple, Spotify and O'Reilly are reading our articles. Subscribe to receive a weekly newsletter with articles around Continuous Integration, Docker, and software development best practices.

We promise that we won't spam you. You can unsubscribe any time.

Join the Discussion

Leave us some comments on what you think about this topic or if you like to add something.