Tu vas pas spécialement avoir d’impact sur les performances et la disponibilité en fait.
Sur la disponibilité il y quand-même des sujets.
Le premier est que pour garantir à l'application d'avoir sa bdd au démarrage on choisit souvent d'écrire un "health-check" qui permet au superviseur de conteneurs de savoir que la bdd est prête avant de démarrer l'application. Si on ne fait pas attention on donne là facilement un prétexte au superviseur pour dézinguer la bdd dès que celle-ci est en surcharge. Ça peut faire mal.
Le second est que certains scénarios de migration sans interruption de service demandent d'intervenir à un niveau très bas dans la pile réseau, ici faire tourner la bdd sous un superviseur de conteneur qui a tendance à traiterle réseau comme son domaine privé va plutôt être un obstacle. Cela peut concerner par exemple le redimensionnement des disques ou le changement de version.
Enfin cela veut aussi dire que planter le superviseur de conteneurs ferait planter la bdd, dont on augmente donc un peu le risque de plantage et réduit donc la disponibilité.
Selon le contexte ces sujets peuvent être sans aucune importance ou par exemple importants.
(Autre pan de la discussion il y aussi des raison extra-techniques qui vont disqualifier cette option, s'il faut par exemple garantir que des équipes différentes administrent la bdd et d'autres développent et opèrent les applications.)
[^] # Re: docker, lecture seule avec volume externe
Posté par Michaël (site web personnel) . En réponse au message Sauvegarde mariadb dans docker. Évalué à 2. Dernière modification le 11 mai 2021 à 15:55.
Sur la disponibilité il y quand-même des sujets.
Le premier est que pour garantir à l'application d'avoir sa bdd au démarrage on choisit souvent d'écrire un "health-check" qui permet au superviseur de conteneurs de savoir que la bdd est prête avant de démarrer l'application. Si on ne fait pas attention on donne là facilement un prétexte au superviseur pour dézinguer la bdd dès que celle-ci est en surcharge. Ça peut faire mal.
Le second est que certains scénarios de migration sans interruption de service demandent d'intervenir à un niveau très bas dans la pile réseau, ici faire tourner la bdd sous un superviseur de conteneur qui a tendance à traiterle réseau comme son domaine privé va plutôt être un obstacle. Cela peut concerner par exemple le redimensionnement des disques ou le changement de version.
Enfin cela veut aussi dire que planter le superviseur de conteneurs ferait planter la bdd, dont on augmente donc un peu le risque de plantage et réduit donc la disponibilité.
Selon le contexte ces sujets peuvent être sans aucune importance ou par exemple importants.
(Autre pan de la discussion il y aussi des raison extra-techniques qui vont disqualifier cette option, s'il faut par exemple garantir que des équipes différentes administrent la bdd et d'autres développent et opèrent les applications.)