Використовуєте What’s Up Docker (WUD) для моніторингу оновлень, але раптом зіткнулися з помилкою “Request failed with status code 429”? Навіть за наявності авторизації на Docker Hub та налаштованого розкладу (cron), приховані тригери можуть непомітно вичерпувати ваші ліміти запитів. У цій статті розбираємось, як параметри WATCHEVENTS та WATCHATSTART генерують зайвий трафік, і як правильно їх налаштувати, щоб моніторинг працював стабільно, передбачувано та без блокувань.

Вступ

Я використовую сервіс WUD для моніторингу нових версій своїх докер контейнерів. Я отримав вчора лист, що оновлення доступно для 6 контейнерів, але вчора я на WUD не заходив і контейнери не оновлював. Проте в веб інтерфейсі згодом я побачив лише два запити на оновлення, що викликало підозру.

Помилка Request failed with status code 429

Сьогодні вирішив повторно зайти на веб інтерфейс WUD, і побачив помилку: Error – Request failed with status code 429

Чому так відбувається? Адже я вже робив спробу уникнути цього, я зареєструвався та залогінівся на Docker Hub, також я створив Cron, щоб перевірка оновлення відбувалася лише один раз на добу об 12 годині дня, а не постійно, щоб не виходити за межі обмежень кількосіт запитів.

Причина виникнення помилки

Щоб ідентифікувати причину постійних запитів, я подивився на логи сервіса, і побачив, що сервіс стартує з наступними параметрами:

INFO whats-up-docker/watcher.docker.local: Register with configuration {"cron":"0 0 12 * * *","socket":"/var/run/docker.sock","port":2375,"jitter":60000,"watchbydefault":true,"watchall":false,"watchevents":true,"watchatstart":true}

З логів видно, що два параметри мають активний статус:

• “watchevents”:true
• “watchatstart”:true

Я розгляну кожен параметр більш детально

watchevents

Параметр WATCHEVENTS визначає, чи буде WUD постійно “слухати” події локального Docker-демона. Якщо ця функція увімкнена (за замовчуванням true), сервіс автоматично ініціює позачергову перевірку оновлень щоразу, коли стан будь-якого відстежуваного контейнера змінюється – наприклад, під час його створення, зупинки або ручного перезапуску. З одного боку, це дозволяє системі миттєво реагувати на зміни в інфраструктурі, але з іншого – під час масового ручного оновлення контейнерів WUD генерує лавину запитів до реєстрів (таких як Docker Hub). Це швидко вичерпує безкоштовні ліміти API, нівелює налаштований розклад cron та призводить до блокування з помилкою 429 (Too Many Requests).

watchatstart

Параметр WATCHATSTART відповідає за поведінку WUD під час його власного старту або перезавантаження. Увімкнений параметр змушує сервіс негайно виконувати повну перевірку всіх контейнерів одразу після запуску, не чекаючи наступного спрацьовування таймера cron. Хоча це зручно для отримання актуального статусу відразу після підняття сервера, часті перезапуски самого контейнера WUD (наприклад, під час налагодження конфігурації або частих деплоїв) згенерують велику кількість одночасних запитів. Вимкнення цього параметра допомагає суворо дотримуватися заданого розкладу та економити дорогоцінні ліміти звернень до Docker Hub.

Зміна конфігурації

Для виправлення помилки достатньо, вимкнути ці параметри в конфігурації докера, в блоці змінних оточення:

environment:
  - WUD_WATCHER_LOCAL_WATCHEVENTS=false
  - WUD_WATCHER_LOCAL_WATCHATSTART=false

Щоб дії вступили в силу, необхідно перезавантажити контейнер командою

docker compose up -d

та почекати 6 годин, поки автоматично не зніметься обмеження з докер хабу.

Висновки

Вимкнення параметрів WATCHEVENTS та WATCHATSTART є важливим кроком для стабільної роботи What’s Up Docker, особливо при використанні безкоштовних акаунтів Docker Hub з їхніми жорсткими лімітами. Хоча ці функції за замовчуванням забезпечують миттєву реакцію на зміни, на практиці вони генерують лавину фонових запитів під час будь-яких ручних маніпуляцій з контейнерами або перезапусків сервера, що швидко призводить до блокування та помилки 429 (Too Many Requests).

Передавши повний контроль над розкладом перевірок виключно планувальнику cron, ви усуваєте непередбачуваний мережевий трафік, ефективно зберігаєте квоти API та гарантуєте собі надійний, спокійний моніторинг оновлень інфраструктури без ризику раптових відключень.