Feature: Deploy to Azure

[bdougie]

Type of feature

🍕 Feature

Current behavior

There were a few instructions shared in this Discord that I will share here. I would love to add similar instructions so we can deploy this as well.

Here are the Docker instructions I shared:

https://github.com/Azure-Samples/qdrant-azure

Suggested solution

I have gotten as far as deploy the sample app and setting up the az cli locally.

Azure setup

$ brew update && brew upgrade azure-cli
$ az login

Azure service set up

  az deployment group create \
  --name repoQueryOS \
  --resource-group openSaucedAlpha \
  --template-file main.bicep 

What is needed?

we need this file main.bicep file created. Looking at this example for reference: https://github.com/Azure-Samples/qdrant-azure/blob/94a638972fb5a47ec623a27fb9cab5b6b3effe96/Azure-Kubernetes-Svc/main.bicep#L4

I have not done a ton of azure, but the cli experience has been nicer than jumping in the portal

Additional context

Open to other suggestions. This is my first exposure to a bicep file, currently doing more research on it.

Code of Conduct

• I agree to follow this project's Code of Conduct

Contributing Docs

• I agree to follow this project's Contribution Docs

[bdougie]

Looks like you can use VScode to generate this file.

https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/quickstart-create-bicep-use-visual-studio-code?tabs=CLI

update: I'll need to pause on this, but if you'd like to take a look at it with your account @Anush008, feel free. Not sure what the approach is and if this should be example.bicep instead of a live version.

Let me know if you have any context on Azure @jpmcb 😅

[jpmcb]

Let me know if you have any context on Azure @jpmcb 😅

Not too much.

But looks like Bicep is their opinionated, infrastructure as code solution for deploying resources across azure cloud (like terraform but only for azure).

I'd caution that we don't want to get too into the weeds with some of these devops solutions at this stage since it can be an endless dark pit of never ending solution-ing. We want to find the balance between having atomic, reproducible deployments (that in theory, anyone can run) and moving quickly. Even a 2 or 3 step script that someone runs manually is better at this stage than spending weeks coming up with the best devops pipeline opinionated for azure.

I'd envision probably a few things for now:

• build the repo-query engine into a container
• use Bicep to shape our azure instance and it's specific needs (network, instances, container runtime, etc.)
• simple script/steps to deploy new container instances to our

From there, we can build things into a pipeline, further operationalize it, etc.

[Anush008]

I've deployed a QdrantDB instance on Azure using their App service. I've currently disable auth.
Found this guide https://github.com/Softlandia-Ltd/qdrant-azure-app-service.

Available here.
https://qdrant-repo-query.azurewebsites.net/dashboard

The kubernetes-helm kept giving me network errors when I tried to deploy using the az cli.

[Anush008]

To enable the development of the extension's chat UI, I will set up the repo-query service on an Azure compute instance connected to the mentioned Qdrant DB instance.

Will allow us to proceed with further development and eventually progress towards a production deployment.

[bdougie]

Awesome @Anush008. Thanks for working through this.

[Anush008]

There's been an update. Azure's App Service which I used to deploy the Qdrant DB instance only allows one container port to be mapped to both 80, 443. No other ports are accessible.

Ref:

https://qdrant-repo-query.azurewebsites.net/dashboard is pointing to port 6333 of the container. That's the dashboard.

But our application needs 2. 6333 and 6334.
6333 for the dashboard and 6334 is what repo-query uses to communicate with Qdrant.

So I ended up running Qdrant on the same compute instance where I'll host repo-query for development.

http://20.163.213.108:6333/dashboard

http://20.163.213.108:6334 for

repo-query/.env.example

Line 2 in 0e9fcac

QDRANT_URL= #Default: http://localhost:6334

Which is essentially localhost.

[bdougie]

Is this ready to be tested by open-sauced/ai#226

Or should we wait to abstract it in the open-sauced/API?

What are the next steps?

[Anush008]

The development deployment is UP. It is a Standard B2s (2 vcpus, 4 GiB memory).

Available at
http://20.163.213.108:3000 => https://opensauced.pizza/
http://20.163.213.108:3000/embed
http://20.163.213.108:3000/query
http://20.163.213.108:3000/collection

[diivi]

Is this ready to be tested by open-sauced/ai#226

I don't think I can test it until it's a https:// url. I get an error when I try to send a request from https://github to http://repo-query. We need to get SSL

[Anush008]

I'll configure SSL.

[Anush008]

@diivi, You can try the service now at

https://opensauced.tools/ redirects to https://opensauced.pizza/
https://opensauced.tools/embed
https://opensauced.tools/query
https://opensauced.tools/collection

The endpoint documentation is here.
https://github.com/open-sauced/repo-query#-service-endpoints

[diivi]

Getting CORS errors now, please allow cross origin access.

Access to fetch at 'https://opensauced.tools/collection?owner=open-sauced&name=ai&branch=beta' from origin 'https://github.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

[Anush008]

Getting CORS errors now, please allow cross origin access.

The CORS policy should've been permissive by default. I set it explicitly. You can try now.

[jpmcb]

@Anush008 - we'll want some sort of "infrastructure-as-code" output from this issue so we can have reproducible builds on Azure. Let me know if you want to connect and get some ideas on what that should look like. I'm not super familiar with azure, but we can always use terraform to get some templates.

[bdougie]

Spent a little bit of time trying to deploy this on stream and a bit confused on how to ClickOps my way to a VM.

Assuming the below is where to start, but I did not see the flavors you shared when creating that.

Specification:

Linux (Ubuntu 22.04) VM
Standard B2s (2 vCPUs, 4 GiB memory)

Ideally if I can get the VM up, I can set up the ports and install. Just stuck on step 0.

[jpmcb]

If you select "See all sizes" from the dropdown:

You should be able to filter and select the instance type down to B2s.

---

I've been exploring abit of deploying to Azure functions and creating a docker image for this service. I think that may be a good direction to go: I'll post more findings here soon!