Standard mode vs. Container mode
Starting with SDL ETS 8.3, both Standard mode and Container mode are supported.
Standard mode
- Hosts are added and deleted via the Web UI or the API.
- Services on the hosts (Job Engines and Translation Engines) are added and deleted via the Web UI or the API.
- API Gateway maintains the list of hosts and services. The list of hosts and services is preserved across system restart.
The main drawback of this ecosystem is that the SDL ETS Administrator would need to be aware when the Worker nodes come up/go down and adjust the SDL ETS configuration (either by calling the REST API or by using the Web UI).
Container mode
The main feature of running SDL ETS in containers is that the hosts and services are automatically added or removed as the Worker containers go up or down.
For example, if more translation bandwidth is needed for a given Language Pair, the administrator can start a new container for that Language Pair and SDL ETS will automatically recognize it. Conversely, Worker containers can be shut down if they are not needed.
- Master nodes and Worker nodes are each run within a container (one master node and multiple worker nodes).
- Each container has an ETS Manager process (ets-manager) as its root process which can run in either Master or Worker mode, almost exactly as the Standard mode. This is done to piggy-back on the existing ets-manager behavior (which starts the correct processes for Master or Worker mode, monitor processes, etc.).
- Upon startup, API Gateway starts with an empty list of hosts.
- Host Agent is aware when started in Container mode:
- It retrieves current capabilities from the configuration file.
- It connects to Rabbit MQ and starts a periodic broadcast of capabilities (Language Pair, the Translation Engines or Job Engines it has).
- API Gateway continuously listens to the broadcasts from host-agent and:
- If a new node is detected, API Gateway adds it to the host list and to the Job Engine / Translation Engine list.
- If a node configuration is changed, the list is synchronized to match the new configuration.
- If a node stops broadcasting, it is assumed to be dead, and its services are removed from the host / service list.