Slik drifter du Qdrant selv i 2026: Lagring, API-nøkler og sikkerhetskopier

Det er ved den første redeployen, ikke ved den første docker run, at selvhosting av Qdrant blir interessant. Hvis lagringstillatelser feiler, eller klienten bruker 6334 mens bare 6333 er rutet, kan Docker fortsatt rapportere en prosess som er helt frisk. Distribusjonen nedenfor er organisert rundt observerbar oppførsel: opprett en collection med riktig vektorstørrelse, sett inn punkter med payload, kjør et filtrert nearest-neighbor-søk og gjenopprett et collection-snapshot.

Den tiltenkte rollen til Qdrant er tydelig: vector database for embeddings- og retrieval-systemer. Denne beskrivelsen forteller oss hva som må være offentlig, hva som bør forbli privat, og hva en sikkerhetskopi må kunne gjenskape.

Kartlegg Qdrant før du rører Docker

Ikke la Qdrant-imaget definere produksjonsarkitekturen ved et uhell. Imaget leverer en prosess på 6333, men lagring, routing og eksterne krav trenger fortsatt bevisste livssykluser. Kravet til det lokale runtime-miljøet er tilstrekkelig RAM og disk for vektordimensjoner, payloads og indekser. Dokumenter forventet kapasitet, eierskap og feilmåte i stedet for å la dette bli et image-default.

Distribusjonen er klar for grundigere testing når den kan opprette en collection med riktig vektorstørrelse, sette inn punkter med payload, kjøre et filtrert nearest-neighbor-søk og gjenopprette et collection-snapshot. Følg transaksjonen i loggene og følg med på vektordimensjoner, HNSW-konstruksjon, payload-indekser, collection-replikaer og forskjellen mellom memory-mapped data og tilgjengelig RAM. Disse observasjonene viser om den nåværende topologien isolerer riktig komponent.

Rout Qdrant uten å late som du har HTTPS

Velg det endelige Qdrant-vertsnavnet før brukere lagrer callbacks eller klientinnstillinger. Hold deretter REST offentlig bare når klientene faktisk trenger det, og hold gRPC privat. Plattformrouten bør terminere TLS én gang og målrette den private porten 6333.

Kjør akseptansetransaksjonen eksternt. Hvis klienten aldri når Qdrant, kan du bruke sjekklisten for SSL-validering til DNS- og sertifikatkontroller. Hvis forespørselen når Qdrant, men lagringstillatelser feiler, eller klienten bruker 6334 mens bare 6333 er rutet, må du slutte å endre proxy-redirects og i stedet undersøke den applikasjonsspesifikke grensen.

Gjør den lokale kommandoen til en tjeneste du kan inspisere

Bruk en kommando som viser alle viktige valg. Denne grunnkonfigurasjonen binder Qdrant til loopback på verten, legger til de kjente datamappene og angir den første nødvendige innstillingen. Bekreft det lokale kravet før eksponering: tilstrekkelig RAM og disk for vektordimensjoner, payloads og indekser.

docker run -d \
  --name qdrant \
  --restart unless-stopped \
  -p 127.0.0.1:6333:6333 \
  -v qdrant-data:/qdrant/storage \
  -e QDRANT__SERVICE__API_KEY=replace-with-a-long-random-value \
  qdrant/qdrant:latest

Erstatt flytende tags med en testet versjon eller digest. Etter oppstart inspiserer du docker logs --tail 200 qdrant og bekrefter at prosessen lytter på 6333. Kjør deretter Qdrants akseptansetest. Et svar fra rotsiden kan ikke bevise at hele scenariet fungerer: opprett en collection med riktig vektorstørrelse, sett inn punkter med payload, kjør et filtrert nearest-neighbor-søk og gjenopprett et collection-snapshot.

Oppgrader Qdrant uten å gjette

Kapasitetstester bør belaste vektordimensjoner, HNSW-konstruksjon, payload-indekser, collection-replikaer og forskjellen mellom memory-mapped data og tilgjengelig RAM – ikke bare sende den samme forespørselen til / gjentatte ganger. Kjør scenariet «opprett en collection med riktig vektorstørrelse, sett inn punkter med payload, kjør et filtrert nearest-neighbor-søk og gjenopprett et collection-snapshot» med realistisk samtidighet, og registrer latency, feilrate og vekst i lagringsforbruket.

Oppgraderingsplanleggingen må ta høyde for denne risikoen: collection-snapshots, kompatibilitet for lagringsformatet og oppførselen til klientbiblioteket må testes før du hopper til en ny serverversjon. Test den nye releasen med representative inndata, kjør deretter akseptansetransaksjonen på nytt og sammenlign resultatet. Hvis lagringstillatelser feiler, eller klienten bruker 6334 mens bare 6333 er rutet, må du dokumentere den mislykkede transaksjonen og undersøke den første involverte grensen i stedet for å anta at ingress er ansvarlig.

Gjør Qdrants smoke-test til en release-sjekk

En release-kandidat for Qdrant fortjener trafikk når den fullfører et fast scenario: opprett en collection med riktig vektorstørrelse, sett inn punkter med payload, kjør et filtrert nearest-neighbor-søk og gjenopprett et collection-snapshot. Registrer image-digest, effektiv ikke-hemmelig konfigurasjon, offentlig origin og tidsstempler for dette scenariet. Testdataene bør kunne kastes, men samtidig være realistiske nok til å teste den samme banen som brukerne.

Kjør testen etter at runtime-miljøet er byttet ut, og bygg deretter tjenesten på nytt fra Qdrant-snapshots og den persistente lagringsmappen. Gjenoppretting er godkjent når et snapshot gjenskaper collectionen med samme antall punkter, vektorkonfigurasjon og representative søkeresultater. Sammenlign ressursmålinger for vektordimensjoner, HNSW-konstruksjon, payload-indekser, collection-replikaer og forskjellen mellom memory-mapped data og tilgjengelig RAM med forrige release. Undersøk betydelige avvik før du promoterer releasen.

Til slutt tester du denne kontrollerte feilen: send inn ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: lagringstillatelser feiler, eller klienten bruker 6334 mens bare 6333 er rutet. Bekreft at Qdrant forklarer feilen, ikke skader eksisterende state og fortsetter etter at den gyldige tilstanden er tilbake. Lagre et redigert loggutdrag og tiden det tok å gjenopprette. Til sammen dekker disse kontrollene oppførsel, varighet og drift – ikke bare at prosessen er oppe.

Bevis at Qdrant overlever utskifting

For Qdrant starter sikker redeploy med Qdrant-snapshots og den persistente lagringsmappen. Mount /qdrant/storage før bootstrap, skriv ufarlige eksempeldata og bytt ut containeren for å bevise at banen faktisk er persistent. Test banen ved å bytte ut containeren mens de ufarlige eksempeldataene fortsatt finnes. Dette avdekker mounts som peker én mappe for høyt eller lavt.

Test deretter disaster recovery på en tom vert. Bruk en applikasjonskonsistent databaseeksport der det er nødvendig, og bekreft at et snapshot gjenskaper collectionen med samme antall punkter, vektorkonfigurasjon og representative søkeresultater. Guiden for database-backup som er testet med gjenoppretting gir et bedre mål enn bare å kontrollere at det ble opprettet en arkivfil.

Pålogging, roller og eksponerte flater

For Qdrant er den verdifulle flaten ikke nødvendigvis landingssiden. Den vanligste feilen er å publisere et API uten autentisering på internett. Motvirk dette bevisst: gi ingestion-tjenester avgrenset API-tilgang og hold hele det administrative API-et på en privat route.

Behandle QDRANT__SERVICE__API_KEY i tråd med Qdrants rolle: hold sensitive verdier ute av Git, dokumenter konsekvensene av rotasjon, og bruk aldri et offentlig eksempel i produksjon. Bruk en container-bruker uten privilegier når imaget støtter det, og mount ingen uvedkommende credentials. Bruk rate- eller størrelsesbegrensninger på ingress der arbeid fra ikke-betrodd input kan forbruke vektordimensjoner, HNSW-konstruksjon, payload-indekser, collection-replikaer og tilgjengelig RAM sammenlignet med memory-mapped data.

Flytt det repeterbare infrastrukturarbeidet til Dockup

Dockup kan håndtere de utskiftbare plattformdelene: route trafikk til port 6333, utstede domenet og sertifikatet, injisere secrets, koble til persistent storage og koble Qdrant til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.

Akseptansearbeidet for Qdrant må fortsatt være eksplisitt. Etter one-click-deployen holder du REST offentlig bare når klientene faktisk trenger det, og gRPC privat. Bekreft det lokale kravet – tilstrekkelig RAM og disk for vektordimensjoner, payloads og indekser – og kjør dette scenariet: opprett en collection med riktig vektorstørrelse, sett inn punkter med payload, kjør et filtrert nearest-neighbor-søk og gjenopprett et collection-snapshot. Denne arbeidsdelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, provider-credentials eller gjenopprettingspolicy velger seg selv.

Vanlige spørsmål

Hva trenger Qdrant for en produksjonsdistribusjon?

Rout Qdrant-containeren på port 6333 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er tilstrekkelig RAM og disk for vektordimensjoner, payloads og indekser. Ikke erklær Qdrant klar før du kan opprette en collection med riktig vektorstørrelse, sette inn punkter med payload, kjøre et filtrert nearest-neighbor-søk og gjenopprette et collection-snapshot.

Hvilke Qdrant-data hører hjemme i en sikkerhetskopi?

Gjør /qdrant/storage persistent, og ta med Qdrant-snapshots og den persistente lagringsmappen i det samme recovery-manifestet. En ren Qdrant-gjenoppretting er først godkjent når et snapshot gjenskaper collectionen med samme antall punkter, vektorkonfigurasjon og representative søkeresultater.

Krever Qdrant HTTPS bak en reverse proxy?

Bruk HTTPS for den offentlige Qdrant-originen, og hold port 6333 på den interne routen. Bruk Qdrant-innstillingen riktig: hold REST offentlig bare når klientene faktisk trenger det, og hold gRPC privat. For Qdrant beskytter HTTPS credentials eller brukerinnhold under transport og sørger for konsistent klientoppførsel som er avhengig av origin.

Hvordan bør en Qdrant-oppgradering testes?

Gjenopprett gjeldende Qdrant-state i en isolert distribusjon, bruk kandidatversjonen og kjør akseptansetransaksjonen på nytt. Vær spesielt oppmerksom på at collection-snapshots, kompatibilitet for lagringsformatet og oppførselen til klientbiblioteket må testes før du hopper til en ny serverversjon. Behold det forrige Qdrant-imaget til grensene for datamigrering og rollback er forstått.