Explore et comprends facilement les mécaniques des différents outils de pipeline as code – #2 Concourse

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éliorer 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

Concourse

Objectif

Pour ce deuxième article, Concourse est le prochain candidat.

Concourse est un outils de pipeline écrit en Go et un moteur de CI/CD très léger.  Il fonctionne avec UI Web et des “workers”.
La spécificité de Concourse réside dans le fait que chaque tâche du pipeline est complètement isolée et doit répondre à 3 événements : GET, TASK et PUT.

Les pipelines sont basés sur les ressources et les tâches :

  • Les ressources sont utilisées pour récupérer (GET) des éléments nécessaires aux tâches et pour sauvegarder (PUT) les résultats des tâches.
  • Les tâches sont un ensemble de sous-tâches pour compléter un pipeline.

Les tâches peuvent être déclenchées à partir d’un GET, par exemple en validant dans un système de contrôle de version, par une nouvelle version d’une application dans un S3 Bucket ou Artifactory ou toute ressource disponible.

Installer et exécuter Concourse avec Docker

Démarrer Concourse avec Docker (docker-compose) en suivant les instructions officielles : http://concourse.ci/docker-repository.html

Vérifier que Concouse est disponible à l’adresse localhost : 8080 et se connecter avec les identifiants dans le docker-compose (concourse:changeme).

Installer le client FLY

L’outil Fly est un outil en ligne de commande pour s’interfacer avec Concourse. Il est nécessaire pour créer, modifier, supprimer des pipelines ou encore debugger des pipelines. Installer le binaire depuis Concourse Download section.

Se connecter à Concourse avec FLY

Premièrement, FLY a besoin de définir un “target” pour accéder à une “team” dans Concourse. Il suffit de se connecter de la manière suivante :

fly -t demo login -c http://localhost:8080 -u concourse -p changeme

Concourse fonctionne, FLY est connecté, ready to rock!

Pipeline as code : let’s get started

Concourse utilise des pipelines sous forme déclarative à l’inverse des pipelines de type scripting (voir Jenkinsfile). Ce format requiert une bonne courbe d’apprentissage.

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

# Declare Concourse resources to use as IN/OUT 
resources:  
  # 'code' resource is a GIT resource used to checkout source-code
  - name: code  
    type: git  
    source:  
      uri: https://gitlab.gologic.ca/gologic-technos/continuous-deployment.git
      branch: master
  # 'storage' resource is S3 resource to store JAR between build and deploy since Concourse do not provide any internal storage tool  
  - name: storage
    type: s3
    source:
      # Name of the bucket in S3 account
      bucket: gologic-concourse-demo-bucket
      region_name: ca-central-1
      # filename of the application to read/write in S3 (check S3 resource documentation for parameters) 
      versioned_file: demo.jar
      # AWS Credentials are passed in command line on set-pipeline. Concourse can use an external vault system too to store credentials
      access_key_id: ((AWS_ACCESS_KEY_ID))
      secret_access_key: ((AWS_SECRET_ACCESS_KEY))
jobs:  
  # First job: Package Application as a JAR and Upload to S3 Bucket for storage
  - name: Build  
    plan:  
    # Check for new commit (trigger=true), 'code' refers to GIT resource
    - get: code  
      trigger: true  
    # Package and copy application to output 'build' folder
    - task: compile  
      config:
        # Use a docker image with Maven to build application
        platform: linux
        image_resource:
          type: docker-image
          source:
            repository: maven
        # 'code' folder contains checkout code
        inputs:
          - name: code
        # 'build' folder is used to store file for next PUT step after RUN step
        outputs: 
          - name: build
        caches:
          - path: code/.m2
        # RUN step allows inline command and FILE step allow to use external task file
        run:
          path: sh
          args:
          - -c
          - |
            mvn -f code/pom.xml package -Dmaven.repo.local=code/.m2
            cp code/target/demo-1.0.jar build/demo.jar
    # Upload build/demo.jar to S3 bucket, 'storage' refers to S3 Resource
    - put: storage
      params:
        file: build/demo.jar
        name: demo.jar
  # Second job: Retrieve application from S3 Bucket and Deploy to AWS Beanstalk
  - name: Deploy
    plan:  
    # Download application from S3 bucket, 'storage' refers to S3 Resource
    - get: storage
      # Only if build job has passed
      passed:
        - Build
      trigger: true
    # Deploy to AWS using credentials 
    - task: deploy-aws  
      params:
        AWS_ACCESS_KEY_ID: ((AWS_ACCESS_KEY_ID))
        AWS_SECRET_ACCESS_KEY: ((AWS_SECRET_ACCESS_KEY))
      config:
        # Use a docker image with AWS eb-cli to init, create environment and deploy application 
        platform: linux
        image_resource:
          type: docker-image
          source:
            repository: chriscamicas/awscli-awsebcli
        inputs:
          - name: storage
        # Run a set of AWS eb commands to deploy application to AWS (Check for AWS Beanstalk logs to check for creation and deployment)
        run:
          path: sh
          args:
          - -c
          - |
            eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"
            eb create concourse-env --single
            eb deploy concourse-env
            eb status

À la différence des autres outils de CI/CD, il est nécessaire d’exécuter une commande FLY pour définir le pipeline :

Set pipeline: 
fly -t demo set-pipeline -p demo -c concourse.yml --var "AWS_ACCESS_KEY_ID=MY_AWS_ACCESS_KEY" --var "AWS_SECRET_ACCESS_KEY=MY_AWS_SECRET_KEY"

Unpause Pipeline to allow execution and triggering:
fly -t demo unpause-pipeline -p demo

Pour exécuter ce Pipeline, lancer la commande FLY suivante :

fly -t demo trigger-job -j demo/Build --watch

Le pipeline (concourse.yml) est défini. À chaque changement de code les étapes sont déclenchées pour compiler, stocker sur un “storage” AWS puis déployer sur AWS.

Malheureusement, un changement au pipeline requiert d’exécuter de nouveau la commande “set-pipeline” avec FLY car la définition du pipeline ne réside pas dans un dépôt de source mais directement dans Concourse à la différence des autres outils de CI/CD.

Conclusion

Concourse est un outil vraiment léger, qui requiert une infrastructure minimale.

Concourse nécessite très peu de click pour voir les résultats des pipelines. L’outils FLY est très utile pour interagir avec Concourse.

Concourse se concentre sur les pipelines. À l’inverse des autres outils il requiert beaucoup d’autres outils ou ressources pour faire fonctionner un pipeline, comme un espace de stockage (ex: S3 Bucket), ou encore un système de sécurité externe (ex: Vault). Pour un orchestrateur CI/CD, il est pratique d’avoir toutes ces fonctions dans un seul outil pour simplifier la maintenance.

 Les modifications dans le pipeline (concourse.yml) ne sont pas déclenchées à partir d’un commit, chaque modification doit être mise à jour avec l’outil Fly et la commande set-pipeline, ce qui mene à des modifications de pipeline non versionnées.

Concourse n’a pas de sécurité à plusieurs niveaux.

Le debug dans Concourse peut-être difficile étant donné que chaque tâche est autonome et sans espace de travail.

Suivez-nous et partagez

Laisser un commentaire