sclorg / varnish-container

Varnish HTTP Cache container images based on Red Hat Software Collections and intended for OpenShift and general usage. Users can choose between Red Hat Enterprise Linux, Fedora, and CentOS based images.

Varnish HTTP accelerator container images

Images available on Quay are:

• CentOS Stream 9 varnish-6
• Fedora varnish-7

This repository contains Dockerfiles for Varnish HTTP accelerator images. Users can choose between RHEL, CentOS, CentOS Stream 8, CentOS Stream 9 and Fedora based images.

Versions

Varnish versions currently provided are:

• varnish-6
• varnish-7

RHEL versions currently supported are:

• RHEL8
• RHEL9

CentOS versions currently supported are:

• CentOS Stream 9

For more information about contributing, see the Contribution Guidelines. For more information about concepts used in these container images, see the Landing page.

Installation

To build a Varnish image, choose either the CentOS or RHEL based image:

• RHEL based image

  These images are available in the Red Hat Container Catalog. To download it run:

  $ podman pull registry.redhat.io/rhel8/varnish-6
  

  To build a RHEL based Varnish image, you need to run the build on a properly subscribed RHEL machine.

  $ git clone --recursive https://github.com/sclorg/varnish-container.git
  $ cd varnish-container
  $ git submodule update --init
  $ make build TARGET=rhel8 VERSIONS=6
  

• CentOS Stream based image

  This image is available on Quay.io. To download it run:

  $ podman pull quay.io/sclorg/varnish-6-c9s
  

  To build a CentOS Varnish image from scratch run:

  $ git clone --recursive https://github.com/sclorg/varnish-container.git
  $ cd varnish-container
  $ git submodule update --init
  $ make build TARGET=c9s VERSIONS=6
  
  

• Fedora based image

  You need to build the Fedora variant locally:

  $ git clone --recursive https://github.com/sclorg/varnish-container.git
  $ cd varnish-container
  $ git submodule update --init
  $ make build TARGET=fedora VERSIONS=7
  

Note: while the installation steps are calling podman, you can replace any such calls by docker with the same arguments.

Notice: By omitting the VERSIONS parameter, the build/test action will be performed on all provided versions of Varnish.

Contributing

In this repository distgen is used for generating image source files. If you'd like update a Dockerfile, please make changes in specs/multispec.yml and/or Dockerfile.template (or other distgen file) and run make generate.

Usage

For information about usage of Dockerfile for Varnish 6, see usage documentation.

For information about usage of Dockerfile for Varnish 7, see usage documentation.

Test

This repository also provides a S2I test framework, which launches tests to check functionality of a simple Varnish application built on top of the Varnish image.

Users can choose between testing a Varnish test application based on a RHEL or CentOS image.

• RHEL based image

  To test a RHEL8 based Varnish image, you need to run the test on a properly subscribed RHEL machine.

  $ cd varnish-container
  $ git submodule update --init
  $ make test TARGET=rhel8 VERSIONS=6
  

• CentOS Stream based image

   $ cd varnish-container
   $ git submodule update --init
   $ make test TARGET=c9s VERSIONS=6
  

• Fedora based image

  $ cd varnish-container
  $ git submodule update --init
  $ make test TARGET=fedora VERSIONS=7
  

Notice: By omitting the VERSIONS parameter, the build/test action will be performed on all provided versions of Varnish.

varnish-container's Issues

registry.centos.org/centos/vernish-4:centos7 build is broken

build for centos/vernish-4:centos7 is broken since last few days. it is failing in the step 8.

Step 8 : COPY 4/s2i/bin/ $STI_SCRIPTS_PATH
lstat 4/s2i/bin/: no such file or directory

it seems there is a symbolic link, which is not getting resolved.

lrwxrwxrwx 1 bamachrn bamachrn    7 Jan 31 18:42 s2i -> ../s2i/

build log: https://registry.centos.org/pipeline-logs/OWQzNTNhMzUxZW/build_logs.txt
This is getting built based on this entry in container-index

Configuration files should support parsing of environment variables

Because OpenShift is extremely environment variable reliant, it would be ideal if we could add a simple process in the run script that would parse the configuration files for environment variables. This would allow for users to define environment variables for things like backend host and port, but could also be extended even further.

test suite fails with "/bin/sh: line 0: exec: gcc: not found"

More debug output (using bash -x):

[INFO] Waiting for application container to start...

+ '[' 1 -le 10 ']'
+ '[' -f /tmp/tmp.ttESA7zcbi.cid ']'
+ attempt=2
+ sleep 1
+ run_test_application
+ run_args=
+ docker run --user=100001 --cidfile=/tmp/tmp.ttESA7zcbi.cid centos/varnish-4-centos7-testapp
+ source /opt/app-root/etc/generate_container_user
++ PASSWD_DIR=/opt/app-root/etc
+++ id -u
++ export USER_ID=100001
++ USER_ID=100001
+++ id -g
++ export GROUP_ID=0
++ GROUP_ID=0
++ envsubst
++ export LD_PRELOAD=libnss_wrapper.so
++ LD_PRELOAD=libnss_wrapper.so
++ export NSS_WRAPPER_PASSWD=/opt/app-root/etc/passwd
++ NSS_WRAPPER_PASSWD=/opt/app-root/etc/passwd
++ export NSS_WRAPPER_GROUP=/etc/group
++ NSS_WRAPPER_GROUP=/etc/group
+ set -e
+ . /etc/opt/rh/rh-varnish4/varnish/varnish.params
++ RELOAD_VCL=1
++ VARNISH_VCL_CONF=/etc/opt/rh/rh-varnish4/varnish/default.vcl
++ VARNISH_LISTEN_PORT=6081
++ VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
++ VARNISH_ADMIN_LISTEN_PORT=6082
++ VARNISH_SECRET_FILE=/etc/opt/rh/rh-varnish4/varnish/secret
++ VARNISH_STORAGE=file,/var/opt/rh/rh-varnish4/lib/rh-varnish4-varnish/varnish_storage.bin,1G
++ VARNISH_TTL=120
++ VARNISH_USER=varnish
++ VARNISH_GROUP=varnish
+ exec varnishd -F -f /etc/opt/rh/rh-varnish4/varnish/default.vcl -a :8080,:8443 -T 127.0.0.1:8081 -t 120 -u default -g root -S /etc/opt/rh/rh-varnish4/varnish/secret -s file,/var/opt/rh/rh-varnish4/lib/rh-varnish4-varnish/varnish_storage.bin,1G
Message from VCC-compiler:
Not running as root, no priv-sep
Message from C-compiler:
Not running as root, no priv-sep
/bin/sh: line 0: exec: gcc: not found
Running C-compiler failed, exited with 127

VCL compilation failed
+ '[' 2 -le 10 ']'
+ '[' -f /tmp/tmp.ttESA7zcbi.cid ']'
+ '[' -s /tmp/tmp.ttESA7zcbi.cid ']'
+ break
+ test_scl_usage 'varnishd -V' varnish-4
+ local 'run_cmd=varnishd -V'
+ local expected=varnish-4
+ info 'Testing the image SCL enable'
+ echo -e '\n\e[1m[INFO] Testing the image SCL enable...\e[0m\n'

ct_cleanup deletes more files it should

After varnish test/run finishes files in / are removed. Looks that CID_FILE_DIR is empty or unset and for cid_file in "$CID_FILE_DIR"/* iterates over files in /.

See https://github.com/sclorg/container-common-scripts/blob/master/test-lib.sh#L35

Send varnishncsa output to stdout

It would be ideal to send varnishncsa output to stdout so it gets logged appropriately and shows up in a normal apache format for parsing using Kibana (or Splunk).

Add imagestream for varnish

I expect it'll look similar to nginx one.

Varnish 5 missing README.MD

New version is missing README.md and as a result of this help.1 cannot be generated and the build of the image fails if only version 5 is built.

Connected bug to this is that the generated help.1 file gets created inside root/ to which symlinks are pointing from versioned directories. This causes the help.1 file to be generated only once, for the first version. So even with a separate README.md for version 5 only 4's help file would be used.

Fedora image out of date, centos container running deprecated versions

The Fedora image is 35, which is EOL. The varnish in the centos8 and centos9 containers is out of date:
quay.io/sclorg/varnish-6-c8s is using varnish 6.0.8-1 (which most likely is missing security updates).
quay.io/sclorg/varnish-6-c9s uses varnish-6.6.2-3 which is deprecated (not being LTS).

Is there intention on updating it?

Add support for extending image and enabling SSL connections

The image should be generally flexible, which means it should be easy to extend the functionality of the image by end users. A common thing that the end users need to change is providing own configuration file or setting up secured connection over SSL.

In some cases, users prefer to extend the image by creating a thin layer on top of the provided image and have the own bits available in the image itself. However, it is also common to use kubernetes secrets to extend the image functionality, by providing a configuration file or pair of SSL certificates.

In some cases, making the image flexible required to refactor the image a bit more; there are PRs for other images, that already support these features below, they could serve for inspiration. An important part of the changes is also documentation how the extending works, what paths should be used, etc.

nginx: sclorg/nginx-container#41 (especially interesting from varnish PoV, since the changes might be quite similar)
httpd: sclorg/httpd-container#28
php: sclorg/s2i-php-container#183
mariadb: sclorg/mariadb-container#45
mysql: sclorg/mysql-container#201
postgresql: sclorg/postgresql-container#208
mongodb: sclorg/mongodb-container#239

Can't run since is giving permission denied error

Here's what I tried till now:

1. Running the example instructed in the docs just adding

# s2i build https://github.com/sclorg/varnish-container.git --context-dir=4/test/test-app/ registry.access.redhat.com/rhscl/varnish-4-rhel7 sample-server
# docker run -p 8080:8080 sample-server
Message from VCC-compiler:
Not running as root, no priv-sep
Message from C-compiler:
Not running as root, no priv-sep
Message from dlopen:
Not running as root, no priv-sep
Mmap error _.vsm.1: Permission denied

2. Tried to build it using a different default.vcl but the result is the same error.

I'm doing something wrong? or this images doesn't work?

Any help would be appreciated, thanks.

README.md in 4 directory is taken from nginx

We need to provide better documentation for this image in 4/README.md.

Assemble process should be cleaner

Instead of copying all the files, we should follow what https://github.com/sclorg/s2i-php-container/blob/master/7.0/s2i/bin/assemble does, which is:

shopt -s dotglob
echo "---> Installing application source..."
mv /tmp/src/* ./

This prevents moving the .git directory with it.

In addition, I'm not sure I see a need to cat the default.vcl file on each build. What is the use besides the occasional debugging?