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.txt --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.1.42
docker pull dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.1.42
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.1.42 new-registry/lpa-lambda-base-fsdk:v.0.1.42
docker tag dockerhub.visionlabs.ru/luna/lpa-lambda-base:v.0.1.42 new-registry/lpa-lambda-base:v.0.1.42
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.1.42
docker push new-registry/lpa-lambda-base:v.0.1.42
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 createdServiceAccount
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/luna_v.5.75.0/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/luna_v.5.75.0/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/luna_v.5.75.0/extras/VLMatch/oracle/make.sh
- Open the directory and run the "make.sh" file.
cd /var/lib/luna/luna_v.5.75.0/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.