Skip to content

A tool that multiplexes HTTP PURGE requests for standalone Varnish pods/instances. Varnish instances may be in Kubernetes or outside of Kubernetes.

License

Notifications You must be signed in to change notification settings

bilalcaliskan/varnish-cache-invalidator

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Varnish Cache Invalidator

CI Docker pulls Go Report Card Quality Gate Status Reliability Rating Maintainability Rating Security Rating Coverage Release Go version License

This tool basically multiplexes PURGE requests on Varnish Cache instances at the same time to manage the cache properly. If you are using Varnish Enterprise, you already have that feature.

varnish-cache-invalidator can be used for standalone Varnish instances or Varnish pods inside a Kubernetes cluster.

Standalone mode In that mode, varnish-cache-invalidator multiplexes requests on static standalone Varnish instances which are provided with --targetHosts flag. This flag gets comma seperated list of hosts.

Please check all the command line arguments on Configuration section. Required args for standalone mode:

--inCluster=false
--targetHosts

Kubernetes mode In that mode, varnish-cache-invalidator discovers kube-apiserver for running Varnish pods inside Kubernetes and multiplexes PURGE requests on them at the same time to manage the cache properly.

Please check all the command line arguments on Configuration section. Required args for Kubernetes mode:

--inCluster=true

Installation

Kubernetes

varnish-cache invalidator requires Kustomize for in-kubernetes installations. You can refer here for Kustomize installation.

If you run below command in the deployment directory, it will take following actions:

  • Deploy varnish-cache-invalidator in the default namespace
  • Deploy varnish instance with sample default.vcl for testing purposes in the default namespace
  • Deploy nginx instance for testing purposes in the default namespace

Here is the command:

$ kustomize build . | kubectl apply -f -

After all of the deployments are succeeded, when you make a GET request to the varnish instance with proper header, you will get following response. Notice X-Cache and X-Cache-Hits response headers. This indicates that our requests are successfully hitting the varnish:

$ curl ${WORKER_NODE_IP}:${VARNISH_NODE_PORT} -H "Host: nginx.default.svc" -v
... omitted
Age: 22
X-Cache: HIT
X-Cache-Hits: 12
... omitted

And yes, you can deploy each component separately to the Kubernetes with previous command on relevant directory. For example if you just want to deploy varnish-cache-invalidator, run below command in deployment/invalidator directory:

$ kustomize build . | kubectl apply -f -

Standalone

You can use binary method to manage standalone Varnish instances, not in Kubernetes. Binary can be downloaded from Releases page.

After then, you can simply run binary by providing required command line arguments:

$ ./varnish-cache-invalidator --inCluster=false --targetHosts 10.0.0.100:6081,10.0.0.101:6081,10.0.0.102:6081

Configuration

Varnish-cache-invalidator can be customized with several command line arguments. You can check sample in-Kubernetes deployment file for how it goes. Here is the list of arguments you can pass:

--inCluster                 bool        InCluster is the boolean flag if varnish-cache-invalidator is running inside cluster or not,
                                        defaults to true
--varnishNamespace          string      VarnishNamespace is the namespace of the target Varnish pods, defaults to default namespace
--varnishLabel              string      VarnishLabel is the label to select proper Varnish pods, defaults to app=varnish
--targetHosts               string      TargetHosts used when our Varnish instances(comma seperated) are not running in Kubernetes as
                                        a pod, required for standalone Varnish instances, defaults to 'http://127.0.0.1:6081'
--serverPort                int         ServerPort is the web server port of the varnish-cache-invalidator, defaults to 3000
--metricsPort               int         MetricsPort is the port of the metrics server, defaults to 3001
--writeTimeoutSeconds       int         WriteTimeoutSeconds is the write timeout of the both web server and metrics server, defaults to 10
--readTimeoutSeconds        int         ReadTimeoutSeconds is the read timeout of the both web server and metrics server, defaults to 10

Examples

TBD

Development

This project requires below tools while developing:

After you installed pre-commit, simply run below command to prepare your development environment:

$ pre-commit install -c build/ci/.pre-commit-config.yaml

License

Apache License 2.0

How varnish-cache-invalidator handles authentication with kube-apiserver in Kubernetes mode?

varnish-cache-invalidator uses client-go to interact with kube-apiserver. client-go uses the service account token mounted inside the Pod at the /var/run/secrets/kubernetes.io/serviceaccount path while initializing the client.

If you have RBAC enabled on your cluster, when you followed the deployment steps on Kubernetes section, it will create required serviceaccount and clusterrolebinding and then use that serviceaccount to be used by our varnish-cache-invalidator pods.

If RBAC is not enabled on your cluster, please follow that documentation to enable it.

About

A tool that multiplexes HTTP PURGE requests for standalone Varnish pods/instances. Varnish instances may be in Kubernetes or outside of Kubernetes.

Topics

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Contributors 3

  •  
  •  
  •