Music Scores As Code

Derrière ce nom pompeux qui peut effrayer, je vais essayer d’expliquer dans cet article comment on peut versionner facilement ses partitions et les publier sur le web.

En cherchant comment mettre de la documentation technique avec des diagrammes PlantUml dans des repos GITLAB et générés avec des pipelines, je me suis mis dans la tête de faire la même chose avec des partitions 🙂

Depuis plusieurs années, j’utilise lilypond pour créer mes partitions. C’est un peu difficile de s’y mettre, mais une fois la syntaxe assimilée, la saisie d’une partition est beaucoup plus efficace. Le rendu des partitions est vraiment optimisé.
Si vous voulez plus de détails sur le pourquoi du comment je vous conseille cette page.

Vous trouverez des exemples sur le site.

J’ai donc eu l’idée de:

  • Stocker ces partitions sur un repo github (jusque là rien d’exceptionnel)
  • Générer automatiquement les partitions au format PDF, PNG et MIDI via une github action (ça commence à devenir intéressant…)
  • Les publier avec les github pages (tant qu’à faire 🙂)

Stockage

Pourquoi stocker dans un référentiel de sources tel que Github ? Pour les non informaticiens : les partitions sont stockées au format texte.

\version "2.12.1"

\header {
  title="Try a little tenderness"
  composer="Harry Woods, Jimmy Campbell & Reg Connely"
  subtitle = "Commitments Version"
  %poet = "Poete"
  instrument = "Piano"
  editor = "L'éditeur"
  %meter=\markup {\bold {"Remarque sur le rhythme"}}
  style = "Soul"
  maintainer = "Alexandre Touret"
  maintainerEmail = "alexandre.touret@free.fr"
  maintainerWeb = "http://blog.touret.info"     
  lastupdated = ""
  source = "Music room"
  footer = "Footer"
  copyright =\markup {\fontsize #-1.5
 "Delivered by A TOURET"}
}
upper=
\relative c'{
  \clef treble
  \time 4/4
  \tempo 4=176
  \key g \major
  
  d'2 (b4 e
  d2 b4 a 
  g2 g2 
  <e g,>2) <fis, c' d> 
  \bar "||"

GIT et GITHUB permettent de versionner facilement et pouvoir faire facilement un retour arrière en cas d’erreur.
Aussi, GITHUB offre des fonctionnalités « sociales » et collaboratives qui facilitent la revue des modifications ( en cas de travail à plusieurs ).
Bref, ça offre la sécurité d’une sauvegarde et la possibilité d’un retour arrière en cas d’erreur.

Générer les partitions avec une github action

Les github actions sont des outils permettant:

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

J’ai donc décidé de créer un workflow qui permet de générer les partitions au format lilypond.

J’ai mis à disposition le code sur github sous licence GNU GPLv3. Elle est utilisable telle quelle.

Pour créer l’action, il faut créer un fichier action.yml à la racine du repo. Voici le contenu

name: 'Lilypond Generator'
description: 'Run Lilypond tool with the given set of arguments to generate music sheets'
author: '@alexandre-touret'

inputs:
  args:
    description: 'Arguments for Lilyponid'
    required: true
    default: '-h'

runs:
    using: 'docker'
    image: 'Dockerfile'
    args:
      - ${{ inputs.args }}

branding:
  icon: 'underline'
  color: 'blue'

Vous aurez compris que ce fichier fait référence à une image Docker. Cette dernière n’est ni plus ni moins qu’une Debian avec lilypond d’installé.

Pour l’utiliser dans un repo github, on peut créer une action qui l’utilise. Voici un exemple:

jobs:
  build_sheets:
    runs-on: ubuntu-latest
    env:
        LILYPOND_FILES: "*.ly"
    steps:
      - name: Checkout Source 
        uses: actions/checkout@v1
      - name: Get changed files
        id: getfile
        run: |
          echo "::set-output name=files::$(find ${{github.workspace}} -name "${{ env.LILYPOND_FILES }}" -printf "%P\n" | xargs)"
      - name: LILYPOND files considered echo output
        run: |
          echo ${{ steps.getfile.outputs.files }}
      - name: Generate PDF music sheets
        uses: alexandre-touret/lilypond-github-action@master
        with:
            args: -V -f --pdf ${{ steps.getfile.outputs.files }}

A la dernière ligne on peut passer les arguments nécessaires à lilypond.

Publication

La c’est l’étape la plus facile :). Il suffit d’activer les github pages et de commiter et pusher les partitions générées

 - name: Push Local Changes
        run: |
          git config --local user.email "${{ secrets.GIT_USERNAME }}"
          git config --local user.name "${{ secrets.GIT_EMAIL }}"
          git add .
          git commit -m "Add changes" -a
      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

Il suffit de créer une page index.md à la racine et d’ajouter des liens vers les partitions générées ( dans mon cas, ça se passe dans le répertoire /docs ).
Vous pouvez trouver un exemple ici.

Conclusion

Voila comment on peut générer un site avec des partitions crées avec Lilypond.
Vous trouverez les différents liens ci-dessous. Peut être que je publierai cette action sur le marketplace une fois que j’aurai publié une documentation digne de ce nom :).

Utiliser des GITHUB Actions pour déployer dans Google Kubernetes Engine

A mes heures perdues, je travaille sur un « POC/side project qui n’aboutira pas et je m’en fiche » basé sur Quarkus. J’ ai choisi d’utiliser les langages et composants suivants :

Oui, tant qu’à faire, autant aller dans la hype …

Mon projet est sur GITHUB. Pour automatiser certaines actions et, disons-le, par fierté personnelle, j’ai choisi d’automatiser certaines actions par la mise en œuvre de pipelines CI/CD.
Depuis peu, GITHUB a intégré un mécanisme de pipeline : GITHUB Actions.

Ça permet, entre autres, de lancer des processus automatisé sur un push ou sur une action pour un commit GIT.

La force de l’outil est, selon moi, de facilement s’intégrer avec beaucoup de services du cloud ( sonarcloud, google cloud, heroku,…). On aime ou on n’aime pas, mais chez Microsoft, l’intégration ils savent faire.

Par exemple, si on veut lancer une compilation lors d’un push, on peut placer un fichier .github/workflows/build.xml avec le contenu :

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Build with Gradle without testing
        run: ./gradlew build -x test

Coté GITHUB, vous verrez l’exécution sur un écran dédié

Vous pouvez créer autant de workflows que vous souhaitez (si votre projet est en libre accès).
Pour chaque workflow, on peut définir et utiliser des jobs. Les logs d’exécution sont disponibles dans ce même écran:

Worflows implémentés

J’ai choisi d’implémenter les workflows suivants:

  • CI: Build sur la feature branch
  • CD: Build sur master branch et déploiement

On obtient donc dans mon cas:

Ce n’est pas parfait. Loin de là. Dans la « vraie vie », pour une équipe de dev, je l’améliorerai sans doute par un build docker dans les features branches, une validation formelle et bloquante de l’analyse sonar, etc.
Pour un dev perso ça suffit largement. Le contenu de la branche master est compilé et une image docker est crée pour être déployée automatiquement dans GKE.

Analyse SONAR

J’ai choisi d’utiliser sonarcloud pour analyser mon code. C’est gratuit pour les projets opensource. L’analyse se fait simplement:

  sonarCloudTrigger:
    name: SonarCloud Trigger
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: SonarCloud Scan
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        run: ./gradlew jacocoTestReport sonarqube

Dans ce job j’utilise deux secrets. Ce sont des tokens qui permettent de ne pas stocker en dur les données dans les repos GITHUB.

Création d’une image Docker et déploiement dans le registry GITHUB

Ici aussi, ça se fait simplement. La preuve :

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Build in JVM Mode with Gradle without testing
        run: ./gradlew quarkusBuild  [1]
      - name: Branch name
        run: echo running on branch ${GITHUB_REF##*/}
      - name: Build the Docker image Quarkus JVM
        run: docker build -f src/main/docker/Dockerfile.jvm -t docker.pkg.github.com/${GITHUB_REPOSITORY}/music-quote-jvm:latest .  [2]
      - name: Login against github docker repository
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: docker login -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}  docker.pkg.github.com   [3]
      - name: Publish the Docker image Quarkus JVM
        run: docker push docker.pkg.github.com/${GITHUB_REPOSITORY}/music-quote-jvm:latest  [4]
  1. Création du binaire
  2. Création de l’image docker en utilisant la commande docker et le Dockerfile fourni par Quarkus
  3. Identification sur la registry Docker de GITHUB
  4. Déploiement de l’image

Pour plus de détails sur la variable GITHUB_TOKEN, vous pouvez lire cet article de la documentation.

Déploiement dans Google Kubernetes Engine

Mon application est pour l’instant architecturée comme suit (attention c’est compliqué):

Pour la déployer dans Google Kubernetes Engine, j’ai besoin d’ implémenter cette « architecture » par les objets Kubernetes suivants:

J’utilise les objets suivants:

  • Des services pour exposer la base de données ainsi que l’application
  • Un deployment pour l’application
  • Des pods car à un moment, il en faut…
  • Un statefulset pour la base de données

Vous pourrez trouver la définition de tous ces objets au format yaml via ce lien. J’ai fait très simple. Logiquement j’aurai du créer un volume pour les bases de données ou utiliser une base de données en mode PAAS.

Pour lancer le déploiement, il faut au préalable créer un secret ( fait manuellement pour ne pas stocker d’objet yaml dans le repository GITHUB) pour se connecter au repo GITHUB via la commande suivante:

kubectl create secret docker-registry github-registry --docker-server=docker.pkg.github.com --docker-username=USER--docker-password=PASSWORD --docker-email=EMAIL

On peut faire pareil pour les connexions base de données. J’ai mis dans un configmap pour ne pas trop me prendre la tête…

Après le déploiement via le pipeline se fait assez simplement:

      [...]
      - uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
        with:
          version: '286.0.0'
          service_account_email: ${{ secrets.GKE_SA_EMAIL }}
          service_account_key: ${{ secrets.GKE_SA_KEY }}
          project_id: ${{ secrets.GKE_PROJECT }}
      # Get the GKE credentials so we can deploy to the cluster
      - run: |-
          gcloud container clusters get-credentials "${{ secrets.GKE_CLUSTER }}" --zone "${{ secrets.GKE_ZONE }}"
      # Deploy the Docker image to the GKE cluster
      - name: Deploy
        run: |-
          kubectl apply -f ./k8s     

J’utilise les « actions » fournies par Google.

Conclusion

Pour que ça marche il y a pas mal d’étapes préalables ( des tokens à générer, un utilisateur technique, …).
J’ai essayé de les référencer dans le README du projet.
Si vous voulez tester l’intégration Kubernetes dans le cloud google, sachez que vous pouvez disposer d’un crédit de 300€ valable un an. Attention, avec ce genre d’architecture, ça part vite…

Améliorer le temps de démarrage de Debian 10

Mon PC Lenovo a un SSD. Le temps de démarrage est actuellement de 11 sec. Ça commence à faire pas mal… J’ai eu donc envie de me pencher sur l’optimisation du démarrage ( encore une fois) . Voici comment gagner (facilement) quelques secondes au démarrage.

Tout d’abord, vous devez analyser les services qui prennent du temps au démarrage. Vous pouvez le faire avec cette commande:

systemd-analyze plot > plot.svg

J’ai obtenu le graphique suivant:

Configuration GRUB

La première manipulation à réaliser est de désactiver le timeout de GRUB. Pour celà, vous pouvez modifier la variable GRUB_TIMEOUT dans le fichier /etc/default/grub:

GRUB_TIMEOUT=0

Ensuite, vous devez mettre à jour la configuration GRUB en exécutant cette commande:

sudo update-grub2

Au prochain reboot, vous ne verrez plus le menu GRUB.

Configuration NetworkManager

Dans mon cas, le service NetworkManager-wait-online.service prenait près de 9 secondes. Après avoir lu plusieurs billets et rapports de bug, je me suis aperçu que je pouvais le désactiver au boot. Vous pouvez le faire en lançant la commande suivante

sudo systemctl disable NetworkManager-wait-online.service

Configuration Apt

Un autre service qui prenait pas mal de temps était apt-daily.timer qui vérifiait au boot qu’il y avait des mises à jour de l’OS. Après quelques recherches, j’ ai vu qu’on pouvait soit le désactiver ( ce qui n’est pas recommandé pour les mises à jour de sécurité ) soit décaler la recherche. J’ai choisi cette solution. Vous devez donc exécuter la commande suivante:

sudo systemctl edit apt-daily.timer

Et renseigner le contenu suivant:

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d
AccuracySec=1h
RandomizedDelaySec=30min

Ce service sera donc lancé 15 minutes après le boot. Ce qui est largement suffisant.

[EDIT] Vous pouvez appliquer la même configuration pour le service apt-daily-upgrade en exécutant la commande:

sudo systemctl edit apt-daily-upgrade.timer

Ensuite, vous pouvez recharger la configuration en exécutant cette commande:

sudo systemctl daemon-reload

Résultats

Après ces quelques manipulations qui peuvent prendre 5 minutes grand maximum, j’ai réussi à optimiser le boot en réduisant le démarrage à 5 secondes!

Vous pourrez trouver le détail ci-dessous:

Erreur 139 à l’exécution d’un container docker

Voici un rapide article sur un problème rencontré récemment. Lors de l’exécution d’un container docker, j’ai eu une erreur SIGSEGV 139. Un crash avec aucune log.

Bref que du bonheur 🙂



Avant d’aller plus loin voici mon environnement:

Après quelques recherches, je me suis rendu compte qu’on pouvait reproduire ce comportement en exécutant cette commande:

docker run -it gcc:4.8.5

Une des raisons trouvées serait un problème de compatibilité avec le noyau 4.8.5 (oui ça remonte…).
Une solution est d’activer l’émulation vsyscall.


Voici la configuration à effectuer:
Dans le fichier /etc/default/grub, ajouter la ligne suivante:

GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"

Puis lancer les commandes suivantes:

$ sudo update-grub 
$ sudo reboot

Maintenant le container devrait pouvoir s’exécuter correctement.

Premiers pas avec Gradle

Depuis quelques temps je me mets à Gradle. Après de (trop?) nombreuses années à utiliser Maven (depuis la version 0.9…), je me risque à modifier mon environnement de build. Du moins sur des projets démo.

Quand on a fait pas mal de Maven, on est un peu dérouté au début. On a d’un coté, la plupart des actions qui sont configurées de manière implicite et de l’autre on peut tout coder/étendre ou presque.

Je ne vais pas me risquer à faire un comparatif des deux outils. Gradle ( donc fortement orienté ) en a fait un.

Je vais plutôt décrire avec cet article comment on peut démarrer rapidement en configurant son environnement pour être utilisé en entreprise.

Installation

Le plus simple est d’utiliser SDKMAN.

Voici la manipulation pour l’installer:

$ curl -s "https://get.sdkman.io" | bash
$ source "$HOME/.sdkman/bin/sdkman-init.sh"
$ sdk install gradle 6.0.1

Configuration d’un proxy

Et oui comment souvent, passer le proxy d’entreprise est la moitié du boulot :).
Pour le configurer de manière globale (c.-à-d. pour tous vos projets) sur votre poste de travail, vous devez créer un fichier gradle.properties dans le répertoire $HOME/.gradle :

systemProp.http.proxyHost=proxy
systemProp.http.proxyPort=8888
systemProp.http.nonProxyHosts=localhost|127.0.0.1
systemProp.https.proxyHost=proxy
systemProp.https.proxyPort=8888
systemProp.https.nonProxyHosts=localhost|127.0.0.1

Configuration d’un miroir Nexus ou Artifactory

A l’instar du proxy, on va essayer de mettre en place une configuration globale. Pour ce faire, on va utiliser les init scripts. Cette fonctionnalité est très intéressante. Elle permet de centraliser des actions et configurations.
Pour créer un script, il faut tout d’abord créer un fichier .gradle dans le répertoire $HOME/.gradle/init.d.

Voici un exemple pour Nexus:

allprojects { 
  buildscript { 
    repositories {
      mavenLocal() 
      maven {url "https://url-nexus"} 
    }
  }
  repositories { 
    mavenLocal()
    maven { url "https://url-nexus"}
  }
}

Configuration du déploiement dans Nexus / Artifactory

Le déploiement dans Nexus est possible via le plugin maven publish. La configuration fournie dans la documentation est tellement bien faite ( comme le reste d’ailleurs ) que je ne vais que mettre un lien vers celle-là:
Voici le lien.

Conclusion

Après ces quelques actions vous pourrez démarrer des builds avec gradle tout en étant compatible avec un environnement « Maven ».
Enjoy 🙂

Partager des variables entre scénarios gatling

Je suis en train de mettre en œuvre des tests de performance avec Gatling. Un des principaux outils libres de tests de performance.

J’ai eu récemment à résoudre un « petit » soucis : je souhaitai partager des variables entre plusieurs scénarios. Il existe pas mal de solutions sur stackoverflow. J’ai condensé certaines d’entre elles pour les adapter à mon besoin.
Ces variables sont issues de exécution d’une seule requête et sont automatiquement injectées dans les scénarios suivants. Ce mécanisme permet par exemple de récupérer un jeton d’un serveur d’identification et de l’injecter pour le scénario que l’on souhaite tester.

Pour ce faire, il faut ajouter une variable de type LinkedBlockingDeque et injecter le contenu choisi via la session

 val holder = new LinkedBlockingDeque[String]() 
...
val firstScenario = scenario("First Simulation")
		.exec(http("first scenario")
			.post("/base/url1")
			.check(jsonPath("$.my_variable").find.saveAs("variable")))
		.exec(session => {
            holder.offerLast(session("variable").as[String])
            session}       
        );

Maintenant on peut l’utiliser dans un autre scénario comme feeder:

val secondScenario = scenario("Second Simulation")
		.feed(sharedDataFeeder)

Voici l’exemple complet

class RecordedSimulation extends Simulation {
val httpProtocol = http
.baseUrl("https://mabaseurl")
.inferHtmlResources()
.acceptHeader("*/*")
.acceptEncodingHeader("gzip, deflate")
.connectionHeader("close")
.userAgentHeader("PostmanRuntime/7.17.1")
/* randomized data information */
var feeder = Iterator.continually(Map("somedata" -> (Random.alphanumeric.take(20).mkString)))
/* ------------------------------------- */
val holder = new LinkedBlockingDeque[String]()
/* Enables to store and fetch the oauth access token */
var sharedDataFeeder= Iterator.continually(Map("variable" -> holder.takeFirst()))
/* ------------------------------------- */
val firstScenario = scenario("First Simulation")
.exec(http("first scenario")
.post("/base/url1")
.check(jsonPath("$.my_variable").find.saveAs("variable")))
.exec(session => {
holder.offerLast(session("variable").as[String])
session}
);
val secondScenario = scenario("Second Simulation")
.feed(feeder)
.feed(sharedDataFeeder)
.repeat(1){
exec(http("url1")
.post("/url1")
.headers(Map("my_header" -> "Bearer ${variable}","Content-Type" -> "application/json"))
.body(ElFileBody("recordedsimulation/anonymized_data.json")));
}
setUp(firstScenario.inject(atOnceUsers(1)),secondScenario.inject(constantConcurrentUsers(10) during (10 minutes),
rampConcurrentUsers(10) to (20) during (10 minutes))
.protocols(httpProtocol));
}


En espérant que cela puisse aider à certain.e.s d’entre vous 🙂

Programmmation par aspect avec Spring AOP

Une fois n’est pas coutume, voici un article qui reprend des basiques de la programmation. J’aborde une stack JAVA, mais c’est applicable à d’autres langages.

Il existe une fonctionnalité très intéressante dans Spring (et dans J(akarta)EE) que l’on oublie assez souvent : l’AOP ou encore la programmation par aspect. Cette manière de programmer permet notamment de séparer le code fonctionnel et technique.
Si vous faites du JAVA, vous utilisez déjà l’AOP. En effet, quand vous faites une insertion en base via JPA dans un EJB ou un bean annoté @Transactional, une transaction est initiée au début de la méthode et fermée à la fin.

Avec Spring et notamment dans Spring boot, voici comment initier l’AOP.

Configuration maven

Ajouter le starter AOP:

 <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

Activation des aspects

Dans la configuration ci-dessous, je prendrai comme exemple le logging des méthodes ( un log en début de méthode et un log en fin ). 

La définition des aspects se fait dans des classes annotées par @Configuration.

@Configuration
@Aspect
@ConditionalOnProperty(name = "debug.enabled", havingValue = "true")
public class DebuggingConfiguration {

private static final Logger LOGGER = LoggerFactory.getLogger(DebuggingConfiguration.class);
private static final String WITHIN_MY_PACKAGE = "within(my.package..*)";

/**
* Log before execution
*
* @param joinPoint the current method
*/
@Before(WITHIN_MY_PACKAGE)
public void logBeforeExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("Beginning of method : [{}]", joinPoint.getSignature().getName());
}
}

/**
* Log after execution
*
* @param joinPoint the current method
*/
@After(WITHIN_MY_PACKAGE)
public void logAfterExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("End of method : [{}]", joinPoint.getSignature().getName());
}
}
}

L’utilisation de l’ annotation @ConditionalOnProperty me permet d’activer cette classe de configuration seulement si la propriété debug.enabled est initialisée à true.

Les annotations @Before et @After indiquent à Spring AOP quand exécuter ces méthodes ou sur quelles méthodes. Dans mon cas, quand les méthodes appelées sont définies dans les classes d’un package défini.

Pour plus de détails sur la syntaxe et les possibilités, vous pouvez vous référer à la documentation.


Mocker des méthodes « final » avec Mockito

Auparavant, dans nos tests, quand on voulait mocker des méthodes « final » ou statiques, on devait passer par PowerMock.

Depuis peu, si on utilise Mockito ( >2.1) , on n’a plus besoin d’ajouter PowerMock pour mocker des méthodes « final ».

Bon il reste toujours la gestion des méthodes statiques à gérer autrement qu’avec Mockito, mais cela va dans le bon sens.

Voici comment activer en quelques commandes le mocking des méthodes « final ».

Dans le répertoire src/test/resources, il faut créer un répertoire mockito-extensions avec un fichier nommé org.mockito.plugins.MockMaker.

src/test/resources
└── mockito-extensions
└── org.mockito.plugins.MockMaker

A l’intérieur de ce fichier, vous devrez ajouter le contenu suivant :

mock-maker-inline

Avec cette configuration, vous pourrez dorénavant mocker des méthodes « final » 🙂

Enjoy

Vérifier les commit GIT avec GPG

Juste pour un pense bête, voici comment paramétrer GIT et GITHUB/GITLAB pour signer les commits avec GPG.

Configuration GPG

Exécutez la commande suivante :

gpg --full-generate-key

Sélectionnez une clé RSA (question 1) de 4096 bits (question 2).

Une fois cette commande effectuée, vous pouvez récupérer votre clé GPG avec cette commande:

gpg –list-secret-keys –keyid-format LONG

gpg --list-secret-keys --keyid-format LONG alexandre@....
/home/alexandre/.gnupg/pubring.kbx
----------------------------------
sec rsa4096/XXXXXXXXXX 2019-08-09 [SC]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid [ ultime ] Alexandre Touret <mon.mail.github.ou.gitlab@monprovider.fr>
ssb rsa4096/XXXXXXXXXX 2019-08-09 [E]

Ensuite, il faut exécuter cette commande

gpg --armor --export XXXXXXXXXX

Configuration GIT

Indiquez la clé GPG à GIT

 git config --local user.signingkey 6F9D7D5FCE959337

Et indiquez que vous voulez signer tous vos commits

git config --local commit.gpgsign true

Si vous ne faites pas cette dernière commande, vous devrez ajouter l’option -S à chaque exécution de la commande git commit.

Exemple:

 git -a -S -m "Ajout javadoc"

Configuration GITHUB

Sur Github ( il y a la même chose sur gitlab), vous pouvez dans vos paramètres ajouter cette clé . De cette manière, vos prochains commits envoyés seront vérifiés.

 En espérant que ça serve à d’autres 🙂

Ansible pour les provisionner tous !

Si vous provisionnez vos VM VirtualBox avec Vagrant, vous avez sans doute eu l’idée d’automatiser le provisionning des machines virtuelles. Dans mon cas une VM GNU/Linux basée sur Debian 9.

Pour cela, soit vous faite tout manuellement et après les mises à jour deviennent fastidieuses, soit vous appliquez un script shell au démarrage de vagrant, soit vous utilisez Ansible.

Ansible est un outil opensource permettant d’automatiser le provisionning et la mise à jour des environnements à distance (via SSH). L’avantage par rapport à des outils tels que Puppet, est qu’il ne nécessite pas l’installation d’agent.

Je vais essayer de vous montrer comment mettre en place le provisionning via Ansible pour VirtualBox.

Configuration de Vagrant

Dans le fichier Vagrantfile, on active le provisionning via Ansible:

config.vm.provision "ansible_local" do |ansible|
ansible.playbook = "site.yml"
ansible.install_mode = "pip"
ansible.version = "2.7.10"
end

Cette configuration fait référence à un fichier « playbook » site.yml. C’est la configuration qui sera appliqué lors du provisionning . Que ça soit à la création ou pour les mises à jour.

Voici un exemple de contenu:

- name: VirtualBox
hosts: all
become: yes
become_user: "root"
become_method: "sudo"
roles:
- common
vars_files:
- vars/environment.yml

Ce fichier est la racine de notre configuration Ansible. On y référence les rôles appliqués et les fichiers d’ environnement. Voici un exemple de rôle:

- name: "Remove useless packages from the cache"
apt:
autoclean: yes
force_apt_get: yes

- name: "Remove dependencies that are no longer required"
apt:
autoremove: yes
force_apt_get: yes

- name: "Update and upgrade apt packages (may take a while)"
become: true
apt:
upgrade: dist
update_cache: yes
force_apt_get: yes

- name: "Install useful packages"
become: true
apt:
name:
- gcc
- g++
...
- zsh
- firewalld
state: present
update_cache: no

- name: ansible create directory example
file:
path: "{{ home }}/.m2"
state: directory
owner: "{{ username }}"
group: "{{ username }}"

- name: Install Maven settings.xml
copy:
src: settings.xml
dest: "{{ home }}/.m2/settings.xml"
owner: "{{ username }}"
group: "{{ username }}"

- name: "Install Maven"
raw: "curl -sL \"http://mirror.ibcp.fr/pub/apache/maven/maven-3/{{ maven_version }}/binaries/apache-maven-{{ maven_version }}-bin.tar.gz\" -o /opt/apache-maven.tar.gz && tar -zxf /opt/apache-maven.tar.gz -C /opt"
become: true
become_user: root
become_method: sudo

- name: "Change Maven Rights"
file:
path: /opt/*
state: touch
modification_time: "preserve"
access_time: "preserve"
owner: "{{ username }}"
group: "{{ username }}"

Les variables d’environnement permettent de variabiliser certains champs de vos rôles. On peut trouver par exemple les versions de certains outils déployés

maven_version: 3.5.4
username: vagrant
home: /home/vagrant
docker_compose_version: 1.22.0

Il y a une quantité impressionnante de modules Ansible que l’on peut utiliser. Que ça soit pour lancer des commandes shell ou lancer des services. Contrairement à la création d’un script shell qui pourrait faire les mêmes actions à la création, on peut facilement gérer la mise à jour de la VM car Ansible détecte les modifications lors de son exécution.

Configuration spécifique pour VirtualBox

Pour VirtualBox, j’ai ajouté deux fichiers de configuration supplémentaires à la racine:

ansible.cfg
[defaults]
hostfile = hosts
hosts
[local]
localhost ansible_connection=local

Provisionning

A la création

le provisionning peut se faire au lancement de vagrant via la commande:

vagrant up

Pour faire une mise à jour

Directement dans la box, vous pouvez lancer les commandes suivantes :

sudo mount -t vboxsf vagrant /vagrant

Puis, vous pouvez lancer les commandes suivantes dans la box:

su -
cd /vagrant
export ANSIBLE_CONFIG=/vagrant
ansible-playbook site.yml