Supporting Services

YOUnite services leverage the following Open Source services:

  • Postgres DB

  • Active MQ Message Bus

  • Elastic

  • Mongo DB (YOUnite Off-the-Shelf Adaptor only)

  • Keycloak (reference ID provider only)

In the event of new releases or mandatory updates for these services, comprehensive instructions will be furnished to facilitate their upgrade. These guidelines will be designed to ensure minimal interruption to existing deployments, with the goal of a seamless transition to the latest versions.

Supporting Services Compatibility Matrix

The YOUnite services utilize the open source services listed below and support the following versions:

Service Versions

Active MQ

2.18.0

Postgres

12

Elastic Opensearch

1.1.0

Elastic Logstash

7.13.2

Elastic Kibana

1.1.0

Elastic Kibana (non-production deployments)

16.1.1

Mongo DB (YOUnite Off-the-Shelf Adaptors)

4.4.6

Mongo Express (Optional Mongo UI)

1.0.2

YOUnite Versions

Specifying a Service’s Version

The version level of a service is set in each service’s Kubernetes spec file with the image property:

image:<docker-repo-path>:<tag>

The <tag> specifies the image’s version number.

You can manually edit a service’s spec file or use the kubectl set image (see below) for updating a service’s image/version number.

Important
Using the latest version tag is strongly discouraged in production deployments.

Service Compatibility Matrix

YOUnite API is the core service that other all other services rely on for their operation. The matrix below illustrates the compatibility of each service and the YOUntie Adaptor SDK with different versions of YOUnite API.

YOUnite API Version (Core Service) YOUnite Data Virtualization Service YOUnite Notification Service YOUnite UI YOUnite Off-the-Shelf Adaptors YOUnite Adaptor SDK

1.8.1 and higher

1.8.1 and higher

1.8.1 and higher

1.8.1 and higher

1.8.1 and higher

1.8.1 and higher

YOUnite Services

Unless, explicitly stated in the release notes or the Service Compatibility Matrix, YOUnite services can run at different levels - most notably the YOUnite adaptors.

However, these services are typically versioned together and usually operate with the same version number simultaneously

  • younite-api

  • younite-ui

  • younite-notification-service

  • younite-data-virtualization-service

Getting the Current Service Version Numbers

To get the version number for the following services, search the service’s log file for string "Starting Application"

  • younite-api

  • younite-notification-service

  • younite-data-virtualization-service

  • YOUnite Off-the-Shelf Adaptors

For the younite-ui, login to the UI and the version number is on the bottom left of the page.

YOUnite Off-the-Shelf Adaptor

Versioning the YOUnite Off-the-Shelf Adaptor may not always be preferable, particularly when it operates in an environment that requires 24x7 uptime.

Important
Restarting a YOUnite Off-the-Shelf Adaptor will result in a temporary interruption of service. However, if the processing service is properly set up, it will continue to detect data events upon restart. For databases, it will pick up data event detection from where it stopped before the restart.

Custom Adaptors

If there is a need to upgrade a custom adaptor to the latest version, it will need to be rebuilt using the latest Adaptor SDK and then made available so that the Kubernetes deployment knows where to locate the updated adaptor image.

Major Releases

In certain rare cases, a major release might necessitate the re-building of custom adaptors and the restarting of all services. Such occurrences are exceptions rather than the norm and will be clearly communicated with detailed instructions to ensure a smooth transition.

Normal Rolling Update Procedure

See your YOUnite system’s integrator for how to best configure your cluster for rolling updates.

The most common strategy is covered here:

  • Add the following to the younite-api and/or younite-data-virtualization-service (if configred) service spec files in the spec section updating the maxUnavailable and maxSurge properties as needed:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Do the following, first for younite-api and then younite-data-virtualization-service (both rolling updates):

  • Update the service’s version number

kubectl set image deployment/your-deployment-name your-container-name=your-image:your-new-version
  • Upgrade the deployment

kubectl set image deployment/your-deployment-name your-container-name=your-image:your-new-version
  • Monitor the Deployment

kubectl rollout status deployment/your-deployment-name
  • Update the version numbers for younite-ui and younite-data-notification-service and restart them (these are non-rolling updates).

Non-Rolling Upgrade to a New Version of YOUnite:

  1. For each service to be updated, update the image property to the desired version in each of the service’s deployment.yml file in the cluster’s spec folder.

  2. Restart the younite-api service

  3. Once younite-api is re-started and running

  4. Start the other YOUnite services, YOUnite Off-the-Shelf Adaptors and customer adaptors

END