Configuring multiple Talend Runtime containers on a single server
Sometimes, you may need to deploy, run and test multiple versions of a SOAP service on a single server for short term development and testing needs.
In cases like this, you can deploy multiple Talend Runtime containers on a single server, to simulate multiple environments, such as Development, Staging, System Integration Test, UAT1, UTA2, etc. Those additional environments are generally temporary. They are created to accelerate development and testing and are cleaned up after the release is done.
Multiple environment Runtime
Talend Runtime can be installed multiple times on the same server. Since there are many ports used by a Talend Runtime instance, you need to change all of them to avoid conflicts.
Deploying multiple Talend Runtime containers
Before you begin
- There are no shared resources between the environments other than Nexus, Git or SVN.
- There is no ActiveMQ or JMS communication with the services.
- There are no ESB infrastructure services used (since these are temporary environments).
- Do not run the default container. If you have already started it, stop it and delete the data directory.
- Copy-paste the container and name it, once per environment.
- Start the first Runtime (container).
Run the configuration script in each container, after starting, to set the
Scripts for different configurations are provided in the scripts folder of the ESB distribution.
- source scripts/configureC1.sh for the first container copy,
- source scripts/configureC2.sh for the second container copy,
- source scripts/configureC3.sh for the third container copy.
Restart each container after having run the script on the Karaf console.
Configure all new servers in Talend Administration Center.
You have now three Talend Runtime containers, each one for simulating a different environment and ready to be used on a single server.
Deploying on different environments
Deployment and testing of SOAP and REST services into the various containers are now transparent, even though the three environments, that is to say the three Talend Runtimes, are on the same physical or virtual server. You can deploy artefacts from Nexus to any environment.
To make services more configurable, you can design them to include context variables in their endpoints. In this example, you have the server, port and version defined as context variables.
In the Contexts view in your Studio, define context variables
for the server, port and version of the services endpoints.
You can use the version variable to define different versions or to reflect several environments for easy reference.
In the Endpoint field of the basic settings of the cCXFRS
component, set the service endpoint URL using the context variables.
The cCXFRS component is renamed to cREST starting from the 6.4 Studio version.
Deploy the different versions of the services on different environments.
The services automatically acquire the IP address and port of the server if you use a relative URL for the endpoint.
The same service is deployed here in different environments with different URL patterns.