Selectel détaille l'installation de Jenkins sur un serveur cloud : des ressources au pipeline

Le build et le déploiement manuels cessent de fonctionner quand un projet grandit plus vite que l'équipe. Chaque modification de la base de code entraîne les mêmes étapes : compiler, lancer les tests, déployer. Plus elles sont nombreuses, plus le risque d'erreur augmente. Zavur, développeur front-end chez Selectel, a publié sur Habr un guide pour résoudre ce problème avec Jenkins sur un serveur virtuel cloud, du choix des ressources jusqu'à un pipeline fonctionnel.

Le texte est paru sur le blog d'entreprise de Selectel, et le serveur y est commandé dans le panneau de ce fournisseur. Mais le schéma lui-même ne dépend presque pas du fournisseur. On peut le reproduire sur n'importe quelle machine virtuelle Linux.

Pourquoi Jenkins plutôt qu'un CI intégré

GitHub Actions et GitLab CI ont un avantage évident : ils vivent à côté du dépôt. Le prix à payer, c'est la dépendance à la plateforme. Jenkins est conçu autrement. C'est un serveur d'automatisation open source autonome, qui récupère le code de n'importe quel dépôt Git sans se soucier de l'endroit où il est hébergé.

Le projet a une longue histoire. Né en 2011 comme fork de Hudson, il s'est entouré depuis d'un écosystème de plus de 1800 plugins. Ils permettent de brancher des systèmes de build, des scanners de code, des notifications vers les messageries et des API cloud. Pour les équipes à stack hétérogène ou travaillant en environnement fermé, c'est souvent l'argument décisif.

Selon l'auteur, Jenkins sait :

• construire des projets depuis n'importe quel dépôt Git ;
• lancer des tests automatiques ;
• construire des images Docker ;
• déployer des applications sur les serveurs cibles.

Ce que contient le guide

L'article suit l'ordre habituel de mise en place d'un serveur CI :

• évaluation des ressources selon les scénarios, du petit projet aux builds lourds ;
• commande d'un serveur virtuel dans le panneau Selectel ;
• préparation du système avant l'installation ;
• installation et configuration initiale de Jenkins ;
• pipeline simple de build automatique d'une application.

L'analyse des ressources est plus utile qu'il n'y paraît. Jenkins est écrit en Java, et la documentation du projet recommande, pour les petites équipes, à partir de 4 Go de RAM et environ 10 Go d'espace disque. Un minimum de 256 Mo ne convient guère qu'à une expérimentation. Les builds avec Docker et les tests lourds augmentent les besoins en processeur et en disque. Si l'on lésine sur le serveur, le pipeline plantera par manque de mémoire au pire moment. L'annonce ne reprend pas les chiffres du guide lui-même : reportez-vous au texte complet de l'article.

Où se cachent les pièges

Installer Jenkins prend quelques minutes. Les problèmes commencent après. Les versions récentes exigent une version à jour de Java (17 ou 21), et l'interface web s'ouvre par défaut sur le port 8080 sans HTTPS. Si on la laisse ainsi, le serveur est accessible à toute personne qui en connaît l'adresse. Il faut aussi mettre à jour les plugins : c'est justement par eux que des vulnérabilités sont corrigées régulièrement.

Autre piège : le stockage de la configuration. Un pipeline assemblé à coups de clics dans l'interface ne peut être ni relu ni annulé. Mieux vaut donc le décrire dans un Jenkinsfile et le conserver dans le dépôt, à côté du code.

Que faire concrètement

Pour une équipe de quelques personnes, cette combinaison couvre le besoin de base en CI/CD sans infrastructure superflue. La marche à suivre est raisonnable :

• commencez avec un petit serveur et surveillez la mémoire pendant les builds ;
• protégez l'accès à l'interface par HTTPS et par une restriction d'IP ou un VPN ;
• décrivez le pipeline dans un Jenkinsfile et conservez-le dans Git ;
• déportez les builds lourds vers des agents dédiés quand un seul serveur ne suffira plus.

Ce guide ne parle ni d'IA ni d'une nouvelle version. C'est un mode d'emploi pratique, utile aux ingénieurs DevOps débutants et aux développeurs front-end qui veulent arrêter de déployer à la main. Tout assistant IA moderne pour le code se heurte de toute façon à la même question : où et comment déployer le résultat. Sans build ni tests automatisés, tout le gain de vitesse de la génération de code se perd vite dans la vérification manuelle.