In the fast-paced world of DataOps and continuous integration, Docker has become an indispensable tool for containerisation. However, like any technology, it occasionally encounters hiccups. One such hiccup is when Docker experiences issues with its Hub Registry and Docker Authentication, like it did yesterday: overview of incident on 28.09.2023.

 Fortunately, there's a way to mitigate these risks and enhance the resilience of your DataOps pipelines: by using multiple pull policies.

Understanding the Challenge

Before delving into the solution, it's important to understand the challenge at hand. When Docker's Hub Registry or authentication systems encounter problems, it can disrupt the smooth flow of your pipelines. This disruption can lead to delays and operational headaches, especially when your CI/CD processes rely heavily on Docker images.

The Power of Multiple Pull Policies

To address this challenge, DataOps offers a powerful feature: the ability to define multiple pull policies. These pull policies act as a safety net, ensuring that your pipelines can continue to operate even when the primary pull policy encounters issues.

Here's how it works:

1. Modify Configuration: In your runner, inside the config.toml, you can specify a list of pull policies. For example:

m>runners]]

  (...)

  executor = "docker"

  /runners.docker]

    (...)

    pull_policy = p"always", "if-not-present"]

In this example, two pull policies are defined: "always" and "if-not-present." Restart the runner after the configuration change.

2. Priority Order: The runner will process these pull policies in the order they are listed. In our example, "always" takes precedence over "if-not-present." This means that if "always" fails to pull an image for any reason, the runner will then fall back to using the locally available image if it exists.

Practical Application

Let's illustrate the practical application of multiple pull policies with an example:

Suppose a runner is configured with these pull policies: "always" and "if-not-present." Here's what happens when a pull is attempted:

1. The runner first attempts to pull the image with the "always" policy. If it succeeds, great! The process continues with the freshly pulled image.

2. If, for any reason, the "always" pull policy fails (e.g., Docker Hub issues, authentication problems), the runner doesn't give up. It moves on to the next policy, which is "if-not-present."

3. With the "if-not-present" policy, the runner checks if a locally cached Docker image is available. If it finds one, it uses that image to ensure that your pipeline can proceed without interruption.

Security Considerations

It's important to note that while multiple pull policies enhance resilience, they also raise security considerations. Using a local image with the "if-not-present" policy could potentially introduce security risks if the locally cached image is outdated or unverified. Therefore, it's crucial to balance resilience with security by regularly updating and validating locally cached images. 

Conclusion

In the dynamic world of DataOps, interruptions in your Docker pipelines can be a frustrating hurdle. However, by leveraging multiple pull policies, you can bolster the resilience of your pipelines and ensure that your CI/CD processes continue to run smoothly, even when Docker experiences issues with its Hub Registry or authentication systems. With the right strategies in place, you can keep your DataOps pipelines resilient and your development workflows on track.

This and other Product information you can find in our documention section and for updates on our platform's status and any potential issues, subscribe to our Status Page.