Content

Upgrade manual

Default ports for services

Default ports of services
Service name Port
LUNA PLATFORM API 5000
LUNA PLATFORM Admin 5010
LUNA PLATFORM Image Store 5020
LUNA PLATFORM Faces 5030
LUNA PLATFORM Events 5040
LUNA PLATFORM Tasks 5050
LUNA PLATFORM Tasks Worker 5051
LUNA PLATFORM Configurator 5070
LUNA PLATFORM Sender 5080
LUNA PLATFORM Handlers 5090
LUNA PLATFORM Python Matcher 5100
LUNA PLATFORM Licenses 5120
LUNA PLATFORM Backport 4 5130
LUNA PLATFORM Backport 3 5140
LUNA PLATFORM Accounts 5170
LUNA PLATFORM Lambda 5210
LUNA PLATFORM Remote SDK 5220
LUNA PLATFORM 3 User Interface 4100
LUNA PLATFORM 4 User Interface 4200
Oracle DB 1521
PostgreSQL 5432
Redis DB 6379
InfluxDB 8086
Grafana 3000

Configuration names for services

The table below includes the service names in the Configurator service. Use these parameters to configure your services.

Service names in the Configurator service in the “Service name” field
Service Service name in Configurator
API luna-api
Licenses luna-licenses
Faces luna-faces
Image Store luna-image-store
Accounts luna-accounts
Tasks luna-tasks
Events luna-events
Sender luna-sender
Admin luna-admin
Handlers luna-handlers
Lambda luna-lambda
Python Matcher luna-python-matcher
Backport 3 luna-backport3
Backport 4 luna-backport4

Settings for the Configurator service are set in its configuration file.

System requirements

LUNA PLATFORM is delivered in Docker containers and can be launched on CPU and GPU. Docker images of the LP containers are required for the installation. Internet connection is required on the server for Docker images download, or the images should be downloaded on any other device and moved to the server. It is required to manually specify login and password for Docker images downloading.

LUNA PLATFORM can be launched with a Docker Compose script.

The following Docker and Docker Compose versions are recommended for LP utilization:

Launching LUNA PLATFORM containers is officially supported on CentOS 7/8. Correct work on other systems is not guaranteed. All the procedures in the installation manual are described for CentOS 7.

LUNA PLATFORM service containers use the CentOS Linux 8.3.2011 operating system.

Processors

The configuration below guarantees software package minimum power operating and cannot be used for the production system. System requirements for the production system are calculated based on the intended system load.

CPU

The following minimum system requirements should be met for the LUNA PLATFORM software package installation:

It is recommended using SSD for databases and Image Store service.

GPU

For GPU acceleration an NVIDIA GPU is required. The following architectures are supported:

Compute Capability 6.1 or higher is required.

A minimum of 6GB or dedicated video RAM is required. 8 GB or more VRAM recommended.

CUDA of version 11.4 should be installed on the server with the Remote SDK service. The recommended NVIDIA driver is r470.

Third-party applications

The following third-party services are used by default with LUNA PLATFORM 5.

You can also use the Oracle database instead of PostgreSQL for all services except the Events service. The installation and configuration of Oracle are not described in this manual.

Balancers and other software can be used when scaling the system to provide fail-safety. The installation guide provides recommendations on launching Nginx container with a configuration file to balance requests to the API, Faces, Image Store, and Events services.

The following third-party applications versions are recommended for LP launching:

These versions were tested by VisionLabs specialists. Newer versions can be used if needed, but they are not guaranteed to work.

It is recommended to use the unzip package to unpack the distribution. The command to download the package is given in the installation manual.

If you need to use an external database and the VLMatch function, you need to download additional dependencies described in the “External DB” section of the installation manual.

PostgreSQL, Redis, InfluxDB, Grafana and Nginx docker containers can be downloaded from the VisionLabs registry.

Introduction

This document gives an example of the steps for upgrading from previous build to a new build of LUNA PLATFORM.

This document also contains the commands required to upgrade from version 5.2.0 and higher to the current build. Note that starting from versions 5.2.0, there may have been critical changes, such as updates to thresholds or neural network versions, deprecation of FaceDetV1 and FaceDetV2 detectors, and others (see the full list in the “Key changes from previous versions” section). A change such as updating the thresholds may give a different result when performing estimation than in the old build. This manual is for upgrading from a previous build and these commands are for advanced users only. These commands are marked accordingly. Be careful and do not perform unnecessary actions if you are updating from from LUNA PLATFORM 5.54.0.

For a successful upgrade, you need to perform the actions from the sections “Before upgrade” and “Services launch”. The section “Additional information” provides useful information on the description of service launch parameters, Docker commands, and information on launching the Python Matcher Proxy service for using matching plugins.

This guide is designed with an assumption that:

All the provided commands should be executed using the Bash shell (when you launch commands directly on the server) or in a program for working with network protocols (when you remotely connect to the server), for example, Putty.

This document includes an example of LUNA PLATFORM deployment. It implements LUNA PLATFORM minimum power operating for demonstration purposes and cannot be used for the production system.

Before upgrade

Make sure that you are the root user before upgrade!

Before upgrading the LUNA PLATFORM, you must perform the following actions:

  1. See key changes from previous versions if you are upgrading from a version other than LUNA PLATFORM 5.54.0.
  2. Create backups.
  3. Prepare to change the version of the neural network to extract descriptors if necessary.
  4. Delete old symbolic link.
  5. Unpack the distribution of the new version of LUNA PLATFORM.
  6. Create new symbolic link.
  7. Change group and owner for new directories.
  8. Move data if you are upgrading from version 5.38.3 and below.
  9. Save user configurations of the Configurator service if they have changed.
  10. Configure SELinux and Firewall if not previously configured.
  11. Create log directories for new services if you have previously used logging to file.
  12. Activate license if necessary.
  13. Set up GPU computing if you plan to use GPU.
  14. Login to VisionLabs registry if authorization was not previously performed.
  15. Remove old containers.

Key changes from previous versions

Note: When updating LUNA PLATFORM from a previous version, skip this section.

The following are the key changes from previous versions that you should pay attention to when updating from older versions of LUNA PLATFORM. Some of these changes require mandatory actions to be performed, otherwise the LUNA PLATFORM may not start or function incorrectly.

Not all changes are listed in the table below. See the LUNA PLATFORM release notes for details on all changes.

Version Changes Mandatory actions
5.53.0 The VisionLabs image for PostgreSQL has been updated from version 12 to version 16. If this image was previously used, then you need to perform the migration yourself according to official documentation.
5.46.0 The functionality for working with neural networks (detection, estimation and extraction) has been transferred from the Handlers service to the new Remote SDK service. -
The 105th neural network model for extracting body descriptors has been removed from the Remote SDK container. Now, by default, the 110th neural network model is used for extracting body descriptors. Read the information described in the section “Prepare to change the neural network version”, and perform certain actions before launching Remote SDK, because the default version has changed.
5.45.1 The default value of the “score_threshold” setting in the “LUNA_HANDLERS_FACE_DETECTOR_SETTINGS” section of the Configurator service has been changed from 0.42 to 0.5. Check the face recognition logic if the “score_threshold” value is used that is different from the default value.
5.40.0 The PostgreSQL, InfluxDB and Image Store container launch commands now prescribe the paths of the directories for mounting located in the root directory /var/lib/luna/<db_or_bucket_folder>, unlike previous versions, where paths were prescribed for a specific version of the LUNA PLATFORM /var/lib/luna/current/example-docker/<db_or_bucket_folder>. This enables you not to move data with each update. Move the old PostgreSQL, InfluxDB and Image Store data to the root directory (see “Move data”), and then delete and recreate the containers by specifying new directory paths for mounting.
5.38.3 The default value of the “score_threshold” setting in the “LUNA_HANDLERS_BODY_DETECTOR_SETTINGS” section of the Configurator service has been changed from 0.3 to 0.5. Check the body recognition logic if the “score_threshold” value is used that is different from the default value.
The default value of the “redetect_face_target_size” setting in the “LUNA_HANDLERS_FACE_DETECTOR_SETTINGS” section of the Configurator service has been changed from 45 to 64. Check the face recognition logic if the “redetect_face_target_size” value is used that is different from the default value.
5.36.5 The address of the license server must now be set in the Configurator settings before starting the Licenses container. Perform the steps described in the “Specify license server address using Configurator” section.
5.35.0 Support for old Services for index building and searching by index has been discontinued. -
5.34.0 The 54, 56 and 57 neural network models for extracting face descriptors have been removed from the Handlers container. Read the information described in the section “Prepare to change the neural network version”, and perform certain actions before launching Handlers if one of the listed models was used.
The 104 and 106 neural network models for extracting body descriptors has been removed from the Handlers container. Now the 107 model is used by default. Read the information described in the section “Prepare to change the neural network version”, and perform certain actions before launching Handlers, because the default version has changed.
Support for the Liveness V1 service has been discontinued. -
5.30.0 Vendor libraries for HASP key and HASP utility have been updated (from 111186 to 30147). Update the HASP service and issue a new license (see “License key activation”).
The mechanism for creating and managing accounts has been changed. Perform actions marked with the phrase Note. Accounts migration (upgrading from 5.2.0…5.28.0 only)
5.28.0 The default value of the “score_threshold” setting in the “FACE_DETECTOR_V3” section of the Configurator service has been changed from 0.89 to 0.42. Check the face recognition logic if the “score_threshold” value is used that is different from the default value.
5.26.0 The presence of a mask on the chin from this version refers to the “missing” state. In previous versions, it referred to the “medical_mask” state. Check the logic of the mask estimation.
5.24.0 Support for the Vertica database for the Events service has been discontinued. -
5.23.0 The default thresholds (recommended) have been updated for the following checks in the “face_quality” section and the “/iso” resource: “mouth_occluded” (old values: min=0, max=0.3; new values: min=0, max=0.5) and “mouth_open” (old values: min=0, max=0.64; new values: min=0, max=0.5) Check the logic of “mouth_occluded” and “mouth_open” if the default values were used.
5.14.0 The Liveness V2 algorithm has been updated. The default thresholds for “liveness_threshold” and “quality_threshold” are now “0.5”. The recommended threshold “liveness_threshold” is now “0.5” instead of “0.88”. Check the logic of the Liveness V2 algorithm.
5.6.0 Now, by default, the neural network model 59 for extracting face descriptors is used. Read the information described in the section “Prepare to change the neural network version”, and perform certain actions before launching Handlers, because the default version has changed.
The 101 model of the neural network for extracting body descriptors has been removed from the Handlers container. Now the 104 model is used by default. Read the information described in the section “Prepare to change the neural network version”, and perform certain actions before launching Handlers, because the default version has changed.
5.3.0 The logic of launching LUNA PLATFORM services inside containers has been changed. Now applications are launched not from the “root” user, but from the “luna” user. -
Support for FaceDetV1 and FaceDetV2 detectors has been discontinued. -

Create backups

It is recommended to create the following backups:

Creating backups will enable you to restore in case of any problems during the migration process.

Below are the backup commands for versions v.5.40.0 and higher. If you are upgrading to a lower version, then the path to the unpacked previous LP version must be added to the location of the LP data directories, for example, to create a backup copy of the PostgreSQL database for version v.5.38.1, run the following command:

cp -r /var/lib/luna/luna_v.5.38.1/example-docker/postgresql /var/lib/luna/BACKUP_postgresql

Backup of PostgreSQL database

Create a backup of the PostgreSQL database using the following command:

cp -r /var/lib/luna/postgresql /var/lib/luna/BACKUP_postgresql

Backup of InfluxDB database

Create a backup of the InfluxDB database using the following command:

cp -r /var/lib/luna/influx /var/lib/luna/BACKUP_influx

Backup of Image Store Buckets

Create a backup of buckets using the following command:

cp -r /var/lib/luna/image_store /var/lib/luna/BACKUP_image_store

Dump file with service settings

Custom values of settings for LUNA PLATFORM services (all except the Configurator service) are automatically migrated using the Configurator service migration mechanism described in the section “Configurator database migration”.

If the migration of the service for some reason has lost the user configuration or the user just wants to store the old service settings for different LP versions, then you can create a dump file.

To create a dump file, use the following command (may be executed from anywhere on your server):

wget -O /var/lib/luna/BACKUP_settings_dump.json 127.0.0.1:5070/1/dump

or

curl 127.0.0.1:5070/1/dump > /var/lib/luna/BACKUP_settings_dump.json

This file will not be used during the normal installation of the LUNA PLATFORM. To apply the dumped settings use the db_create.py script with the --dump-file command line argument (followed with the created dump file name): base_scripts/db_create.py --dump-file settings_dump.json. You can apply full settings dump on an empty database only. See the detailed information in the “Settings dump” section of the administrator manual.

Prepare to change the neural network version

In some LUNA PLATFORM builds, neural network models for extracting face and body descriptors are removed, and the default model usage settings are changed. See the section “Key changes from previous versions” for more information about these changes.

If you are upgrading from versions 5.2.0 and higher and in the previous build, one of the removed models was specified in the settings “DEFAULT_FACE_DESCRIPTOR_VERSION” or “DEFAULT_HUMAN_DESCRIPTOR_VERSION”, then the launch of the Remote SDK service will fail if you do not perform the additional steps.

There are available models of neural networks for extracting descriptors in the current LUNA PLATFORM build:

Object from which descriptor is extracted Neural network models Default model
Face 59, 60, 62 59
Body 107, 110 110

It is necessary to perform one of the additional actions depending on the following scenarios of the work:

Continuation of the use of missing neural networks

Request to VisionLabs an old neural network model and prepare it for transfer to the new Remote SDK container after its launch (see instructions in the section “Use non-delivery neural network model” of administrator manual).

Switching to new version of the neural network with continuation of the use of old descriptors

Switching to new version of the neural network with cessation of the use of old descriptors

Specify the new version of the neural network in the settings “DEFAULT_FACE_DESCRIPTOR_VERSION” or “DEFAULT_HUMAN_DESCRIPTOR_VERSION” before launching the Remote SDK service (see section “Change the neural network model for extracting descriptors”).

If it is not necessary to extract body descriptors, then you can disable the use of the neural network using the command --env=EXTEND_CMD="--enable-body-descriptor-estimator=0" when launching Remote SDK container (see the detailed information in the section “Enable/disable several estimators and detectors” of the administrator manual).

Delete the symbolic link to the previous minor version directory using the following command:

rm -f /var/lib/luna/current

Distribution unpacking

The distribution package is an archive luna_v.5.56.0, where v.5.56.0 is a numerical identifier, describing the current LUNA PLATFORM version.

The archive includes configuration files, required for installation and exploitation. It does not include Docker images for the services. They should be downloaded from the Internet.

Move the distribution package to the directory on your server before the installation. For example, move the files to /root/ directory. The directory should not contain any other distribution or license files except the target ones.

Move the distribution to the created directory.

mv /root/luna_v.5.56.0.zip /var/lib/luna

Install the unzip archiver if it is necessary.

yum install -y unzip

Go to the folder with distribution.

cd /var/lib/luna

Unzip files.

unzip luna_v.5.56.0.zip

Create a symbolic link.

The link indicates that the current version of the distribution file is used to run LUNA PLATFORM.

ln -s luna_v.5.56.0 current

Changing group and owner for directories

LP services are launched inside the containers by the “luna” user. Therefore, it is required to set permissions for this user to use the mounted volumes.

Go to the LP “example-docker” directory.

cd /var/lib/luna/current/example-docker/

Create a directory to store settings.

mkdir luna_configurator/used_dumps

Set permissions for the user with UID 1001 and group 0 to use the mounted directories.

chown -R 1001:0 luna_configurator/used_dumps

Move data (versions 5.38.3 and below)

Note: Perform these actions only if you are upgrading from version 5.38.3 and below, because starting with LUNA PLATFORM v.5.40.0, the PostgreSQL, InfluxDB and Image Store container launch commands prescribe the paths of the directories for mounting located in the root directory /var/lib/luna/<db_or_bucket_folder>, unlike previous versions, where paths were prescribed for a specific version of the LUNA PLATFORM /var/lib/luna/current/example-docker/<db_or_bucket_folder>. Thus, there is no need to move data in new versions.

Move the data from your version to the directory /var/lib/luna/. Below are examples of commands for version 5.38.3.

Move Image Store buckets

The following step is required if you are storing Image Store buckets in the default directory.

Copy the “image_store” folder with all its buckets.

mv /var/lib/luna/luna_v.5.38.3/example-docker/image_store /var/lib/luna/

Set rights for the luna user.

chown -R 1001:0 /var/lib/luna/image_store

Move PostgreSQL data

The following step is required if you are using PostgreSQL in Docker container.

Copy the “data” folder.

mv /var/lib/luna/luna_v.5.38.3/example-docker/postgresql /var/lib/luna/

Move InfluxDB Data

The following step is required if you are using InfluxDB in Docker container.

Copy the “influx” folder with all its buckets.

mv /var/lib/luna/luna_v.5.38.3/example-docker/influx /var/lib/luna/

Starting from version 5.9.0, InfluxDB OSS version 2 is used by default. This version enables you to visualize monitoring data using Grafana. If necessary, you can migrate data from InfluxDB version 1 to InfluxDB version 2. See Influx documentation for more details.

Save user configurations of the Configurator

Note: Skip this step if the Configurator settings have not been changed.

The configurations of the Configurator service are not automatically migrated, unlike the configurations of all other services.

If your previous LP version was used with non-default Configurator service configurations, back up your “luna_configurator_postgres.conf” config file in the separate directory on your server.

cp /var/lib/luna/<your_previous_lp_version>/example-docker/luna_configurator/configs/luna_configurator_postgres.conf /var/lib/luna/BACKUP_luna_configurator_postgres.conf

This backup must be mounted to the Configurator service container that is being run.

If you are not sure if the Configurator service configurations have changed, you can compare the created backup with the Configurator configurations from the current distribution using the following command:

diff /var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf /var/lib/luna/BACKUP_luna_configurator_postgres.conf

SELinux and Firewall

You must configure SELinux and Firewall so that they do not block LUNA PLATFORM services.

SELinux and Firewall configurations are not described in this guide.

If SELinux and Firewall are not configured, the installation cannot be performed.

Create log directory for new services

Skip this section if no logs were previously stored on the server.

In the new version of LUNA PLATFORM, new services could appear, for which you need to create directories with logs. It depends on the version from which you are upgrading. For example, version 5.30.0 introduced the Accounts service.

See “Logging to server” section if you have not previously used logging to a file, but want to enable it.

Following are the commands to create directories for all existing services. These commands will create and assign permissions only to missing directories.

mkdir -p /tmp/logs/configurator /tmp/logs/image-store /tmp/logs/accounts /tmp/logs/faces /tmp/logs/licenses /tmp/logs/events /tmp/logs/python-matcher /tmp/logs/handlers /tmp/logs/remote-sdk /tmp/logs/tasks /tmp/logs/tasks-worker /tmp/logs/sender /tmp/logs/api /tmp/logs/admin /tmp/logs/backport3 /tmp/logs/backport4
chown -R 1001:0 /tmp/logs/configurator /tmp/logs/image-store /tmp/logs/accounts /tmp/logs/faces /tmp/logs/licenses /tmp/logs/events /tmp/logs/python-matcher /tmp/logs/handlers /tmp/logs/remote-sdk /tmp/logs/tasks /tmp/logs/tasks-worker /tmp/logs/sender /tmp/logs/api /tmp/logs/admin /tmp/logs/backport3 /tmp/logs/backport4

If you need to use the Python Matcher Proxy service, then you need to additionally create the /tmp/logs/python-matcher-proxy directory and set its permissions.

License activation

To activate/upgrade the license, follow these steps:

Actions from License activation manual

Open the license activation manual and follow the necessary steps.

Note: This action is mandatory. The license will not work without following the steps to activate the license from the corresponding manual.

Calculations using GPU

You can use GPU for the general calculations performed by Remote SDK.

Skip this section if you are not going to utilize GPU for your calculations.

You need to install NVIDIA Container Toolkit to use GPU with Docker containers. The example of the installation is given below.

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.repo | tee /etc/yum.repos.d/nvidia-docker.repo
yum install -y nvidia-container-toolkit
systemctl restart docker

Check the NVIDIA Container toolkit operating by running a base CUDA container (this container is not provided in the LP distribution and should be downloaded from the Internet):

docker run --rm --gpus all nvidia/cuda:11.4.3-base-centos7 nvidia-smi

See the NVIDIA documentation for additional information.

Attributes extraction on the GPU is engineered for maximum throughput. The input images are processed in batches. This reduces computation cost per image but does not provide the shortest latency per image.

GPU acceleration is designed for high load applications where request counts per second consistently reach thousands. It won’t be beneficial to use GPU acceleration in non-extensively loaded scenarios where latency matters.

Login to registry

When launching containers, you should specify a link to the image required for the container launching. This image will be downloaded from the VisionLabs registry. Before that, you should login to the registry.

Login and password can be requested from the VisionLabs representative.

Enter login <username>.

docker login dockerhub.visionlabs.ru --username <username>

After running the command, you will be prompted for a password. Enter password.

In the docker login command, you can enter the login and password at the same time, but this does not guarantee security because the password can be seen in the command history.

Remove old containers

Before launching the containers of the current minor version, stop all LUNA PLATFORM related containers of the previous minor version and third-party software containers.

It is also necessary to delete the PostgreSQL and InfluxDB containers in order to recreate them with new mounted directories (see “Move data”).

To delete a container use the following command:

docker container rm -f [container_name]

where [container_name] is the service docker container name or ID.

For example, to remove LP containers only use the following command:

docker container rm -f luna-configurator luna-backport3 luna-backport4 luna-sender  luna-tasks luna-handlers luna-remote-sdk luna-python-matcher luna-events luna-licenses luna-faces luna-image-store luna-ui-3 luna-ui-4 luna-admin luna-api luna-tasks-worker luna-accounts

To delete PostgreSQL and InfluxDB containers, use the following command:

docker container rm -f postgres influxdb

If you are upgrading from version 5.38.3 and below, you must delete the PostgreSQL and InfluxDB containers.

To see the containers names or IDs, use the following command:

docker ps -a

It is also recommended to delete old images of the containers to free space. You can use the following command to delete all unused images.

If there is enough space on the server it is recommended to perform this action only after new version of LP is successfully launched.

The command deletes all the unused images, not only the images related to LP.

docker image prune -a -f

Services launch

This section gives examples for:

LUNA PLATFORM services must be launched in the following sequence:

The Lambda service (disabled by default) can be launched after Licenses and Configurator services.

The following service are used when emulation of LUNA PLATFORM 3 is required only:

The following service are used when emulation of LUNA PLATFORM 4 is required only:

It is recommended to launch containers one by one and wait for the container status to become “up” (use the docker ps command).

Some of these services are optional and you can disable their use. It is recommended to use Events, Tasks, Sender and Admin services by default. See the “Optional services usage” section for details.

When launching each service, certain parameters are used, for example, --detach, --network, etc. See the section “Launching parameters description” for more detailed information about all launch parameters of LUNA PLATFORM services and databases.

See the “Docker commands” section for details about working with containers.

Monitoring configuration

Monitoring LUNA PLATFORM services requires running the Influx 2.0.8-alpine database. Below are the commands to launch the InfluxDB container.

For more information, see the “Monitoring” section in the administrator manual.

If necessary, you can configure the visualization of monitoring data using the LUNA Dashboards service, which includes a configured Grafana data visualization system. In addition, you can launch the Grafana Loki tool for advanced work with logs. See the instructions for launching LUNA Dashboards and Grafana Loki in the “Monitoring and logs visualization using Grafana” section.

Migration from version 1

If necessary, you can upgrade from the InfluxDB OSS 1 version.

The process of migrating InfluxDB from version 1 is not described in this documentation. InfluxDB provides built-in tools for migrating from version 1 to version 2. See the documentation:

https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/docker/

InfluxDB OSS 2

Note: Make sure that the old InfluxDB container is deleted.

Use the docker run command with these parameters:

docker run \
-e DOCKER_INFLUXDB_INIT_MODE=setup \
-e DOCKER_INFLUXDB_INIT_BUCKET=luna_monitoring \
-e DOCKER_INFLUXDB_INIT_USERNAME=luna \
-e DOCKER_INFLUXDB_INIT_PASSWORD=password \
-e DOCKER_INFLUXDB_INIT_ORG=luna \
-e DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=kofqt4Pfqjn6o0RBtMDQqVoJLgHoxxDUmmhiAZ7JS6VmEnrqZXQhxDhad8AX9tmiJH6CjM7Y1U8p5eSEocGzIA== \
-v /etc/localtime:/etc/localtime:ro \
-v /var/lib/luna/influx:/var/lib/influxdb2 \
--restart=always \
--detach=true \
--network=host \
--name influxdb \
dockerhub.visionlabs.ru/luna/influxdb:2.0.8-alpine

If you need to set the custom settings of the InfluxDB (for example, set the IP address and port when launching InfluxDB on separate server), then you need to change them in the configurations of each LUNA PLATFORM service. See the section “Set custom InfluxDB settings” for more information.

Run third-party services

This section describes the launching of databases and message queues in docker containers. They must be launched before LP services.

PostgreSQL

Migrate PostgreSQL 12 to PostgreSQL 16

In LUNA PLATFORM v.5.53.0, the VisionLabs image for PostgreSQL has been updated from version 12 to version 16.

If this image was previously used, then you need to perform the migration yourself according to official documentation. If necessary, you can continue using PostgreSQL 12 by specifying the image “postgis-vlmatch:12” in the container launch command.

Mounting PostgreSQL 12 data from the directory “/var/lib/luna/postgres” into a container for PostgreSQL 16 will result in an error.

Launch PostgreSQL

Note: Make sure that the old PostgreSQL container is deleted.

Use the following command to launch PostgreSQL.

docker run \
--env=POSTGRES_USER=luna \
--env=POSTGRES_PASSWORD=luna \
--shm-size=1g \
-v /var/lib/luna/postgresql/data/:/var/lib/postgresql/data/ \
-v /var/lib/luna/current/example-docker/postgresql/entrypoint-initdb.d/:/docker-entrypoint-initdb.d/ \
-v /etc/localtime:/etc/localtime:ro \
--name=postgres \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/postgis-vlmatch:16

-v /var/lib/luna/current/example-docker/postgresql/entrypoint-initdb.d/:/docker-entrypoint-initdb.d/ \ - The “docker-entrypoint-initdb.d” script includes the commands for the creation of services databases. During database creation, a default username and password are automatically used.

-v /var/lib/luna/current/example-docker/postgresql/data/:/var/lib/postgresql/data/ - The volume command enables you to mount the “data” folder to the PostgreSQL container. The folder on the server and the folder in the container will be synchronized. The PostgreSQL data from the container will be saved to this directory.

--network=host - If you need to change the port for PotgreSQL, you should change this string to -p 5440:5432. Where the first port 5440 is the local port and 5432 is the port used inside the container.

You should create all the databases for LP services manually if you are going to use an already installed PostgreSQL.

Redis

If you already have Redis installed, skip this step.

Use the following command to launch Redis.

docker run \
-v /etc/localtime:/etc/localtime:ro \
--name=redis \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/redis:7.2

Configurator

Optional services usage

The listed below services are not mandatory for LP:

You can disable them if their functionality is not required for your tasks.

Use the “ADDITIONAL_SERVICES_USAGE” section in the API service settings in the Configurator service to disable unnecessary services.

You can use the dump file provided in the distribution package to enable/disable services before Configurator launch.

vi /var/lib/luna/current/extras/conf/platform_settings.json

Disabling any of the services has certain consequences. For more information, see the “Disableable services” section of the administrator manual.

Configurator database migration

Migration from the previous LP build to LP build v.5.56.0 is described in this section.

The following instruction for Configurator DB migration assumes that you already have settings migration revision set in your database. This revision is set using the configs.migrate head script. This script is included in the installation manuals of LP, starting with build 5.1.1. If you have performed installation according to the manual, you do not need to perform additional actions.Settings migration will be performed automatically.

If there is no revision, you should recreate the database structure. See the LP 5 installation manual section “Configurator DB tables creation” for instructions. Then you should specify all the required settings manually.

The migration from version 5.1.0 is described in “LP_Docker_Upgrade_Manual.html” in the distribution package of version 5.1.1. You can update your Configurator database using this instruction and distribution package of version 5.1.1. Otherwise, you should recreate the database structure for the Configurator service and specify all the required settings manually. See the LP 5 installation manual section “Configurator DB tables creation” for instructions.

Migration from pre-release builds (builds before v.5.1.0) of LP is not provided. You should transfer all the required settings to the Configurator DB of 5.1.1 build manually.

When upgrading the Configurator service database with existing service configurations, a database structure migration must be performed, which will also migrate the saved settings of all LP services except the Configurator service configurations.

Note on migrating Configurator service settings is described in the next section.

Use the docker run command with these parameters to create the Configurator database tables.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf:/srv/luna_configurator/configs/config.conf \
--network=host \
-v /tmp/logs/configurator:/srv/logs \
--rm \
--entrypoint bash \
dockerhub.visionlabs.ru/luna/luna-configurator:v.2.1.80 \
-c "alembic upgrade head; cd /srv/luna_configurator/configs/configs/; python3 -m configs.migrate --config /srv/luna_configurator/configs/config.conf head;"

Here:

Run Configurator container

Note: Configurator service configurations are not automatically migrated, unlike all other service configurations. If the configurations of the Configurator service were changed in the previous version of LP and you need to save custom values, then in the command below you need to replace the path /var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf with the path with a backup copy of the configurations Configurator service /var/lib/luna/BACKUP_luna_configurator_postgres.conf (see “Save user configurations of the Configurator” section).

Use the docker run command with these parameters to launch Configurator:

docker run \
--env=PORT=5070 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf:/srv/luna_configurator/configs/config.conf \
-v /tmp/logs/configurator:/srv/logs \
--name=luna-configurator \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-configurator:v.2.1.80 

At this stage, you can activate logging to file if you need to save them on the server (see the “Logging to server” section).

Image Store

Image Store container launch

Note: If you are not going to use the Image Store service, do not launch this container and disable the service utilization in Configurator. See section “Optional services usage”.

Use the following command to launch the Image Store service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5020 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /var/lib/luna/image_store/:/srv/local_storage/ \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/image-store:/srv/logs \
--name=luna-image-store \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-image-store:v.3.10.2

Here -v /var/lib/luna/image_store/:/srv/local_storage/ is the data from the specified folder is added to the Docker container when it is launched. All the data from the specified Docker container folder is saved to this directory.

If you already have a directory with LP buckets you should specify it instead of /var/lib/luna/image_store/.

Buckets creation

Buckets are required to store data in Image Store. The Image Store service should be launched before the commands execution.

When upgrading from the previous version, it is recommended to launch the bucket creation commands one more time. Hence you make sure that all the required buckets were created.

If the error with code 13006 appears during launching of the listed above commands, the bucket is already created.

There are two ways to create buckets in LP.

Run the listed below scripts to create buckets.

Run this script to create general buckets:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/api:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-api:v.6.23.0 \
python3 ./base_scripts/lis_bucket_create.py -ii --luna-config http://localhost:5070/1

If you are going to use the Tasks service, use the following command to additionally create the “task-result” in the Image Store service:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/tasks:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-tasks:v.3.19.2 \
python3 ./base_scripts/lis_bucket_create.py -ii --luna-config http://localhost:5070/1

If you are going to use the portraits, use the following command to additionally create the “portraits”.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/api:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-backport3:v.0.10.2 \
python3 ./base_scripts/lis_bucket_create.py -ii --luna-config http://localhost:5070/1

Use direct requests to create required buckets.

The curl utility is required for the following requests.

The “visionlabs-samples” bucket is used for face samples storage. The bucket is required for LP utilization.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-samples

The “portraits” bucket is used for portraits storage. The bucket is required for Backport 3 utilization.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=portraits

The “visionlabs-bodies-samples” bucket is used for human bodies samples storage. The bucket is required for LP utilization.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-bodies-samples

The “visionlabs-image-origin” bucket is used for source images storage. The bucket is required for LP utilization.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-image-origin

The “visionlabs-objects” bucket is used for objects storage. The bucket is required for LP utilization.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=visionlabs-objects

The “task-result” bucket for the Tasks service. Do not use it if you are not going to use the Tasks service.

curl -X POST http://127.0.0.1:5020/1/buckets?bucket=task-result

Accounts

Accounts DB tables creation

Note. Accounts migration (upgrading from 5.2.0…5.28.0 only). Perform the steps below only if you are upgrading from LP 5.2.0…5.28.0, where the Admin service was not used. If you have used the Admin service before, skip this section and perform the steps in the “Accounts database migration” section.

Use the following command to create Accounts DB tables:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/accounts:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-accounts:v.0.2.2 \
python3 ./base_scripts/db_create.py --luna-config http://localhost:5070/1

Accounts database migration

You need to execute migration scripts to update your Accounts database structure.

It is recommended to create the back up of your database before applying any changes.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/accounts:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-accounts:v.0.2.2 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

In LUNA PLATFORM 5.30.0, the database that stores information about accounts has changed. In LUNA PLATFORM versions 5.2.0…5.28.0, information was stored in the Admin database (luna_admin database), and in versions 5.30.0 and higher, information is stored in the Accounts database (luna_accounts database). If you are upgrading from versions 5.2.0…5.28.0 to the current version, then the script above will transform the luna_admin database to work with new accounts (the database name will remain the same).

Accounts container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5170 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/accounts:/srv/logs \
--name=luna-accounts \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-accounts:v.0.2.2

Licenses

Note: To use a trial license, it is required to launch the Licenses service on the same server where trial license is being used.

Specify license settings using Configurator

Follow the steps below to set the settings for HASP-key or Guardant-key.

Specify HASP license settings

Note: Perform these actions only if the HASP key is used. See the “Specify Guardant license settings” section if the Guardant key is used.

To set the license server address, follow these steps:

If the license is activated using the HASP key, then two parameters “vendor” and “server_address” must be specified. If you want to change the HASP protection to Guardant, then you need to add the “license_id” field.

Specify Guardant license settings

Note: Perform these actions only if the Guardant key is used. See the “Specify HASP license settings” section if the HASP key is used.

To set the license server address, follow these steps:

If the license is activated using the Guardant key, then three parameters “vendor”, “server_address” and “license_id” must be specified. If you want to change the Guardant protection to HASP, then you need to delete the “license_id” field.

Licenses container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5120 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/licenses:/srv/logs \
--name=luna-licenses \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-licenses:v.0.9.5

Faces

Faces database migration

You need to execute migration scripts to update your Faces database structure.

It is recommended to create the back up of your database before applying any changes.

Run the following command to perform the Faces DB migration.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/faces:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-faces:v.4.10.2 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

Faces container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5030 \
--env=WORKER_COUNT=2 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/faces:/srv/logs \
--name=luna-faces \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-faces:v.4.10.2

Events

Events database migration

You need to execute migration scripts to update your Events database structure.

It is recommended to create the back up of your database before applying any changes.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/events:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-events:v.4.11.3 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

Events container launch

Note: If you are not going to use the Events service, do not launch this container and disable the service utilization in Configurator. See section “Optional services usage”.

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5040 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/events:/srv/logs \
--name=luna-events \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-events:v.4.11.3

Python Matcher services

For matching tasks, you can use either only the Python Matcher service, or additionally use the Python Matcher Proxy service, which redirects matching requests to either the Python Matcher service or matching plugins. This section describes how to use Python Matcher without Python Matcher Proxy.

You need to use the Python Matcher Proxy service only if you are going to use matching plugins. Using Python Matcher Proxy and running the corresponding docker container are described in the “Use Python Matcher with Python Matcher Proxy” section.

See the description and usage of matching plugins in the administrator manual.

Use Python Matcher without Python Matcher Proxy

The Python Matcher service with matching by the Faces DB is enabled by default after launching.

The Python Matcher service with matching by the Events is also enabled by default. You can disable it by specifying “USE_LUNA_EVENTS = 0” in the “ADDITIONAL_SERVICES_USAGE” settings of Configurator (see “Optional services usage” section). Thus, the Events service will not be used for LUNA PLATFORM.

The Python Matcher that matches using the matcher library is enabled when “CACHE_ENABLED” is set to “true” in the “DESCRIPTORS_CACHE” setting.

A single image is downloaded for the Python Matcher service and the Python Matcher Proxy service.

Python Matcher container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5100 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/python-matcher:/srv/logs \
--name=luna-python-matcher \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-python-matcher:v.1.8.2

Remote SDK

Change the neural network model for extracting descriptors

In this version of the LUNA PLATFORM, the following changes have occurred regarding neural network models for extracting body descriptors:

If the 105th model was previously used, then launching the Remote SDK service will fail if you do not perform one of the actions described in the section “Prepare to change the neural network version”.

If the 107th model was previously used, then launching the Remote SDK service will not fail, however, since this model is considered outdated, it is recommended to update the model to the 110th in the “DEFAULT_HUMAN_DESCRIPTOR_VERSION” setting, and then perform the “Additional extraction” task after launching the Admin service.

Example of actions for changing the neural network model in Configurator:

Remote SDK container launch

You can run the Remote SDK service utilizing CPU (set by default) or GPU.

By default, the Remote SDK service is launched with all estimators and detectors enabled. If necessary, you can disable the use of some estimators or detectors when launching the Remote SDK container. Disabling unnecessary estimators enables you to save RAM or GPU memory, since when the Remote SDK service launches, the possibility of performing these estimates is checked and neural networks are loaded into memory. If you disable the estimator or detector, you can also remove its neural network from the Remote SDK container. See the “Enable/disable several estimators and detectors” section of the administrator manual for more information.

Run the Remote SDK service using one of the following commands according to the utilized processing unit.

Run Remote SDK utilizing CPU

Use the following command to launch the Remote SDK service using CPU:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5220 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/remote-sdk:/srv/logs \
--network=host \
--name=luna-remote-sdk \
--restart=always \
--detach=true \
dockerhub.visionlabs.ru/luna/luna-remote-sdk:v.0.4.0

Run Remote SDK utilizing GPU

The Remote SDK service does not utilize GPU by default. If you are going to use the GPU, then you should enable its use for the Remote SDK service in the Configurator service.

If you need to use the GPU for all estimators and detectors at once, then you need to use the “global_device_class” parameter in the “LUNA_REMOTE_SDK_RUNTIME_SETTINGS” section. All estimators and detectors will use the value of this parameter if the “device_class” parameter of their settings like "LUNA_REMOTE_SDK_<estimator-or-detector-name>_SETTINGS.runtime_settings" is set to “global” (by default for all estimators and detectors).

If you need to use the GPU for a specific estimator or detector, then you need to use the “device_class” parameter in sections like "LUNA_REMOTE_SDK_<estimator/detector-name>_SETTINGS.runtime_settings".

See section “Calculations using GPU” for additional requirements for GPU utilization.

Use the following command to launch the Remote SDK service using GPU:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5220 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--gpus device=0 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/remote-sdk:/srv/logs \
--network=host \
--name=luna-remote-sdk \
--restart=always \
--detach=true \
dockerhub.visionlabs.ru/luna/luna-remote-sdk:v.0.4.0

Here --gpus device=0 is the parameter specifies the used GPU device and enables GPU utilization. A single GPU can be utilized per Remote SDK instance. Multiple GPU utilization per instance is not available.

Run slim version of Remote SDK

You can run a slim version of the Remote SDK service that contains only configuration files without neural networks. It is assumed that the user himself will add the neural networks he needs to the container.

The launch of the slim version of the Remote SDK service is intended for advanced users.

To successfully launch the Remote SDK container with a custom set of neural networks, you need to perform the following actions:

Using the “enable-all-estimators-by-default” flag for the “EXTEND_CMD” variable, you can disable the use of all neural networks (estimators) by default, and then use special flags to explicitly specify which neural networks should be used. If you do not specify this flag or set the value “--enable-all-estimators-by-default=1”, the Remote SDK service will try to find all neural networks in the container. If one of the neural networks is not found, the Remote SDK service will not start.

List of available estimators:

Argument Description
--enable-all-estimators-by-default Enable all estimators by default.
--enable-human-detector Simultaneous detector of bodies and bodies.
--enable-face-detector Face detector.
--enable-body-detector Body detector.
--enable-face-landmarks5-estimator Face landmarks5 estimator.
--enable-face-landmarks68-estimator Face landmarks68 estimator.
--enable-head-pose-estimator Head pose estimator.
--enable-liveness-estimator Liveness estimator.
--enable-fisheye-estimator FishEye effect estimator.
--enable-face-detection-background-estimator Image background estimator.
--enable-face-warp-estimator Face sample estimator.
--enable-body-warp-estimator Body sample estimator.
--enable-quality-estimator Image quality estimator.
--enable-image-color-type-estimator Face color type estimator.
--enable-face-natural-light-estimator Natural light estimator.
--enable-eyes-estimator Eyes estimator.
--enable-gaze-estimator Gaze estimator.
--enable-mouth-attributes-estimator Mouth attributes estimator.
--enable-emotions-estimator Emotions estimator.
--enable-mask-estimator Mask estimator.
--enable-glasses-estimator Glasses estimator.
--enable-eyebrow-expression-estimator Eyebrow estimator.
--enable-red-eyes-estimator Red eyes estimator.
--enable-headwear-estimator Headwear estimator.
--enable-basic-attributes-estimator Basic attributes estimator.
--enable-face-descriptor-estimator Face descriptor extraction estimator.
--enable-body-descriptor-estimator Body descriptor extraction estimator.
--enable-body-attributes-estimator Body attributes estimator.
--enable-people-count-estimator People count estimator.
--enable-deepfake-estimator Deepfake estimator.

See the detailed information on enabling and disabling certain estimators in the section “Enable/disable several estimators and detectors” of the administrator manual.

Below is an example of a command to assign rights to a neural network file:

chown -R 1001:0 /var/lib/luna/current/<neural_network_name>.plan

Example of a command to run Remote SDK container with mounting neural networks for face detection and face descriptor extraction:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5220 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--env=EXTEND_CMD="--enable-all-estimators-by-default=0 --enable-face-detector=1 --enable-face-descriptor-estimator=1" \
-v /var/lib/luna/current/cnn59b_cpu-avx2.plan:/srv/fsdk/data/cnn59b_cpu-avx2.plan \
-v /var/lib/luna/current/FaceDet_v3_a1_cpu-avx2.plan:/srv/fsdk/data/FaceDet_v3_a1_cpu-avx2.plan \
-v /var/lib/luna/current/FaceDet_v3_redetect_v3_cpu-avx2.plan:/srv/fsdk/data/FaceDet_v3_redetect_v3_cpu-avx2.plan \
-v /var/lib/luna/current/slnet_v3_cpu-avx2.plan:/srv/fsdk/data/slnet_v3_cpu-avx2.plan \
-v /var/lib/luna/current/LNet_precise_v2_cpu-avx2.plan:/srv/fsdk/data/LNet_precise_v2_cpu-avx2.plan \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/remote-sdk:/srv/logs \
--network=host \
--name=luna-remote-sdk \
--restart=always \
--detach=true \
dockerhub.visionlabs.ru/luna/luna-remote-sdk:v.0.4.0

Handlers

Note: If you are not going to use the Handlers service, do not launch this container and disable the service utilization in Configurator. See section “Optional services usage”.

Handlers database migration

You need to execute migration scripts to update your Handlers database structure.

It is recommended to create the back up of your database before applying any changes.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/handlers:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-handlers:v.3.4.2 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

Handlers container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5090 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/handlers:/srv/logs \
--name=luna-handlers \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-handlers:v.3.4.2

Tasks

Note: If you are not going to use the Tasks service, do not launch the Tasks container and the Tasks Worker container. Disable the service utilization in Configurator. See section “Optional services usage”.

Tasks database migration

You need to execute migration scripts to update your Tasks database structure.

It is recommended to create the back up of your database before applying any changes.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/tasks:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-tasks:v.3.19.2 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

Tasks and Tasks Worker containers launch

Tasks service image includes the Tasks service and the Tasks Worker. They both must be launched.

The “task-result” bucket should be created for the Tasks service before the service launch. The buckets creation is described in the “Buckets creation”.

If it is necessary to use the Estimator task using a network disk, then you should first mount the directory with images from the network disk into special directories of Tasks and Tasks Worker containers. See the “Estimator task” section in the administrator manual for details.

Tasks Worker launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5051 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--env=SERVICE_TYPE="tasks_worker" \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/tasks-worker:/srv/logs \
--name=luna-tasks-worker \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-tasks:v.3.19.2

Tasks launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5050 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/tasks:/srv/logs \
--name=luna-tasks \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-tasks:v.3.19.2

Sender

Sender container launch

Note: If you are not going to use the Sender service, do not launch this container and disable the service utilization in Configurator. See section “Optional services usage”.

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5080 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/sender:/srv/logs \
--name=luna-sender \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-sender:v.2.10.2

API

API container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5000 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--name=luna-api \
--restart=always \
--detach=true \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/api:/srv/logs \
--network=host \
dockerhub.visionlabs.ru/luna/luna-api:v.6.23.0

Account creation using API service

The account is created using an HTTP request to the “create account” resource of the API service.

You can also create an account using the Admin service. This method requires an existing login and password (or the default login and password) and enables you to create an “admin” account. See the “Admin service” section of the administrator manual for details.

To create the account using a request to the API service, you need to provide the following mandatory data:

Create the account using your authentication details.

Note. Accounts migration (upgrading from 5.2.0…5.28.0 only). If you want to keep the ability to use the “account_id” that was used as the “Luna-Account-Id” header in versions 5.2.0…5.28.0 (without creating an account in the Admin service), then you need to link the old “account_id” to the account being created.

Example of CURL-request to the “create account” resource:

curl --location --request POST 'http://127.0.0.1:5000/6/accounts' \
--header 'Content-Type: application/json' \
--header 'Luna-Account-Id: <your_old_account_id>' \
--data '{
  "login": "user@mail.com",
  "password": "password",
  "account_type": "user",
  "description": "description"
}'

It is necessary to replace the authentication data from the example with your own.

To work with tokens, you must have an account.

Admin

Admin container launch

Note: If you are not going to use the Admin service, do not launch this container.

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5010 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/admin:/srv/logs \
--name=luna-admin \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-admin:v.5.5.2 

Monitoring data about the number of executed requests is saved in the luna-admin bucket of the InfluxDB. To enable data saving use the following command:

docker exec -it luna-admin python3 ./base_scripts/influx2_cli.py create_usage_task --luna-config http://127.0.0.1:5070/1

Backport 3

The section describes launching of Backport 3 service.

The service is not mandatory for utilizing LP5 and is required for emulation of LP 3 API only.

Backport 3 database migration

You need to execute migration scripts to update your Backport 3 DB structure.

It is recommended to create the back up of your database before applying any changes.

Run the following command to perform the Backport 3 DB migration.

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/backport3:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-backport3:v.0.10.2 \
alembic -x luna-config=http://127.0.0.1:5070/1 upgrade head

Accounts and tokens migration

Note. Accounts migration (upgrading from 5.2.0…5.28.0 only). Use the following command to migrate existing accounts and tokens from Backport 3 previous version:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/backport3:/srv/logs \
--rm \
--network=host \
--entrypoint bash dockerhub.visionlabs.ru/luna/luna-backport3:v.0.10.2 -c "cd ./base_scripts/migrate_accounts/ && pip3 install -r requirements-postgres.txt && python3 ./run.py --backport_db_url postgres://luna:luna@127.0.0.1:5432/luna_backport3 --accounts_db_url postgres://luna:luna@127.0.0.1:5432/luna_admin"

Here:

When migrating API and Faces service databases, all Backport 3 accounts will be migrated and stored in the database of the Accounts service. All migrated accounts will be of type “user”. The fields “password”, “email” and “organization_name” will be transferred from the “account” table of the Backport 3 database to the “account” table of the Accounts database under new names - “password”, “login” and “description” respectively. Tokens will remain stored in the Backport3 database, but their identifier will also be entered in the Accounts database, where the necessary permissions will be automatically set.

Backport 3 container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5140 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--name=luna-backport3 \
--restart=always \
--detach=true \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/backport3:/srv/logs \
--network=host \
dockerhub.visionlabs.ru/luna/luna-backport3:v.0.10.2

User Interface 3

The User Interface 3 is used with the Backport 3 service only.

User Interface 3 container launch

Use the following command to launch the service:

docker run \
--env=PORT=4100 \
--env=LUNA_API_URL=http://127.0.0.1:5140 \
--name=luna-ui-3 \
--restart=always \
--detach=true \
--network=host \
-v /etc/localtime:/etc/localtime:ro \
dockerhub.visionlabs.ru/luna/luna3-ui:v.0.5.10

Here:

Backport 4

The section describes launching of Backport 4 service.

The service is not mandatory for utilizing LP5 and is required for emulation of LP 4 API only.

Backport 4 container launch

Use the following command to launch the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5130 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--name=luna-backport4 \
--restart=always \
--detach=true \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/backport4:/srv/logs \
--network=host \
dockerhub.visionlabs.ru/luna/luna-backport4:v.1.4.2

User Interface 4

The User Interface 4 is used with the Backport 4 service only.

User Interface 4 container launch

Note: You should have the account with account type user before launching the User Interface 4 container. Its login and password in Base64 format will be used to work with the user interface.

Use the following command to launch the service:

docker run \
--env=PORT=4200 \
--env=LUNA_API_URL=http://<server_external_ip>:5130 \
--env=BASIC_AUTH=dXNlckBtYWlsLmNvbTpwYXNzd29yZA== \
--name=luna-ui-4 \
--restart=always \
--detach=true \
--network=host \
-v /etc/localtime:/etc/localtime:ro \
dockerhub.visionlabs.ru/luna/luna4-ui:v.0.1.5

Here:

You should use the external IP of the service, not localhost.

You should specify the Backport 4 service port (“5130” is set by default).

Lambda

Working with the Lambda service is possible only when deploying LUNA PLATFORM services in Kubernetes. To use it, you need to deploy LUNA PLATFORM services in Kubernetes yourself or consult VisionLabs specialists. Use the commands below as reference information.

Note: If you are not going to use the Lambda service, do not run this container.

Enable the use of the Lambda service (see the section “Using optional services”).

Prepare Docker registry

It is necessary to prepare a registry for storing Lambda docker images. Transfer the base images and Kaniko executor image to your registry using the following commands.

Upload the images from the remote repository to the local image storage.

docker pull dockerhub.visionlabs.ru/luna/lpa-lambda-base-fsdk:v.0.0.45
docker pull dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.0.45
docker pull dockerhub.visionlabs.ru/luna/kaniko-executor:latest

Add new names to the images by replacing new-registry on their own. The names of the base images in the user registry must be the same as in the dockerhub.visionlabs.ru/luna registry.

docker tag dockerhub.visionlabs.ru/luna/lpa-lambda-base-fsdk:v.0.0.45 new-registry/lpa-lambda-base-fsdk:v.0.0.45
docker tag dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.0.45 new-registry/lpa-lambda-base:v.0.0.45
docker tag dockerhub.visionlabs.ru/luna/kaniko-executor:latest new-registry/kaniko-executor:latest

Push local images to your remote repository by replacing new-registry on their own.

docker push new-registry/lpa-lambda-base-fsdk:v.0.0.45
docker push new-registry/lpa-lambda-base:v.0.0.45
docker push new-registry/kaniko-executor:latest

Create Lambda database

Use the following command to create a Lambda database in PostgreSQL:

docker exec -it postgres psql -U luna -c "CREATE DATABASE luna_lambda;"

Lambda DB tables creation

Use the following command to create the Lambda DB tables:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/lambda:/srv/logs \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/luna-lambda:v.0.2.0 \
python3 ./base_scripts/db_create.py --luna-config http://localhost:5070/1

Lambda container launch

Use the following command to start the service:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5210 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/lambda:/srv/logs \
--name=luna-lambda \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-lambda:v.0.2.0

Additional information

This section provides the following additional information:

Monitoring and logs visualization using Grafana

Monitoring visualization is performed by the LUNA Dashboards service, which contains the Grafana monitoring data visualization platform with configured LUNA PLATFORM dashboards.

If necessary, you can install customized dashboards for Grafana separately. See the “LUNA Dashboards” section in the administrator manual for more information.

Together with Grafana, you can use the Grafana Loki log aggregation system, which enables you to flexibly work with LUNA PLATFORM logs. The Promtail agent is used to deliver LUNA PLATFORM logs to Grafana Loki (for more information, see the “Grafana Loki” section in the administrator manual).

LUNA Dashboards

Note: To work with Grafana you need to use InfluxDB version 2.

Note: Before updating, make sure that the old LUNA Dashboards container is deleted.

Run LUNA Dashboards container

Use the docker run command with these parameters to run Grafana:

docker run \
--restart=always \
--detach=true \
--network=host \
--name=grafana \
-v /etc/localtime:/etc/localtime:ro \
dockerhub.visionlabs.ru/luna/luna-dashboards:v.0.0.9

Use “http://IP_ADDRESS:3000” to go to the Grafana web interface when the LUNA Dashboards and InfluxDB containers are running.

Grafana Loki

Note: Grafana Loki requires LUNA Dashboards to be running.

Note: Before updating, make sure that the old Grafana Loki and Promtail containers are removed.

Run Grafana Loki container

Use the docker run command with these parameters to run Grafana Loki:

docker run \
--name=loki \
--restart=always \
--detach=true \
--network=host \
-v /etc/localtime:/etc/localtime:ro \
dockerhub.visionlabs.ru/luna/loki:2.7.1

Run Promtail container

Use the docker run command with these parameters to run Promtail:

docker run \
-v /var/lib/luna/current/example-docker/logging/promtail.yml:/etc/promtail/luna.yml \
-v /var/lib/docker/containers:/var/lib/docker/containers \
-v /etc/localtime:/etc/localtime:ro \
--name=promtail \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/promtail:2.7.1 \
-config.file=/etc/promtail/luna.yml -client.url=http://127.0.0.1:3100/loki/api/v1/push -client.external-labels=job=containerlogs,pipeline_id=,job_id=,version=

Here:

Docker commands

Show containers

To show the list of launched Docker containers use the command:

docker ps

To show all the existing Docker containers use the command:

docker ps -a 

Copy files to container

You can transfer files into the container. Use the docker cp command to copy a file into the container.

docker cp <file_location> <container_name>:<folder_inside_container>

Enter container

You can enter individual containers using the following command:

docker exec -it <container_name> bash

To exit the container, use the command:

exit

Images names

You can see all the names of the images using the command:

docker images

Delete image

If you need to delete an image:

docker rmi -f 61860d036d8c

Delete all the existing images.

docker rmi -f $(docker images -q)

Stop container

You can stop the container using the command:

docker stop <container_name>

Stop all the containers:

docker stop $(docker ps -a -q)

Delete container

If you need to delete a container:

docker container rm -f 23f555be8f3a

Delete all the containers.

docker container rm -f $(docker container ls -aq)

Check service logs

You can use the following command to show logs for the service:

docker logs <container_name>

Launching parameters description

When launching a Docker container for a LUNA PLATFORM service you should specify additional parameters required for the service launching.

The parameters specific for a particular container are described in the section about this container launching.

All the parameters given in the service launching example are required for proper service launching and utilization.

Launching services parameters

Example command of launching LP services containers:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=<Port_of_the_launched_service> \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/<service>:/srv/logs/ \
--name=<service_container_name> \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/<service-name>:<version>

The following parameters are used when launching LP services containers:

Links to download the container images you need are available in the description of the corresponding container launching.

Service arguments

Each service in LUNA PLATFORM has its own launch arguments. These arguments can be passed through:

Some arguments can only be passed by setting a flag. For the Handlers and Remote SDK services, it is possible to use the environment variable “EXTEND_CMD” to explicitly pass flags. See the example of using the “EXTEND_CMD” variable in the “Run slim version of Remote SDK” section.

For example, using the --help flag you can get a list of all available arguments. An example of passing an argument to an API service:

docker run --rm dockerhub.visionlabs.ru/luna/luna-api:v.6.23.0 python3 /srv/luna_api/run.py --help

List of main arguments:

Launch flag Environment variable Description
--port PORT Port on which the service will listen for connections.
--workers WORKER_COUNT Number of workers for the service.
--log_suffix --log_suffix LOG_SUFFIX LOG_SUFFIX Suffix added to log file names (with the option to write logs to a file enabled).
--config-reload RELOAD_CONFIG Enable automatic configuration reload. See “Automatic configurations reload” in the LUNA PLATFORM 5 administrator manual.
--pulling-time RELOAD_CONFIG_INTERVAL Configuration checking period (default 10 seconds). See “Automatic configurations reload” in the LUNA PLATFORM 5 administrator manual.
--luna-config --luna-config CONFIGURATOR_HOST, CONFIGURATOR_PORT Address of the Configurator service for downloading settings. For --luna-config it is sent in the format http://localhost:5070/1. For environment variables, the host and port are set explicitly. If the argument is not given, the default configuration file will be used.
--config None Path to the file with service configurations.
--<config_name> None

Tag of the specified configuration in the Configurator. When setting this configuration, the value of the tagged configuration will be used. Example: --INFLUX_MONITORING TAG_1

Note: You must pre-tag the appropriate configuration in. Configurator.

Note: Only works with the --luna-config flag.

The list of arguments may vary depending on the service.

It is also possible to override the settings of services at their start using environment variables.

The VL_SETTINGS prefix is used to redefine the settings. Examples:

Creating DB parameters

Example command of launching containers for database migration or database creation:

docker run \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/<service>:/srv/logs/ \
--rm \
--network=host \
dockerhub.visionlabs.ru/luna/<service-name>:<version> \
python3 ./base_scripts/db_create.py --luna-config http://localhost:5070/1

The following parameters are used when launching containers for database migration or database creation:

Here:

Logging to server

To enable saving logs to the server, you should:

Create logs directory

Below are examples of commands for creating directories for saving logs and assigning rights to them for all LUNA PLATFORM services.

mkdir -p /tmp/logs/configurator /tmp/logs/image-store /tmp/logs/accounts /tmp/logs/faces /tmp/logs/licenses /tmp/logs/events /tmp/logs/python-matcher /tmp/logs/handlers /tmp/logs/remote-sdk /tmp/logs/tasks /tmp/logs/tasks-worker /tmp/logs/sender /tmp/logs/api /tmp/logs/admin /tmp/logs/backport3 /tmp/logs/backport4
chown -R 1001:0 /tmp/logs/configurator /tmp/logs/image-store /tmp/logs/accounts /tmp/logs/faces /tmp/logs/licenses /tmp/logs/events /tmp/logs/python-matcher /tmp/logs/handlers /tmp/logs/remote-sdk /tmp/logs/tasks /tmp/logs/tasks-worker /tmp/logs/sender /tmp/logs/api /tmp/logs/admin /tmp/logs/backport3 /tmp/logs/backport4

If you need to use the Python Matcher Proxy service, then you need to additionally create the /tmp/logs/python-matcher-proxy directory and set its permissions.

Logging activation

LP services logging activation

To enable logging to file, you need to set the log_to_file and folder_with_logs settings in the <SERVICE_NAME>_LOGGER section of the settings for each service.

Automatic method (before/after starting Configurator)

To update logging settings, you can use the logging.json settings file provided with the distribution package.

Run the following command after starting the Configurator service:

docker cp /var/lib/luna/current/extras/conf/logging.json luna-configurator:/srv/luna_configurator/used_dumps/logging.json

Update your logging settings with the copied file.

docker exec -it luna-configurator python3 ./base_scripts/db_create.py --dump-file /srv/luna_configurator/used_dumps/logging.json

Manual method (after starting Configurator)

Go to the Configurator service interface (127.0.0.1:5070) and set the logs path in the container in the folder_with_logs parameter for all services whose logs need to be saved. For example, you can use the path /srv/logs.

Set the log_to_file option to true to enable logging to a file.

Configurator service logging activation (before/after Configurator start)

The Configurator service settings are not located in the Configurator user interface, they are located in the following file:

/var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf

You should change the logging parameters in this file before starting the Configurator service or restart it after making changes.

Set the path to the logs location in the container in the FOLDER_WITH_LOGS = ./ parameter of the file. For example, FOLDER_WITH_LOGS = /srv/logs.

Set the log_to_file option to true to enable logging to a file.

Mounting directories with logs when starting services

The log directory is mounted with the following argument when starting the container:

-v <server_logs_folder>:<container_logs_folder> \

where <server_logs_folder> is the directory created in the create logs directory step, and <container_logs_folder> is the directory created in the activate logging step.

Example of command to launch the API service with mounting a directory with logs:

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5000 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--name=luna-api \
--restart=always \
--detach=true \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/api:/srv/logs \
--network=host \
dockerhub.visionlabs.ru/luna/luna-api:v.6.23.0

The example container launch commands in this documentation contain these arguments.

Docker log rotation

To limit the size of logs generated by Docker, you can set up automatic log rotation. To do this, add the following data to the /etc/docker/daemon.json file:

{
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m",
        "max-file": "5"
    }
}

This will allow Docker to store up to 5 log files per container, with each file being limited to 100MB.

After changing the file, you need to restart Docker:

systemctl reload docker

The above changes are the default for any newly created container, they do not apply to already created containers.

Set custom InfluxDB settings

If you are going to use InfluxDB OSS 2, then you need to update the monitoring settings in Configurator service.

There are the following settings for InfluxDB OSS 2:

"send_data_for_monitoring": 1,
"use_ssl": 0,
"flushing_period": 1,
"host": "127.0.0.1",
"port": 8086,
"organization": "<ORGANIZATION_NAME>",
"token": "<TOKEN>",
"bucket": "<BUCKET_NAME>",
"version": <DB_VERSION>

You can update InfluxDB settings in the Configurator service by following these steps:

vi /var/lib/luna/current/extras/conf/influx2.json
docker cp /var/lib/luna/current/extras/conf/influx2.json luna-configurator:/srv/
docker exec -it luna-configurator python3 ./base_scripts/db_create.py --dump-file /srv/influx2.json

You can also manually update settings in the Configurator service user interface.

The Configurator service configurations are set separately.

vi /var/lib/luna/current/example-docker/luna_configurator/configs/luna_configurator_postgres.conf
docker restart luna-configurator

Use Python Matcher with Python Matcher Proxy

As mentioned earlier, along with the Python Matcher service, you can additionally use the Python Matcher Proxy service, which will redirect matching requests either to the Python Matcher service or to the matching plugins. Plugins may significantly improve matching processing performance. For example, it is possible to organize the storage of the data required for matching operations and additional objects fields in separate storage using plugins, which will speed up access to the data compared to the use of the standard LUNA PLATFORM database.

To use the Python Matcher service with Python Matcher Proxy, you should additionally launch the appropriate container, and then set a certain setting in the Configurator service. Follow the steps below only if you are going to use matching plugins.

See the description and usage of matching plugins in the administrator manual.

Python Matcher proxy container launch

Use the following command to launch the service:

After starting the container, you need to set the "luna_matcher_proxy":true parameter in the “ADDITIONAL_SERVICES_USAGE” section in the Configurator service.

docker run \
--env=CONFIGURATOR_HOST=127.0.0.1 \
--env=CONFIGURATOR_PORT=5070 \
--env=PORT=5110 \
--env=WORKER_COUNT=1 \
--env=RELOAD_CONFIG=1 \
--env=RELOAD_CONFIG_INTERVAL=10 \
--env=SERVICE_TYPE="proxy" \
-v /etc/localtime:/etc/localtime:ro \
-v /tmp/logs/python-matcher-proxy:/srv/logs \
--name=luna-python-matcher-proxy \
--restart=always \
--detach=true \
--network=host \
dockerhub.visionlabs.ru/luna/luna-python-matcher:v.1.8.2

After launching the container, you need to set the following value in the Configurator service.

ADDITIONAL_SERVICES_USAGE = "luna_matcher_proxy":true