Blog d'un ingénieur informaticien parmi d'autres...

Adieu Google Suite

Mon, 09 May 2022 00:00:00 +0200

Le drame

Le 24 mai 2008, je reçus ce courriel de Google :

Cher administrateur Google Apps,

Nous sommes très heureux de vous donner la possibilité d’offrir de puissants outils de communication et de partage à courtine.org grâce à Google Apps.

…

Bien cordialement, L’équipe Google Apps

— google-apps-do-not-reply@google.com
Google Apps : confirmation d'inscription et étapes suivantes

C’était le début de mon utilisation des services "Google Apps for Business", qui seront par la suite renommés "Google Suite". Je n’en ai pas changé depuis lors, et mes adresses familiales @courtine.org étaient donc gérées par Google depuis cette date. J’ai toujours été très satisfait par ce service :

Il a une interface agréable à utiliser.
Il fonctionne bien.
Il a toutes les fonctionnalités pour répondre à mes besoins.
Il ne m’a jamais coûté un centime.

Sur ce dernier point, j’ai bien conscience que "si c’est gratuit, c’est moi le produit". Mais c’est un compromis que j’acceptais en connaissance de cause.

Presque 14 ans plus tard, ce 26 janvier 2022, comme les autres utilisateurs du service, je reçois le courriel suivant :

Bonjour,

Nous vous informons que l’ancienne édition gratuite de G Suite dont vous disposez ne sera plus disponible à compter du 1er juillet 2022. Pour conserver vos services et vos comptes, vous devez passer à Google Workspace.

Nous avons lancé l’ancienne édition gratuite de G Suite (l’offre Google Apps originale destinée aux entreprises et aux établissements d’enseignement) il y a 16 ans. Nous avons arrêté ce service en 2012, et nous allons maintenant migrer tous les utilisateurs restants vers un abonnement Google Workspace payant (basé sur les fonctionnalités que vous utilisez aujourd’hui).

…

— The Google Workspace Team
Action requise Passez à un abonnement Google Workspace

Alors, c’est embêtant, mais je n’en veux pas à Google de cette décision. J’ai bien conscience que le service qu’ils offrent a un coût, et il n’est pas anormal de le facturer.

Finalement, la décision de Google me semble plutôt être une bonne nouvelle. Elle va permettre de mettre sur un pied d’égalité les différents fournisseurs de services.

Trouver une alternative

Le service de Google me convenant, j’aurais été prêt à payer pour continuer à l’utiliser. Cependant, avec une utilisation assez minimale des fonctionnalités proposées (courriel, calendrier, annuaire de contacts) et une famille nombreuse, le tarif de base (un peu moins de 5€ par adresse et par mois) m’a semblé particulièrement élevé pour une simple utilisation familiale.

J’ai donc cherché des alternatives.

Mes critères pour cette recherche sont surtout d’avoir une solution à un tarif raisonnable. La confidentialité et les garanties de chiffrement ne sont pas essentiels pour moi. C’est pour cette raison que je retiens pas ProtonMail par exemple (sans doute très bien, mais aussi cher que Google Workspace).

GMail

La solution Google étant satisfaisante, une première possibilité est de me créer des adresse GMail, et de rediriger les adresses @courtine.org vers celles-ci.

Avantages

C’est simple à mettre en œuvre (avec le service "Routage des e-mails" de Cloudflare par exemple).
C’est transparent pour les utilisateurs (on conserve la même interface).
Ça reste gratuit.

Inconvénients

On ne quitte finalement pas Google…
… et on reste donc le produit.

Office 365

Microsoft propose une offre "Office 365 Famille" à 100€ par an pour 6 personnes, soit 1,4€ par adresse et par mois.

Avantages

L’interface des services Microsoft, bien pensée.
Le tarif raisonnable.
La suite Office incluse dans le prix (même si nous n’en avons pas l’utilité).

Inconvénients

On reste chez un GAFAM.
Il ne faut pas avoir besoin de plus de 6 adresses.

Les autres

On a ensuite un certain nombre de fournisseurs alternatifs, qui a mon avis sont relativement équivalents :

"E-mail pro" d’OVH (1€ par adresse et par mois).
Offre "Mail" de Gandi (0,42€ par adresse et par mois).
etc.

Avantages

On quitte les GAFAM.

Inconvénients

L’interface web est souvent un RoundCube, moins pratique que les produits maison de Google/Microsoft/etc.

Il en existe encore certainement beaucoup d’autres (et dont certaines sont peut-être même mieux adaptées à mes besoins)… Je n’ai pas du tout la prétention de présenter un panel exhaustif mais uniquement les différentes options que j’ai considérées.

Le choix

Parmi les alternatives, il y avait également l’auto-hébergement. Cependant, je manque de temps pour m’amuser à installer/configurer/gérer/maintenir ce genre de services… Je n’ai donc pas creusé cette solution ni les différentes manières possibles de la mettre en pratique.

Quitte essayer de m’affranchir Google, j’ai voulu aller au bout de la démarche, en ne migrant ni vers GMail, ni un autre GAFAM (et donc en excluant Office 365). J’ai donc finalement opté pour l’offre mail de Gandi (chez qui j’avais déjà un compte, mes noms de domaine y étant enregistrés).

Les boites basiques chez Gandi sont limitées à 3Go, contre 15 pour les comptes Google. Le choix de Gandi a donc été possible parce que je n’utilisais qu’une très faible portion du stockage Google (moins de 2 Go pour le plus gros compte).

La migration

Adresses et enregistrements DNS

Je commence par créer les adresses, alias, redirections… chez Gandi, afin d’avoir les boites souhaitées (à l’identique de celles présentes chez Google, pour ne pas perdre de messages une fois la migration effectuée).

Je modifie ensuite les enregistrements MX, afin de commencer le routage des nouveaux messages vers les nouvelles boites.

Chez Gandi, la documentation initiale ne concerne que le routage. Il faut se rendre sur la page antispoofing pour avoir le complément d’information sur les enregistrements DKIM, SPF, DMARC.

Configuration DNS complète

; Routage
@ 10800 IN MX 10 spool.mail.gandi.net.
@ 10800 IN MX 50 fb.mail.gandi.net.
; SPF
@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"
; DMARC
_dmarc 10800 IN TXT "v=DMARC1; p=reject; rua=mailto:admin@mondomaine.tld"
; DKIM
gm1._domainkey 10800 IN CNAME gm1.gandimail.net.
gm2._domainkey 10800 IN CNAME gm2.gandimail.net.
gm3._domainkey 10800 IN CNAME gm3.gandimail.net.

Le temps de passer l’expiration des DNS, et on vérifie que les nouveaux messages arrivent bien dans la boite aux lettres Gandi.

Récupération de l’historique

Maintenant que les nouveaux messages arrivent dans les boites Gandi, il reste à récupérer l’historique. Pour cela, j’ai utilisé l’excellent imapsync.

Cet outil dispose de très nombreuses options particulièrement utiles dans le cadre de cette migration :

un mode spécial "GMail", qui active des options bien pensées :
- la conversion automatique des tags en dossiers.
- le dédoublonnage des messages ayant plusieurs tags.
- la synchronisation en dernier du dossier "[Gmail]/All Mail" (on ne trouve dans ce dossier que les messages archivés qui n’avaient aucun tag).
- etc.
la possibilité d’arrêter et de reprendre la synchronisation ultérieurement.

Au même titre que le mode "GMail", il existe des modes Office 365, Exchange et Domino.

Configuration Google préalable

Avant la migration, il faut dans les paramètres de la boite autoriser la connecion IMAP.

Il faut également permettre à imapsync de se connecter. Dans les paramètres de Mon compte Google :

si on a activé l’identification à deux facteurs, il faut générer un mot de passe d’application à usage unique.
dans le cas contraire, il est possible d’activer "l’accès moins sécurisé".

Cette dernière possibilité disparaît le 30 mai 2022.

Lancement de la migration

imapsync --gmail1 --user1 adresse@mondomaine.tld --password1 MonAncienSuperMotDePasse --host2 mail.gandi.net --user2 adresse@mondomaine.tld --password2 MonNouveauSuperMotDePasse

Et le reste ?

La messagerie était le service principal que nous utilisions. Mais nous avions également un peu de Google Drive, la synchronisation des contacts et des calendriers.

Sur l’ensemble de l’opération, j’ai trouvé Google exemplaire dans les possibilités offertes de récupérer ses données pour les migrer ailleurs.

Quelques exemples

un accès IMAP simple à mettre en place, y compris quand on a activé l’identification à deux facteurs.
de multiples formats d’export standard pour les contacts (csv, vCard, etc.) et les calendriers (ics, etc.).
Google Takeout, pour l’export de toutes ses autres données.

Pour les contacts/calendriers, notre besoin principal était la synchronisation sur le téléphone. Et comme nous utilisons des iPhone, nous avons opté dans un premier temps pour iCloud.

Par rapport à l’export Google, l’expérience de l’import sur iCloud et de son utilisation est assez catastrophique (l’interface web est minimaliste en ergonomie et en fonctionnalités).

Quelques exemples

pas de gestion de fusion des contacts en doublon.
pas de possibilité d’importer un calendrier à partir d’un fichier ics (il faut obligatoirement passer par l’application dédiée sur un Mac pour ça).

Finalement, je suis déçu par le manque d’efforts d’Apple sur ces produits. Si j’ai le temps, j’essayerai de trouver une meilleure alternative.

Je commence tout juste à regarder Nextcloud… même si ça me semble très lourd par rapport au besoin, et qu’on revient à de l’auto-hébergement que je préférerais éviter.

Bilan

La migration est terminée, et les nouvelles habitudes se prennent vite. Plusieurs fonctionnalités me manquent… en particulier la gestion des comptes multiples, et la possibilité de passer rapidement de l’un à l’autre sans avoir besoin de se déconnecter/reconnecter.

Pour remédier au problème, ainsi qu’au manque de fonctionnalités et d’ergonomie, je vais probablement gérer mes messages depuis un logiciel client (Thunderbird par exemple), alors que je n’utilisais plus que l’interface web.

P.S. Pour les retardataires, Google vient de repousser d’un mois la date limite pour migrer vers Google Workspace ou ailleurs. Ils proposent une offre spéciale de migration "Starter Pack" à 3$ par utilisateur et par mois.

Mon Devoxx France 2022

Wed, 27 Apr 2022 00:00:00 +0200

Enfin !

Après quelques années d’absence, j’avais réservé ma place pour Devoxx 2020… qui a été annulé (avec raison). J’aurais pu participer à l’édition 2021, mais malgré l’obligation du pass vaccinal, j’ai préféré décliner par peur d’un grand rassemblement en période COVID.

Nous voici donc en 2022, et je suis bien décidé à participer cette fois ! Je m’inscris donc via la formation Oxiane.

Commençons par ce qui fâche

Faux départ

Avant d’arriver, le premier désagrément viendra de la RATP, avec un incident sur ma ligne (RER B) et le retard qui va avec. Sur les 3 jours de conférence, soit 6 trajets, j’ai rencontré 4 incidents sur cette ligne ! La RATP n’est pas fautive dans tous les cas (personnes sur les voies…), mais il demeure que "l’expérience utilisateur" est très mauvaise (retard et rames bondées).

L’enregistrement

Ayant pris de l’avance, j’arrive finalement juste avant l’heure de début… pour tomber sur la file d’attente Oxiane. Il faudra 45 minutes pour signer la feuille d’émargement et récupérer le badge.

Immédiatement après la conférence, nous avons reçu un message d’excuse, ainsi que l’explication de ce délai anormal (un bug informatique !). J’ai donc bon espoir que ça ne se reproduira plus… même s’il aurait sans doute été possible de faire mieux (reporter l’émargement au cours de la journée en demandant de repasser à l’accueil ou sur le stand par exemple).

Le port du masque

Malgré la consigne de port du masque, j’ai trouvé que celle-ci n’était que moyennement respectée. Elle l’était par une grande majorité des participants, mais où qu’on regarde, on tombait toujours sur plusieurs personnes non masquées. Je comprends le relâchement, mais j’ai trouvé ça dommage.

Depuis la fin de la conférence, plusieurs messages sur les réseaux sociaux de participants ayant attrapé la COVID. Je ne suis pas expert, mais vu le brassage durant ces 3 jours, je suis loin d’être persuadé que le laxisme soit en cause dans ces contaminations…

Une conférence au top !

Les quelques réserves ci-dessus ne me font pas perdre de vue l’essentiel : la conférence était géniale, et l’organisation fantastique !

L’organisation

Malgré les plus de 3000 participants, la circulation a toujours été fluide, y compris pour l’heure du repas ou le "Meet and greet". Lorsqu’une salle était pleine, on était redirigée vers les autres conférences, ou vers un lieu de rediffusion. J’imagine à peine le travail que ça a demandé aux gilets rouges, tant en amont que pendant la conférence.

Des rencontres "IRL"

Devoxx, c’est toujours l’occasion de revoir des connaissances… et de s’en faire de nouvelles ! Et après plusieurs années de crise sanitaire pendant lesquelles on ne s’était pas vus, c’était particulièrement plaisant !

Des stands sympas

Avant même de parler des conférences elles-mêmes, il y avait pas mal de choses intéressantes à voir sur les stands. Une toute petite sélection :

Le stand Commit Strip (et sa fresque), sur lequel j’ai pu acheter le dernier tome (dédicacé) "The summer of code".
Le stand voisin des Webosaures, et leur incroyable exposition de machines rétros.
Le stand Axa, pour leur sympatique jeu vidéo à base de Leap Motion (ça faisait longtemps que j’en avais vu un).
Et tous les autres stands pour leurs goodies… Que serait un Devoxx sans goodies ?

Les conférences

Elles seront bientôt disponibles sur la chaîne Youtube Devoxx France. Et comme elles étaient toutes excellentes, je ne peux que vous recommander de filer les voir !

Mes coups de cœur

Parmi celles auxquelles j’ai assisté : il en manque donc 95%, ce qui donnera une sélection très peu objective. Et ce d’autant plus que j’ai manqué plusieurs conférences qui me faisaient très envie, faute de place disponible : il faudra donc que j’attende pour les voir.

La keynote "La quête d’une gouvernance collaborative du web" de Lê Nguyên Hoang, et son outil de recommandation Tournesol qu’il me tarde de tester.
La conférence "Valhalla: To the Hell and Back" de Rémi Forax, parceque c’est toujours intéressant de voir l’envers du décor et de comprendre les cheminements et les problématiques rencontrées dans l’implémentation des fonctionnalités du langage.
"Doctolib a besoin d’une base de données plus puissante. Ok, mais laquelle ?" de Bertrand Paquet et David Gageot, pour la même raison.
"Cryptanalyse de la machine Enigma : entre espionnage et mathématiques" de Jean-Christophe Sirot.
"Qu’est-ce que l’InnerSource ? Comment ça se met en place et pourquoi ça va améliorer votre IT … mais pas que ?" par Philippe Charrière et Matthieu Vincent.

Des choses à tester

Au cours de ces 3 jours, j’ai noté (lors des conférences ou sur les stands) un certain nombre de choses à tester (au travail ou sur des projets personnels) :

Programmer une extension de navigateur : parce qu’après avoir assisté à la conférence "Gagner du temps en créant des extensions pour vos navigateurs", ça semble finalement assez abordable. Bon… encore faut-il trouver une idée d’extension.
La nouvelle fonction Recorder de Chrome. Ça semble super pour automatiser le rejeu de scénarios de tests manuels en développement web.
Les générateurs de pipeline To be continuous (ou l’équivalent de Sopra-Steria mais dont je ne retrouve plus le lien) pour Gitlab.
La librairie Test Containers pour automatiser l’instanciation de conteneurs Docker pour les tests d’intégration.
Le WASM (généré à partir de Rust)… mais là encore, il faudrait tout d’abord avoir une idée de cas d’utilisation.
Vite en remplacement de Webpack pour la construction des applications web.

Et pas mal d’autres choses encore…

Conclusion

Un énorme merci à toute l’équipe pour cette super édition des 10 ans !

En espérant que l’année prochaine, la situation permette de reprendre les Devoxx4Kids dans la foulée de la conférence !

Adieu Google Analytics

Wed, 23 Feb 2022 00:00:00 +0100

Il y a plus d’un an, j’écrivais en conclusion d’un article :

Je n’ai conservé qu’un Google Analytics (anonymisé)… mais je le consulte tellement peu que je songe à le supprimer également.

Depuis, je n’ai que très peu pris le temps de m’occuper de ce blog… et encore moins d’en consulter les informations de fréquentation (probablement peu reluisantes). Je peux donc confirmer sans difficulté que je n’ai pas l’utilité de ces statistiques.

Mais, ce qui m’a finalement poussé à mettre à jour ce blog pour supprimer Google Analytics, c’est la récente décision de la CNIL de mettre en demeure une société de cesser son utilisation. La solution de Google n’est en effet pas conforme au RGPD.

C’est donc maintenant chose faite (depuis quelques jours déjà).

Et comme c’était l’unique librairie qui utilisait un cookie, j’ai pu en profiter pour simplifier les mentions légales et supprimer le bandeau d’avertissement. Enfin, je n’ai pour l’instant aucune intention de mettre en place une solution de statistiques de remplacement (même si la CNIL en propose un certain nombre).

Terraformisation de l’infrastructure VSphere existante

Thu, 11 Feb 2021 00:00:00 +0100

Introduction

Dans l’article précédent, nous avons vu comment gérer notre infrastructure VSphere avec Terraform.

Lorsque nous mettons cela en place sur un serveur VSphere existant, il peut déjà contenir des machines virtuelles, qui ne sont pas gérées par Terraform. On peut donc souhaiter réintégrer ces machines dans Terraform.

Une solution est évidemment de les supprimer pour les recréer avec Terraform, mais on ne souhaite pas nécessairement utiliser une méthode aussi radicale.

Déclaration de la machine

En utilisant le module décrit dans l’article précédent, nous déclarons la machine, en reprenant ses caractéristiques :

Fichier main.tf

module "vm_preexistante" {
  source = "./modules/ubuntu20.04"

  vm_hostname = "vm_preexistante"
  vm_ip = "192.168.0.15"
  vm_num_cpus = 4
  vm_memory = 4096
  vm_datastore = "datastore1"
  vm_disks = {
    "disk0" = { size = 60 }
}

À ce stade, si on tente d’appliquer le fichier (ou si on demande le plan), Terraform ignorant que la machine existe déjà va vouloir la créer.

Import de la machine

Heureusement, il existe une commande dédiée pour demander à Terraform de réconcilier la VM déclarée et celle qui existe.

Import d’une machine existante

terraform import module.vm_preexistante.vsphere_virtual_machine.ubuntu_server_2004 /datacenter/vm/vm_preexistante

Pour que cette commande fonctionne, quelques points d’attention :

le nom ubuntu_server_2004 doit correspondre exactement à celui de la resource Terraform déclarée dans le module ;
le nom datacenter est le nom réel du Datacenter VSphere, et non le nom qu’on a donnée à la donnée Terraform vsphere_datacenter ;
le /vm qui suit est une constante obligatoire ;
le nom vm_preexistante qui suit est le nom VSphere de la machine virtuelle existante (éventuellement précédé de son arborescence VSphere).

Un fois la machine importée, on vérifie via terraform plan que Terraform ne prévoit plus de créer la machine virtuelle mais uniquement de la mettre à jour. Si le plan nous convient, on l’applique pour finaliser l’opération : la machine est maintenant gérée via Terraform.

Conclusion

On peut ainsi migrer doucement l’ensemble des machines qui existaient dans une gestion centralisée via Terraform… pour plus facilement toutes les détruire en une seule commande.

Déploiement du template VSphere avec Terraform

Tue, 08 Dec 2020 00:00:00 +0100

Introduction

Rappel : dans l’article précédent, nous avons vu comment créer un template VSphere pour Ubuntu 20.04.

Maintenant, que nous avons le template et le fichier de "post-configuration", nous aimerions automatiser son déploiement. Or, il y a un outil pour ça : Terraform. Si l’outil a initialement été conçu pour provisionner des machines dans le cloud, il supporte VSphere.

Je renouvelle l’avertissement de mon post précédent : l’administration système (et Terraform en particulier) n’étant pas ma spécialité, il est possible que le script qui suit contienne des mauvaises pratiques. N’hésitez pas à me le signaler : je corrigerai en conséquence.

Pour utiliser le script qui suit, il est obligatoire d’avoir assigné une adresse IP fixe au template de la machine virtuelle. C’est cette IP fixe qui permet dans la dernière partie du script de s’y connecter pour injecter le script de configuration et l’exécuter.

Structure

Le code Terraform peut être assez redondant. Nous allons donc mutualiser ce qui peut l’être dans un module.

Voici la structure de notre projet :

- main.tf
- files
    - ubuntu20.04_config.sh
- modules
    - ubuntu20.04
        - main.tf

Le module

Fichier modules/ubuntu20.04/main.tf

# Constantes (1)
locals {
  vm_config_file = "ubuntu20.04_config.sh"
  # Ces constantes ont été définies lors de l'installation d'Ubuntu, pour créer le template.
  vm_template_login      = "admin"
  vm_template_password   = "my_secret_password"
  vm_template_ip         = "192.168.0.10"
}

# Infrastructure VSphere.

provider "vsphere" { (2)
  user = "vsphere_user"
  password = "vsphere_password"
  vsphere_server = "vsphere_server"
}

data "vsphere_datacenter" "dc" {
  name = "datacenter"
}

data "vsphere_datastore" "ds" {
  name          = var.vm_datastore
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_compute_cluster" "cluster" {
  name          = "cluster"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "network" {
  name          = "vlan1"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_virtual_machine" "ubuntu2004_template" {
  name          = "ubuntu20.04_template"
  datacenter_id = data.vsphere_datacenter.dc.id
}

# Variables to configure VM. (3)

variable "vm_hostname" {
  description = "VM hostname."
  type        = string
}

variable "vm_ip" {
  description = "VM IP."
  type        = string
}

variable "vm_num_cpus" {
  description = "VM CPUs."
  type        = number
  default     = 1
}

variable "vm_memory" {
  description = "VM memory (MB)."
  type        = number
  default     = 2048
}

variable "vm_datastore" {
  description = "VM datastore."
  type        = string
  default     = "datastore1"
}

# Déclaration des disques (4)
variable "vm_disks" {
  description = "VM memory (MB)."
  type        = map(any)
  default     = {
    disk0 = {
      unit_number = 0
      size = 8 # Taille du template par défaut (en GB).
    }
  }
}

# Déclaration de la VM

resource "vsphere_virtual_machine" "ubuntu_server_2004" {
  name             = var.vm_hostname
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.ds.id
  guest_id         = data.vsphere_virtual_machine.ubuntu2004_template.guest_id
  scsi_type        = data.vsphere_virtual_machine.ubuntu2004_template.scsi_type

  num_cpus = var.vm_num_cpus
  memory   = var.vm_memory

  network_interface {
    network_id = data.vsphere_network.network.id
  }

  # Configuration des disques (4)
  dynamic "disk" {
    for_each = var.vm_disks
    content {
      label = disk.key
      size = disk.value.size
      unit_number = try(disk.value.unit_number, 0)
    }
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.ubuntu2004_template.id
  }

  # Injection et exécution du script de post-configuration

  provisioner "file" {
    source      = "files/${local.vm_config_file}"
    destination = "/tmp/${local.vm_config_file}"

    connection {
      type     = "ssh"
      host     = local.vm_template_ip
      user     = var.vm_template_login
      password = var.vm_template_password
    }
  }

  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/${local.vm_config_file}",
      "echo \"${var.vm_template_password}\" | sudo -S /tmp/${local.vm_config_file} ${var.vm_hostname} ${var.vm_ip}",
      "rm -f /tmp/${local.vm_config_file}",
      "echo \"${var.vm_template_password}\" | sudo -S netplan apply"
    ]

    connection {
      type     = "ssh"
      host     = local.vm_template_ip
      user     = var.vm_template_login
      password = var.vm_template_password
    }
  }
}

1	Les locals permettent d’éviter les répétitions de constantes (ou de précalculer des valeurs en combinant des variables).
2	Pour simplifier le script, j’ai mis les identifiants en dur. Il est possible de les remplacer par des variables, pour éviter que les identifiants se retrouvent en gestion de configuration et/ou si on souhaite adresser de multiples instances VSphere.
3	Les variables permettent d’injecter les éléments de configuration qui varient d’une machine à l’autre.
4	L’utilisation d’une map et d’une boucle permet d’affecter plusieurs disques à notre machine virtuelle en cas de besoin.

Ce module est assez simpliste. Il est possible d’externaliser plus de choses sous la forme de constantes/variables, pour prendre en compte une architecture VMWare plus complexes (multiples datacenters, clusters, réseaux, etc.) Il est également possible d’affecter plusieurs réseaux à une même machine, en utilisant la même technique que pour l’affectation des disques.

La déclaration des machines

Le module étant créé, il ne reste plus qu’à déclarer les machines dans le fichier principal main.tf.

Fichier main.tf

# Première VM, utilisant les valeurs par défaut du template.
module "vm1" {
  source = "./modules/ubuntu20.04"

  vm_hostname = "vm1"
  vm_ip = "192.168.0.11"
}

# Utilisation des variables pour configurer les différents éléments.
module "vm2" {
  source = "./modules/ubuntu20.04"

  vm_hostname = "vm2"
  vm_ip = "192.168.0.12"
  vm_num_cpus = 2
  vm_memory = 4096
  vm_datastore = "datastore2"
  vm_disks = {
    "disk0" = { size = 30 }
    "disk1" = {
      size = 40
      unit_number = 1
    }
    "disk2" = {
      size = 50
      unit_number = 2
    }
  }
}

Le déploiement

Il n’y a plus qu’à exécuter et à laisser Terraform travailler :

terraform init
terraform plan
terraform apply

Conlusion

Terraform, c’est un super-outil pour automatiser le déploiement de l’infrastructure.

C’est aussi un outil "dangereux" : il ne sait pas gérer toutes les modifications d’infrastructure "en place", et en cas de modification d’une machine, il va parfois procéder en la supprimant/recréant. Or, tout le monde n’est pas passé à l’approche infrastructure immutable, où les machines n’hébergent que du code et où les données sont attachées depuis l’extérieur… Si on n’y prête pas attention, on peut donc avoir vite fait de supprimer une machine hébergeant des données de production.

La machine ainsi mise à disposition étant "nue", Il faut ensuite installer/configurer les serveurs/applications. On pourra pour automatiser également cette partie utiliser par exemple Ansible, avec la suite de scripts DebOps pour les serveurs basés sur Debian/Ubuntu.

Template Ubuntu 20.04 sur VSphere

Wed, 02 Dec 2020 00:00:00 +0100

Problématique

On n’a pas tous la chance de travailler dans une société qui déploie applications serverless sur un cluster Kubernetes hébergé dans le cloud… Mais pour beaucoup de sociétés et de cas d’utilisations, de bonnes vieilles machines virtuelles suffisent amplement à couvrir les besoins.

Le sujet auquel nous allons nous ateler est donc de créer un template VSphere pour simplifier le déploiement de machines virtuelles. Normalement, ça ne devrait pas être un problème : lorsqu’on a créé un template de VM sur VSphere, on peut le configurer lorsqu’on le déploie.

Mais voilà… pour ça, il faut que le système d’exploitation soit supporté par la version de VSphere qu’on utilise. Or, Ubuntu (Server) 20.04 n’est supporté qu’à partir de vCenter 6.7U3g (avril 2020). Si on n’a un serveur VSphere à jour, ça va donc moins marcher… et on n’a pas toujours la main sur le serveur.

Avant d’aller plus loin, je précise que je ne suis pas du tout un spécialiste de l’administration système. Le contournement que je propose ci-après n’est donc sans doute pas dans les règles de l’art (mais je n’ai pas trouvé mieux pour l’instant). N’hésitez pas à me faire signe si vous avez de meilleures solutions.

Le template

Pour créer le template, nous allons simplement installer une VM Ubuntu manuellement, en faisant attention à certains points :

À l’installation, on crée le disque de la plus petite taille dont on a besoin, en utilisant LVM, ce qui permettra de le redimensionner en fonction des besoins.

Après l’installation, on applique les opérations indiquées dans cet article VMWare, en particulier la suppression de cloud-init, installé par défaut.

Suppression de cloud-init et modification .

sudo apt purge cloud-init
sudo apt autoremove
sudo rm -rf /etc/cloud
sudo sed -i -e 's|D /tmp|#D /tmp|g' /usr/lib/tmpfiles.d/tmp.conf

Modification du service /lib/systemd/system/open-vm-tools.service

# ...
[Unit]
# ...
After=dbus.service

Si on veut une configuration réseau de la machine en DHCP, il faut savoir qu’Ubuntu ne présente pas par défaut l’adresse MAC en réponse aux requêtes DHCP. On peut immédiatement modifier ce comportement :

Fichier /etc/netplan/00-installer-config.yaml

network:
  ethernets:
    ens192:
      dhcp4: true
      dhcp-identifier: mac
  version: 2

Ces opérations effectuées, on peut convertir la machine virtuelle en template.

Déploiement du template

Comme on l’a vu, lors du déploiement, on ne peut rien configurer si on n’a pas un vCenter à jour. Il va donc falloir configurer la VM manuellement, en effectuant un certain nombre d’opérations :

Changement du nom d’hôte de la machine

Changement du nom d’hôte

sudo hostnamectl set-hostname vm_new_hostname

Changement des clés SSH de la machine

Si on a installé un serveur SSH lors de l’installation Ubuntu, on régénère les clés SSH de la machine pour éviter qu’elles soient identiques sur plusieurs machines distinctes.

Régénération des clés SSH de la machine

rm -f /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
systemctl restart ssh

Changement d’adresse IP

Si on a choisi une IP fixe plutôt qu’une configuration DHCP, la VM a été déployée avec l’adresse IP définie pour le template.

On ne peut dans ce cas déployer qu’une machine virtuelle à la fois (si on la configure en SSH). Après changement de l’adresse IP (ci-dessous), on peut déployer la machine suivante, etc.

Modification de l’adresse IP

sudo sed -i "s|192.168.0.10/24|192.168.0.42/24|" /etc/netplan/00-installer-config.yaml (1)
sudo netplan apply (2)

1	Adresse/masque à remplacer par les valeurs de votre choix.
2	Attention : au moment de la configuration de l’adresse IP définitive de la machine, la connexion SSH est coupée.

Redimentionnement du disque

On suppose ici qu’on n’a configuré à l’installation qu’un seul disque, avec le partitionnement LVM par défaut, soit :

/dev/sda1 pour le bootloader ;
/dev/sda2 /boot ;
/dev/sda3 / ;

Si on a configuré la machine virtuelle avec plus d’espace disque que le template, on doit affecter cet espace .

Création de /dev/sda4 avec l’espace additionnel

fdisk /dev/sda
# Dans la console fdisk
n # Nouvelle partition
4 # Création de sda4 (1)
\n # Début de l'espace disponible (on laisse par défaut).
\n # Affecter tout l'espace disponible (par défaut).
w # Écrire la nouvelle table des partitions

1	À modifier si vous choisissez un partitionnement différent. On peut également laisser vide pour laisser la valeur par défaut.

Redimentionnement LVM de la partition '/'

pvcreate /dev/sda4
vgextend ubuntu-vg /dev/sda4
lvextend -l+100%FREE /dev/ubuntu-vg/ubuntu-lv /dev/sda4
resize2fs /dev/ubuntu-vg/ubuntu-lv

Là aussi, il faudra adapter le script si vous choisissez un partitionnement plus complexe.

Script de configuration

On aimerait maintenant éviter d’effectuer pour chaque machine toutes ces opérations qui sont inutilement répétitives. On crée donc un script de configuration, dont les seuls paramètres sont le nom d’hôte de la machine et son adresse IP (cette partie étant inutile en DHCP).

Script complet de configuration

#!/bin/bash

# Script de configuration d'une VM déployée à partir d'un template Ubuntu Server.
# Le script doit être exécuté avec les droits d'administration.

if [ "$#" -ne 2 ]; then
 echo "Usage: ubuntu_template_config.sh HOSTNAME ADRESSE_IP"
 exit 1
fi

DEST_HOSTNAME=$1
DEST_IP=$2

TEMPLATE_IP=192.168.0.10
DNS_MASK=24

# Modification du nom de la machine.
hostnamectl set-hostname ${DEST_HOSTNAME}

# Modification de l'adresse IP.
sed -i "s|${TEMPLATE_IP}/${DNS_MASK}|${DEST_IP}/${DNS_MASK}|" /etc/netplan/00-installer-config.yaml
# sudo netplan apply (1)

# Régénération des clés SSH de la machine.
rm -f /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
systemctl restart ssh

# Modification de la taille du disque.
# Le template contient déjà les disques sda1 (grub), sda2 ('/boot'), et sda3 ('/' utilisant LVM).

# Si cette ligne est présente dans la sortie d'erreur, cela signifie que le disque a été redimentionné avant déploiement du template.
# On applique alors un redimentionnement LVM pour le prendre en compte.
fdisk -l /dev/sda 2>&1 | grep "GPT PMBR size mismatch"

if [ "$?" -eq 0 ]; then

  # Création de sda4 avec le disque manquant.
  sed -e 's/\s*\([\+0-9a-zA-Z]*\).*/\1/' << EOF | fdisk /dev/sda
    n # Nouvelle partition
    4 # sda4
      # Début de l'espace disponible
      # Fin de l'espace disponible
    w # Écriture de la table des partitions
EOF

  # Extension LVM.
  pvcreate /dev/sda4
  vgextend ubuntu-vg /dev/sda4
  lvextend -l+100%FREE /dev/ubuntu-vg/ubuntu-lv /dev/sda4
  resize2fs /dev/ubuntu-vg/ubuntu-lv
fi

1	On ne reconfigure pas le service réseau immédiatement, car cela aurait pour effet d’arrêter le script si celui-ci est exécuté via SSH. Il ne faut donc pas oublier d’appliquer manuellement la configuration `netplan`.

Ce script suppose un certain nombre de choses sur le template (partitionnement des disques, serveur SSH déjà installé, etc.). Il est bien évidemment à adapter en fonction des choix effectués lors de l’installation.

Le mot de la fin

Ubuntu 20.04 n’était évidemment qu’un exemple. On peut décliner cette méthode pour créer un script de "post-configuration" pour d’autres distributions dont la configuration n’est pas directement possible sur VSphere.

Vers Gitlab Pages en douceur

Mon, 30 Nov 2020 00:00:00 +0100

À l’origine

Dans cet article, j’expliquais comment ce blog est déployé automatiquement lors d’un git push via un script Gitlab CI.

Et puis je suis tombé sur ce tuto de Philippe Charrière, où il explique comment déployer un blog statique sur Gitlab Pages. Bon… c’était juste avant de migrer vers un blog à base de tickets Gilab. Et même si je trouve le concept génial, je ne suis pas tout à fait près à franchir le pas.

En revanche, le tuto m’a bien donné envie d’essayer de publier sur Gitlab Pages, et ce d’autant plus que les sources sont déjà hébergées sur Gitlab. À terme, cela pourrait me permettre de me passer de la Dedibox que j’utilise actuellement pour l’hébergement.

Mise en œuvre

Par rapport au tuto, deux différences qui semblent faciles à contourner :

le blog n’est pas directement constitué de pages, mais il est construit avec Jekyll ;
il doit être déployé simultanément sur la Dedibox actuelle, et sur Gilab Pages (au moins dans un premier temps).

Le premier essai naïf

Il semble y avoir très peu de choses à modifier par rapport à l’ancienne version, et il s’agit d’ailleurs exclusivement de renommage :

l’étape de construction doit s’appeler pages (et non build ou autre chose) ;
le site doit être construit dans le répertoire public.

Divulgâchis : ne vous précipitez pas sur cette première version… elle ne fonctionne pas comme prévu.

Premier essai de configuration ".gitlab-ci.yml"

image: ruby:2.6

stages:
  - pages
  - deploy

variables:
  JEKYLL_ENV: production
  LC_ALL: C.UTF-8

cache:
  paths:
    - /vendor

before_script:
  - gem install bundler
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'

pages:
  stage: pages
  script:
    - bundle install --path=/vendor
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  only:
    - master

deploy:
  stage: deploy
  script:
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - "scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r public $BLOG_USER@$BLOG_SERVER:~/blog/"
  dependencies:
    - pages
  only:
  - master

Le problème

Techniquement, ça se déploie bien. En revanche, tous les liens du site sur Gitlab Pages sont cassés, et le résultat est inutilisable.

Celà vient du fait que les pages sont déployées à l’adresse https://bcourtine.gitlab.io/blog/, alors que le site autohébergé est servi à l’adresse https://blog.courtine.org/ sans préfixe. Et je ne sais pas s’il est possible de modifier facilement ce point pour héberger directement à l’adresse https://bcourtine.gitlab.io/.

Pour y remédier, nous allons donc jouer avec les templates Jekyll :

on ajoute au fichier _config.yml une propriété baseurl (si elle n’existe pas encore) ;
on n’oublie pas de la prendre en compte également dans les variables Asciidoc du fichier ;
on vérifie que les liens dans les templates Jekyll sont tous bien préfixés par cette variable (par exemple {{ post.url | prepend: site.baseurl }}).

Extrait de _config.yml

# ...

baseurl: '' # '/blog' pour Gitlab Pages
url: 'https://blog.courtine.org'

permalink: '/:year/:month/:day/:title/'

jsdir: '/js' (1)
stylesdir: '/css' (2)
imagesdir: '/images' (2)

asciidoctor:
  base_dir: :docdir
  attributes:
    imagesdir: '{site.baseurl}/images'
    iconsdir: '{site.imagesdir}/icons'
    stylesdir: '{site.baseurl}/css'
    # ...

1	À utiliser dans les templates sous la forme `{{ site.jsdir \| prepend: site.baseurl }}`.
2	Idem.

Comme ces variables sont évaluées au moment de la construction du site par Jekyll, on n’a pas le choix de construire deux fois le blog, en modifiant les variables entre les deux constructions. Un simple sed fait l’affaire pour ça.

Voici donc la configuration Gitlab qui marche pour mon cas d’utilisation.

Configuration ".gitlab-ci.yml" fonctionnelle

image: ruby:2.6

stages:
  - pages
  - deploy

variables:
  JEKYLL_ENV: production
  LC_ALL: C.UTF-8

cache:
  paths:
    - /vendor

before_script:
  - gem install bundler
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'

pages:
  stage: pages
  script:
    - bundle install --path=/vendor

    # Build for https://blog.courtine.org/
    - bundle exec jekyll build -d _site

    # Replace url and build for Gitlab Pages
    - "sed -i \"s|^url:.*|url: 'https://bcourtine.gitlab.io'|\" _config.yml"
    - "sed -i \"s|^baseurl:.*|baseurl: '/blog'|\" _config.yml"
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - _site
      - public
  only:
    - master

deploy:
  stage: deploy
  script:
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - "scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r _site $BLOG_USER@$BLOG_SERVER:~/blog/"
  dependencies:
    - pages
  only:
  - master

Il faut bien penser à mettre à jour la visibilité des pages pour rendre le site public si le dépôt est privé (les pages sont également privées par défaut dans ce cas).

Google analytics

J’utilise Google Analytics pour connaître la fréquentation (ridicule) du blog, et les articles les plus consultés. Or, avec ce double déploiement, les pages /article et /blog/article sont référencées de manière distincte, là où je voudrais un comptage unique des consultations.

Mais Google Analytics a une manière élégante de résoudre ce problème. Dans Admin > All Filters, il est possible d’ajouter des filtres. Nous créons donc un filtre de type Custom > Search and Replace : sur le champ Request URI, on remplace /blog/ par / et le tour est joué.

Conclusion

Avec finalement peu d’efforts, tout marche comme on veut : merci Philippe !

Lors de cette opération, j’ai fait un passage en revue des templates (j’avais parfois été fainéant en omettant le filtre prepend). J’en ai profité pour nettoyer un peu et ne garder que le minimum :

Suppression de Disqus, qui était très peu utilisé ;
Suppression des liens de partage sur les réseaux sociaux, pour la même raison ;

Je n’ai conservé qu’un Google Analytics (anonymisé)… mais je le consulte tellement peu que je songe à le supprimer également.

Bureau de télétravail

Thu, 26 Nov 2020 00:00:00 +0100

En image

En détail

Depuis maintenant presque un an, avec la Covid-19, le télétravail est devenu la norme (même si j’en faisais ponctuellement avant). Et pour travailler dans de bonnes conditions, voici le matériel en détail :

Un fauteuil "gaming" réglable.
Un meuble de récupération… je suis incapable d’en donner sa référence.
Un pot de crayons (et du papier dans le tiroir) : je n’ai encore rien trouvé de mieux pour réfléchir…
Trois écrans (dont deux QHD). Le dernier est arrivé récemment : il devait à l’origine remplacer l’écran Full-HD… mais ma carte graphique ayant trois sorties vidéo, j’ai finalement gardé les trois. Ce n’est pas indispensable, mais on y trouve vite un intérêt.
Un ordinateur (fixe !) sous Linux Mint. Au travail, nous sommes aussi sur des postes fixes : je travaille donc en synchronisant les éléments sur lesquels je travaille (via git essentiellement).

J’ai un PC portable Dell (également sous Mint), sur lequel tous mes outils de développement sont installés et prêts à l’emploi… mais en pratique, je l’utilise beaucoup plus rarement.

Pour la communication :

Une webcam Logitech C920.
Un micro Blue Yeti.
Un casque Bose QC 35 II.
Un DAC Fiio X3 II (bien plus pour la musique que pour les visioconférences).
Une lampe à orientation/éclairage variable (pour l’éclairage en visioconférence).

Les accessoires :

Une souris ergonomique (d’une marque inconnue) : avant de découvrir, j’étais sujet à des douleurs/tendinites qui ont complètement disparu depuis.
Un clavier Logitech G910. J’aime le toucher d’un clavier mécanique, et les "touches macro" peuvent facilement être mises à profit pour les raccourcis de programmes ou raccourcis de développements.
Un switch USB avec interrupteurs (permettant d’allumer/éteindre la webcam le micro, etc. sans avoir besoin de les débrancher).

L’air de rien, ces petits accessoires augmentent nettement le confort de travail.

Ressenti

Le meuble qui est l’élément principal que je souhaiterait remplacer dans cette installation :

Les placards latéraux ne me servent pas au quotidien, et laissent peu de place sur les jambes.
Le bureau n’est pas réglable en hauteur (et ne me permet donc pas de tester le "développement debout").

Cependant, je reste satisfait de cette installation, et j’y travaille confortablement. En particulier, j’apprécie bien l’espace surélevé sur le bureau qui met les écrans à bonne hauteur.

Le calendrier cinéma vu du front

Tue, 17 Sep 2019 00:00:00 +0200

La problématique

Les semaines cinéma en France démarrent le mercredi, jour de sortie en salle des nouveaux films. Ce problème a déjà été expliqué dans cet article, et traité en java.

Mais il n’y a pas que le java dans la vie… et on a le même besoin pour la partie frontend de nos applications.

Le code historique

Nous avons longtemps traité ce problème avec du code utilitaire, basé sur les objets Date, en javascript et plus récemment en typescript (les algorithmes étant identiques à ceux que nous utilisions en java, avant la migration Java 8).

Quelques méthodes historiques

export function getSemaineCinema(date: Date): number { /* ... */ }
export function getAnneeCinema(date: Date): number { /* ... */ }
export function getPremierJourAnneeCinema(annee: number): Date { /* ... */ }
export function getPremierJourSemaineCinema(date: Date): Date { /* ... */ }
// etc.

Moment.js à la rescousse

Moment.js, c’est le Joda-Time du monde JS.

Or, il permet de définir une locale personnalisée… dont un champ "weeks", composé des deux valeurs qui correspondent aux possibilités de configuration de la classe WeekFields utilisée en Java 8 (et supérieur). :

export const configureFrCineLocale = () => {
  moment.defineLocale("fr_cine", {
    week: {
      dow: 3, (1)
      doy: 6, (2)
    },
    months: ["Janvier", "Février", /* ... */],
    monthsShort: ["Jan", "Fév", /* ... */],
    weekdays: ["Dimanche", "Lundi", /* ... */], (3)
    weekdaysShort: ["Dim", "Lun", /* ... */], (3)
    weekdaysMin: ["Di", "Lu", /* ... */], (3)
    // ...
  });

  moment.locale("fr_cine");
};

1	Jour de la semaine débutant la semaine, ici le mercredi.
2	Jour de la semaine qui doit être dans l’année courante.
3	Attention à ne pas oublier que les libellés des jours commencent au dimanche.

Initialement, nous avions interprété doy comme le "nombre de jours de la semaine dans l’année courante", comme dans l’API Java. Mais l’API Moment.js fonctionne différemment : l’année de la semaine cinéma doit contenir le jour 7 + dow - doy (cf. documentation). Comme l’année cinéma de la semaine doit contenir le 4 janvier et commencer un mercredi, on obtient doy = 6 (4 = 7 + 3 - 6).

Une fois cette locale définie et configurée, Moment.js fournit toutes les méthodes permettant d’obtenir les valeurs que l’on souhaite (semaine et année cinéma d’une date donnée, etc.).

Toutes les méthodes de notre librairie maison, ont ainsi presque toutes été réduites à une ligne.

Bonus : l’interface graphique

Si nous utilisons du code JS, c’est essentiellement pour aboutir à des interfaces web. Le code que nous développons pour nos nouveaux besoins repose principalement sur React, ainsi que les bibliothèques de composant Ant Design. Or, celle-ci dispose de composants DatePicker/WeekPicker reposant sur Moment.js, et sur sa locale configurée. Ainsi, sans autre développement que la configuration ci-dessus, nous obtenons par exemple un WeekPicker qui est un "Semaine cinéma picker", correspondant très bien à nos besoins.

Déploiement du blog avec Gitlab-CI

Mon, 11 Mar 2019 00:00:00 +0100

Au début…

La première version de ce blog statique était mise en production manuellement :

Construction et test du site en local, sur ma machine de développement.
Déploiement du site construit via rsync.

Pour les besoins d’un blog perso, ça suffit amplement. Cependant, ce blog servant également à faire des tests, je voulus aller plus loin.

Déploiement continu V1

Ce blog étant initialement hébergé sur un beau serveur dédié Dedibox, il y avait la place pour d’autres services. Entre autres, Gitorious et Jenkins.

La premier script de déploiement continu fut donc l’occasion de tester (et d’approuver) les pipelines.

Plus tard, le code fut migré vers Bitbucket, un des premiers hébergeurs à proposer des dépôts privés gratuitement. Le pipeline de déploiement a été conservé sur Jenkins.

Vers Gitlab

D’autres offres existent :

La dernière en date, Github propose depuis peu des dépôt privés gratuits.
Gitlab également, avec en plus 2000 heures mensuelles de calcul sur des instances Gitlab Runner partagées.

C’est cette dernière option qui m’a convaincu de migrer l’hébergement des sources du blog. Elle m’a également fourni un remplaçant plus simple au pipeline Jenkins de déploiement continu. L’existence de ce remplaçant a aidé à la décision d’abandonner la Dédibox.

Il ne restait plus qu’à écrire le script de déploiement .gitlab-ci.yml. Je me suis pour cela inspiré de la documentation et des posts de Philippe Charrière.

Déploiement continu d’un site Jekyll via SSH

image: ruby:2.6

stages:
  - build
  - deploy

variables:
  JEKYLL_ENV: production
  LC_ALL: C.UTF-8

cache: (1)
  paths:
    - /vendor

before_script:
  - gem install bundler
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )' (2)

build:
  stage: build
  script:
    - bundle install --path=/vendor
    - bundle exec jekyll build -d blog
  artifacts: (3)
    paths:
      - blog

deploy:
  stage: deploy
  script:
    - mkdir .ssh
    - chmod 700 .ssh
    - echo $KNOWN_HOSTS > .ssh/known_hosts (4)
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - "scp -r blog $BLOG_USER@$BLOG_SERVER:" (5)
  dependencies: (3)
    - build
  only:
    - master

1	L’utilisation du cache permet de conserver les gems d’un build au suivant.
2	Précaution non nécessaire pour cette image, qui contient déjà `ssh-agent`.
3	La déclaration d’un artefact dans une étape de build permet de réutiliser celui-ci dans une étape ultérieure, via une dépendance.
4	Utilisation des secrets Gitlab : les variables définies dans le projet sont injectées lors de l’exécution du script.
5	`rsync` est plus adapté, mais n’est pas installé par défaut dans l’image `ruby`.

Avec ce pipeline, le site est construit à chaque push sur Gitlab, et la branche master déployée automatiquement.

Conclusion

Ce nouveau script de déploiement me donne plainement satisfaction, en particulier pour sa simplicité : un seul service (Gitlab) gère le code, l’intégration continue, et le déploiement.

Une alternative aurait pu être d’utiliser Cloudbess Codeship. Mais cette solution aurait nécessité un service supplémentaire. C’est la raison pour laquelle je me suis plutôt orienté vers Gitlab, dont j’apprécie la simplicité et l’approche "tout en un".

Blog d'un ingénieur informaticien parmi d'autres...

Adieu Google Suite

Le drame

Trouver une alternative

GMail

Office 365

Les autres

Le choix

La migration

Adresses et enregistrements DNS

Récupération de l’historique

Et le reste ?

Bilan

Mon Devoxx France 2022

Enfin !

Commençons par ce qui fâche

Une conférence au top !

Les conférences

Conclusion

Adieu Google Analytics

Terraformisation de l’infrastructure VSphere existante

Introduction

Déclaration de la machine

Import de la machine

Conclusion

Déploiement du template VSphere avec Terraform

Introduction

Structure

Le module

La déclaration des machines

Le déploiement

Conlusion

Template Ubuntu 20.04 sur VSphere

Problématique

Le template

Déploiement du template

Changement du nom d’hôte de la machine

Changement des clés SSH de la machine

Changement d’adresse IP

Redimentionnement du disque

Script de configuration

Le mot de la fin

Vers Gitlab Pages en douceur

À l’origine

Mise en œuvre

Le premier essai naïf

Le problème

Google analytics

Conclusion

Bureau de télétravail

En image

En détail

Ressenti

Le calendrier cinéma vu du front

La problématique

Le code historique

Moment.js à la rescousse

Bonus : l’interface graphique

Déploiement du blog avec Gitlab-CI

Au début…​

Déploiement continu V1

Vers Gitlab

Conclusion

Au début…