Rendre les journaux Jenkins jolis | Opensource.com

  • FrançaisFrançais



  • Jenkins est un serveur d’automatisation gratuit et open source pour la création, le test et le déploiement de code. C’est l’épine dorsale de l’intégration continue et de la livraison continue (CI / CD) et peut faire gagner des heures aux développeurs chaque jour et les protéger de la mise en ligne d’un code défaillant. Lorsque le code échoue, ou lorsqu’un développeur a besoin de voir la sortie des tests, Jenkins fournit des fichiers journaux pour examen.

    Les journaux de pipeline Jenkins par défaut peuvent être difficiles à lire. Ce bref résumé des bases de la journalisation Jenkins offre quelques astuces (et code) sur la façon de les rendre plus lisibles.

    Ce que vous obtenez

    Les pipelines Jenkins sont divisés en étapes. Jenkins enregistre automatiquement le début de chaque étape, comme ceci:

    [Pipeline] // stage
    [Pipeline] stage (hide)
    [Pipeline] { (Apply all openshift resources)
    [Pipeline] dir

    Le texte est affiché sans beaucoup de contraste et les éléments importants (comme le début d’une étape) ne sont pas mis en évidence. Dans un journal de pipeline de plusieurs centaines de lignes, trouver où une étape commence et où une autre se termine, surtout si vous parcourez les journaux à la recherche d’une étape particulière, peut être intimidant.

    Les pipelines Jenkins sont écrits comme un mélange de scripts Groovy et shell. Dans le code Groovy, la journalisation est clairsemée; souvent, il se compose de texte grisé dans la commande sans détails. Dans les scripts shell, le mode débogage (set -x) est activée, de sorte que chaque commande du shell est entièrement réalisée (les variables sont déréférencées et les valeurs sont imprimées) et consignées en détail, tout comme la sortie.

    Il peut être fastidieux de lire les journaux pour obtenir des informations pertinentes, étant donné qu’il peut y en avoir tellement. Étant donné que les journaux Groovy qui continuent et suivent un script shell dans un pipeline ne sont pas très expressifs, ils manquent souvent de contexte:

    [Pipeline] dir
    Running in /home/jenkins/agent/workspace/devop-master/devops-server-pipeline/my-repo-dir/src
    [Pipeline] { (hide)
    [Pipeline] findFiles
    [Pipeline] findFiles
    [Pipeline] readYaml
    [Pipeline] }

    Je peux voir dans quel répertoire je travaille et je sais que je cherchais des fichiers et lisais un fichier YAML en suivant les étapes de Jenkins. Mais qu’est-ce que je cherchais et qu’ai-je trouvé et lu?

    Ce qui peut être fait?

    Je suis heureux que vous ayez posé la question, car il existe quelques pratiques simples et quelques petits extraits de code qui peuvent vous aider. Tout d’abord, le code:

    def echoBanner(def ... msgs) {
       echo createBanner(msgs)
    }

    def errorBanner(def ... msgs) {
       error(createBanner(msgs))
    }

    def createBanner(def ... msgs) {
       return """
           ===========================================

           ${msgFlatten(null, msgs).join("n        ")}

           ===========================================
       """
    }

    // flatten function hack included in case Jenkins security
    // is set to preclude calling Groovy flatten() static method
    // NOTE: works well on all nested collections except a Map
    def msgFlatten(def list, def msgs) {
       list = list ?: []
       if (!(msgs instanceof String) && !(msgs instanceof GString)) {
           msgs.each { msg ->
               list = msgFlatten(list, msg)
           }
       }
       else {
           list += msgs
       }

       return  list
    }

    Ajoutez ce code à la fin de chaque pipeline ou, pour être plus efficace, charger un fichier Groovy ou faites-en partie Bibliothèque partagée Jenkins.

    Au début de chaque étape (ou à des points particuliers d’une étape), appelez simplement echoBanner:

    echoBanner("MY STAGE", ["DOING SOMETHING 1", "DOING SOMETHING 2"])

    Vos journaux dans Jenkins afficheront les éléments suivants:

        ===========================================

        MY STAGE
        DOING SOMETHING 1
        DOING SOMETHING 2

        ===========================================

    Les bannières sont très faciles à repérer dans les journaux. Ils aident également à définir le flux du pipeline lorsqu’ils sont utilisés correctement, et ils cassent les journaux bien pour la lecture.

    J’utilise ceci depuis un moment maintenant professionnellement dans quelques endroits. Les commentaires ont été très positifs pour ce qui est d’aider à rendre les journaux de pipeline plus lisibles et le flux plus compréhensible.

    le errorBanner La méthode ci-dessus fonctionne de la même manière, mais le script échoue immédiatement. Cela permet de mettre en évidence où et ce qui a causé l’échec.

    Les meilleures pratiques

    1. Utiliser echo Jenkins avance libéralement tout au long de votre code Groovy pour informer l’utilisateur de ce que vous faites. Ceux-ci peuvent également vous aider à documenter votre code.
    2. Utilisez des instructions de journal vides (une étape d’écho vide dans Groovy, echo '', ou juste echo dans le shell) pour diviser la sortie pour une meilleure lisibilité. Vous utilisez probablement des lignes vides dans votre code dans le même but.
    3. Évitez le piège de l’utilisation set +x dans vos scripts, qui masque la journalisation des instructions shell exécutées. Cela ne nettoie pas tant vos journaux que cela fait de vos pipelines une boîte noire qui cache ce que fait votre pipeline et toutes les erreurs qui apparaissent. Assurez-vous que la fonctionnalité de vos pipelines est aussi transparente que possible.
    4. Si votre pipeline crée des artefacts intermédiaires que les développeurs et / ou le personnel DevOps pourraient utiliser pour aider à déboguer les problèmes, consignez également leur contenu. Oui, cela rallonge les journaux, mais ce n’est que du texte. Ce sera des informations utiles à un moment donné, et qu’est-ce qu’un journal (s’il est utilisé correctement) qu’une mine d’informations sur ce qui s’est passé et pourquoi?

    Secrets Kubernetes: là où la transparence totale ne fonctionnera pas

    Il y a des choses que vous ne veulent se retrouver dans vos journaux et être exposés. Si vous utilisez Kubernetes et que vous faites référence à des données conservées dans un secret Kubernetes, vous ne voulez certainement pas que ces données soient exposées dans un journal, car les données ne sont que masquées et non chiffrées.

    Imaginez que vous souhaitiez prendre des données contenues dans un secret et les injecter dans un fichier JSON basé sur un modèle. (Le contenu complet du modèle Secret et JSON n’est pas pertinent pour cet exemple.) Vous voulez être transparent et consigner ce que vous faites car c’est la meilleure pratique, mais vous ne voulez pas exposer vos données secrètes.

    Changez le mode de votre script depuis le débogage (set -x) à la journalisation des commandes (set -v). À la fin de la partie sensible du script, réinitialisez le shell en mode de débogage:

    sh """
       # change script mode from debugging to command logging
       set +x -v

       # capture data from secret in shell variable
       MY_SECRET=$(kubectl get secret my-secret --no-headers -o 'custom-column=:.data.my-secret-data')

       # replace template placeholder inline
       sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json

       # do something with modified template-file.json...

       # reset the shell to debugging mode
       set -x +v
    "

    ""

    Cela affichera cette ligne dans les journaux:

    sed s/%TEMPLATE_PARAM%/${MY_SECRET_DATA}/ my-template-file.json

    Cela ne réalise pas la variable shell MY_SECRET_DATA, contrairement au mode de débogage du shell. De toute évidence, ce n’est pas aussi utile que le mode débogage si un problème survient à ce stade du pipeline et que vous essayez de comprendre ce qui n’a pas fonctionné. Mais c’est le meilleur équilibre entre la transparence de l’exécution de votre pipeline pour les développeurs et les DevOps, tout en gardant vos secrets cachés.

    Source

    N'oubliez pas de voter pour cet article !
    1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
    Loading...

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée.