Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.
Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.
D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.
Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.
La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.
Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.
Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.
Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.
[^] # Re: cloud baremetal
Posté par oau . En réponse au journal Le cloud ça scale bien. Évalué à 2.
Tu as raison. Mais avec k8s c'est plus simple. Je ne ne gère pas l'allocation des noeuds du cluster pg sur les nodes du cluster k8s, ni la création des lv et des fs. Je n'ai pas besoin de savoir quelle instance est où ni sur quel fs etc.
Si k8s à besoin de bouger un noeud de la base sur un autre noeud du cluster k8s c'est possible. Que ce soit pour pg ou n'importe quoi d'autre d'ailleurs.
D'autres part toute la conf de pg est dans un yaml dans ma cicd. Nombre de noeud du cluster pg, user, db, config de la base, la taille des disques, le backup, le streaming des wal dans S3, le type de réplication que je veux pour chaque noeud. Je peux créer une base à partir d'une autre, à un instant t juste avec un yaml. Parfait pour tester une version de dev avec des vraies données.
Bref pour pg, comme pour tout le reste j'ai de l'infrastructure as code. En vrai techniquement ça change rien. Mais en standardisant et en automatisant à outrance on peut gérer énormément de service.
La plupart de nos clients sont des applications en SaaS ou des algorithmes de traitement de données. J'ai une stack redis, dB, front www JS et serveur d'applications backend genre python,ruby ou java. J'injecte l'id du client et le type de plateforme que je veux. Production, staging, dev, une branche en particulier etc. Et je déploy via la cicd.
Que j'ai 10 fois l'application, ou 10 000 fois ça change rien. K8s se débrouille pour tout déployer en fonction des contraintes que je lui donne. Essentiellement de ne pas démarrer deux noeuds de base pg dans la même zone.
Quand c'est des algorithmes de traitement de données je peux avoir 10 algorithmes différents qui tournent en parallèle sur les mêmes données (merci Kafka) et qui remplissent 10 cluster pg différents. Juste en me basant dans ce cas là sur le nom de la branche git. En vrai on fait l'administration pratiquement uniquement avec git. Et c'est la cicd qui gère.
Enfin quand je n'ai plus de place ou plus de ressources sur le cluster, j'ajoute des serveurs.