Exécuter un microservice | Aide Talend Studio
Accéder au contenu principal

Exécuter un microservice

Dernière mise à jour : 27/10/2026

Après avoir construit un Job ou une Route en tant que microservice, vous pouvez l'exécuter indépendamment du Studio Talend en mode autonome. Vous pouvez exécuter un service SOAP construit en tant que microservice à partir de son fichier .jar fat.

Pour configurer les propriétés d'application par défaut des microservices construits à partir d'un projet, modifiez le paramètre dans Project Settings (Paramètres du projet) > Build (Construire) > Standalone Microservices (Microservices autonomes) > Microservices application properties file (Fichier de propriétés de l'application de microservices). Le fichier s'applique à chaque microservice construit à partir du projet. La clé favorite pour ce paramètre est ms_standalone_application_properties.

Pour exécuter un fichier .jar de microservice, procédez comme suit dans une fenêtre de console :

  1. Modifiez le répertoire dans lequel se trouve le fichier .jar de microservice.

  2. Lancez la commande suivante.

    java -jar <ArchiveFileName> --context=<context_environment_name> --configuration.additional-location=<configuration_file_path> --<context_parameter_name>=<context_parameter_value>

Par défaut, lorsque vous exécutez un microservice, il appelle les fichiers de configuration du dossier /config dans le .jar du microservice. À l'aide de la propriété configuration.additional-location, vous pouvez passer à un dossier de configuration externe dans lequel se trouvent les fichiers de configuration.

Par exemple, la commande suivante exécute le microservice DemoREST_0.1.jar, à l'aide de la configuration du fichier custom.properties dans le répertoire dans lequel se trouve le .jar du microservice.

java -jar DemoREST_0.1.jar --configuration.additional-location=./custom.properties

Les paramètres suivants peuvent être configurés dans le fichier des propriétés, par exemple :

# ============================================================================
    # Microservice runtime configuration (application.properties)
    #
    # Applicability of each parameter:
    #   [ALL]  - applies to all microservices (REST and SOAP)
    #   [REST] - applies to REST microservices only
    #   [SOAP] - applies to SOAP microservices only
    # ============================================================================

    # [ALL] Location of the startup banner printed in the console.
    banner.location=classpath:/config/banner.txt

    # --- Embedded HTTP server (Jetty) -------------------------------------------
    # [ALL] Protocol (http/https), bind address and listen port of the server.
    server.protocol=http
    # keep it as 0.0.0.0 for docker container
    server.host=0.0.0.0
    server.port=8065
    # [ALL] Base context path the CXF servlet is mounted on. Both REST (JAX-RS) and
    # SOAP (JAX-WS) endpoints are published below this path, e.g.
    # http://<host>:<port>/services/<endpoint>.
    server.servlet.context-path=/services

    # [ALL] Location of the logging (log4j2) configuration file.
    logging.config=classpath:config/log4j2.xml

    # --- Management / monitoring ------------------------------------------------
    # [ALL] Base path and the actuator endpoints exposed for monitoring
    # (health, info, metrics, ...).
    management.server.base-path=/
    management.endpoints.web.exposure.include=info,health,jolokia,prometheus

    # [ALL] Expose Java runtime information on the info endpoint.
    management.info.java.enabled=true

    # [ALL] Default credentials protecting the management endpoints. The same
    # credentials are reused for SOAP service security, so SOAP microservices do
    # not need their own credentials.
    security.user.name=${MS_SECURITY_USER_NAME:#{null}}
    security.user.password=${MS_SECURITY_USER_PASSWORD:#{null}}

    # [ALL] SSL configuration (disabled by default).
    #security.require-ssl=false
    #server.ssl.key-store=dispatchJob/src/main/resources/config/keystore.jks
    #server.ssl.key-store-type=JKS
    #server.ssl.key-store-password=sspass
    #server.ssl.key-store-alias=servicekey

    #server.ssl.client-auth=need

    # [ALL] SSL truststore configuration (disabled by default).
    #server.ssl.trust-store=server-truststore.jks
    #server.ssl.trust-store-password=password
    #server.ssl.trust-store-type=JKS

    # [ALL] Embedded Jetty thread pool sizing.
    jetty.threadPool.maxThreads=200
    jetty.threadPool.minThreads=8
    #jetty.threadPool.threadNamePrefix=JettyThread

    # [ALL] Server access (request) log settings (disabled by default).
    #server.requestlog.enabled=false
    #server.requestlog.append=true
    #server.requestlog.file=request.log
    #server.requestlog.retaindays=1
    #server.requestlog.format=%{client}a - %u %t "%r" %s %O "%{Referer}i" "%{User-Agent}i"

    # --- SOAP (JAX-WS) specific -------------------------------------------------
    # [SOAP] Parameters below are reserved for SOAP microservices. They share the
    # same HTTP server and base path as REST (server.servlet.context-path above);
    # SOAP endpoints are published as <context-path>/<service>?wsdl. SOAP service
    # security reuses the shared security.user.* credentials defined above. The
    # entries are documented for the SOAP microservice build and are commented out
    # (no effect until the build consumes them).

    # [SOAP] Publish the WSDL and the CXF service-list page under the base path.
    #soap.wsdl.publish=true
    #soap.service-list.hide=false

De plus, vous pouvez utiliser le paramètre management.endpoints.secured=true/false pour activer ou désactiver l'authentification simple pour les endpoints health et info, ce qui n'a aucun impact sur l'authentification simple de l'endpoint jolokia.

Pour les microservices de Routes :

  • http://localhost:8065/health peut être utilisé pour récupérer le statut des vérifications d'activité des microservices, y compris les vérifications par défaut et les vérifications personnalisées. La vérification par défaut est celle du contexte Camel.

  • http://localhost:8065/ready peut être utilisé pour récupérer le statut des vérifications de préparation des microservices, y compris les vérifications par défaut et les vérifications personnalisées. Chaque flux de Route comprend un vérificateur de préparation par défaut.

Vous pouvez personnaliser les données exposées par l'endpoint info en ajoutant le paramètre management.info.env.enabled=true et les propriétés info.* dans le fichier de propriétés. Par exemple :
info.app.encoding=UTF-8
info.app.java.source=17
info.app.java.target=17

Vous pouvez utiliser le paramètre management.endpoint.prometheus.enabled=true/false pour activer ou désactiver l'endpoint Prometheus du microservice.

Vous pouvez utiliser les paramètres suivants afin d'écraser la configuration de sécurité pour les types d'authentification BASIC (simple) et JWT Bearer Token (Jeton Bearer JWT) dans les composants cREST et tRESTRequest :
security.enabled=[true/false]
security.type=[BASIC/JWT]
security.jwt.keystore.type=[JKS/PKCS12/JWKS]
security.jwt.keystore.url=
security.jwt.keystore.file=
security.jwt.keystore.password=
security.jwt.keystore.alias=
security.jwt.audience=

La configuration de sécurité des types d'authentification BASIC (basique) et JWT Bearer Token (Jeton Bearer JWT) et l'activation de l'endpoint Prometheus dans le fichier des propriétés peuvent être écrasées via l'utilisation du paramètre adéquat dans le Commandline, lors de l'exécution du microservice.

Chaque paramètre de contexte de la configuration du microservice(application.properties) peut être écrasé. Voici l'ordre de priorité des paramètres de contexte, les derniers écrasant les premiers :

  1. Contexte par défaut de l'archive du microservice.
  2. --context=<context_environment_name>
  3. --config.additional-location=anyFile1,anyFile2
    1. anyFile1
    2. anyFile2
  4. --ctxParamName=ctxParamValue --ctxParamName=ctxOtherParamValue --ctxParam2Name=ctxParam2Value
    Dans cet exemple, le deuxième paramètre ctxParamName écrase le premier. Le résultat sera :
    ctxParamName=ctxOtherParamValue and ctxParam2Name=ctxParam2Value

Pour exécuter un microservice en tant que fichier .zip, procédez comme suit :

  1. Extrayez le fichier .zip dans le répertoire de votre choix.

  2. Accédez au dossier <ArchiveFileName> contenant le dossier config externe, le fichier .jar du microservice et les scripts de démarrage afin de lancer le microservice pour Linux (.sh) et pour Windows (.bat).

  3. Modifiez les fichiers de configuration du dossier config selon vos besoins et exécutez le fichier .sh sous Linux ou .bat sous Windows pour démarrer le microservice avec les configurations externes.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.