{"id":55467,"date":"2020-01-21T00:00:00","date_gmt":"2020-01-20T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya"},"modified":"2020-02-18T14:03:35","modified_gmt":"2020-02-18T11:03:35","slug":"postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/postgres-vtornik-5-postgresql-i-kubernetes-ci-cd-avtomatizatsiya-testirovaniya","title":{"rendered":"Mardi Postgres n\u00b05 : \u00ab PostgreSQL et Kubernetes. CI\/CD. Automatisation des tests \u00bb","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mardi
\n
\n\u00c0 la fin de l'ann\u00e9e derni\u00e8re, un autre direct de la communaut\u00e9 PostgreSQL russe a eu lieu #RuPostgres<\/a><\/noindex>, au cours duquel son cofondateur, Nikolai Samokhvalov, a discut\u00e9 avec le directeur technique de \u00ab Flanta \u00bb, Dmitri Stolyarov, de cette SGBD dans le contexte de Kubernetes.<\/p>\n

Nous publions le compte rendu de la partie principale de cette discussion, et sur la cha\u00eene YouTube de la communaut\u00e9<\/a><\/noindex> la vid\u00e9o compl\u00e8te a \u00e9t\u00e9 publi\u00e9e :<\/a><\/noindex><\/p>\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Bases de donn\u00e9es et Kubernetes<\/h2>\n

\nNS<\/b>: Nous ne allons pas parler aujourd'hui de VACUUM et de CHECKPOINT. Nous voulons discuter de Kubernetes. Je sais que tu as d\u00e9j\u00e0 beaucoup d'exp\u00e9rience. J'ai regard\u00e9 tes vid\u00e9os, et j'en ai m\u00eame revu certains morceaux... Allons droit au but : pourquoi utiliser Postgres ou MySQL dans K8s ?<\/i><\/p>\n

DS<\/b>: Il n'y a pas de r\u00e9ponse unique \u00e0 cette question, et il n'y en aura jamais. Mais en gros, il s'agit de simplicit\u00e9 et de commodit\u00e9... potentielles. Tout le monde souhaite des services g\u00e9r\u00e9s.<\/p>\n

NS<\/b>: Pour avoir RDS<\/a><\/noindex>, uniquement chez soi ?<\/i><\/p>\n

DS<\/b>: Oui : pour avoir RDS, mais o\u00f9 que ce soit.<\/p>\n

NS<\/b>: \u00ab O\u00f9 que ce soit \u00bb \u2014 c'est un bon point. Dans les grandes entreprises, tout est situ\u00e9 \u00e0 diff\u00e9rents endroits. Et pourquoi, si c'est une grande entreprise, ne pas prendre une solution pr\u00eate \u00e0 l'emploi ? Par exemple, Nutanix a ses propres d\u00e9veloppements, d'autres entreprises (VMware\u2026) proposent le m\u00eame \u00ab RDS, mais chez soi \u00bb.<\/i><\/p>\n

DS<\/b>: Mais cela concerne une mise en \u0153uvre sp\u00e9cifique, qui ne fonctionnera que dans certaines conditions. Et quand il s'agit de Kubernetes, il y a une \u00e9norme diversit\u00e9 d'infrastructures (qui peuvent \u00eatre dans K8s). En essence, c'est une norme pour l'API du cloud...<\/p>\n

NS<\/b>: Et c'est m\u00eame gratuit !<\/i><\/p>\n

DS<\/b>: Ce n'est pas si important. La gratuit\u00e9 est importante pour un segment de march\u00e9 qui n'est pas si grand. Ce qui est essentiel, c'est autre chose... Tu te souviens probablement de la pr\u00e9sentation \u00abBases de donn\u00e9es et Kubernetes<\/a><\/noindex>\u00bb?<\/p>\n

NS<\/b>: Oui.<\/i><\/p>\n

DS<\/b>: J'ai compris qu'il a \u00e9t\u00e9 re\u00e7u de mani\u00e8re tr\u00e8s ambigu\u00eb. Certaines personnes ont pens\u00e9 que je disais : \u00ab Allez-y, utilisons toutes les bases de donn\u00e9es dans Kubernetes ! \u00bb, tandis que d'autres ont d\u00e9cid\u00e9 que c'\u00e9tait juste des bicyclettes horribles. Ce que je voulais vraiment dire : \u00ab Regardez ce qui se passe, quels probl\u00e8mes existent et comment les r\u00e9soudre. Est-ce que l'on doit faire fonctionner des bases de donn\u00e9es en Kubernetes actuellement ? En production ? Eh bien, seulement si vous aimez... faire certaines choses. Mais pour le dev, je peux dire que je recommande. Pour le dev, la dynamique de cr\u00e9ation\/d'\u00e9limination des environnements est tr\u00e8s importante. \u00bb<\/p>\n

NS : Par dev, tu entends tous les environnements qui ne sont pas en prod ? Staging, QA...<\/i><\/p>\n

DS<\/b>: Si l'on parle des perf-stands, il n'y en a probablement plus, car les exigences sont sp\u00e9cifiques. Si l'on parle de cas particuliers o\u00f9 une tr\u00e8s grande base de donn\u00e9es est n\u00e9cessaire en staging, c'est aussi probablement non\u2026 Si c'est un environnement statique, de longue dur\u00e9e, quel est l'avantage d'avoir la base dans K8s ?<\/p>\n

NS<\/b>: Aucun. Mais o\u00f9 voyons-nous des environnements statiques ? L'environnement statique est d\u00e9j\u00e0 obsol\u00e8te.<\/i><\/p>\n

DS<\/b>: Le staging peut \u00eatre statique. Nous avons des clients\u2026<\/p>\n

NS<\/b>: Oui, j'en ai aussi. C'est un gros probl\u00e8me si vous avez une base de 10 To et que le staging n'est que de 200 Go\u2026<\/i><\/p>\n

DS<\/b>: J'ai un cas tr\u00e8s int\u00e9ressant ! Sur le staging se trouve une base de donn\u00e9es de prod, sur laquelle des modifications sont apport\u00e9es. Et il y a un bouton : \u00ab d\u00e9ployer en production \u00bb. Ces changements \u2014 les deltas \u2014 sont synchronis\u00e9s (je crois, simplement par API) dans la production. C'est une option tr\u00e8s exotique.<\/p>\n

NS<\/b>: J'ai vu des startups dans la vall\u00e9e qui sont encore sur RDS ou m\u00eame sur Heroku \u2014 c'est des histoires de 2-3 ans \u2014 et elles t\u00e9l\u00e9chargent le dump sur leur laptop. Parce que la base ne fait pour le moment que 80 Go, et il y a de la place sur le laptop. Puis elles ach\u00e8tent des disques pour chacun, afin d'avoir 3 bases pour mener diff\u00e9rents d\u00e9veloppements. \u00c7a arrive aussi. J'ai aussi vu que certaines n'ont pas peur de copier la prod vers staging \u2014 cela d\u00e9pend beaucoup de l'entreprise. Mais j'ai aussi vu qu'ils ont tr\u00e8s peur, et qu'ils manquent souvent de temps et de main-d'\u0153uvre. Mais avant de passer \u00e0 ce sujet, j'aimerais entendre parler de Kubernetes. Je comprends bien qu'en prod, ce n'est pas encore le cas pour qui que ce soit ?<\/i><\/p>\n

DS<\/b>: Nous avons de petites bases en prod. Cela concerne des volumes de dizaines de gigaoctets et des services non critiques, pour lesquels il n'\u00e9tait pas justifi\u00e9 de faire des r\u00e9pliques (et il n'y a pas une telle n\u00e9cessit\u00e9). Et \u00e0 condition que sous Kubernetes, il y ait un stockage correct. Cette base fonctionnait sur une machine virtuelle \u2014 disons sous VMware, sur un stockage SAN. Nous l'avons mise dans PV<\/a><\/noindex> et maintenant nous pouvons la transf\u00e9rer d'une machine \u00e0 l'autre.<\/p>\n

NS<\/b>: Des bases de cette taille, jusqu'\u00e0 100 Go, sur de bons disques et avec un bon r\u00e9seau, peuvent \u00eatre install\u00e9es en quelques minutes, n'est-ce pas ? Une vitesse de 1 Go par seconde, ce n'est plus une exotique.<\/i><\/p>\n

DS<\/b>: Oui, pour une op\u00e9ration lin\u00e9aire, ce n'est pas un probl\u00e8me.<\/p>\n

NS<\/b>: D'accord, pour la prod, nous devons seulement r\u00e9fl\u00e9chir. Et si nous envisageons Kubernetes pour des environnements non-prod \u2014 comment faire ? Je vois que chez Zalando ils cr\u00e9ent un op\u00e9rateur<\/a><\/noindex>, chez Crunchy ils d\u00e9veloppent<\/a><\/noindex>, il y a encore d'autres options. Et il y a OnGres<\/a><\/noindex> \u2014 c'est notre bon ami Alvaro d'Espagne : ils font en fait pas seulement un op\u00e9rateur<\/a><\/noindex>, mais une distribution enti\u00e8re (StackGres<\/a><\/noindex>), dans lequel en plus du Postgres lui-m\u00eame, nous avons \u00e9galement d\u00e9cid\u00e9 d'inclure une sauvegarde, un proxy Envoy...<\/i><\/p>\n

DS<\/b>: \u00c0 quoi sert Envoy ? Pour l'\u00e9quilibrage de la charge du trafic Postgres ?<\/p>\n

NS<\/b>: Oui. Donc, ils le voient comme : si l'on prend une distribution Linux et le noyau, alors PostgreSQL classique est le noyau, et ils veulent cr\u00e9er une distribution qui sera conviviale pour le cloud et fonctionnera sur Kubernetes. Ils assemblent des composants (backups, etc.) et les peaufinent pour qu'ils fonctionnent bien.<\/i><\/p>\n

DS<\/b>: C'est vraiment g\u00e9nial ! En gros, c'est un logiciel pour cr\u00e9er son propre Postgres g\u00e9r\u00e9.<\/p>\n

NS<\/b>: Les distributions Linux ont toujours des probl\u00e8mes : comment faire des pilotes pour que tout le mat\u00e9riel soit support\u00e9. Leur id\u00e9e est qu'ils vont fonctionner sur Kubernetes. Je sais que dans l'op\u00e9rateur Zalando, nous avons r\u00e9cemment vu une connexion \u00e0 AWS, et ce n'est pas tr\u00e8s bien. Il ne devrait pas y avoir de lien avec une infrastructure sp\u00e9cifique - quel est alors le sens ?<\/i><\/p>\n

DS<\/b>: Je ne sais pas dans quelle situation Zalando est li\u00e9, mais dans Kubernetes, le stockage est fait de telle mani\u00e8re qu'il n'est pas possible de faire un backup de disque de mani\u00e8re g\u00e9n\u00e9rique. R\u00e9cemment, dans la norme - dans la derni\u00e8re version de la sp\u00e9cification CSI<\/a><\/noindex> \u2014 la possibilit\u00e9 de snapshots a \u00e9t\u00e9 ajout\u00e9e, mais o\u00f9 est-elle impl\u00e9ment\u00e9e ? Honn\u00eatement, c'est encore tellement embryonnaire\u2026 Nous essayons CSI sur AWS, GCE, Azure, vSphere, mais d\u00e8s que l'on commence \u00e0 l'utiliser, on voit que ce n'est pas encore pr\u00eat.<\/p>\n

NS<\/b>: C'est pourquoi il faut parfois s'appuyer sur l'infrastructure. Je pense que cela reste une phase pr\u00e9coce - des probl\u00e8mes de croissance. Question : quels conseils donnerais-tu aux d\u00e9butants qui veulent essayer PgSQL dans K8s ? Quel op\u00e9rateur peut-\u00eatre ?<\/i><\/p>\n

DS<\/b>: Le probl\u00e8me, c'est que pour nous, Postgres ne repr\u00e9sente que 3 %. Nous avons une tr\u00e8s grande liste de diff\u00e9rents logiciels sur Kubernetes, je ne vais m\u00eame pas tous les \u00e9num\u00e9rer. Par exemple, Elasticsearch. Il y a une multitude d'op\u00e9rateurs : certains se d\u00e9veloppent activement, d'autres non. Nous avons \u00e9tabli nos propres exigences sur ce qui doit \u00eatre dans un op\u00e9rateur pour que nous le prenions au s\u00e9rieux. Un op\u00e9rateur sp\u00e9cifiquement pour Kubernetes \u2014 et non un \u00ab op\u00e9rateur pour faire quelque chose dans les conditions d'Amazon \u00bb\u2026 En fait, nous utilisons assez massivement (= presque tous les clients) un seul op\u00e9rateur \u2014 pour Redis<\/a><\/noindex> (nous publierons bient\u00f4t un article \u00e0 ce sujet)<\/i>.<\/p>\n

NS<\/b>: Et pour MySQL, il n'y en a pas non plus ? Je sais que Percona\u2026 \u00e9tant donn\u00e9 qu'ils s'occupent d\u00e9sormais aussi de MySQL, MongoDB et Postgres, ils devront en cr\u00e9er un universel : pour toutes les bases, pour tous les fournisseurs cloud.<\/i><\/p>\n

DS<\/b>: Nous n'avons pas eu le temps de nous pencher sur les op\u00e9rateurs pour MySQL. Ce n'est pas notre priorit\u00e9 actuelle. MySQL fonctionne bien en mode autonome. Pourquoi un op\u00e9rateur, si tu peux simplement lancer la base de donn\u00e9es\u2026 Tu peux lancer un conteneur Docker avec Postgres, ou le lancer simplement.<\/p>\n

NS<\/b>: C'\u00e9tait aussi une question. En fait, sans op\u00e9rateur ?<\/i><\/p>\n

DS<\/b>: Oui, \u00e0 100% nous avons PostgreSQL fonctionnant sans op\u00e9rateur. Pour l'instant, c'est comme \u00e7a. Nous utilisons activement un op\u00e9rateur pour Prometheus et pour Redis. Nous pr\u00e9voyons de trouver un op\u00e9rateur pour Elasticsearch \u2014 c'est le plus urgent, car nous souhaitons l'installer dans 100% des cas sous Kubernetes. De m\u00eame, nous voulons arriver \u00e0 installer MongoDB aussi syst\u00e9matiquement sous Kubernetes. Il y a certaines attentes \u2014 on a l'impression qu'il y a des choses \u00e0 r\u00e9aliser dans ces cas. Quant \u00e0 Postgres, nous ne nous sommes m\u00eame pas pench\u00e9s dessus. Bien s\u00fbr, nous savons qu'il existe diff\u00e9rentes options, mais en fait, nous fonctionnons en autonome.<\/p>\n

Base de donn\u00e9es pour les tests dans Kubernetes<\/h2>\n

\nNS<\/b>: Passons au sujet des tests. Comment d\u00e9ployer les modifications dans la base \u2014 du point de vue DevOps. Il y a des microservices, beaucoup de bases, et il y a tout le temps des changements. Comment assurer un CI\/CD normal, pour que du point de vue SGBD tout soit en ordre. Quelle est ton approche ?<\/i><\/p>\n

DS<\/b>: Il ne peut pas y avoir une seule r\u00e9ponse. Il y a plusieurs param\u00e8tres. Le premier \u2014 c'est la taille de la base que nous souhaitons d\u00e9ployer. Tu as toi-m\u00eame mentionn\u00e9 que les entreprises ont des attitudes diff\u00e9rentes vis-\u00e0-vis de la n\u00e9cessit\u00e9 d'avoir une copie de la base de prod sur dev et stage.<\/p>\n

NS<\/b>: Et dans le cadre du RGPD, je pense qu'ils y font de plus en plus attention\u2026 Je peux dire qu'en Europe, ils ont d\u00e9j\u00e0 commenc\u00e9 \u00e0 infliger des amendes.<\/i><\/p>\n

DS<\/b>: Mais souvent, il est possible d'\u00e9crire un logiciel qui r\u00e9alise un dump \u00e0 partir de la production et qui l'obscurcit. On obtient des donn\u00e9es de production (instantan\u00e9, dump, copie binaire\u2026), mais elles sont anonymis\u00e9es. \u00c0 la place, il peut aussi y avoir des scripts de g\u00e9n\u00e9ration : cela peut \u00eatre des fixtures ou simplement un script qui g\u00e9n\u00e8re une grande base. Le probl\u00e8me, c'est combien de temps faut-il pour cr\u00e9er l'image de base ? Et combien de temps pour la d\u00e9ployer dans l'environnement requis ?<\/p>\n

Nous sommes arriv\u00e9s \u00e0 un sch\u00e9ma : si le client a un ensemble de donn\u00e9es de fixtures (version minimale de la base), nous les utilisons par d\u00e9faut. Si nous parlons d'environnements de revue, lorsqu'on a cr\u00e9\u00e9 une branche, un exemplaire de l'application a \u00e9t\u00e9 d\u00e9ploy\u00e9 \u2014 nous y d\u00e9ployons une petite base. Mais cela a bien fonctionn\u00e9 et une variante<\/a><\/noindex>, lorsque nous prenons un dump de la production une fois par jour (la nuit) et que nous construisons un conteneur Docker avec PostgreSQL et MySQL avec ces donn\u00e9es charg\u00e9es. Si nous devons d\u00e9ployer la base 50 fois \u00e0 partir de cette image, cela se fait de mani\u00e8re assez simple et rapide.<\/p>\n

NS<\/b>: Par simple copie ?<\/i><\/p>\n

DS<\/b>: Les donn\u00e9es sont directement stock\u00e9es dans l'image Docker. C'est-\u00e0-dire que nous avons une image pr\u00eate, disons de 100 Go. Gr\u00e2ce aux couches dans Docker, nous pouvons d\u00e9ployer cette image le nombre de fois n\u00e9cessaire, rapidement. C'est une m\u00e9thode basique, mais qui fonctionne bien.<\/p>\n

NS<\/b>: Ensuite, quand vous testez, cela change directement \u00e0 l'int\u00e9rieur du Docker, n'est-ce pas ? Le copy-on-write \u00e0 l'int\u00e9rieur du Docker \u2014 on le supprime et on recommence, tout va bien. Super ! Et vous l'utilisez d\u00e9j\u00e0 \u00e0 plein temps ?<\/i><\/p>\n

DS<\/b>: Depuis longtemps.<\/p>\n

NS<\/b>: Nous faisons des choses tr\u00e8s similaires. Sauf que nous n'utilisons pas le copy-on-write de Docker, mais quelque chose d'autre.<\/i><\/p>\n

DS<\/b>: Ce n'est pas g\u00e9n\u00e9rique. Le syst\u00e8me de Docker fonctionne partout.<\/p>\n

NS<\/b>: En th\u00e9orie, oui. Mais nous avons aussi des modules, il est possible de cr\u00e9er diff\u00e9rents modules et de travailler avec diff\u00e9rents syst\u00e8mes de fichiers. Voici le point. Nous regardons tout cela sous un autre angle du c\u00f4t\u00e9 de Postgres. Maintenant, j'ai observ\u00e9 du c\u00f4t\u00e9 de Docker et j'ai vu que tout fonctionnait. Mais si la base est \u00e9norme, par exemple, 1 To, cela devient long : tant pour les op\u00e9rations de nuit, que pour tout faire entrer dans Docker\u2026 Et si l'on doit entrer 5 To dans Docker\u2026 Ou tout se passe bien ?<\/i><\/p>\n

DS<\/b>: Quelle est la diff\u00e9rence ? Ce ne sont que des blobs, juste des bits et des octets.<\/p>\n

NS<\/b>: La diff\u00e9rence est : vous le faites via dump et restore ?<\/i><\/p>\n

DS<\/b>: Ce n'est pas du tout n\u00e9cessaire. Les m\u00e9thodes de g\u00e9n\u00e9ration de cette image peuvent \u00eatre vari\u00e9es.<\/p>\n

NS<\/b>: Pour certains clients, nous avons fait en sorte que, plut\u00f4t que de g\u00e9n\u00e9rer r\u00e9guli\u00e8rement une image de base, nous la maintenions constamment \u00e0 jour. Elle est en fait une r\u00e9plique, mais elle ne re\u00e7oit pas les donn\u00e9es directement du ma\u00eetre, mais par le biais d'une archive. Une archive binaire o\u00f9 les WAL sont appliqu\u00e9s chaque jour, et o\u00f9 les backups sont \u00e9galement effectu\u00e9s\u2026 Ces WAL finissent ensuite par arriver \u2014 avec un l\u00e9ger retard (\u00e0 peine 1-2 secondes) \u2014 jusqu'\u00e0 l'image de base. \u00c0 partir de celle-ci, nous clonons de toutes les mani\u00e8res possibles \u2014 en ce moment, par d\u00e9faut, nous utilisons ZFS.<\/i><\/p>\n

DS<\/b>: Mais avec ZFS, vous \u00eates limit\u00e9 \u00e0 un seul n\u0153ud.<\/p>\n

NS<\/b>: Oui. Mais ZFS a aussi un aspect magique send<\/a><\/noindex>: avec lequel vous pouvez envoyer un snapshot et m\u00eame (je ne l'ai pas encore beaucoup test\u00e9, mais\u2026) vous pouvez envoyer la delta entre deux PGDATA<\/code>. En r\u00e9alit\u00e9, nous avons aussi un autre outil que nous n'avons pas vraiment envisag\u00e9 pour ces t\u00e2ches. Postgres a pg_rewind<\/a><\/noindex>, fonctionnant comme un rsync \u00ab intelligent \u00bb, \u00e9vitant beaucoup de ce qui peut ne pas \u00eatre examin\u00e9, car il n'y a certainement rien qui a chang\u00e9. Nous pouvons r\u00e9aliser une synchronisation rapide entre deux serveurs et revenir en arri\u00e8re de la m\u00eame mani\u00e8re.<\/i><\/p>\n

Nous essayons donc de cr\u00e9er un outil de ce c\u00f4t\u00e9, plus orient\u00e9 DBA, qui permet de faire la m\u00eame chose que tu as mentionn\u00e9 : nous avons une base, mais nous voulons tester quelque chose 50 fois, presque simultan\u00e9ment.<\/i><\/p>\n

DS<\/b>: 50 fois signifie que vous devez commander 50 instances Spot.<\/p>\n

NS<\/b>: Non, tout se fait sur une seule machine.<\/i><\/p>\n

DS<\/b>: Mais comment allez-vous d\u00e9ployer 50 fois, si cette base unique, disons, fait un t\u00e9raoctet. Elle a probablement besoin de, disons, 256 Go de RAM ?<\/p>\n

NS<\/b>: Oui, parfois il faut beaucoup de m\u00e9moire \u2014 c'est normal. Mais un exemple de la vie r\u00e9elle. Sur la machine de production, il y a 96 c\u0153urs et 600 Go. Alors que pour la base de donn\u00e9es, 32 c\u0153urs sont utilis\u00e9s (voire parfois 16 c\u0153urs maintenant) et 100-120 Go de m\u00e9moire.<\/i><\/p>\n

DS<\/b>: Et vous y mettez 50 copies ?<\/p>\n

NS<\/b>: Donc, il n'y a qu'une seule copie, ensuite cela fonctionne en copy-on-write (ZFS)\u2026 Je vais expliquer plus en d\u00e9tail.<\/i><\/p>\n

Par exemple, nous avons une base de 10 To. Nous avons cr\u00e9\u00e9 un disque pour elle, ZFS a d\u00e9j\u00e0 compress\u00e9 sa taille de 30-40 %. Puisque nous ne faisons pas de tests de charge, le temps de r\u00e9ponse exact n'est pas important pour nous : il peut \u00eatre jusqu'\u00e0 2 fois plus lent \u2014 c'est acceptable.<\/i><\/p>\n

Nous offrons aux d\u00e9veloppeurs, QA, DBA, etc. la possibilit\u00e9 d'effectuer des tests en 1-2 flux. Par exemple, ils peuvent lancer une migration. Cela ne n\u00e9cessite pas imm\u00e9diatement 10 c\u0153urs \u2014 il lui faut 1 backend Postgres, 1 c\u0153ur. La migration va d\u00e9marrer \u2014 peut-\u00eatre, l'autovacuum<\/a><\/noindex> va d\u00e9marrer aussi, alors le deuxi\u00e8me c\u0153ur sera utilis\u00e9. Nous avons allou\u00e9 16-32 c\u0153urs, donc 10 personnes peuvent travailler en m\u00eame temps, il n'y a pas de probl\u00e8me.<\/i><\/p>\n

Puisque physiquement PGDATA<\/code> il s'av\u00e8re que nous trompons en fait Postgres. L'id\u00e9e est la suivante : par exemple, 10 Postgres sont lanc\u00e9s simultan\u00e9ment. Quel est g\u00e9n\u00e9ralement le probl\u00e8me ? On les met tous en place. shared_buffers<\/a><\/noindex>, disons, \u00e0 25 %. En cons\u00e9quence, cela repr\u00e9sente 200 Go. Plus de trois de tels syst\u00e8mes ne peuvent plus \u00eatre lanc\u00e9s, car la m\u00e9moire va manquer.<\/i><\/p>\n

Mais \u00e0 un moment donn\u00e9, nous avons compris que ce n'\u00e9tait pas n\u00e9cessaire : nous configurons shared_buffers \u00e0 2 Go. PostgreSQL a effective_cache_size<\/a><\/noindex>, et en r\u00e9alit\u00e9, c'est le seul qui influence les plans<\/a><\/noindex>. Nous le r\u00e9glons \u00e0 0,5 To. Et il n'est m\u00eame pas important qu'il n'y en ait pas r\u00e9ellement : il construit des plans comme s'il y en avait.<\/i><\/p>\n

Ainsi, lorsque nous testons une migration, nous pouvons rassembler tous les plans \u2014 nous verrons comment cela se d\u00e9roulera en production. Les secondes seront diff\u00e9rentes (plus lentes), mais les donn\u00e9es que nous lisons r\u00e9ellement et les plans eux-m\u00eames (quels sont les JOIN et autres) sont exactement les m\u00eames que ceux en production. Et il est possible d'ex\u00e9cuter de nombreux contr\u00f4les de ce type sur une seule machine.<\/i><\/p>\n

DS<\/b>: Ne penses-tu pas qu'il y a plusieurs probl\u00e8mes ici ? Le premier \u2014 c'est une solution qui ne fonctionne que sur PostgreSQL. Cette approche est tr\u00e8s sp\u00e9cifique, elle n'est pas g\u00e9n\u00e9rique. Le deuxi\u00e8me \u2014 Kubernetes (et tout ce vers quoi vont les technologies cloud) implique de nombreux n\u0153uds, et ces n\u0153uds sont \u00e9ph\u00e9m\u00e8res. Dans ton cas, il s'agit d'un n\u0153ud stateful, persistant. Ces aspects me posent des contradictions.<\/p>\n

NS<\/b>: D'une part, je suis d'accord, c'est purement une histoire de Postgres. Je pense que si nous avons un type d'IO direct et une m\u00e9moire tampon presque pour toute la m\u00e9moire, cette approche ne conviendra pas \u2014 les plans seront diff\u00e9rents. Mais pour l'instant, nous ne travaillons qu'avec Postgres et ne pensons pas aux autres.<\/i><\/p>\n

Concernant Kubernetes. Tu racontes partout que notre base est persistante. Si une instance plante, l'essentiel est de sauvegarder le disque. Notre plateforme repose \u00e9galement sur Kubernetes, tandis que le composant avec Postgres est s\u00e9par\u00e9 (bien qu'il y figure un jour). Donc, c'est comme \u00e7a : l'instance est tomb\u00e9e, mais nous avons conserv\u00e9 son PV et l'avons simplement connect\u00e9 \u00e0 une autre (nouvelle) instance, comme si rien ne s'\u00e9tait pass\u00e9.<\/i><\/p>\n

DS<\/b>: De mon point de vue, nous cr\u00e9ons des pods dans Kubernetes. K8s est \u00e9lastique : les n\u0153uds sont command\u00e9s automatiquement selon les besoins. La t\u00e2che consiste simplement \u00e0 cr\u00e9er un pod et \u00e0 indiquer qu'il a besoin de X ressources, et ensuite K8s se d\u00e9brouillera tout seul. Mais la prise en charge des stockages dans Kubernetes reste encore instable : dans 1.16<\/a><\/noindex>, sur 1.17<\/a><\/noindex> (cette version a \u00e9t\u00e9 publi\u00e9e il y a une semaine<\/i> ) ces fonctionnalit\u00e9s sont encore en b\u00eata.<\/p>\n

Il faudra six mois \u00e0 un an pour que cela devienne plus ou moins stable, ou du moins d\u00e9clar\u00e9 comme tel. Ensuite, la possibilit\u00e9 de snapshots et de redimensionnements r\u00e9soudra compl\u00e8tement votre probl\u00e9matique. Car vous avez une base. Oui, elle peut ne pas \u00eatre tr\u00e8s rapide, mais la vitesse d\u00e9pend de ce qui se cache \u00ab sous le capot \u00bb, car certaines impl\u00e9mentations savent g\u00e9rer la copie et le copy-on-write au niveau du sous-syst\u00e8me de disque.<\/p>\n

NS<\/b>: Il faut aussi que tous les moteurs (Amazon, Google\u2026) commencent \u00e0 prendre en charge cette version \u2014 cela prend aussi un certain temps.<\/i><\/p>\n

DS<\/b>: Pour l'instant, nous ne les utilisons pas. Nous utilisons les n\u00f4tres.<\/p>\n

D\u00e9veloppement local sous Kubernetes<\/h2>\n

\nNS<\/b>: As-tu d\u00e9j\u00e0 rencontr\u00e9 ce besoin lorsque tu dois lancer tous les pods sur une seule machine et faire des tests rapides. Pour obtenir rapidement une preuve de concept et voir que l'application fonctionne dans Kubernetes, sans d\u00e9dier une multitude de machines \u00e0 cela. Il y a Minikube, n'est-ce pas ?<\/i><\/p>\n

DS<\/b>: Je pense que ce cas \u2014 de d\u00e9ployer sur un seul n\u0153ud \u2014 concerne exclusivement le d\u00e9veloppement local. Ou certaines manifestations d'un tel mod\u00e8le. Il y a Minikube<\/a><\/noindex>, il y a k3s<\/a><\/noindex>, KIND<\/a><\/noindex>. Nous allons utiliser Kubernetes IN Docker. Nous avons commenc\u00e9 \u00e0 travailler avec \u00e7a pour des tests.<\/p>\n

NS<\/b>: Je pensais auparavant que c'\u00e9tait une tentative de regrouper tous les pods dans une seule image Docker. Mais il s'av\u00e8re que c'est tout autre chose. De toute fa\u00e7on, il s'agit de conteneurs s\u00e9par\u00e9s, de pods s\u00e9par\u00e9s \u2014 juste dans Docker.<\/i><\/p>\n

DS<\/b>: Oui. Il y a une imitation assez amusante, mais le sens est tel\u2026 Nous avons un utilitaire pour le d\u00e9ploiement \u2014 werf<\/a><\/noindex>. Nous voulons y inclure un mode \u2014 disons werf up<\/code>: \u00abD\u00e9marre-moi un Kubernetes local\u00bb. Et ensuite lancer un werf follow<\/code>. Ainsi, le d\u00e9veloppeur pourra coder dans son IDE, tandis qu'un processus s'ex\u00e9cute dans le syst\u00e8me, qui voit les modifications et reconstruit les images, les red\u00e9ploie dans le K8s local. C'est ainsi que nous voulons essayer de r\u00e9soudre le probl\u00e8me du d\u00e9veloppement local.<\/p>\n

Snapshots et clonage de bases de donn\u00e9es dans le cadre de K8s<\/h2>\n

\nNS<\/b>: Revenons au copy-on-write. J'ai remarqu\u00e9 que les services cloud ont aussi des snapshots. Ils fonctionnent diff\u00e9remment. Par exemple, dans GCP : si tu as une instance de plusieurs t\u00e9raoctets sur la c\u00f4te est des \u00c9tats-Unis. Tu fais p\u00e9riodiquement des snapshots. Tu rel\u00e8ves d'un snapshot une copie du disque sur la c\u00f4te ouest \u2014 en quelques minutes c'est d\u00e9j\u00e0 pr\u00eat, \u00e7a fonctionne tr\u00e8s rapidement, il suffit de remplir le cache en m\u00e9moire. Mais ces clones (snapshots) sont l\u00e0 pour provisionner un nouveau volume. C'est g\u00e9nial quand tu dois cr\u00e9er beaucoup d'instances.<\/i><\/p>\n

Mais pour les tests, il me semble que les snapshots dont tu parles dans Docker ou ceux dont je parle dans ZFS, btrfs et m\u00eame LVM... \u2014 ils permettent justement de ne pas cr\u00e9er r\u00e9ellement de nouvelles donn\u00e9es sur une seule machine. Dans le cloud, tu devras \u00e9galement les payer chaque fois et attendre non pas des secondes, mais des minutes (et dans le cas de lazy load<\/a><\/noindex>, peut-\u00eatre des heures).<\/i><\/p>\n

Au lieu de cela, tu peux obtenir ces donn\u00e9es en une ou deux secondes, faire tourner un test et les jeter. Ces snapshots r\u00e9solvent des t\u00e2ches diff\u00e9rentes. Dans le premier cas \u2014 pour se scaler et obtenir de nouvelles r\u00e9pliques, et dans le second \u2014 pour des tests.<\/i><\/p>\n

DS<\/b>: Je ne suis pas d'accord. R\u00e9aliser correctement le clonage des volumes est une t\u00e2che pour le cloud. Je n'ai pas regard\u00e9 leur impl\u00e9mentation, mais je sais comment nous faisons cela sur le mat\u00e9riel. Nous avons Ceph, on peut dire \u00e0 n'importe quel volume physique (RBD<\/a><\/noindex>) et obtenir en quelques dizaines de millisecondes un second volume avec des caract\u00e9ristiques identiques, clone<\/i> IOPS etc. Il faut comprendre qu'il y a un copy-on-write complexe en interne. Pourquoi le cloud ne pourrait-il pas faire de m\u00eame ? Je suis s\u00fbr qu'ils essaient de le faire d'une mani\u00e8re ou d'une autre.<\/a><\/noindex>'s, etc. Il faut comprendre qu'il y a un astucieux m\u00e9canisme de copy-on-write \u00e0 l'int\u00e9rieur. Pourquoi le cloud ne ferait-il pas de m\u00eame ? Je suis s\u00fbr qu'ils essaient d'une mani\u00e8re ou d'une autre de le faire.<\/p>\n

NS<\/b>: Pourquoi est-il n\u00e9cessaire de d\u00e9marrer une instance compl\u00e8te ? Nous avons une instance avec 32 c\u0153urs, et une autre avec 16... et elle peut contenir un certain nombre de volumes - par exemple, quatre. Lorsque nous commandons une cinqui\u00e8me, une instance sera d\u00e9j\u00e0 lanc\u00e9e, puis elle sera supprim\u00e9e.<\/i><\/p>\n

DS<\/b>: Oui, c'est int\u00e9ressant, dans Kubernetes cela donne une autre histoire. Notre base de donn\u00e9es n'est pas dans K8s, et il y a une instance. Pourtant, le clonage d'une base de donn\u00e9es de plusieurs t\u00e9raoctets prend moins de deux secondes.<\/p>\n

NS<\/b>: C'est g\u00e9nial. Mais mon point de d\u00e9part est que ce n'est pas une solution g\u00e9n\u00e9rique. Oui, c'est super, mais cela convient uniquement \u00e0 Postgres et seulement sur un n\u0153ud.<\/i><\/p>\n

DS<\/b>: Ce n'est pas seulement pour Postgres : les plans, comme je l'ai d\u00e9crit, fonctionneront ainsi uniquement en son sein. Mais si nous ne nous pr\u00e9occupons pas des plans, mais avons simplement besoin de toutes les donn\u00e9es pour des tests fonctionnels, alors cela conviendra \u00e0 n'importe quel SGBD.<\/p>\n

NS<\/b>: Il y a de nombreuses ann\u00e9es, nous avons fait quelque chose de similaire avec des snapshots LVM. C'est classique. Cette approche a \u00e9t\u00e9 utilis\u00e9e tr\u00e8s activement. Les n\u0153uds \u00e9tat-plein sont vraiment un d\u00e9fi. Parce qu'il faut les faire fonctionner sans interruption, toujours se souvenir d'eux...<\/i><\/p>\n

DS<\/b>: Ne vois-tu pas ici une possibilit\u00e9 de hybridation ? Disons qu'un \u00e9tat-plein est un pod, il fonctionne pour plusieurs utilisateurs (beaucoup de testeurs). Nous avons un seul volume, mais gr\u00e2ce au syst\u00e8me de fichiers, les clones sont locaux. Si le pod tombe, le disque reste ; le pod se rel\u00e8vera, l'information sur tous les clones sera lue, tout sera remis en place et il dira : \u00ab Voici vos clones lanc\u00e9s sur ces ports, travaillez avec eux \u00bb.<\/p>\n

NS<\/b>: Techniquement, cela signifie qu'au sein de Kubernetes c'est un pod, \u00e0 l'int\u00e9rieur duquel nous lan\u00e7ons plusieurs Postgres.<\/i><\/p>\n

DS<\/b>: Techniquement, cela signifie qu'au sein de Kubernetes, c'est un pod dans lequel nous lan\u00e7ons plusieurs instances de Postgres.<\/p>\n

NS<\/b>: Oui. Il a une limite : disons que pas plus de 10 personnes peuvent y travailler en m\u00eame temps. Si 20 s'av\u00e8rent n\u00e9cessaires, nous lancerons un second pod identique. Il est tout \u00e0 fait possible de le cloner compl\u00e8tement, obtenant un second volume complet, avec les m\u00eames 10 clones 'minces'. Ne vois-tu pas cette possibilit\u00e9 ?<\/i><\/p>\n

DS<\/b>: Il faut ajouter ici des questions de s\u00e9curit\u00e9. Cette approche implique que ce pod a des privil\u00e8ges \u00e9lev\u00e9s (capabilit\u00e9s), car il peut effectuer des op\u00e9rations non standards sur le syst\u00e8me de fichiers... Mais je le r\u00e9p\u00e8te : je pense qu'\u00e0 moyen terme, Kubernetes corrigera les probl\u00e8mes de stockage, et dans le cloud, toute l'histoire avec les volumes sera r\u00e9solue - tout fonctionnera \u00ab simplement \u00bb. Il y aura redimensionnement, clonage... S'il y a un volume, nous disons : \u00ab Cr\u00e9e un nouveau bas\u00e9 sur celui-ci \u00bb, et en une seconde et demie, nous avons ce dont nous avons besoin.<\/p>\n

NS<\/b>: Je ne crois pas qu\u2019une seconde et demie soit r\u00e9alisable pour de nombreux t\u00e9raoctets. Sur Ceph, tu le fais toi-m\u00eame, mais tu parles des clouds. Va dans le cloud, fais un clone d'un volume EBS de plusieurs t\u00e9raoctets sur EC2 et regarde quelle sera la performance. Cela ne prendra pas quelques secondes. Cela m\u2019int\u00e9resse beaucoup de savoir quand ils atteindront ce r\u00e9sultat. Je comprends de quoi tu parles, mais je me permets de ne pas \u00eatre d'accord.<\/i><\/p>\n

DS<\/b>: D'accord, mais j'ai dit que c'\u00e9tait \u00e0 moyen terme, pas \u00e0 court terme. Dans quelques ann\u00e9es.<\/p>\n

\u00c0 propos de l\u2019op\u00e9rateur PostgreSQL de Zalando<\/h2>\n

\nAu milieu de cette r\u00e9union, Alexey Klyukin, un ancien d\u00e9veloppeur de Zalando, a \u00e9galement rejoint la discussion et a parl\u00e9 de l'histoire de l'op\u00e9rateur PostgreSQL :<\/p>\n

C'est g\u00e9nial que ce sujet soit abord\u00e9 : Postgres et Kubernetes. Quand nous avons commenc\u00e9 \u00e0 le d\u00e9velopper chez Zalando en 2017, c'\u00e9tait un sujet que tout le monde voulait explorer, mais personne ne s'y mettait. Tout le monde avait d\u00e9j\u00e0 Kubernetes, mais quand on demandait comment g\u00e9rer les bases de donn\u00e9es, m\u00eame des gens comme Kelsey Hightower<\/a><\/noindex>, pr\u00f4nant Kubernetes, disaient \u00e0 peu pr\u00e8s ceci :<\/p>\n

\u00ab Allez vers des services g\u00e9r\u00e9s et utilisez-les, ne lancez pas de BD dans Kubernetes. Sinon, votre K8s d\u00e9cidera, par exemple, de faire une mise \u00e0 niveau, \u00e9teindra tous les n\u0153uds et vos donn\u00e9es s'\u00e9chapperont tr\u00e8s loin. \u00bb<\/i><\/p>\n

Nous avons d\u00e9cid\u00e9 de cr\u00e9er un op\u00e9rateur qui, contrairement \u00e0 ce conseil, lancerait la base de donn\u00e9es Postgres dans Kubernetes. Et nous avions de bonnes raisons \u2013 Patroni<\/a><\/noindex>. Il s'agit d'un basculement automatique pour PostgreSQL, effectu\u00e9 correctement, c'est-\u00e0-dire en utilisant etcd, consul ou ZooKeeper comme stockage d'informations sur le cluster. Un tel stockage qui transmettra \u00e0 tous ceux qui demandent, par exemple, qui est le leader actuellement, la m\u00eame information - malgr\u00e9 le fait que tout soit distribu\u00e9 - pour \u00e9viter le split brain. De plus, nous avions Docker image<\/a><\/noindex> pour cela.<\/p>\n

En fait, le besoin d'un basculement automatique est apparu pour l'entreprise apr\u00e8s la migration d'un centre de donn\u00e9es physique interne vers le cloud. Le cloud \u00e9tait bas\u00e9 sur une solution PaaS (Platform-as-a-Service) propri\u00e9taire. Il \u00e9tait Open Source, mais pour le mettre en place, il fallait beaucoup travailler. Cela s'appelait STUPS<\/a><\/noindex>.<\/p>\n

Au d\u00e9but, il n'y avait pas de Kubernetes. Plus pr\u00e9cis\u00e9ment, lorsque notre solution \u00e9tait mise en \u0153uvre, K8s existait d\u00e9j\u00e0, mais \u00e9tait encore tellement immature qu'il n'\u00e9tait pas adapt\u00e9 \u00e0 la production. C'\u00e9tait, je pense, en 2015 ou 2016. D'ici 2017, Kubernetes \u00e9tait devenu relativement mature - le besoin de migration vers celui-ci est apparu.<\/p>\n

Et nous avions d\u00e9j\u00e0 un conteneur Docker. Il y avait une PaaS qui utilisait Docker. Pourquoi ne pas essayer K8s ? Pourquoi ne pas \u00e9crire notre propre op\u00e9rateur ? Murat Kabilov, qui est venu nous rejoindre depuis Avito, a commenc\u00e9 cela par ses propres initiatives - \u00ab juste pour jouer \u00bb, - et le projet a \u00ab d\u00e9coll\u00e9 \u00bb.<\/p>\n

Mais en fait, je voulais parler d'AWS. Pourquoi il y avait historiquement du code li\u00e9 \u00e0 AWS\u2026<\/p>\n

Lorsque vous lancez quoi que ce soit dans Kubernetes, il faut comprendre que K8s est un travail en cours. Il \u00e9volue constamment, s'am\u00e9liore et, parfois, m\u00eame se casse. Il faut suivre de pr\u00e8s tous les changements dans Kubernetes, \u00eatre pr\u00eat \u00e0 plonger dedans et \u00e0 comprendre comment cela fonctionne en d\u00e9tail \u2014 peut-\u00eatre plus que vous ne le souhaiteriez. C'est en principe le cas pour toute plateforme sur laquelle vous ex\u00e9cutez vos bases de donn\u00e9es\u2026<\/p>\n

Alors, lorsque nous avons cr\u00e9\u00e9 l'op\u00e9rateur, nous avions Postgres qui fonctionnait avec un volume externe (dans ce cas, EBS, puisque nous travaillions dans AWS). La base de donn\u00e9es a grandi, et \u00e0 un moment donn\u00e9, il a fallu faire un redimensionnement : par exemple, la taille initiale de l'EBS \u00e9tait de 100 To, la base a atteint cette taille, maintenant nous voulons faire un EBS de 200 To. Comment ? Supposons que l'on puisse faire un dump\/restauration sur une nouvelle instance, mais c'est long et entra\u00eene un temps d'arr\u00eat.<\/p>\n

C'est pourquoi nous voulions un redimensionnement qui allait augmenter la partition EBS et ensuite dire au syst\u00e8me de fichiers d'utiliser le nouvel espace. Et nous l'avons fait, mais \u00e0 l'\u00e9poque, Kubernetes n'avait aucune API pour l'op\u00e9ration de redimensionnement. \u00c9tant donn\u00e9 que nous travaillions sur AWS, nous avons \u00e9crit du code pour son API.<\/p>\n

Personne n'emp\u00eache de faire la m\u00eame chose pour d'autres plateformes. L'op\u00e9rateur n'est pas limit\u00e9 \u00e0 \u00eatre ex\u00e9cut\u00e9 uniquement sur AWS, il fonctionnera ailleurs \u00e9galement. En gros, c'est un projet Open Source : si quelqu'un veut acc\u00e9l\u00e9rer l'apparition de l'utilisation d'une nouvelle API \u2014 vous \u00eates le bienvenu. Il y a GitHub<\/a><\/noindex>, les pull requests \u2014 l'\u00e9quipe de Zalando s'efforce d'y r\u00e9pondre assez rapidement et de promouvoir l'op\u00e9rateur. D'apr\u00e8s ce que je sais, le projet a particip\u00e9<\/a><\/noindex> au Google Summer of Code et \u00e0 d'autres initiatives similaires. Zalando travaille tr\u00e8s activement dessus.\n<\/p><\/blockquote>\n

<\/p>\n

P.S. Bonus !<\/h2>\n

\nSi vous \u00eates int\u00e9ress\u00e9 par le sujet de PostgreSQL et Kubernetes, nous attirons \u00e9galement votre attention sur le fait que la semaine derni\u00e8re a eu lieu le prochain Postgres Tuesday, o\u00f9 Nikolai a \u00e9chang\u00e9 avec Alexandre Kukushkin de Zalando<\/b>. La vid\u00e9o est disponible ici<\/a><\/noindex>.<\/p>\n

P.P.S.<\/h2>\n

\nLisez aussi dans notre blog :<\/p>\n