Существуют разные виды ошибок, и они появляются в разных местах. Эта ошибка была трудной, потому что она обнаружилась там, где мы ее не ожидали.
На прошлой неделе мы заметили, что наши развертывания веб-приложений Java в kubernetes (k8s) перестали работать на прошлой неделе. Все началось с небольшой команды, которая выполнила развертывание (для non-prod). Ошибка началась с неудачного развертывания. Мы используем датчики живости и готовности, чтобы помочь k8s сообщить нам, правильно ли работает приложение. Наш тест на живость терпел неудачу. Это странно. Это просто говорит нам, можем ли мы сказать “привет” в ответ на http GET.
Наша первая идея – посмотреть наши журналы. Мы увидели ошибку: Последний пакет, успешно отправленный на сервер, был отправлен 0 миллисекунд назад. Драйвер не получил никаких пакетов от сервера.
Хммм… Это странно. Трассировка стека была получена из нашего клиентского соединения MySQL. Не было никаких изменений в:
- Код, который подключается к MySQL.
- Версия клиентской библиотеки.
- Экземпляр MySQL.
Мы отменили фиксацию и хотели посмотреть, позволит ли нам вернуться к предыдущей фиксации. Нет. Итак, теперь у нас есть “тот же” код, запущенный в контейнере docker, работающем в том же развертывании, работающем с ТОЙ же базой данных.
Это та часть шоу, где режиссер ускоряет время, чтобы показать, что актеры выполняют БОЛЬШУЮ работу, но не хотят тратить время на изучение каждой мельчайшей детали. То же самое относится и к нам. Мы начали пробовать все мыслимые библиотеки и вносить изменения, какие только могли. (Перенесемся на несколько часов вперед…)
Затем мы вернулись и повторили ошибку:
Последний пакет, успешно отправленный на сервер, был отправлен 0 миллисекунд назад. Драйвер не получил никаких пакетов от сервера.
Для нас это не имело смысла и поэтому я сделал то, чего обычно не делаю. Я прокрутил более 5000 строк трассировки стека, “вызванных” линиями, до дна ямы. Внизу я нашел это сообщение: Вызвано: javax.net.ssl. Исключение SSLHandshakeException: Нет подходящего протокола (протокол отключен или наборы шифров не подходят) . Это была наша лучшая хлебная крошка на сегодняшний день! Это указывало на то, что возникла проблема с установлением безопасного соединения. Хммм…
Один момент, который вы должны понять, заключается в том, что Java обрабатывает соединения TLS (он же SSL) в JVM. Когда вы открываете соединение с другой службой, JVM выполняет всю настройку безопасного соединения.
Поэтому я задал вопрос: “Изменилась ли Java JVM/JRE в последнее время?” Ответ был: “да”. Мы обнаружили, что изменение в JVM привело к тому, что разрешенные версии TLS стали более строгими: https://bugs.openjdk.java.net/browse/JDK-8254713 .
Вы видите, что наши сервисы запускаются с использованием контейнера docker. Мы основали наш контейнер docker на текущей LTS Java: gcr.io/distroless/java:11 . О чем мы не подумали, так это о том, что это не специально закрепленная версия. Это означает, что сопровождающие репозитория docker будут периодически обновлять его. Оказывается, они сделали это после последней точечной версии Java 11. Мы смогли немедленно исправить это, изменив базовое изображение на: openjdk:11.0.8-jre . Это относится к конкретному выпуску JVM. Мы также отправили запрос на обновление нашего TLS для нашей базы данных.
Что ж, я надеюсь, что если вы это увидите, то это будет более очевидно и займет меньше времени на поиск решения!
Оригинал: “https://dev.to/stevesmashcode/why-did-my-java-web-app-stop-working-with-mysql-1oig”