-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General docker-compose: ISLE-MYSQL consider use of a volume for data #81
Comments
@br2490 I'm confused by this statement "Having data on volume may make it easier to get at those DB files" Within the Docker-compose service entry for mysql, exist these volumes: volumes:
(this is how one can add a database using a sql file, there is an example)
(mysql cnf file peristed for changes)
(databases live and persist here)
(logs logs logs) What is missing exactly? I believe these volumes are doing what you've explained above? Right? Or are you suggesting simply streamlining down to one volume? |
@g7morris, sorryI was not clear! |
@br2490 Except I'm still not following. How is the "volume" reference in the current Docker Compose file not a Could you elaborate on what is missing from the current method please? |
@g7morris: in a nutshell I think docker volumes are filesystems managed by docker and relatively 'independent' from the host. Docker handling the FS means docker controls the data and can do important stuff with it (e.g., migration). The bind/mount is dependent on the host system having files at a certain location on start - docker doesn't know about it, and will create an empty folder if it doesn't find something there. An example can be found in #67: in that docker-compose you will see a section for docker-managed volumes and calls for a default |
@br2490 Okay! I think I get it now. Thanks for being patient and explaining on this one. There isn't any apparent distinction in the documentation thus my confusion on what was happening. Perhaps they could use more code eh? This helped. Specifically several quotes: Quote 1:
Quote 2:
Okay with that bold part it finally clicked. Yes, agreed now that I'm on the same page. We'll need to revisit this entirely. It might actually make things easier as permissions on Docker hosts vs containers is a tricky thing already. I'd like to avoid it all together. I think more reading is in my future clearly however as I'm not clear on how to set permissions within this new structure. |
@br2490 Echoing from the Slack post: New Example Volume structure: version: '2' mysql: fedora: solr: apache: This is what it “feels” like we should be moving to. Granted I’ll need to test and work out if this is feasible. Also will need to update each respective Dockerfile to add / remove each structure. This would be most likely the death knell of the customization folder (as intended? and which we’ll handle with proper documentation for copying of files to the data volume e.g. install_site.sh) Your thoughts? |
Voting to close this issue as it is now 'legacy'. Volumes and mounts are understood and we will implement them to persist data when and where possible (and logical!). |
Having data on volume may make it easier to get at those DB files, maybe even add your own data directly into it.
Not sure (read: highly doubt) if moving entire SQL data folders around is something to do.
May just rely on dump and import for CUSTOMIZATION. To that end: review the MySQL default init or entrypoint script - I think it will scour a folder looking for sql, sql.gz or .tar files and import.
Please review my refactor pull and see if it made sense?
See #63 #64
tagging: @Islandora-Collaboration-Group/isle-steering-committee
The text was updated successfully, but these errors were encountered: