Improved: Baikal / SabreDAV Calendar in Less Than 10 Minutes
Releasing the original 10-minute guide to robust calendar deployment using Baikal / SabreDAV led to lots of interesting feedback. The main user comments centered about using a newer OS container foundation. The original Docker image was based on Ubuntu 14.04, and most newer servers are based on 16.04 LTS. This update presents how the pr3d4t0r/calendar image was updated to run on the latest Ubuntu Server with long term support.
Upgrading the Dockerfile base from Ubuntu 14.04 to 16.04
Ubuntu Server 16.04 changed how PHP is installed. First, it defaults to PHP NG instead of PHP 5.x. Second, prior distributions bundled the complete PHP core and most extensions package. The Dockerfile now performs explicit installation of such packages (e.g. PHP DOM).
The other important change was in forcing PHP to output errors to the /var/log/syslog for easier troubleshooting.
Summary of Dockerfile changes
FROM ubuntu:16.04
.
.
### "system-requirements"
RUN apt-get install apache2
RUN apt-get install curl
RUN apt-get install postfix
RUN apt-get install mailutils
RUN apt-get install rsyslog
RUN apt-get install sqlite3
RUN apt-get install php
RUN apt-get install libapache2-mod-php
RUN apt-get install php-date
RUN apt-get install php-dom
RUN apt-get install php-mbstring
RUN apt-get install php-sqlite3
RUN apt-get install unzip
.
.
# In the Apache 2 server config section:
RUN echo "error_log = syslog" >> /etc/php/7.0/apache2/php.ini
.
.
Summary of bin/runapache2 changes
The bin/runapache2 script launches the web server as a foreground application and acts as the container's execution entry point. It required only two changes:
Use the Apache 2 run-time environment variables from /etc/apache2/envvars (the previous version declared them in the script)
Explicit creation of the lock and run directories
#!/bin/bash
hostname calendar.example.org
domainname example.org
source /etc/apache2/envvars
mkdir -p "$APACHE_LOCK_DIR"
mkdir -p "$APACHE_RUN_DIR"
service rsyslog start
service postfix start
/usr/sbin/apache2 -DFOREGROUND
The latest, complete version of the package is available from GitHub under pr3d4t0r/calendar.
Why Ubuntu Server instead of Alpine?
Using the smallest container possible is considered a Docker best practice. Alpine is the smallest distribution basic Docker image; it weighs 2 MB against 180 MB of the basic Ubuntu image. So, why use the Ubuntu image?
The main reasons: familiarity and availability.
- The Advanced Package Tool (apt) and dpkg are more pervasive than Alpine's apk package tools. More sysadmins and developers are familiar with apt and dpkg.
- Not all Baïkal users will have access to a dockerized system, but most will have access to a stand alone machine. The Dockerfile acts as a step-by-step Baïkal deployment HOWTO, or the Dockerfile can be converted into a one-pass shell script that performs all the installation steps.
Where is the pr3d4t0r/calendar ready-to-run Docker image?
There's no pr3d4t0r/calendar Baïkal image in Docker Hub yet because a few issues need to be addressed before making it available for public consumption:
- The host and domain names should be passed to the calendar container when it starts; they are indispensable for the correct Postfix and web server configuration and right now they're coded in to the Dockerfile.
- A public pr3d4t0r/calendar image would work best with a Docker volume container for data storage, including disaster recovery, backup procedures, and data management; for now it uses a directory in the host mapped to a virtual volume.
- Optional support for Let's Encrypt in the image so that the Baïkal server does its own SSL termination; the current image assumes a data center approach of separating the application (Baïkal) from SSL termination (firewall, reverse proxy, gateway, etc.). Best SysOp practices suggest keeping them separate, but practicality of deploying the Baïkal server in a single image would offer tremendous value for small shops and start ups.
- Remove Postfix from the pr3d4t0r/calendar image; this requires code changes in Baïkal to use Swift Mailer instead of the PHP mail() function, plus a mechanism for passing the MX server or relay configuration to the container over environment variables (similar to 1).
The SabreDAV team and pr3d4t0r are working toward sorting out the best solutions to these issues.
A 100% stand alone pr3d4t0r/calendar Baïkal image will be available at the end of Q3 via Docker Hub.
Questions or comments?
Do you want to customize this Calendar Service? Fork the project on GitHub!
Contact me on @ciurana or follow my tech page on Facebook.