Microservices - Cloud

Talend Remote Engine User Guide for Windows

Version
Cloud
Language
English
Operating system
Windows
Product
Talend Cloud
Module
Talend Remote Engine
Content
Design and Development
Installation and Upgrade
Last publication date
2024-02-23

Deployment

Microservice deployments are executed directly via Talend Remote Engine. For each microservice, the Data Service Runner starts a separate Java process as a subprocess of the Remote Engine itself.

Each microservice is deployed with a unique identifier and dynamically gets a unique HTTP port when started. It is displayed on the Task Details page in Talend Management Console after a successful deloyment.

The deployment with a unique identifier and HTTP port allows you to deploy the same Talend Cloud artifact through multiple tasks with different configurations on the same Remote Engine.

By default, the deployment consists of the following parts:
  • An artifact (the microservice ZIP based deployment)
  • An application.properties file
  • A context property file (depending on the Talend Cloud environment and the overwrite parameters set in Talend Management Console)
  • Running a new Java sub-process of the current Talend Remote Engine

During deployment, each microservice is attributed a network port starting from 5060 by default.

The number of deployed microservices is limited to 20 by default. To change it, see Customizing global microservice configuration.

Undeployment

After a microservice is deployed, the only action linked to its unique identifier is undeployment. Undeployment means that every trace of its deployment is deleted from the <MicroserviceExecutionDirectory>. After undeployment, the network port is released and available for a new deployment.

Recovery

If Talend Remote Engine, the Data Service Runner, or the host machine is stopped, every deployed microservice is stopped and kept in the <MicroserviceExecutionDirectory>. When all services are started again, the microservice is started with the same configuration as before.

Any configuration update between a start/stop is ignored by the deployed microservices. To avoid recovery, microservices should be undeployed.