eKeeper Docker Images
TAR files (.tar) contain the docker images for the various containers.
Use docker to load the required image(s), e.g.:
$ docker load -i ekeeper-mysqld.tar $ docker load -i ekeeper-wellesley.dev.tar
The provided images include a MySQL 5.6 database server (there is a compatibility problem with
version 5.7). In the future this could be split into
development and live versions, with different optimisation and debug options specified in
/etc/my.cnf. But for now there is only a single image.
There are also images for the MortgageKeeper and Wellesley web sites. These should contain the
correct Apache configuration for those sites, along with any site-specific
The web sites come in two varieties: live and dev. The live variety contains its own set of
appropriate Subversion repository.
The development containers map host directories to the container's document root so that
developers can edit application files directly on their local PC. Developers will have to specify
the location of their files in Composer (see below).
The development containers are also set up for debugging with Xdebug. I have this working in
PhpStorm and the Xdebug Chrome App, but not Eclipse. I assume the configuration is okay in
The MortgageKeeper-XXX/ and Wellesley-XXX/ directories contain Docker Composer YAML files (.yml).
These are used to run multi-container Docker applications. The applications here comprise a simple
Apache 2.4 web server with PHP 5.6 and a database server with MySQL 5.6.
To run the application, do
$ docker-compose -f Wellesley-dev/docker-compose.dev.yml up -d
The containers in each Composer application operate together and are unable to see other containers.
This way multiple web servers and multiple database servers can run on a single host machine.
The development Composer files (
.../XXXX-dev/docker-compose.yml) map a directory on the host
system to the container's document root (or similar). Developers will need to edit this to ensure
that the correct directory on their local disk is mapped to the container's file system.
The database containers use a Docker-managed volume to store the database files. This volume is
specific to the Composer application. Its data is persistent across invokations of the Composer
application, and can be backed up as and when needed. On first run the MySQL container will
initialise an empty database, this will need to be populated with application data.
For example, to populate the MySQL databases do:
$ docker exec -it wellesley_dev-database_1 \ mysql -uroot -pXXXXXXXX -e 'CREATE DATABASE wellesleyv5data CHARSET=utf8;' $ zcat Wellesley090216.sql.gz | docker exec -it wellesley_dev-database_1 \ mysql -uroot -pXXXXXXXX wellesleyv5data
To backup to a local .sql.gz file, do
$ docker exec -it wellesley_dev-database_1 \ mysqldump -uroot -pXXXXXXXX wellesleyv5data | gzip > backup.sql.gz
The root password for the database images has been randomly set as 3k43ghj3j3. Setting database
specific usernames and passwords is done in the original Dockerfile for the image, or in the running
container itself using standard MySQL commands.
Developers will likely keep their own site-specific Composer files as these are mostly tailored
to local configuration, e.g. development files in particular directories, or sites on particular
port numbers. But, as and when server configurations change or software is upgraded etc. it will
be possible to distribute new image files (the .tar files) to developers. On receipt of a new image
the developer will shut down their Composer applicaton:
$ docker-compose -f Wellesley/docker-compose.dev.yml down
delete the old image:
$ docker rmi ekeeper/wellesley:dev
load the new image:
$ docker load -i ekeeper-wellesley.dev.tar
and restart the application:
$ docker-compose -f Wellesley/docker-compose.dev.yml up -d
Distribution can also be achieved with a company Docker Trusted Registry. This would allow
images to be uploaded to the registry with
docker push and then downloaded with
docker pull. The
Docker Trusted Registry costs money to run, but might be worth it eventually.