Problem: There is no production installation document

[weex]

If there are to be multiple independent instances of fedi-trustroots, then production installation should be possible to complete by following a document.

[nicksellen]

Here's a dump of my thoughts! Feel free to pick, choose, adapt, discard any of these thoughts as you feel of course :) Happy to talk it over more too if that's useful.

https://www.trustroots.org is setup somewhat manually on the server (something like what is described in Server.md).

dev2 setup

This is not literally a production setup, as it's a staging site, but would be suitable for a production setup.

https://dev2.trustroots.org is more recent, and configured with https://github.com/Trustroots/trustroots-debops, and auto deployed via travis.

The method for deployment is via an intermediate bundle (trustroots.tar.gz) that contains everything needed for running the server (pre-built frontend, pre-installed node_modules). That is built within travis, by running npm run build:tarball.

The server setup is using systemd (https://github.com/Trustroots/trustroots-debops/tree/master/ansible/roles/trustroots/templates):

• nginx site (configure via debops - the key bit is proxy_pass http://unix:/run/trustroots-server.socket)
• socket systemd socket definition
• server service systemd server definition - basically node server.js
• worker service systemd worker definition - basically node worker.js

This setup allows scaling the number of server services (and maybe workers?), as the socket stuff functions to balance between them.

Deployment specific configuration is via config/env/local.js configured via template, the contents are in the secret area, but it looks like this (secrets removed). It's stuff to override any of the values in config/env with deployment specific ones.

The nodejs package comes from nodesource to get a recent version (package managers usually have too old versions of nodejs).

co-op cloud

Now, a whole other option is creating a docker-based production setup that can be used with https://coopcloud.tech/ - this would make it possible for anyone using a co-op cloud system to spin up a fedi-trustroots instance, alongside any other related services they might want. I think that goes in a nice direction.

(other options are available like https://yunohost.org/ - why not all! ... at some point).

[weex]

Attempted a couple of paths but got further with a combination of Server.md and https://team.trustroots.org/Install.html on Ubuntu 18.04.5 so I'll start there.

I was able to get nginx, Passenger, mongodb, and letsencrypt all setup with my subdomain of choice. Then I started in on the trustroots specific part attempting to build everything on the droplet itself (this required 4gb ram to deal with the npm ci.

The best state achieved was seeing bullet points like "Volunteering" and several others with no styling or graphics in the browser. The page was requesting things from localhost:3000 which didn't seem to care about any changes I made in config/env/default.js (I was changing them there because git's helpful in showing what I fiddled with).

Here's what I changed there: https://gist.github.com/weex/a1f428ca453859918632ac2a15f82950 And here's the nginx config: https://gist.github.com/weex/013ed3f295b4a741c6768cd90213fc50

I cloned the fedi-trustroots source code to /var/www/o3.davidsterry.com/ft

Then I realized that I hadn't run npm ci with NODE_ENV=production so started doing that but canceled it midstream. Then when I tried it again, I got the following error about a missing husky. I feel like that will go away if I can start fresh from an installed node perspective. So how would I do that?

Another question is, does it matter if npm ci is run with production flag?

End of NODE_ENV=production npm ci log with husky error in case that's pertinent. https://gist.github.com/weex/7fdc3ac24ea97cdcf409cee6920c170c

---

I also attempted the debops route. What OS was used for that?

In the end that failed for me with this

$ debops bootstrap -l dev2
[DEPRECATION WARNING]: Ansible will require Python 3.8 or newer on the 
controller starting with Ansible 2.12. Current version: 3.6.9 (default, Jan 26 
2021, 15:33:00) [GCC 8.4.0]. This feature will be removed from ansible-core in 
version 2.12. Deprecation warnings can be disabled by setting 
deprecation_warnings=False in ansible.cfg.
Traceback (most recent call last):
  File "/home/dsterry/env/bin/debops", line 276, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/home/dsterry/env/bin/debops", line 252, in main
    monorepo_path, inventory_path)
  File "/home/dsterry/env/bin/debops", line 149, in gen_ansible_cfg
    if (ver(ansible_version) >= ver("1.7") and
  File "/usr/lib/python3.6/distutils/version.py", line 70, in __ge__
    c = self._cmp(other)
  File "/usr/lib/python3.6/distutils/version.py", line 337, in _cmp
    if self.version < other.version:
TypeError: '<' not supported between instances of 'str' and 'int'

[weex]

Here's work in progress that serves SSL-encrypted on the domain of your choice. I'll get it into Markdown format once it's more complete. Trustroots Production Setup WIP.pdf

[nicksellen]

First some answers:

I feel like that will go away if I can start fresh from an installed node perspective. So how would I do that?

npm ci is already doing a clean install, https://docs.npmjs.com/cli/v7/commands/npm-ci says:

This command is similar to npm install, except it's meant to be used in automated environments such as test platforms, continuous integration, and deployment -- or any situation where you want to make sure you're doing a clean install of your dependencies.

Another question is, does it matter if npm ci is run with production flag?

I don't think that has any effect. And for the build you'll need all the dev dependencies anyway. If you did want to remove the dev dependencies later, there is npm prune --omit dev (I think that should work). Also npm install comes with npm install --omit dev variant too (at least in my installed npm version, older ones had other options for similar uses).

I also attempted the debops route.

To clarify, I didn't mean to suggest/recommend that route (actually using debops, or that repo), but just that included in that setup are systemd unit files, and a general setup that could be useful.

What OS was used for that?

Debian Buster (Debian is my goto server OS).

In the end that failed for me with this

If you did want to try debops, I could help work out what is going on, but I am not recommending it, so unless you actively want to try debops, we can leave it unsolved. If you want to explore more about debops check out https://docs.debops.org/en/master/.

[nicksellen]

Then a few thoughts:

Starting with Ubuntu 18.04 when 20.04 is available seems less than optimal. Maybe we can resolve the issue you had? Although in general I go for Debian for server OSes, seems the most common from my experience. Feels Nice And Stable :) I'm sure Ubuntu works fine too though, they're pretty similar in general.

Passenger installation instructions for Ubuntu 20.04 (and Debian Buster (10)) are here https://www.phusionpassenger.com/docs/tutorials/deploy_to_production/installations/oss/aws/node/nginx/ (I did see some older instructions that stopped at Ubuntu 18.04 / Debian 9).

Although, personally, I would not use passenger at all. nginx proxying to node works very well, and it's not clear me what passenger really adds (ultimately I guess they want you do upgrade to paid versions, for their business model).

The packaging step I added (making trustroots.tar.gz in CI then deploying that) is intended to simplify the deployment method (don't need to install dependencies or run the build (and therefore don't need enough memory on server to build everything)).

Increasingly I'm leaning more towards having docker setups for production too, especially if intended for others to deploy, so that could be another option still.

Great that you're making progress :star:

[mariha]

I am not really sure why I closed it, shouldn't be me and probably shouldn't be closed yet.

[weex]

It probably closed automatically when you merged the PR since it said "Fixes #10" That being said, I think it is better to close this an open another with whatever problem there might be with the merged install doc.