Gitlab CI: Pipeline maven

Le Gitlab CI intègre depuis la version 8.8 de Gitlab la notion de pipeline. C’est une notion très à la mode permettant de pouvoir séparer son processus de build en plusieurs étapes distinctes, interdépendantes et parallélisables.

Nous allons prendre ici l’exemple d’une application SpringBoot utilisant Maven et créer un pipeline de construction de l’application ayant le cheminement suivant

  • Construction de l’application
  • Tests unitaires
  • Tests de qualité de code (sonar)
  • Déploiement Nexus (SNAPSHOT)
  • Déploiement Nexus (release, branche master uniquement)

Continuer à lire

Ansible: variables chiffrées hors d’un vault-file

Ansible dispose d’un moyen pour chiffrer les mots de passe appelé le vault. Les vaults sont des fichiers, généralement disposés au sein de l’inventaire ansible qui sont entièrement chiffrés.

Dans un système entièrement industrialisé, on retrouve généralement ansible accompagné d’un SCM comme git afin de versionner le code et l’inventaire de l’infrastructure.L’utilisation d’un ou plusieurs vault files pour les mots de passe pose un souci, les variables chiffrées (nom et valeurs) sont tous au sein du vault et donc tous chiffrés. Lors d’un changement sur un mot de passe unitaire au sein d’une vault, le différentiel du SCM montrera un changement global de la vault, et non le changement unitaire du mot de passe. Continuer à lire

Ansible: améliorer la sortie écran

Ansible est un très bon ordonnanceur, avec une sortie relativement claire, néanmoins il se peut que vous ayez envie de l’améliorer.

La sortie standard Ansible utilise le plugin CallbackModule présent dans le répertoire lib/ansible/plugins/callback/default.py. Nous allons ici bénéficier de la possibilité de définir nos propres callback plugins et de l’héritage objet Python pour pouvoir améliorer facilement la sortie Ansible. Continuer à lire

PostgreSQL: changer le owner de toutes les tables/séquences d’un schéma

Lors d’une restauration de base de données, parfois il se peut que vous ayez besoin de changer le propriétaire d’une table ou d’une séquence pour un autre user, par exemple si vous prenez une base de production pour la mettre sur votre intégration pour vos développeurs (anonymisées, bien sûr 😉 ).

Plutôt que de devoir faire fastidieusement un ALTER TABLE table par table, voici 2 requêtes SQL qui vont vous permettre de générer les SQL pour changer rapidement le owner de toutes les tables et séquences: Continuer à lire

PostgreSQL: supprimer toutes les tables d’un schéma rapidement

Parfois, il peut être utile de supprimer toutes les tables d’un schéma directement, notamment si vous souhaitez réimporter un backup depuis un autre environnement.

Il peut être fastidieux de faire des DROP TABLE unitaires, heureusement les schémas PostgreSQL respectent la norme SQL. Contrairement à MySQL qui mélange la notion de base de données et schéma, sur PostgreSQL les bases de données peuvent comporter plusieurs schémas.

Continuer à lire

Gestion de LetsEncrypt sous FreeBSD avec nginx et une jail

LetsEncypt est une autorité de certification utilisant une API basée sur des appels HTTP et un client côté serveur qui va générer des tokens lus par les serveurs LetsEncrypt.

Nous allons ici voir une architecture LetsEncrypt typique dans laquelle nous allons utiliser le client acme-client d’OpenBSD disponible dans les ports et les packages FreeBSD.

Installation

Dans un premier temps installez le client sur votre machine hôte (et pas votre jail web):

Continuer à lire

Optimisations BDD: indexes en doublon

Les indexes prennent de l’espace disque et de la mémoire. Les moteurs MySQL/MariaDB/PostgreSQL savent utiliser des indexes plus complexes afin de lire des données nécessitant un seul index donc les champs conditionnant sont inclus dans un index plus complexe.

Exemple ici avec 3 indexes

Si nous faisons une requête filtrant sur le champ id_1 uniquement (SELECT field1 FROM table1 where id_1 = 3), le moteur de BDD est capable d’utiliser 2 indexes: index_b, qui ne contient que id_1 et index_a qui contient id_1 puis id_2.

En revanche, si nous faisons une requête filtrant sur le champ id_2 uniquement (SELECT field1 FROM table1 where id_2 = 6), le moteur de BDD ne pourra utiliser que index_c.

Si nous reprenons index_a, il n’est pas valide car le moteur de BDD lira cet index en trouvant les records discriminants sur id_1 avant les records discriminant sur id_2. Ce n’est pas un chemin optimal pour trouver un résultat dépendant uniquement de id_2. L’ordre des champs d’un index est donc important.

Pour finir, index_a filtrant tout d’abord sur id_1 avant de filtrer sur id_2, il sait donc filtrer uniquement sur id_1 et donc index_b est inutile (il prend des ressources disque et mémoire inutiles). Supprimez donc index_b qui prend de l’espace disque et mémoire pour rien.

PostgreSQL: nettoyer complètement un schéma sans effort

Dans certains cas, comme par exemple dans un environnement d’intégration, il peut être intéressant de nettoyer toutes entrées dans votre BDD PostgreSQL. Lorsque le nombre de tables devient grand et surtout lorsque vous avez construit un schéma robuste à base de clefs étrangères, il peut être fastidieux de nettoyer ce schéma.

Heureusement, il est possible de nettoyer votre base en demandant à PostgreSQL de générer la requête qui va lister les tables du schéma et les nettoyer. Continuer à lire

Apache: obtenir l’IP source depuis un en-tête conditionel dans les logs

Dans le cadre d’un environnement web haute disponibilité il y a généralement des répartiteurs de charge HTTP comme HAproxy ou des reverse proxies comme Apache ou Nginx en frontal qui vont s’occuper de répartir la charge et/ou filtrer une partie des requêtes pour ménager les serveurs d’application de backend.

Le principal problème rencontré dans ce type d’architecture est que, généralement, le service web de frontend va masquer l’IP source du client, réduisant la tracabilité de celui-ci sur les backends. Nous allons ici partir du principe que le service web de frontend retransmet l’IP au backend via un en-tête HTTP nommé X-Real-IP. Continuer à lire

Ansible: gérer les clefs SSH de ses serveurs

Ansible est un outil d’industrialisation puissant. Il permet notamment de gérer les clefs publiques SSH de vos utilisateurs en les déployant sur un ensemble de machines.

Nous allons ici étudier le module authorized_key fourni par ansible.

Déploiement de clef SSH

Dans un premier temps nous allons parler de la tâche permettant de déployer les clefs SSH. Continuer à lire

Linux: Ajout de CPU à chaud

Sur un système Linux récent (noyau > 2.6.24) il est possible de changer le nombre de CPU de la machines à chaud, qu’on soit en machine virtuelle ou physique.

Pour vérifier l’état d’activation d’un CPU, il suffit d’afficher le fichier concernant le CPU mentionné

Si online est à 1 le CPU est activé et si c’est à 0 il est désactivé

Pour cela il suffit de s’interfacer avec le sous système /sys pour changer l’état actif/inactif du CPU en poussant 0 ou 1 dans le champ online

Pour activer tous les CPU d’un coup, faîtes une boucle:

A des fins de tests vous pouvez également désactiver des CPU en spécifiant 0 au lieu de 1, la seule limitation étant que le cpu0 n’est pas désactivable.

Surcharger le DNS utilisé par dhclient

La configuration DNS sous UNIX est située dans le fichier /etc/resolv.conf.

Dans une configuration classique pour un serveur ce fichier est statique. Il est créé lors de la première installation en se référant au paramétrage spécifié dans l’installeur.

Pour une configuration dynamique en DHCP, généralement un client, c’est le binaire dhclient qui va s’occuper de modifier les lignes de configuration afin de mettre les DNS reçus via DNS ainsi que les zones de recherches et suffixe DNS.

Le principal problème que nous allons essayer de résoudre ici est essentiellement une problématique de type cloud. Continuer à lire