Конфигурирование 1000 контейнеров, в частности, с 1000 различных конфигураций, даже если это один и тот же образ контейнера, не является желательным сценарием.
Либо вам нужно будет, чтобы инструмент оркестровки знал о том, какие контейнеры живы какие конфиги, и будьте в курсе всех доступных конфигов. Это не практично, но выполнимо.
Или сами контейнеры должны будут знать обо всех конфигах и общаться между собой о том, у кого какой конфиг. Это практично, но трудно сделать правильно.
Третий вариант - создать специализированный контейнер, в котором размещаются конфиги, так же, как вы можете создать реестр для своих контейнеров. Если конфиги являются файлами, они могут просто находиться в подключенном томе, который отслеживается приложением «config registry». Для этого приложения было бы намного проще контролировать, какие конфиги были переданы в какие контейнеры.
Ваше приложение должно было бы зарегистрироваться в этом "реестре конфигурации" при запуске и получить свою конфигурацию. В случае интеграции с кластерным API docker он мог бы контролировать раскручивание новых контейнеров, когда в его списке есть конфиги, которые еще не были переданы контейнеру приложения. Таким образом, вы можете удалить новую конфигурацию в сопоставленном томе контейнера «config registry», и это приведет к тому, что новый контейнер будет запущен вместе с конфигурацией.
Вам также потребуется проверка работоспособности из реестр для каждого контейнера периодически. Если контейнер исчезает, аренда конфигурации «заканчивается» - и он должен попытаться создать новый контейнер для конфигурации.
Это потребует некоторой работы, я уверен - но результат будет более масштабируемым. Если вы используете Java, загляните в Spring Cloud Config - они, возможно, уже решили этот вариант использования, не уверен.
Ну, это всего лишь мысль. Звучит полезно?