hughbris / cadaver

Docker image build files for running Grav CMS under Caddy webserver

Cadaver

Run Grav CMS under Caddy webserver in a docker container.

Usage

Sourcing the docker image

This image is currently available from Github's container repository only. It's not hosted on Dockerhub, because I dislike it and also because someone squatted on my username :/

Pull or use the image from its canonical URL:

$ docker pull ghcr.io/hughbris/cadaver

Building the docker image

If you need to build the image locally, maybe for your own special flavour, first clone this repo.

In the repo directory, use this command to build your image. The image name parameter given after -t is not fixed since it's not official, so go ahead and use whatever target image name you prefer.

$ docker build -t local/my-docker-grav-caddy .

There's a good chance that you don't want cached copies of the layers making up the target image you are building. To override docker build's default behaviour of caching image layers, use this intuitive incantation:

$ docker build --no-cache --pull -t local/my-docker-grav-caddy .

(thanks to user @m-dk on stackoverflow.com for guidance; another obscure DX delivered by dockercorp engineers)

This will use more bandwidth and may not be what you want this time.

You can change the PHP base image from its default now, using the build-time argument base_image, e.g.

$ docker build --build-arg base_image=php:7.4-fpm-alpine -t local/my-docker-grav-caddy:php7.4 .

Note

As of 0.2.4.1, the default base_image value is php:8.2-fpm-alpine.

Using docker-compose

My compose file looks something like this, tweak as needed:

version: "3.3"

services:

   grav:
        image: ghcr.io/hughbris/cadaver
        container_name: grav-caddy
        domainname: local
        hostname: grav-caddy
        restart: unless-stopped
        ports:
            - 127.0.0.1:2015:2015
        volumes:
            - /var/data/containers/caddytest/backup:/var/www/grav/backup
            - /var/data/containers/caddytest/logs:/var/www/grav/logs
            - /var/data/containers/caddytest/user:/var/www/grav/user
            - /etc/timezone:/etc/timezone:ro
            - /etc/localtime:/etc/localtime:ro
        environment:
            - PUID=1000
            - PGID=1000
            - ACME_AGREE=true
            # - GRAV_SCHEDULER=true # defaults to false currently
            # - ROBOTS_DISALLOW=true # defaults to false, set true for staging environments etc, see extras/robots.disallow.txt for more discussion; set to "AI_BOTS" to block only AI content harvesters, see extras/robots.ai-bots.txt for details
            # - GRAV_MULTISITE=dir # yet to be implemented

Caveats

Cron and Grav's scheduler are enabled using the GRAV_SCHEDULER environment setting. I'm sensing from my research that cron within service containers is unreliable and not recommended / best practice.

Credits

I started this project trying to marry concepts and techniques found in dsavell/docker-grav and seffyroff/caddy-grav-alpine.

cadaver's Issues

Support or document how to execute Grav's cron-based scheduler

Grav has its own handy job scheduler which requires the OS's cron. It's not considered good practice in Docker to run a cron service inside an application container. This makes the scheduler difficult to support, but the documentation should suggest ways to add support for it that the application container can use.

Setting file permissions fails for filenames with spaces

I noticed in some logs after a recent install of a site with existing content (user populated) that there were some errors from chmod and it looks like it couldn't set permissions for files that had spaces in their names.

This looks like a problem where xargs is treating every space piped to it from find as a new file to be chmoded. Indeed, that's what I'm seeing from a quick search and the solution seems to be to add a flag to change xargs's delimiter. Hopefully it's that simple, need to test.

Permission scripting in init script unsets githook executable bits

When there are githooks under .git/hooks/, execute bits are reset by the permission setting part of init/init/grav.

Add multisite capability

Mainly the subdirectory version, which is already added commented out.

Very little incentive to implement the subdomain version, since I tend to expose containers via reverse proxy.

Add xdebug support

I have never used Xdebug, don't even know how to capitalise it. Would be handy in development environments I'm sure.

I've looked at how to install this. The blocker is how to manage this variant in the docker image, as a tag I guess. Might require a build script to manage option permutations. Look at similar images for implementation clues.

Change the name

• think of a better name
• investigate and manage any unintended consequences of name change
• make change

Innocent as I am, I've picked up only lately that this repo might be unfortunately named. Wanted: something unique-ish integrating the qualities of grav + docker + caddy.

Since the tagged images are being used by at least one person, find out what, if any, redirects Github/GHCR puts in place. Do the best I can to minimise the impacts.

Add simple robots.txt option for discouraging AI bots

Thanks to them having a feed and me starting to rediscover feedreaders, Ars Technica have alerted me that it's now possible to block ChatGPT using robots.txt.

Given how important this is to many site owners, add an option to put this directive into a robots.txt file published from a container instance. I already have ROBOTS_DISALLOW, a simple boolean. Need to keep supporting this, while extending it for cases like this. I think there is a danger that the number of possible commonly sought-after boilerplate robots.txt files could extend beyond what will scale. For now, I think provide a small number of them and also provide instructions on how to do this by simply bind mounting a custom robots file.

The directive for ChatGPT API bots is:

User-agent: GPTBot
Disallow: /

I can see this needing to be extended. To future-proof, file should be named generically like ai-bots or similar.

Investigate alternate php-fpm base images

https://serversideup.net/open-source/docker-php/ is just good enough at selling its benefits that I am wondering if I'm using the best base image provider.

Update: I'm having trouble setting up a working Caddy server using the S6 overlay framework that this image uses now.

Upgrade to PHP8

It's happening ready or not