Settings of FXTR v2

System requirements

  1. The main system requirements:

1 VPC, minimum 3 subnets desired private to have NAT gateway and possibility to set whitelist IP for outgoing traffic to 3 sides

  • EBS volumes are used by log and monitoring for data storage;

  • recommended OS: Amazon Linux 2 for nodes and alpine for docker images

  1. System components are set via helm, each has its own production-grade setup.

  • for logging you can use ELK stack, 3 statefullsets each in AZ with Persistent Volume;

  • for monitoring you can use stack prometheus-operator. Grafana with PV, HA prometheus in 3 AZ with PV. NATS minimum on 3 AZ.

  • for Secret Storage you can use vault from hashicorp for safe transmission all secret files and environment variables in microservices before the launch of the main process. Statefulset of 3 pods each on 1 of 3 AZ.

  • for ingress controller you can use nginx ingress controller.

  1. Scaling: it is recommended to have minimum 3 pods for each microservice from AZ; scaling is made on the base of 2 parameters: CPU and memory trashhold on 80%. Grace period for terminating pod by default is 30 sec.

  2. For the security of kubernetes environment you can use default security groups made by eksctl tool.

  3. For configuration of the kubernetes worker nod capacity you can use m5.xlarge.

  4. For logging configuration you can use standart configuration fluentd from helm chart, one of the highest log level on prod, trace and debug.

  5. The process of deployment of Access Server MT5 and DC server MT4 is on responsibility of the company that makes deployment.

Settings of FXTR v2

FXTR v2 needs 2 files for its work:

  1. accounttype_settings.json (the filename can be differnet, important to set it in the ENV variable while starting FXTR v2) - config file of FXTR v2. Contains parameters for connecting to RW-manager in the context of the list of servers (there can be several RW-managers connected to different MT5 servers). In addition, the file contains group settings for opening an account. The filename and path to the file are set in the ENV variable when FXTR v2 is started.

  2. public.pem - the public key that will be used to verify the client JWT token when the request is authorized. The name and path to the file are set in the ENV variable when FXTR v2 is started.

When launching a docker image, you can specify a parameter with which you can “mount” the necessary files at the specified path for the container, for example: The service uses two paths to read the config and the public key (which are specified in the env parameters):

  • /opt/config/accounttype_setttings.json - config

  • /opt/config/atwallet_public.pem - public key

For examlpe the files are here:

  • /home/user/fxtr_v2/accounttype_setttings.json - config

  • /home/user/fxtr_v2/atwallet_public.pem - public key

When starting a docker container, the local files that the service will work with should be forwarded inside:

The structure of other settings.json:

Comments:

YOUR_RWMANAGER_IP_ADDRESS - IP-address of RwManager

YOUR_RWMANAGER_PORT - PORT of RWManager's IP-address

YOUR_MT5_PUBLIC_IP_ADDRESS - public address of MT5 server to connect "directly" from the terminal. For DEV environment: 127.0.0.1.

YOUR_PRIVATE_STREAMING_KEY - private key to connect to stream of RwManager.

GROUP_NAME_1 - The name of the group that will work with the selected RwManager.

GROUP_NAME_2 - The name of the group that will work with the selected RwManager.

GROUP_NAME_3 - The name of the group that will work with the selected RwManager.

There can be any number of groups.

You also need to create a private and public key. And specify the path to the public key as an environment variable when starting FXTRv2, which will verify the signature (that the JWT was signed by the exact private key that was just created).

Checking availibility of FXTR v2

In order to check that FXTR is up and runnig the following operation can be executed:

  • to check availability of services curl --location 'base_url/api/v2/fxtr/about' - correct response should have status 200 and body of the response contains of json object with build and version;

  • to check accounts configuration curl --location 'https://stage-fxtr.rock-west.net/api/v2/fxtr/info' - correct responce shoud have status 200 and body of the response contains of json object with supported account types and parametrs to create it;

  • to check availability of linked RW-Manager curl --location 'base_url/api/v2/fxtr/server-time?server_code=srv_code_from_config' correct response should have status 200 and body of the response contains of json object with time of rw-manager linked to provided srv_code_from_config;

  • to check avilabilty of streaming interface the connections to the ws socket should be established according description in Open stream for the account.

Auth Logs

Example of process of user authtorization:

Example of process of user authtorization in debug mode:

Last updated