Bonjour,
En général, quand on utilise des conteneurs, on sépare tout : 1 conteneur pour l'app, 1 pour la BDD, etc.
Typiquement, si tu utilises docker en dev tu auras :
- un conteneur pour l'app symfony/api-platform
- un conteneur node pour le front (pour le build et le live-reload)
- un conteneur pour la BDD
En dev sur ta machine, tu n'as pas forcément besoin d'un Dockerfile (tout dépend des extensions serveur que tu utiliseras).
C'est au moment de déployer que tu devras faire un build de ton (tes) image(s).
Là c'est dépendant de ton appli, mais je pense que dans ton cas, tu as mis ton app js dans le dossier assets de symfony, donc tu devras avoir un Dockerfile avec ce qu'on appelle un multi stage build, c'est à dire qu'il fera d'abord un build du js avec node et ensuite il copiera les fichiers buildés/minifiés dans ton app SF (dans 'public/build' en général) et ton conteneur final ne contiendra que ce qui est utile pour faire tourner SF (plus besoin de node puisque tes js sont buildés).
Sur le principe, le Dockerfile va faire qqchose comme ça (mon app n'est pas à la racine du projet mais dans 'app') :
Pour les images, perso, j'aime bien utiliser FrankenPhp, mais comme je n'aime pas devoir builder pour démarrer un projet en local, j'ai fait ma propre image qui se base dessus et dans laquelle j'ai intégré les extensions que l'équipe dans laquelle je bosse utilise tout le temps.
Si tu veux un exemple de compose.yaml, voici un starter_kit que j'ai fait pour des projets php symfony : https://github.com/timinh/starter_kit
Et un autre avec node activé (c'est un projet exemple pour une formation que j'ai animée avant l'été sur symfony/api-platform et vue.js mais le principe est le même avec react) : https://github.com/timinh/formation_symfony_vue/tree/session_distance_26_juin
Dans cet exemple je n'utilise pas webpack, je préfère utiliser vite, mais après c'est juste de la config à adapter.
Il n'y a pas de Dockerfile pour la mise en prod mais je pourrai en ajouter un dans le starter kit si tu veux un exemple.