FixMyStreet with Docker
You can use Docker and Docker Compose to get up and running quickly with FixMyStreet.
This is just one of many ways to install FixMyStreet.
Public images
As well as providing a Dockerfile
which you could use as the basis of your own
customised build, we provide public images on Docker Hub
with a full FixMyStreet installation for each of our tagged releases.
Docker Compose
If you have Docker and Docker Compose installed, then the following should set up a working FixMyStreet installation, with containers for the application, database, memcached and webserver:
docker-compose up
You can then layer your own cobrand-specific code on top, update the configuration, or log in and make changes.
A superuser is automatically created, with email superuser@example.org
and password given in docker-compose.yml
.
This basic installation uses the default cobrand, with a (deliberately) rather garish colour scheme.
Adding your own cobrand
If you want to map your own cobrand data into the Docker container, have a repository/directory that contains the following (all items optional):
my-cobrand-repo/
templates/web/(cobrand)/
templates/email/(cobrand)/
perllib/FixMyStreet/Cobrand/(CoBrand.pm)
web/cobrands/(cobrand)/
Create a docker-compose.override.yml file in the root of the fixmystreet repository (alongside docker-compose.yml) containing:
version: '3'
services:
fixmystreet:
volumes:
- /path/to/your/general.yml:/var/www/fixmystreet/fixmystreet/conf/general.yml
- /path/to/my-cobrand-repo:/var/www/fixmystreet/cobrand
Now if you run docker-compose up
it should automatically include that cobrand
within the running container.
This is a new facility, so please do feed back your thoughts.
Database configuration
The example Docker Compose environment includes a slightly customised Postgres container
based on the official image and localised for en_GB
.
This will be configured the first time it is started and its data stored in a
Docker volume for persistence. The password for the postgres
user should be set
in the POSTGRES_PASSWORD
environment variable and made available to both the
database and application containers; along with the various FMS_DB_*
environment
variables this will be used to ensure the correct users, permissions and databases
are created when the container starts for the first time.
Using an external database
If you wish to host the database in an external service you can do so by updating
the various FMS_DB_*
environment variables used by the application container and
in general.yml
. You should not provide a POSTGRES_PASSWORD
variable to the
application container in this case.
The application container will attempt to create the database if it doesn’t already exist, so
you can either provide the user with the CREATEDB
privilege or simply provide
an empty database and the application container will load the schema when it starts
for the first time.
Installation complete… now customise
You should then proceed to customise your installation.