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
TravisCI
Objectif
Notre cinquième cobaye est nul autre que TravisCI. Vous trouverez les autres articles en cliquant ici : #1-Jenkins, #2-Concourse, #3-GitLab, #4-CircleCI .
Travis CI est un logiciel libre d’intégration continue. Il fournit un service en ligne utilisé pour compiler, tester et déployer le code source des logiciels développés, notamment en lien avec le service d’hébergement du code source GitHub. Un client en command-line permet d’intéragir avec le service en ligne: https://github.com/travis-ci/travis.rb.
Dans cet article, nous présentons la partie configuration d’un pipeline. La fonction pipeline de TravisCI fonctionne sous forme de descripteur en format YAML. La configuration est stockée dans le projet dans un fichier .travis.yml.
TravisCI 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, le pipeline est déclenché lors d’un changement du code source sur une branche, que ce soit un changement au niveau du contenu de la source ou du pipeline lui-même.
Un pipeline TravisCI suit un cycle de tâches pré-établies permettant de suivre des étapes claires et garder une nomenclature dans chaque pipeline. Les cycles de base sont: before_install, install, before_script, script, after_success or after_failure, after_script (voir job-lifecycle).
Il est possible d’avoir plusieurs étapes distinctes dans le pipeline en définissant des jobs, chaque job doit définir l’enchaînement des cycles. Comme dans les autres outils, il est possible de conserver le workspace d’un cycle à un autre en passant des options comme “skip_cleanup: true”, par exemple.
La quantité de langages et de plateformes de déploiement est impressionante et rend cet outil très versatile!
Configurer un projet TravisCI
La configuration d’un projet TravisCI est très rapide, si votre code source est dans GitHub. Premièrement connectez-vous avec votre compte GitHub.
TravisCI découvre automatiquement vos projets dans GitHub.
Sélectionnez le projet dans TravisCI. Si votre projet a déjà un fichier .travis.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 “More Options”, 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 variables d’environnements 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
TravisCI utilise des pipelines sous forme déclarative en YAML à l’inverse des pipelines de type scripting (voir Jenkinsfile). TravisCI utilise des modèles par langage de programmation. Par exemple, un pipeline contenant “language: java”, cherchera automatiquement à faire un build Maven, ce qui facilite grandement les configurations.
Dans l’exemple ci-dessous, le pipeline comporte deux étapes pour tester les “stages” mais il est possible d’avoir un pipeline très simple et rapidement.
Dans les sources du projet, ouvrez le script .travis.yml et étudiez le contenu :
jobs:
include:
# build-and-deploy stage
- stage: build-and-deploy
# Define a template with JAVA
language: java
# cache: Add a cache folder to improve build-speed
cache:
directories:
- $HOME/.m2
# install phase: with maven project packaging a jar is implicit
# script phase: Copy artefact to build folder to allow upload to S3 bucket
script:
- mkdir build
- cp target/demo-1.0.jar build/demo.jar
# Run a set of AWS eb commands to deploy application to AWS (Check for AWS Beanstalk logs to check for creation and deployment)
before_deploy:
- export ELASTIC_BEANSTALK_ENV=node-server-${TRAVIS_BRANCH}
- export ELASTIC_BEANSTALK_LABEL=git-$(git rev-parse --verify HEAD --short)
- export ELASTIC_BEANSTALK_DESCRIPTION=https://github.com/sumn2u/node-server/tree/$(git rev-parse HEAD)
- docker pull chriscamicas/awscli-awsebcli
- docker run -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY chriscamicas/awscli-awsebcli /bin/sh -c "eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"; eb create travisci-env --single || true; eb setenv SERVER_PORT=5000"
after_deploy:
- rm build/demo.jar
# deploy binary from s3 bucket to beanstalk
deploy:
- provider: elasticbeanstalk
access_key_id: $AWS_ACCESS_KEY_ID
secret_access_key: $AWS_SECRET_ACCESS_KEY
zip-file: "build/demo.jar"
region: "ca-central-1"
app: "continuous-deployment-demo"
env: "travisci-env"
bucket_name: "travisci-bucket"
skip_cleanup: true
only_create_app_version: false
Dès l’ajout du fichier .travis.yml dans le projet, l’onglet “Build History” détecte le changement dans GitHub et offre un sommaire des builds en cours et le statut. La vue “Current” affiche le build en cours et les logs pour voir l’avancement des étapes du pipeline.
Conclusion
TravisCI est hébergé en mode SAAS, facilitant la maintenance et l’intégration à GitHub.
La quantité de modèles par langage de programmation et de plateformes de déploiement supportée est impressionante.
Très bien intégré avec GitHub, il devient presque l’outil par défaut lorsque le projet est hébergé dans GitHub.
Le mode interactif avec le command-line est pratique pour débugger un service en ligne.
Les pipelines avec les étapes de base “build, deploy” sont simples mais des pipelines impliquant des étapes plus complexes comme des exécutions de tests peuvent s’avérer très complexes, à mettre en place.
TravisCI offre une version “On Premise” mais elle est réservée aux entreprises donc impossible à démontrer.
