Коллеги, а кто-нибудь из вас добрался до необходимости собирать и тестировать контейнеры Docker в CI?
Суть вопроса в следующем: есть нагруженная микросервисная архитектура (финтек, агрегация и обработка данных с рынка), построенная на Docker+Spring Boot+Netflix Cloud. В качестве отправной точки выбрали сборку Alpine Linux с Java 8, на основе которой построили свой базовый образ (БО) для всех микросервисов. Аналогично поступили со всеми используемыми базами данных и сторонними сервисами (Kafka, Influx, Mongo, Pg...). Поскольку микросервисы строятся на нашем БО, это позволяет контролировать через него версию Alpine, версию Java и при необходимости накатывать нужные патчи или менять конфигурацию линукса. Естественно, хочется как-то верифицировать качество БО. CI уже собирает его и публикует в наш репозиторий. Как и что здесь можно тестировать?
B>Коллеги, а кто-нибудь из вас добрался до необходимости собирать и тестировать контейнеры Docker в CI?
B>Суть вопроса в следующем: есть нагруженная микросервисная архитектура (финтек, агрегация и обработка данных с рынка), построенная на Docker+Spring Boot+Netflix Cloud. В качестве отправной точки выбрали сборку Alpine Linux с Java 8, на основе которой построили свой базовый образ (БО) для всех микросервисов. Аналогично поступили со всеми используемыми базами данных и сторонними сервисами (Kafka, Influx, Mongo, Pg...). Поскольку микросервисы строятся на нашем БО, это позволяет контролировать через него версию Alpine, версию Java и при необходимости накатывать нужные патчи или менять конфигурацию линукса. Естественно, хочется как-то верифицировать качество БО. CI уже собирает его и публикует в наш репозиторий. Как и что здесь можно тестировать?
раз уж вы вытащили отдельно (в образы?) сторонние базы и сервсисы, тогда интеграционные или юнит тесты в докере удобно в CI засовывать интегрировать: добавляете такой build-step в ваш CI:
docker-compose up --exit-code-from my_integration_tests
докер дождется завершения контейнера my_integration_tests и передаст его код завершения в CI. ну и консольные логи тестов передаст парсеру логов CI.
Здравствуйте, VladCore, Вы писали:
B>>Естественно, хочется как-то верифицировать качество БО. CI уже собирает его и публикует в наш репозиторий. Как и что здесь можно тестировать?
VC>раз уж вы вытащили отдельно (в образы?) сторонние базы и сервсисы, тогда интеграционные или юнит тесты в докере удобно в CI интегрировать
Это само собой, только на вопрос это никак не отвечает...
Здравствуйте, Baudolino, Вы писали:
B>>>Естественно, хочется как-то верифицировать качество БО. CI уже собирает его и публикует в наш репозиторий. Как и что здесь можно тестировать?
VC>>раз уж вы вытащили отдельно (в образы?) сторонние базы и сервсисы, тогда интеграционные или юнит тесты в докере удобно в CI интегрировать B>Это само собой, только на вопрос это никак не отвечает...
Потому что непонятно зачем тестировать базовый образ отдельно. У вас уже есть тесты контейнеров построенные с вашим образом или без него. Докер как раз для того и придумали что бы деплоить приложение вместе с ОС и зависимостями заточенными под ваш код.
или кто то будет свои образы делать под себя а вам нужно чтото типа примера по типу reference example of a custom image?
VC>Потому что непонятно зачем тестировать базовый образ отдельно.
Причина ровно та же, зачем пишутся юнит-тесты для библиотек — верифицировать контракты библиотеки. Базовый образ это та же библиотека со своими контрактами: если изменение версии одного из его компонентов приводит к нарушению контракта, то неплохо бы узнать об этом до того, как на основе БО будет построен образ приложения и отправлен в тестирование.
