问题
We are deploying multiple containers(1000) using ECS, each container use the same code to start an application, but will consume a different config file (we have the files ready.) You can think about the scenario like this: there is 1000 files, and there is 1000 containers, each container will get its unique file and do some work.
One simple approach would be create individual docker image for each container instance, with the only difference of that config file. (Definitely not a good approach.)
How can we do this using a single image. Does ECS support single image but you can pass in different files/parameters?
Another approach would be have some logic when the container start, it will get the file from a service(like S3). But the requirement is that each container needs to get a unique file (1000 files maps to 1000 containers). What's the best way to do this?
回答1:
Configuring 1000 containers specifically with 1000 different configs, even if it is the same container image, is not a desirable scenario.
Either you will have to have the orchestration tool be aware of which containers are alive with which configs, and be aware of all the configs that are available. This is not practical, but doable.
Or the containers themselves will have to know of all the configs, and communicate between themselves about who's got what config. This is practical, but hard to do right.
A third option would be to build a specialized container that hosts the configs, in the same manner that you may have a registry for your containers. If the configs are files, they could simply reside in a mounted volume, that is monitored by the contained "config registry" application. It would be a much easier task for this application to control what configs have been passed to what containers.
Your application would have to register with this "config registry" on startup, and receive its configuration. If integrated with the docker cluster API, it could control spinning up new containers when it had configs in its list, that were not handed off to an application container yet. In this manner, you could drop a new config in the mapped volume of the "config registry" container, and that would result in a new container being spun up with the configuration.
You would also need a healthcheck from the registry to each container periodically. If a container vanishes, the configuration lease "ends" - and it should seek to create a new container for the configuration.
This would require some work I am sure - but the result would be more scalable. In case you are using Java, look into Spring Cloud Config - they may have solved this usecase already, not sure.
Well, that's just a thought. Does it sound useful?
来源：https://stackoverflow.com/questions/61000720/distribute-files-between-multiple-docker-containers