Containerized Caches

Feel free to raise any issue or PR

Index

• Motivation
• Which caches are available?
• How to use it?
  • Systemd socket activation
• Clients configuration
  • Making it simpler
  • Configurations
• Credits

Motivation

While working with containers, it might be needed to modify the Dockerfile a couple of times, which makes to invalidate the cache. Which means that you might need to wait until the build finish. But this is not the only reason, sometimes your network might be metered - specially if you are a digital nomad - then it might imply saving some money too.

So as a summary, it’s an optimization for the whole environment.

Which caches are available?

For the time being, this setup provides caches for:

• apt (Debian based distros)
• composer (PHP packaging)
• npm (Node packaging)
• pip (Python packaging)

How to use it?

You could go ahead and run:

make start

Without any parameter, it will start all caches, if you are interested only in one, then use make start c=pip for example. After that, you need to set up the proxy configuration in your packaging system, more on that later.

This means that there is an extra step before any request, and since we are thinking about optimizations, a better way to do it is using systemd socket activation.

All the options are described when you use:

make help

Note: Look at Making it simpler

Known errors

network lb declared as external, but could not be found

Getting this error might get you thinking why is the lb network required. Short answer it is not required, also if you check the docker-compose.yml file there will be many labels that are not required for the service. Those are helpers to access the caches from a web browser. I’ll explain more later. The easiest solution is:

make network

Systemd socket activation

The idea with is to optimize resources, having caches running without being used is a waste of resources. Using socket activations is possible to start the cache, once the first request is made.

To make it work, enable the socket activation for the service that you want. At the moments, the options are apt, composer, npm and pip.

For apt:

make install-sockets c=apt

How does this work?

Please take a look at this documentation where I’m using the same idea.

In the socket-activation/templates folder are 3 files.

• cache-EXAMPLE.socket This is the starting point, it will listen on GLOBAL_IP:PORT_SERVICE and when the first request arrives, the cache-EXAMPLE.service will be started.
• cache-EXAMPLE.service Here is it used as a proxy between the GLOBAL_IP and the SERVICE_IP. It will request to start cache-EXAMPLE-container.service and send the received request
• cache-EXAMPLE-container.service The definition of how to start the service.

These three files are required as a generic way to delegate the socket activation, if the services are able to receive a socket, then only two files will be used and cache-EXAMPLE.service, will provide the socket to the original service.

Clients configuration

It’s possible to set up local and containers to use these caches. The easiest way to do it on containers is:

make build i=python

Making it simpler

To avoid jumping directories to create a new container image, is good to have an alias to the Makefile, and then use it as a global command. So you can create the alias in your shell configuration.

alias cache="make -C <Path-of-your-repository>"

And then use it anywhere like cache build id=python

Configurations

Without changes, the proxies are set to use the domains:

• cache-apt.srv
• cache-composer.srv
• cache-npm.srv
• cache-pip.srv

If you are using dnsmasq with NetworkManagers, the easiest way to do it, is to resolve the domain srv to the GLOBAL_IP defined in the .env file.

• //etc/NetworkManager/dnsmasq.d/local-resolutions.conf/

address=/srv/172.17.0.1

and restart NetworkManager:

sudo systemd restart NetworkManager

How does it work?

• Pull i=<image>
• Tag it as <image>-original
• Add layers with packaging caches customizations
• Tag the new image as <image>

Doing this, we avoid modifying the Dockerfiles for any project.

Credits

• Docker compose Makefile Colors and initialization setup for Makefile and docker composer
• Velocita Proxy Docker image Velocita acts as a caching reverse proxy to Composer repositories.
• sameersbn/apt-cacher-ng Apt-Cacher NG is a caching proxy, specialized for package files from Linux distributors, primarily for Debian (and Debian based) distributions but not limited to those.
• Docker pip cache This image runs devpi server serving as a caching proxy to the main index. Here is the link to the original repo. I’ve created a fork because the PR with changes wasn’t updated.