{"id":18196,"date":"2017-08-08T12:15:36","date_gmt":"2017-08-08T09:15:36","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=18196"},"modified":"2017-08-08T11:41:06","modified_gmt":"2017-08-08T08:41:06","slug":"building-remote-caching-system-sequel","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/devops\/building-remote-caching-system-sequel\/","title":{"rendered":"Building a Remote Caching System: The Sequel"},"content":{"rendered":"

Last fall, Docker made some big changes that required us to overhaul how our Codeship Pro image caching system worked. Our director of engineering, Laura Frank, published a blog post explaining everything<\/a> back when we launched this new system.<\/p>\n

The gist of this was that Docker no longer allowed images pulled from a remote source to be used as a cache source. This was a security measure to prevent cache poisoning. The workaround to this was to rely on the save and load commands to package up your images and store them on S3 as tarballs. This took a lot more time to do, per image, for a variety of reasons; Laura\u2019s blog post will explain it all in more detail.<\/p>\n

Now, though, we\u2019re undoing all of that\u2026because Docker restored the original functionality and made it possible for us to use remote images as a local cache source again.<\/p>\n

For you, this means much faster image caching on your builds. For us, it means we\u2019re using an Amazon-backed registry with much less disk space and much less overhead to offer a much better experience and faster build times for Codeship Pro builds! If you can\u2019t tell, we\u2019re very excited about improving the performance of our caching system.<\/p>\n

Watch the engineer who\u2019s working on our caching system discuss the update.<\/a><\/p><\/blockquote>\n

Registry-based System Security and Benchmarks<\/h2>\n

Let\u2019s take a minute to talk about the how and why of these changes a bit more.<\/p>\n

What is the new system in more detail?<\/h3>\n

Essentially, after your builds complete, we push any images you have enabled caching for \u2014 using your simple cached: true<\/code> directive attached to your services, as defined in your codeship-services.yml<\/a> file \u2014 to an Amazon-backed registry we maintain.<\/p>\n

These images are set up on registry accounts with credentials unique to your project. No other project has backend access to your cached images, and there is no centrally accessible pool of cached images under a single account.<\/p>\n

We\u2019re big fans of deferring security to more complex and larger providers, like AWS, where we can. Rather than host our own registry infrastructure and add a new security apparatus to our infrastructure support operations, we made the call that using AWS for this purpose would provide more reliable security than we could internally compete with at our size.<\/p>\n

Let\u2019s look at performance<\/h3>\n

Speed was the main reason we made this change, and the benchmarks we have indicate that the gains for most builds will be quite substantial. Additionally, because we no longer need to save parent image data and because registries are much smarter at only saving differentials between images than the full tarball we previously had to rely on, you can see it has a huge dent in the disk space the system requires as well.<\/p>\n