Нашел 3 пути.
1. Первый и правильный с точки зрения назначения консула описан тут:
поднимаем кластер для использования в качестве discovery-сервиса и потом заполняем данными из клиента.
https://github.com/deployable/docker-consul
2. Способ на котором мы пока остановились - храним данные в volume. Есть проблемы с правами при разворачивании проекта в новом окружении.
3. Костыльный и неправильный , но рабочий способ - подставить в качестве entrypoint свой скрипт, который запускает 2 скрипта - один в фоновом режиме пингует поднятие консула и заполняет его данными, второй собственно поднимает сам консул.
Примерное содержимое файлов:
Docker-compose.ymlversion: '3.2'
services:
consul:
build:
context: ./
dockerfile: Dockerfile
ports:
- 8500:8500
entrypoint: sh -c "cd /confrun/ && sh kvconf.sh"
Dockerfile
FROM consul:latest
COPY ./confrun/ /confrun/
RUN chmod 755 -R /confrun/
EXPOSE 8300 8400 8500 8600
ENTRYPOINT sh -c "cd /confrun/ && sh kvconf.sh"
kvconf.sh
#!/usr/bin/dumb-init /bin/sh
sh ./subscriber.sh &
sh ./runner.sh
subscriber.sh
#!/bin/bash
let "timeout = $(date +%s) + 15"; \
while ! curl -f -s
localhost:8500/v1/status/leader | grep "[0-9]:[0-9]"; do\
if [ $(date +%s) -gt $timeout ]; then echo "timeout"; exit 1; fi; \
sleep 1; \
done; \
consul kv put sql/config/addr db;
...все нужные команды. Чтобы избежать повторного заполнения при старте, нужно дописать consul get с проверкой на значение...
runner.sh
#!/bin/bash
consul agent -server -ui -bind 0.0.0.0 -client 0.0.0.0 -bootstrap-expect 1 -data-dir /consul/data -config-dir /consul/config
Ну и в принципе вместо runner.sh будет правильнее подставить стандартный скрипт консула entrypoint.sh.
До конца этот путь не довел, т.к. все-таки слишком костыльно на мой взгляд, но все запускалось и значения добавлялись.