[Dachs-support] Errors of registration in RofR
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Fri May 28 13:22:01 CEST 2021
Hi Carlos,
On Fri, May 28, 2021 at 01:51:03PM +0400, Carlos Henrique Brandt wrote:
> Sorry I saw your messages too late (in the evening). If you feel like we
> can try again, let me know in advance.
No, it seems things are fine right now; we've re-built the container
from a git checkout and fiddled a bit, then ChloƩ worked out some
issues with an overly paranoid reverse proxy, and it seems all is
fine now.
> * First, I updated and push DaCHS server version 2.3 to DockerHub (together
> with Postgres 11).
Could this be done as part of a github action on pushes to master?
The old version coming from dockerhub was causing a bit of grief
here.
> * Third, Dockerfiles and docs were moved from `chbrandt` user to
> `gavodachs` organization:
> - https://github.com/gavodachs
That's excellent. I've updated the links on
http://docs.g-vo.org/DaCHS/ and on the readthedocs.
>
> now that dachs-on-docker is apparently becoming something useful.
> The move, as always, is a never ending story (parenthesis for a classic:
> [2] ;) since I feel docs can be done better,
> apart from the containers/compose, use cases, etc.
> You're very encouraged to submit pull requests, issues, etc.
Well... The work with ChloƩ yesterday made me itch a bit, but you
know how I feel about Docker in general...
However, here's what I think we should say:
If you have only a few smallish data collections, here is the
recommended way to set up throwaway containers:
(1) make a directory to put in which your deployment lives.
(2) create your gavo.rc, defaultmeta.txt, and spinup.sh (templates here)
(3) put that under version control (VESPA folks: use obspm gitlab
so-and-so)
(4) write a Dockerfile
(this would inherit from the one-container thing on dockerhub,
copy in the three files from (2), and possibly logos and all
that), and would start spinup.sh at the end.
(5) put your data and RDs into other directories *on the host
system* (example arihip)
(6) amend your spinup.sh with all the dachs imp and dachs pub
commands you intend to run.
(7) write a deploy.sh script with one line of -v
/var/gavo/inputs/arihip:/host/data/arihip as applicable; don't
forget the -p (template)
(8) chmod +x deploy.sh && deploy.sh on the host system
Or so. I think that's about the least fragile setup we can get with
docker in the equation; the one drawback here is that this will
re-publish all data to the registry each time it's spun up. If we
find people deploy like this in production and in large numbers,
here's what we ought to do:
(a) in your gavo.rc, set [db]dumpsystemtables to true; this will
write a dump of the current publication state to /var/gavo/state each
night at 0:20.
(b) use -v /var/gavo/state:/host/data/dachs-state to have DaCHS'
stateDir (that then has the system table dump in it) persist on the
host system.
(c) before running the imp-s and pub-s, run
dachs dump load /var/gavo/state/systemtables.dump
and say dachs pub -k rather than just dachs pub.
Volunteers for writing the prose and trying all that out?
-- Markus
More information about the Dachs-support
mailing list