Csak az a baj, hogy a konténerezéshez passzoló konfig kezelési alternatívák eléggé nehézsúlyúak.
Először is, azt nagyon erősen antipattern-nek tartom, hogy a konfigonként külön image-et csináljon az ember. Még akkor is, ha a docker az image layer-ekkel elég takarékosan meg tudja oldani. Az image-eket nemcsak egyszer kell legyártani, hanem van karbantartási költségük is, sőt hosszabb távon ez lesz a domináns munka. Gondolj arra, ha kiderül, hogy pl security hiba miatt valamelyik random libet frissíteni kell az összes image-ben. Az image az maradjon csak meg 'template'-nek, amiből tetszőlegesen sok service instance-ot lehet indítani eltérő konfiggal.
Erre azt szokták csinálni, hogy valami etcd vagy consul vagy hasonló elosztott konfig key-value store-t üzemeltetnek legalább egy példányban a hoston (nyilván ezek inkább több node-os kubernetes vagy docker swarm clusterre vannak kitalálva), a konténeren belüli alkalmazás pedig ebből veszi ki a zoxigé... neki szóló paramétereket. A meglevő alkalmazások többségében nincs etcd vagy consul kliens (egyébként is szerintem rossz ötlet lenne mindenben függőséget kiépíteni ezekre), ezért vannak olyan toolok, mint confd, ami legenerál egy-egy konfigfile-t, és feliratkozik a változásokra a key-value store-ban, változtatás esetén újragenerálja. Így a konfigfile a teljes életét a konténeren belül éli le, nem kell volume-ozni. Ha inotify-os konfig reload van az alkalmazásban, akkor valószínűleg ez a legkulturáltabb megoldás. Csak igényel pár dedikált service-t és elég munkás megcsinálni a teljes konfig automatizálást.
---
Régóta vágyok én, az androidok mezonkincsére már!