mirror of
https://github.com/trustgraph-ai/trustgraph.git
synced 2026-07-02 02:58:10 +02:00
Squashed 'ai-context/trustgraph-templates/' content from commit 42a5fd1b
git-subtree-dir: ai-context/trustgraph-templates git-subtree-split: 42a5fd1b678f32be378062e30451e2052ccb95dd
This commit is contained in:
commit
74cc8a4685
1216 changed files with 116347 additions and 0 deletions
|
|
@ -0,0 +1,25 @@
|
|||
When you download the deploy configuration, you will have a ZIP file containing all the configuration needed to launch TrustGraph in Docker Compose. Unzip the ZIP file:
|
||||
|
||||
```bash
|
||||
unzip deploy.zip
|
||||
```
|
||||
|
||||
On MacOS, it may be necessary to specify a destination directory for the TrustGraph package:
|
||||
|
||||
```bash
|
||||
unzip deploy.zip -d deploy
|
||||
```
|
||||
|
||||
Navigate to the `docker-compose` directory. From this directory, launch TrustGraph with:
|
||||
|
||||
```bash
|
||||
docker compose -f docker-compose.yaml up -d
|
||||
```
|
||||
|
||||
If you are on Linux, running SELinux, you may need to change permissions on files in the deploy bundle so that they are accessible from within containers. This affects the `grafana` and `prometheus` directories.
|
||||
|
||||
```bash
|
||||
chcon -Rt svirt_sandbox_file_t grafana prometheus
|
||||
chmod 755 prometheus/ grafana/ grafana/*/
|
||||
chmod 644 prometheus/* grafana/*/*
|
||||
```
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
To deploy to Kubernetes, you likely need to have Kubernetes credentials set up to connect to the Kubernetes management service. The mechanism to do this varies with the different kinds of Kubernetes services in use, check with your cloud provider documentation.
|
||||
|
||||
When you download the deploy configuration, you will have a ZIP file containing all the configuration needed to launch TrustGraph on Kubernetes. Unzip the ZIP file:
|
||||
|
||||
```bash
|
||||
unzip deploy.zip
|
||||
```
|
||||
|
||||
and launch:
|
||||
|
||||
```bash
|
||||
kubectl apply -f resources.yaml
|
||||
```
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
When you download the deploy configuration, you will have a ZIP file containing all the configuration needed to launch TrustGraph in Podman Compose. Unzip the ZIP file:
|
||||
|
||||
```bash
|
||||
unzip deploy.zip
|
||||
```
|
||||
|
||||
Navigate to the `docker-compose` directory. From this directory, launch TrustGraph with:
|
||||
|
||||
```bash
|
||||
podman compose -f docker-compose.yaml up -d
|
||||
```
|
||||
|
||||
If you are on Linux, running SELinux, you may need to change permissions on files in the deploy bundle so that they are accessible from within containers. This affects the `grafana` and `prometheus` directories.
|
||||
|
||||
```bash
|
||||
chcon -Rt svirt_sandbox_file_t grafana prometheus
|
||||
chmod 755 prometheus/ grafana/ grafana/*/
|
||||
chmod 644 prometheus/* grafana/*/*
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
Document RAG APIs are separate from GraphRAG. You can use `tg-invoke-document-rag` to test Document RAG processing once documents are loaded:
|
||||
|
||||
```bash
|
||||
tg-invoke-document-rag -q "Describe a cat"
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
Once the system is running, you can access the Workbench on port 8888, or access using the following URL:
|
||||
|
||||
[http://localhost:8888/](http://localhost:8888/)
|
||||
|
||||
Once you have data loaded, you can present a Graph RAG query on the Chat tab. As well as answering the question, a list of semantic relationships which were used to answer the question are shown and these can be used to navigate the knowledge graph.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
The API Gateway is a required component which supports the CLI and Workbench. The API Gateway must be configured with a secret key using an environment variable. The secret can be set to an empty string if no authentication is required.
|
||||
|
||||
```
|
||||
GATEWAY_SECRET=
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
The API Gateway is a required component which supports the CLI and Workbench. The API Gateway must be configured with a secret key. However, that secret key can be empty if no authentication is required. The Workbench does not currently use keys for authentication. The below example shows how to set the API Gateway secret to be empty with no authentication.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic gateway-secret \
|
||||
--from-literal=gateway-secret=
|
||||
```
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
The MCP server requires two secrets provided as environment variables. The MCP server secret is used by clients to authenticate to the MCP service. The gateway secret must match the value configured for the API Gateway, as the MCP server acts as a client of the gateway. Both can be set to empty strings to disable authentication.
|
||||
|
||||
```
|
||||
MCP_SERVER_SECRET=
|
||||
GATEWAY_SECRET=
|
||||
```
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
The MCP server requires two secrets provided in a Kubernetes secret. The MCP server secret is used by clients to authenticate to the MCP service. The gateway secret must match the value configured for the API Gateway, as the MCP server acts as a client of the gateway. Both can be set to empty strings to disable authentication.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic mcp-server-secret \
|
||||
--from-literal=mcp-server-secret= \
|
||||
--from-literal=gateway-secret=
|
||||
```
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
To use Azure Serverless APIs, you need to have a serverless endpoint deployed, and you must also provide an endpoint token as an environment variable.
|
||||
|
||||
```
|
||||
AZURE_ENDPOINT=https://ENDPOINT.API.HOST.GOES.HERE/
|
||||
AZURE_TOKEN=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
To use Azure Serverless APIs, you need to have a serverless endpoint deployed. You must also provide an Azure endpoint and token in a Kubernetes secret before launching the application.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic azure-credentials \
|
||||
--from-literal=azure-endpoint=AZURE-ENDPOINT \
|
||||
--from-literal=azure-token=AZURE-TOKEN
|
||||
```
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
To use Azure's OpenAI APIs, you need to have a serverless OpenAI endpoint deployed, and you must also provide an endpoint token as an environment variable. In addition, the OpenAI API requires an API Version and Model Name to be set. The Model Name is set by the user during the deployment within AzureAI.
|
||||
|
||||
```
|
||||
AZURE_ENDPOINT=https://ENDPOINT.API.HOST.GOES.HERE/
|
||||
AZURE_TOKEN=TOKEN-GOES-HERE
|
||||
AZURE_API_VERSION=API-VERSION-GOES-HERE
|
||||
AZURE_MODEL=MODEL-NAME-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
To use Azure's OpenAI APIs, you need to have a serverless OpenAI endpoint deployed. You must also provide an endpoint token, API version, and model name in a Kubernetes secret. The Model Name is set by the user during the deployment within AzureAI.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic azure-openai-credentials \
|
||||
--from-literal=azure-endpoint=https://ENDPOINT.API.HOST.GOES.HERE/ \
|
||||
--from-literal=azure-token=TOKEN-GOES-HERE \
|
||||
--from-literal=azure-api-version=API-VERSION-GOES-HERE \
|
||||
--from-literal=azure-model=MODEL-NAME-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use AWS Bedrock, you must have enabled models in the AWS Bedrock console. You must also provide an AWS access key ID and secret key.
|
||||
|
||||
```
|
||||
AWS_ACCESS_KEY_ID=ID-KEY-HERE
|
||||
AWS_SECRET_ACCESS_KEY=TOKEN-GOES-HERE
|
||||
AWS_DEFAULT_REGION=AWS-REGION-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
To use AWS Bedrock, you must have enabled models in the AWS Bedrock console. You must also provide an AWS access key ID and secret key as a Kubernetes secret before deploying the application.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic bedrock-credentials \
|
||||
--from-literal=aws-id-key=AWS-ID-KEY \
|
||||
--from-literal=aws-secret=AWS-SECRET-KEY \
|
||||
--from-literal=aws-region=AWS-REGION-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Anthropic Claude, you need a Claude API key. Provide the Claude API key in an environment variable when running the Docker Compose configuration.
|
||||
|
||||
```
|
||||
CLAUDE_KEY=CLAUDE-KEY-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Anthropic Claude, you need a Claude API key which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic claude-credentials \
|
||||
--from-literal=claude-key=CLAUDE-KEY-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Cohere APIs, you need an API token which must be provided in an environment variable.
|
||||
|
||||
```
|
||||
COHERE_KEY=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Cohere APIs, you need an API token which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic cohere-credentials \
|
||||
--from-literal=cohere-key=COHERE-KEY
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Google AI Studio APIs, you need an API token which must be provided in an environment variable.
|
||||
|
||||
```
|
||||
GOOGLE_AI_STUDIO_KEY=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Google AI Studio APIs, you need an API token which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic googleaistudio-credentials \
|
||||
--from-literal=google-ai-studio-key=GOOGLEAISTUDIO-KEY
|
||||
```
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Llamafile, you must have a Llamafile service running on an accessible host. The Llamafile host must be provided in an environment variable.
|
||||
|
||||
```
|
||||
LLAMAFILE_URL=LLAMAFILE-URL
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Llamafile, you must have a Llamafile service running on an accessible host. The Llamafile host must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic llamafile-credentials \
|
||||
--from-literal=llamafile-url=http://llamafile:1234/
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
LMStudio allows you to run models locally, with a nice UX. The LMStudio application or service must be running, and have the REST API enabled, and model made available by pulling from the model repository.
|
||||
|
||||
Note that LMStudio is a commercial product - a licence is needed for non-personal usage. See [lmstudio.ai/work](https://lmstudio.ai/work).
|
||||
|
||||
```
|
||||
LMSTUDIO_URL=http://localhost:1234
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your LMStudio API service.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
LMStudio service URL must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} \
|
||||
create secret generic lmstudio-credentials \
|
||||
--from-literal=lmstudio-url=http://lmstudio:11434/
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your LMStudio service.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Mistral, you need a Mistral API key. Provide the Mistral API key in an environment variable when running the Docker Compose configuration.
|
||||
|
||||
```
|
||||
MISTRAL_TOKEN=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Mistral, you need a Mistral API key which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic mistral-credentials \
|
||||
--from-literal=mistral-key=MISTRAL-TOKEN
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
The power of Ollama is the flexibility it provides in Language Model deployments. Being able to run LMs with Ollama enables fully secure AI TrustGraph pipelines that aren't relying on any external APIs. No data is leaving the host environment or network.
|
||||
|
||||
The Ollama service must be running, and have required models available using `ollama pull`. The Ollama service URL must be provided in an environment variable.
|
||||
|
||||
```
|
||||
OLLAMA_HOST=http://ollama-host:11434
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your Ollama service.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
The Ollama service URL must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} \
|
||||
create secret generic ollama-credentials \
|
||||
--from-literal=ollama-host=http://ollama:11434/
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your Ollama service.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use OpenAI APIs, you need an API token which must be provided in an environment variable.
|
||||
|
||||
```
|
||||
OPENAI_TOKEN=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use OpenAI APIs, you need an API token which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic openai-credentials \
|
||||
--from-literal=openai-token=OPENAI-TOKEN-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Text Generation Inference (TGI) is Hugging Face's production-ready inference server for LLMs. It provides high-performance text generation with features like continuous batching, tensor parallelism, and optimized attention mechanisms.
|
||||
|
||||
The TGI service must be running with the required model loaded. The TGI service URL must be provided in an environment variable.
|
||||
|
||||
```
|
||||
TGI_BASE_URL=http://tgi-host:8080/v1
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your TGI service, noting the `v1` suffix for OpenAI-compatible API.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
The TGI service URL must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} \
|
||||
create secret generic tgi-credentials \
|
||||
--from-literal=tgi-url=http://tgi:8080/v1
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your TGI service.
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use VertexAI, you need to have a Google Cloud credential file provisioned for a service account which has access to the VertexAI services. This means signing up to GCP and using an existing, or launching a new GCP project. The GCP credential will be a JSON file which should be stored in `vertexai/private.json`.
|
||||
|
||||
The credential file is mounted as a volume in Docker Compose, which can cause issues with SELinux if you are running on Linux. Make sure that Docker has access to volume files if this affects you.
|
||||
|
||||
```bash
|
||||
chcon -Rt svirt_sandbox_file_t vertexai/
|
||||
```
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
To use VertexAI, you need to have a Google Cloud credential file provisioned for a service account which has access to the VertexAI services. This means signing up to GCP and using an existing, or launching a new GCP project. The GCP credential will be a JSON file which would arrive in a file called `private.json`.
|
||||
|
||||
The private.json file should be loaded into Kubernetes as a secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic vertexai-creds --from-file=private.json=private.json
|
||||
```
|
||||
|
||||
> **Warning:** Google Cloud private.json files are secrets which potentially provide access to all of your Google Cloud resources. Take great care to ensure that the permissions of the account are minimal, ideally scoped to just AI services.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
vLLM is a high-throughput, memory-efficient inference and serving engine for LLMs. Using PagedAttention and continuous batching, vLLM enables fully secure AI TrustGraph pipelines that aren't relying on any external APIs. No data is leaving the host environment or network.
|
||||
|
||||
The vLLM service must be running with the required model loaded using `vllm serve`. The vLLM service URL must be provided in an environment variable.
|
||||
|
||||
```
|
||||
VLLM_BASE_URL=http://vllm-host:8000/v1
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your vLLM service, noting the `v1` suffix.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
The vLLM service URL must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} \
|
||||
create secret generic vllm-credentials \
|
||||
--from-literal=vllm-url=http://vllm:8000/v1
|
||||
```
|
||||
|
||||
Replace the URL with the URL of your vLLM service.
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have an Azure account, and a running AKS cluster. You also need to be authenticated with the cluster and be able to see the cluster state. See [Azure Kubernetes Service (AKS)](https://azure.microsoft.com/en-us/products/kubernetes-service).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have Docker Compose installed. See [Installing Docker Compose](https://docs.docker.com/compose/install/).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have an AWS account, and a running EKS cluster. You also need to be authenticated with the cluster and be able to see the cluster state. See [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have a Google Cloud account, and a running GKE cluster. You also need to be authenticated with the cluster and be able to see the cluster state. See [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have the Minikube cluster installed and running. See [Minikube - Get Started!](https://minikube.sigs.k8s.io/docs/start). There is TrustGraph documentation on Minikube [here](https://trustgraph.ai/docs/running/minikube).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have an OVHcloud account, and a running Managed Kubernetes cluster. You also need to be authenticated with the cluster and be able to see the cluster state. See [OVHcloud Managed Kubernetes](https://www.ovhcloud.com/en/public-cloud/kubernetes/).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have the Podman environment and Podman Compose installed. This should be available with your Linux distribution. See [Beginner's Guide to Using Podman Compose](https://linuxhandbook.com/podman-compose/).
|
||||
|
|
@ -0,0 +1 @@
|
|||
You need to have a Scaleway account, and a running Kubernetes Kapsule cluster. You also need to be authenticated with the cluster and be able to see the cluster state. See [Scaleway Kubernetes Kapsule](https://www.scaleway.com/en/kubernetes-kapsule/).
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
FalkorDB is licensed under the [Server Side Public License (SSPLv1)](https://github.com/FalkorDB/FalkorDB/blob/master/LICENSE.txt).
|
||||
|
||||
> "The Server Side Public License (SSPLv1) is designed to ensure that if you use FalkorDB as part of a service you make available to others (e.g., in the cloud or as an API), you are required to make the source code of your complete service available under the SSPLv1 license. This is similar to GPL but extends to server use."
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
To use Pinecone, you need an API token which must be provided in an environment variable. The API token can be created in the Pinecone console of your account.
|
||||
|
||||
```
|
||||
PINECONE_API_KEY=TOKEN-GOES-HERE
|
||||
```
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
To use Pinecone, you need an API token which must be provided in a Kubernetes secret.
|
||||
|
||||
```bash
|
||||
kubectl -n {{namespace}} create secret \
|
||||
generic pinecone-api-key \
|
||||
--from-literal=pinecone-api-key=PINECONE-API-KEY
|
||||
```
|
||||
Loading…
Add table
Add a link
Reference in a new issue