Контейнер Qdrant в Docker стартует за минуту, и именно поэтому его так часто запускают без тома, без ключа и без копий. Для рабочей базы нужны три решения: где на диске лежит индекс, кто может подключиться по сети и как делается снимок для восстановления. Всё остальное, от коллекций до фильтров, строится поверх этих трёх решений и пересобирается дороже, если фундамент заложен кое-как.
Один контейнер
По документации Qdrant, образ qdrant/qdrant запускается с публикацией портов для HTTP и gRPC и томом в каталог /qdrant/storage. Без тома данные исчезнут вместе с контейнером, а по умолчанию доступ открыт без шифрования и авторизации.
В кратком руководстве показана команда: загрузить образ, запустить контейнер с двумя опубликованными портами и смонтировать локальный каталог в хранилище внутри контейнера. HTTP-интерфейс и веб-панель на пути dashboard слушают первый порт, gRPC — второй. Для кластера нужен ещё один порт для связи между узлами.
Роль базы в системе поиска по документам мы разбирали в статье про Qdrant в RAG. Здесь речь об эксплуатации: хранение, доступ, копии и обновление. Общую картину выбора между векторными базами описывает материал про выбор векторной базы для RAG.
Документация называет контейнер удобным для тестов и разработки, а для рабочей нагрузки обычно советует облачную версию или Kubernetes. Запускать Docker в продакшене она разрешает при условии, что вы обеспечите быстрое постоянное хранилище, безопасность, копии, мониторинг и (для высокой доступности) несколько узлов с балансировщиком. Часть этого придётся заменить дисциплиной: копиями, мониторингом и регламентом обновления.
Хранилище на диске
Индекс — главная ценность базы: пересчитать эмбеддинги большой коллекции долго и дорого, а иногда исходных документов уже нет. Поэтому место и тип хранилища выбирают осознанно.
- Локальный диск хоста. Рекомендация документации: твердотельный накопитель, если векторы выносятся на диск.
- Файловая система с поддержкой стандарта POSIX и блочным доступом. Сетевые файловые системы вроде NFS и объектные хранилища вроде S3 для хранилища Qdrant, по документации, непригодны: работать с ними Qdrant откажется. Допустимы сетевые устройства с блочным доступом вроде iSCSI.
- Каталог хоста вместо анонимного тома: путь известен, права настраиваются обычными средствами, копии делает привычный скрипт.
- Запас по месту: индекс растёт вместе с числом векторов, размерностью и полезными данными, поэтому диск рассчитывают с запасом под рост и под снимки.
Каталог данных на сетевом диске NFS выглядит удобным, потому что тогда есть общий доступ и «резерв». По документации Qdrant, на NFS и S3 база работать откажется, поэтому держите хранилище на локальном или блочном диске. Отдельное предупреждение документации касается Docker и WSL на Windows: монтирование каталогов там известно потерей данных.
Условный пример: компания загружает в Qdrant регламенты и инструкции, несколько десятков тысяч фрагментов, и подключает чат для сотрудников. База стоит на отдельной машине, каталог данных лежит на локальном диске, а снимок делается каждую ночь и уходит на другое хранилище. После первого обновления образа команда прогоняет контрольные вопросы и убеждается, что выдача осталась прежней.
Память определяется числом векторов, их размерностью, индексами по полям и настройкой квантования. Для оценки возьмите тестовую коллекцию с типичным составом и замерьте расход вместо того, чтобы выводить его из рекламных цифр.
Закрыть доступ
Документация Qdrant честно сообщает: стандартная конфигурация стартует без шифрования и авторизации, и любой, кто видит порт, читает и меняет коллекции. Для рабочей базы это недопустимо.
- Ключ API: задаётся переменной окружения QDRANT__SERVICE__API_KEY (для ключа только на чтение есть QDRANT__SERVICE__READ_ONLY_API_KEY), после чего все запросы без ключа получают отказ.
- Ключ только на чтение: отдельное значение для приложений, которые лишь ищут, и основной ключ для того, кто загружает данные.
- Порты: HTTP и gRPC привязывайте к внутреннему интерфейсу или закрытой сети Docker, наружу публикуйте только через защищённый шлюз.
- Шифрование: для передачи по сети включают TLS либо терминируют его на шлюзе перед контейнером.
- Веб-панель: убедитесь, что она закрыта от внешней сети вместе с остальным интерфейсом.
Для рабочих сценариев добавьте и мониторинг: у Qdrant есть конечные точки состояния и метрик, которые читает обычная система наблюдения. Следите за свободным местом, использованием памяти и временем ответа на поисковые запросы. Резкий рост любого из показателей раньше, чем жалобы пользователей, подскажет, что пора расширять машину или пересматривать настройки индекса.
Если приложение находится в соседнем контейнере, объедините их в общую сеть Docker и оставьте порт на хосте закрытым. Так поверхность атаки резко сокращается, а приложение обращается к базе по имени сервиса. Подробнее о защите контейнерного контура мы писали в статье про vLLM Docker, принципы совпадают.
Где у вас сейчас хранится индекс поиска по документам?
Копия и возврат
База без копии — один сбой диска до потери недель работы. Qdrant умеет делать снимки (snapshots) отдельных коллекций и всего хранилища, а также восстанавливаться из них.
- Создайте снимок коллекции через интерфейс и сохраните его за пределами контейнера и желательно за пределами самой машины.
- Опишите расписание: как часто делается снимок, сколько штук хранится, кто проверяет, что копии появляются.
- Проверьте восстановление: поднимите отдельный тестовый контейнер, загрузите снимок и сравните число векторов и результаты тестовых запросов.
- Зафиксируйте версию Qdrant, на которой сделан снимок: документация даёт рекомендации по совместимости версий при обновлениях.
- Раз в квартал повторяйте учения по восстановлению: копия без пробного восстановления считается непроверенной.
Разделяйте роли ключей. Загрузку данных делает отдельный сервис с основным ключом, а поиск выполняют приложения с ключом только на чтение. Тогда скомпрометированный поисковый сервис способен лишь читать данные, а возможности удалить коллекцию у него уже нет. Меняйте ключи по расписанию и после ухода сотрудников, знавших значения.
Помните об источнике: исходные документы и скрипты загрузки хранятся отдельно от базы. Тогда в худшем случае вы пересоберёте индекс, вместо потери знаний компании. Правила обновления самих документов описаны в статье про базу знаний на RAG.
Проверка выдачи
После каждого изменения, от обновления версии до восстановления из копии, поиск проверяют на фиксированном наборе вопросов. Запущенная и отвечающая база ещё требует доказательства, что отвечает верно.
| Событие | Что проверить | Признак проблемы |
|---|---|---|
| Первый запуск | Коллекция создана, число векторов совпадает с загруженным | Пустая коллекция после перезапуска: том отсутствует в команде запуска |
| Обновление образа | Контейнер стартует, коллекции видны, запросы отвечают | Ошибка совместимости версий, пропавшие коллекции |
| Восстановление из снимка | Число векторов и результаты контрольных запросов | Расхождение с эталонной выдачей |
| Массовая загрузка | Время ответа и расход памяти до и после | Рост задержки, нехватка памяти |
| Смена ключа | Приложения получают отказ со старым и ответ с новым | Приложение с забытым старым ключом |
Контрольный набор состоит из двадцати запросов с известными правильными документами. Доля попаданий в первые результаты показывает качество и позволяет заметить ухудшение раньше, чем пожалуются пользователи. Обновление образа в пятницу вечером без копии и без контрольного прогона превращает любую неполадку в аврал. Такие контуры поиска мы собираем в проектах по нейросетям для документов.