azure-samples/qdrant-azure

Qdrant Vector Database on Azure Cloud

Qdrant Vector Database on Azure Cloud

This project combines the power of the Qdrant Vector Database with the Microsoft Azure Cloud allowing you to bring Vector Search and Embeddings storage to your AI products.

Getting started

You have several options for how to get Qdrant running on Azure:

• Azure Kubernetes Service
• Qdrant Container in Docker

Prerequisites

To get started, users will need access to an Azure subscription.

To deploy using the Deploy to Azure button which leverages an ARM template, you need write access on the resources you're deploying and access to all operations on the Microsoft.Resources/deployments resource type.

Installation

Azure Kubernetes Service

To deploy Qdrant to a cluster running in Azure Kubernetes Services, go to the Azure-Kubernetes-Svc folder and follow instructions in the README.md to deploy to a Kubernetes cluster with Load Balancer on Azure Kubernetes Services (AKS).

You can quickly create an Azure Kubernetes Service cluster by clicking the Deploy to Azure button below. After creating your AKS cluster, go to the Azure-Kubernetes-Svc folder to deploy Qdrant into the AKS cluster using Helm.

AKS Prerequisites

PLEASE NOTE! ensure that you have a resource group and ssh key in that resource created before selecting the Deploy to Azure Button below. More details can be found in README.md in Azure Kubernetes Service README.md

Docker (Local)

To develop against and run Qdrant locally.

VS Code Dev Container This project contains a dev container configuration which can be used for local development. To learn more about using a dev container, please review Developing inside a Container.

Docker Locally To run the Qdrant vector database running in Docker locally, please follow the instructions from Qdrant's website: Install Qdrant with Docker

To run Qdrant with Docker locally, you can use the following command using default values stored in the file .config/config.yaml located in the Local-Docker-Deployment folder.

docker run -p 6333:6333 \
    -v $(pwd)/path/to/data:/qdrant/storage \
    -v $(pwd)/path/to/custom_config.yaml:/qdrant/config/production.yaml \
    qdrant/qdrant

You can overwrite values by creating and adding new records to a file ./config/production.yaml. An example of the production.yaml file located in the Local-Docker-Deployment directory. Please review the Qdrant documentation to learn more information on configuration options for Qdrant.

Resources for Learning More

• Semantic Kernel Blog: The Power of Persistent Memory with Semantic Kernel and Qdrant Vector Database
• Qdrant Vector Search [Vector Database]
• Qdrant Integration with OpenAI
• Azure Container Instances (ACI)
• Azure Kubernetes Service (AKS)
• Docker Desktop

qdrant-azure's Issues

Azure deploy / Delete permission

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Hello, first i'd like to thank you for this repo. It helped me deploy a full working qdrant infra on azure using container APP with the arm file template.json, very simply.
And its working very well. Except recently, i noticed that when i try to call the delete endpoint :
DELETE /collection/<collection_name>

i get "status": {
"error": "Service internal error: Permission denied (os error 13)"
},

However the collection does not show anymore when listing collections.
I looked into the storage account and it seems the program could not delete the actual collection files on the storage account. Seems like a missing Delete permission.

Would you know if this is something i can manually fix or if i can correct the template to specify these writes. It seems that Readwrite permissions are not enough to delete ? Something like Microsoft.Storage/storageAccounts/blobServices/delete

Thanks a lot for the help.

Storage file name too long for ACI

Please provide us with the following information:

Error in deploying storage with ACI due to generated storage file name being too long.

This issue is for a: (mark with an x)

- [X ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Any log messages given by the failure

Expected/desired behavior

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Broken image link in README

qdrant-azure/Local-Docker-Deployment/README.md

Line 90 in 01ee6cd



Deprecated AKS API version

Please provide us with the following information:

Azure-Kubernetes-Svc/resources.bicep is using 2022-05-02-preview API version which has been deprecated. This will prevent folks from being able to deploy AKS clusters.

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [x] regression (a behavior that used to work and stopped in a new release)

Need to have a storage account

qdrant-azure/README.md

Line 55 in 01ee6cd

If using the **Deploy to Azure button**, you will need to have a storage account set up in Azure previously. Update the`storageaccountname` parameter in the `qdrant-deploy-aci.parameters.json` file in the `Azure-Container-Instances` directory with your existing storage account name.

Hmm, this is no good... defeats the purpose of the "Deploy to Azure" button on GitHub, if you have to clone the repo and update some parameters. Can't we create a storage account in the deployment yaml?

Docker compose should not contain Postgres

qdrant-azure/Local-Docker-Deployment/example-windows-docker-compose.yaml

Lines 5 to 18 in 01ee6cd

	db:
	image: postgres:14
	restart: always
	ports:
	- '127.0.0.1:5432:5432'
	environment:
	POSTGRES_USER: octols
	POSTGRES_PASSWORD: hfh45-JGThj
	POSTGRES_INITDB_ARGS: --encoding=UTF-8 --lc-collate=C --lc-ctype=C
	PGDATA: /var/lib/postgresql/data/postgres
	LC_COLLATE: UTF-8
	LC_CTYPE: UTF-8
	volumes:
	- d:\workspace\mydata:/var/lib/postgresql/data

All of the "db" section should be removed, as it's not related to qdrant.

How do I secure this?

- [ ] bug report -> please search issues before submitting
- [x] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

I followed the walkthrough blog post:
https://devblogs.microsoft.com/semantic-kernel/the-power-of-persistent-memory-with-semantic-kernel-and-qdrant-vector-database/
and I'm wondering how to secure it properly?

Qdrant supports api key but how do I enable it during the deployment?
https://qdrant.tech/documentation/guides/security/

Repo Topics

qdrant-azure/README.md

Lines 16 to 27 in 01ee6cd

	Products:
	- azure
	- azure-resource-manager
	- azure-container-instance
	- azure-kubernetes-service
	- qdrant vector database (oss)
	- docker
	languages:
	- json
	- yaml
	- bicep

These can be "topics" for the repo. Set here:

...they don't need to be listed up front, taking up all the prime real estate.

Qdrant Image blocking in ACI

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ X ] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Qdrant image is public on DockerHub, but when image attempted to be retrieved from ACI it notes inaccessible image. The image has been verified to be:

• Public
• Available for download via docker pull
• Available for use as image in AKS
• Not in restricted repo or account in Docker
• Has happen in various types of Azure Subscriptions

Any log messages given by the failure

Expected/desired behavior

The image is pulled an deployed in a similar fashion as it would be in Docker or K8s/AKS

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Main README Fixes

qdrant-azure/README.md

Line 61 in 01ee6cd

To deploy Qdrant to a cluster running in Azure Kubernetes Services, go to the `Azure-Kubernetes-Svc` folder and follow instructions in the `README.md` to deploy to a Kubernetes cluster with Load Balancer on Azure Kubernetes Services (AKS).

"go to the Azure-Kubernetes-Svc folder and follow instructions in the README.md"

• ...this could just be a simple link to the README without any of the instructions.

• All of the text under the header "Docker (Local)" is about AKS.

• The giant logos at the top of the page should go -- they're pixelated, and we don't have permission to use qdrant's logo.

Copy-editing for READMEs

In README.MD:

• At the top, perhaps include a quote from Qdrant or write one yourself on why the project exists.
• Remove "Ability to" under Features
• Suggestion: This may not exist now, but if we have a Semantic Kernel example of how to make use of Qdrant, let's find a way to link it here. We'd do the same in the SK repo.
• Under "Getting Started", provide a link to Azure subscription if available.
• "An example of the production.yaml file is located in the Local-Docker-Deployment directory"

In Azure-Container-Instances/README.MD

• Remove "Ability to" under Features
• Boldface the different options
• Wrap the az command in a code block:

az deployment group create
--name ExampleDeployment
--resource-group ExampleGroup
--template-uri \

In Azure-Kubernetes-Svc/README.MD

• Remove "Ability to" under Features

How can I upgrade a Qdrant on Azure-Kubernetes-Svc

Please provide us with the following information:

This issue is for a: (mark with an x)

- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [X] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

• Deployed Qdrant on Azure Kubernetes Service following [Documentation/Link]
• Need to upgrade Qdrant to latest version

Any log messages given by the failure

• N/A

Expected/desired behavior

• A step-by-step tutorial or documentation on how to safely upgrade Qdrant deployed on Azure Kubernetes Service.

OS and Version?

• macOS(Ventura)

Versions

• Qdrant: [current_version]
• Kubernetes: [current_version]
• Azure CLI: [current_version]

Mention any other details that might be useful

• Would be beneficial to cover backup procedures before upgrading.

---

Thanks! We'll be in touch soon.

Invalid Key Pair Name

Please provide us with the following information:

This issue is for a: (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

• Deploy Qdrant to AKS
• Use qdrantssh as ssh key-pair name

Any log messages given by the failure

Expected/desired behavior

Qdrant resource is deployed successfully

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Working deloyment stopped working

Hi guys. We've been running a stock standard Azure Container Apps deployment successfully since December 4th 2023. Its been running fine with successful data querying, as of COB last Friday. Since Monday morning the container is crashing and cant start up. There is nothing I'm aware of that ran or was done on our side as part of an automated or human process that did anything to the resource. This is the second deployment that this has occurred with (ran well for a few weeks then suddenly the container started crashing) and I'm struggling to understand why. The log stream shows:

2024-01-17T06:32:52.25782 Connecting to the container 'qdrantapicontainerapp'...
2024-01-17T06:32:52.27576 Successfully Connected to container: 'qdrantapicontainerapp' [Revision: 'sygniasynapseqdranthttp--0tfisge-567f7bd697-5hr52', Replica: 'sygniasynapseqdranthttp--0tfisge']
2024-01-17T06:32:37.835011814Z 2: std::panicking::rust_panic_with_hook
2024-01-17T06:32:37.835016242Z at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:735:13
2024-01-17T06:32:37.835020700Z 3: std::panicking::begin_panic_handler::{{closure}}
2024-01-17T06:32:37.835024728Z at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:609:13
2024-01-17T06:32:37.835028695Z 4: std::sys_common::backtrace::__rust_end_short_backtrace
2024-01-17T06:32:37.835032312Z at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/sys_common/backtrace.rs:170:18
2024-01-17T06:32:37.835037161Z 5: rust_begin_unwind
2024-01-17T06:32:37.835041559Z at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/std/src/panicking.rs:597:5
2024-01-17T06:32:37.835046238Z 6: core::panicking::panic_fmt
2024-01-17T06:32:37.835049925Z at /rustc/a28077b28a02b92985b3a3faecf92813155f1ea1/library/core/src/panicking.rs:72:14
2024-01-17T06:32:37.835055635Z 7: collection::shards::shard_holder::ShardHolder::load_shards::{{closure}}.110038
2024-01-17T06:32:37.835059663Z 8: storage::content_manager::toc::TableOfContent::new
2024-01-17T06:32:37.835063911Z 9: qdrant::main
2024-01-17T06:32:37.835067928Z 10: std::sys_common::backtrace::__rust_begin_short_backtrace
2024-01-17T06:32:37.835072066Z 11: main
2024-01-17T06:32:37.835075943Z 12:
2024-01-17T06:32:37.835079880Z 13: __libc_start_main
2024-01-17T06:32:37.835083507Z 14: _start
2024-01-17T06:32:37.835086994Z
2024-01-17T06:32:37.835092183Z 2024-01-17T06:32:37.834886Z ERROR qdrant::startup: Panic occurred in file /qdrant/lib/collection/src/shards/replica_set/mod.rs at line 246: Failed to load local shard "./storage/collections/[redacted]/0": Service internal error: RocksDB open error: IO error: No such file or directory: while unlink() file: ./storage/collections/[redacted]/0/segments/23a17757-59d1-4649-acbb-7b5b183af4bb/LOG.old.1705084754144915: No such file or directory

If I browse to the file its looking for, in the Azure portal, its reported as being marked for deletion by an SMB client. As far as I know there was no human action that did this, and all other files are accessible. This is also the only fine that has contents. All the other LOG.old files are 0 size. We cant delete the file because its already marked for deletion, so I cant upload any sort of replacement file, so short of redeploying everything, I'm not sure where to go from here. I set the soft delete period to the minimum (1 day) in the hopes that once the file deleted it would sort itself out, but the file hasn't deleted and is still present but inaccessible. I'm really hoping I don't have to do a complete redeploy to fix this, so any assistance you can give to help understand why this has happened, would be highly appreciated.

Thanks so much

Please provide us with the following information:

This issue is for a: (mark with an x)

- [X] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

No idea. It was working fine and then something marked the log.OLD file for deletion

Any log messages given by the failure

Expected/desired behavior

That the working deployment continues to work

OS and Version?

Azure Container Service , so probably Linux

Versions

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

Add the Qdrant Cloud on Azure option

You can add the further option of "Qdrant Cloud on Azure" option to use Qdrant in Azure AI apps after the following announcement:

Introducing Qdrant Cloud on Microsoft Azure

It would be beneficial to provide information on where the data is stored (either Azure or Qdrant Cloud) and details on privacy features.

"Too Many Request" errors during the parallel upload

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

I followed the walkthrough blog post:
https://devblogs.microsoft.com/semantic-kernel/the-power-of-persistent-memory-with-semantic-kernel-and-qdrant-vector-database/

but uploading documents in parallel causes too many "Too Many Request" Errors.

I think it's not an issue with the VM's Spec, since the node's CPU usage is 12%.

Is there a workaround for this?