docker-canvas aims to provide a simple, disposable, containerized Canvas instance for fast(ish) integration testing of LTI applications.
- docker (developed & tested w/ v1.12.1)
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.
- Clone this repo somewhere.
- Build the image:
docker build -t canvas-docker .
- Start the container:
docker run -t -i -p 3000:3000 --name canvas-docker canvas-docker
- Point your browser to http://localhost:3000. The admin user/pass login is
The "fat" container
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.
Default developer_key & API access token
The image build includes the injection of default
access_token entries into the database.
- developer key: test_developer_key
- access token: canvas-docker
API requests should be possible, e.g.,
curl -H "Authorization: Bearer canvas-docker" http://localhost:3000/api/v1/courses
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:
- EMAIL_DELIVERY_METHOD (set this to "smtp")
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
- The resulting canvas image is built and run using
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_setuprake task threw lots of warnings about missing triggers (?). So that.
- Everything is currently somewhat "opinionated" in that things that would be nice to have configurable are hard-coded, e.g., postgres and canvas usernames, postgres network settings, path to the postgres data, etc.
Dockerfilebuild process mostly follows Canvas's Quick Start guidelines with a few exeptions:
- as mentioned above,
- redis is installed, configured and used
delated_jobbackground task is executed
- postgres is configured to not require a password for local connections, or for connections originating within a network defined by Docker's default network bridge setup: 172.17.0.0/16.
- as mentioned above,
- Jay Luker - lbjay
2016 President and Fellows of Harvard College