docker-canvas aims to provide a simple, disposable, containerized Canvas instance for fast(ish) integration testing of LTI applications.
docker run --name canvas-docker -p 3000:3000 -d lbjay/canvas-docker
This repo is registered at Docker Hub as an automated build. So you should also be able to docker pull lbjay/canvas-docker
to get the pre-built image.
docker build -t canvas-docker .
docker run -t -i -p 3000:3000 --name canvas-docker canvas-docker
canvas@example.edu
/ canvas-docker
.The Dockerfile
and associated build scripts create a resulting docker image where all necessary services of the Canvas instance are run within a single container. This approach is sometimes called a "fat" container. This admittedly goes against the "Docker Philosophy" of one concern per container, but for the intended purposes of the image it offers a couple of advantages, chief among them, faster spin-up times. The functionality focus is on creating a tool for integration testing of external (LTI) apps, not general canvas development, scalability, or, god forbid, actual deployment.
The image build includes the injection of default developer_key
and access_token
entries into the database.
API requests should be possible, e.g.,
curl -H "Authorization: Bearer canvas-docker" http://localhost:3000/api/v1/courses
The developer key is for use with Canvas's OAuth2 Token Request Flow. For example, if you're making use of harvard-dce/django-canvas-api-token.
By default the instance's outgoing email delivery_method
will be set to "test", meaning outgoing emails, such as user registration messages, will be
sent to the container's stdout.
To configure 'smtp' delivery set the following $ENV values at runtime:
Example using Mandrill:
docker run -d --name=canvas -p 3000:3000 -e EMAIL_DELIVERY_METHOD=smtp -e SMTP_ADDRESS=smtp.mandrillapp.com -e SMTP_PORT=587 -e SMTP_USER=<mandrill_user> -e SMTP_PASS=<mandrill_api_key> lbjay/canvas-docker
RAILS_ENV=development
. At some point I might try creating a separate "production" flavor, but, because docker doesn't allow the setting of build-time variables except in the Dockerfile
, it would require a separate Dockerfile
. Also, when I did try building with RAILS_ENV=production
, the resulting instance had issues with routing errors to the compiled assets, and the db:initial_setup
rake task threw lots of warnings about missing triggers (?). So that.Dockerfile
build process mostly follows Canvas's Quick Start guidelines with a few exeptions:
RAILS_ENV=development
delated_job
background task is executedApache 2.0
2016 President and Fellows of Harvard College