Release Notes

Warning

Lightbend Orchestration is no longer actively developed and will reach its End of Life on April 15, 2020.

We recommend Migrating to the Improved Kubernetes Deployment Experience.

This page tracks the components of Lightbend Orchestration. Note that reactive-lib is automatically included by sbt-reactive-app, so you do not normally need to specify its version. However, a particular version can be used by explicitly setting the reactiveLibVersion sbt setting.

Latest Versions

Project Version
sbt-reactive-app 1.7.3
reactive-cli 1.7.1
reactive-lib 1.7.0

sbt-reactive-app 1.7.3

1.7.1

sbt-native-packager 1.3.18

sbt-reactive-app 1.7.1 updates its dependency to sbt-native-packager 1.3.18 to bring in some bug fixes around Docker image building.

Other fixes

  • Fixes -Dplay.server.pidfile.path=/dev/null generation. cli#201
  • Default rp to --registry-use-local. --registry-disable-local is added to disable it. cli#203

1.7.0

In general, the theme of Lightbend Orchestration 1.7.0 is to remove unnecessary features to make the deployment leaner and more manageable. 1.7.0 runtime is based on Akka 2.5.20 and Akka Management 0.20.0.

Secure Docker image building with sbt-native-packager 1.3.17

For building Docker images, Lightbend Orchestration depends on sbt-native-packager, an sbt plugin maintained by Nepomuk “Muki” Seiler. To improve the security around file permissions and Red Hat OpenShift compatibility, Lightbend Tooling team has contributed a few enhancements to sbt-native-packager.

First, dockerPermissionStrategy was added to decide how file permissions are set for the working directory inside the Docker image. The default DockerPermissionStrategy.MultiStage strategy uses multi-stage Docker build to call chmod ahead of time. This avoids extra Docker layer overhead.

Next, dockerChmodType setting was added to specify what file permissions are set for the working directory. By default, it uses DockerChmodType.UserGroupReadExecute, which prevents the working directory to be writable. If you want your application to write a file, the following setting can be used to opt-in:

import com.typesafe.sbt.packager.docker.DockerChmodType
dockerChmodType := DockerChmodType.UserGroupWriteExecute

See sbt-native-packager 1.3.16 release note for more details.

YAML file generation for Akka Cluster Bootstrapping using Kubernetes API

The main feature of Lightbend Orchestration is the automatic generation of Kubernetes configuration (YAML) files.

For Akka Cluster Bootstrapping, Lightbend Orchestration generates YAML files using Kubernetes API as the discovery method. Starting with Lightbend Orchestration 1.7.0, we will use a specialized label akka.lightbend.com/service-name, which denotes the Akka Cluster to join when a pod comes up.

  • The value of the this label will default to either the app name or the app name + version depending on the deployment type.
  • Deployment pods are labeled with "akka.lightbend.com/service-name": "friendimpl" etc.
  • You can override the label selector as follows: -Dakka.discovery.kubernetes-api.pod-label-selector=akka.lightbend.com/service-name=%s (as opposed to using app=%s).
  • You can override the effective name as follows: -Dakka.management.cluster.bootstrap.contact-point-discovery.effective-name=friendimpl etc.

YAML file generation: Removal of automatic port assignment

Previous releases of Lightbend Orchestration automatically assigned various port numbers from port 10000 in part by overriding your application.config file. Lightbend Orchestration 1.7.0 removes this feature, and respects the port number declared in your your application.config. Otherwise, default port numbers will be used such as port 9000 for Play. This also allows us to remove RP_ENDPOINT_* environment variables, generally simplifying the generated YAML file.

Note: This also means that your deployed service will expose different port number (for example 9000) instead of 10000.

YAML file generation for Akka Cluster Bootstrapping using DNS

Optionally, Lightbend Orchestration 1.7.0 adds experimental support to generate Kubernetes configuration for Akka Cluster Bootstrapping using DNS as the discovery method.

If you want to use DNS, pass --discovery-method=akka-dns to the rp command line. cli#195

Rename of sbt-reactive-app key names

All key names are renamed to prefix with rp and camel cased to comply with Plugins Best Practices. For instance, endpoints setting will now be rpEndpoints, and deploy task will be rpDeploy. The old key names are deprecated and will be removed in the future. sbt-reactive-app#145

Deprecation of SecretReader

In the effort to reduce runtime dependencies, SecretReader was deprecated. Read from the file /rp/secrets/%name%/%key% where %name% is transformed to lowercase, and - for non-alphanum instead. lib#118

Other bug fix

  • Fixes missing protocol when UDP endpoint is selected. cli#196

sbt-reactive-app 1.6.1

  • Fixes binary compatibility issue with sbt-native-packager 1.3.15 adopted by Play 2.6.20+ and Lagom 1.4.10. #169 by @ignasi35

1.6.0

The reactive-lib 1.6.0 runtime is based on Akka 2.5.18 and Akka Management 0.20.0.

Akka Cluster bootstrap: port-name

To maintain the compatibility with Akka Management 0.20.0, reactive-lib 0.9.3+ sets the default value of akka.management.cluster.bootstrap.contact-point-discovery.port-name in the config to "akka-mgmt-http". lib#90

In addition, reactive-cli 1.6.0 will generate YAML that passes -Dakka.management.cluster.bootstrap.contact-point-discovery.port-name explicitly from the command line, which allows us to incrementally transition to the port name "management" in the future. cli#185

Akka Cluster bootstrap: discovery-method

Instead of using -Dakka.discovery.method, reactive-cli 1.6.0 will generate YAML that passes -Dakka.management.cluster.bootstrap.contact-point-discovery.discovery-method, which is a setting more specific to Akka Cluster bootstrap. cli#184

Since reactive-lib’s ClusterServiceDiscovery was never used, the implementation and akka.discovery.method = reactive-lib in config were both removed. lib#99

Other fixes