Configurer et gérer des clusters de bases de données

Ce guide pratique vous montre comment configurer et gérer des clusters de bases de données PostgreSQL dans la plateforme Atlas.

Prérequis

• Avoir un compte sur la plateforme Atlas
• Être administrateur de workspace ou avoir les droits nécessaires
• Avoir un workspace déjà créé
• Avoir au moins un DeploymentTarget créé
• Avoir accès au dépôt GitOps de votre workspace

Types d'implémentations

Atlas propose deux types d'implémentations pour les bases de données PostgreSQL :

1. CNPG (CloudNativePG) : Déploiement dans le cluster Kubernetes, adapté pour les environnements de développement et de test.
2. Managed (OVH) : Cluster de base de données managé, recommandé pour les environnements de production.

Création d'un DatabaseCluster

1. Cloner le dépôt GitOps de votre workspace

1
2

git clone <URL du dépôt de votre workspace>
cd <nom du dépôt>

2. Créer un fichier YAML pour le DatabaseCluster

Créez un nouveau fichier YAML dans le dossier resources du dépôt. Nommez-le de manière significative, par exemple ma-db-dev.yaml.

1
2

mkdir -p resources
touch resources/ma-db-dev.yaml

3. Définir la configuration du DatabaseCluster

Ouvrez le fichier ma-db-dev.yaml dans votre éditeur préféré et ajoutez la configuration appropriée selon le type d'implémentation que vous souhaitez utiliser.

Option 1 : Configuration CNPG (pour développement/test)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

apiVersion: workspace.fabrique.social.gouv.fr/v1alpha1
kind: DatabaseCluster
metadata:
  name: ma-db-dev
spec:
  parameters:
    name: "ma-db-dev"
    implementation: "cnpg"
    version: "15"
    diskSize: 10
    replicas: 1
    cnpg:
      resources:
        limits:
          cpu: "500m"
          memory: "512Mi"
        requests:
          cpu: "100m"
          memory: "256Mi"
    zoneRef:
      name: "dev"
    secretDeliveryTargets:
      - kind: "DeploymentTarget"
        name: "mon-app-dev"

Option 2 : Configuration Managed (pour production)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: workspace.fabrique.social.gouv.fr/v1alpha1
kind: DatabaseCluster
metadata:
  name: ma-db-prod
spec:
  parameters:
    name: "ma-db-prod"
    implementation: "managed"
    version: "15"
    diskSize: 80
    replicas: 3
    ovh:
      plan: "essential"
      flavor: "db1-4"
      authorized_ips: []
    zoneRef:
      name: "prod"
    secretDeliveryTargets:
      - kind: "DeploymentTarget"
        name: "mon-app-prod"

Assurez-vous de remplacer : - ma-db-dev ou ma-db-prod par un nom significatif pour votre base de données - mon-app-dev ou mon-app-prod par le nom de votre DeploymentTarget - dev ou prod par le nom de la zone appropriée

4. Pousser les changements vers le dépôt

1
2
3

git add resources/ma-db-dev.yaml
git commit -m "Ajout du DatabaseCluster pour mon application"
git push

5. Vérifier la création du DatabaseCluster

Une fois les changements poussés, ArgoCD détectera automatiquement les modifications et créera le DatabaseCluster. Vous pouvez vérifier l'état de la création dans ArgoCD.

1. Accédez à ArgoCD via l'interface Atlas
2. Recherchez l'application correspondant à votre workspace
3. Vérifiez que le DatabaseCluster a été créé avec succès

Paramètres de configuration

Paramètres communs

Paramètres spécifiques à CNPG

Paramètres spécifiques à Managed (OVH)

Format et accès aux informations de connexion

Les informations de connexion à la base de données sont automatiquement livrées au DeploymentTarget spécifié dans secretDeliveryTargets. Le secret est livré dans le format JSON suivant :

1
2
3
4
5
6
7
8
9

{
  "url": "postgresql://username:password@host:port/database",
  "server": "host:port",
  "host": "host",
  "port": "port",
  "username": "username",
  "password": "password",
  "database": "database"
}

Vous pouvez accéder à ces informations de deux façons :

Via Vault

1. Accédez à Vault via l'interface Atlas
2. Naviguez vers le chemin correspondant à votre DeploymentTarget
3. Vous y trouverez les informations de connexion à la base de données

Via les secrets Kubernetes

Les informations de connexion sont également disponibles sous forme de secrets Kubernetes dans le namespace de votre DeploymentTarget. Vous pouvez y accéder dans votre application en montant le secret ou en utilisant les variables d'environnement.

Exemple d'utilisation dans un déploiement Kubernetes :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mon-application
spec:
  # ...
  template:
    # ...
    spec:
      containers:
      - name: mon-application
        image: mon-image:latest
        env:
        # Utilisation de l'URL complète
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: url
        # Ou utilisation des paramètres individuels
        - name: DB_HOST
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: host
        - name: DB_PORT
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: port
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: ma-db-dev
              key: database

Exemple d'utilisation avec TypeScript et Sequelize

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

import { Sequelize } from 'sequelize';

// Utilisation directe de l'URL de connexion
const sequelize1 = new Sequelize(process.env.DATABASE_URL as string);

// Ou utilisation des paramètres individuels
const sequelize2 = new Sequelize(
  process.env.DB_NAME as string,
  process.env.DB_USER as string,
  process.env.DB_PASSWORD as string,
  {
    host: process.env.DB_HOST,
    port: parseInt(process.env.DB_PORT || '5432', 10),
    dialect: 'postgres',
    logging: false
  }
);

// Vérification de la connexion
async function testConnection(): Promise<void> {
  try {
    await sequelize1.authenticate();
    console.log('Connexion établie avec succès.');
  } catch (error) {
    console.error('Impossible de se connecter à la base de données:', error);
  }
}

// Définition d'un modèle
import { Model, DataTypes } from 'sequelize';

interface UserAttributes {
  id: number;
  name: string;
  email: string;
  createdAt?: Date;
  updatedAt?: Date;
}

class User extends Model<UserAttributes> implements UserAttributes {
  public id!: number;
  public name!: string;
  public email!: string;
  public readonly createdAt!: Date;
  public readonly updatedAt!: Date;
}

User.init(
  {
    id: {
      type: DataTypes.INTEGER,
      autoIncrement: true,
      primaryKey: true,
    },
    name: {
      type: DataTypes.STRING,
      allowNull: false,
    },
    email: {
      type: DataTypes.STRING,
      allowNull: false,
      unique: true,
    },
  },
  {
    sequelize: sequelize1,
    tableName: 'users',
  }
);

Modification d'un DatabaseCluster

La modification d'un DatabaseCluster se fait en modifiant le fichier YAML correspondant dans le dépôt du workspace. Cependant, certains champs sont immuables et ne peuvent pas être modifiés après la création.

Champs immuables

• spec.parameters.name : Le nom du DatabaseCluster ne peut pas être modifié après la création.
• spec.parameters.implementation : L'implémentation (cnpg ou managed) ne peut pas être modifiée après la création.

1. Cloner le dépôt GitOps de votre workspace (si ce n'est pas déjà fait)

1
2

git clone <URL du dépôt de votre workspace>
cd <nom du dépôt>

2. Modifier le fichier YAML du DatabaseCluster

Ouvrez le fichier resources/ma-db-dev.yaml dans votre éditeur préféré et modifiez la configuration selon vos besoins.

3. Pousser les changements vers le dépôt

1
2
3

git add resources/ma-db-dev.yaml
git commit -m "Modification du DatabaseCluster pour mon application"
git push

4. Vérifier la mise à jour du DatabaseCluster

Une fois les changements poussés, ArgoCD détectera automatiquement les modifications et mettra à jour le DatabaseCluster. Vous pouvez vérifier l'état de la mise à jour dans ArgoCD.

Suppression d'un DatabaseCluster

La suppression d'un DatabaseCluster se fait en supprimant le fichier YAML correspondant du dépôt du workspace.

Attention : La suppression d'un DatabaseCluster entraînera également la suppression de la base de données et de toutes les données qu'elle contient. Assurez-vous de sauvegarder toutes les données importantes avant de supprimer un DatabaseCluster.

1. Cloner le dépôt GitOps de votre workspace (si ce n'est pas déjà fait)

1
2

git clone <URL du dépôt de votre workspace>
cd <nom du dépôt>

2. Supprimer le fichier YAML du DatabaseCluster

1
2
3

git rm resources/ma-db-dev.yaml
git commit -m "Suppression du DatabaseCluster pour mon application"
git push

3. Vérifier la suppression du DatabaseCluster

Une fois les changements poussés, ArgoCD détectera automatiquement les modifications et supprimera le DatabaseCluster. Vous pouvez vérifier l'état de la suppression dans ArgoCD.

Bonnes pratiques

Choix de l'implémentation

• Utilisez l'implémentation cnpg pour les environnements de développement et de test.
• Utilisez l'implémentation managed pour les environnements de production.

Haute disponibilité

• Pour la haute disponibilité en production, définissez replicas à une valeur supérieure à 1.
• Pour les bases de données managées, utilisez un plan adapté à vos besoins de disponibilité.

Ressources

• Ajustez les ressources (CPU, mémoire) et la taille du disque en fonction des besoins de votre application.
• Pour les bases de données CNPG, définissez des resource limits appropriés pour éviter les problèmes de performance.

Sécurité

• Pour les bases de données managées, limitez l'accès en utilisant le champ authorized_ips.
• Utilisez des secrets pour stocker les informations de connexion à la base de données.

Sauvegardes

• Mettez en place des sauvegardes régulières de vos bases de données.
• Testez régulièrement la restauration de vos sauvegardes.

Résolution des problèmes courants

Le DatabaseCluster n'est pas créé

• Vérifiez que vous avez bien poussé les changements vers le dépôt
• Vérifiez que le fichier YAML est correctement formaté
• Vérifiez que vous avez les droits nécessaires
• Vérifiez que la zone référencée existe

Erreur de connexion à la base de données

• Vérifiez que le DatabaseCluster a été créé avec succès
• Vérifiez que les secrets ont été correctement livrés au DeploymentTarget
• Vérifiez que votre application utilise les bonnes informations de connexion
• Pour les bases de données managées, vérifiez que l'adresse IP de votre application est autorisée

Problèmes de performance

• Vérifiez les ressources allouées à votre base de données
• Surveillez l'utilisation des ressources dans Grafana
• Optimisez vos requêtes et votre schéma de base de données
• Augmentez les ressources si nécessaire