Комментарии 18
С недавних пор в docker-compose.yml не нужно указывать version
Дополню ваш комментарий ссылкой на спеку:
Compose spec: Version and name top-level elements
Version top-level element (obsolete)
The top-level version property is defined by the Compose Specification for backward compatibility. It is only informative you'll receive a warning message that it is obsolete if used.
Compose doesn't use version to select an exact schema to validate the Compose file, but prefers the most recent schema when it's implemented.
Compose validates whether it can fully parse the Compose file. If some fields are unknown, typically because the Compose file was written with fields defined by a newer version of the Specification, you'll receive a warning message. Compose offers options to ignore unknown fields (as defined by "loose" mode).
Спасибо, узнали что-то новое, исправим!
Спасибо за уточнение, это полезное дополнение.
Но получается так, что эти два сервиса, запускающие Karate-тесты, практически полностью дублируют друг друга. У них меняется только API_URL.
В таком случае можно было этот API_URL использовать из внешней переменной окружения.
environment:
API_URL: ${API_URL:-http://url}
Запускать как обычно.
Второй вариант - указать API_URL в командной строке самого compose:
docker compose -e API_URL="http://api" --file mystack.yaml upКстати, compose уже давно выделился в отдельный плагин, поэтому запуск через одну команду "docker-compose" - это легаси, в будущем может перестать работать. Нужно запускать как "docker compose".
Да, вы правы, можно использовать внешнюю переменную окружения. Но мы выбрали этот кейс как простой пример использования шаблонов сервисов. Нам, например, может понадобиться изменить скрипт в одном из копий сервиса, и для того, чтобы не копировать весь сервис, используем шаблон
Спасибо за совет о docker compose, учтем!
Начиная с какой-то версии уже давно не работает.
yaml можно называть просто compose.yml
Интересно, спасибо!
Ещё есть советы по поводу безопасности.. я понимаю что у вас тут, скорее всего, БД для тестов и данные в ней не очень секретные, но вашим примером может воспользоваться кто-то для другого случая и тогда безопасность пострадает.
Плохая привычка хранить пароли в compose файлах. Потому что они попадают в системы контроля версий (git, etc) и доступны всем кто имеет доступ к коду. Например, случайная компрометация репозитория может раскрыть доступ ещё и к данным, а часто на продакшене часть секретов совпадает (ключи, сертификаты, пользователи).
Публикация портов наружу. В вашем примере порт ( 5432:5432 ) будет опубликован для всех интерфейсов хоста. Что, вместе с предыдущим пунктом, приведёт к тому что кто угодно может подключиться к вашей базе. Вариант - использовать docker networks. У вас же всё на одном хосте? Включите все сервисы в одну network - и публикация портов не нужна совсем. Сервисы будут видеть друг друга внутри сети по именам контейнеров, а снаружи никто не сможет подключиться. Поскольку у вас независимые тесты - это идеальный вариант. В этом случае пароли можно использовать совсем простые и можно хранить внутри compose файла.
А если разработчик запускает бд через профиль only-db, а тесты с хоста через терминал? Как с локалхоста подключится к сети докер?
Вы правы, для чувствительных данных, таких как логин, пароль от базы данных, нужно использовать как минимум env переменные. Не добавили этого в статью, чтобы не усложнять пример. Чтобы попробовать фичи - достаточно скопировать и вставить, без создания переменных, откуда будут браться логины и пароли.
Что насчет портов: мы указали порт для базы данных, чтобы иметь возможность подключиться к ней из API, запущенного в IDE. Спасибо за совет, посмотрим в сторону бинда на локальный хост :)
Я бы ещё добавил health check на базу и для веб сервиса перед запуском тестов. У вас скорее все все стартует быстро, но при определенных условиях создание базы и старт веб сервиса соответственно могут знать какое-то время. То есть сервисы запустятся, но база не готова будет принимать запросы, и веб сервис тоже. Поэтому в docker compose добавили health check функционал https://docs.docker.com/compose/startup-order/. Вот тут есть примеры https://www.warp.dev/terminus/docker-compose-health-check. Для постгреса посмотрите в сторону pg_ ready.
Прикольно, healthcheck таки доехал до compose, раньше боль была.
healthcheck полезен, чтобы контейнер перезапускался при невыполнении заданного скрипта, но еще было бы неплохо добавить зависимостей для запуска сервисов, чтобы те же запросы к бд, как и само API, не падали без healthy бд сервиса: https://docs.docker.com/compose/compose-file/05-services/#long-syntax-1
Да, отличная идея добавить healthcheck. Мы используем эту фичу в наших других проектах, но для простоты примера не добавили её в статье, чтобы сфокусироваться на представленных выше фичах. Спасибо за совет!
Публикации
Клёвые фичи в Docker Compose — профили и шаблоны