. . .

Executor


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').