Page de recherche dans les notes du jardin numérique de Stéphane Klein

Recherche effectué dans :

Tous type de notes (44)

journal_note (25)

evergreen_note (19)

Filtre actif, cliquez pour en enlever un tag :

admin-sys

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (44 notes) :

Pendant l'année 2014, Athoune m'a fait découvrir les concepts DevOps "Baking" et "Frying".

Je le remercie, car ce sont des concepts que je considère très importants pour comprendre les différents paradigmes de déploiement.

Je n'ai aucune idée dans quelles conditions il avait découvert ces concepts. J'ai essayé de faire des recherches limitées à l'année 2014 et je suis tombé sur cette photo :

J'en déduis que cela devait être un sujet à la méthode dans l'écosystème DevOps de 2014.

Cet ami me l'avait très bien expliqué avec une analogie du type :

« Le baking en DevOps, c’est comme dans un restaurant où les plats sont préparés en cuisine et ensuite apportés tout prêt salle à la table du client. Le frying, c’est comme si le plat était préparé directement en salle sur la table du client. »

Bien que cette analogie ne soit pas totalement rigoureuse, elle m'a bien permis de saisir, en 2014, le paradigme Docker qui consiste à préparer des images de container en amont. Ce paradigme permet d'installer, de configurer ces images "en cuisine", donc pas sur les serveurs de production, "de goûter les plats" et de les envoyer ensuite de manière prédictible sur le serveur de production.

Ces images peuvent être construites soit sur la workstation du développeur ou mieux, sur des serveurs dédiés à cette fonction, comme Gitlab-Runner…

Définitions proposées par LLaMa :

Baking (ou "Image Baking") : Il s'agit de créer une image de serveur prête à l'emploi, avec tous les logiciels et les configurations nécessaires déjà installés et configurés. Cette image est ensuite utilisée pour déployer de nouveaux serveurs, qui seront ainsi identiques et prêts à fonctionner immédiatement. L'avantage de cette approche est qu'elle permet de réduire le temps de déploiement et d'assurer la cohérence des environnements.

Frying (ou "Server Frying") : Il s'agit de déployer un serveur "nu" et de le configurer et de l'installer à la volée, en utilisant des outils d'automatisation tels que Ansible, Puppet ou Chef. Cette approche permet de personnaliser la configuration de chaque serveur en fonction des besoins spécifiques de l'application ou du service.

Exemple :

Cas d'usage Baking Frying

Docker Construire une image complète (docker build) et la stocker dans un registre Lancer un conteneur minimal et installer les dépendances au démarrage.

Machines virtuelles (VMs) Créer une image VM avec Packer et la déployer telle quelle Démarrer une VM de base et appliquer un script d’installation à la volée

CI/CD Compiler et packager une application en image prête à être déployée Construire l’application à chaque déploiement sur la machine cible

Cas d'usage	Baking	Frying
Docker	Construire une image complète (`docker build`) et la stocker dans un registre	Lancer un conteneur minimal et installer les dépendances au démarrage.
Machines virtuelles (VMs)	Créer une image VM avec Packer et la déployer telle quelle	Démarrer une VM de base et appliquer un script d’installation à la volée
CI/CD	Compiler et packager une application en image prête à être déployée	Construire l’application à chaque déploiement sur la machine cible

En 2014, lorsque le concept de baking m’a été présenté, j’ai immédiatement été enthousiasmé, car il répondait à trois problèmes que je cherchais à résoudre :

Réduire les risques d’échec d’une installation sur le serveur de production
Limiter la durée de l’indisponibilité (pendant la phase d’installation)
Éviter d'augmenter la charge du serveur durant les opérations de build lors de l’installation

Depuis, j'évite au maximum le frying et j'ai intégré le baking dans ma doctrine d'artisan développeur.

Début novembre un ami me posait la question :

Quand tu déploies des conteneurs en prod, sans k8s, tu fais comment ?

Après 3 mois d'attente, voici ma réponse 🙂.

Mon contexte

Tout d'abord, un peu de contexte. Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Cela dit, j'ai également eu à gérer des infrastructures comportant plusieurs serveurs : 10, 20, 30 serveurs. Ces serveurs étaient généralement utilisés pour héberger une infrastructure de soutien (Platform infrastructure) à destination des développeurs. Par exemple :

Environnements de recettage
Serveurs pour faire tourner Gitlab-Runner
Sauvegarde des données
Etc.

Ce contexte montre que je n'ai jamais eu à gérer le déploiement de services à très forte charge, comme ceux que l'on trouve sur des plateformes telles que Deezer, le site des impôts, Radio France, Meetic, la Fnac, Cdiscount, France Travail, Blablacar, ou encore Doctolib. La méthode que je décris dans cette note ne concerne pas ce type d'infrastructure.

Ma méthode depuis 2015

Dans cette note, je ne vais pas retracer l'évolution complète de mes méthodes de déploiement, mais plutôt me concentrer sur deux d'entre elles : l'une que j'utilise depuis 2015, et une déclinaison adoptée en 2020.

Voici les principes que j'essaie de suivre et qui constituent le socle de ma doctrine en matière de déploiement de services :

Je m'efforce de suivre le modèle Baking autant que possible (voir ma note 2025-02-07_1403), sans en faire une approche dogmatique ou extrémiste.
J'applique les principes de The Twelve-Factors App.
Je privilégie le paradigme Remote Task Execution, ce qui me permet d'adopter une approche GitOps.
J'utilise des outils d'orchestration prenant en charge le mode push (voir note 2025-02-07_1612), comme Ansible, et j'évite le mode pull.

En pratique, j'utilise Ansible pour déployer un fichier docker-compose.yml sur le serveur de production et ensuite lancer les services.

Je précise que cette note ne traite pas de la préparation préalable du serveur, de l'installation de Docker, ni d'autres aspects similaires. Afin de ne pas alourdir davantage cette note, je n'aborde pas non plus les questions de Continuous Integration ou de Continuous Delivery.

Imaginons que je souhaite déployer le lecteur RSS Miniflux connecté à un serveur PostgreSQL.
Voici les opérations effectuées par le rôle Ansible à distance sur le serveur de production :

1. Création d'un dossier /srv/miniflux/
1. Upload de /srv/miniflux/docker-compose.yml avec le contenu suivant :

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: password
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:password@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: secret
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

1. Depuis le dossier /srv/miniflux/ lancement de la commande docker compose up -d --remove-orphans --wait --pull always

Voilà, c'est tout 🙂.

En 2020, j'enlève "une couche"

J'aime enlever des couches et en 2020, je me suis demandé si je pouvais pratiquer avec élégance la méthode Remote Execution sans Ansible.
Mon objectif était d'utiliser seulement ssh et un soupçon de Bash.

Voici le résultat de mes expérimentations.

J'ai besoin de deux fichiers.

_payload_deploy_miniflux.sh
deploy_miniflux.sh

Voici le contenu de _payload_deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

PROJECT_FOLDER="/srv/miniflux/"

mkdir -p ${PROJECT_FOLDER}

cat <<EOF > ${PROJECT_FOLDER}docker-compose.yaml
services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: {{ .Env.MINIFLUX_POSTGRES_PASSWORD }}
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:{{ .Env.MINIFLUX_POSTGRES_PASSWORD }}@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: {{ .Env.MINIFLUX_ADMIN_PASSWORD }}
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

EOF

cd ${PROJECT_FOLDER}

docker compose pull
docker compose up -d --remove-orphans --wait

Voici le contenu de deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

cd "$(dirname "$0")/../"

gomplate -f _payload_deploy_miniflux.sh | ssh root@$SERVER1_IP 'bash -s'

J'utilise gomplate pour remplacer dynamiquement les secrets dans le script _payload_deploy_miniflux.sh.

En conclusion, pour déployer une nouvelle version, j'ai juste à exécuter :

$ ./deploy_miniflux.sh

Je trouve cela minimaliste et de plus, l'exécution est bien plus rapide que la solution Ansible.

Ce type de script peut ensuite être exécuté aussi bien manuellement par un développeur depuis sa workstation, que via GitLab-CI ou même Rundeck.

Pour un exemple plus détaillé, consultez ce repository : https://github.com/stephane-klein/poc-bash-ssh-docker-deployement-example

Bien entendu, si vous souhaitez déployer votre propre application que vous développez, vous devez ajouter à cela la partie baking, c'est-à-dire, le docker build qui prépare votre image, l'uploader sur un Docker registry… Généralement je réalise cela avec GitLab-CI/CD ou GitHub Actions.

Objections

Certains DevOps me disent :

« Mais on ne fait pas ça pour de la production ! Il faut utiliser Kubernetes ! »
« Comment ! Tu n'utilises pas Kubernetes ? »

Et d'autres :

« Il ne faut au grand jamais utiliser docker-compose en production ! »

Ne jamais utiliser docker compose en production ?

J'ai reçu cette objection en 2018. J'ai essayé de comprendre les raisons qui justifiaient que ce développeur considère l'usage de docker compose en production comme un Antipattern.

Si mes souvenirs sont bons, je me souviens que pour lui, la bonne méthode conscistait à déclarer les états des containers à déployer avec le module Ansible docker_container (le lien est vers la version de 2018, depuis ce module s'est grandement amélioré).

Je n'ai pas eu plus d'explications 🙁.

J'ai essayé d'imaginer ses motivations.

J'en ai trouvé une que je ne trouve pas très pertinente :

Uplodaer un fichier docker-compose.yml en production pour ensuite lancer des fonctions distantes sur celui-ci est moins performant que manipuler docker-engine à distance.

J'en ai imaginé une valable :

En déclarant la configuration de services Docker uniquement dans le rôle Ansible cela garantit qu'aucun développeur n'ira modifier et manipuler directement le fichier docker-compose.yml sur le serveur de production.

Je trouve que c'est un très bon argument 👍️.

Cependant, cette méthode a à mes yeux les inconvénients suivants :

Je maitrise bien mieux la syntaxe de docker compose que la syntaxe du module Ansible community.docker.docker_container
J'utilise docker compose au quotidien sur ma workstation et je n'ai pas envie d'apprendre une syntaxe supplémentaire uniquement pour le déploiement.
Je pense que le nombre de développeurs qui maîtrisent docker compose est suppérieur au nombre de ceux qui maîtrisent le module Ansible community.docker.docker_container.
Je ne suis pas utilisateur maximaliste de la méthode Remote Execution. Dans certaines circonstances, je trouve très pratique de pouvoir manipuler docker compose dans une session ssh directement sur un serveur. En période de stress ou de debug compliqué, je trouve cela pratique. J'essaie d'être assez rigoureux pour ne pas oublier de reporter mes changements effectués directement le serveur dans les scripts de déploiements (configuration as code).

Tu dois utiliser Kubernetes !

Alors oui, il y a une multitude de raisons valables d'utiliser Kubernetes. C'est une technologie très puissante, je n'ai pas le moindre doute à ce sujet.
J'ai une expérience dans ce domaine, ayant utilisé Kubernetes presque quotidiennement dans un cadre professionnel de janvier 2016 à septembre 2017. J'ai administré un petit cluster auto-managé composé de quelques nœuds et y ai déployé diverses applications.

Ceci étant dit, je rappelle mon contexte :

Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Je pense que faire appel à Kubernetes dans ce contexte est de l'overengineering.

Je dois avouer que j'envisage d'expérimenter un usage minimaliste de K3s (attention au "3", je n'ai pas écrit k8s) pour mes déploiements. Mais je sais que Kubernetes est un rabbit hole : Helm, Kustomize, Istio, Helmfile, Grafana Tanka… J'ai peur de tomber dans un Yak!.

D'autre part, il existe déjà un pourcentage non négligeable de développeur qui ne maitrise ni Docker, ni docker compose et dans ces conditions, faire le choix de Kubernetes augmenterait encore plus la barrière à l'entrée permettant à des collègues de pouvoir comprendre et intervenir sur les serveurs d'hébergement.

C'est pour cela que ma doctrine d'artisan développeur consiste à utiliser Kubernetes seulement à partir du moment où je rencontre des besoins de forte charge, de scalabilité.

Note de type #mémento pour ajouter le support healthcheck à nginx-proxy et nginx-proxy acme-companion.

J'ai effectué des recherches dans les dépôts GitHub des projets :

nginx-proxy « health », j'ai trouvé :
- nginx-proxy health check
acme-companion « health », j'ai trouvé :
- Support Docker health checks

J'ai aussi trouvé « Adding health check support to nginx-proxy nginx.tmpl file · nginx-proxy/nginx-proxy » qui est un sujet qui m'intéresse, mais pas en lien avec le sujet de cette note.

N'ayant rien trouvé de clés en main, voici ci-dessous mon implémentation.

Je ne suis pas certain qu'elle soit très robuste 🤔.

Elle a tout de même l'avantage de me permettre d'utiliser l'option --wait dans docker-compose up -d --remove-orphans --wait.

J'ai partagé aussi posté un commentaire à l'issue pour partager mon implémentation.

# docker-compose.yml
services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy:1.6.4
    container_name: nginx-proxy
    restart: unless-stopped
    network_mode: "host"
    volumes:
      - ./vhost.d/:/etc/nginx/vhost.d:rw
      - ./htpasswd:/etc/nginx/htpasswd:ro
      - html:/usr/share/nginx/html
      - certs:/etc/nginx/certs:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro
    healthcheck:
      test: ["CMD-SHELL", "nginx -t && kill -0 $$(cat /var/run/nginx.pid)"]
      interval: 10s
      timeout: 2s
      retries: 3

  acme-companion:
    image: nginxproxy/acme-companion:2.5.1
    restart: unless-stopped
    volumes_from:
      - nginx-proxy
    depends_on:
      - "nginx-proxy"
    environment:
      DEFAULT_EMAIL: contact@stephane-klein.info
    volumes:
      - certs:/etc/nginx/certs:rw
      - acme:/etc/acme.sh
      - /var/run/docker.sock:/var/run/docker.sock:ro
    healthcheck:
      test: ["CMD-SHELL", "ps aux | grep -v grep | grep -q '/bin/bash /app/start.sh'"]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 10s

volumes:
  html:
  certs:
  acme:

Suite de la note 2025-01-14_2152 au sujet de Scaleway Domains and DNS.

Dans l'e-mail « External domain name validation » que j'ai reçu, je lis :

Alternative validation process (if your current registrar doesn't offer basic DNS service):

Please set your nameservers at your registrar to:

9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud

9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud

J'ai essayé cette méthode alternative pour le sous-domaine scw.stephane-klein.info :

Voici les DNS Records correspondants :

scw.stephane-klein.info.	1	IN	NS	9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud.
scw.stephane-klein.info.	1	IN	NS	9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud.

J'ai vérifié ma configuration :

$ dig NS scw.stephane-klein.info @ali.ns.cloudflare.com
scw.stephane-klein.info. 300    IN      NS      9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns0.dom.scw.cloud.
scw.stephane-klein.info. 300    IN      NS      9ca08f37-e2c8-478d-bb0e-8a525db976b9.ns1.dom.scw.cloud.

J'ai attendu plus d'une heure et cette méthode de validation n'a toujours pas fonctionné.

Je pense que cela ne fonctionne pas 🤔.

Je vais créer un ticket de support Scaleway pour savoir si c'est un bug ou si j'ai mal compris comment cela fonctionne.

2025-01-17 : réponse que j'ai reçu :

Notre équipe produit est revenue vers nous pour nous indiquer qu’en effet il y a un défaut de documentation.

Ce process alternatif ne fonctionne que sur la racine des domaines pas sur un sous domaine.

C’était pour les tlds qui ne donnent pas de DNS par défaut aux clients.

Conclusion : la documentation était imprécise, ce que j'ai essayé de réaliser ne peut pas fonctionner.

J'ai réalisé un test pour vérifier que la délégation DNS par le managed service de Scaleway nommé Domains and DNS (lien direct) fonctionne correctement pour un sous-domaine tel que testscaleway.stephane-klein.info.

Je commence par suivre les instructions du how to : How to add an external domain to Domains and DNS.

Sur la page https://console.scaleway.com/domains/internal/create :

Je sélectionne la dernière entrée « Manage as external ».

Ensuite :

J'ai ajouté le DNS Record suivant à mon serveur DNS géré par cloudflare :

_scaleway-challenge.testscaleway.stephane-klein.info.	1	IN	TXT	"dd7e7931-56d6-4e04-bcd7-e358821e63dd"

Vérification :

$ dig TXT _scaleway-challenge.testscaleway.stephane-klein.info +short
"dd7e7931-56d6-4e04-bcd7-e358821e63dd"

Je n'ai aucune idée de la fréquencede passage du job Scaleway qui effectue la vérification de l'entrée TXT :

J'ai ajouté mon domaine à 22h22 et il a été validé à 22h54 :

Ensuite, j'ai ajouté les DNS Records suivants :

testscaleway.stephane-klein.info.	1	IN	NS	ns1.dom.scw.cloud.
testscaleway.stephane-klein.info.	1	IN	NS	ns0.dom.scw.cloud.

Vérification :

$ dig NS testscaleway.stephane-klein.info +short
ns0.dom.scw.cloud.
ns1.dom.scw.cloud.

Ensuite, j'ai configuré dans la console Scaleway, le DNS Record :

test1   3600 IN A  8.8.8.8

Vérification :

$ dig test1.testscaleway.stephane-klein.info +short
8.8.8.8

Conclusion : la réponse est oui, le managed service Scaleway Domains and DNS permet la délégation de sous-domaines 🙂.

Comme mentionné dans la note 2024-12-28_1621, j'ai implémenté un playground nommé powerdns-playground.
J'ai fait le triste constat de découvrir encore un projet (PowerDNS-Admin) qui ne supporte pas une "automated and unattended installation" 🫤.

PowerDNS-Admin ne permet pas de créer automatiquement un utilisateur admin.

Pour contourner cette limitation, j'ai implémenté un script configure_powerdns_admin.py qui permet de créer un utilisateur basé sur les variables d'environnement POWERDNS_ADMIN_USERNAME, POWERDNS_ADMIN_PASSWORD, POWERDNS_ADMIN_EMAIL.

Le script ./scripts/setup-powerdns-admin.sh se charge de copier le script Python dans le container powerdns-admin et de l'exécuter.

J'ai partagé ce script sur :

le SubReddit self hosted : https://old.reddit.com/r/selfhosted/comments/1hocrjm/powerdnsadmin_a_python_script_for_automating_the/?
et le Discord de PowerDNS-Admin : https://discord.com/channels/1088963190693576784/1088963191574376601/1322661412882874418

Je viens de tomber dans un Yak! 🙂.

Je cherchais des alternatives Open source à ngrok et j'ai trouvé sish (https://docs.ssi.sh/).

Côté client, sish utilise exclusivement ssh pour exposer des services (lien la documentation).

Voici comment exposer sur l'URL http://hereiam.tuns.sh le service HTTP exposé localement sur le port 8080 :

$ ssh -R hereiam:80:localhost:8080 tuns.sh

Je trouve cela très astucieux 👍️.

Après cela, j'ai commencé à étudier comment déployer sish et j'ai lu cette partie :

This includes taking care of SSL via Let's Encrypt for you. This uses the adferrand/dnsrobocert container to handle issuing wildcard certifications over DNS.

source

Après cela, j'ai étudié dnsrobocert qui permet de générer des certificats SSL Let's Encrypt avec la méthode DNS challenges, mais pour cela, il a besoin d'insérer et de modifier des DNS Record sur un serveur DNS.

Je n'ai pas envie de donner accès à l'intégralité de mes zones DNS à un script.
Pour éviter cela, j'ai dans un premier temps envisagé d'utiliser un serveur DNS managé de Scaleway, mais j'ai constaté que le provider Scaleway n'est pas supporté par Lexicon (qui est utilisé par dnsrobocert).

Après cela, j'ai décidé d'utiliser PowerDNS et je viens de publier ce playground : powerdns-playground.

Dans le blog de Richard Jones, j'ai découvert nbdkit.

nbdkit is an NBD server. NBD — Network Block Device — is a protocol for accessing Block Devices (hard disks and disk-like things) over a Network.

-- from

Dans le tutoriel "Proxmox Template with Cloud Image and Cloud Init", #JaiDécouvert un usage de la commande virt-customize :

# wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
# virt-customize -a noble-server-cloudimg-amd64.img --install qemu-guest-agent --run-command 'systemctl enable qemu-guest-agent.service'

Je trouve cela extrêmement pratique, cela évite de devoir utiliser Packer pour personnaliser une image disque.

J'ai fait quelques recherches et j'ai appris que la fonctionnalité d'installation de package est ancienne, elle a été implémentée dans libguestfs en 2014 par Richard Jones, employé de chez Red Hat (auteur de libguestfs).

#JaiDécouvert Harvester qui me semble être une alternative moderne à Proxmox, basé sur KubeVirt et Longhorn.

J'ai regardé la vidéo Kubevirt: Et si Kubernetes orchestrait vos VMs? (Mickael ROGER) qui m'a découragé d'utiliser KubeVirt.

En 2019, j'ai rencontré un problème lors de l'exécution de pg_dumpall sur une base de données PostgreSQL hébergée sur AWS RDS. À l'époque, ce problème était "la goutte d'eau" qui m'avait empressé de migrer de RDS vers une instance PostgreSQL self hosted avec une simple image Docker dans un docker-compose.yml, mais je digresse, ce n'est pas le sujet de cette note.

Aujourd'hui, j'ai fait face à nouveau à ce problème, mais cette fois, j'ai décidé de prendre le temps pour bien comprendre le problème et d'essayer de le traiter.

Pour cela, j'ai implémenté et publié un playground nommé rds-playground.

Je peux le dire maintenant, j'ai trouvé une solution à mon problème 🙂.

Ce playground contient :

Un exemple de déploiement d'une base de données AWS RDS avec Terraform.
Un script qui permet d'importer avec succès la base de données AWS RDS vers une instance locale de PostgreSQL, en incluant les rôles.

Au départ, je pensais que le problème venait d'un problème de configuration des rôles du côté de AWS RDS ou alors que je n'utilisais pas le bon user. J'ai ensuite compris que c'était une fausse piste.

J'ai ensuite découvert ce billet : "Using pg_dumpall with AWS RDS Postgres".

For those interested, RDS Postgres (by design) doesn't allow you to read pg_authid, which was earlier necessary for pg_dumpall to work.

J'ai compris que pour exécuter un pg_dumpall sur une instance RDS, il est impératif d'utiliser l'option --no-role-passwords.

Autre subtilité : sur une instance RDS, le rôle SUPERUSER est attribué au rôle rlsadmin, tandis que cette option est supprimé du rôle postgres.

ALTER ROLE postgres WITH NOSUPERUSER INHERIT CREATEROLE
CREATEDB LOGIN NOREPLICATION NOBYPASSRLS VALID UNTIL 'infinity';

Par conséquent, j'ai décidé d'utiliser le même nom d'utilisateur superuser pour l'instance locale PostgreSQL :

services:
  postgres:
    image: postgres:13.15
    environment:
      POSTGRES_USER: rdsadmin
      POSTGRES_DB: postgres
      POSTGRES_PASSWORD: password
      ...

Pour aller plus loin, je vous invite à suivre le README.md de rds-playground.

Nouvelle #iteration de Projet 14.

Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.

-- from

Résultat : j'ai migré de Vagrant Host Manager vers vagrant-dns avec succès 🙂.

Voici le commit : lien vers le commit.

Voici quelques explications de la configuration Vagrantfile.

Les lignes suivantes permettent d'utiliser la seconde IP des machines virtuelles pour identifier les identifier (renseignés par le serveur DNS).

  config.dns.ip = -> (vm, opts) do
    ip = nil
    vm.communicate.execute("hostname -I | cut -d ' ' -f 2") do |type, data|
      ip = data.strip if type == :stdout
    end
    ip
  end

La commande hostname retourne les deux IP de la machine virtuelle :

vagrant@server1:~$ hostname -I
10.0.2.15 192.168.56.22

La commande hostname -I | cut -d ' ' -f 2 capture la seconde IP, ici 192.168.56.22.

La configuration DNS qui retourne cette IP est consultable via :

$ vagrant dns -l
/server1.vagrant.test/ => 192.168.56.22
/server2.vagrant.test/ => 192.168.56.23
/grafana.vagrant.test/ => 192.168.56.23
/loki.vagrant.test/ => 192.168.56.23

Autre subtilité :

vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

Cette ligne configure la machine virtuelle pour qu'elle utilise le serveur DNS de vagrant-dns.
Cela permet de résoudre les noms des autres machines virtuelles. Exemple :

vagrant@server1:~$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23            -- link: eth0

-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

En mettant en place vagrant-dns sur ma workstation qui tourne sous Fedora, j'ai rencontré la difficulté suivante.

J'avais la configuration suivante installée :

$ cat /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Elle me permet de résoudre les hostnames des machines qui appartiennent à un réseau privé exposé via OpenVPN (voir cette note).

Voici ma configuration complète de systemd-resolved :

$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf

...

[Resolve]
...

# /etc/systemd/resolved.conf.d/1-vagrant-dns.conf
# This file is generated by vagrant-dns
[Resolve]
DNS=127.0.0.1:5300
Domains=~test

# /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd

Quand je lançais resolvectl query server2.vagrant.test pour la première fois après redémarrage de sudo systemctl restart systemd-resolved, tout fonctionnait correctement :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Mais, la seconde fois, j'avais l'erreur suivante :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: Name 'server2.vagrant.test' not found

Ce problème disparait si je supprime /etc/systemd/resolved.conf.d/csd.conf.

Je n'ai pas compris pourquoi. D'après la section "Protocols and routing" de systemd-resolved, le serveur 10.57.40.1 est utilisé seulement pour les hostnames qui se terminent par .csd.

J'ai activé les logs de systemd-resolved au niveau debug avec

$ sudo resolvectl log-level debug
$ journalctl -u systemd-resolved -f

Voici le contenu des logs lors de la première exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/506a9fc7d740dc4892e88bfc590bee98.

Voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/956befc280ef9738bfe48cdf7f5ef930.

J'ai l'impression que la ligne 13 indique que le cache de systemd-resolved a été utilisé et qu'il n'a pas trouvé de réponse pour server2.vagrant.test. Pourquoi ? Je ne sais pas.

Ligne 13 : NXDOMAIN cache hit for server2.vagrant.test IN A

Ensuite, je supprime /etc/systemd/resolved.conf.d/csd.conf :

$ sudo rm /etc/systemd/resolved.conf.d/csd.conf

Je relance systemd-resolved et voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test : https://gist.github.com/stephane-klein/9f87050524048ecf9766f9c97b789123#file-systemd-resolved-log-L11

Je constate que cette fois, la ligne 11 contient : Cache miss for server2.vagrant.test IN A.

Pourquoi avec .csd le cache retourne NXDOMAIN et sans .csd, le cache retourne Cache miss et systemd-resolved continue son algorithme de résosultion du hostname ?

Je soupçonne systemd-resolved de stocker en cache la résolution de server2.vagrant.test par le serveur DNS 10.57.40.1. Si c'est le cas, je me demande pourquoi il fait cela alors qu'il est configuré pour les hostnames qui se terminent par .csd 🤔.

Autre problème rencontré, la latence de réponse :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

La réponse est retournée en 7 secondes, ce qui ne me semble pas normal.

J'ai découvert que je n'ai plus aucune latence si je passe le paramètre DNSStubListener à no :

$ sudo cat <<EOF > /etc/systemd/resolved.conf.d/0-vagrant-dns.conf
[Resolve]
DNSStubListener=no
EOF
$ sudo systemctl restart systemd-resolved
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

Le temps de réponse passe de 7.5s à 2.9ms. Je n'ai pas compris la signification de ma modification.

Je récapitule, pour faire fonctionner correctement vagrant-dns sur ma workstation Fedora j'ai dû :

supprimer /etc/systemd/resolved.conf.d/csd.conf
et paramétrer DNSStubListener à no

Dans le cadre du Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS, j'utilise Vagrant avec le plugin Vagrant Host Manager pour gérer les hostnames des machines virtuelles.

Vagrant Host Manager met correctement à jour les fichiers /etc/hosts sur ma machine hôte, c'est-à-dire, ma workstation, et dans les machines virtuels.
Cependant, ces noms d'hôtes ne sont pas accessibles à l'intérieur des containers Docker.
Par exemple, ici, http://grafana.example.com:3100/ n'est pas accessible à l'intérieur du container Promtail.

Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.

vagrant-dns semble exposer un serveur DNS qui sera accessible et utilisé par les containers Docker.

D'autre part, vagrant-dns (page contributors) semble un peu plus actif que Vagrant Host Manager (page contributors).

#JaiDécouvert le site Formation DevOps | DevSecOps de Stéphane Robert. Énormément d'informations très bien catégorisées et en français !

J'ai parcouru la section Analyser le code ! et j'y ai découvert :

Alexandre m'a partagé l'article "Linux : Enregistrer toutes les commandes saisies avec auditd" qui présente Linux Audit.

The Linux audit framework provides a CAPP-compliant (Controlled Access Protection Profile) auditing system that reliably collects information about any security-relevant (or non-security-relevant) event on a system. It can help you track actions performed on a system.

-- from

La norme de sécurité de l'industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard destiné à poser les normes de la sécurité des systèmes d'information amenés à traiter et stocker des process ou des informations relatives aux systèmes de paiement.

Dans ce cadre, de nombreuses conditions sont à respecter afin d'être compatible avec cette norme. Parmi celles-ci, l'enregistrement des commandes et instructions saisies par les utilisateurs à privilèges sur un système.

-- from

D'après ce que j'ai compris, la fonctionnalité Linux Audit est implémentée au niveau du kernel.

Linux Audit permet de surveiller les actions effectuées sur les fichiers (lecture, écriture…) et les appels syscalls.

D'après ce que je comprends, Linux Audit est conçu à des fins de sécurité. Il semble peu adapté pour documenter les opérations réalisées sur un serveur dans le cadre d'un travail collaboratif.

#JaiDécouvert l'option "append-only" mode de restic.

#JaiDécouvert rustic, un clone de restic implémenté en Rust (from).

#JaiLu L'option ControlMaster de ssh_config.

J'y ai découvert l'open ControlMaster de OpenSSH.

#JaiLu Google Authenticator - ArchWiki.

Code source de Google Authenticator PAM module : https://github.com/google/google-authenticator-libpam.

Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

sudo apt upgrade -y
ou sudo apt dist-upgrade -y (plus risqué)
ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

J'arrête les services sur server(n+1).servers.example.com ;
J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
Je relance les services sur server(n+1).servers.example.com
Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

Une grande sécurité ;
L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
Une durée de coupure limitée et maîtrisée ;
La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
La garantie du bon fonctionnement des scripts de déploiement automatisé ;
La vérification de l'efficacité des scripts de restauration des sauvegardes ;
Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.

#JaiLu Securing A Linux Server.

J'ai trouvé cet article excellent.

J'y ai découvert :

#JeMeDemande souvent comment nommer la méthode permettant d'installer des applications de manière scriptée.

Lorsque je recherche cette fonctionnalité, j'utilise généralement les mots-clés : "headless", "script", "cli".

Je constate que la roadmap de Proxmox utilise le terme « automated and unattended installation » :

Support for automated and unattended installation of Proxmox VE.

-- from

#JaiPublié cette question dans la section discussion du projet Plausible : Plausible automated and unattended installation support (create user and web site by script) · plausible/analytics.

#JaiLu la page Wikipedia de Teleport.

Je pense que cela fait plus de 5 ans que #JeSouhaiteTester cet outil.

#JaiLu en partie le thread Hacker News Dokku: My favorite personal serverless platform.

#JaiDécouvert :

J'ai apprécié ce tableau de comparaison de fonctionnalités entre dokploy, CapRover, Dokku et Coolify.

C'est la ligne "Docker compose support" qui a attiré mon attention.
Je reste très attaché au support de docker compose qui je trouve est une spécification en même temps simple, complète et flexible qui ne m'a jamais déçu ces 9 dernières années.

Attention, je n'ai pas bien compris si Dokku est réellement open source ou non 🤔.

Je constate que Dokploy est basé sur Docker Swarm.

Dokploy leverages Docker Swarm to orchestrate and manage container deployments for your applications, providing an intuitive interface for monitoring and control.

-- from

Choix qui me paraît surprenant puisque Docker Swarm est officieusement déprécié.

Je me suis demandé si K3s pourrait être une alternative à Docker Swarm 🤔.

Alexandre m'a partagé OpenSCAP mais je n'ai pas encore pris le temps de l'étudier.

Je viens d'apprendre que l'option -N de ssh permet de ne pas ouvrir une session shell interactive sur le serveur distant.

Option très utile lors de l'ouverture de tunnels ssh.

Exemple :

ssh -L 8080:localhost:80 user@host -N

[ ] https://github.com/bunkerity/bunkerweb

Commandes valables sous Fedora mais aussi plus généralement sous Linux.

Affiche la configuration DNS actuelle :

$ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 127.0.0.1:5300
       DNS Servers: 127.0.0.1:5300
        DNS Domain: ~test

Link 2 (wlp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.31.1
       DNS Servers: 192.168.31.1

Intéroge directement un serveur DNS :

$ dig @127.0.0.1 -p 5300 server2.vagrant.test +short
192.168.56.21

Résolution d'un hostname avec resolvectl :

$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23

-- Information acquired via protocol DNS in 4.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network

La commande suivante affiche toutes la configuration de resolved.conf :

$ systemd-analyze cat-config systemd/resolved.conf

Date de la création de cette note : 2024-06-05.

Ce projet est terminé : voir 2024-07-06_1116.

Quel est l'objectif de ce projet ?

Bien que j'aie beaucoup travaillé de décembre 2023 janvier 2024 sur le projet Implémenter un POC de pgBackRest, je souhaite mettre à jour et améliorer le repository restic-pg_dump-docker.

Quelques tâches à réaliser :

[x] Mettre à jour tous les composants ;
[x] Publier le Dockerfile de stephaneklein/restic-backup-docker ;
[ ] Réaliser et publier un screencast ;
[x] Améliorer le README.md.

Pourquoi je souhaite réaliser ce projet ?

Pourquoi continuer ce projet alors que j'ai travaillé sur pgBackRest qui semble bien mieux ?

Pour plusieurs raisons :

Je ne peux pas installer pgBackRest dans un « sidecar container Docker » — en tout cas, je n'ai pas trouvé comment réaliser cela 🤷‍♂️. Je dois utiliser un container Docker PostgreSQL qui intègre pgBackRest.
Pour le moment, je ne comprends pas très bien la taille consommée par les "WAL segments" sauvegardés dans les buckets.
Pour le moment, je ne sais pas combien de temps prend la restauration d'un backup d'une base de données d'une taille supérieure à un test. Par exemple, combien de temps prend la restauration d'une base de données de 100 Mo 🤔.
Je ne suis pas rassuré de devoir lancer un cron — supercronic — lancé par tini

Bien que pgBackRest permette un backup en temps "réel" et est sans doute plus rapide que "ma" méthode "restic-pg_dump", pour toutes les raisons listée ci-dessus, je pense que la méthode "restic-pg_dump" est moins complexe à mettre en place et à utiliser.

#JeMeDemande si la fonctionnalité "incremental backups" la version 17 de PostgreSQL sera une solution plus pratique que pgBackRest et la méthode "restic-pg_dump" 🤔.

Repository de ce projet :

https://github.com/stephane-klein/restic-pg_dump-docker

Je vais travailler dans la branche nommée june-2024-working-session

Date de création de cette note : 2024-10-11.

Quel est l'objectif de ce projet ?

Je souhaite implémenter et publier un projet de "référence", de type skeleton, dont la fonction est d'installer les éléments de base d'un serveur Ubuntu LTS sécurisé.

Comme point de départ, je peux utiliser mon repository poc-bash-ssh-docker-deployement-example et le faire évoluer.

Le script _install_basic_server_configuration.sh se contente d'installer Docker.

J'aimerais y intégrer les recommandations présentes dans l'excellent article "Securing A Linux Server".

J'aimerais, entre autres, ajouter les fonctionnalités suivantes :

[x] Amélioration de la configuration de OpenSSH ;
[x] Installation et configuration de ufw ;
[x] Mise en place de ipsum ;
[x] Installation et configuration de fail2ban ;
[x] Système d'installation / suppression de clés ssh ;
[x] En option : installation et configuration de node exporter ;
[x] En option : installation et configuration de l'envoi des logs de journald et Docker vers Loki en utilisatant Promtail (~~installation et configuration de l'envoi des logs de journald vers Loki en utilisant Vector~~) ;
[x] En option : installation de configuration de Grafana ; avec Grizzly configuration des dashboards
- [x] des logs et
- [x] metrics des serveurs
[x] En option : installer et configurer apticron pour envoyer un message dans les logs dès qu'un package de sécurité doit être installé.
- [x] Génération d'une alerte Grafana si une mise à jour de sécurité doit être installé
[x] En option : envoie de notification sur smartphone en cas d'alerte Grafana, via ntfy
[ ] En option : installation et configuration de Linux Audit ;

Le repository doit présenter cette installation :

[x] via Vagrant
[ ] sur un Virtual machine Scaleway avec Terraform

Repository de ce projet :

basic_ubuntu_server_install_playground

Ressources :

Date de la création de cette note : 2024-07-30.

Quel est l'objectif de ce projet ?

Implémenter et publier un plugin Nodemailer de transport pour l'API HTTP Transactional Email de Scaleway.

Pourquoi je souhaite réaliser ce projet ?

Les ports SMTP des instances computes de Scaleway sont par défaut fermés. Pour contourner cette contrainte, il est nécessaire d'effectuer une demande au support pour les ouvrir.
Partant de ce constat, #JaiDécidé d'utiliser le protocole HTTP autant que possible pour envoyer des e-mails.

Problème : je n'ai pas trouvé de plugin de transport Nodemailer pour Scaleway, ce qui a motivé la création de ce projet.

Repository de ce projet :

https://github.com/stephane-klein/nodemailer-scaleway-transport (non publié au moment de la rédaction de cette note)

Ressources :

https://fr.wikipedia.org/wiki/Panne_informatique_mondiale_de_juillet_2024

https://fr.wikipedia.org/wiki/OpenSSH

https://complianceascode.readthedocs.io/en/latest/manual/user/01_introduction.html

🚀 10x easier, 🚀 140x lower storage cost, 🚀 high performance, 🚀 petabyte scale - Elasticsearch / Splunk / Datadog alternative for 🚀 (logs, metrics, traces, RUM, Error tracking, Session replay).

Dépôt GitHub : https://github.com/openobserve/openobserve.

Site web : https://people.redhat.com/sgrubb/audit/

GitHub : https://github.com/linux-audit/audit-userspace