This dockerfile provides a ready-to-go Baikal server.
For more details, see ckulka/baikal-docker (GitHub).
I follow the same version naming scheme as Baikal themselves.
The following tags support multiple architectures, e.g. amd64, arm32v7 and arm64v8.
0.8.0,0.8.0-apache,apache,latest0.8.0-nginx,nginx
For earlier versions all the way back to version 0.2.7, please search in the tags tab. Version 0.4.5 and older are only available for amd64.
- Where to file issues: https://github.com/ckulka/baikal-docker/issues
- Supported architectures (more info):
amd64,arm32v7,arm64v8 - Image updates: PRs for ckulka/baikal-docker
- Source of this description: https://github.com/ckulka/baikal-docker
From sabre.io/baikal:
Baikal is a Cal and CardDAV server, based on sabre/dav, that includes an administrative interface for easy management.
For more information, read the main website at baikal-server.com.
Baikal is developed by Net Gusto and fruux.
The following command will start Baikal:
docker run --rm -it -p 80:80 ckulka/baikal:nginxAlternatively, use the provided examples/docker-compose.yaml from the Git repository:
docker-compose upYou can now open http://localhost or http://host-ip in your browser and use Baikal.
The image exposes the /var/www/baikal/Specific and /var/www/baikal/config folders, which contain the persistent data. These folders should be part of a regular backup.
If you want to use local folders instead of Docker volumes, see examples/docker-compose.localvolumes.yaml to avoid file permission issues.
Traefik is a modern HTTP reverse proxy that supports Docker + Let's Encrypt and manages its configuration automatically and dynamically.
An example for Docker Compose can be found at examples/docker-compose.ssl.yaml.
This is my recommended approach, as your other containers can easily be added and you don't have to actively manage your certificates, Traefik creates new ones & replaces them when needed. Furthermore, since the image is an official Docker image, you won't have to worry as much about getting updates from a third party - aka me.
I included an example Docker Compose file examples/docker-compose.ssl.yaml as a template.
For more details on the Traefik configuration, see Traefik's Docker and Traefik's Let's Encrypt docs.
If you want to use your own certificates, the recommended appraoch is to hide this container behind your own HTTPS proxy, e.g. with Traefik's Static Certificates or nginx.
This way your other containers can easily be added and since the images are either official Docker images, e.g. Traefik and nginx, or directly come from the maintainers, you won't have to worry as much about getting updates from a third party - aka me. Security is important for all our internet facing workloads and using the official images makes keeping us safer just that much easier.
Alternatively, if you're using the apache image variant, you can also mount your certificates into the container and expose the 443 port:
# The folder /etc/ssl/private/baikal contains the files baikal.public.pem and baikal.private.pem
docker run --rm -it -p 80:80 -p 443:443 -v /etc/ssl/private/baikal:/etc/ssl/private/:ro ckulka/baikal:apacheI also included the Docker Compose template examples/docker-compose.apache.yaml for this scenario.
To ensure Baikal is up after reboots, I also included a Systemd service template which relies on the Docker Compose file to start all containers. Before you use it, make sure that the working directory matches your server setup.
sudo curl -o /etc/systemd/system/baikal.service https://github.com/ckulka/baikal-docker/blob/master/baikal.service
# Adjust the WorkingDirectory variable
sudo systemctl enable baikal.serviceThis automatically starts the service whenever your server (re)boots.
I backup my persistent data to AWS S3.
Docker-compose file: examples/docker-compose.awss3.yaml
# Important: only start the baikal container
docker-compose up baikal
# On a regular basis, perform the backup
docker-compose run --rm backupThe ckulka/baikal images come in several flavors, each designed for a specific use case.
This is the defacto image, as follows the official guidelines the closest using Apache httpd.
With that being said, it's worth checking out the nginx variant as it requires fewer resources, e.g. memory, and is a lot smaller in size.
If you are unsure about what your needs are, you probably want to use this one though.
This image relies on Apache httpd and uses the official PHP image that's packaged with the Apache web server.
It also ships with HTTPS support and self-signed certificates, which can be replaced by user-provided certificates - for more details, see the SSL Certificates: Static Certificates section.
This image uses environment variables to set Apache's ServerName and ServerAlias directives to avoid Apache httpd's warnings in the logs.
The BAIKAL_SERVERNAME environment variable is used to set the global ServerName directive, e.g. dav.example.io. For more details, see Apache Core Features: ServerName Directive.
The BAIKAL_SERVERALIAS environment variable is used to set the ServerAlias directive of the VirtualHosts, e.g. dav.example.org dav.example.com. For more details, see Apache Core Features: ServerAlias Directive.
This image builds the master branch from the source repository ckulka/baikal-docker. Use at your own risk.
This image relies on nginx and uses the official nginx image.
Compared to the Apache variant, it is significantly smaller (less than half the size) and produces no warning messages out-of-the-box.