Ce guide de GitLab explique comment sécuriser les conteneurs à chaque étape de leur cycle de vie grâce à différentes méthodes de container scanning. L’objectif est de détecter les vulnérabilités dès leur apparition, que ce soit lors de la construction de l’image ou en production, afin d’éviter les risques liés aux dépendances externes (OS, bibliothèques, etc.). GitLab propose cinq approches de scanning, dont le pipeline-based Container Scanning, qui analyse les images via Trivy lors des pipelines CI/CD pour bloquer les images vulnérables avant déploiement.
L’article détaille notamment l’activation du pipeline-based Container Scanning, soit via une configuration automatique via une merge request, soit manuellement en ajoutant un template dans le fichier .gitlab-ci.yml. Il est possible de personnaliser le scan en ciblant une image spécifique ou en filtrant les vulnérabilités selon leur gravité (ex. uniquement les vulnérabilités High ou plus). Les résultats s’affichent directement dans les merge requests, avec des détails sur la sévérité, les paquets concernés et les correctifs disponibles.
Ce guide explique comment configurer un pipeline CI/CD complet pour une application React avec GitLab, permettant des déploiements automatisés. L’auteur souligne les avantages de cette approche, comme l’élimination des erreurs liées aux différences d’environnement local et la suppression des déploiements manuels, source de problèmes passés. Le tutoriel détaille la création d’un fichier .gitlab-ci.yml pour automatiser les tests, la construction et le déploiement sur GitLab Pages à chaque push sur la branche principale.
L’article illustre la configuration avec un projet React simple, intégrant des variables d’environnement pour afficher des informations comme l’heure de construction ou l’environnement. Il met en garde contre des pièges courants, comme la gestion des emojis dans les tests ou les restrictions de CRA concernant les variables d’environnement, et propose des solutions pratiques pour les contourner. Le pipeline est conçu pour reproduire fidèlement l’environnement de production, garantissant ainsi une cohérence dans les builds.
Dans ce second volet de leur série sur le déploiement On-Premise, JoliCode explique comment automatiser et simplifier la création et la publication des images Docker en production grâce à Castor, un outil de gestion de tâches PHP. L’article détaille une task Castor (production:build) qui vérifie la branche Git, les modifications non commitées, construit les images et les pousse vers un registre privé, tout en gérant les tags de version (format YYYY.MM.DD). L’objectif est de rendre le processus de déploiement plus fluide et autonome pour les clients. Un exemple de code et des explications sur l’intégration avec GitLab CI sont également fournis.
Ce billet présente 10 prompts d'IA prêts à l'emploi pour accélérer la livraison de logiciels en éliminant les goulots d'étranglement courants. Il explique comment l'IA peut être utilisée pour améliorer les processus d'examen de code, de sécurité et de documentation, en fournissant des exemples concrets de prompts pour des tâches spécifiques comme la détection d'erreurs logiques, l'identification des changements cassants et l'analyse des résultats de scans de sécurité. L'objectif est d'aider les équipes à améliorer leur efficacité et à livrer des logiciels plus rapidement.
Cet article explore les différents types d'executors de GitLab Runner, essentiels pour optimiser vos pipelines CI/CD. Il explique en détail le fonctionnement des GitLab Runners, leur architecture, et les implications en termes de sécurité, coûts, et scalabilité. L'article souligne l'importance de comprendre les flux réseau et les distinctions entre le Runner Manager et les environnements d'exécution pour une configuration efficace et sécurisée.
Andrew Nesbitt explore le fonctionnement de Dependabot, un outil de mise à jour automatique des dépendances pour GitHub, GitLab et Gitea. Bien que Dependabot soit souvent perçu comme un bot intelligent, il s'agit en réalité d'une bibliothèque Ruby sans état, dont la logique de mise à jour est open source sous licence MIT, mais dont la coordination et le suivi d'état restent propriétaires. L'auteur détaille l'architecture du code, qui supporte plus de 25 écosystèmes de paquets, et explique comment Dependabot utilise des outils natifs pour effectuer les mises à jour. Malgré sa complexité, Dependabot-core est conçu pour être sans état, traitant chaque tâche de manière indépendante.
Pour remplacer son instance GitLab auto-hébergée (trop gourmande en ressources pour un usage personnel), l’auteur a migré vers Forgejo (fork de Gitea) en utilisant Terraform pour automatiser la transition. Plutôt que d’utiliser des scripts de migration obsolètes, il a exploité les providers Terraform pour GitLab et Gitea/Forgejo : le code liste les projets source, les recrée en mode miroir sur la nouvelle forge, puis bascule le domaine. La CI/CD a été réécrite en workflows Forgejo Actions (similaires à GitHub Actions), simplifiant le processus et réduisant significativement la consommation de ressources (10 Go de RAM et 10 % d’espace disque gagnés). Une approche efficace et maintenable, qui montre comment détourner Terraform pour des besoins ponctuels. Le gain en performance et en simplicité est notable, surtout pour un petit serveur.
Ce billet détaille la migration d’une instance GitLab vers un nouveau serveur, motivée par la fin de vie de CentOS. L’auteur a opté pour AlmaLinux 9, compatible avec les paquets RedHat. La procédure repose sur la documentation officielle de GitLab et s’applique à toute distribution supportée.
Étapes clés :
- Installation : Installer GitLab sur le nouveau serveur en utilisant la même version que l’ancien, après avoir mis à jour le système et ajouté les dépôts GitLab.
- Sauvegarde et transfert : Créer une sauvegarde complète de l’instance existante, transférer les fichiers de configuration (
gitlab.rb,gitlab-secrets.json) et les backups vers le nouveau serveur viarsync. - Restauration : Arrêter les services, restaurer la sauvegarde, puis relancer et vérifier l’intégrité des données avec des commandes comme
gitlab-rake gitlab:checketgitlab:doctor:secrets. - Finalisation : Mettre à jour les enregistrements DNS ou l’IP, puis effectuer les mises à jour progressives de GitLab pour éviter les ruptures. L’auteur recommande aussi de réinstaller GitLab Runner si nécessaire et de configurer des sauvegardes automatiques régulières.
L’article souligne l’importance de suivre les versions intermédiaires lors des mises à jour pour garantir la stabilité.
Cet article explique comment configurer un "git credential helper" OAuth sur Debian et Microsoft WSL pour se connecter à GitLab, évitant ainsi de stocker des mots de passe ou des jetons d'accès personnels. Pour Debian, il utilise git-credential-oauth, tandis que pour WSL, il utilise le "Git Credential Manager" inclus avec "Git for Windows". Des instructions détaillées sont fournies pour chaque environnement, y compris la configuration pour des instances GitLab auto-hébergées.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre