Concernant la base de données ne pouvant pas être placée dans Docker, il y a deux articles tordus, l'un est posté par l'auteur original, et le second est cet article, traduit
.
Toujours le même point de vue :
Lorsque le volume est petit, vous pouvez le faire avec désinvolture. Lorsque le volume est important, certaines choses ne fonctionneront pas. Les bases de données traditionnelles et le docker ne sont pas la bonne méthode. Il est recommandé de ne pas les conteneuriser directement. la base de données, vous avez besoin de la prise en charge de divers systèmes, notamment des systèmes middleware et des systèmes conteneurisés.
Si votre base de données peut automatiquement évoluer, effectuer une reprise après sinistre, changer et est livrée avec sa propre solution multi-nœuds, Docker est une meilleure solution.
Mais sinon, n’utilisez pas Docker.
Le texte original est également très clair :
在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。
Lorsque le trafic est faible, tout peut être conteneurisé. Base de données, application, hadoop, divers nœuds, nginx.
Lorsque le volume est important, les services liés au stockage ne sont pas adaptés à la conteneurisation. Les services sans état tels que la couche application et la couche métier conviennent à la conteneurisation. Les services gourmands en mémoire tels que la mise en cache peuvent être conteneurisés.
Pour faire simple, il y a trois problèmes : la reprise après sinistre, les performances et la cohérence des données.
En ce qui concerne les bases de données traditionnelles comme MySQL, il y a tellement de problèmes que je peux énumérer :
Comment conteneuriser MySQL ?
Que dois-je faire si la base de données principale mysqld s'agenouille ?
Que dois-je faire si le dockerd de la bibliothèque principale s'agenouille ?
Que dois-je faire si l'esclave mysqld s'agenouille ?
Que dois-je faire si le docker esclave s'agenouille ?
Mysql peut-il être rapidement étendu via des conteneurs lorsque le pic approche ? plan?
Solution de commutation maître-esclave de données ? Comment assurer la cohérence ?
Le volume pendant les périodes de pointe est suffisamment important, et parfois la capacité d'une machine physique n'est suffisante que pour un seul processus MySQL.
Donc c'est aussi une seule machine, pourquoi mysql ne peut-il pas être démarré directement ?
Pourquoi devons-nous mettre un conteneur à l'extérieur ? Quelle est la perte de performance ?
Comment mettre à jour MySQL ?
Le volume de données perdra-t-il des données ? (J'ai rencontré plusieurs fois des conteneurs endommagés...)
Mais MySQL n'est pas complètement incontenable. Les entreprises qui ne sont pas sensibles à la perte de données (comme les produits trouvés par la recherche JD.com) peuvent être numérisées et utiliser le partage de base de données pour augmenter le débit en augmentant le nombre d'instances.
En ce qui concerne les problèmes mentionnés dans l'article original, certaines choses ont des défauts, mais elles sont bien pensées. Par exemple, la question suivante est très problématique (à propos des répertoires de données partagés) :
En ce qui concerne les bases de données avec lesquelles j'ai été en contact jusqu'à présent, seules les bases de données telles que cassandra (il existe également tidb et cockroachdb, mais je n'ai pas encore rencontré de cas d'utilisation dans les grandes entreprises) sont adaptées à la conteneurisation.
Mais Cassandra elle-même est également sur le point d'être apatride : elle fournit ses propres solutions de reprise après sinistre, d'extension de capacité et de commutation.
Ce qui suit est une mention de JD.com.
JD.com est une valeur aberrante, mais JD.com a également mentionné des problèmes similaires et des éléments qui nécessitent une attention particulière.
S'il n'y a aucun problème avec une seule machine, cela est toujours bénéfique dans certains cas. Par exemple, lorsque la base de données Oracle de mon entreprise ajustait les paramètres auparavant, la base de données s'est écrasée et n'a pas pu être démarrée. Heureusement, j'utilisais Docker. cette fois-là, je l'ai donc exécuté directement. Pointez simplement le répertoire de données vers celui d'origine
.
Peu importe la façon dont vous créez un cluster, il n'est pas facile de le configurer manuellement à l'aide de docker ou d'outils comme swarm. Il est préférable de le construire directement sur une machine physique pour éviter les ennuis
.
Il existe une entreprise à l'étranger spécialisée dans les solutions de stockage de données pour les dockers, par exemple, flocker et rancher's convoy
Docker est plus adapté aux apatrides et ne changera pas le service.
S'il y a un grand nombre de clusters : Écrivez le fichier docker. Ensuite, lorsque le code est téléchargé dans l'entrepôt de code, après avoir déployé le fichier docker, laissez le script de publication créer le service docker par lots et y insérer le code du service.
Non seulement MySQL, mais similaire à Redis et mc ne sont pas adaptés à l'installation dans Docker. En d'autres termes, mettre la base de données dans Docker est juste pour le plaisir d'utiliser Docker, et il n'y a pas beaucoup d'avantages.
Oui, car les caractéristiques de Docker déterminent qu'il n'est pas adapté au stockage de données. Non seulement les bases de données, mais également tous les services liés au stockage ne sont pas adaptés à l'utilisation de Docker.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Concernant la base de données ne pouvant pas être placée dans Docker, il y a deux articles tordus, l'un est posté par l'auteur original, et le second est cet article, traduit
.Toujours le même point de vue :
Lorsque le volume est petit, vous pouvez le faire avec désinvolture. Lorsque le volume est important, certaines choses ne fonctionneront pas. Les bases de données traditionnelles et le docker ne sont pas la bonne méthode. Il est recommandé de ne pas les conteneuriser directement. la base de données, vous avez besoin de la prise en charge de divers systèmes, notamment des systèmes middleware et des systèmes conteneurisés.
Si votre base de données peut automatiquement évoluer, effectuer une reprise après sinistre, changer et est livrée avec sa propre solution multi-nœuds, Docker est une meilleure solution.
Mais sinon, n’utilisez pas Docker.
Le texte original est également très clair :
Lorsque le trafic est faible, tout peut être conteneurisé. Base de données, application, hadoop, divers nœuds, nginx.
Lorsque le volume est important, les services liés au stockage ne sont pas adaptés à la conteneurisation. Les services sans état tels que la couche application et la couche métier conviennent à la conteneurisation. Les services gourmands en mémoire tels que la mise en cache peuvent être conteneurisés.
Pour faire simple, il y a trois problèmes : la reprise après sinistre, les performances et la cohérence des données.
En ce qui concerne les bases de données traditionnelles comme MySQL, il y a tellement de problèmes que je peux énumérer :
Comment conteneuriser MySQL ?
Que dois-je faire si la base de données principale mysqld s'agenouille ?
Que dois-je faire si le dockerd de la bibliothèque principale s'agenouille ?
Que dois-je faire si l'esclave mysqld s'agenouille ?
Que dois-je faire si le docker esclave s'agenouille ?
Mysql peut-il être rapidement étendu via des conteneurs lorsque le pic approche ? plan?
Solution de commutation maître-esclave de données ? Comment assurer la cohérence ?
Le volume pendant les périodes de pointe est suffisamment important, et parfois la capacité d'une machine physique n'est suffisante que pour un seul processus MySQL.
Donc c'est aussi une seule machine, pourquoi mysql ne peut-il pas être démarré directement ?
Pourquoi devons-nous mettre un conteneur à l'extérieur ? Quelle est la perte de performance ?
Comment mettre à jour MySQL ?
Le volume de données perdra-t-il des données ? (J'ai rencontré plusieurs fois des conteneurs endommagés...)
Mais MySQL n'est pas complètement incontenable.
Les entreprises qui ne sont pas sensibles à la perte de données (comme les produits trouvés par la recherche JD.com) peuvent être numérisées et utiliser le partage de base de données pour augmenter le débit en augmentant le nombre d'instances.
En ce qui concerne les problèmes mentionnés dans l'article original, certaines choses ont des défauts, mais elles sont bien pensées. Par exemple, la question suivante est très problématique (à propos des répertoires de données partagés) :
En ce qui concerne les bases de données avec lesquelles j'ai été en contact jusqu'à présent, seules les bases de données telles que cassandra (il existe également tidb et cockroachdb, mais je n'ai pas encore rencontré de cas d'utilisation dans les grandes entreprises) sont adaptées à la conteneurisation.
Mais Cassandra elle-même est également sur le point d'être apatride : elle fournit ses propres solutions de reprise après sinistre, d'extension de capacité et de commutation.
Ce qui suit est une mention de JD.com.
JD.com est une valeur aberrante, mais JD.com a également mentionné des problèmes similaires et des éléments qui nécessitent une attention particulière.
Même de nombreuses personnalisations ont été apportées à Docker.
Vous pouvez consulter le partage JD.com.
Pas adapté, pas incapable
S'il n'y a aucun problème avec une seule machine, cela est toujours bénéfique dans certains cas. Par exemple, lorsque la base de données Oracle de mon entreprise ajustait les paramètres auparavant, la base de données s'est écrasée et n'a pas pu être démarrée. Heureusement, j'utilisais Docker. cette fois-là, je l'ai donc exécuté directement. Pointez simplement le répertoire de données vers celui d'origine
.Peu importe la façon dont vous créez un cluster, il n'est pas facile de le configurer manuellement à l'aide de docker ou d'outils comme swarm. Il est préférable de le construire directement sur une machine physique pour éviter les ennuis
.Il existe une entreprise à l'étranger spécialisée dans les solutions de stockage de données pour les dockers, par exemple, flocker et rancher's convoy
.Docker est plus adapté aux apatrides et ne changera pas le service.
S'il y a un grand nombre de clusters :
Écrivez le fichier docker. Ensuite, lorsque le code est téléchargé dans l'entrepôt de code, après avoir déployé le fichier docker, laissez le script de publication créer le service docker par lots et y insérer le code du service.
Non seulement MySQL, mais similaire à Redis et mc ne sont pas adaptés à l'installation dans Docker. En d'autres termes, mettre la base de données dans Docker est juste pour le plaisir d'utiliser Docker, et il n'y a pas beaucoup d'avantages.
Oui, car les caractéristiques de Docker déterminent qu'il n'est pas adapté au stockage de données. Non seulement les bases de données, mais également tous les services liés au stockage ne sont pas adaptés à l'utilisation de Docker.
Je n'arrive même pas à comprendre dans quel répertoire l'image mysql officielle stocke les données.