Add a Docker compose file #215
Conversation
Adds a docker compose file which can be used for easily getting up and running with a dev environment. Adds material pulling into the Dockerfile with controllable behaviour via the MATERIAL_METHOD build-arg, either 'copy' in a local folder or pull the repo described in a local config yaml file. Also moves database migration to the entrypoint script so that a working database is not required at build-time.
|
@jackleland the multiple different client containers is a really smart and inventive solution. Nice one. |
|
@alasdairwilson I can add a bash script in addition to these changes if you'd prefer people had the option? |
|
It looks like changing files in the .material directory forces the build to not use the cache, so no need for |
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). |
|
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) |
|
Ahh I see your point, there are definitely ways around this via cache busting though. I'll work up an example in a sec |
Adds support for cache-busting the git-pull of the material repo, meaning that the pull section of the dockerfile will not be run from the cached layer if the CACHE_BUST environment variable is changed between calls to `docker build` or `docker-compose build`. So far there seems no way to dynamically set the environment variable from within the compose file, so a script is included to do this manually via export, equally a prepended env variable could be used when calling `docker-compose build` or `... up --build`.
|
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 |
There was a problem hiding this comment.
So apologies for hijacking this but I wanted to test it and ended up in a rabbit hole that ended in fixing a few critical issues: the main one being the mount of the external .material meant that it would never actually use any of the pulled material in the container and that the prisma commands were incorrect and the cache busting didn't work quite right.
I think the solution with the 3 material sources in the dockerfile is really clever, I think in retrospect the iffyness of the cachebusting meant we probably should have just gone with a simpler dockerfile and a python requirement on the build stage but I don't think it is enough better to be worth replacing it so I am happy as it is.
Thanks for the contribution 👍
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_METHODbuild-arg, either:"copy"in a local folder, specified byMATERIAL_DIR"pull"the repo described in a local config yaml file, specified byYAML_TEMPLATEThe pull option is the default, and uses the recently added python script functionality.
Note that the local
.materialis 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:
yarn devto cut down on build iteration time (maybedev-dynamic-compose.yml)