Sauvegardes d’une instance PostgreSQL

Magazine
Marque
Linux Pratique
Numéro
141
Mois de parution
janvier 2024
Spécialité(s)


Résumé

Maintenant que nous avons installé [1] et configuré [2] un serveur PostgreSQL, la prochaine étape revient à s’assurer de sa sauvegarde. Il existe deux types de sauvegardes avec PostgreSQL : la sauvegarde (ou export) logique et la sauvegarde physique.


Body

Pour un export logique, il est habituel de faire appel à l’outil pg_dump. Cependant, ce dernier ne gère pas la rétention, ce qui est pourtant une fonctionnalité critique. Nous allons donc mettre en place l’outil pg_back qui utilise en sous-main pg_dump, et propose de gérer, entre autres, la rétention.

Pour ce qui est des sauvegardes physiques (aussi appelées sauvegardes PITR), les développeurs de PostgreSQL proposent pg_basebackup, mais là aussi, pas de gestion de la rétention. Deux outils sont généralement sélectionnés : pgbackrest et barman. Ma préférence va à pgbackrest, bien plus complet, et c’est donc ce dernier que nous installerons.

1. Gérer les exports logiques avec pg_back

Les exports logiques dans PostgreSQL sont gérés avec les outils pg_dump et pg_dumpall. Ce dernier peut sembler suffisant vu qu’il sauvegarde toute l’instance, mais il souffre d’un inconvénient majeur : le résultat de l’export est un script SQL. De ce fait, il devient très compliqué de faire une restauration partielle (par exemple, une seule base ou quelques tables). Le cas où nous avons besoin de restaurer l’instance complète est assez rare, ce qui diminue fortement l’intérêt de pg_dumpall.

Donc les utilisateurs ont plutôt tendance à utiliser pg_dump. Lors de son exécution, cet outil ne s’occupera que d’une seule base. Si nous souhaitons sauvegarder toutes les bases, il faut alors l’exécuter une fois par base à sauvegarder. Cet inconvénient est contrebalancé par tous les avantages de cet outil : sauvegarde complète ou partielle, format de sauvegarde au choix, compression, etc. Pour en revenir au souci de la sauvegarde par base, elle amène un autre problème : il faut connaître la liste des bases à sauvegarder. Nous pouvons très bien écrire un script avec en dur la liste des bases et une exécution de pg_dump pour chacune des bases, mais cela voudrait dire qu’il faut modifier le script à chaque ajout et suppression de base. Ça n’est pas pratique, c’est source d’erreurs. Il faut donc un moyen automatisé pour récupérer la liste des bases à sauvegarder. L’outil psql nous permet de le faire en exécutant une requête sur le catalogue système pg_database.

Il existe un autre inconvénient à pg_dump. Le script de création du schéma permet de cloner les objets de cette base. Cela veut dire qu’il contient la définition des objets, avec leur propriétaire, leur tablespace, et les droits des utilisateurs sur ces objets. Cependant, la définition des rôles (propriétaires et utilisateurs) et des tablespaces n’est pas incluse dans cette sauvegarde. L’explication généralement donnée (mais peu convaincante) est que ce ne sont pas des objets de la base et que pg_dump ne sauvegarde que les objets contenus dans la base. Bref, si nous voulons importer sans erreur le résultat de pg_dump, il faut que les rôles et les tablespaces soient déjà définis. Et c’est là que pg_dumpall devient intéressant. Cet outil permet de sauvegarder uniquement la définition de tous les rôles et de tous les tablespaces grâce à l’option --globals-only.

Donc si nous devions résumer en un petit script les différentes opérations à réaliser, cela ressemblerait à cela :

pg_dumpall --globals-only > definition_roles_tablespaces.sql
psql -XAtc "SELECT datname FROM pg_database WHERE datallowconn ORDER BY datname" | while read d
do
  pg_dump -Fc ${d} > ${d}.dump
done

Évidemment, c’est très simpliste. Il y a plein d’autres points à prendre en compte, comme exclure certaines bases, gérer le niveau de compression, gérer la rétention, gérer la sauvegarde sur un serveur secondaire, etc.

Pour éviter d’avoir à coder un script gérant tout ça (sans même parler de la maintenance d’un tel script personnalisé), il est nettement préférable de s’en remettre à un outil déjà conçu pour ça. Cet outil s’appelle pg_back. Il a été écrit par Nicolas Thauvin et profite de toute l’expérience de ce dernier comme administrateur PostgreSQL. Il est disponible sur son site GitHub (https://github.com/orgrim/pg_back). Des packages Debian et RPM sont téléchargeables directement depuis le site (https://github.com/orgrim/pg_back/releases). Le script fait appel à pg_dumpall pour récupérer la définition des rôles et des tablespaces. Il récupère la liste des bases à sauvegarder, tout en excluant celles indiquées dans son fichier de configuration. Il utilise par défaut le format binaire custom pour la sauvegarde. La sauvegarde des différentes bases peut être parallélisée. Une somme de contrôle peut être calculée et enregistrée une fois la sauvegarde terminée. Il sait mettre en pause le rejeu de la réplication quand il sauvegarde à partir d’un secondaire. Et surtout, il gère la rétention des sauvegardes. C’est un outil très complet, et très facilement configurable.

Voici comment l’installer sur le système que nous avons mis en place depuis deux articles maintenant :

(root)# dnf install -y \
  https://github.com/orgrim/pg_back/releases/download/v2.1.1/pg-back-2.1.1-x86_64.rpm

La version 2.2.1 correspond à la dernière version de ce projet au moment de l’écriture de cet article. Je vous conseille fortement de vérifier si une version plus récente est disponible.

Le fichier de configuration se trouve dans le répertoire /etc/pg_back. Nous allons simplement modifier le répertoire des binaires de PostgreSQL, vu qu’il ne se trouve pas forcément dans le PATH de chaque utilisateur :

bin_directory = /usr/pgsql-15/bin

Le répertoire de sauvegarde, indiqué par le paramètre backup_directory, est par défaut /var/backups/postgresql. Il peut être intéressant de le modifier pour qu’il pointe vers un autre disque, plus volumineux. Dans tous les cas, il doit exister, nous allons donc le créer :

(root)# install -d -o postgres -g postgres -m 700 /var/backups/postgresql

La rétention se configure en nombre de jours (paramètre purge_older_than) et en nombre de sauvegardes (paramètre purge_min_keep). Par défaut, la rétention est de 30 jours. Il sera nécessaire de la modifier suivant la taille de la sauvegarde et la place disponible sur disque.

Pour tester la sauvegarde, nous allons créer deux bases et les peupler à l’aide de l’outil pgbench :

(postgres)$ createdb b1
(postgres)$ createdb b2
(postgres)$ export PATH=/usr/pgsql-15/bin:$PATH
(postgres)$ pgbench -i b1
[...]
done in 0.42 s (drop tables 0.00 s, create tables 0.02 s, client-side generate 0.24 s, vacuum 0.06 s, primary keys 0.10 s).
(postgres)$ pgbench -is 100 b2
[...]
done in 26.76 s (drop tables 0.00 s, create tables 0.03 s, client-side generate 21.34 s, vacuum 0.48 s, primary keys 4.91 s).

Maintenant, lançons une sauvegarde :

(postgres)$ pg_back
2023/10/28 15:27:06 INFO: dumping globals
2023/10/28 15:27:06 INFO: dumping instance configuration
2023/10/28 15:27:06 INFO: dumping database postgres
2023/10/28 15:27:06 INFO: dump of postgres to /var/backups/postgresql/postgres_2023-10-28T15:27:06+02:00.dump done
2023/10/28 15:27:06 INFO: dumping database b1
2023/10/28 15:27:07 INFO: dump of b1 to /var/backups/postgresql/b1_2023-10-28T15:27:06+02:00.dump done
2023/10/28 15:27:07 INFO: dumping database b2
2023/10/28 15:27:15 INFO: dump of b2 to /var/backups/postgresql/b2_2023-10-28T15:27:07+02:00.dump done
2023/10/28 15:27:15 INFO: waiting for postprocessing to complete
2023/10/28 15:27:15 INFO: purging old dumps

Voyons ce que pg_back a ajouté dans le répertoire de sauvegarde :

(postgres)$ ll /var/backups/postgresql/
total 27784
-rw-r--r--. 1 postgres postgres   285528 Oct 28 15:27 b1_2023-10-28T15:27:06+02:00.dump
-rw-r--r--. 1 postgres postgres 28136068 Oct 28 15:27 b2_2023-10-28T15:27:07+02:00.dump
-rw-r--r--. 1 postgres postgres     4608 Oct 28 15:27 hba_file_2023-10-28T15:27:06+02:00.out
-rw-r--r--. 1 postgres postgres     1669 Oct 28 15:27 ident_file_2023-10-28T15:27:06+02:00.out
-rw-r--r--. 1 postgres postgres      374 Oct 28 15:27 pg_globals_2023-10-28T15:27:06+02:00.sql
-rw-r--r--. 1 postgres postgres      583 Oct 28 15:27 pg_settings_2023-10-28T15:27:06+02:00.out
-rw-r--r--. 1 postgres postgres     1035 Oct 28 15:27 postgres_2023-10-28T15:27:06+02:00.dump

Nous avons les sauvegardes des bases b1, b2 et postgres, la sauvegarde des objets globaux, et même la sauvegarde des fichiers de configuration du serveur PostgreSQL. Configurons maintenant une rétention de deux sauvegardes :

purge_older_than = 0
purge_min_keep = 2

Faisons maintenant plusieurs sauvegardes, puis regardons le nombre de sauvegardes de la base b1 :

(postgres)$ ll /var/backups/postgresql/b1*
-rw-r--r--. 1 postgres postgres 285528 Oct 28 15:27 /var/backups/postgresql/b1_2023-10-28T15:27:06+02:00.dump
(postgres)$ ll /var/backups/postgresql/b1* | wc -l
1
(postgres)$ pg_back >& /dev/null
(postgres)$ ll /var/backups/postgresql/b1* | wc -l
2
(postgres)$ pg_back >& /dev/null
(postgres)$ ll /var/backups/postgresql/b1* | wc -l
2
(postgres)$ ll /var/backups/postgresql/b1*
-rw-r--r--. 1 postgres postgres 285528 Oct 28 15:31 /var/backups/postgresql/b1_2023-10-28T15:31:22+02:00.dump
-rw-r--r--. 1 postgres postgres 285528 Oct 28 15:31 /var/backups/postgresql/b1_2023-10-28T15:31:37+02:00.dump

Après la deuxième sauvegarde, nous avons deux fichiers pour b1. Après la troisième sauvegarde, nous n’en avons toujours que 2. En regardant le nom des fichiers, nous voyons bien la troisième sauvegarde (à 15:31:37), et la première sauvegarde (à 15:27:06) n’existe plus, elle a été supprimée.

Il ne reste plus qu’à exécuter pg_back grâce à la crontab, avec une fréquence dépendant de votre RPO (Recovery Point Objective), et à configurer une rétention plus en phase avec vos besoins.

Quant à la restauration, pg_back ne propose rien. Ça n’aurait pas vraiment de sens de toute façon. L’export des objets globaux se restaure avec l’outil psql et l’export des bases avec l’outil pg_restore.

2. Gérer les sauvegardes PITR avec pgbackrest

Un export logique a deux inconvénients forts. La fenêtre de perte de données peut être très importante. Tout dépend de la fréquence des sauvegardes, mais il est rare de voir des exports logiques réalisés fréquemment. Donc le RPO se mesurera généralement en jours, plus rarement en heures. L’autre inconvénient concerne la rapidité de remise en place du service. Je devrais d’ailleurs plutôt parler ici de lenteur. Importer une sauvegarde logique prend du temps. Plus il y aura d’index et de contraintes dans la sauvegarde logique, plus l’import sera long. Et donc, le RTO (Recovery Time Objective) est lui aussi important.

Si vous avez besoin d’un RPO et d’un RTO minimal, il est pratiquement obligatoire de se tourner vers les sauvegardes PITR. Le RPO est minimal, car, après la sauvegarde, toute modification dans la base est archivée pour pouvoir être rejouée le cas échéant. Le RTO est minimal, car il n’est pas nécessaire de reconstruire les index et de vérifier les contraintes.

L’outil proposé par les développeurs de PostgreSQL pour une sauvegarde PITR simplifiée est pg_basebackup. Cependant, là aussi, la rétention n’est pas gérée et la restauration nécessite de réaliser plusieurs actions.

D’autres outils sont apparus, les plus connus étant barman et pgbackrest. Ce dernier proposant plus de fonctionnalités, nous allons nous pencher sur lui.

Son installation nécessite l’activation du dépôt EPEL. Cela se fait ainsi :

(root)# dnf install -y                                                        \
  https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm      \
  https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

Il ne reste plus qu’à installer le paquet pgbackrest :

(root)# dnf install -y pgbackrest

La configuration se trouve dans le fichier /etc/pgbackrest.conf. Ce dernier ressemble à un fichier INI avec des sections de configuration (dont le nom est entre crochets) et une série de paramètres par section, avec le format standard « paramètre = valeur ».

Dans la section global, un paramètre essentiel est repo1-path. Il indique où seront stockées les sauvegardes. Nous allons conserver la valeur par défaut.

Chaque instance à sauvegarder doit avoir sa propre section, appelée par la suite stanza. Cette section indiquera comment se connecter à l’instance à sauvegarder et permettra de personnaliser les options de sauvegarde de l’instance. Ajoutons-en une dans le fichier de configuration par l’intermédiaire de ces deux lignes :

[linuxpratique]
pg1-path=/srv/data

Ceci fait, nous devons initialiser la stanza. Cela se fait par l’intermédiaire de l’action stanza-create :

(postgres)$ pgbackrest stanza-create --stanza linuxpratique

Cette commande a créé quelques sous-répertoires dans le répertoire indiqué par le paramètre repo1-path.

L’action check nous permet de vérifier notre configuration :

(postgres)$ pgbackrest check
ERROR: [087]: archive_mode must be enabled

La stanza est bien décrite, pgbackrest a pu se connecter à l’instance, mais il s’est rendu compte que le paramètre archive_mode de l’instance PostgreSQL n’était pas configuré. Il faut en effet configurer l’archivage dans PostgreSQL. Pour cela, nous allons réaliser ces deux ajouts dans le fichier linuxpratique.conf :

archive_mode = on
archive_command = 'pgbackrest archive-push --stanza=linuxpratique %p'

Pour que ces modifications soient prises en compte, il faut redémarrer le serveur PostgreSQL :

(root)# systemctl restart postgresql-15

Relançons maintenant la vérification de notre configuration :

(postgres)$ pgbackrest check

Pas de message, tout va bien. Demandons plus d’informations :

(postgres)$ pgbackrest info
stanza: linuxpratique
    status: error (no valid backups)
    cipher: none
 
    db (current)
        wal archive min/max (15): 00000001000000000000004F/00000001000000000000004F

Parfait. L’erreur sur le fait qu’il n’y ait pas de sauvegardes valides est logique, vu que nous n’avons pas encore effectué de sauvegarde. De ce fait, nous allons maintenant pouvoir lancer une sauvegarde. Cela se fait avec l’action backup :

(postgres)$ pgbackrest backup --stanza linuxpratique
WARN: option 'repo1-retention-full' is not set for 'repo1-retention-full-type=count', the repository may run out of space
      HINT: to retain full backups indefinitely (without warning), set option 'repo1-retention-full' to the maximum.
WARN: no prior backup exists, incr backup has been changed to full

Nous avons un premier message d’avertissement nous indiquant que nous n’avons pas configuré de rétention, et que cela peut s’avérer dangereux pour l’espace disque disponible. Le deuxième message d’avertissement indique que pgbackrest fait une sauvegarde complète vu qu’il n’y en a pas encore. En effet, par défaut, pgbackrest fait des sauvegardes incrémentales. Si nous voulons un autre type de sauvegarde (complète ou différentielle), il faut le spécifier avec l’option --type qui prend en argument le type de sauvegarde souhaité.

Ceci étant dit, la sauvegarde s’est bien terminée :

(postgres)$ pgbackrest info
stanza: linuxpratique
    status: ok
    cipher: none
 
    db (current)
        wal archive min/max (15): 000000010000000000000053/000000010000000000000054
 
        full backup: 20231028-173108F
            timestamp start/stop: 2023-10-28 17:31:08+02 / 2023-10-28 17:31:42+02
            wal start/stop: 000000010000000000000054 / 000000010000000000000054
            database size: 1.5GB, database backup size: 1.5GB
            repo1: backup set size: 86.8MB, backup size: 86.8MB

La rétention se configure avec le paramètre repo1-retention-full. Par exemple :

repo1-retention-full=2

Si nous lançons une deuxième sauvegarde avec cette nouvelle configuration, nous nous trouvons cette fois-ci avec une sauvegarde incrémentale :

[postgres@localhost ~]$ pgbackrest backup --stanza linuxpratique
[postgres@localhost ~]$ pgbackrest info
stanza: linuxpratique
    status: ok
    cipher: none
 
    db (current)
        wal archive min/max (15): 000000010000000000000053/000000010000000000000056
 
        full backup: 20231028-173108F
            timestamp start/stop: 2023-10-28 17:31:08+02 / 2023-10-28 17:31:42+02
            wal start/stop: 000000010000000000000054 / 000000010000000000000054
            database size: 1.5GB, database backup size: 1.5GB
            repo1: backup set size: 86.8MB, backup size: 86.8MB
 
        incr backup: 20231028-173108F_20231028-173919I
            timestamp start/stop: 2023-10-28 17:39:19+02 / 2023-10-28 17:39:20+02
            wal start/stop: 000000010000000000000056 / 000000010000000000000056
            database size: 1.5GB, database backup size: 20.2KB
            repo1: backup set size: 86.8MB, backup size: 2.3KB
            backup reference list: 20231028-173108F

Nous pouvons faire autant de sauvegardes que nous le souhaitons, la rétention n’entre pas en ligne de compte, car elle ne concerne que les sauvegardes complètes. Par contre, si je fais deux nouvelles sauvegardes complètes, seules les deux dernières sauvegardes complètes seront conservées :

[postgres@localhost ~]$ pgbackrest info
stanza: linuxpratique
    status: ok
    cipher: none
 
    db (current)
        wal archive min/max (15): 00000001000000000000005C/00000001000000000000005E
 
        full backup: 20231028-174134F
            timestamp start/stop: 2023-10-28 17:41:34+02 / 2023-10-28 17:42:08+02
            wal start/stop: 00000001000000000000005C / 00000001000000000000005C
            database size: 1.5GB, database backup size: 1.5GB
            repo1: backup set size: 86.8MB, backup size: 86.8MB
 
        full backup: 20231028-174235F
            timestamp start/stop: 2023-10-28 17:42:35+02 / 2023-10-28 17:43:14+02
            wal start/stop: 00000001000000000000005E / 00000001000000000000005E
            database size: 1.5GB, database backup size: 1.5GB
            repo1: backup set size: 86.8MB, backup size: 86.8MB

Nous remarquons d’ailleurs que cela a forcé la suppression des sauvegardes incrémentales entre la première sauvegarde (réalisée à 17h31, et qui a été supprimée pour respecter la configuration de la rétention) et la deuxième sauvegarde (lancée à 17h41).

Reste à tester la restauration. Disons qu’à 18h02, nous avons ajouté une troisième base :

(postgres)$ date && createdb b3
Sat Oct 28 06:02:28 PM CEST 2023

Et qu’à 18h05, j’ai supprimé par erreur la base b2 :

(postgres)$ date && dropdb b2
Sat Oct 28 06:05:29 PM CEST 2023

Je souhaite restaurer ma sauvegarde et rejouer l’activité jusqu’à avant la suppression de b2, donc un peu avant 18h05. Pour cela, nous allons utiliser l’action restore en lui précisant la cible de restauration. Il faut tout d’abord arrêter PostgreSQL :

(root)# systemctl stop postgresql-15

Puis supprimer le contenu du répertoire de données et du répertoire des journaux de transactions :

(root)# rm -rf /srv/data/* /srv/wal/*

Nous pouvons enfin lancer la restauration en précisant la cible datée :

(postgres)$ pgbackrest restore --stanza linuxpratique --type time --target "2023-10-28 18:04:00"
WARN: contents of directory link 'pg_wal' will be restored in a directory at the same location

Comme l’indique le message d’avertissement, le répertoire pg_wal n’est plus le lien symbolique renvoyant vers la bonne partition. Nous allons donc changer cela :

(root)# cd /srv/data
(root)# rm -rf pg_wal/
(root)# ln -s /srv/wal pg_wal

L’action restore de pgbackrest a rempli le fichier postgresql.auto.conf avec le paramétrage de restauration :

(root)# cat postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
 
# Recovery settings generated by pgBackRest restore on 2023-10-28 18:09:49
restore_command = 'pgbackrest --stanza=linuxpratique archive-get %f "%p"'
recovery_target_time = '2023-10-28 18:04:00'

et il a créé le fichier recovery.signal :

(root)# ll recovery.signal
-rw-------. 1 postgres postgres 0 Oct 28 18:09 recovery.signal

Il ne reste plus qu’à démarrer PostgreSQL :

(root)# systemctl start postgresql-15

Au bout d’un petit moment, nous pouvons nous connecter et constater la réapparition de la base supprimée :

(postgres)$ psql -Atc "SELECT datname FROM pg_database ORDER BY datname"
b1
b2
b3
postgres
template0
template1

Nous avons donc bien un système qui nous permet de restaurer jusqu’à un moment spécifique situé plus loin que la fin de la sauvegarde.

Il existe énormément plus d’options pour pgbackrest, à tel point qu’il est difficile de les connaître toutes. Heureusement, la documentation (https://pgbackrest.org/command.html) est bien écrite et exhaustive. Il est aussi à noter que Stefan Fercot, un contributeur majeur de pgbackrest, a fait de nombreuses conférences sur le sujet, et certaines sont disponibles sur YouTube. Son blog contient aussi plusieurs articles sur cet outil (https://pgstef.github.io/).

3. Exports logiques ou sauvegardes PITR ?

Maintenant que nous avons discuté des deux outils, lequel doit-on vraiment installer ? Mon avis personnel serait les deux. Même si ce sont tous les deux des outils de sauvegarde, ils ne font pas la même chose, ils ne remplissent pas le même besoin.

Un export logique pourra être restauré sur n’importe quel serveur, quelle que soit son architecture côté matériel et côté logiciel. Il pourra être restauré sur une version majeure de PostgreSQL différente de celle de la sauvegarde. Il pourra être restauré partiellement.

Cependant, sa relative lenteur en sauvegarde comme en restauration fait qu’une sauvegarde PITR est très intéressante, car bien plus rapide, dans le cas d’un serveur de production problématique où seul un rechargement de la sauvegarde permettrait de reprendre la production. La sauvegarde PITR est aussi intéressante pour restaurer jusqu’à un certain point dans le temps, permettant à la fois de minimiser le RPO tout en évitant de rejouer des écritures erronées.

Bref, c’est à vous de faire ce choix. Le mien est fait : il faut faire les deux sauvegardes, mais pas avec la même fréquence. L’export logique se fait moins fréquemment, voire manuellement, pour régler des besoins spécifiques. La sauvegarde PITR est mise en place en permanence et la sauvegarde des fichiers se fait à une fréquence allant de tous les jours à toutes les semaines. Il est possible d’avoir une sauvegarde de fichiers encore moins fréquente, mais cela rendra la restauration plus lente et plus risquée.

4. Oups

L’article précédent [2] mentionnait d’activer la récupération de statistiques sur les routines en configurant le paramètre track_functions à la valeur on. C’est une erreur, ce paramètre n’est pas un booléen. Il peut avoir les valeurs none, pl ou all. La valeur pl permet de tracer l’activité sur les fonctions écrites dans un langage de procédure, la valeur all permet de tracer aussi les fonctions C et SQL. La valeur all est intéressante, mais la valeur pl peut s’avérer suffisante.

Références

[1] « Installation de PostgreSQL », Linux Pratique n°139 :
https://connect.ed-diamond.com/linux-pratique/lp-139/installation-de-postgresql

[2] « Configuration de base d’une instance PostgreSQL », Linux Pratique n°140 :
https://connect.ed-diamond.com/linux-pratique/lp-140/configuration-de-base-d-une-instance-postgresql



Article rédigé par

Par le(s) même(s) auteur(s)

Supervision d’une instance PostgreSQL

Magazine
Marque
Linux Pratique
Numéro
142
Mois de parution
mars 2024
Spécialité(s)
Résumé

Maintenant que nous sommes rassurés suite à l’installation de solutions de sauvegarde [1], il est temps de s’occuper de la supervision de notre instance. Il existe différents types d’outils, certains en ligne de commandes, certains graphiques (généralement une application web), certains font de la rétro-analyse alors que d’autres font de la supervision en direct. Encore une fois avec PostgreSQL, les outils sont nombreux et la difficulté vient principalement du choix offert.

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 125 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous