Add a Docker compose file

[jackleland]

Adds a docker compose file which can be used for easily getting up and running with a local dev environment, addressing #121 (partially) and #194. Moves database migration to the entrypoint script so that a working database is not required at build-time.

Also adds material-pulling into the Dockerfile with controllable behaviour via the MATERIAL_METHOD build-arg, either:

• "copy" in a local folder, specified by MATERIAL_DIR
• "pull" the repo described in a local config yaml file, specified by YAML_TEMPLATE The pull option is the default, and uses the recently added python script functionality.

Note that the local .material is mounted in at run time, but doesn't seem to get updated with the cron job.

Works as-is but could probably be improved in a few ways:

1. An additional Dockerfile/option to use yarn dev to cut down on build iteration time (maybe dev-dynamic-compose.yml)
2. Split the material pulling stuff into a separate image
3. Get the mounted material directory to be refreshed from by the cronjob
4. Use the test material repo set up for #189
5. Implement a production version with NGINX and qdrant

[mjaquiery]

@jackleland the multiple different client containers is a really smart and inventive solution. Nice one.

[jackleland]

@alasdairwilson I can add a bash script in addition to these changes if you'd prefer people had the option?

[jackleland]

It looks like changing files in the .material directory forces the build to not use the cache, so no need for --no-cache. Also the image looks to be about 2.5GB (when pulling as opposed to copying) compared to 2.3 previously.

[alasdairwilson]

It looks like changing files in the .material directory forces the build to not use the cache, so no need for --no-cache. Also the image looks to be about 2.5GB (when pulling as opposed to copying) compared to 2.3 previously.

Size difference is minimal then, though yeuch at the size of the container in the first place.

The bigger worry for the --no-cache was that if you update the material repo (the github) then it wont run the pull step so the .material folder will be unchanged (and it will cache right past it).

[alasdairwilson]

Although having said that...perhaps it is fine that you only initially deploy with this and that if we have the cronjob + add the nextjs timeout then your material will update at midnight anyway (could make this more frequent)

[jackleland]

Ahh I see your point, there are definitely ways around this via cache busting though. I'll work up an example in a sec

[jackleland]

So I've added a cache-bust but there doesn't seem to be a way to set an environment variable dynamically with docker-compose (that I've found anyhow), so I included a bash script to do it automatically i.e. there's still a single command to get from a fresh clone to a running gutenberg.

Also added a 'production' compose file with nginx and qdrant included, but I haven't tested this very thoroughly - at this point it's more a starting point than an actual deployment option.

Let me know thoughts