Add docker volume for solr index; modify static files volume

[dchiller]

This PR makes two changes to docker volumes:

1. It adds a docker volume that contains the solr index files. This allows us to persist the index between container builds, rather than re-indexing every time the container is built.
2. It reworks the static files volume that is used to share static files managed by django with the nginx container. Django-managed static files are now mapped to /code/static/django in the nginx container rather than /code/static. Node-managed static files are still mapped to /code/static. This means that any existing files in the volume persisted from build to build do no overwrite changes to static files introduced in a build of the nginx container. This fixes #841.

[ahankinson]

I know I’m probably sounding like a broken record, but why not ditch docker and install Solr directly. Then you wouldn’t need to worry about persisting the data across container rebuilds…

[dchiller]

I know I’m probably sounding like a broken record, but why not ditch docker and install Solr directly.

I don't feel like I can make this decision re: Cantus Ultimus. It was "dockerized" two summers ago (I wasn't really involved in the "why", just the implementation of this decision, but I think the rationale was that all the other DDML projects used it?).

I'm not entirely opposed to the idea, especially now that I am more ansible and poetry comfortable, but yeah, doesn't feel like a decision I can take on my own.

The one thing that I still like about docker is that in development it separates some of the services that I use across projects: eg. I am literally running separate postgres and solr instances for Cantus Ultimus and CantusDB. Of course, I could run the same server locally and just have different databases and different cores, but there is something that feels nice about being able to tear down (for example) my postgres installation for Cantus Ultimus without affecting simultaneous work with CantusDB. I guess I could use a single docker container for development, but deploy directly to the vm (sans Docker). How do you think about this?

[fujinaga]

I’ll see Andrew this weekend in Halifax so he can convince me in person.

On Apr 3, 2024, at 11:00 AM, Dylan Hillerbrand @.***> wrote:

I know I’m probably sounding like a broken record, but why not ditch docker and install Solr directly.

I don't feel like I can make this decision re: Cantus Ultimus. It was "dockerized" two summers ago (I wasn't really involved in the "why", just the implementation of this decision, but I think the rationale was that all the other DDML projects used it?).

I'm not entirely opposed to the idea, especially now that I am more ansible and poetry comfortable, but yeah, doesn't feel like a decision I can take on my own.

The one thing that I still like about docker is that in development it separates some of the services that I use across projects: eg. I am literally running separate postgres and solr instances for Cantus Ultimus and CantusDB. Of course, I could run the same server locally and just have different databases and different cores, but there is something that feels nice about being able to tear down (for example) my postgres installation for Cantus Ultimus without affecting simultaneous work with CantusDB. I guess I could use a single docker container for development, but deploy directly to the vm (sans Docker). How do you think about this?

— Reply to this email directly, view it on GitHubhttps://github.com/DDMAL/cantus/pull/842#issuecomment-2034861469, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAH342IKPVFBMQZ7MQVNX43Y3QKR7AVCNFSM6AAAAABFVIH5EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZUHA3DCNBWHE. You are receiving this because you are subscribed to this thread.Message ID: @.***>