Очистка кэша Nginx в Docker и Kubernetes: практическое руководство

Введение: зачем очищать кэш Nginx в контейнерных средах

Кэш Nginx хранит готовые ответы бэкенда, чтобы не гонять каждый запрос к приложению. При обновлении статики, изменении конфигурации или отладке эти сохранённые файлы устаревают. Пользователь получает старую версию страницы, хотя бэкенд уже отдал новую. Единственный способ исправить ситуацию - удалить содержимое кэш-директории.

В Docker очистка выполняется через docker exec внутри работающего контейнера или через управление volume. В Kubernetes задача решается разовыми Job, проверками ReadinessProbe и Persistent Volumes. Цель одна - убрать устаревшие файлы, не уронив сервис. Это руководство даёт готовые команды и манифесты для обеих сред.

Если вы ещё не настраивали кэширование, начните с базовой настройки proxy_cache в Nginx. Для глубокого понимания структуры кэш-директории и параметров proxy_cache_path изучите руководство по очистке и инвалидации кеша Nginx.

Очистка кэша Nginx в Docker

Docker-контейнер с Nginx изолирован, но кэш лежит внутри его файловой системы. Доступ к нему возможен двумя путями: выполнение команды внутри контейнера или хранение кэша на внешнем volume. Первый способ быстрый, второй - управляемый.

Использование docker exec для удаления файлов кэша

Команда docker exec запускает процесс внутри работающего контейнера. Для очистки кэша Nginx выполните:

docker exec <container_name> rm -rf /var/cache/nginx/*

Путь /var/cache/nginx - стандартный для официального образа Nginx. В кастомных сборках он может отличаться. Проверьте фактическое расположение:

docker exec <container_name> ls /var/cache/nginx

Если директория пуста или отсутствует, найдите её через конфигурацию Nginx:

docker exec <container_name> nginx -T | grep proxy_cache_path

Вывод покажет точный путь, заданный директивой proxy_cache_path. Ошибка в пути при rm -rf опасна: можно удалить не те файлы. Перед выполнением всегда проверяйте содержимое целевой директории.

Хранение кэша на volume для удобной очистки

Если кэш лежит внутри контейнера, он исчезает при пересоздании контейнера. Это замедляет работу после каждого деплоя. Монтирование volume решает проблему: данные сохраняются между жизненными циклами контейнера, а очистка выполняется с хоста.

Запуск контейнера с volume:

docker run -d \
  --name nginx-cache \
  -v nginx-cache-volume:/var/cache/nginx \
  nginx:latest

Теперь очистить кэш можно двумя способами. Первый - через тот же docker exec, но данные физически находятся на volume:

docker exec nginx-cache rm -rf /var/cache/nginx/*

Второй - удалить содержимое volume с хоста. Найдите точку монтирования:

docker volume inspect nginx-cache-volume --format '{{ .Mountpoint }}'

Затем очистите директорию на хосте. Этот подход удобен, когда контейнер временно остановлен или доступ к нему ограничен. Для продакшена храните кэш на быстром хранилище, например на SSD-дисках от Timeweb Cloud, чтобы повторное заполнение кэша не создавало узкое место.

Очистка кэша Nginx в Kubernetes

В Kubernetes поды эфемерны. Кэш, хранящийся внутри контейнера, теряется при рестарте. Для сохранения данных используется Persistent Volume, а для очистки - Job или CronJob. ReadinessProbe гарантирует, что под не начнёт принимать трафик до завершения очистки.

Создание Job для разовой очистки кэша

Job запускает под, который выполняет команду и завершается. Это правильный способ разовой очистки кэша в Kubernetes. Пример манифеста:

apiVersion: batch/v1
kind: Job
metadata:
  name: nginx-cache-cleaner
spec:
  template:
    spec:
      containers:
      - name: nginx-cache-cleaner
        image: nginx:latest
        command: ["/bin/sh", "-c", "rm -rf /var/cache/nginx/*"]
        volumeMounts:
        - name: cache-volume
          mountPath: /var/cache/nginx
      volumes:
      - name: cache-volume
        persistentVolumeClaim:
          claimName: nginx-cache-pvc
      restartPolicy: Never

Примените манифест и проверьте статус:

kubectl apply -f nginx-cache-cleaner-job.yaml
kubectl get jobs
kubectl logs job/nginx-cache-cleaner

Job должен завершиться со статусом Completed. Если под падает с ошибкой, проверьте права доступа к Persistent Volume и корректность пути монтирования. Подробнее об управлении кэшем в Kubernetes читайте в руководстве по кэшированию в Docker и Kubernetes.

Настройка ReadinessProbe для проверки готовности после очистки

ReadinessProbe определяет, готов ли под принимать трафик. После очистки кэша Nginx может быть не готов обслуживать запросы, пока кэш не заполнится заново. Добавьте проверку, которая не пускает трафик до появления нужных файлов или до завершения очистки.

Пример конфигурации в Deployment:

readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - test ! -f /var/cache/nginx/cache_file || exit 0
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

Эта проверка возвращает успех, если файл cache_file отсутствует, то есть кэш очищен. Логику можно инвертировать: проверять наличие маркера завершения очистки. Главное - под не принимает трафик, пока условие не выполнено. Это снижает риск отдачи устаревших данных после деплоя.

Использование Persistent Volumes для отказоустойчивости

Persistent Volume хранит кэш вне жизненного цикла пода. При пересоздании пода данные сохраняются, и Nginx не начинает с холодного кэша. Это критично для высоконагруженных сервисов, где повторное заполнение кэша создаёт пиковую нагрузку на бэкенд.

Пример PersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-cache-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

Доступ ReadWriteMany нужен, если несколько реплик Nginx используют общий кэш. Для одиночного пода достаточно ReadWriteOnce. При очистке через Job подключите тот же PVC, что и у основного Deployment. Убедитесь, что у Job есть права на запись в эту директорию.

Автоматизация очистки кэша с помощью CronJob

Регулярная очистка предотвращает накопление устаревших данных и неконтролируемый рост кэш-директории. CronJob запускает Job по расписанию. Пример ежедневной очистки в 03:00:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nginx-cache-cleanup
spec:
  schedule: "0 3 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: nginx-cache-cleaner
            image: nginx:latest
            command: ["/bin/sh", "-c", "rm -rf /var/cache/nginx/*"]
            volumeMounts:
            - name: cache-volume
              mountPath: /var/cache/nginx
          volumes:
          - name: cache-volume
            persistentVolumeClaim:
              claimName: nginx-cache-pvc
          restartPolicy: Never

Параметр concurrencyPolicy: Forbid запрещает параллельный запуск нескольких Job. Это защищает от наложения очисток, если предыдущая ещё не завершилась. Выбирайте время с минимальной нагрузкой на сервис, обычно ночные часы. Для CI/CD-пайплайнов автоматизацию очистки можно встроить в этап деплоя, о чём рассказано в FAQ по администрированию динамического контента.

Риски и предостережения при очистке кэша

Очистка кэша не проходит бесследно. Сразу после удаления Nginx начинает заново запрашивать данные у бэкенда. Если трафик высокий, бэкенд может получить резкий всплеск нагрузки. Очищайте кэш в непиковые часы или используйте механизм stale-кэша, чтобы Nginx отдавал устаревшие данные, пока бэкенд не ответит.

Неправильный путь в команде rm -rf - самая опасная ошибка. Удаление не той директории приводит к потере данных или поломке контейнера. Всегда проверяйте путь через ls или nginx -T. Тестируйте очистку на staging-окружении перед запуском в продакшене.

При использовании Persistent Volumes учитывайте права доступа. Job, запущенный под другим пользователем, может не иметь прав на запись в директорию кэша. Настройте securityContext с правильным fsGroup или используйте initContainers для подготовки прав.

Заключение

В Docker очистка кэша Nginx выполняется через docker exec с командой rm -rf или через управление volume, смонтированным в директорию кэша. В Kubernetes используйте Job для разовой очистки, CronJob для регулярной, ReadinessProbe для контроля готовности и Persistent Volumes для сохранности данных. Выбор метода зависит от того, насколько часто нужно очищать кэш и какие требования к отказоустойчивости предъявляет сервис.

Проверяйте пути перед удалением, тестируйте на staging и очищайте кэш в непиковые часы. Эти меры минимизируют риски и сохраняют стабильность сервиса. Для углублённого изучения инвалидации кэша и стратегий разгрузки бэкенда обратитесь к руководству по инверсному кэшированию.