Настройка Redis и кэширования

Реализация OSA Proxy

Эта страница относится к текущей реализации OSA Proxy. Архивная Java/Spring-реализация доступна в разделе Архивная Java/Spring-реализация.

OSA Proxy поддерживает Redis-кэш вердиктов Judge, чтобы ускорять повторные запросы и снижать нагрузку на CodeScoring. Кэш выключен по умолчанию.

cache:
  judge:
    enabled: true
    redis-db: 1
    ttl: 24h
    refresh-after: 30m
    proactive-refresh-enabled: false
    proactive-refresh-interval: 2h
    proactive-refresh-workers: 10
    key-prefix: "cs:judge:"
  redis:
    address: redis:6379
    username: ""
    password: ""
    db: 0
    tls:
      enabled: false
      ca-file: ""
      server-name: ""

Параметры

ПараметрНазначение
cache.judge.enabledВключает Redis-кэш результатов проверки Judge.
cache.judge.redis-dbНеобязательное переопределение базы Redis для кэшей вердиктов и handler'ов. Если не задано, используется cache.redis.db.
cache.judge.ttlВремя жизни записи кэша. По умолчанию 24h.
cache.judge.refresh-afterВозраст записи, после которого ее можно обновлять в фоне. По умолчанию 30m.
cache.judge.proactive-refresh-enabledВключает периодическое фоновое обновление устаревающих записей. По умолчанию false.
cache.judge.proactive-refresh-intervalПериод фонового обновления. По умолчанию 2h.
cache.judge.proactive-refresh-workersКоличество workers для фонового обновления. По умолчанию 10.
cache.judge.key-prefixПрефикс Redis-ключей.
cache.redis.addressАдрес Redis в формате host:port.
cache.redis.usernameИмя пользователя Redis ACL.
cache.redis.passwordПароль Redis.
cache.redis.dbНомер базы Redis.
cache.redis.tls.enabledВключает TLS для Redis. По умолчанию false.
cache.redis.tls.ca-fileНеобязательный путь к дополнительному PEM CA bundle. Сертификаты из файла добавляются к системным корням доверия.
cache.redis.tls.server-nameНеобязательное общее имя для SNI и проверки сертификатов Redis и Sentinel.

TLS для Redis

Чтобы включить TLS, задайте:

cache:
  redis:
    address: redis.example.com:6380
    tls:
      enabled: true
      ca-file: ""
      server-name: ""

OSA Proxy использует TLS 1.2 или новее и всегда проверяет сертификат сервера. Отключить проверку сертификата нельзя.

При пустом ca-file используется системное хранилище доверенных CA контейнера. Если указан PEM-файл, сертификаты из него добавляются к системным корням, а не заменяют их. Параметр server-name обычно оставляют пустым: тогда сертификат каждого подключения проверяется по hostname из его адреса. Непустое значение задаёт одну общую SNI/verify identity для Redis, всех Sentinel endpoints и найденного master; используйте его, только если это имя присутствует в SAN всех соответствующих сертификатов.

В стандартном osa-proxy.yml эти параметры связаны с переменными окружения:

REDIS_TLS_ENABLED=true
REDIS_TLS_CA_FILE=
REDIS_TLS_SERVER_NAME=

Корпоративный CA в Docker Compose

Для каталога с корпоративными CA добавьте его в SSL_CERT_DIR, сохранив системный каталог /etc/ssl/certs:

services:
  osa-proxy:
    environment:
      SSL_CERT_DIR: /etc/ssl/certs:/etc/osa-proxy/certs
      REDIS_TLS_ENABLED: "true"
      REDIS_TLS_CA_FILE: ""
      REDIS_TLS_SERVER_NAME: ""
    volumes:
      - ./certs:/etc/osa-proxy/certs:ro

При пустом REDIS_TLS_CA_FILE Redis использует системное хранилище вместе с сертификатами из SSL_CERT_DIR. Альтернативный вариант — примонтировать отдельный PEM bundle и указать путь к нему в REDIS_TLS_CA_FILE.

Корпоративный CA в Helm

Создайте Secret с PEM-сертификатами:

kubectl create secret generic osa-proxy-ca \
  --from-file=corp-root-ca.pem

Включите TLS в конфигурации Redis и подключите Secret через CA directory чарта:

config:
  content: |
    cache:
      judge:
        enabled: true
      redis:
        address: redis.example.com:6380
        tls:
          enabled: true
          ca-file: ""
          server-name: ""

certificates:
  caDirectory:
    enabled: true
    secretName: osa-proxy-ca

Chart добавляет смонтированный каталог к системному SSL_CERT_DIR, поэтому ca-file можно оставить пустым. После обновления Secret перезапустите pods OSA Proxy, чтобы клиент перечитал CA.

Redis Sentinel

Для Redis HA включите Sentinel. Обычный cache.redis.address в этом режиме не требуется. Учетные данные Redis master и Sentinel задаются независимо:

cache:
  judge:
    enabled: true
    ttl: 24h
    refresh-after: 30m
    key-prefix: "cs:judge:"
  redis:
    username: redis-user
    password: redis-password
    db: 0
    tls:
      enabled: true
      ca-file: ""
      server-name: ""
    sentinel:
      enabled: true
      master-name: mymaster
      addresses:
        - sentinel-1:26379
        - sentinel-2:26379
        - sentinel-3:26379
      username: sentinel-user
      password: sentinel-password

В Sentinel-режиме один TLS-конфиг применяется и к Sentinel, и к обнаруженному Redis master. Поэтому при tls.enabled: true оба сервиса должны принимать TLS и использовать сертификаты, которым доверяет OSA Proxy.

При временной недоступности Redis OSA Proxy продолжает использовать предусмотренные локальные механизмы кэширования.

TTL и фоновое обновление

Фоновое обновление не продлевает 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 доступна по адресу:

http://127.0.0.1:8081/swagger/

Основные endpoints для сброса кэша:

  • DELETE /api/v1/cache/purls — удалить записи по конкретным PURL (в теле запроса передается JSON со списком purls);
  • DELETE /api/v1/cache/packages/{packageType} — удалить записи по типу пакета с возможностью фильтрации по имени пакета (packageName) и контексту репозитория (repositoryName и repositoryManagerUrl).

Подробное описание параметров, авторизации и примеры вызовов приведены в разделе Admin API.

Страница была полезна?