De l’hébergement au déploiement jusqu’à l’intérieur des programmes, il ne viendrait à l’idée de personne de devoir faire certaines actions manuellement à une fréquence régulière. Il y a plusieurs raisons à cela :

Le risque de faire des erreurs. Nous sommes humains et si on devait tout faire manuellement, qui plus est des choses répétitives, on risquerait très souvent de “casser la prod”.

Gagner du temps : Comme je vous le disais en introduction de cet article, les tâches automatisées c’est les vacances (ou presque 😛). Cela vous permet de vous concentrer sur des activités plus créatives et à forte valeur ajoutée.

Uniformiser les processus : L'automatisation garantit que chaque tâche est exécutée de manière cohérente à chaque fois. Cela permet de standardiser les opérations et d'assurer une qualité uniforme du produit final.

Faciliter la montée en échelle : Avec l'automatisation, il est plus simple de déployer des applications à grande échelle, sur plusieurs serveurs ou environnements. Cela vous permet de gérer efficacement des infrastructures complexes.

Documentation et traçabilité : Les scripts et outils d’automatisation peuvent être versionnés et documentés, offrant ainsi une meilleure traçabilité des changements et une documentation fiable des processus utilisés.

Coût réduit : À long terme, l’automatisation permet de réduire les coûts opérationnels, en nécessitant moins d'interventions manuelles et en réduisant les erreurs coûteuses.

Bon, vous l’aurez compris ça a beaucoup d’avantages et ça facilite pas mal notre travail quotidien 😀

“C’est super ça mais comment fait alors pour la mettre en place ?”

Et bien, tout dépend de votre stack technique et de ses configurations mais ici j’ai choisi de traiter un cas assez courant à savoir une application fonctionnant sur des services Docker.

Imaginons pour l’exemple que vous ayez une application sous Symfony et que vous souhaitez automatiser la consommation de messages placés dans une instance RabbitMQ.

Automatiser avec Supervisor

Supervisor est un outil populaire pour gérer les processus en arrière-plan. Il redémarre automatiquement les processus en cas d'échec, ce qui est idéal pour les consommateurs de messages comme Symfony Messenger.

Installation de Supervisor (Ubuntu/Debian)

Simplement avec apt

Configuration de Supervisor

Créez un fichier de configuration pour le processus Symfony Messenger.

Ajoutez la configuration suivante :

command : La commande que vous voulez exécuter. Remplacez /path/to/php par le chemin de votre exécutable PHP et /path/to/your/project par le chemin de votre projet Symfony.

autostart=true : Le processus démarrera automatiquement au démarrage de Supervisor.

autorestart=true : Le processus sera redémarré automatiquement en cas de plantage.

user=www-data : L'utilisateur sous lequel le processus sera exécuté. Remplacez www-data par l'utilisateur approprié.

Démarrer le processus avec Supervisor

Après avoir créé le fichier de configuration, rechargez Supervisor et démarrez le processus :

Automatiser avec systemd

Si votre serveur utilise systemd, vous pouvez créer un service systemd pour gérer votre commande.

Créer un service systemd

Créez un fichier de service :

Ajoutez la configuration suivante :

Démarrer le service avec systemd

Après avoir créé le fichier de service, démarrez-le et assurez-vous qu'il démarre au démarrage du système :

Automatiser avec Docker

Non vous ne rêvez pas, si vous le souhaitez il est tout à fait possible d’utiliser un container Docker pour automatiser les tâches d’un … container Docker 😀

En fait comme vous le savez déjà, un container peut être “lié” à un autre, c’est le cas par exemple entre un container PHP et un container d’une base de données. Donc il est tout à fait envisageable sur ce principe d’avoir un container qui agit automatiquement sur un autre lorsqu’il est lancé.

Voyons cela en détail :

Exemple de Docker-compose

Ajoutez un service dans votre fichier docker-compose.yml :

Puis démarrez ce service avec :

Dans l’idée de tout garder sous Docker c’est la solution que j’ai choisi dans ma situation et cela fonctionne parfaitement. Mais vous pouvez très bien utiliser une autre des méthodes que l’on a évoqué.

Pourquoi éviter les cronjobs ?

“Oui mais si moi j’aime faire des cron c’est possible ou pas ?”

C’est effectivement possible, rien ne vous en empêche mais ce n’est pas la solution la plus recommandée :

Avantages et inconvénients de l'utilisation de Cron

Avantages :

Simplicité : Un cron job est simple à configurer et ne nécessite pas de processus supplémentaire.

Contrôle horaire : Vous pouvez planifier l'exécution à des moments précis.

Inconvénients :

Redémarrage automatique : Contrairement à des solutions comme Supervisor, un cron job ne redémarrera pas automatiquement un processus qui s'arrête de manière inattendue.

Surveillance : Vous aurez moins de visibilité et de contrôle sur l'exécution continue du consommateur.

Comment être alerté en cas de problème ?

“Ok bon je vois mais ton système aussi là il peut avoir des erreurs et des bugs non ?”

Oui, comme toujours en informatique, le risque zéro n’existe pas. Donc pour palier à cela on peut prévoir d’être alerté en cas de problème et là aussi il y a plusieurs solutions.

Alertes basées sur les logs

Vous pouvez utiliser des outils ou des scripts pour détecter des erreurs dans les logs et envoyer des alertes.

Surveiller les Logs avec un Script Bash

Vous pouvez écrire un script bash qui recherche des erreurs spécifiques dans les logs du consommateur, puis envoie un email ou une notification.

Exemple de script pour surveiller les erreurs :

Vous pouvez ensuite programmer ce script pour s'exécuter régulièrement via cron :

Utiliser un service de surveillance des Logs

Si vous avez un système de centralisation des logs (comme ELK Stack, Loggly, Splunk, ou un autre service SaaS), vous pouvez configurer des alertes basées sur des conditions spécifiques, comme des erreurs ou des interruptions dans les logs.

Supervision du processus avec supervisor

Si vous utilisez Supervisor, vous pouvez configurer des alertes par email en cas d'arrêt inattendu du consommateur :

Dans le fichier de configuration supervisor.conf pour votre consommateur :

Monitoring de conteneur avec Docker

Si vous utilisez Docker, vous pouvez utiliser des outils comme Prometheus et Alertmanager pour surveiller l'état des conteneurs et déclencher des alertes.

Prometheus collecte les métriques sur l'état des conteneurs (par exemple, si un conteneur est en panne).

Alertmanager est utilisé pour envoyer des alertes par email, Slack, ou d'autres canaux de notification basés sur les conditions définies dans Prometheus.

Monitoring de serveur avec des outils externes

Vous pouvez utiliser des services de monitoring tels que New Relic, Datadog, Nagios, ou Zabbix pour surveiller la santé de votre application, y compris les processus en arrière-plan comme Symfony Messenger.

Ces outils peuvent être configurés pour :

Surveiller l'état des processus ou des services (s'assurer que le consommateur est en cours d'exécution).

Surveiller l'utilisation des ressources (CPU, mémoire, etc.).

Déclencher des alertes en fonction de seuils ou d'événements spécifiques (par exemple, si un processus s'arrête ou échoue).

Configurer des alertes avec Cron

Si vous avez tout de même décidé d’utiliser Cron 😛 ou que vous y êtes obligés par contrainte technique, vous pouvez configurer cron pour envoyer un email en cas d'erreur.

Ajoutez MAILTO en haut de votre crontab pour spécifier l'adresse email de destination :

Avec cette configuration, si une erreur survient lors de l'exécution de la commande, cron enverra un email à l'adresse spécifiée.

Conclusion

Voilà, vous savez maintenant à la fois comment automatiser des process dans un container Docker et aussi les monitorer, c’est-à-dire les surveiller et être alerté en cas de problème.

Vous y gagnerez du temps, de la performance et de la propreté dans vos configurations. D’autant plus que vous pouvez dupliquer ces process à vos futures applications et ainsi avoir la même routine sur quasiment tous vos projets selon leur stack technique.

Je vous avais dit qu’on allait parler de vacances ? 😀

Allez, sur ces belles paroles on se retrouve bientôt pour un prochain article. 🙂