Developpement sur Olivier DOSSMANN

Ce que j'aurais voulu savoir sur Gitlab CI

Sun, 18 May 2025 13:55:39 +0200

Introduction

Il y a quelques mois je parlais de ma formation Bootcamp pour devenir Ingénieur DevOps. J’y ai utilisé - à nouveau - Gitlab CI (Continuous Integration). Vous savez, cet outil permettant d’exécuter des actions après avoir envoyé votre code/dépôt sur la plateforme Gitlab ?

C’est très utile, par exemple pour lancer les tests sur votre code, vérifier que le code s’exécute dans un environnement précis ou tout simplement vérifier que le code compile. Et si votre dépôt n’est pas du code, par exemple un site web, vous pouvez tester les liens morts ; voire publier votre site ! Les possibilités sont - finalement - nombreuses !

En revanche, un tel outil est parfois déstabilisant. Et des cheveux, j’en ai arrachés ! J’aurais apprécié tomber sur un article explicatif. Avec des astuces. Peut-être que le présent article m’aurait convenu, qui sait !

J’aurai par exemple aimé savoir comment publier facilement un site web, tester localement le fichier .gitlab-ci.yml avant de l’envoyer sur Gitlab, connaître plus d’astuces pour les mots clés Gitlab, savoir utiliser Docker dans Gitlab CI et ce que sont les composants réutilisables.

Ce sont ainsi tous les sujets que nous allons aborder aujourd’hui.

Photo trouvée sur le profil de didier.camus sur Flickr sous Licence Œuvre du domaine public.

Publier rapidement un site statique

Gitlab met à disposition des utilisateurs un espace permettant d’héberger des sites webs statiques. Incroyable n’est-ce pas ? Cet espace est Gitlab Pages.

Comment cela fonctionne ? Il suffit de créer un dépôt Gitlab, d’ajouter un fichier .gitlab-ci.yml contenant la section suivante :

image: busybox

pages:
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Code récupéré du projet https://gitlab.com/pages/plain-html.

Cela signifie qu’au terme de la CI/CD (dans l’étape nommée deploy), le contenu du dossier public sera publié sur Gitlab Pages. À quelle adresse ? Imaginons que vous partez d’un dépôt dont l’adresse est : https://gitlab.com/blankoworld/monprojet/, l’adresse URL d’accès à votre site publié sera : https://blankoworld.gitlab.io/monprojet/. Pratique non ?

Astuce : Si votre dépôt est privé, vous pouvez quand même rendre votre site public. Il suffit d’aller dans Settings > General, Section « Visibility, project features, permissions » et dans le sous-titre « Pages », activez la fonctionnalité. Et dans le menu déroulant à côté, choisissez « Everyone ». N’oubliez pas de sauvegarder cette configuration. Le code sera privé, le site web statique public !

Pour plus d’exemple, veuillez vous rendre sur la page Gitlab présentant la liste de projets utilisant Gitlab Pages.

Tester avant d’envoyer sur le dépôt ?

Le truc vraiment embêtant avec les fichiers .gitlab-ci.yml, c’est qu’on ne peut pas les tester sur notre machine (localement). Pour avancer il faut :

modifier le fichier .gitlab-ci.yml,
le valider (faire un commit),
l’envoyer sur Gitlab,
patienter que la pipeline se lance (et parfois se termine),
bénéficier du résultat ou, dans la plupart des cas, recommencer à l’étape 1…

À une époque on pouvait utiliser une commande gitlab-runner exec en local. Mais celle-ci a été supprimée : https://gitlab.com/gitlab-org/gitlab-runner/-/commit/f8508c924f80b104ec7353353e6ad0edb5daae66 .

Suivant ce que nous faisons dans la CI/CD de Gitlab, il est possible d’utiliser un outil bien pratique nommé gitlab-ci-local : gitlab-ci-local.

Vous trouverez quelques détails de gitlab-ci-local sur mon recueil d’astuces.

Généralités

Voici quelques pistes intéressantes sur le sujet Gitlab :

Une documentation de départ est : https://docs.gitlab.com/topics/build_your_application/. Elle permet d’en savoir plus sur la syntaxe de gitlab-ci.yaml, les variables pré-définies ou encore le fonctionnement d’un pipeline dans Gitlab CI,
Toujours utiles : les actions que je nomme comme « globales ». Par exemple les mots clés image, variables ou before_script peuvent être utilisés en début du fichier pour définir des actions ou des valeurs qui seront utilisées dans toutes les étapes du pipeline. Ce qui peut être un avantage, ou un inconvénient. Exemple : image: ubuntu:latest va définir que toutes les étapes se lanceront dans un docker partant de l’image Ubuntu,
Entrées/sorties : un artefact = une sortie. C’est à dire des fichiers utilisables/disponibles pour les étapes suivantes (donc en entrée pour les autres étapes) en utilisant le mot clé dependencies (Cf. https://docs.gitlab.com/ci/jobs/job_artifacts/#fetching-artifacts). Sauf si dependencies = [] est utilisé.
Utiliser des variables globales en début du fichier (par exemple pour les numéros de versions) fait gagner du temps sur le long terme. Exemple :

variables:
  DOCKER_VERSION: "27.3.1"
  UBUNTU_VERSION: "24.04"

Concernant le mot clé script :
- si on veut écrire plusieurs lignes, utiliser la syntaxe suivante :
```
script:
  - echo "première étape des scripts"
  - |
    echo "première ligne"
    echo "seconde ligne"
    echo "etc."
```
- limiter à 10 lignes maximum,
- si on utilise la syntaxe pour écrire plusieurs lignes, le debug est plus difficile
Pour organiser les étapes, on peut donner à chacune d’elle une étape pré-requise en utilisant le mot clé « needs », cela permet de chaîner les étapes dans un certain ordre. Exemple : si on veut que l’étape « deploy » se fasse après « compile », alors à la fin de l’étape « deploy » on met needs: [compile].

Le Cas Docker

Création d’une image Docker… dans un conteneur Docker

Dans la situation où vous voudriez fabriquer des images Docker, vous allez être confrontés à plusieurs problématiques :

il faut utiliser des commandes docker pour créer des images,
mais la plupart des Gitlab Runner exécutent les étapes de Gitlab CI dans un Docker,
donc on se retrouve à vouloir exécuter des commandes docker dans un environnement Docker.

Vous voyez le problème ?

Pour contourner cette situation il suffit d’utiliser Docker-in-Docker.

En somme le début du fichier .gitlab-ci.yml ressemblera à :

variables:
  DOCKER_VERSION: "27.4.1"

image: docker:$DOCKER_VERSION

services:
  - docker:$DOCKER_VERSION-dind

S’identifier

Pour utiliser les dépôts de conteneurs de Gitlab, rien de plus simple il suffit d’écrire le code suivant dans le fichier .gitlab-ci.yml :

before_script:
  - docker info
  - echo "$CI_REGISTRY_PASSWORD" | docker login $CI_REGISTRY -u $CI_REGISTRY_USER --password-stdin

Nul besoin de renseigner les variables. Elles sont renseignées par Gitlab CI.

Construire l’image

Pour construire l’image cela va ressembler à :

variables:
  CONTAINER_TEST_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

build-image:
  stage: build
  script:
    - docker pull "$CONTAINER_TEST_IMAGE" || true
    - docker build --build-arg BUILDKIT_INLINE_CACHE=1 -t $CONTAINER_TEST_IMAGE .
    - docker push $CONTAINER_TEST_IMAGE

On part du principe que le fichier Dockerfile est situé à la racine de votre projet Gitlab.

CONTAINER_TEST_IMAGE est une variable globale construite à partir des variables pré-définies de Gitlab CI.

Pousser l’image sur le dépôt

Dans cette situation nous sommes contents d’avoir déjà ajouté l’authentification aux dépôts de conteneurs Gitlab.

Cette fois on fait une étape pour récupérer l’image précédente et lui donner un nouveau nom :

push-image:
  stage: push
  script:
    - export IMAGE_TAG="$(date +'%Y%m%d')-${CI_COMMIT_SHORT_SHA}"
    - docker pull $CONTAINER_TEST_IMAGE
    - docker tag $CONTAINER_TEST_IMAGE $CI_REGISTRY_IMAGE:$IMAGE_TAG
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

L’idée est :

de créer un nom de tag pour l’image (variable IMAGE_TAG),
récupérer l’image précédente - puisque les étapes d’un fichier .gitlab-ci.yml s’exécutent dans des conteneurs isolés les uns des autres,
apposer un nouveau tag sur l’image récupérée,
publier le résultat en poussant l’image ainsi étiquetée.

Ceci ne s’exécute que si la branche est nommée main. Donc chaque commit sur cette branche générera une image Docker et un tag.

Ordre d’exécution des étapes

Afin que les deux étapes précédentes s’exécutent dans un certain ordre, ne pas oublier les lignes suivantes dans le fichier .gitlab-ci.yml :

stages:
  - build
  - push

Comme si ça ne suffisait pas…

En outre, voici d’autres éléments à rajouter dans son fichier .gitlab-ci.yml :

variables:
  # Use TLS https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
  DOCKER_HOST: tcp://docker:2376
  DOCKER_TLS_CERTDIR: "/certs"

Ces lignes permettent de renseigner un autre accès à l’API Docker pour lancer les commandes docker.

Les composants réutilisables

Gitlab CI offre la possibilité d’utiliser des composants réutilisables pour agrémenter les étapes de son fichier .gitlab-ci.yml. Ceci évite de réinventer la roue (en codant soi-même).

Plusieurs composants sont disponibles sur la page Gitlab components.

Exemple d’utilisation d’un composant :

include:
  - component: gitlab.com/components/container-scanning/container-scanning@5.1.0

C’est très utile dans certaines situations comme pour tester des fichiers Terraform (avec le composant OpenTofu), le composant Go, le composant Rust ou même utiliser les fonctionnalités Autodevops de Gitlab.

Conclusion

Au premier abord Gitlab CI paraît complexe et maigre en fonctionnalités. Cependant la lecture de la documentation (très fournie !) donne rapidement un aperçu bien plus avantageux de cet outil. On y découvre les composants réutilisables, les mots clés image, variables, before_script, les artefacts (sorties), les variables globales, le déploiement de sites statiques et j’en passe !

Certaines difficultés telles que Docker viennent s’immiscer dans nos essais. Mais une fois les obstacles franchis c’est un outil très satisfaisant. Je l’apprécie.

Je serais ravi de tomber plus souvent sur des articles décrivant ses fonctionnalités. J’espère participer à une diffusion plus grande de la connaissance Gitlab CI et, qui sait, peut-être partagerais-je prochainement d’autres astuces ?

Cookiecutter-trognon pour initialiser mes scripts Bash

Sun, 28 Apr 2024 13:20:47 +0200

Introduction

Pour la petite histoire, l’année dernière je lisais l’article de deblan sur la création d’un modèle de script Shell sur le journalduhacker. Cela m’a rappelé que tôt ou tard dans la quête de l’automatisation on arrive toujours à faire nos propres modèles de scripts.

La plupart de mes projets utilisent le modèle de script Trognon.

Comment, en partant de ce modèle, pourrais-je automatiser la création de nouvelles commandes ? C’est là qu’entre en jeu cookiecutter, une commande et une méthode permettant de transformer n’importe lequel de vos projet en template pour les suivants !

Nous commencerons par voir le résultat de l’adaptation d’un script avec cookiecutter. Ensuite nous verrons ce qu’est cookiecutter. Finalement nous expliquerons comment adapter son projet avec cookiecutter en présentant le cas pratique de cookiecutter-trognon.

Photo trouvée sur le profil de Alan Levine sur Flickr sous Domaine public.

Le résultat : cookiecutter-trognon

Pour une fois nous commencerons par la fin, c’est à dire le résultat ! L’automatisation de Trognon a donné un dépôt : cookiecutter-trognon.

Grâce à lui, créer un nouveau script Bash suivant le modèle de Trognon revient à taper les commandes suivantes :

# Installe cookiecutter sur notre machine (à ne faire que la première fois)
pipx install cookiecutter
# Utilise mon dépôt Github de cookiecutter-trognon comme modèle
cookiecutter gh:blankoworld/cookiecutter-trognon

Ensuite 2 questions sont posées pour définir :

le nom du dossier dans lequel ma commande se trouvera
le nom souhaité pour la commande

Évidemment j’ai défini les questions à poser et ce que je faisais des réponses dans le résultat. C’est là tout l’intérêt de cookiecutter : vous définissez les questions à poser, les réponses possibles s’il en est, quoi faire des réponses et où les utiliser dans vos templates.

Voyons donc cookiecutter.

Présentation de cookiecutter

cookiecutter est un outil Python qui duplique un répertoire, vous pose des questions et modifie le duplicat en remplaçant certaines chaînes de caractères par les réponses données aux questions.

Il sait agir de manière conditionnelle : c’est-à-dire qu’il peut aussi ajouter/enlever des pans de code/texte en fonction de la valeur d’une variable. Ceci grâce au moteur de template Jinja.

Autrement dit : vous définissez les fichiers dont vous avez besoin (parfois un copier/coller suffit), puis vous insérez dans vos fichiers des chaînes de caractères que vous souhaitez remplacer dans le projet. Vous pouvez également définir des valeurs conditionnelles. Par exemple : si je souhaite avoir une licence MIT, alors le fichier LICENSE contiendra un certain texte. Si je choisis la licence LPRÀB/WTFPL, alors j’aurais un autre texte.

Un exemple concret serait plus parlant, essayons avec cookiecutter-trognon !

Comment transformer Trognon en cookiecutter-trognon ?

En rapide

Pour rendre un projet compatible avec cookiecutter, il va falloir suivre quelques étapes clés :

Créer un nouveau répertoire pour votre projet,
Y créer un fichier nommé cookiecutter.json,
Créer un répertoire nommé {{ cookiecutter.project_slug }} (oui oui, AVEC les accolades),
Déposer les fichiers nécessaires au projet dans le répertoire {{ cookiecutter.project_slug }},
Remplacer dans les fichiers tous les mots à adapter à chaque nouveau projet : pour cela utiliser les mots clés fournis dans le fichier cookiecutter.json (variables).

Dans le cas de Trognon, j’ai déposé les fichiers du projet dans le répertoire {{ cookiecutter.project_slug }}.

cookiecutter.json, la configuration du projet

J’ai ensuite rempli le fichier cookiecutter.json tel que montré ici :

{
  "project_name": "Mon projet",
  "__project_slug": "{{ cookiecutter.project_name.lower().replace(' ', '_').replace('-', '_') }}",
  "command_shortname": "CommandePrincipale",
  "__command_slug": "{{ cookiecutter.command_shortname.lower().replace(' ', '_').replace('-', '_') }}",
  "__prompts__": {
    "project_name": "Choisissez un nom de projet court",
    "command_shortname": "Que voudriez-vous comme nom court de commande ?"
  }
}

Je défini des variables comme :

project_name : le nom du projet, avec comme valeur par défaut Mon projet,
command_shortname : le nom de la commande Bash que nous utiliserons.

D’autres variables ne demanderont rien à l’utilisateur car elles commencent par deux espaces soulignes __. Je parle bien entendu de __project_slug, __command_slug et __prompts__.

Cependant __prompts__ a une particularité : il permet de personnaliser la question posée pour chaque variable.

Ainsi pour définir project_name, l’utilisateur verra la question suivante : Choisissez un nom de projet court.

Remplacer des mots par des variables

Maintenant que le fichier cookiecutter.json possède des mots clés spécifiques (des variables), nous allons pouvoir modifier les fichiers de notre projet pour contenir des « mots-clés ». Par exemple voici le début du fichier README.md de Trognon (AVANT modifications) :

# Trognon

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./agnes help

# Installe votre projet (vous devez définir ce que `install` fait)
./agnes install

# créé un dump de la base de données
./agnes dump

Ce qui donne le fichier README.md suivant dans notre projet cookiecutter-trognon (APRÈS modifications) :

# {{ cookiecutter.project_name }}

Un lanceur de commandes personnalisées pour votre projet de développement.

Exemple : 

# Affiche l'aide
./{{ cookiecutter.__command_slug }} help

# Installe votre projet (vous devez définir ce que `install` fait)
./{{ cookiecutter.__command_slug }} install

# créé un dump de la base de données
./{{ cookiecutter.__command_slug }} dump

Nous avons ainsi remplacé respectivement le titre du fichier et les commandes d’exemple en {{ cookiecutter.project_name }} et {{ cookiecutter.__command_slug }}.

Vous pouvez en savoir plus sur la documentation officielle de cookiecutter.

Conclusion

J’espère qu’à travers cet article vous aurez compris l’avantage d’utiliser cookiecutter et que vous envisagerez à l’avenir de l’intégrer dans votre processus d’automatisation de la génération initiale de vos projets et de vos scripts.

L’informatique énonce souvent d’éviter de réinventer la roue ; je pense que cookiecutter est l’outil indispensable pour favoriser ce concept.

Une fois ce processus de création automatisé, vous vous rendrez compte que vous générerez plus souvent des scripts/projets, que vous vous concentrerez uniquement sur le contenu du projet et pas sur tout l’environnement autour : c’est un gain de temps et de qualité ! Une belle valeur ajoutée en somme.

La Genèse d'un projet

Wed, 13 Sep 2023 12:13:23 +0200

Il y a quelques temps je lançais un billet sur le projet Gachette qui permet de publier mon blog. Dans la même lancée je souhaite aujourd’hui vous présenter un autre projet sur lequel je travaille de temps en temps : Genèse. Genèse est assez difficile à définir. Cependant je l’imagine comme une commande unique pour permettre à plusieurs développeurs de travailler sur un environnement commun et en lançant une instance par ticket/problème relevé.

Cet outil, bien qu’il soit utile et facile à utiliser, demande un minimum d’explication pour comprendre à la fois le concept et l’utilité réelle.
C’est pourquoi je vais avant tout poser la problématique principale qui a initiée le projet, puis montrer quelques usages intéressants qui sont plus parlants et finalement tenter d’expliquer son fonctionnement en interne.

Photo trouvée sur le profil de Damian Gadal sur Flickr sous licence CC BY 2.0.

Ce qui a initié le projet

De nombreuses années d’expérience professionnelle dans le domaine informatique m’ont amené à rencontrer plusieurs problèmes et à réfléchir sur énormément de sujets.

L’un d’eux se porte sur l’environnement de travail : je parle de l’environnement système utilisé pour travailler sur un projet. J’ai relevé quelques éléments intéressants, similaires à des postulats :

on essaie souvent de se rapprocher de l’environnement système de la production : ceci pour repérer assez tôt d’éventuels problèmes
plus l’environnement entre collègues est similaire, mieux nous travaillons : si un collaborateur rencontre un problème il peut se tourner vers le reste de l’équipe pour avoir de l’aide
nous en arrivons souvent à faire un fichier docker-compose.yml pour cela : peut-être est-ce initialement plus facile de partager un fichier léger (docker-compose.yml) qu’une machine virtuelle entière ?
quand on nouveau collaborateur arrive dans l’équipe, il a pas mal de choses à apprendre sur le projet. Et il peine souvent - en plus de toutes les choses à apprendre - à devoir installer l’environnement initial
on utilise souvent un fichier docker-compose.yml très proche entre plusieurs projets : ce qui est normal puisqu’on utilise très souvent des technologies similaires qu’on maîtrise pour les vendre à nos clients
on travaille souvent sur plusieurs tickets, c’est à dire plusieurs problèmes émis par le client. Chaque fois que nous démarrons un nouveau ticket, dans l’idéal, nous devrions avoir un environnement sain et propre pour ne pas avoir de fioritures de nos travaux précédents

En discutant avec Richard Dern (qui a d’ailleurs fait une refonte de son site web avec un nouveau moteur de blog), nous avons réfléchi à un outil capable de résoudre plusieurs de ces problématiques. Le fil rouge était :

les environnements doivent rester isolés : utilisation d’un fichier docker-compose.yml pour générer un environnement
création d’un répertoire unique pour chaque nouveau ticket/projet/autre afin de garder quelque chose de sain et propre
éviter de devoir se répéter entre plusieurs projets : mettre en commun les éléments qui le peuvent, comme par exemple le type de base de données
permettre à plusieurs utilisateurs de travailler sur la même machine : nommage des environnements d’une manière particulière (avec le nom de l’utilisateur par exemple)
permettre à chaque développeur de personnaliser son environnement : par exemple s’il souhaite avoir une interface web pour la base de données, qu’il puisse rajouter l’outil qu’il souhaite
si nous travaillons sur 2 tickets d’un même projet, sachant que l’environnement est similaire pour un même projet, ces deux environnements doivent pouvoir exister en même temps : s’ils utilisent les mêmes ports d’adresses, cela va échouer. Il faut donc des ports aléatoires.
si les ports sont aléatoires, alors il faut un accès facile à chacun des environnements, par exemple à l’aide d’une interface Web commune à tous ces environnements

C’est assez difficile à se l’imaginer sans des explications, une démonstration et/ou quelqu’un qui nous guide pour nous montrer le fonctionnement, alors je vais vous présenter un cas d’usage.

Usage et exemple de Genèse

Imaginons un cas d’usage typique : un client détient une application web (faite avec un framework) qui utilise une base de données MySQL. Appelons cette application : memory_game.

Il est très probable que nous ayons d’autres clients qui utilisent MySQL. Et il est très probable que notre client fera des tickets de bugs que nous aurons à résoudre. Nous aurons probablement plusieurs collaborateurs (pour lesquels nous allons répartir les tickets).

Il utilise un fichier docker-compose.yml avec le contenu suivant :

version: '3'

services:
  php:
    image: toasterlint/php-apache-mysql
    ports:
      - "8888:80"
    volumes:
      - ./:/var/www/html

  db:
    image: mysql
    command: --default-authentication-plugin=mysql_native_password
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: mot2passe
      MYSQL_DATABASE: maBdd
    volumes:
      - ./base_de_donnees:/docker-entrypoint-initdb.d

On comprend donc qu’il y a :

un service (nommé db) pour une base de données MySQL,
un service (nommé php) pour l’application écrite en PHP sur le port 8888.

Avec Genèse, générer un nouvel environnement de développement reviendrait à faire :

# Génère un docker-compose.yml dans le dossier instances/memory_game à partir du profil nommé memory_game
./genese -p memory_game

instances/memory_game est un répertoire de travail :

avec le dépôt de version du projet memory_game,
un fichier docker-compose.yml prévu pour lancer un environnement complet,
et un fichier .env contenant des variables permettant au projet d’être autonome.

Si l’exécutable ./genese venait à disparaître, le dossier reste fonctionnel pour travailler (avec Docker Compose évidemment).

Si on travaille sur plusieurs problèmes en parallèle, on peut vouloir créer un dossier par problème. Imaginons le ticket 42 et le ticket 16 :

# Génère une instance du projet dans le dossier instances/ticket42
./genese -p memory_game -n ticket42
# Même chose avec le dossier instances/ticket16
./genese -p memory_game -n ticket16

Il faut récupérer une branche spéciale du service memory_game ?

# Récupère dans le dépôt Git fourni dans le service memory_game la branche maBrancheSpeciale
BRANCHE_MEMORY_GAME="maBrancheSpeciale" ./genese -p memory_game -n essaiautrebranche

Vous découvrirez dans un prochain article à quel usage je réserve cela 😉

Quelles sont les instances dont je dispose ?

# Liste l'ensemble des instances
./genese -i

Et j’obtiens une liste des dossiers ayant été créés.

Si je veux supprimer une instance spécifique :

# Supprimer l'instance ticket16
./genese -s ticket16

Et si on veut avoir une visualisation des instances lancées, d’accéder à leur détail, éteindre un conteneur, le rallumer, regarder les fichiers de journalisation (logs) ou encore entrer dans un conteneur avec une invite de commande, on peut utiliser l’interface Web Portainer fournie avec Genèse. Cela ressemble à quelque chose comme :

Seriez-vous curieux de savoir comment cela fonctionne (sans entrer dans le technique évidemment !) ?

Comment ça marche ?

Nous allons voir que Genèse s’appuie sur quelques éléments clés comme :

l’instance : version autonome et isolée, située dans le dossier instance,
le service : la description nécessaire pour générer un service, par exemple MySQL,
le profil : contient une liste de services permettant de démarrer une instance.

Prenons l’exemple précédent, nous aurons :

deux services :
- l’un nommé mysql pour la base de données,
- l’autre nommé memory_game pour notre application,
un profil nommé memory_game qui liste les services mysql et memory_game.

Chaque fois que nous lancerons la commande ./genese avec le profil memory_game nous aurons la possibilité de générer une instance avec un nom spécifique.

Comment cela peut-il fonctionner ? Les services ont une structure permettant de décrire :

la partie du fichier docker-compose.yml qui va être utilisée,
la possibilité de donner le dépôt Git utilisé pour récupérer les sources du projet et la branche par défaut à récupérer,
la possibilité de donner un dossier extras permettant de surcharger les sources du projet récupéré (par exemple pour mettre des fichiers de configuration),
la possibilité d’agir à des moments clés de la génération de l’instance via des déclencheurs qui sont des scripts pour :
- procéder à des changements AVANT le lancement des conteneurs Docker, par exemple modifier des fichiers de configuration,
- agir APRÈS le lancement des conteneurs, par exemple pour lancer des commandes dans les conteneurs Docker lancés,
- afficher des informations à la fin du processus de création de l’instance, par exemple pour afficher les ports utilisés par les différents conteneurs

À cela s’ajoute une interface Web (Portainer) permettant de contrôler les instances lancées et accéder à des fonctionnalités particulières de Docker.

La documentation de Genèse devrait se charger bien mieux que moi pour les détails techniques et les possibilités de cet outil.

Conclusion

Malgré l’exemple d’utilisation et quelques détails sur son fonctionnement, Genèse mérite qu’on s’y attarde : nous n’avons gratté que la surface.

Cela ressemble à un framework pour des profils de personnes de type devops afin de leur fournir un outil unique ; à la fois déployer des instances pour les développeurs ; et des instances de type test pour les personnes fonctionnelles.

Je ne sais pas comment suggérer de passer un peu de temps sur l’outil pour comprendre que c’est un bon investissement de temps. Surtout pour des personnes d’un profil DevOps et qui connaissent le scripting Bash. J’espère que la curiosité vous piquera au vif !

Nous nous retrouverons très probablement pour en reparler dans un cadre différent encore.

Déploiement d'une application Crystal en production

Sun, 07 Oct 2018 15:29:39 +0200

Introduction

Le mois dernier je parlais de l’installation de PixelFed, un outil récent avec peu de documentation. Aujourd’hui je voudrais installer en production un site web développé avec Amber, un framework du langage Crystal pour développer rapidement des sites webs.

Force est de constater que souvent les tutoriels proposés ne correspondent pas à mes attentes. J’ai décidé de vous livrer aujourd’hui le résultat de mes enquêtes sur le sujet !

Après une présentation du framework Amber, je listerai rapidement les étapes à suivre pour déployer son application sur un serveur.

Un tutoriel plus détaillé pour Amber est disponible sur mon wiki.

Au sujet d’Amber

C’est un framework web. C’est à dire un outil pour simplifier la création de sites Web. Il peut aussi bien faire des sites vitrines que des applications webs ou des API web. Il est donc multifonctions.

Amber est écrit en Crystal, un langage dont la syntaxe est similaire à Ruby, mais dont l’application résultante est plus rapide. Ça dépotte !

Pourquoi je parle de Ruby aussi ? Parce qu’il possède un outil formidable très connu pour créer des sites webs : Ruby On Rails. Déjà très intéressant pour créer des sites webs, il était normal que les développeurs Crystal s’attardent à la création d’un outil similaire : Amber !

J’ai déjà utilisé Ruby On Rails, alors je me suis dis pourquoi pas tenter Amber ? Allons-y !

Déploiement, en bref

Je rappelle qu’un tutoriel plus détaillé pour Amber est disponible sur mon wiki. Et le “Quick Start” d’Amber explique très bien comment créer un projet.

Pour déployer Amber, il faut suivre quelques étapes clés :

créer une base de données sur le serveur et garder en tête l’identifiant, le mot de passe et la base de donnée associée
configurer le mode production sur notre machine et garder quelque part la clé située dans le fichier .encryption_key
compiler sur notre machine l’application en mode --release, mais aussi amber lui même. Si votre machine et le serveur sont d’architectures différentes, pensez à la compilation croisée d’application Crystal (en)
copie de certains dossiers de votre application vers le serveur
migration du schéma de la base de données sur le serveur
création d’un fichier systemd sur le serveur pour le lancement/arrêt du service (votre site web)
lancement de votre service sur le serveur
configuration et relance de Nginx en association avec votre site web sur le serveur

Je vous donne ce qui est généralement important ci-dessous.

La configuration de la connexion dans le fichier de production :

database_url: postgres://amber_user:mot2passe@localhost:5432/amber_production

Savoir quels fichiers copier :

bin/
config/environments/.production.enc et QUE celui-là (les autres sont inutiles pour la production)
db/
public/
src/locales/

On oublie souvent de déployer la base (en mettant la clé située dans le fichier .encryption_key) :

AMBER_ENV=production AMBER_ENCRYPTION_KEY="oliBK0J9-HrSK1K8VPTtsMERyj2as1mUZqvPqfKGGeQ" ./bin/amber db migrate

Avec un fichier systemd bien rempli, notamment les variables d’environnement :

[Unit]
Description=Lance le framework web Amber pour le site monsite.tld
After=network.target

[Service]
Type=simple
User=http
WorkingDirectory=/srv/www/monsite
Environment="AMBER_ENV=production"
Environment="PORT=3002"
Environment="AMBER_ENCRYPTION_KEY=oliBK0J9-HrSK1K8VPTtsMERyj2as1mUZqvPqfKGGeQ"
ExecStart=/home/www/monsite/bin/tutamber
Restart=always

[Install]
WantedBy=multi-user.target

Et finalement on se mange souvent sur une configuration Nginx pourrie, mais on commence simple :

server {
  listen      *:80;
  listen      [::]:80;
  server_name monsite.domaine.tld;
  root        /srv/www/monsite;
  index       index.html;

  proxy_set_header X-Real-IP  $remote_addr;

  location / {
    proxy_set_header Host $host;
    proxy_pass http://127.0.0.1:3002;
  }
}

Et voilà !

Conclusion

Le déploiement d’une application Amber n’est pas plus compliquée qu’un autre service. Mais il faut avouer qu’elle n’est pas si bien détaillée sur le site même d’Amber. Le projet est encore jeune, tout autant que le langage Crystal lui-même. Avec mon tutoriel vous savez quoi faire : installer des sites Amber partout 😂.

Cependant je vous conseille vivement de tester Crystal, Amber et d’autres éléments de la communauté : c’est facile à écrire, c’est réactif, bien pensé, avec une communauté active, des personnes gentilles qui répondent aux questions, c’est top !

Développer pour Arduino en ligne de commande

Sun, 18 Oct 2015 11:12:18 +0100

Introduction

L’Arduino est une carte électronique assez connue permettant grossomodo de transformer n’importe quel objet en objet intelligent puisque vous allez pouvoir programmer ce dernier afin d’avoir des comportements spécifiques suivant les données reçues par un certain nombre de capteurs.

Arduino permet de réunir le monde de l’informatique à celui de l’électronique et favorise le DIY (Do It Yourself = fait le toi-même).

Le site officiel d’Arduino propose de nombreuses documentations et surtout un logiciel pour développer, compiler et envoyer sur l’Arduino votre programme. C’est une interface simple, claire, compatible Windows, MacOSX et GNU/Linux car développée en Java. Cependant, je préfère très - ou trop ? - souvent développer des programmes sous VIM en mode console et faire les compilations et l’envoi en ligne de commande. Et je ne suis pas le seul. Voilà pourquoi j’ai décidé de vous partager mon environnement de travail pour Arduino.

Sommaire

Programmer pour Arduino se résume finalement comme beaucoup d’autres projets aux 3 actions suivantes :

développer un programme sur son éditeur préféré
compiler le programme (parfois sur le même éditeur)
envoyer le résultat en production. Dans notre cas ce sera dans l’Arduino

Si la première étape est facile pour tout le monde, puisque chacun a probablement déjà son éditeur préféré, les 2 dernières étapes sont moins simples.

Sous GNU/Linux, et plus particulièrement sous une distribution dérivée Debian, cela se résume quasiment à :

installer les paquets arduino-core et arduino-mk
initialiser des variables dans son .bashrc, .zshrc ou tout autre invite de commande
savoir créer pour chacun de ses projets Arduino un fichier Makefile
savoir quelle commande utiliser pour compiler et pour envoyer le résultat sur l’arduino

Passons donc à la préparation de l’environnement

Installation et configuration

Comme vous l’avez vu, nous commençons par l’installation des paquets arduino-core et arduino-mk :

apt-get install arduino-core arduino-mk

Ceci devrait, entre autre, installer avrdude qui nous facilitera l’envoi sur l’Arduino.

Ensuite nous éditons le fichier de configuration de notre shell préféré, ici .bashrc afin d’y initialiser les variables suivantes :

ARDUINO_DIR : le dossier dans lequel a été installé arduino-core qui contient, entre autres les bibliothèques nécessaires à la programmation d’un Arduino
ARDMK_DIR : le dossier dans lequel a été installé arduino-mk
AVR_TOOLS_DIR : le dossier dans lequel chercher l’outil avrdude

Chez moi cela donne quelque chose comme :

export ARDUINO_DIR="/usr/share/arduino"
export ARDMK_DIR="/usr/share/arduino"
export AVR_TOOLS_DIR="/usr"
export ISP_PORT="/dev/ttyACM0"

À noter que j’ai rajouté la variable ISP_PORT pour définir d’emblée le port de communication avec mon Arduino. Ce n’est donc pas obligatoire dans votre cas (comme nous le verrons par la suite).

Passons à l’utilisation de tout cela.

Utilisation

Si nous devions résumer une utilisation simple de cet environnement, voici les étapes que nous ferions :

créer un dossier pour notre projet
créer un fichier avec l’extension .ino et remplir ledit fichier avec un programme
créer un fichier Makefile dans le dossier du projet
y ajouter quelques variables
lancer la commande make
brancher l’Arduino et faire un make upload

Et le tour est joué !

Je pense que le point à éclaircir ici est celui du fichier Makefile à remplir. Rien ne vaut un bon vieil exemple de mon fichier Makefile pour le projet Blink qui fait clignoter la LED 13 de mon Arduino MEGA 2560 :

BOARD_TAG = mega2560
ARDUINO_LIBS = 
ARDUINO_PORT = /dev/ttyACM0

include /usr/share/arduino/Arduino.mk

Rien de plus, rien de moins. Avec ça, un simple make && make upload devrait faire l’affaire 😃

Les commandes disponibles

Le fichier Makefile inclut celui fournit par le paquet arduino-mk. Et ce dernier est rempli de commandes en tous genre. Le mieux pour s’en rendre compte est de lancer la commande suivante dans votre projet :

make help

Vous aurez tout un tas de commandes possibles. Par exemple je souhaitais connaître les valeurs possibles de la variable BOARD_TAG, ayant un modèle spécial d’Arduino. J’ai donc fait :

make show_boards

ce qui m’a permis de savoir que le modèle mega2560 était disponible.

Conclusion

Je trouve ce fichier Makefile parfait pour développer en toute sérénité sans avoir à installer l’environnement Java nécessaire au programme conseillé par Arduino et tout en gardant son outil de développement favori.

Petit bonus pour ceux qui aiment s’amuser avec la sortie série d’un Arduino : si votre programme ajoute des Serial.print(), vous pouvez voir la sortie de votre Arduino en utilisant le logiciel minicom de la manière suivante :

minicom -b 9600 -o -D /dev/ttyACM0

Ça me rappelle mes débuts sous la carte Efika tiens !

Installations multiples de Dokuwiki, script de mise à jour

Mon, 14 Apr 2014 18:54:54 +0100

Introduction

Dokuwiki est un outil formidable qui permet de créer un wiki simplement avec un serveur ayant PHP.

Il est tellement formidable que je l’ai installé dans quasiment chacun de mes projets. Seulement voilà, sa qualité est telle qu’il est régulièrement mis à jour ; ce qui me demande beaucoup de temps à chaque nouvelle version pour mettre à jour mes multiples installations.

Recherche d’une solution

Je me suis dit récemment qu’il y avait forcément d’autres personnes qui avaient le même problème que moi. Et j’ai eu raison, d’autres personnes comme Johannes Thönes explique comment mettre à jour de multiples installations de Dokuwiki à l’aide d’un script.

Le couac

Cependant, en voyant le script de Johannes Thönes, je me suis vite rendu compte qu’il n’était plus fonctionnel sur les versions courantes de Dokuwiki.

J’ai donc mis la main à la pâte et je vous ai mis à jour le script de mise à jour de multiples installations de Dokuwiki.

Tout content de moi, je tente de lancer le script sur ma machine distante et BAM. Cela ne fonctionne pas à cause de dépendances avec le gem libarchive. Impossible de l’installer/compiler sous GNU/Linux Debian. Alors que sous Ubuntu cela passait sans problème. Sgrumblblbl.

Ainsi je me suis lancé dans une tâche inutile, ardue, futile, mais tellement enrichissante : la création d’un script BASH pour mettre à jour de multiples installations de Dokuwiki.

Mettre à jour ses Dokuwiki à l’aide d’un script Bash

Après tout, me suis-je dis, Dokuwiki donne les commandes pour GNU/Linux, 80% des serveurs sont sous GNU/Linux, et puis cela demande moins de dépendances branlantes d’avoir BASH que d’avoir un script Ruby, non ?

Quoiqu’il en soit, j’ai écrit un script BASH pour mettre à jour de multiples installations de Dokuwiki.

Tout ce que je demande pour que cela fonctionne, c’est :

d’avoir CURL installé sur votre machine
d’avoir BASH (évidemment)
de modifier le fichier pour renseigner vos installations de Dokuwiki
lancer le script avec un utilisateur ayant les permissions totales sur les installations de Dokuwiki
donner le lien, en argument au lancement du script, de la dernière version de Dokuwiki

Ce que fait le script :

Vérifie l’existence des répertoires d’installation
Vérifie la présence de CURL
Crée un répertoire temporaire et en donne l’adresse absolue
Télécharge la dernière version de Dokuwiki et l’extraie dans le dossier temporaire
Télécharge un fichier contenant la liste des fichiers obsolètes dans Dokuwiki
Pour chacun de vos Dokuwiki :
- Création d’un répertoire de sauvegarde dans le répertoire temporaire crée précédemment
- Copie de sauvegarde de vos fichiers dans le répertoire temporaire
- Copie des nouveaux fichiers Dokuwiki dans votre répertoire d’installation de Dokuwiki
- Suppression des fichiers de Dokuwiki obsolètes
- Mise à jour du message apparaissant à l’écran sur l’interface de Dokuwiki
- Changement des permissions de votre installation de Dokuwiki avec l’utilisateur www-data et le groupe www-data (peut être changé dans le script)

Conclusion

Première utilisation, première joie, première pause pendant que ça met à jour alors que nous sommes dans le fauteuil, peinard.

Je conseille évidemment ce script à tout le monde et suis curieux de savoir s’il servira à plus d’un !

Liens utiles

Voici Docker, plus léger et plus simple qu'une machine virtuelle

Thu, 03 Apr 2014 13:20:30 +0100

Introduction

Nous parlions précédemment de VirtualBox pour créer des machines virtuelles sur sa machine. C’est une solution pratique qui permet de tester un environnement sans avoir à installer quoique ce soit de plus que VirtualBox sur sa machine et sans perdre de données. Un environnement fermé.

Mais quand il s’agit de lancer plusieurs services sur une machine (un serveur web, un serveur de base de données, une application web, etc.) cela devient tout de suite lourd et consommateur de mémoire vive + espace disque.

Des solutions alternatives existent, comme l’utilisation de LXC qui sont des conteneurs qui utilisent communément le noyau Linux mais fonctionnent à peu de choses prêts comme ce que nous appelons des chroots. Cependant cette solution n’est pas si simple car il faut gérer les conteneurs, leur lancement, etc.

Une solution plus simple, se basant sur les LXC existe : Docker.

Présentation de Docker

Pour en savoir plus sur Docker, il faut se rendre sur la page prévue à cet effet sur le site officiel.

Mais pour vous résumer un peu ce que j’en ai compris :

Docker permet de créer des applications dans un conteneur
Un conteneur est plus léger en terme de taille et en terme de consommation mémoire qu’une machine virtuelle entière
Les conteneurs peuvent être construits à partir d’un simple fichier nommé le Dockerfile
Les conteneurs peuvent être partagés via un dépôt public (Index Docker)
La création d’un conteneur peut se faire via l’utilisation de commit, ce qui permet de versionner les conteneurs
La création d’un conteneur peut se faire via l’héritage d’un autre conteneur

Ainsi :

faire tourner plusieurs conteneurs est plus léger que créer plusieurs machines virtuelles
le versionnement de ses conteneurs permet de redémarrer depuis un précédent commit, de rejouer certaines choses ou améliorer des conteneurs précédents
le Dockerfile est un simple fichier, ce qui permet de partager/déplacer une application contenue dans un conteneur de manière très rapide
plus de soucis avec les collègues au sujet d’un environnement différent d’un développeur à l’autre : tout le monde utilise la même version du conteneur

Vous l’aurez compris, cela n’a que des avantages - quasiment.

Installation et utilisation

Le site de Docker nous apprend comment installer et utiliser Docker en quelques points, mais aussi la page Docker de mon Recueil d’astuces.

Ce que je pense qu’il faut au minimum retenir ce sont les commandes suivantes :

# Créer un nouveau conteneur basé sur Ubuntu
docker run -i -t ubuntu /bin/bash
# Voir les conteneurs lancés
docker ps
# Voir tout les conteneurs crées
docker ps -a
# Voir les images disponibles sur notre machine (à partir desquelles créer de nouveaux conteneurs)
docker images
# Supprimer un conteneur (ID est l'identifiant donné par la commande docker ps -a)
docker rm ID
# Donner un nom à son conteneur (--name). Utile à la place d'utiliser un ID
docker run -i -t --name SuperNom ubuntu /bin/bash

Et évidemment, le plus intéressant est de regarder l’index des fichiers Docker disponibles.

Quelques regrets

En faisant quelques conteneurs Docker, on peut regretter :

le fait qu’il faille utiliser supervisord de manière systématique pour lancer plusieurs services dans un conteneurs.
l’utilisation d’espace partagés ne nous prévient pas qu’on risque d’écraser nos propres données sur la machine hôte
ne fonctionne que sur architecture am64
ne fonctionne que pour Linux (puisque basé sur LXC), donc sous windows il faut utiliser une machine virtuelle avec Ubuntu

Si on se soustrait de ses inconvénients, cela reste un outil intéressant !

Conclusion

Docker est un outil intéressant comparé à la gestion, la création et l’utilisation de conteneurs LXC, c’est une surcouche très attrayante.

J’apprécie qu’on puisse générer un environnement commun à l’ensemble d’une équipe de développeurs afin qu’ils aient toujours les mêmes bibliothèques et outils. En revanche, pour de la production je ne trouve pas cela encore assez au point car réussir à lancer plusieurs services sur un conteneur est vite décourageant et demande pas mal de connaissances !

Mon utilisation de Docker resterait donc du côté développement, afin d’utiliser un fichier simple qui génère un environnement complet de développement et de déploiement local d’un ou plusieurs services. Par exemple pour avoir un serveur OpenERP ou bien un serveur postgreSQL.

Je pense que ça peut-être déployé sur un serveur distant (machine virtuelle ou non) avec plusieurs conteneurs, un par service afin de permettre de déployé/déplacer un service rapidement, sans effort et sans pertes.

Je verrais cela à l’utilisation, et je vous invite à en faire autant !

Liens utiles

Traduction de ses scripts Lua avec gettext

Mon, 02 Sep 2013 18:32:01 +0100

Introduction

En ce moment j’avance sur un projet informatique écrit dans le language Lua. Je m’essaie ainsi à ce langage et en profite de sa puissance pour mes scripts de création de sites web comme PorteAil ou encore Makefly.

Ainsi, pour l’un ou l’autre raison j’ai besoin de traduire les messages d’erreurs de l’application en la langue de l’utilisateur. Il y a probablement plusieurs méthodes, mais voici celle que j’utilise.

Notez que je donne le détail complet du code dans mon tutoriel sur Gettext pour Lua.

Image sous Licence Creative Commons CC-BY 2.0 trouvée sur une galerie photo de gsfc.

Gettext

L’outil le plus utilisé selon Internet est Gettext. Il permet de parcourir notre code afin d’en extraire les chaînes à traduire. Puis divers outils permettent de procéder à la traduction des chaînes, soit automatiquement, soit manuellement.

Enfin l’outil va générer des fichiers binaires pour une rapidité accrue de traitement/lecture/rendu.

Implémentation

Il n’y a pas d’implémentation à part entière pour Lua, il faut donc créer sa propre implémentation.

En premier lieu on doit créer une fonction qui va lire nos chaînes et donner la traduction (en lisant le fichier binaire spécifique à la langue de l’utilisateur. Généralement c’est une fonction _ (espace souligné) qu’on utilise. Elle va lire le fameux fichier binaire (extension *.mo) de Gettext et donner le résultat.

Sachant que nous voulons retourner les erreurs du programme/script en plusieurs langues, il va falloire initialiser la fonction avant le début de nos traitements.

Vous pouvez voir tout ceci dans le tutoriel sur Gettext pour Lua que je vous ai concocté.

Résumé

Si on devait synthétiser, voici ce qu’il faut faire :

faire une fonction _ qui lit une chaîne et donne sa traduction
faire une fonction qui lit un fichier *.mo et cherche une chaîne donnée pour en sortir son résultat
initialiser le chargement du fichier *.mo et la fonction de traduction en début de script
ajouter les chaînes à traduire dans des fonctions _()
parcourir notre code avec gettext pour récupérer les chaînes à traduire
traduire
convertir en fichier binaire
joindre le binaire à notre programme et enlever les fichiers temporaire (*.po, *.pot, etc.)

Conclusion

En dehors de la lecture du fichier binaire de gettext qui se résoud facilement en cherchant sur Internet, l’implémentation fût facile et le résultat est au-delà de mes espérances.

L’avantage d’avoir des fichiers à traduire au format *.po, c’est que des interfaces graphiques simples telles que gTranslator ou poedit permettent à des non-initiés au code de programmation de traduire votre application sans avoir à lire du code.

Des interfaces web permettent également de traduire en ligne sans installer quoique ce soit. C’est donc très utile pour des projets !