Serve beta from nginx in docker compose, with its config in this repo

[adamjohnwright]

beta.reactome.org is served by Apache configured by hand on the dev box. Nothing about that arrangement is in any repository, so it is unreviewed, unversioned, and reconstructable only from memory if the box is rebuilt.

Proposal: move it into the docker-compose.yml that already exists here, behind nginx.

The case is reproducibility, not performance

Worth being straight about this, because the usual framing does not survive contact: Apache 2.4 is not slow and not obsolete. As a reverse proxy in front of a Node process at beta's traffic, nginx and Apache are indistinguishable. If throughput were the only argument, this would not be worth the risk.

The argument that does hold is that beta's entire configuration is invisible:

beta.reactome.org
  /                   → localhost:4200      (the Angular build, via serve-prod.js)
  /ContentService/    → localhost:8080      (Tomcat)
  /AnalysisService/   → localhost:8080      (Tomcat)
  TLS                 → Let's Encrypt

Three vhosts, no review, no history, one machine. Putting it in the repo means it is diffable, it is rebuildable, and the next person to touch it can see why it is shaped the way it is — including the reasons that are not obvious, such as beta proxying to its own Tomcat because that one serves endpoints the public host does not.

A second reason, which is new

DeltaSignal (#155, superseded by #202) needs a route. Its backend is a Julia HTTP API that ships its own Dockerfile, docker-compose.dev.yml and docker-compose.prod.yml, serving /api/* with a /api/health check.

The Angular side calls /api/pathways, /api/parse and /api/solve as bare relative paths, routed only by proxy.conf.js — the dev server's proxy, which does not exist in a built artifact. So DeltaSignal cannot work on beta at all until something in front of beta routes /api. That is this issue.

A trap worth recording: DeltaSignal's compose binds 8080, which on this box is Tomcat. proxy.conf.js currently defaults DELTASIGNAL_BACKEND to http://localhost:8080, so an unconfigured developer sends DeltaSignal's calls to Tomcat and gets 404s from a real server rather than a clear failure. Whatever port it lands on, that default should point at it.

What would need to be true before switching

Certbot is the risk, and it is not a small one. It is configured with:

authenticator = apache
installer = apache

Swap the proxy without migrating that and renewal silently stops; beta loses HTTPS within 90 days with nothing to warn anyone. There is already a dns-cloudflare authenticator on the box for another certificate, which is the safer path — it does not care which web server is running.

Step one is therefore certbot, not nginx, and it should be proved with a renewal dry-run before anything else moves.

Other things to settle:

• 001-reactome.conf is a third vhost; whatever it serves has to be accounted for, not assumed idle.
• Ports 80 and 443 have to move from Apache to the container atomically, or beta is down in between.
• ~/git/reactome_nginx exists on the dev box but is empty — worth knowing it is a placeholder and not prior art.
• Beta is the curator QA gate. This should not land mid-review-cycle.

Suggested shape

• nginx service in this repo's docker-compose.yml, config in docker/nginx/ and reviewed like code
• routes: / → the served build, /ContentService/ and /AnalysisService/ → Tomcat, /api/ → DeltaSignal
• certs mounted from the host, renewal moved to dns-cloudflare first
• Apache kept installed but disabled for one cycle, so reverting is a systemctl command rather than a rebuild

Not in scope

Production. This is about beta and the dev box.