Design principles

EOSC Performance API is designed to run as a container service so it can be deployed with container technologies such as Docker and Kubernetes.

digraph {
  graph [bgcolor="#ffffff" pad=0.5 ratio="fill"]
  "named: postgres" [shape="folder"]
  "net: frontend-net" [shape="pentagon"]
  "net: backend-net" [shape="pentagon"]
  "backend_vx" [shape="component"]
  "database" [shape="component"]
  5432 [shape="circle"]
  "backend_vx" -> "database" [style="dotted"]
  "backend_vx" -> "net: frontend-net"
  "backend_vx" -> "net: backend-net"
  "named: postgres" -> "database" [style="dashed" label="/data" dir="both"]
  5432 -> "database" [style="solid"]
  "database" -> "net: backend-net"
}

You should be able to access the backend from the frontend network. in production it is recommended to run a reverse proxy container which provides HTTPS layer although for development it can be enough just to export the port 5000 where Flask normally runs.

Data storage

The main container includes all the dependencies to run the software, however, it is designed to store the data into an external postgresql database, normally deployed as a container. See the configuration settings to know more details about how to configure the application to connect to the external database.

When deploying the database as a container using a container orchestrator, it recommended to connect it to the “backend-net” network so all the backend related containers such as the backend itself or a backup service can access the required ports.

In case the database has to be managed outside the container network, it is generally a good idea to export the port where postgresql listens the incoming connections. By default it is the 5432, although for security reasons is always recommended to use a different port and always keep the container running with the last security updates.

Production vs development

You can control the environment as production or development configuring the environmental variable FLASK_ENV. This variable can take the following values and behaviors:

  • production: Backend service runs enforcing security requirements and performance processing. You should always run the application as production except for specific short executions for development. Testing should run as well in production to ensure the correct behavior of components.

  • development: Backend service runs with minimum security requirements and with additional loads for debugging. When running in development the number open queries might be limited to the specific used extension. Therefore it is not suitable for long running operations. In addition, some variables required for production might be optional, see configuration settings for more details about defaults when running on development mode.

Settings

You can get a full list of configurable environment variables from the configuration settings page.