Additional information

This section provides the following additional information:

• Steps to create a Docker registry-authentication-secret.
• Steps to launch Lambda.
• Nuances of using GPU in Minikube.
• VLMatch library compilation example for Oracle.

Create Docker registry authentication secret

To download images with LUNA PLATFORM services you need to authorize in the Docker registry.

Create a credentials file, such as vlabs-credentials.json, containing the login and password:

{
  "auths": {
    "dockerhub.visionlabs.ru": {
      "username": "your_username",
      "password": "your_password"
    }
  }
}

Grant Kubernetes access to the registry with Docker images.

kubectl create secret generic my-dockerhub-secret --from-file=.dockerconfigjson=vlabs-credentials.json --type=kubernetes.io/dockerconfigjson

If you have previously authorized via the docker login command, you can grant Kubernetes access using the following command:

kubectl create secret generic my-dockerhub-secret --from-file=.dockerconfigjson=$HOME/.docker/config.json --type=kubernetes.io/dockerconfigjson

The secret can be specified during Helm chart setting.

Launch Lambda

To run Lambda, you need to do some additional steps.

Prepare user Docker registry for Lambda

Note: Skip this section if you are not going to use the Lambda service.

You need to prepare the user registry for storing Lambda images. Transfer the base images and the container assembly tool to your registry using the commands below.

Upload the images from the remote repository to the local image repository:

docker pull dockerhub.visionlabs.ru/luna/lpa-lambda-base-fsdk:v.0.5.29

docker pull dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.5.29

Upload the used container build tool image:

docker pull dockerhub.visionlabs.ru/luna/kaniko-executor:latest

Add new names to the images by replacing new-registry with your own. The names of the base images in the custom registry should be the same as in the dockerhub.visionlabs.visionlabs.ru/luna registry.

docker tag dockerhub.visionlabs.ru/luna/lpa-lambda-base-fsdk:v.0.5.29 new-registry/lpa-lambda-base-fsdk:v.0.5.29

docker tag dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.5.29 new-registry/lpa-lambda-base:v.0.5.29

docker tag dockerhub.visionlabs.ru/luna/kaniko-executor:latest new-registry/kaniko-executor:latest

Send local images to your remote repository, replacing new-registry with your own.

docker push new-registry/lpa-lambda-base-fsdk:v.0.5.29

docker push new-registry/lpa-lambda-base:v.0.5.29

docker push new-registry/kaniko-executor:latest

Configuring access for Lambda

Note: Skip this section if you are not going to use the Lambda service.

For the Lambda service to work properly, access to Kubernetes resources must be properly configured to ensure the security and efficient management of the service. This can be done, for example, by defining roles and role bindings using the Role Based Access Control (RBAC) mechanism.

The example below shows how to configure accesses using RBAC in Kubernetes for the Lambda service:

• Define an object of type ServiceAccount, which represents the identifier used by the service to interact with the Kubernetes API server:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: lambda-user

• Define a Role object type that defines a set of permissions for the resources your service will work with:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: production
  name: lambda-admin-role
rules:
- apiGroups: ["", "apps", "networking.k8s.io"]
  resources: ["deployments", "pods", "pods/log", "pods/status", "services", "services/proxy", "ingresses"]
  verbs: ["get", "watch", "list", "create", "delete", "patch"]

Here, services/proxy means the ability to send requests to the /lambdas/\{lambda_id\}/proxy resource of the Lambda service.

• Define a RoleBinding object type that binds a role to the created ServiceAccount type, determining which resources and operations are available to the Lambda service:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-lambda
  namespace: production
subjects:
- kind: ServiceAccount
  name: lambda-user
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: lambda-admin-role

Start installation of Helm chart for Lambda

Navigate to the directory with the Helm charts.

cd /var/lib/luna/current/extras/k8s

Run the Helm charts installation for the required services using the following commands:

helm install --wait --timeout 10m luna-lambda ./luna-lambda

Use GPU in Minikube

Minikube is a tool for locally installing and managing a Kubernetes cluster. It is used by developers and testers to build and test applications in a local environment before deploying them to larger Kubernetes clusters.

The use of GPUs in Minikube is only supported from version 1.32.

Each LUNA PLATFORM service that supports GPU running automatically creates GPU processes, regardless of which resources (CPU or GPU) are installed. If more than one GPU service is running, the GPU resources must be shared between them to avoid possible errors caused by video card access conflicts.

See official NVIDIA documentation for more information about GPU resource sharing.

To isolate services from the GPU and prevent them from creating additional processes, set the CUDA_VISIBLE_DEVICES/NVIDIA_VISIBLE_DEVICES environment variable to none for those services that use the GPU and should not be used.

env:
  - name: CUDA_VISIBLE_DEVICES
    value: none

VLMatch library compilation for Oracle

Note: The following instructions describe the installation for Oracle 21c.

All files required to compile a user-defined extension (UDx) into VLMatch can be found in the following directory:

/var/lib/luna/current/extras/VLMatch/oracle

To compile the VLMatch UDx function you need to:

• Install the required environment, see. requirements:

sudo yum install gcc g++ 

• Change the SDK_HOME — oracle sdk root variable (default is $ORACLE_HOME/bin, check that the $ORACLE_HOME environment variable is set) in the makefile.

vi /var/lib/luna/current/extras/VLMatch/oracle/make.sh

• Open the directory and run the "make.sh" file.

cd /var/lib/luna/current/extras/VLMatch/oracle

chmod +x make.sh

./make.sh

• Define the library and function inside the database (from the database console):

CREATE OR REPLACE LIBRARY VLMatchSource AS '$ORACLE_HOME/bin/VLMatchSource.so';
CREATE OR REPLACE FUNCTION VLMatch(descriptorFst IN RAW, descriptorSnd IN RAW, length IN BINARY_INTEGER)
   RETURN BINARY_FLOAT 
AS
   LANGUAGE C
   LIBRARY VLMatchSource
   NAME "VLMatch"
   PARAMETERS (descriptorFst BY REFERENCE, descriptorSnd BY REFERENCE, length UNSIGNED SHORT, RETURN FLOAT);

• Test the function by calling (from the database console):

SELECT VLMatch(HEXTORAW('1234567890123456789012345678901234567890123456789012345678901234'), HEXTORAW('0123456789012345678901234567890123456789012345678901234567890123'), 32) FROM DUAL;

The result should be "0.4765625".

Transfer the generated VLMatchSource.so file to the Oracle DBMS.