Use fig or equivalent to deploy lensing

[anoopsarkar]

We should consider using Fig + Docker to deploy lensing as a replacement to the now increasingly complex website.md file

More about Fig

This is related to issue #125

[theq629]

That's probably a good idea. The original use of makefiles was to avoid software we weren't familiar with, but I think we're definitely past the point where it still makes sense.

[anoopsarkar]

@vlad003 what do you think about this issue?

[avacariu]

I think Docker could be a good idea if we want to be deploying multiple versions of the site on one server. I'll take a look at it tonight and I'll post a more comprehensive response (I want to make sure that this wouldn't end up being more complicated).

Aside: Looks like Fig is deprecated and replaced by Docker Compose.

[avacariu]

Do we want separate containers for each component of the site, or do we want to put them all together into one container? I think having the entire site in one container would be a good idea because then we wouldn't have to deal with which frontend connects to which backend.

We would then be able to deploy multiple copies of the site, each one with its own database, frontend and query backend.

[anoopsarkar]

Using Docker Compose is the way to go. We should close this issue and open a new one.

Would a single container mean that we could do the domain "localization" as part of the container: so each domain (e.g. wikipedia, aviation) would contain its own app.py and necessary links to the right domain files.

[avacariu]

What I was thinking was:

One container per domain

• inside the container you put Apache + virtualhost (for frontend), and query backend with all the config files set for a specific domain + local settings.

Multiple containers

• One container for each query backend (for each domain + local settings we have)
• One container for each frontend (for each domain + local settings we have)

I have no idea which method would be easier to manage. If the tooling around Docker is really good, they could be equivalent.

[anoopsarkar]

If you can play around with it, see which one is easier to deploy and configure. We'll go with that.

[avacariu]

I've read over the Docker and Compose documentation, and I've decided on the following approach:

1. I'll start by writing a Dockerfile for the "one container per domain" approach. This'll replace website.md, and will confirm that everything works fine within a container (I want to see how the programs handle different host kernels, since you can use CentOS images on a Ubuntu host and vice versa).
2. I'll split the Dockerfile into multiple components, one for each part of the site. Once the initial Dockerfile is working properly, this should be pretty straightforward. We can use Docker Compose to manage these.

I'm working on step 1 right now.

It looks like it's a good idea to use Docker Compose since some people are suggesting to use a dedicated container to handle all the persistent data (and getting all other containers to access the data volumes through that one container). I'm still trying to figure out what best practices are for this.