Настройка Redis и кэширования
Эта страница относится к текущей реализации OSA Proxy. Архивная Java/Spring-реализация доступна в разделе Архивная Java/Spring-реализация.
OSA Proxy поддерживает Redis-кэш вердиктов Judge, чтобы ускорять повторные запросы и снижать нагрузку на CodeScoring. Кэш выключен по умолчанию.
Параметры
TLS для Redis
Чтобы включить TLS, задайте:
OSA Proxy использует TLS 1.2 или новее и всегда проверяет сертификат сервера. Отключить проверку сертификата нельзя.
При пустом ca-file используется системное хранилище доверенных CA контейнера. Если указан PEM-файл, сертификаты из него добавляются к системным корням, а не заменяют их. Параметр server-name обычно оставляют пустым: тогда сертификат каждого подключения проверяется по hostname из его адреса. Непустое значение задаёт одну общую SNI/verify identity для Redis, всех Sentinel endpoints и найденного master; используйте его, только если это имя присутствует в SAN всех соответствующих сертификатов.
В стандартном osa-proxy.yml эти параметры связаны с переменными окружения:
Корпоративный CA в Docker Compose
Для каталога с корпоративными CA добавьте его в SSL_CERT_DIR, сохранив системный каталог /etc/ssl/certs:
При пустом REDIS_TLS_CA_FILE Redis использует системное хранилище вместе с сертификатами из SSL_CERT_DIR. Альтернативный вариант — примонтировать отдельный PEM bundle и указать путь к нему в REDIS_TLS_CA_FILE.
Корпоративный CA в Helm
Создайте Secret с PEM-сертификатами:
Включите TLS в конфигурации Redis и подключите Secret через CA directory чарта:
Chart добавляет смонтированный каталог к системному SSL_CERT_DIR, поэтому ca-file можно оставить пустым. После обновления Secret перезапустите pods OSA Proxy, чтобы клиент перечитал CA.
Redis Sentinel
Для Redis HA включите Sentinel. Обычный cache.redis.address в этом режиме не требуется. Учетные данные Redis master и Sentinel задаются независимо:
В Sentinel-режиме один TLS-конфиг применяется и к Sentinel, и к обнаруженному Redis master. Поэтому при tls.enabled: true оба сервиса должны принимать TLS и использовать сертификаты, которым доверяет OSA Proxy.
При временной недоступности Redis OSA Proxy продолжает использовать предусмотренные локальные механизмы кэширования.
Фоновое обновление не продлевает TTL записи само по себе. TTL продлевается при чтении данных из кэша реальными запросами, поэтому редко используемые записи со временем удаляются из Redis.
Управление кэшем
Методы очистки кэша и Swagger UI перенесены с основного порта :8080 (где ранее использовались пути /api/swagger и /api/cache/...) на выделенный порт Admin API (по умолчанию :8081, секция admin в osa-proxy.yml). Административные методы /api/v1/... защищены Bearer-токеном.
Сброс записей кэша вердиктов выполняется через Admin API на отдельном порту (по умолчанию :8081). Запросы к Admin API требуют передачи Bearer-токена в заголовке Authorization.
Интерактивная документация Swagger UI доступна по адресу:
Основные endpoints для сброса кэша:
DELETE /api/v1/cache/purls— удалить записи по конкретным PURL (в теле запроса передается JSON со спискомpurls);DELETE /api/v1/cache/packages/{packageType}— удалить записи по типу пакета с возможностью фильтрации по имени пакета (packageName) и контексту репозитория (repositoryNameиrepositoryManagerUrl).
Подробное описание параметров, авторизации и примеры вызовов приведены в разделе Admin API.
