Docker image for Radicale calendar and contact server, +security +addons
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci WIP testing circleci for work Sep 24, 2018
.gitignore Initial tests for the docker image Aug 21, 2018
.travis.yml fix: ignore preinstalled python deps Feb 8, 2019
Dockerfile fix: handle cffi install failure Dec 20, 2018
LICENSE Create LICENSE Dec 2, 2018
Pipfile chore: switch to pipenv Sep 10, 2018
Pipfile.lock fix: handle cffi install failure Dec 20, 2018
README.md
build.sh Upgrade to alpine 3.8 Aug 19, 2018
config refactor: move config/config to root Sep 18, 2018
docker-compose.yml Adding a Docker compose file Nov 6, 2017
docker-entrypoint.sh feat: make config only readable Sep 18, 2018
logo.png doc: add logo Sep 19, 2018
test_image.py feat: make config only readable Sep 18, 2018

README.md

Logo

Docker-Radicale

Build Status Docker Build Status GitHub tag Pulls Stars Automated build

Enhanced Docker image for Radicale, the CalDAV/CardDAV server.

Features

  • 🔐 Secured: run as a normal user, not root
  • Enhanced: add Git for versioning, Bcrypt for authentication and InfCloud as an alternative UI
  • 🏗 Multi-architecture: run on amd64, arm (RaspberryPI...) and others

Version, Tags and Multi-architecture

Latest tag: latest tag

Version number = Architecture + '.' + Radicale version + '.' + increment number

Example: those tags were created for Radicale 2.1.10:

  • tomsquest/docker-radicale:i386.2.1.10.0
  • tomsquest/docker-radicale:amd64.2.1.10.0
  • tomsquest/docker-radicale:arm.2.1.10.0
  • tomsquest/docker-radicale:aarch64.2.1.10.0

The last number is ours, incremented on changes. For example, 2.1.10.2 made the /config readonly (this is specific to this image).

Additionally, Docker Hub automatically build and publish this image as tomsquest/docker-radicale (which by default is amd64).

Running

Minimal instruction:

docker run -d --name radicale \
    -p 5232:5232 \
    tomsquest/docker-radicale

Production-grade run:

docker run -d --name radicale \
    -p 127.0.0.1:5232:5232 \
    --read-only \
    --init \
    --pids-limit 50 \
    --security-opt="no-new-privileges:true" \
    --health-cmd="curl --fail http://localhost:5232 || exit 1" \
    --health-interval=30s \
    --health-retries=3 \
    -v ~/radicale/data:/data \
    -v ~/radicale/config:/config:ro \
    tomsquest/docker-radicale

Docker compose

A Docker compose file is included. It can be extended.

Custom User/Group ID for the data volume

You will certainly mount a volume to keep Radicale data between restart/upgrade of the container. But sharing files from the host and the container can be problematic. The reason is that radicale user in the container does not match the user running the container on the host.

To solve this, this image offers four options (see below for details):

  • Option 0. Do nothing, permission will be fixed by the container itself
  • Option 1. Create a user/group with id 2999 on the host
  • Option 2. Specify a custom user/group id on docker run
  • Option 3. Build the image with a custom user/group

Option 0. Do nothing, the container will fix the permission itself

When running the container with a /data volume (eg. -v /mydata/radicale:/data), the container entrypoint will automatically fix the permissions on /data.

This option is OK but not optimal:

  • Ok for the container, as inside it the radicale user can read and write its data
  • But on the host, the data directory will then be owned by the user/group 2999:2999

Option 1. User/Group 2999 on the host

The image creates a user and a group with Id 2999.
You can create an user/group on your host matching this Id.

Example:

sudo addgroup --gid 2999 radicale
sudo adduser --gid 2999 --uid 2999 --shell /bin/false --disabled-password --no-create-home radicale

Option 2. Custom User/Group at run

The user and group Ids used in the image can be overridden when the container is run.
This is done with the UID and GID env variables, eg. docker run -e UID=123 -e GID=456 ....

But beware, the --read-only run flag cannot be used in this case. Using custom UID/GID tries to modify the filesystem at runtime but this is made impossible by the --read-only flag.

Option 3. Custom User/Group at build

You can build the image with custom user and group Ids and still use the --read-only flag.
But, you will have to clone this repo, do a local build and keep up with changes of this image.

Usage: docker build --build-arg=UID=5000 --build-arg=GID=5001 ...

Custom configuration

To customize Radicale configuration, either:

  • Recommended: use this repository preconfigured config file,
  • Use the original config file and:
    1. set hosts = 0.0.0.0:5232
    2. set filesystem_folder = /data/collections

Then mount your custom config volume when running the container: -v /my_custom_config_directory:/config.

Contributing

To run the tests (your user will need to be a member of the docker group)

  1. pip install pipenv
  2. pipenv install -d
  3. pytest -v

Releasing

Create a Git tag, eg. 2.1.10.0, push it and Travis will build the images and publish them on Docker hub.

Contributors