Configuring Trains Server

Upgrading Trains Server

We recommend using the latest version of Trains Server.

The Trains Server configuration uses the following configuration files:

  • hosts.conf
  • logging.conf
  • secure.conf
  • events.conf
  • tasks.conf
  • apiserver.conf

The default configuration files are in the trains-server repository.

Trains Server configurations

Trains Server supports two configurations:

Single IP (domain)

Single IP (domain) with the following open ports:

  • Web application on port 8080.
  • API service on port 8008.
  • File storage service on port 8081.

Sub-domain configuration

Sub-Domain configuration with default http/s ports (80 or 443):

  • Web application on sub-domain: app.*.*.
  • API service on sub-domain: api.*.*.
  • File storage service on sub-domain: files.*.*.

Securing deployment

By default, Trains Server deploys as an open network.

To restrict Trains Server network access:

  1. Shutdown down the Docker containers
    docker-compose down
  2. Edit your docker-compose.yml file as follows:
    • In the elasticsearch section, remove the two lines:
      ports:
      - "9200:9200"
    • In the mongo section, remove the two lines:
      ports:
      - "27017:27017"
    • In the redis section, remove the two lines:
      ports:
      - "6379:6379"
  3. Spin up the docker containers.
    docker-compose -f docker-compose.yml pull
    docker-compose -f docker-compose.yml up -d

Web Login Authentication

You can configure the Trains Server for web login authentication which permits only those users who are provided with credentials to access your Trains system. Those credentials are a user name and password.

Without web login authentication, Trains Server allows does not restrict access (by default).

To add web login authentication to your Trains Server, do the following:

  1. In your Trains Server /opt/trains/config/apiserver.conf, add the auth.fixed_users section and specify the users.
    For example:
    auth {
        # Fixed users login credentials
        # No other user will be able to login
        fixed_users {
            enabled: true
            users: [
                {
                    username: "jane"
                    password: "12345678"
                    name: "Jane Doe"
                },
                {
                    username: "john"
                    password: "12345678"
                    name: "John Doe"
                },
            ]
        }
    }
  2. Restart Trains Server, see the Restarting Trains Server.

Sub-domains and load balancers

You can configure Trains Server for sub-domains and a load balancer.

For example, if your domain is trains.mydomain.com, and your sub-domains are app and api, then do the following:

To configure sub-domains and load balancers for your Trains Server, do the following:

  1. In your Trains Server /opt/trains/config/apiserver.conf file, add the following auth.cookies section:
    auth {
      cookies {
        httponly: true
        secure: true
        domain: ".trains.mydomain.com"
        max_age: 99999999999
      }
    }
  2. Use the following load balancer configuration:
    • Listeners:
      • Optional: HTTP listener, that redirects all traffic to HTTPS.
      • HTTPS listener for app. forwarded to AppTargetGroup
      • HTTPS listener for api. forwarded to ApiTargetGroup
      • HTTPS listener for files. forwarded to FilesTargetGroup
    • Target groups:
      • AppTargetGroup: HTTP based target group, port 8080
      • ApiTargetGroup: HTTP based target group, port 8008
      • FilesTargetGroup: HTTP based target group, port 8081
    • Security and routing:
      • Load balancer: make sure the load balancers are able to receive traffic from the relevant IP addresses (Security groups and Subnets definitions).
      • Instances: make sure the load balancers are able to access the instances, using the relevant ports (Security groups definitions).
  3. Restart Trains Server, see Restarting Trains Server.

Non-responsive Task watchdog

The non-responsive experiment watchdog monitors experiments that were not updated for a specified time interval and then the watchdog marks them as aborted. The non-responsive experiment watchdog is always active.

You can modify the following settings for the watchdog:

  • The time threshold (in seconds) of experiment inactivity (default value is 7200 seconds (2 hours)).
  • The time interval (in seconds) between watchdog cycles.

To configure the non-responsive watchdog for your Trains Server, do the following:

  1. In your Trains Server /opt/trains/config/services.conf file, add or edit the tasks.non_responsive_tasks_watchdog and specify the watchdog settings.
    For example:
    tasks {
        non_responsive_tasks_watchdog {
            # In-progress tasks that haven't been updated for at least 'value' seconds will be stopped by the watchdog
            threshold_sec: 7200
    
            # Watchdog will sleep for this number of seconds after each cycle
            watch_interval_sec: 900
        }
    }
  2. Restart Trains Server, see Restarting Trains Server.