Introduction

Varnish Controller’s main function is to manage a cluster of Varnish servers. Some new concepts have been introduced to create a system that’s both generic and highly flexible. Though all communication with the system is conducted using a REST API, an easy-to-use Command Line Interface (CLI) is provided.

Building blocks

Varnish Controller consists of three main parts:

The Agent interacts with the Varnish process and is responsible for VCL deployments.
The Brainz process handles all system-wide decision-making.
The API-GW (API Gateway) serves a REST API to control the system.

These services can be scaled horizontally by adding more processes of the same kind.

The fourth component called Router (Varnish Traffic Router) is used to route traffic to the most appropriate Varnish server based on different configurable decisions, using either HTTP302 or DNS.

Communication

A vital part of these processes is interprocess communication. This is performed over NATS; a lightweight, high-performance messaging service. NATS is a free, third-party, open-source software. Communication over NATS can be encrypted - see the installation guide.

Varnish integration

A Varnish instance handled by Varnish Controller shouldn’t be manually modified when it comes to loading VCLs. The agent takes control of the Varnish instance and removes any loaded label/VCL that isn’t related to what’s deployed within Varnish Controller. All VCL changes must be made exclusively from the Varnish Controller API/CLI. Since agents handle the deployments to Varnish servers, this document refers to both servers and agents, interchangeably.