Comments (5)
In one of our development systems we've set up a 256MB tmpfs
scratch space defined in /etc/fstab
as:
tmpfs /storage-mem/mig_system_run tmpfs nosuid,nodev,noatime,noexec,uid=1000,gid=1000,mode=0770,size=256m 0 0
Then in the active docker-compose.yml
each container just links that location into place for simple shared use.
volumes:
[...]
# NOTE: mig_system_run is a shared volatile cache using host tmpfs
- /storage-mem/mig_system_run:/home/mig/state/mig_system_run
to significantly speed up operations on the caches.
The 256MB size
was chosen a bit arbitrarily as an example. We see actual data sizes in maybe a few tens of megabytes even on production systems, so one can probably pick any size from 64m if memory is very scarce, or leave out the size argument completely to let the system use the default percentage.
The uid
and gid
values match the default setup, and just need to be adjusted to fit if one uses different values in docker-migrid
so that all container services can read and write there.
from docker-migrid.
We can add a note about the tmpfs
setup and corresponding commented out volume lines in docker-compose_production.yml
to ease use, but all deployments will need to act to enable it correctly.
from docker-migrid.
Some thoughts on that:
-
The mounting of a tmpfs should be done in Ansible (or whatever admins use to deploy the environment of Migrid)
Bjarke and I already talked about how that might be possible. -
The directory which hold the cache data on the host should be configurable and documented in docker-migrid. Something like
MIG_SYSTEM_RUN
maybe?
So the volume mount might look like:
volumes:
[...]
# NOTE: mig_system_run is a shared volatile cache using host tmpfs
- ${MIG_SYSTEM_RUN}:/home/mig/state/mig_system_run
The default could also be something like /tmp/mig_system_run
to enable the volatile behaviour by default.
Some distros even mount /tmp as a tmpfs iirc.
- Could you explain a bit more what you mean with the status markers needing to be shared between services.
We have the issue that we have multiple physical hosts running different Lustre services. Does the mig_system_run folder needs to be shared between them?
from docker-migrid.
Sorry, I never got back to you on this one - and thanks for your valuable input, btw 👍
Sure, it would be better to have it exposed as a variable and then handled where most appropriate on each site.
I only started looking into basically integrating it hard-coded in our docker-compose files before your comment, but got sidetracked by other more urgent matters and vacation so it's still only half done :-/
For a few things like account expiry and suspension to fully kick-in the mig_system_run/
contents currently need to be shared or synchronized between all migrid containers for one site. Which in practice of course makes it tricky to use a local tmpfs if the individual migrid-X containers are distributed across multiple VMs/hosts. If you have the mig_system_run
directory on lustre you would still want to mount the same lustre location into each container or run some frequent synchronization on top. Hope that answers your question.
from docker-migrid.
Implemented as suggested with a new MIG_SYSTEM_RUN
variable to define which directory should be bound to the internal state/mig_system_run
. It is documented in the variables doc and instructions for setting up and using a tmpfs mount for it are included with the variable in the provided .env
files.
ATTENTION integrators should make adjustments accordingly at least on production sites.
from docker-migrid.
Related Issues (20)
- define mail smtp_sender HOT 1
- Freeze Archives - file link error HOT 1
- The future of the single profile
- Future release workflow of docker-migrid HOT 10
- Bug: Cannot load modules/mod_wsgi_python3.so HOT 5
- Match check against pattern attributes HOT 1
- Std. jobs from generateconfs in cron HOT 1
- logrotate inside docker HOT 5
- feature request: cron support for */7 HOT 1
- Expose gdp.log in state/log/ on sensitive data sites HOT 2
- When checking for empty sequences HOT 1
- Question about usage of named Docker volumes HOT 5
- Rsyslog config error HOT 4
- Define equality checks of objects via "rich comparison" methods HOT 1
- Take out volume mount for mig/ directory in production HOT 4
- Github Actions don't run on all PRs HOT 1
- Identify and document internal and external container dependencies
- Logging up and download of files via SFTP/FTPS HOT 3
- Apache web log should land outside the container HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-migrid.