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:

Shutdown down the Docker containers
```
docker-compose down
```
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"
```

Spin up the docker containers.

docker-compose -f docker-compose.yml pull
docker-compose -f docker-compose.yml up -d

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:

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"
            },
        ]
    }
}

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:

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
  }
}

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).
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:

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
    }
}

Restart Trains Server, see Restarting Trains Server.