A lire, cette màj:

Update: The conclusion of this post talks about managing Docker kittens with Ansible; I no longer do that, but instead use Amazon ECS with Terraform. Docker has stabilized a lot since my early experiences as well. However some things like custom kernel parameters (e.g. for Redis) will always be a limitation. I’ll write a new blog post on how I use ECS and Terraform soon.

Huhu.. Toujours est-il que ces schedulers docker sont encore bien jeunes pour y faire tourner de la prod. ECS semble stable mais il souffre d'un manque de fonctionnalité pour faire du stateful:

• Pas de notion d'affinité / d'anti-affinité entre tâches, même si on trouve ce workaround dégueu: https://github.com/aws/amazon-ecs-agent/issues/212#issuecomment-143591755 (cf. https://jeekajoo.eu/links/?-RNUJQ)
• Pas de support des drivers de stockage: https://github.com/aws/amazon-ecs-agent/issues/236 . Rédhibitoire pour faire tourner une base de données mysql ou postgresql.
• On doit se farcir le discovery des services via un consul / etcd qu'on va gérer soit-même. C'est possible, mais hors process et faillible car en dehors du contrôle des services dont le rôle est de respawner des tâches. cf https://jeekajoo.eu/links/?5Rqafg

Yes, two tasks from the same task definition can be started on the same container instance as long as none of the consumed resources conflict. If you want to prevent this behavior, the easiest way is to assign a host port in the task definition. Assigning a host port will consume a resource (a port) on the host that is then unavailable when the second task needs to be placed.

Haha, voici la méthode pour créer une sorte d'anti-affinité entre des tâches dans un cluster ECS ; pour faire en sorte que 2 tâches ne se retrouvent pas sur la même instance (vm).
D'après le commentaire juste en dessous, ils bossent pour proposer une option. Dans le futur, on peut donc espèrer un truc éminemment plus propre que cette gruikerie réseau.