SearchThis tutorial shows how to get started with Varnish Plus docker images.
A container is a standard unit of software that contains an application and all its dependencies so the application can run reliably when moved from one environment to another. An application that runs on your machine, e.g, a laptop isn’t guaranteed to run on your colleague’s machine because the environments are different. This is where containers are useful as they provide an isolated environment in where the application runs. The containers are hosted and managed by the container runtime.
In Dockerland, there are images and containers. An image is immutable file that is essentially a snapshot of a container. If you run an image it will become a container. Simply put, an image serves as a template for a container. Varnish Enterprise images are Docker images so you will need to install Docker Engine as your container runtime.
Supported docker image distribution:
The Varnish Enterprise docker images are built on top of Debian 11.0 (bullseye) slim version and supports Busybox utility commands. Looking for another platform?
Before you can start this tutorial, you should have:
When using docker images supplied form Varnish Software, the images are supplied for your convenience. This means that it is each customer’s responsibility to decide if the image as supplied is sufficient for their needs, both when it comes to tools available inside the docker containers, and the quality of security updates for software not licensed directly from Varnish Software.
Of course, maintaining your own Docker images will be less convenient but give you full control over updates and tools in the images.
Read the section How are the Docker images built and maintained?" near the bottom of this document to learn what Varnish Software does to keep the Docker images up to date and secure.
Contact sales@varnish-software.com if you have problems with your credentials or need to have new ones.
To be able to download Docker images from the Varnish Software Docker registry, you will need to login first. Use your USERNAME and TOKEN which is a hashcode that serves the role of a password.
docker login -u="$USERNAME" -p="$TOKEN" quay.io
All images can be pulled from the registry using:
docker pull quay.io/varnish-software/$IMAGE_NAME[:$TAG]
Tags can be the version number and also “latest”. If you don’t specify a tag, it will default to “latest”. If the docker pull command is issued with the “latest” tag, it will pull the latest version of the image that is defined in $IMAGE_NAME.
Examples:
Images available are:
Varnish Plus:
Controller:
See Controller container documentation for more details.
The Dockerfile sample below PULLs the latest image and updates both: VARNISH_LISTEN_PORT and MSE_MEMORY_TARGET defaults. The same logic can be applied to all exposed ENV parameters.
FROM quay.io/varnish-software/varnish-plus:latest
ENV VARNISH_LISTEN_PORT "8080"
ENV MSE_MEMORY_TARGET "512m"
EXPOSE $VARNISH_LISTEN_PORT
Varnish official images provide an entrypoint script which will automatically start the Varnish processes with parameters that are defined by the ENV variables.
ENV VARNISH_LISTEN_PORT "80"
ENV VARNISH_ADMIN_LISTEN_PORT "6082"
ENV VARNISH_VCL_CONF "/etc/varnish/default.vcl"
ENV VARNISH_SECRET_FILE "/etc/varnish/secret"
ENV VARNISH_MIN_THREADS "50"
ENV VARNISH_MAX_THREADS "1000"
ENV VARNISH_THREAD_TIMEOUT "120"
ENV VARNISH_TTL "120"
ENV MSE_MEMORY_TARGET "256m"
ENV MSE_CONFIG "/etc/varnish/mse.conf"
ENV VARNISH_LISTEN_ADDRESS ""
ENV VARNISH_TLS_CFG ""
ENV VARNISH_EXTRA ""
VARNISH_LISTEN_PORT it is the port Varnish will be exposedVARNISH_SECRET_FILE will be created if it does not exist as VARNISH_SECRET_FILE (/etc/varnish/secret)MSE_CONFIG will be used if the provided path is pointing to a file.VARNISH_TLS_CFG if it is set, Varnish in-core TLS will be enabled. If VARNISH_TLS_CFG is a file then that file will be used. If it is not a file, TLS configuration file will be generated and used.VARNISH_EXTRA is just added to the end of all command line (-p) parameters to varnishd.ENV VARNISH_BROADCASTER_HOST "0.0.0.0"
ENV VARNISH_BROADCASTER_CFG "/etc/varnish/nodes.conf"
ENV VARNISH_BROADCASTER_PORT "8088"
ENV VARNISH_BROADCASTER_MGMT_PORT "8089"
ENV VARNISH_BROADCASTER_TTL "10m0s"
ENV VARNISH_BROADCASTER_PID "/tmp/broadcaster.pid"
ENV VARNISH_BROADCASTER_LOG "INFO"
ENV VARNISH_BROADCASTER_EXTRA ""
VARNISH_BROADCASTER_HOST sets the broadcaster’s running host (listen-address).VARNISH_BROADCASTER_CFG is the path to a file where the broadcaster writes the nodes to broadcast against.VARNISH_BROADCASTER_PORT is the port under which the broadcaster is exposed.VARNISH_BROADCASTER_MGMT_PORT listening port for the broadcaster’s management.VARNISH_BROADCASTER_LOG sets log verbosity options (debug, info, warning, error, quiet).VARNISH_BROADCASTER_EXTRA is just added to the end of all command line parameters to the broadcaster.ENV VARNISH_DISCOVERY_FLAGS "dns --group example.com --nodefile /etc/varnish/nodes.conf"
VARNISH_DISCOVERY_FLAGS will start varnish-discovery with a default option and then it can be changed according to the discovery service flag options (e.g., DNS, AWS, VAC, K8S, etc…).Varnish docker images come with a default vcl file. But, we recommend you to use your own custom.vcl file so that you can benefit from the full caching power of Varnish.
# PULLING VARNISH-PLUS IMAGE
FROM quay.io/varnish-software/varnish-plus:latest
# DEFINING ENV VARIABLES
ENV VARNISH_LISTEN_PORT "80"
ENV VARNISH_ADMIN_LISTEN_PORT "6082"
ENV VARNISH_VCL_CONF "/etc/varnish/default.vcl"
ENV VARNISH_SECRET_FILE "/etc/varnish/secret"
ENV VARNISH_MIN_THREADS "50"
ENV VARNISH_MAX_THREADS "1000"
ENV VARNISH_THREAD_TIMEOUT "120"
ENV VARNISH_TTL "120"
ENV MSE_MEMCACHE_TARGET "256m"
ENV MSE_CONFIG "/etc/varnish/mse.conf"
ENV VARNISH_LISTEN_ADDRESS ""
ENV VARNISH_TLS_CFG ""
ENV VARNISH_EXTRA ""
# COPY YOUR CUSTOM VCL TO THE SAME PATH AS VARNISH_VCL_CONF
COPY custom.vcl /etc/varnish/default.vcl
EXPOSE $VARNISH_LISTEN_PORT
After preparing the Dockerfile and the custom.vcl file, you can then build docker image with custom tag.
docker build -t "CUSTOM_TAG" .
When the image is done building, you should be able to see the newly built image.
docker image ls
Now our docker image is ready to be run as a container. Remember that we exposed the varnish listening port with EXPOSE $VARNISH_LISTEN_PORT in our Dockerfile. This will allow the container to talk to other containers. But to be able to reach the container processes from the outside, the container port needs to be mapped to the machine’s port numbers. This can be done with the -p parameter. Assuming that Varnish port is 6081, we can forward localhost port 80 to port 6081 inside the container when we run docker container using our newly built docker image.
docker run -p 80:6081 "CUSTOM_TAG"
Now we can check how well Varnish is running.
curl localhost:80
docker image inspect quay.io/varnish-software/varnish-plus:latest | jq .[0].Config.Env
Output Example:
[
"VARNISH_LISTEN_ADDRESS=",
"VARNISH_LISTEN_PORT=6081",
"VARNISH_VCL_CONF=/etc/varnish/default.vcl",
"VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1",
"VARNISH_ADMIN_LISTEN_PORT=6082",
"VARNISH_TTL=120",
"VARNISH_MIN_THREADS=50",
"VARNISH_MAX_THREADS=1000",
"VARNISH_THREAD_TIMEOUT=120",
"VARNISH_SECRET_FILE=/etc/varnish/secret",
"MSE_MEMORY_TARGET=80%",
"MSE_CONFIG=/etc/varnish/mse.conf",
"VARNISH_TLS_CFG=",
"VARNISH_EXTRA="
]
Run Varnish Enterprise with defaults.
docker run -it --rm -d -p 6081:6081 --name varnish quay.io/varnish-software/varnish-plus:latest
With the above command, we started running the container as a daemon (-d) and published port 6081 on the host network.
We also named the container web using the --name option.
This will run with the default VCL and may not be what we want so let’s stop it and supply a custom VCL.
docker stop varnish
Let’s create a custom VCL to use with our container, lets place it in /tmp/my.vcl
vcl 4.1;
backend default none;
sub vcl_recv {
if (req.url == "/ping") {
return(synth(200, "pong"));
}
}
docker run -it --rm -p 6081:6081 --name varnish -v /tmp/my.vcl:/etc/varnish/default.vcl quay.io/varnish-software/varnish-plus:latest
__ __ _ _ ____ _
\ \ / /_ _ _ __ _ __ (_)___| |__ | _ \| |_ _ ___
\ \ / / _' | '__| '_ \| / __| '_ \ | |_) | | | | / __|
\ V / (_| | | | | | | \__ \ | | | | __/| | |_| \__ \
\_/ \__,_|_| |_| |_|_|___/_| |_| |_| |_|\__,_|___/
www.varnish-software.com
varnishd (varnish-plus-6.0.9r4 revision 89b7b028f75a0cb5ceb3f58c78d909081f60f6ff)
Generating new secrets file: /etc/varnish/secret
Opening environment 'mse'
Environment 'mse' opened successfully
Debug: Version: varnish-plus-6.0.9r4 revision 89b7b028f75a0cb5ceb3f58c78d909081f60f6ff
Debug: Platform: Linux,5.10.76-linuxkit,x86_64,-jnone,-smse,-hcritbit
Debug: Child (27) Started
Info: Child (27) said Child starts
Info: Child (27) said Environment mse fully populated in 0.00 seconds. (0.00 0.00 0.00 0 0 0/4 0 0 0 0)
Let us check the if the configuration is loaded.
$ curl localhost:6081/ping
<!DOCTYPE html>
<html>
<head>
<title>200 pong</title>
</head>
<body>
<h1>Error 200 pong</h1>
<p>pong</p>
<h3>Guru Meditation:</h3>
<p>XID: 2</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
In this example we will create a docker-compose.yml config
specifying two containers echoserver and varnish the echoserver is just a small web server that will echo back everything sent to it and we use it as our varnish backend.
First we create a minimal docker-compose.yml file:
---
version: "3"
services:
echoserver:
image: jmalloc/echo-server
environment:
- LOG_HTTP_HEADERS=1
expose:
- "8080"
varnish:
image: "quay.io/varnish-software/varnish-plus:latest"
volumes:
- ./custom.vcl:/etc/custom.vcl
ports:
- "8081:6081"
environment:
- VARNISH_VCL_CONF=/etc/custom.vcl
- MSE_MEMORY_TARGET=50%
It will start a backend server on port 8080 and a Varnish externally accessible on port 8081, we are also adding a custom.vcl and mount it as /etc/custom.vcl in the container, as it is not in the default path
we supply VARNISH_VCL_CONF environment variable with the path to our custom vcl and finally we tell The MSE Memory Governor that we want at maximum 50% of available memory used for cache.
Our custom.vcl looks like this and should be in the same directory as the docker-compose.yml configuration file:
vcl 4.1;
backend default {
.host = "echoserver";
.port = "8080";
}
sub vcl_recv {
set req.http.x-varnish-added-this = "yes";
}
Start the containers with docker-compose up
Attaching to docker-for-docs_varnish_1, docker-for-docs_echoserver_1
varnish_1 | __ __ _ _ ____ _
varnish_1 | \ \ / /_ _ _ __ _ __ (_)___| |__ | _ \| |_ _ ___
varnish_1 | \ \ / / _' | '__| '_ \| / __| '_ \ | |_) | | | | / __|
varnish_1 | \ V / (_| | | | | | | \__ \ | | | | __/| | |_| \__ \
varnish_1 | \_/ \__,_|_| |_| |_|_|___/_| |_| |_| |_|\__,_|___/
varnish_1 |
varnish_1 | www.varnish-software.com
varnish_1 |
echoserver_1 | Echo server listening on port 8080.
...
To test we can do a couple of curl commands, as we are running a echo
server we will see the added header in the output:
$ curl http://localhost:8081
Request served by 131dbbf0f6ca
HTTP/1.1 GET /
Host: localhost:8081
User-Agent: curl/7.68.0
Accept: */*
X-Forwarded-For: 172.22.0.1
X-Varnish-Added-This: yes
Accept-Encoding: gzip
X-Varnish: 3
The following Dockerfiles will let you build your custom Varnish docker images. You can use them out of box as these Dockerfiles are ready-to-use.
FROM ubuntu:20.04
# Packages in our repositories are signed and distributed via HTTPS.
# You need to enable HTTPS support in the package manager and install our public key before installing the packages
RUN sudo apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://$TOKEN:@packagecloud.io/varnishplus/60/gpgkey | sudo apt-key add -
RUN sudo echo "machine packagecloud.io/varnishplus/60" > /etc/apt/auth.conf
RUN sudo echo "login $TOKEN" >> /etc/apt/auth.conf
# Make sure auth.conf is not world readable:
RUN sudo chown root:root /etc/apt/auth.conf
RUN sudo chmod 600 /etc/apt/auth.conf
RUN sudo echo "deb https://packagecloud.io/varnishplus/60/ubuntu/ focal main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN sudo apt-get update
# Install Varnish-plus
RUN sudo apt-get install varnish-plus
FROM ubuntu:18.04
RUN sudo apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://$TOKEN:@packagecloud.io/varnishplus/60/gpgkey | sudo apt-key add -
RUN sudo echo "machine packagecloud.io/varnishplus/60" > /etc/apt/auth.conf
RUN sudo echo "login $TOKEN" >> /etc/apt/auth.conf
# Make sure auth.conf is not world readable:
RUN sudo chown root:root /etc/apt/auth.conf
RUN sudo chmod 600 /etc/apt/auth.conf
RUN sudo echo "deb https://packagecloud.io/varnishplus/60/ubuntu/ bionic main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN sudo apt-get update
# Install Varnish-plus
RUN sudo apt-get install varnish-plus
FROM ubuntu:16.04
RUN sudo apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://$TOKEN:@packagecloud.io/varnishplus/60/gpgkey | sudo apt-key add -
RUN sudo echo "deb https://$TOKEN:@packagecloud.io/varnishplus/60/ubuntu/ xenial main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
RUN sudo echo "deb-src https://$TOKEN:@packagecloud.io/varnishplus/60/ubuntu/ xenial main" >> /etc/apt/sources.list.d/varnish-6.0-plus.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN sudo apt-get update
# Install Varnish-plus
RUN sudo apt-get install varnish-plus
FROM debian:buster
RUN sudo apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://$TOKEN:@packagecloud.io/varnishplus/60/gpgkey | sudo apt-key add -
RUN sudo echo "machine packagecloud.io/varnishplus/60" > /etc/apt/auth.conf
RUN sudo echo "login $TOKEN" >> /etc/apt/auth.conf
# Make sure auth.conf is not world readable:
RUN sudo chown root:root /etc/apt/auth.conf
RUN sudo chmod 600 /etc/apt/auth.conf
RUN sudo echo "deb https://packagecloud.io/varnishplus/60/debian/ buster main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN sudo apt-get update
# Install Varnish-plus
RUN sudo apt-get install varnish-plus
FROM debian:stretch
RUN sudo apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://$TOKEN:@packagecloud.io/varnishplus/60/gpgkey | sudo apt-key add -
RUN sudo echo "deb https://$TOKEN:@packagecloud.io/varnishplus/60/debian/ stretch main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
RUN sudo echo "deb-src https://$TOKEN:@packagecloud.io/varnishplus/60/debian/ stretch main" >> /etc/apt/sources.list.d/varnish-6.0-plus.list
# Note: This is required for brotli support.
RUN sudo echo "deb http://deb.debian.org/debian stretch-backports main" >> /etc/apt/sources.list.d/sources.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN sudo apt-get update
# Install Varnish-plus
RUN sudo apt-get install varnish-plus
As we are phasing out the VAC in favor of the Varnish Controller, there is no varnish-agent docker image. But it is not difficult to create your own docker image which contains varnish-agent. The following example will show you how to run Varnish agent as a sidecar to Varnish.
Varnish agent needs to read the Varnish secret file to authenticate itself to Varnish, or slightly different implementation would be that containers of these two processes needs to have same secret file. However, in the official varnish plus docker image the secret file is generated every time a container is started, meaning that two containers of exact same image will have different secret files. Therefore, we need to put our secret file in our custom built docker images to ensure varnish secret file will be the same for varnish-plus container and varnish-agent container. For this purpose we can use RUN echo "varnish-secret" > /etc/varnish/secret command to create a secret file.
This Dockerfile will build docker image that has varnish-agent installed and it contains the varnish secret file.
FROM quay.io/varnish-software/varnish-plus:latest
USER root
RUN apt-get update
RUN apt-get install -y apt-transport-https curl gnupg
RUN curl -L https://packagecloud_key:@packagecloud.io/varnishplus/60/gpgkey | apt-key add -
RUN echo "machine packagecloud.io/varnishplus/60" > /etc/apt/auth.conf
RUN echo "login packagecloud_key" >> /etc/apt/auth.conf
# Make sure auth.conf is not world readable:
RUN chown root:root /etc/apt/auth.conf
RUN chmod 600 /etc/apt/auth.conf
RUN echo "deb https://packagecloud.io/varnishplus/60/debian/ buster main" > /etc/apt/sources.list.d/varnish-6.0-plus.list
# Run apt-get update to update repository metadata and follow the product installation instructions
RUN apt-get update
# Install Varnish-plus
RUN apt-get install varnish-agent
RUN echo "varnish-secret" > /etc/varnish/secret
USER varnish
Now we will set up varnish-agent that connects to varnish with the following docker-compose.yaml file. This is where Dockerfile above comes handy. Please make sure that docker-compose.yaml file and Dockerfile are in the same directory.
version: "3"
services:
varnishd:
build: .
hostname: varnish
restart: unless-stopped
ports:
- "80:8080"
environment:
VARNISH_LISTEN_PORT: "8080"
VARNISH_ADMIN_LISTEN_PORT: "6082"
volumes:
- varnish-var:/var/lib/varnish:rw
varnishncsa:
image: "quay.io/varnish-software/varnish-plus:latest"
hostname: varnish
restart: unless-stopped
entrypoint: ["/usr/bin/varnishncsa", "-a", "-w", "/etc/varnish/varnishncsa.log"]
volumes:
- varnish-var:/var/lib/varnish:ro
depends_on:
- varnishd
varnish-agent:
build: .
restart: unless-stopped
entrypoint: ["/usr/bin/varnish-agent", "-T", "varnishd:6082"]
ports:
- "6085:6085"
volumes:
varnish-var:
driver: local
driver_opts:
type: tmpfs
device: tmpfs
version: "3"
services:
varnishd:
image: "quay.io/varnish-software/varnish-plus:latest"
hostname: varnish
restart: unless-stopped
ports:
- "80:8080"
environment:
VARNISH_LISTEN_PORT: "8080"
volumes:
- varnish-var:/var/lib/varnish:rw
varnishncsa:
image: "quay.io/varnish-software/varnish-plus:latest"
hostname: varnish
restart: unless-stopped
entrypoint: ["/usr/bin/varnishncsa", "-a", "-w", "/etc/varnish/varnishncsa.log"]
volumes:
- varnish-var:/var/lib/varnish:ro
depends_on:
- varnishd
volumes:
varnish-var:
driver: local
driver_opts:
type: tmpfs
device: tmpfs
There are two ways to configure in-core TLS for docker containers. You can use an autogenerated self-signed certificate or you can provide your own TLS configuration file.
If VARNISH_TLS_CFG is set and is not a file, the TLS configuration file which contains a self-signed certificate will be automatically generated when the varnish process starts.
version: "3"
services:
varnishd:
image: "quay.io/varnish-software/varnish-plus:latest"
hostname: varnish
restart: unless-stopped
ports:
- "80:6443"
environment:
VARNISH_LISTEN_PORT: "6443"
VARNISH_TLS_CFG: "/"
volumes:
- /path/to/default.vcl:/etc/varnish/default.vcl
VARNISH_TLS_CFG should be configured to TLS configuration file as it is stated in the In-Process TLS documentation.
version: "3"
services:
varnishd:
image: "quay.io/varnish-software/varnish-plus:latest"
hostname: varnish
restart: unless-stopped
ports:
- "80:6443"
environment:
VARNISH_LISTEN_PORT: "6443"
VARNISH_TLS_CFG: "/etc/varnish/tls.conf"
volumes:
- /path/to/default.vcl:/etc/varnish/default.vcl
- /path/to/tls.conf:/etc/varnish/tls.conf
If you see the following warning in the varnish controller agent’s log, it indicates that the controller agent can’t read VSM (Varnish Shared Memory). The controller agent uses varnishstat to fetch statistics from VSM which is located under /var/lib/varnish/$directory. The $directory part of this path depends on the varnish hostname, or if you configured the varnish name using the -n option, $directory is the same as the varnish name.
WARNING [YY-MM-DD HH:MM:SS.XXXXXX] failed to fetch statistics, exit status 1
For the varnish controller agent to be able to find VSM, VARNISH_CONTROLLER_VARNISH_NAME needs to be the same as the varnish name. If you haven’t configured the varnish name, it is most likely that $directory is the same as the varnish hostname.
Furthermore, when the specified name (-n parameter) begins with a forward slash, it is interpreted as the absolute path to the directory and VSM will be created under this absolute path. In this case, we can configure VARNISH_CONTROLLER_VARNISH_NAME as the absolute path to the directory where the VSM exists and varnish controller agent will be able to find VSM.
This section is a description on how we create and maintain Docker images supplied to customers. Even though Varnish Software is applying what we consider best practices for running software in Docker, it is up to each user to decide if this is good enough, or if a custom image is necessary.
It is possible to extract the exact Dockerfile behind our images, like this:
docker docker run -v /var/run/docker.sock:/var/run/docker.sock mrhavens/dedockify <docker-image-id>
Like in the examples above, each Dockerfile starts off with a base image, updates the software database, installs the necessary packagecloud repository and then the software. Then variables with a default configuration is set up. The following shows one example, our Varnish Cache Plus image:
FROM debian:bullseye-slim
ARG version
ENV VARNISH_LISTEN_ADDRESS ""
ENV VARNISH_LISTEN_PORT "6081"
ENV VARNISH_VCL_CONF "/etc/varnish/default.vcl"
ENV VARNISH_ADMIN_LISTEN_ADDRESS "127.0.0.1"
ENV VARNISH_ADMIN_LISTEN_PORT "6082"
ENV VARNISH_TTL "120"
ENV VARNISH_MIN_THREADS "50"
ENV VARNISH_MAX_THREADS "1000"
ENV VARNISH_THREAD_TIMEOUT "120"
ENV VARNISH_SECRET_FILE "/etc/varnish/secret"
ENV MSE_MEMORY_TARGET "80%"
ENV MSE_CONFIG "/etc/varnish/mse.conf"
ENV VARNISH_TLS_CFG ""
ENV VARNISH_EXTRA ""
RUN --mount=type=secret,id=auth_conf,dst=/etc/apt/auth.conf cat /etc/apt/auth.conf && \
apt-get update && \
apt-get -y upgrade && \
apt-get install -y --no-install-recommends ca-certificates apt-transport-https curl gnupg uuid-runtime busybox && \
groupadd -r varnish && \
useradd -r -s /bin/false -g varnish varnish && \
curl -L -s https://$(tail -n1 /etc/apt/auth.conf|tr -d 'login '):@packagecloud.io/varnishplus/60/gpgkey | apt-key add - && \
echo "deb https://packagecloud.io/varnishplus/60/debian/ bullseye main" > /etc/apt/sources.list.d/varnish-enterprise-60.list && \
apt-get update && \
# Install Varnish
apt-get install -y --no-install-recommends varnish-plus=${version}* varnish-plus-vmods-extra=${version}* varnish-plus-ha=${version}* && \
apt-get install -y jq && \
mkdir -p /var/lib/mse && \
chown -R varnish:varnish /var/lib/varnish /var/lib/mse && \
chown varnish:varnish /etc/varnish && \
# Cleanup
apt-get purge -y --auto-remove -o APT::AutoRemove::RecommendsImportant=false gnupg && \
rm -fr /root/.gnupg && \
rm -rf /var/lib/apt/lists/* && \
rm -f /etc/varnish/secret && \
rm -fr /var/lib/varnish/* && \
rm -f /etc/apt/sources.list.d/varnish-enterprise-60.list
COPY entrypoint.sh /entrypoint.sh
USER varnish
WORKDIR /etc/varnish
EXPOSE $VARNISH_LISTEN_PORT
ENTRYPOINT ["/entrypoint.sh"]
When the Docker image is built, we use publicly available tools (https://trivy.dev/) to scan the images.
Then, for each vulnerability or bug detected in the image, the build system checks the existence of updates fixing them in the upstream software repository (Debian). If an update was not applied to the image, the process stops, and our engineers will be notified to resolve the situation and make sure updates are applied.
The docker images are built automatically once a day, making sure that fixes are applied within 24 hours. The maintenance of the images is straightforward and limited to functional updates (e.g. when changes to the software necessitates additional parameters) or updates to the base images.
Please note that vulnerability scanners will report all possible vulnerabilities in any part of the software in the images, a large majority of the reported issues do not apply to the software as configured in the Dockerfile. There are several reasons for this:
VCL resources: