Surtout avec Rails, je n'ai aucune expérience, mais regardons d'un point de vue de docker et d'ingénierie logicielle.
L'équipe Docker préconise, parfois de manière assez agressive, que les conteneurs concernent les applications d'expédition. Dans cette très belle déclaration , Jérôme Petazzoni dit que tout est question de séparation des préoccupations. Je pense que c'est exactement le point que vous avez déjà compris.
L'exécution d'un conteneur rails qui démarre une migration ou une configuration peut être utile pour le déploiement initial et probablement souvent nécessaire pendant le développement. Cependant, lors de la mise en production, vous devriez vraiment envisager de séparer les préoccupations.
Ainsi, je dirais avoir une image, que vous utilisez pour exécuter le conteneur N rails et ajouter un conteneur tools/migration/setup quel que soit le conteneur, que vous utilisez pour effectuer des tâches administratives. Regardez ce que les développeurs de l'image officielle des rails dites à ce sujet :
Lorsque vous regardez cette image, il n'y a pas de commande de configuration ou de migration. C'est totalement à l'utilisateur de savoir comment l'utiliser. Ainsi, lorsque vous devez exécuter plusieurs conteneurs, continuez.
D'après mon expérience avec mysql cela fonctionne bien. Vous pouvez exécuter un conteneur de données uniquement pour héberger les données, exécuter un conteneur avec le serveur mysql et enfin exécuter un conteneur pour des tâches administratives telles que la sauvegarde et la restauration. Pour les trois conteneurs, vous pouvez utiliser la même image. Vous êtes maintenant libre d'accéder à votre base de données depuis disons plusieurs Wordpress conteneurs. Cela signifie une séparation claire des préoccupations. Lorsque vous utilisez docker-compose il n'est pas si difficile de gérer tous ces conteneurs. Il existe certainement déjà de nombreux conteneurs et outils tiers pour vous aider également à mettre en place une application complexe composée de plusieurs conteneurs.
Enfin, vous devez décider si docker et l'architecture de micro-services correspond à votre problème. Comme indiqué dans cet article il y a des raisons contre. L'un des principaux problèmes étant qu'il ajoute une toute nouvelle couche de complexité. Cependant, c'est le cas avec de nombreuses solutions et je suppose que vous en êtes conscient et que vous êtes prêt à l'accepter.
