Aller au contenu principal

· 5 minutes de lecture
TheBidouilleur

Introduction à Nix et NixOS

NixOS est une distribution Linux sortie initialement en 2003 et créée par (Eelco Dolstra, un chercheur travaillant sur la création d'un système immuable. Celle-ci se base sur le gestionnaire de paquet Nix qui permet de gérer la configuration du système à l'aide de fichiers Nix (un langage de programmation similaire au Haskell).

Ainsi si je souhaite créer un utilisateur kiko sur mon système, je peux écrire ceci dans mon fichier configuration.nix (qui est le fichier de configuration de l'OS initial)

  users.users.kiko = {
isNormalUser = true;
description = "kiko";
extraGroups = [ "networkmanager" "wheel" "sudo" ];
packages = with pkgs; [
firefox
vim
neovim
kubectl
terraform
];
};

Ou si je veux installer des programmes dans le système, je peux écrire ça :

  environment.systemPackages = with pkgs; [
vim
wget
htop
];

Et là, si vous êtes habitués aux gestionnaires de paquets normaux : vous avez remarqué que mon utilisateur peut installer des librairies de manière autonome.

C'est l'un des points forts de Nix ! Des environnements éphémères, des librairies contradictoires qui peuvent cohabiter, et des utilisateurs entièrements indépendants.

Nix (nous parlons du gestionnaire de paquets) autorise chaque utilisateur à avoir son propre PATH (ex: /run/wrappers/bin:/home/kiko/.nix-profile/bin:/etc/profiles/per-user/kiko/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin ). Mais il ne se limite pas qu'à ça : on peut créer des environnements temporaires assez rapidement pour ne pas avoir à installer un programme et pouvoir s'en servir ponctuellement.

❯ cowsay
The program 'cowsay' is not in your PATH. It is provided by several packages.
You can make it available in an ephemeral shell by typing one of the following:
nix-shell -p cowsay
nix-shell -p neo-cowsay

~
❯ nix-shell -p cowsay
this path will be fetched (0.01 MiB download, 0.05 MiB unpacked):
/nix/store/9647mfqndy0aa8qkniqa05qc9yi575ny-cowsay-3.04
copying path '/nix/store/9647mfqndy0aa8qkniqa05qc9yi575ny-cowsay-3.04' from 'https://cache.nixos.org'...

~ via ❄️ impure (shell)
❯ cowsay "J aime la bidouille"
_____________________
< J aime la bidouille >
---------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||

~ via ❄️ impure (shell)
exit
exit

~ took 44s
❯ cowsay
The program 'cowsay' is not in your PATH. It is provided by several packages.
You can make it available in an ephemeral shell by typing one of the following:
nix-shell -p cowsay
nix-shell -p neo-cowsay

Nous avons créé un environnement similaire au notre.. mais avec le binaire cowsay.

Mais nous avons parlé d'environnement, alors créons un réel nix-shell plus complet...

Nix-Shell

Créons 2 fichiers.

# default.nix
with (import <nixpkgs> {});
let
my-python-packages = python-packages: with python-packages; [
requests
];
python-with-my-packages = python3.withPackages my-python-packages;
in
mkShell {
buildInputs = [
python-with-my-packages
];
}
# app.py
import requests
response = requests.get('http://perdu.com')
print(response.content)

Le fichier app.py est notre très complèxe application tandis que le fichier default.nix décrit l'environnement requis. Si je lance directement l'application python3 app.py je me retrouve avec une erreur car je n'ai pas installé python3 dans mon environnement.. Je peux créer un nix-shell avec python et lancer mon app.py :

❯ nix-shell -p python38 # création d'un env avec python3.8

/tmp/python via 🐍 v3.8.13 via ❄️ impure (shell)
❯ python3 app.py
Traceback (most recent call last):
File "app.py", line 1, in <module>
import requests
ModuleNotFoundError: No module named 'requests'

Mais nous nous retrouvons avec un autre problème de dépendance.. Il est donc possible de créer notre environnement à l'aide du fichier default.nix qui contiendra Python et la librairie requests (indispensable pour notre application.

Par défaut, nix-shell va chercher les fichiers nommés default.nix dans notre répertoire courant.

/tmp/python via 🐍 took 5m28s 
❯ nix-shell

/tmp/python via 🐍 v3.9.13 via ❄️ impure (nix-shell)
❯ python3 app.py
b"<html><head><title>Vous Etes Perdu ?</title></head><body><h1>Perdu sur l'Internet ?</h1><h2>Pas de panique, on va vous aider</h2><strong><pre> * <----- vous &ecirc;tes ici</pre></strong></body></html>\n"

Avec cette méthode, il est possible d'avoir plusieurs environnements pour lancer des applications différentes sans se soucier des effets de bords sur nos autres programmes.

Home-Manager

Si jamais je résume ce que nous avons vu :

  • Comment NixOS peut automatiser une configuration d'OS (On pourrait voir comment l'installer de la même manière)
  • Comment créer des environnements indépendants Il reste un aspect essentiel au passage sur Nix: le déploiement d'une configuration utilisateur !

Nix permet de déployer bien plus que quelques programmes, il existe une librairie d'instruction pour faciliter la configuration/déploiement d'un logiciel. Par exemple, à la création de mon utilisateur quotidien, je dois parametrer Git avec mon nom, et mon mail avant chaque commit..

git config --global user.name "Toto"
git config --global user.email "toto@toto.com"

Avec Nix, je peux créer un fichier dans mon home et garder cette configuration en dur :

  programs = {
git = {
enable = true;
userName = "Toto";
userEmail = "toto@toto.com";
ignores = [
"*~"
"*.swp"
];
};
};

J'ai donc plusieurs fichiers Nix me permettant d'installer mes programmes, de configurer Git, d'installer mon EMacs-Doom avec mes paramètres, de déposer mes dotfiles aux bons endroits. Pour l'instant.. ma configuration est publique et disponible ici, à voir ce que j'en ferai à l'avenir.. :)

Conclusion

Nix est vaste, très vaste, et il peut être compliqué d'en apprendre les bases. La communauté est au courant du manque de documentation et fait beaucoup d'effort pour donner une image agréable à Nix pour les débutants. Je pense que Nix a un potentiel non-négligeable pour les workstations/serveurs et pourrait même remplacer des outils de déploiement d'OS comme Packer.

On peut trouver les instructions / packages sur l'incroyable site search.nix.org. Je pense continuer à apprendre Nix jusqu'à pouvoir moi-même contribuer à la communauté et maintenir mes propres packages.

Seule complexité reste d'apprendre le langage Nix ! Mais avez-vous entendu parler de Guix.. ?

· 5 minutes de lecture
TheBidouilleur

J'ai eu l'occasion de tester de nombreux moyens de transport alternatifs pour des déplacements quotidiens en ville (Trottinettes, Vélo électrique) mais aucun ne m'a jamais autant tenté que la gyroroue ! Depuis que j'ai découvert ce véhicule via les vidéos de Thomas(Mr.Flex sur YouTube), je fantasme sur l'idée de pouvoir m'en servir pour mes déplacements en plus de pouvoir prendre le train, bus ou tram.

Jusque-là, je me déplaçais exclusivement en vélo électrique (avec environ ~10 km pour arriver au travail), seuls les deux-roues m'intéressaient. Puis, pendant mes vacances d'étés de 2022, et étant donné que j'avais beaucoup de temps libre : je me suis dit "Pourquoi pas ?". Je me suis donc procuré un appareil d'occasion nommé le Kingsong ks-16b. Image montrant la gyroroue

Utiliser un appareil d'occasion me rassure pas mal en sachant que je ne veux pas abîmer du neuf, je récupère cette roue avec un kilométrage de 265 km et une batterie de 680Wh (me suffisant pour faire 40km). J'ai essayé de faire au moins 20 minutes d'apprentissages par jour pour me familiariser avec la bête et espérer la maîtriser en moins d'une semaine. (Ce que les gens promettent parfois sur les réseaux.)

Je vais donc résumer dans la prochaine partie mes avancées dans l'apprentissage de la gyroroue.

La longue route

Lundi 08/08

Première séance de 30min. Je comprends à quel point on sous-estime le simple fait de monter sur la roue sans s'appuyer sur un mur. J'arrive à monter avec peine mais je suis surpris de pouvoir y arriver en si peu de temps. Je peux démarrer et faire 1-2m sans tomber.

Mardi 09/08

Je m'accroche pendant une belle heure, objectif : aller d'un point A à un point B. (En l'occurrence : traverser mon garage) Je prends une ceinture (à mettre dans le trolley, ça aide à ce que la roue ne tombe pas alors que je descends de la roue) et je démarre pour faire une simple ligne droite. Aucun succès, pas moyen de faire quelques mètres sans devoir mettre pied à terre. Je ne désespère pas en réussissant à faire le pendule contre un mur mais je suis un peu déçu de ne pas pouvoir faire mieux.

Mercredi 10/08

Mercredi se décompose en 2 séances d'une heure chacune : matin, et après-midi. Le matin, aucune avancée. Des pendules, j'avance contre un mur à droite, j'avance (un peu) contre un mur à gauche mais insatisfait de ma progression. Je me motive à faire une nouvelle séance qui commence de la même manière. (Je traverse un peu mon garage en long mais incapable de me tenir droit) Je suis conscient que je dois aller vite et projeter mon regard, mais comment faire des dizaines de mètres si je n'arrive pas à tenir droit sur 2-3m ? Et en décidant de prendre une grande ligne droite et d'appuyer sur le champignon : j'arrive à me stabiliser pendant les 2-3 premiers mètres avant de continuer sur ma lancée. La solution à comprendre : C'est normal que je sois déséquilibré au début, c'est justement pour trouver ma stabilité ! Je m'amuse à faire 20… 30 et 50 mètres, je n'arrive pas à rouler droit, mais j'avance, et c'est ce qui compte.

Jeudi 11/08

Plein de confiance, je reprends là où je me suis arrêté. Je file plus ou moins droit mais je n'ai aucune difficulté à avancer. Je m'arrête après 20min à cause d'une douleur du pied droit, en sachant que je suis encore très crispé : ça ne m'étonnerait pas que ça soit à cause de mon manque de confiance. J'arrive à faire un virage parfait (pas saccadé), hâte de m'entraîner à faire de belles courbes.

Samedi 13/08

J'arrive à tourner à 90° ! J'ai quelques douleurs musculaires, je prend quelques pauses entre chaque séance pour éviter de conserver ces douleurs.

Samedi 20/08

Après la bonne pause d'une semaine, je profite d'une sortie en famille pour faire de la gyroroue en parc. J'ai roulé ~30min pour une distance d'environ 4km (!). J'arrivais à esquiver les groupes de personnes sans soucis et à atteindre une vitesse de 23km/h. Il me manque surement de la précision, mais je me sens vraiment en confiance.

J'ai bien pensé à enregistrer le trajet via l'application Euc World mais aucun moyen de le partager via le site officiel. Voici une capture d'écran prise le jour-même. Trajet

Equipement

J'envisage de me servir de la roue au quotidien. Et tout comme le vélo, je souhaite m'imposer un certain équipement. Casque intégral (moto, moto-cross ou VTT) et protection au dos seront mon minimum. J'envisage aussi de mettre des genouillères et des protections aux coudes.

Casque

J'ai beaucoup réfléchi à un casque intégral qui pourrait être confortable, pratique et sécurisant. Ma première suggestion était un casque de VTT/BMX qui recouvrirait le menton (pour protéger la machoire) mais je me suis finalement orienté vers un casque moto classique. Lien ici

N'ayant jamais été sur la moindre moto, je trouve ce casque un peu lourd mais j'imagine que c'est un poids correct pour un réel casque intégral. (1.6kg)

Assurance

Pour rouler sur route, je souhaite avoir une assurance pour protéger les gens et me protéger. Comme de nombreux Wheelers, je pense me tourner vers Wizza mes tarifs

En contactant la MAIF (avec laquelle je possède un contrat), j'ai remarqué qu'ils avaient également une offre pour les EDPMs, et donc les gyroroues. Le prix est d'environ 5€/mois.

· 4 minutes de lecture
TheBidouilleur

Je suis en plein apprentissage de Kubernetes et des solutions pour gérer un cluster, je pratique sur un cluster de test sur lequel se trouve des petits conteneurs comme celui gérant thebidouilleur.xyz.

Longhorn est un incontournable dans l'univers Kubernetes (et notamment k3s), je ne pouvais pas continuer à apprendre sans m'attarder sur Longhorn. Mais avant tout..

Qu'est ce que Longhorn ?

Longhorn se présente sous cette simple phrase :

Longhorn is a lightweight, reliable and easy-to-use distributed block storage system for Kubernetes.

Mais on peut aller un peu plus loin que cette simple phrase... Longhorn est système de centralisation de stockage entre les noeuds du cluster. Cela veut dire qu'au lieu d'utiliser un stockage externe comme un NFS (ou autre, voici la liste des possibilités on va pouvoir utiliser garder les données en internes en utiliser les disques de nos machines présentes dans le cluster.

Et si vous vous posez la même question que moi avant de connaitre : Longhorn va faire l'équivalent d'un RAID 0 en réplicant les données sur plusieurs noeuds pour éviter que la perte d'une machine entraine la perte de donnée.

Valeurs concrètes

Par exemple, en comptant les disques de mes noeuds j'ai 4x32Gio et 1x16Gio, soit 144Gio ( ou 132Go parce que Rancher utilise cette valeur ). Sur ces 132Go, j'en occupe 36 actuellement, je peux en utiliser 56 sur Longhorn, et j'en ai 40 réservés aux réplicas. (par défaut, Rancher génère 3 replicas)

panel longhorn

Comment déployer Longhorn ?

lien de la documentation officielle

On peut déployer Longhorn via Helm, le catalogue Rancher ou juste via Kubectl (l'option que j'ai choisi)

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.3.0/deploy/longhorn.yaml

Version !

Attention, cette commande va uniquement déployer la version 1.3.0 de longhorn, pensez à récupérer le dernier lien dans la documentation (ou éditer le lien que j'ai mis)

Par mesure de sécurité, il faut toujours vérifier ce que contient le yaml appliqué. Pensez à jeter un coup d'oeil !

Il faudra attendre que les pods se déploient pour commencer à utiliser Longhorn. Pour vérifier l'état en temps réel, la documentation vous propose la commande suivante:

kubectl get pods \
--namespace longhorn-system \
--watch

Mais vous pouvez aussi bien utiliser k9s.

Une fois OK, nous pourrons déployer notre premier pod lié à longhorn.

Mise en pratique Longhorn

Voici le manifest que l'on va déployer pour utiliser un volume dans longhorn:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: longhorn-nginx-thebidouilleur-demo
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 1Gi
---
apiVersion: v1
kind: Pod
metadata:
name: longhorn-thebidouilleur-demo
namespace: default
spec:
containers:
- name: block-volume-test
image: nginx:stable-alpine
imagePullPolicy: IfNotPresent
volumeMounts:
- name: volume-longhorn
mountPath: "/usr/share/nginx/html"
ports:
- containerPort: 80
volumes:
- name: volume-longhorn
persistentVolumeClaim:
claimName: longhorn-nginx-thebidouilleur-demo

On demande bien 1Gio à allouer à ce volume (ça influera sur le stockage alloué pour les replicas) et on déploie un nginx classique. Une fois déployé, on va ouvrir un tunnel vers ce pod:

kubectl port-forward longhorn-thebidouilleur-demo 8080:80
astuce

En sachant que le tunnel doit s'ouvrir sur votre poste local (et non sur un des noeuds du cluster). Je vous invite à consulter cette page pour mettre kubectl sur votre machine.

et si on interroge le nginx, on tombe évidemment sur une erreur 403 puisque le dossier longhorn est vide. On va donc créer notre fichier index.html directement depuis le pod.

kubectl exec longhorn-thebidouilleur-demo -i -t -- /bin/sh
echo "Hello World" > /usr/share/nginx/html/index.html

Et en réinterrogeant notre pod : on tombe bien sur notre Hello World

[thebidouilleur@bertha ~]$ curl localhost:8080
Hello World

Maintenant.. c'est bien mignon mais est-ce que nous gardons bien notre page en cas de suppression du pod ?

kubectl delete pod longhorn-thebidouilleur-demo

On voit bien que sur le dashboard longhorn : le volume est passé en deattach. (ce qui veut dire que les données sont toujours présentes mais pas utilisées sur un pod)

On va ré-appliquer le même manifest pour recréer notre pod et refaire le même tunnel pour accéder au nginx

[thebidouilleur@bertha ~]$ curl localhost:8080
Hello World

Nous retrouvons bel et bien notre page "Hello World"!

Conclusion

Longhorn est un outil extremement simple d'utilisation et permettant d'éviter de créer une solution externe au cluster qui serait moins pratique à gérer. Je ne suis pas non-plus aller très loin dans ses fonctionnalitées et je vous laisse vous faire votre propre avis pour longhorn en production (et pour ça, allez voir l'article du site easyadmin.tech) Longhorn est le bienvenue dans mon Homelab de test et sera au centre de celui-ci !

· 4 minutes de lecture
TheBidouilleur

Mon premier cluster Kubernetes est actuellement en ligne. C'est encore un banc de test mais je l'ai pris prématurement en prod pour me forcer à l'administrer de manière sérieuse. Aujourd'hui (et en espérant que ça ait déjà évolué lorsque vous lirez l'article), mes pods utilisent un backend storage en NFS (accessible sur mon NAS).

Je veux que Kubernetes devienne mon manager de conteneur principal, je pense donc essentiel de découvrir les particularités générales de Kubernetes avant de commencer à y déployer des applications un peu plus complexes. Le stockage S3 est souvent référencé comme pratique et utile avec Kubernetes.

remarque

J'ai déjà utilisé Minio dans un autre contexte. Mais je ne compte pas utiliser Minio pour débuter S3, je veux une solution déjà prête et générique (apprendre la normalité avant de se spécialiser). Inutile de préciser qu'à l'avenir : Minio sera ma solution principale en Object Storage.

Je me suis donc orienté vers AWS Contabo qui propose une solution bien moins chère que notre amis américain. je paye 2,39€ mensuels pour 250Go à la place des 5,75€ demandés par Amazon.

Qu'est ce que le S3 ?

Pas besoin de faire une définition bancale, voici directement l'explication d'Amazon :

Amazon Simple Storage Service (Amazon S3) est un service de stockage d'objets qui offre une capacité de mise à l'échelle, une disponibilité des données, une sécurité et des performances de pointe. Les clients de toutes les tailles et de tous les secteurs peuvent stocker et protéger n'importe quelle quantité de données pour la quasi-totalité des cas d'utilisation, par exemple les lacs de données ainsi que les applications natives cloud et mobiles. Grâce à des classes de stockage économiques et à des fonctions de gestion faciles à utiliser, vous pouvez optimiser les coûts, organiser les données et configurer des contrôles d'accès affinés pour répondre à des exigences opérationnelles, organisationnelles et de conformité spécifiques.

Traduction : C'est une méthode performante et rapide de transférer des masses de données.

Et comment utiliser un stockage S3 ?

Il convient avant tout de rappeler une notion importante dans l'utilisation d'un Cloud :

Si vous ne stockez pas chez vous : considerez que vos données peuvent être visionnées sans votre concentement. (Gouv, NSA, Mamie, Hacker etc...) Alors il convient de chiffrer vos données. Nous parlerons de Minio dans sur une autre page, une solution libre et open-source à héberger à la maison.

On peut dialoguer avec un serveur S3 via de nombreux outils :

Pour chiffrer mes données, je peux très bien passer par un simple script Bash chiffrant via GPG, puis envoyant les objets vers mon s3. Mais je n'apprécie pas cette solution bancale, et autant utiliser une solution all-in-one comme rclone ou restic. Et c'est effectivement avec restic que l'on va chiffrer et push les données.

Chiffrer puis envoyer ses objets

Comme dit précédemment : restic va être notre outil principal. Celui-ci fonctionne avec un système de "dépot"

Création du dépot restic

Restic permet de créer un dépot (qui peut être distant ou local), ce dépot chiffré sera le lieu où nous enverrons nos objets. Pour une première utilisation, on doit initialiser le dépot avec un restic init qui va créer la structure de fichier, et décider de la clé de chiffrement. Une fois le dépot créer, nous pourrons envoyer nos snapshots.

Restic autorise l'utilisation de variables d'environnement. On peut les définir avant d'utiliser restic.

export AWS_ACCESS_KEY_ID=ab5u8coxxpvjxwq4zu74jifmvfvxfu2y
export AWS_SECRET_ACCESS_KEY=3hs9sopqqto9sf8hhet8i92di987qcs6
bucketName="thebidouilleur" # variable séparée pour pouvoir la réutiliser ailleurs
export RESTIC_PASSWORD=Smudge9476 # Mot de passe de chiffrement
export RESTIC_REPOSITORY="s3:https://eu2.contabostorage.com/${bucketName}"

Ce ne sont pas mes vrais tokens, ne tentez pas d'utiliser les mêmes variables.

On peut enfin laisser restic créer notre dépot :

restic init

Si aucune erreur n'apparait ... félicitation ! On peut faire un restic backup pour créer notre première snapshot !

asciicast

On peut donc réaliser plusieurs sauvegardes assez facilement

· 6 minutes de lecture
TheBidouilleur

[ Cet article provient de mon ancien-blog, celui-ci sera également disponible dans la partie "Documentation" du site ]

Introduction

Bientot 7 ans que mon infra principale est sous Proxmox. C'est l'hyperviseur dans lequel j'ai le plus confiance, et qui est également gratuit. Dès que je dois déployer plus de 2 machines virtuelles et qu eje peux choisir l'environnement : Proxmox sera mon premier choix. Il propose une webui complète et efficace, sans oublier l'avantage des outils en cli. Je n'exclue pas qu'un jour, je puisse changer d'environnement. Et aujourd'hui, j'ai de nouveaux besoins dans mon hyperviseur : Automatiser un déploiement complet de mon infrastructure, et comme je vais pas réinstaller chaque machine individuellement, je dois partir d'une "base" qui servira de template pour que le système des machines soit pré-configuré comme je le souhaite. Et cette fameuse template, je peux la faire à la main.... ou je peux la déployer automatiquement via Packer !

· 8 minutes de lecture
TheBidouilleur

[ Cet article provient de mon ancien-blog, celui-ci sera également disponible dans la partie "Documentation" du site ]

Introduction

Depuis que jai commencé l'informatique (depuis un peu moins d'une dizaine d'année), je ne me suis jamais préoccupé de comment je visualisais mes logs. Un petit view par ci, un gros grep par là.. mais aucune gestion avancée.

J'ai basé ma supervision sur Zabbix et Grafana qui m'affichent les metriques de chaque machine virtuelle individuellement. Et même si c'est bien pratique, je n'ai presque aucun visuel sur l'état de mes applications ! J'ai donc décidé de me renseigner sur Graylog et Elastic Search proposant un stack assez fiable et facile à mettre en place. Puis en voyant les ressources demandées, j'ai remis ce besoin à "plus tard", et j'ai remis "plus tard" à l'année prochaine.. Et ainsi de suite !

2 ans plus tard...

Aujourd'hui (Decembre 2021), une grosse faille 0day est dévoilée concernant Log4J, et on ne parle pas d'une "petite" faille, c'est une bonne grosse RCE comme on les aime !

Je ne suis pas concerné par Log4J, ce n'est pas utilisé dans Jenkins, et je n'ai aucune autre application basée sur Java ouverte sur internet. Mais j'aurai bien aimé savoir si mon serveur a été scanné par les mêmes IP que l'on retrouve sur les listes à bannir. Et c'est avec cet évenement que j'ai décidé de me renseigner sur "Comment centraliser et visualiser ses logs?".

Le choix du stack

Un stack est un groupement de logiciel permettant de répondre à une fonction. Un exemple classique est celui du stack "G.I.T." (et non pas comme l'outil de versioning!) :

  • Grafana
  • Influxdb
  • Telegraf

C'est un stack qui permet de visualiser les mectriques de différentes machines, InfluxDB est la base de donnée stockant les informations, Telegraf est l'agent qui permet aux machines d'envoyer les métriques, et Grafana est le service web permettant de les visualiser.

Comme dit dans l'introduction, j'utilise Zabbix qui me permet de monitorer et collecter les metriques, et j'y ai couplé Grafana pour les afficher avec beaucoup de paramètrages.

Dans la centralisation de logs (et la visualisation), on parle souvent du stack suivant:

ELK:

  • ElasticSearch
  • Logstash
  • Kibana

Mais ce stack n'est pas à déployer dans n'importe quel environnement, il est efficace, mais très lourd.

Dans ma quête pour trouver un stack permettant la centralisation de logs, j'apprécierai utiliser des services que je dispose déjà.
Et voici le miracle à la mode de 2021 ! Le Stack GLP : Grafana, Loki, Promtail.

Stack GLP

Là où j'apprécie particulièrement ce stack, c'est qu'il est léger. Beaucoup plus léger que ELK qui, même si très efficace, demande beaucoup.

De même que Graylog2 + Elastic Search (une très bonne alternative) qui demande presque un serveur baremetal low-cost à lui seul.

Alors que Grafana / Loki ne demanderont que 2Go pour fonctionner efficacement et sans contraintes. (Grand maximum, à mon échelle : j'utiliserai beaucoup moins que 2Go)

Installer notre stack

Je pars du principe que tout le sait installer un Grafana, c'est souvent vers ce service que les gens commencent l'auto-hebergement (en même temps, les graphiques de grafana sont super sexy !).

Mais si vous n'avez pas encore installé votre Grafana (dans ce cas, quittez la salle et revenez plus tard), voici un lien qui vous permettra de le faire assez rapidement

Par simplicité, je ne vais pas utiliser Docker dans cette installation.

Partie Loki

J'ai installé Loki sur un conteneur LXC en suivant le guide sur le site officiel ici. Je passe par systemd pour lancer l'executable, et je créé à l'avance un fichier avec le minimum syndical (qui est disponible sur le github de Grafana)

auth_enabled: false

server:
http_listen_port: 3100
grpc_listen_port: 9096

common:
path_prefix: /tmp/loki
storage:
filesystem:
chunks_directory: /tmp/loki/chunks
rules_directory: /tmp/loki/rules
replication_factor: 1
ring:
instance_addr: 127.0.0.1
kvstore:
store: inmemory

schema_config:
configs:
- from: 2020-10-24
store: boltdb-shipper
object_store: filesystem
schema: v11
index:
prefix: index_
period: 24h

Je n'ai pas pris la peine d'activer l'authentification en sachant que je suis dans un LAN avec uniquement mes machines virtuelles. Je considère pas que mon Loki comme un point sensible de mon infra.

Après seulement 2-3 minutes de configuration, notre Loki est déjà disponible !

On peut dès maintenant l'ajouter en tant que datasource sur notre Grafana : !()[https://i.imgur.com/G3tWx1r.png]

(J'utilise localhost car la machine possédant le grafana héberge également le Loki)

Il se peut que Grafana rale un peu car notre base de donnée Loki est vide.

Partie Promtail

Promtail est l'agent qui va nous permettre d'envoyer nos logs à Loki, j'ai écris un role Ansible assez simple me permettant d'installer notre agent sur de nombreuses machines en surveillant les logs provenant de Docker, varlog et syslog.

Voici ma template Jinja2 à propos de ma configuration :

server:
http_listen_port: 9080
grpc_listen_port: 0

positions:
filename: /tmp/positions.yaml

clients:
{% if loki_url is defined %}
- url: {{ loki_url }}
{% endif %}


scrape_configs:


- job_name: authlog
static_configs:
- targets:
- localhost
labels:
{% if ansible_hostname is defined %}
host: {{ ansible_hostname }}
{% endif %}
job: authlog
__path__: /var/log/auth.log


- job_name: syslog
static_configs:
- targets:
- localhost
labels:
{% if ansible_hostname is defined %}
host: {{ ansible_hostname }}
{% endif %}
job: syslog
__path__: /var/log/syslog

- job_name: Containers
static_configs:
- targets:
- localhost
labels:
{% if ansible_hostname is defined %}
host: {{ ansible_hostname }}
{% endif %}
job: containerslogs
__path__: /var/lib/docker/containers/*/*-json.log

- job_name: DaemonLog
static_configs:
- targets:
- localhost
labels:
{% if ansible_hostname is defined %}
host: {{ ansible_hostname }}
{% endif %}
job: daemon
__path__: /var/log/daemon.log

Si vous n'êtes pas à l'aise avec des templates Jinja2, vous trouverez une version "pure" de la config ici

Vous pouvez bien evidemment adapter cette template à vos besoins. Mon idée première est d'avoir une "base" que je peux mettre sur chaque machine (en sachant aussi que si aucun log n'est disponible, comme pour Docker, Promtail ne causera pas une erreur en ne trouvant pas les fichiers)

Une fois Promtail configuré, on peut le démarrer : via l'executable directement :

/opt/promtail/promtail -config.file /opt/promtail/promtail-local-config.yaml

ou via systemd (automatique si vous passez par mon playbook) :
systemctl start promtail

Une fois cet agent un peu partout, on va directement aller s'amuser sur Grafana !

Faire des requetes à Loki depuis Grafana

On va faire quelque chose d'assez contre-intuitif : nous n'allons pas commencer par faire un Dashboard : on va d'abord tester nos requetes ! Scrollez pas, je vous jure que c'est la partie la plus fun !

Sur Grafana, nous avons un onglet "Explore". Celui-ci va nous donner accès à Loki en écrivant des requetes, celles-ci sont assez simple, et surtout en utilisant l'outil "click-o-drome" en dépliant le Log Browser

Pardon j'ai un chouïa avancé sans vous...

Avec la template que je vous ai donné, vous aurez 4 jobs :

  • daemon
  • authlog
  • syslog
  • containersjobs

Ces jobs permettent de trier les logs, on va tester ça ensemble. Nous allons donc selectionner la machine "Ansible", puis demander le job "authlog". Je commence par cliquer sur Ansible, puis Authlog. Grafana me proposera exactement si je souhaite choisir un fichier spécifique. Si on ne précise pas de fichier(filename) Grafana prendra tous les fichiers (donc aucune importance si nous n'avons qu'un seul fichier)

(vous remarquerez plus tard que dès notre 1ere selection, grafana va cacher les jobs/hôte/fichier qui ne concernent pas notre début de requete)

En validant notre requete (bouton show logs)

Nous avons donc le résultat de la requete vers Loki dans le lapse de temps configuré dans Grafana (1h pour moi). Mon authlog n'est pas très interessant, et mon syslog est pollué par beaucoup de message pas très pertinents.

Nous allons donc commencer à trier nos logs !

En cliquant sur le petit "?" au dessus de notre requete, nous avons une "cheatsheet" résumant les fonctions basiques de Loki. Nous découvrons comment faire une recherche exacte avec |=, comment ignorer les lignes avec != et comment utiliser une expression regulière avec |~

Je vous partage également une cheatsheet un peu plus complète que j'ai trouvé sur un blog : ici

Ainsi, on peut directement obtenir des logs un peu plus colorés qui nous permettrons de cibler l'essentiel !

(L'idée est de cibler les logs sympas avec les couleurs qui vont avec)

Conclusion

Si on entend souvent parler de la suite ELK, ça n'est pas non-plus une raison pour s'en servir à tout prix ! Loki est une bonne alternative proposant des fonctionnalitées basiques qui suffiront pour la plupart.

· 3 minutes de lecture
TheBidouilleur

Changelog (janv 2022) - Aujourd'hui, j'ai remplacé Caddy par Traefik, à voir dans un futur article

Dans ma courte vie d'informaticien, je n'ai toujours eu qu'une seule IP publique. Celle de mon serveur OVH sur lequel vous visualisez le site actuellement. Et en sachant que j'ai de nombreux services Web, il m'a rapidement été nécéssaire de chercher les différents solutions permettant d'installer un Reverse Proxy efficace qui servirait à rediriger mes utilisateurs vers l'application voulue en fonction du domaine.

Dans ma longue quête (qui n'est certainement pas achevée), j'ai eu l'occassion de tester de nombreuses solutions comme Haproxy, Apache2, Nginx et maintenant.. Caddy

Haproxy a été pour moi le plus facile et le plus pratique pour démarrer, bonne documentation, incorpore de nombreux outils permettant de vérifier la configuration, ou rajouter des authentifications. J'ai été satisfait durant quelques années.

(Je ne compte pas Apache2, qui a été pratique pour débuter sans installer un service dédié à mon besoin de redirection)

Ensuite, j'ai utilisé aaPanel (dont vous trouverez un article sur ce site) me permettant d'avoir une toute un panel web pour mes sites et mes redirections ! J'ai abandonné en sachant que c'était un système bien ficelé dans lequel j'avais peu de liberté en terme d'édition de config

Puis mon besoin inutile d'avoir une interface Web m'a mené vers NPM (Nginx Proxy Manager) dont vous trouverez plus d'information ici. Qui m'était très pratique en sachant qu'il était sous forme de conteneur Docker, et proposant une interface gérant la création de redirection ainsi que le SSL, toujours chez let's encrypt. Mais à chaque expiration de certificat, NPM m'obligeait à aller manuellement séléctionner un-par-un chaque certificat à update : et ça, c'était impensable en sachant le nombre de domaine que j'ai créé.

Aujourd'hui, mon attention se porte vers Caddy qui, pour l'instant, correspond exactement à ce que je souhaite, et avec une simplicité incroyable.

Caddy

Caddy est, comme vous l'aurez compris, un reverse-proxy assez polyvalent et très utilisé dans certains conteneurs Docker ! Celui-ci génère automatiquement vos certificats (et configure les redirections automatiquement) sans aucun soucis avec Let's Encrypt. Caddy est assez léger et vous évitera les configurations à ralonge, voici un exemple bête :

thoughtless.eu {
reverse_proxy 192.168.5.125:8062
log {
output file /var/log/caddy/thoughtless.eu_access.log
}
}

Cette ligne créera une redirection en reverse-proxy avec la configuration par défault :

  • Caddy updatera / generera des certificats chaque fois que c'est nécéssaire
  • Il redirigera automatiquement les requetes en http:// vers le https://
  • Il écriera des logs des accès dans un fichier

En apache2 / Haproxy, ça aurait pris un chouïa + de lignes.

Mais attendons de voir, Caddy est encore très neuf pour moi, et je suis sûr que mon prochain besoin m'orientera vers une autre solution telle que Traefik par exemple !

Bonne courage dans votre longue quête autour des reverse-proxy

· 6 minutes de lecture
TheBidouilleur

[ Cet article provient de mon ancien-blog, celui-ci sera également disponible dans la partie "Documentation" du site ]

Docker Swarm

Introduction

Le monde de la conteneurisation a apporté de nombreuses choses dans l'administration système, et a actualisé le concept de DevOps. Mais une des choses principales que nous apporte les conteneurs (et particulièrement Docker), c'est l'automatisation. Et bien que Docker soit déjà complet avec le déploiement de service, on peut aller un peu plus loin en automatisant la gestion des conteneurs ! Et pour répondre à ça : Docker Inc. propose un outil adapté pour l'orchestration automatique d'instance : Docker Swarm.