On Mon, Feb 05, 2018 at 10:58:02AM +0100, Aurelien Bompard wrote:
Hey, sorry for the silence on this subject, I was experimenting
with
deployment options.
So far, here's what I've come up with.
Npm has a command called "shrinkwrap" which will list all the installed
dependencies and their versions recursively and dump that in a file. It's
pretty much like "pip freeze". Then all subsequent calls to "npm
install"
will use those versions regardless of what the most current one is.
So I've generated and committed this version in git, and then I've cleaned
up the local dependencies dir, run "npm install" again, and tarred up this
big directory. I'm using this tarball as an additional source for the Hubs
RPM that I wrote, untar it in %prep, build the JS in %build, install the
resulting files in %install.
This adresses the issues of reproductible builds, and the "bundled"
sources (which are only bundled in the source RPM, not the binary one) are
easily re-generated on any machine with npm installed. It also means that
the RPM can build in mock because all dependencies are locally provided.
Would this method of deployment work for you?
This sounds fine for me. Thanks for looking into this!
Concerning services location (all local or split), I'm
thinking on the
following layout:
- shared PostgreSQL
- everything else on the same host.
It's simple and it would be sufficient for a start because we're only
going to setup a few group hubs for "early adopter" teams (however anyone
with a FAS account can login and have their hub autocreated). Then if we
need to loadbalance we'll be able to split the services, that shouldn't be
a problem.
What do you think?
This also sounds fine to me. We can always adjust as needed from there, but we
also need to be careful not to give a bad impression to the first users because
we aimed too low on the server side.
Pierre