Découvre les outils de pipeline as code – #4 CircleCI

par Benjamin Lallement, conseiller DevOps et membre du collectif Gologic

Objectifs de cette série

Cette série d’articles a pour but d’explorer les différents outils pour effectuer des déploiements en pipeline as code.

L’objectif de chaque article reste le même : récupérer le code source depuis GIT, compiler un projet JAVA/Spring-Boot avec Maven, lancer les tests puis déployer l’application sur AWS BeanStalk.

Ces étapes seront écrites sous forme de code dans un pipeline et exécutées avec l’outil CI/CD.

Chaque article sera divisé en plusieurs parties :

• Installation et démarrage d’un outil CI/CD
• Configuration de l’outil CI/CD (si nécessaire)
• Développement du pipeline de déploiement continu
• Vérification du déploiement
• Conclusion simple

Si vous voulez exécuter un pipeline, vous aurez besoin de :

• Runtime Docker pour exécuter les étapes du pipeline.
• Un environnement AWS BeanStalk avec clé d’accès et secret pour déployer l’application.

Avant de commencer, définissons deux concepts clés : déploiement continu et pipeline as code.

Que signifie “déploiement continu”?

Le déploiement continu est étroitement lié à l’intégration continue et fait référence à la mise en production d’un logiciel qui réussit les tests automatisés.

“Essentially, it is the practice of releasing every good build to users”, explique Jez Humble, auteur du livre Continuous Delivery.

En adoptant à la fois l’intégration continue et le déploiement continu, vous réduisez non seulement les risques et les erreurs rapidement, mais vous améliorez régulièrement les applications pour arriver à une meilleure solution.

Avec des livraisons plus rapides et régulières, vous pouvez rapidement vous adapter aux besoins de l’entreprise et aux besoins des utilisateurs. Cela permet une plus grande collaboration entre les opérations et la livraison, ce qui transforme votre processus de livraison en un avantage commercial.

Que signifie “pipeline as code”?

Les équipes font pression pour automatiser leurs environnements (tests), y compris l’infrastructure.

Le “pipeline as code” permet de définir les étapes de déploiement via du code au lieu de configurer ces étapes manuellement.

Code source

La référence de la démo est disponible dans GitHub : Continuous Deployment Demo

CircleCI

Objectif

Pour ce quatrième article, CircleCI est notre volontaire désigné.  Vous trouverez le premier, le deuxième et le troisième article en cliquant ici : #1-Jenkins, #2-Concourse, #3-GitLab.

CircleCI est un moteur d’intégration continue proposé en mode SaaS. La version 2.0 de CircleCI prend en charge les “workflows” pour simplifier l’enchaînement des étapes du pipeline. Il permet aux développeurs d’exécuter les pipelines localement avec un client cli compatible macOS et Linux.

Dans cet article, nous présentons la partie configuration d’un pipeline. La fonction pipeline de CircleCI fonctionne sous forme de descripteur en format YAML. La configuration est stockée dans le projet dans un fichier .circleci/config.yml.

CircleCI s’intègre très facilement avec un projet GitHub. Il est cependant impossible de l’utiliser avec un dépôt non accessible publiquement étant donné que l’outil est disponible en mode SaaS. Le projet GitHub est configuré dans le projet ainsi le pipeline est déclenché lors d’un changement du code source sur une branche, que ce soit un changement au niveau du contenu du source ou du pipeline lui-même.

Un pipeline CircleCI est composé principalement de “jobs” et “workflows”. Les “jobs” sont des descriptions de tâches comme une compilation, une exécution de tests, un déploiement tandis que les “workflows” définissent l’ordonnancement d’exécution des tâches. Cela rend la configuration facile à comprendre et bien structurée.

Les tâches (“step”) offrent une grande variété de configurations (checkout, restore_cache, run, store_test, persist, …). Une commande très intéressante “persist_to_workspace” permet de stocker temporairement des fichiers à travers les tâches. Ce genre de commande est souvent oublié dans les outils de CI/CD préférant stocker les fichiers dans des dépôts de données.

Les “workflows” offrent une grande possibilité de séquences par les types de déclencheur, filtres et requis.

Configurer un projet CircleCI

La configuration d’un projet CircleCI est très rapide, si votre code source est dans GitHub ou BitBucket. Premièrement connectez-vous avec votre compte GitHub ou BitBucket.

Ajoutez un nouveau projet. CircleCI découvre automatiquement vos projets dans GitHub ou BitBucket.

Sélectionnez le projet à configurer (“follow”) dans CircleCI. Si votre projet a déjà un fichier .circleci/config.yml, alors le pipeline s’exécutera aussitôt et proposera un résumé du pipeline.

Gestion des variables d’environnement

Afin de déployer l’application dans AWS, il est nécessaire d’ajouter dans les variables d’environnement du projet les configurations d’identification à AWS. Dans l’onglet “Builds”, cliquez sur l’icône “settings” du projet. Dans la section “Environment Variables”, ajoutez les clés AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY avec vos configurations à AWS.

Ces variables sont maintenant disponibles comme variable d’environnement dans l’ensemble des tâches du projet!

Maintenant que le projet est configuré, passons à l’étape de création du pipeline!

Pipeline-as-code : let’s get started

CircleCI utilise des pipelines sous forme déclarative à l’inverse des pipelines de type scripting (voir Jenkinsfile). Le format de configuration fourni par CircleCI est assez simple à comprendre et beaucoup d’exemples sont disponibles, ce qui facilite la création.

Dans les sources du projet, ouvrez le script .circleci/config.yml et étudiez le contenu :

version: 2
#
# Jobs are a collection of Steps. All of the steps in the job are executed in a single unit which consumes a CircleCI container from your plan while it’s running.
# Job: "maven-build" job test and package demo application with Maven, persist JAR in workspace and store it as Artefacts
# Job: "aws-deploy" job get binary from attached workspace and deploy to AWS
# https://circleci.com/docs/2.0/jobs-steps/
#
jobs:
  # Job to Build Maven application
  maven-build:
    
    # specify the version you desire here
    docker:
      - image: maven
      
    working_directory: ~/repo

    environment:
      # Customize the JVM maximum heap limit
      MAVEN_OPTS: -Xmx3200m
      
    steps:

      - checkout

      # Download and cache dependencies
      - restore_cache:
          key: demo-{{ checksum "pom.xml" }}
      
      - run: mvn dependency:go-offline
      
      - save_cache:
          paths:
            - ~/.m2
          key: demo-{{ checksum "pom.xml" }}
          
      # Run maven commands
      - run: mvn package
      
      # Store tests to compare builds      
      - store_test_results:
          path: target/surefire-reports
      # Store artifacts on CircleCI internal repository
      - store_artifacts:
          path: target/demo-1.0.jar
          
      # Persist the specified paths target/demo-1.0.jar) into the workspace for use in aws-deploy job. 
      - persist_to_workspace:
          # Must be an absolute path, or relative path from working_directory. This is a directory on the container which is taken to be the root directory of the workspace.
          root: ~/repo/target
          # Must be relative path from root
          paths:
            - demo-1.0.jar

  # Job to Deploy spring-boot demo application to AWS BeanStalk
  aws-deploy:
    working_directory: ~/app
    docker:
      - image: chriscamicas/awscli-awsebcli
    steps:
      - attach_workspace:
          # Must be absolute path or relative path from working_directory
          at: ~/app/target

      - run:
          name: Deploying
          command: |
            echo "$AWS_ACCESS_KEY_ID"
            eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"
            eb create circleci-env --single || true
            eb setenv SERVER_PORT=5000
            eb deploy circleci-env
            eb status
#
# Workflows: A workflow is a set of rules for defining a collection of jobs and their run order.
# In this demo, "aws-deploy" jobs is triggered only after the success of "maven-build" jobs
# see https://circleci.com/docs/2.0/workflows/
#
workflows:
  version: 2
  workflow:
    jobs:
      - maven-build
      - aws-deploy:
          requires:
            - maven-build

Dès l’ajout du fichier config.yml dans le projet, l’onglet “Builds” se met à jour et offre un sommaire des builds en cours et du statut. La vue “Workflows” est pratique pour voir l’avancement des étapes du pipeline.

Conclusion

CircleCI est hébergé en mode SAAS facilitant la maintenance et l’intégration à GitHub ou BitBucket.

Configuration structurée et simple à comprendre et à enchaîner.

Beaucoup d’intégration directement avec des outils comme Slack, JIRA ou encore AWS.

 CircleCI n’offre pas de version “On Premise” pouvant restreindre l’intégration dans des infrastructures internes aux entreprises.

 Le coût d’abonnement peut coûter cher en ajoutant des conteneurs ou du parallélisme pour exécuter les pipelines.