Introduction

Executor service is providing multiple endpoints that allow you to deploy microservices to different engines. It supports different service deployment engines and allows you to inject external configuration properties of the Microservices you want to deploy.

By default the Executor service will be available under the following location:

Port	8070
Context path	/executor
Host	https://localhost:8070/executor

Installation

Please refer to the [Executor] Installation.

Supported deployment engine

Currently the following deployment engines are supported by Executor:

Nomad
Kubernetes

You have to choose one engine for deploying with Executor. Further configuration details can be found in Configuration section. For future releases it is also planned to support Cloud Foundry.

Supported Source Types

Executor supports microservices in the following format:

JAR (microservice as executable Java Jar file)
DOCKER (microservice as Docker image)

Usage

The following Executor rest end points are provided to do deployment operations on microservices:

Method	Path	Description
POST	http://<EXECUTOR_HOST>/executor/deployment	Deploy/start the microservice. The deployment configuration needs to be posted as request body as JSON object. See Deployment object in next section for more details. After the deployment succeeds the microservice deployment Id is returned.
GET	http://<EXECUTOR_HOST>/executor/deployment/{id}	Retrieve the current information about a microservice deployment by the given id.
PUT	http://<EXECUTOR_HOST>/executor/deployment/{id}	Restart the microservice deployment (identified by the given id) with an updated deployment configuration from request body.
DEL	http://<EXECUTOR_HOST>/executor/deployment/{id}	Stop and remove a microservice deployment by the given id.
GET	http://<EXECUTOR_HOST>/executor/deployment/{id}/status	Retrieve the deployment status of the deployment with the given id to find out how many service instances are running, pending or terminated.

Deployment Object

The deployment setting is encapsulated within a Deployment object which is send as JSON formatted request body to start your microservice. The Deployment object has the following structure:

{
    "id" : "MyService-1.0.0-LIVE",
    "serviceName" : "MyService",
    "serviceVersion" : "1.0.0",
    "execParams" : [ "" ],
    "sourceLocation" : "path/toMyService.jar",
    "sourceType" : "JAR",
    "count" : 1,
    "cpu" : 500,
    "memory" : 300
}

Field	Requirement	Explanation
id	Required	Unique Id of the microservice deployment to access the deployment configuration.
serviceName	Optional	The serviceName is used to get externalized configuration that are registered to the service name if set.
serviceVersion	Optional	The serviceVersion is used to find labeled external configuration (version=configuration label)
execParam	Optional	Execution parameter you want to inject into the deployment command. This is highly depending on the selected engine and the chosen `sourceType`. It's a list of Strings that contains the argument prefix, the argument key and if existing the argument value. For sourceType DOCKER currently only environment variables can be set. E.g. JAR: [ "--spring.property=myValue", "-DFlag", "-DmySysproperty=value" ] E.g. DOCKER: [ "spring_property=myValue", "ANOTHER_ENV_VAR=value" ] It is also possible to define default execution parameter (JAR) and default environment variables (DOCKER) which will be applied to each service deployment. Please check the configuration part of Executor's installation.
sourceLocation	Required	URL to the location of the microservice that should be deployed. Remember to set the authorization header if the access of the artifact from source location needs authentication.
sourceType	Required	Type of the microservice source. Currently JAR and DOCKER are supported.
count	Optional	Amount of microservice instances that will be deployed
cpu	Optional	Amount of CPU capacity in MHz each microservice instance should use
memory	Optional	Amount of RAM in MB each microservice instance should use

Limitations

Kubernetes Pod Scaling

To increase or decrease your running pod instances on Kubernetes you just need to send a PUT Request with the Deployment object containing only the deployment id and the count. In this case Executor will send a replacement request to Kubernetes, that adjusts your replicaSet number of the deployment you want to modify.

Sometimes you also want to give a new sourceLocation to signalize that the container image has changed. Keep in mind that Kubernetes will only adjust your running pods with the new image when the image tag has changed.
Currently the docker images that are created by executor depend on the serviceName serviceVersion and deployed ApiOmatSystem (e.g. MyService-1.0.0-LIVE).

That means, swapping your service image with the same tag can currently only be done by first scaling all pods down and afterwards scaling them up again (the image pull policy is internally set to 'Always').