Canvas LMS Development setup issue for Linux/Mac too difficult

[MuhmdRaouf]

Summary:

We are going to start a project using Canvas LMS, and we are currently in the phase where we are setting up the project for the team, some of us have Mac and some Linux and some Windows too, my question is why do we need DNS server like dory or VM like dinghy for MacOS, what is the benefits of them, as we could just contain each part in specific docker images then connect them together through a docker-compose network, what might be different if I use localhost:3000 instead of using docker.canvas and saved a lot of hassle, as right now the script doesn't work as expected all the time, also sometimes it works on Mac but not on Linux and vice versa, I wanted to create separate docker images for the project as eg. (ruby's, postgres's, cassandra's, and redis's images) then use docker-compose to connect them together, and use the args in docker-compose to specify as the current environment is production or development, use the env vars to specify the database name, username, and password and so on.

I am asking as I might missing something, big project like this must take that approach for a reason, after all, so I wanted to understand why as the docs doesn't explain why.

Steps to reproduce:

1. using stable branch first time.
2. using master branch a second time

Expected behavior:

1. worked on macOS doesn't work on Linux due build problems, or dory DNS fails and I need do dory up periodically.
2. worked on Linux doesn't work on macOS due build problems, or specific images we don't have permission to access it, or some unknown hard to debug error or problems with dinghy VM as it already exists, or can't find config.json file, and cant just reuse the existing VM.

Actual behavior:

Build the project and make it up and running ready for development.

[grahamb]

This isn't a bug; these questions are better suited to either the Canvas developers Google Group or the IRC channel, but since you're already here…

There is nothing stopping you from either a) running Canvas bare-metal on your machine and accessing localhost:3000, or b) doing your own docker-compose setup and avoiding dinghy or dory.

Re: why you need dinghy on macOS: strictly-speaking, you don't. Dinghy is from a time before the official Docker for Mac, which still runs a linux VM (because Docker is really just an implementation of Linux namespaces with some tooling surrounding it); you can't run Docker "base-metal" on Mac or Windows. Dinghy is a set of tools that handles setting up Docker Machine (e.g. downloading and setting up the Boot2Docker VM on your hypervisor platform of choice), and provides both a NFS server for mounting directories from your host machine inside the B2D VM, a nginx proxy and a DNS server, so you can easily host multiple compose projects without having to worry about port numbers or conflicts (e.g. you can run your canvas compose stack at http://canvas.docker, and some other project at http://your-other-project.docker). It also makes it easy to provide TLS certificates, so you can serve your compose stack over HTTPS, which can be important for some applications (e.g. testing LTIs).

Dory is a similar project for Linux, without the Boot2Docker bit.

As for why, well, it's because that's how Instructure devs prefer to work. You're free to do whatever you like. FWIW, I've used the Dinghy setup for years (as a non-Instructure person) and have had zero real problems with it. I've since moved to using a Linux VM as my main dev environment and built a similar setup (not using dory, because I can have real DNS for my VM) using nginx-proxy/nginx-proxy, nginx-proxy/docker-letsencrypt-nginx-proxy-companion, and some custom tooling that talks to my employer's DNS servers to manage DNS entries.