BAF Lite installation instructions
Environment preparation
Downloading the distribution
Download and unpack the BAF Lite distribution onto the machine where you plan to perform the installation. You can use the following command:
$ curl --output baf_lite.zip <distribution_link>
In the curl request, specify the link to the BAF Lite distribution (zip file).
A link to the folder containing the distribution and accompanying documentation in PDF format will be sent via email.
Next, move the license file face_sdk.lic (attached to the email) to the setup folder.
Make sure the license file is named exactly face_sdk.lic. Using a different name will cause secret generation errors.
The BAF Lite installation package includes:
- ./cli.sh — entry point for running commands.
- ./cfg — folder containing configuration files.
All subsequent commands must be executed from the setup directory in the system console.
Loading images
Load the product images into the local registry from the archive:
$ ./cli.sh generic load-images
Load the infrastructure images into the local registry from the archive:
$ ./cli.sh smc load-images
Configuration
Basic configuration
Enter environment variables
Globally, environment variables can be divided into three categories:
- Environment variables of system elements not related to Helm charts;
- Public environment variables of the module chart;
- Secret environment variables of the module chart.
The first category uses the format <variable_name>=<value> and is represented by the following files:
| Configuration file | Variable name | Description |
| ./cfg/smc.settings.cfg | apiserver_advertise_address | address for kube-apiserver, usually the machine's internal IP address. |
| external_ip_address | address for ingress-controller, specify the machine's external IP address. |
The second category uses YAML format. These settings are subsequently applied directly during chart installation as external values to override the internal values of the Helm chart. Each chart has a complete standard set of environment variables. Only those variables that need to be changed are included in the external values files.
For changing most environment variables, a flexible mechanism is provided that allows passing YAML objects directly to the final deployment template.
For services that support this configuration, the envOverride field is used. In this field, in the form of a YAML dictionary, the key is the variable name, and the value is a YAML object that will be inserted into the final template as the service's environment variable.
Example:
envOverride:
JWT_CLOCK_SKEW:
value: '1'
All variable values must be strings. Otherwise, a deployment error will occur.
Flexible customisation of environment variables is available in the following files:
| Configuration file | Configuration section | Variable name | Default value | Description |
| ./cfg/authentification-service.values.yaml | authentification_service | JWT_LEEWAY | value: '1' | allowed system time difference between servers (clock skew) used when validating JWT tokens. |
| ./cfg/util-services.values.yaml | client_log | JWT_CLOCK_SKEW | value: '1' | allowed system time difference between servers (clock skew) used when validating JWT tokens. The value must match the JWT_LEEWAY parameter in the authentification-service.values.yaml file. |
| ./cfg/video-recorder.values.yaml | video_recorder | UVICORN_CONCURRENCY | value: '30' | number of simultaneously processed HTTP connections per pod. Exceeding the limit will return a 503 error. |
| SQLALCHEMY_POOL_SIZE | value: '20' | maximum number of persistent connections that the SQLAlchemy pool will maintain per pod. | ||
| SQLALCHEMY_POOL_OVERFLOW | value: '10' | number of connections above the persistent limit that will be closed after use per pod. | ||
| RETENTION_BATCH_SIZE | value: '83' | size of the batch of attempt video content to be deleted at one time. | ||
| RETENTION_BATCH_PAUSE | value: '4' | time in seconds between batch deletions. | ||
| RETENTION_CHECK_FREQUENCY | value: '3600' | frequency of cleanup check execution in seconds. | ||
| JWT_CLOCK_SKEW | value: '1' | allowed system time difference between servers (clock skew) used when validating JWT tokens. The value must match the JWT_LEEWAY parameter in the authentification-service.values.yaml file. | ||
| minio | S3_ERROR_DATA_RETENTION_DAYS | value: '3' | retention period for error data in days in the object storage. | |
| MINIO_API_DELETE_CLEANUP_INTERVAL | value: '30s' | interval at which MinIO deletes objects from the bucket. | ||
| S3_BUCKETS_PREFIX | value: 'vr' | prefix placed before all bucket names in the following format: <prefix>.<bucket name> | ||
| S3_USE_HTTPS | value: '0' | flag that determines whether to use the HTTPS protocol when interacting with S3. |
There are also classic variables that are substituted into the template by value. This is either due to the complex logic of their use in charts or the lack of need for deep customization.
Values written with dots in YAML files indicate a nested structure.
List of files with classic variables:
| Configuration file | Variable path | Description |
| ./cfg/authentification-service.values.yaml | ingress.enable | set the parameter value to 1 to provide external access to the authentication service via an ingress resource. The ingress will use the domain from the ingress.rules.gateway.host parameter. |
| ./cfg/baf-lite.values.yaml | ingress.rules.gateway.host | domain name used in the ingress for routing requests to Kubernetes services for BAF Lite. |
| gateway.dns_resolver | domain name of the DNS server that will be used for resolving Kubernetes service names. | |
| gateway.dns_validity_time | time after which the DNS name will be re-resolved. | |
| gateway.cluster_domain | the k8s cluster domain that will be used in the path to the video-recorder service. | |
| ./cfg/video-recorder.values.yaml | minio.enable | if you are using your own MinIO server, set to 0. Note: change the values of the video-recorder-minio secret in the ./cfg/video_recorder.secrets.json file and the minio.host, minio.port and S3_USE_HTTPS (1 for https, 0 for http) fields in the current file. |
| video_recorder.decoding_enabled | if you do not need video decoding, set to 0. | |
| video_recorder.decoding_process_count | number of decoding processes run in a single service replica. The more processes, the more simultaneous video decoding sessions the service can handle. | |
| video_recorder.retention_workers_count | number of processes performing video content cleanup. | |
| postgres.deploy | if you have your own database, set to 0. Note: change the values of the video-recorder-postgres secret in the ./cfg/video_recorder.secrets.json file and the postgres.host, postgres.port fields. | |
| redis.deploy | if you have your own Redis, set to 0. Note: change the redis.host, redis.port fields. | |
| ./cfg/util-services.values.yaml | ingress.rules.gateway.host | must be equal to the ingress domain in the ./cfg/baf.values.yaml file. |
| ./cfg/image-api.values.json | processing.enable_ingress | set the parameter value to 1 to provide external access to the image-api module via an ingress resource. The ingress will use the domain from the ingress.host parameter. |
| ingress.host | domain name used in the ingress for routing requests to Kubernetes services for the image-api module. |
The third category is stored in JSON files and is used by delivery scripts to create secrets inside the Kubernetes cluster.
If you need to use your own secrets, add to envOverride (in the values.yaml file of the corresponding module) a variable with the name of the variable associated with the secret, and describe in it the correct YAML for obtaining data from your secret.
List of secret files and their environment variables:
| Configuration file | Secret name | Secret description | Secret field | (values.yaml file) Section\Environment variable name |
| ./cfg/authentification-service.secrets.json | jwt-keys | key data for token signing and verification. | private | authentification_service\JWT_PRIVATE_KEY |
| public |
| |||
| ./cfg/video-recorder.secrets.json | video-recorder-postgres | database connection details. | user | video_recorder\POSTGRES_USER |
| password | video_recorder\POSTGRES_PASSWORD | |||
| db | video_recorder\POSTGRES_DB | |||
| video-recorder-token | access token for the service's internal APIs. | access_token | video_recorder\TOKEN | |
| vr-postgres-root-credentials | username and password for the root user in the database. | user |
| |
| password |
| |||
| video-recorder-minio | MinIO connection details. | user | minio\MINIO_ROOT_USER | |
| password | minio\MINIO_ROOT_PASSWORD |
Updating configuration of a running instance
To apply updates to module values, run the module installation command. If the update doesn't take effect, uninstall and reinstall the module.
For updates involving module resources (e.g., secrets), execute the module resource installation command. Then, restart the module pods using Kubernetes tools to ensure they pick up the changes.
Extended configuration (optionally)
Docker settings for GPU usage
To set nvidia-container-runtime as the default low-level runtime, run the following command:
./cli.sh smc nvidia install
Configuring GPU usage in BAF
To enable GPU in BAF, you need to override the CONFIGS variable for the face-detector-template-extractor service. This is done in the ./cfg/image-api.values.yaml file.
In the processing.services section, add the following YAML object:
face-detector-template-extractor:
envOverride:
CONFIGS:
value: '{"capturer": {"name": "common_capturer_uld_fda.xml", "params": {"use_avx2": 0, "downscale_rawsamples_to_preferred_size": 0}}, "recognizer": {"name": "method12v1000_recognizer.xml", "params": {"use_avx2": 0, "use_cuda": 1}}}'
Install and configure a cluster
If you already have a deployed cluster, move to Configure licensing section.
To create and configure the cluster, run the following commands:
./cli.sh smc system-patch
./cli.sh smc install
These commands:
- Create database mount point.
- Initialize a cluster.
- Install the secrets.
To use GPU in a cluster, install NVIDIA device plugin:
$ ./cli.sh smc nvidia install
Cluster health check
After initializing the master node, make sure that all nodes are ready for operation and have the Ready status. You can check this by running the command below:
$ kubectl get nodes
As a result, the following output will be displayed in the terminal:
NAME STATUS ROLES AGE VERSION
master-node Ready control-plane,master 11d v1.23.8
To check all cluster components, run the following command:
$ kubectl get all --all-namespaces
Deploying BAF Lite
Starting the Deployment
Installing the image-api subsystem.
Run the command to install the module secrets for the cluster:
$ ./cli.sh image-api install-secrets
Run the module installation:
$ ./cli.sh image-api install
Installing the Authentication subsystem
Run the command to generate JWT signing keys:
$ ./cli.sh authentification-service generate-jwt-keys
As a result, you will receive two ECDsa keys, which must be added to the configuration file ./cfg/authentification-service.secrets.json in the jwt-keys section. Run the command to install the secrets:
$ ./cli.sh authentification-service install-secrets
Run the command to install the module:
$ ./cli.sh authentification-service install
Installing the Video Recorder (VR) subsystem
Create directories for storing object storage and relational database data using the commands:
$ ./cli.sh video-recorder minio-create-mountpoint
$ ./cli.sh video-recorder postgres-create-mountpoint
Run the command to install Video Recorder secrets:
$ ./cli.sh video-recorder install-secrets
Run the command to install Video Recorder:
$ ./cli.sh video-recorder install
Installing the Util Services (US) subsystem
To install Util Services, run the command:
$ ./cli.sh util-services install
Installing BAF Lite
Run the module installation:
$ ./cli.sh baf-lite install
To monitor the deployment progress, open another terminal tab and enter the following command:
$ watch 'kubectl get pods'
All pods having the Running status means that BAF Lite is up and running.
Configure DNS server
To provide access to BAF, DNS server on your network should contain a record that domain is available at <external_ip_address>.
For testing you need to fill in IP address and domain in the /etc/hosts file on Linux or C:\Windows\System32\drivers\etc\hosts on Windows.
To do this, add a new line like <external_ip_address> <host> at the end of this file, set the values for the corresponding variables and save the file. Note that you need to have administrator privileges to edit the hosts file.