Portfolio de Tiberiu Rosca

GLPI

GLPI a été le premier projet sur lequel j’ai travaillé, avec Linux et les outils autour.
Il est venu après Podman, car Podman a été utilisé pour le déployer.

Comment a-t-il été mis en place ?

GLPI fonctionne sur un serveur web (Apache, Nginx...), avec du PHP et une base de données SQL.
En sachant cela, nous avons pu concevoir une configuration fiable, permettant les sauvegardes, les mises à jour et les retours en arrière en cas de problème.

Nous avons décidé au départ d’utiliser un serveur Proxmox, et d’héberger des machines virtuelles Debian, dans lesquelles nous avons déployé des images Podman.
Cela permet à l’entreprise d’avoir de la flexibilité pour de futurs changements, et des intégrations avec d’autres outils (comme Jenkins).

Cette configuration est encore en développement, et certaines optimisations seront réalisées plus tard, après des projets plus urgents.

Représentation d’une pile serveur Proxmox, invité Debian et Podman

Dans cette configuration, nous créons une image GLPI avec Apache, PHP, et une version de GLPI déjà téléchargée et configurée pour la sécurité.

Pourquoi de cette manière

Pourquoi Podman

Cette configuration nous a permis de générer des images GLPI que nous pouvions déployer le plus rapidement possible, réduisant ainsi les interruptions de service.
Si nous voulions revenir en arrière après une mise à jour, il suffisait de déployer l’image précédente et d’utiliser la sauvegarde créée avant la mise à jour.

Podman permet également d’assurer la fiabilité des images, car nous obtenons toujours la même version de base de Debian, ce qui réduit les risques d’échec d’une image.

L’utilisation de Podman a aussi apporté plus de flexibilité si nous voulions nous éloigner de Proxmox pour fonctionner sans VM, ou déployer ailleurs.

Pourquoi un serveur SQL séparé

Séparer le serveur SQL permet d’avoir plus de fiabilité et de contrôle des versions. Cela permet de choisir la version, la méthode de mise à jour, et de revenir facilement en arrière.
Pour celui-ci, nous avons choisi d’utiliser une image officielle MariaDB. Elle était déjà disponible, donc pour accélérer un peu les choses, nous avons décidé de ne pas la créer nous-mêmes.

Sauvegarde Python séparée ?

Nous avons également déployé un serveur Python séparé, qui créait automatiquement des sauvegardes et les envoyait à l’endroit souhaité. Il nous envoyait aussi un email avec les journaux d’erreurs en cas d’échec d’une sauvegarde.