Skip to content

Installation access details

Kjell Petersen edited this page Jan 18, 2024 · 6 revisions

As we've seen in the other intro pages, FEGA Norway is a distributed architecture over several zones/location, with multiple services at each location, that orchestrated together delivers the FEGA Norway service and it's functionality to the researchers/end users.

To develop, test and operate FEGA Norway, we need to have multiple deployments for different purposes, and it's then key to understand which resources (microservices/instances/dbs/users) at the different locations that are linked together to constitute the deployment of one specific FEGA Norway stack for a given purpose.

4 immediate different installations of the FEGA Norway stack would be: the production and test stacks, tests run in GitHub, local installation on dev computer/server.

Production installation

The stable deployment used to serve production data.

  • Trusted zone frontend=proxy server: ega.elixir.no server hosted by USIT/UIO
  • Secure zone backend in TSD: p969 project, p969-containers VM with podman services enabled
  • "norway" CEGA RabbitMQ exchange and "norway" nss-endpoint user (using prod endpoints in config files)
  • Relies on RMQ services of TSD (in p01)
  • Relies on Postgres DB hotel service of TSD both in Trusted and Secure zone
  • Utilize prod TSD-file-api for transfers (to p969 project)

Test installation

The staging deployment to test newer versions of microservices together in TSD. Any combiniation of microservices considered to be deployed in production, should be thoroughly tested in same combiniation in this stack first.

  • Trusted zone frontend=proxy server: tryggve.tsd.usit.uio.no server hosted by USIT/UIO
  • Secure zone backend in TSD: p2184 project, p2184-services-l VM with podman enabled
  • "norway" CEGA RabbitMQ exchange and "norway" nss-endpoint user (using test endpoints in config files)
  • Relies on RMQ services of TSD (in p01, but separate parallel configs/setup to prod)
  • Relies on Postgres service of TSD in Secure zone
  • Utilize a non-persistent standard postgres container in the Trusted zone (identity mapping at the Proxy server)
  • Utilize prod TSD-file-api for transfers (to p2184 project)

GitHub nightly integration test

To test nightly that the latest versions of all components play well together, a GitHub CI/CD pipeline is configured to:

  1. build/pull all the latest container images we use in the deployments above,
  2. together with additional containers for replacing the TSD-file-api, RMQ server, postgres (trusted + secure instance),
  3. deploy them all in a docker node of GitHib CI/CD infrastructure
  4. automatically perform a scripted upload, ingest and download of a test file (by-passing the manual meta-data entry step of the end-user)
  5. report results in the GitHub action section of the repository of the workflow

Link to repo neic-nordic/LocalEGA-deploy-swarm

  • Relies on FEGA Norway specific RMQ container
  • Utilize a non-persistent standard postgres container in the Trusted zone (identity mapping at the Proxy server)
  • Utilize neic-nordic/sda-db container for non-persistent postgres server in Secure zone
  • "norway" CEGA RabbitMQ exchange and "norway" nss-endpoint user in test CEGA servers (has this been updated?)
  • Utilize a "TSD-stub-code" container to mimic minimal TSD-file-api functionality needed for the integration test

Local dev deployment

Some notes here how one could install a stack locally based on different repos / integration tests available (both FEGA Norway and neic-nordic origin). NB! The new FEGA-Norway mono-repo will soon facilitate easier testing during development locally on your own system: https://github.com/ELIXIR-NO/FEGA-Norway.