Standardize on Docker as the primary deployment option

@arikfr mentioned that he’d like to standardize on Docker as the primary deployment option. Supporting multiple options requires either spending already-stretched maintainer time keeping them updated, or letting them get outdated and having users complain. Similarly, having a single primarily deployment path means we need less documentation.

As part of this, what do you think about removing the following?

• Heroku procfiles.
• Vagrant box - I’m unsure whether this is still helpful for dev or not. It’s quick to rebuild the docker container, but it might be a pain to debug what’s happening inside the docker container, I’m not sure.
• Google Cloud Images
• AWS image
• Fabric script - this seems to do a fair bit, when all it should be handling is DB migrations. Could switch to using flask-alembic to handle migrations.

While removing options seems like it’d make it more difficult for users to get started, it’d actually make it less confusing because there’d be a single “officially-blessed” path for getting up and running.

[arikfr]

Just to clarify what I meant by standardizing on Docker for deployment: we will still have AWS/Google Cloud images, but they will use the Docker images, which will simplify their maintenance.

The cloud images had been a great help with adoption, and having just Docker images won’t serve the same audience. The Vagrant box is still used for development environments, and probably will only be replaced by Docker when Docker is more adopted (and has better support for OS/X).

The Fabric script is used to upgrade the cloud images.

I’m cool with dropping Procfile and Procfile.heroku as Heroku is not supported anymore (although I’m thinking of supporting it again).

So the path forward should be:

1. Finish the work on the [Ubuntu/docker deployment[(https://github.com/getredash/redash/tree/master/setup/ubuntu_docker).
2. Have clear instructions and script for upgrading a Docker based setup. It’s going to be similar to our current Fabric file, but simpler: stop containers -> grab latest -> run migrations (if needed) -> start containers.
3. Switch to creating cloud images with the Ubuntu/docker deployment script.

The upgrade process is the main reason I didn’t move forward with the Docker deployment yet. I didn’t have the time to invest in researching a good way to run the upgrade process with Docker images.

[arikfr]

I’ve been experimenting with using Docker Compose for running Redash as an alternative for our complicated images setup and it seems to work quite nicely.

If time allows, v4’s images will use Docker.