Как проверить, готов ли экземпляр Docker Cassandra к подключению

Question

У меня есть два экземпляра docker, которые я запускаю с помощью docker-compose. Один держит экземпляр Кассандры Один содержит приложение Spring Boot, которое пытается подключиться к этому приложению.

Однако приложение Spring Boot всегда будет отказывать, поскольку оно пытается подключиться к экземпляру Cassandra, который еще не готов к подключению.

Я пробовал:

• Использование рестарта: всегда в Docker-compose
  • Это все еще не всегда работает, потому что Cassandra может быть «достаточно», чтобы больше не вызывать сбой приложения Spring Boot, но не «достаточно», чтобы успешно создать семейство таблиц / столбцов. Кроме того, это очень хакерское решение.
• Использование проверки здоровья
  • Кажется, что проверка работоспособности в compose не имеет возможности перезапуска
• Использование bash-скрипта в качестве точки входа
  • В надежде, что я смогу использовать netstat, ping, ... что угодно, чтобы определить состояние готовности Кассандры

Прямо сейчас единственное, что действительно работает, - это использовать тот же скрипт bash и приостановить процесс на x секунд, а затем запустить jar. Это еще более странно ...

У кого-нибудь есть идеи, как это решить?

Спасибо!

Answer 1

Служба весенней загрузки, определенная в docker-compose.yml зависит от , - служба Кассандара? Если да, то служба запускается, только если служба cassandra готова.

https://docs.docker.com/compose/compose-file/#depends_on

Взгляните на этот репозиторий github, чтобы найти проверку здоровья для службы кассандры.

https://github.com/docker-library/healthcheck

ЗАКЛЮЧЕНИЕ

После некоторого обсуждения мы выяснили, что docker-compose, по-видимому, не обеспечивает функциональность для ожидания, пока сервисы не будут исправными и работоспособными, такими как Kubernetes и Openshift (см. Комментарии ниже). Они рекомендуют использовать скрипт-обертку (docker-entrypoint.sh), который ожидает запуска зависимой службы, что делает необходимые двоичные файлы, которые не должны использоваться реальной службой, такой как двоичный файл клиента cassandra. Кроме того, служба, зависящая от Кассандры, никогда не сможет подняться, если Кассандра этого не сделает, чего не должно быть.

Главное для микросервисов является то, что они должны быть устойчивыми к сбоям и не должны погибать или не появляться, если в данный момент недоступна зависимая служба или неожиданно исчезает. Следовательно, микросервис должен быть реализован таким образом, чтобы он пытался установить соединение после запуска или неожиданного исчезновения. Неожиданно - это слово, которое на самом деле неправильно используется в этом контексте, потому что вы всегда должны ожидать таких проблем в распределенной среде, и даже при использовании docker-compose вы столкнетесь с такими проблемами, как обсуждалось в этой теме.

Следующая ссылка указывает на руководство, которое помогло правильно интегрировать cassandra в приложение весенней загрузки. Он предоставляет способ реализации извлечения соединения cassandra с повторным поведением, поэтому служба устойчива к несуществующей базе данных cassandra и больше не будет запускаться. Надеюсь, это поможет и другим.

https://dzone.com/articles/containerising-a-spring-data-cassandra-application