Varnish 6.x, Drupal 8.4+, WSL, Docker Desktop

Varnish + Drupal using Alpine Linux Docker Containers

Time to revisit an old trusty friend

Spoiler Alert: those Docker images ain’t nowhere on Docker Hub !!
Multiple Varnish containers running in my compose stack.


  • The Drupal 8.x Cache API has quite some improvements and features over Drupal 7.x — cache tags and contexts, in addition to pre-existing max-age support, something to potentially exploit with Varnish for squeezing every once of performance out of Drupal/Varnish.
  • Alpine Linux, my primary and pretty much sole Docker container base image conveniently already provides a recent version of Varnish 6.x in an apk package.
  • Also, I’m definitely not the first one to put Varnish in a container, by many years. Which is a good thing, because it means there is plenty of documentation.

A little dive into Docker Compose architecture

In the rest of the “short” story below I’ll be corresponding about some of the little things that I found interesting while rolling out this Varnish container for Docker on my local development environment. Don’t be intimidated, it’s mostly screenshots !

Docker Compose dependencies

The thing I find interesting about Docker Compose and Kubernetes is that they augment Docker by providing some pieces of functionality that are either not present or not as easily implemented with plain vanilla Docker. One of these pieces would be service dependencies, for example. With both Docker Compose and Kubernetes you can specify in their respective service manifests to only start Service A after Service B has started, helping prevent race conditions or having to write bash scripts with unreliable sleep commands, healthchecks, pings, etc.

# inside example docker-compose.ymlvarnish:
image: alexanderallen/varnish-6:alpine-3.12
- nginx

Coupled Varnish/Nginx instances using decoupled service names

When starting Varnish, the -b parameter specifies which backend Varnish pulls its data from.

-F -s malloc,32M -a :80 -b nginx:8080
-F -s malloc,32M -a :80 -b

Using PHP-FPM and NGINX Container Pairs

I run a separate NGINX container for each PHP application in my machine, because it has simplified things on the DevOps side for me, locally speaking.

Namespacing resources in Docker (such as volumes)

Scaling Containers Using Service Aliases

Here is a heroic screenshot of my Varnish container attempting (and failing) to communicate with the NGINX container ona service callednginx:8080. The reason? Too many hostnames (containers) in the local Docker network have the name of nginx:

Like compose services, all Ricks are have the same name. How would you identify them? Credit: Adult Swim.

Giving Docker Compose services a network alias

To solve the problem of services with duplicate names on a shared network, you can provide each service with a unique alias. In my case, I opted to do so dynamically, using the $PROJECT_NAME variable. This variable contains the name of each application, and is unique as long as each application name is different.

Using unique service aliases with variables
Sharing external networks between services and applications
Fully updated example of using service aliases
If services where Rick and Morty…
Rick (Varnish) and Morty (Nginx) can finally talk to each other.
Docker Compose applications and w their respective service containers

Smoke Test

In the screenshot below you see TO THE LEFT

  • Dummy PHP application, served by nginx/1.19.6 (the NGINX container).
  • Serviced by PHP/7.3.22 in the background (the PHP-FPM container).
  • The Varnish HTTP headers:
  • X-VARNISH: 32782 and,
  • Via: 1.1 Varnish (Varnish 6.4).
Comparing regular NGINX versus Varnish response for Drupal install page.
  • Both the dummy and Drupal applications have different, distinct ports for both the NGINX and Varnish containers. These ports are not hardcoded, and automatically assigned by Docker Compose.
Retrieving ephemeral container ports
White glove service and luxurious DX: opening browser tabs for you !!

Conclusion: Some deep reflections of today’s cartoon analogy

If Nginx is the source of content, and Varnish the dependent — why would I consider Nginx to the the Rick of my analogy? Shouldn’t Morty be Varnish, dependant on Rick’s Nginx as a fountain of content and wisdom? Isn’t Rick after all the adult in the room?



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Callback Insanity

Organic, fair-sourced DevOps and Full-Stack things. This is a BYOB Establishment — Bring Your Own hipster Beard.