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

#JaiDécouvert Kamal Proxy (from) « A minimal HTTP proxy for zero-downtime deployments » codé en Golang. Un projet Basecamp qui fonctionne avec kamal.

Cela attire ma curiosité, parce que la semaine dernière, je réfléchissais comment implémenter la fonctionnalité Skew Protection en self hosted, voir aussi 2023-07-04_1735.

J'ai lancé mon activité de freelance en juillet 2024.

Depuis, j'ai déjà travaillé pour deux clients en régie : l'un pour du développement web, et l'autre pour une mission DevOps. Actuellement, je suis en discussion pour deux nouvelles missions.

Jusqu'à présent, je n'ai fait aucune promotion de mon activité #freelance, même parmi mes amis. Très peu de personnes sont au courant de ma nouvelle activé.

Mon premier projet en tant que freelance a été la continuation d'un projet sur lequel je travaillais depuis près d'un an.
Quant au second projet, il m'est venu grâce à un ami développeur qui m'a mis en relation avec le client.

Place de maché de freelances

La dernière semaine d'août, j'ai créé et activé un compte sur Malt, mais pour le moment, personne ne m'a contacté.

Plus d'informations au sujet de mon aventure Malt dans la note suivante : Première itération de mon aventure Malt.

Je me suis aussi inscrit sur Collective, j'ai reçu cette semaine deux opportunités de missions auxquelles je dois répondre :

Je suis aussi inscrit sur Jean-Paul.io, pour le moment, je n'ai reçu aucun message.

J'ai prévu de m'inscrire sur Comet et LeHibou.

Ma stratégie de publication LinkedIn

Maintenant que les sections CV, Mes services et Mes disponibilités et tarifs sont a jours sur mon site personnelle et que j'ai enfin édité un nouveau CV au format A4 — ce fut difficile d'être concis — je me suis dit que je suis prêt à poster un message sur LinkedIn pour informer mon réseau de ma nouvelle activité.

Voici les messages que je souhaite poster :

Bonjour, petit message "publicitaire" 😉 pour vous informer que je suis #Freelance depuis juillet.

Depuis mon lancement, j'ai déjà travaillé pour deux clients en régie, pour du développement web et une mission DevOps. Actuellement, je suis en discussion pour deux autres missions.

Il me reste entre 30 et 40 jours de disponibilité d'ici fin décembre, et je suis donc à la recherche de nouvelles missions pour compléter mon planning.

Si vous avez des projets ou connaissez des personnes qui pourraient avoir besoin de mes services, n'hésitez pas à me contacter ou à partager mon profil. 🙏

#PayItForward : Un grand merci par avance pour tout partage (repost) ou recommandation en commentaire !

Pour plus d'informations :

Mon CV : https://sklein.xyz/fr/cv/?campaign=ryxHYa

Exemples de services que je propose : https://sklein.xyz/fr/services-freelance/?campaign=ryxHYb

Mes disponibilités et tarifs : https://sklein.xyz/fr/availability-and-pricing/?campaign=ryxHYc

À bientôt ! 🙂

Et 3 jours plus tard :

Vous travaillez au sein d'une organisation et vous cherchez quelqu'un pour lancer une application web de type MVP (Produit Minimum Viable) soignée, développée et déployée à partir de zéro avec un minimum de bug ?

Si la réponse est oui, n'hésitez pas à me contacter, je peux peut-être vous aider à réaliser ce projet.

Pour plus d'informations :

Mon CV : https://sklein.xyz/fr/cv/?campaign=ryxHYa2

Exemples de services que je propose : https://sklein.xyz/fr/services-freelance/?campaign=ryxHYb2

Mes disponibilités et tarifs : https://sklein.xyz/fr/availability-and-pricing/?campaign=ryxHYc2

À bientôt ! 🙂

#Freelance #WebDev #MVP

3 jours plus tard :

En tant que #Freelance, je propose mes services en software engineering pour des prestations que je qualifie de "pompiers", par exemple :

Correction de bugs sous forme de "quick win" ;

Réduction des lenteurs de votre application sous forme de "quick win" ;

Traitement en urgence de problèmes d'hébergement (hosting).

Si vous rencontrez de type de problème, n'hésitez pas à me contacter, je peux peut-être vous aider sur ces sujets.

#Freelance #DevOps #BugFix #OpenToWork

Je souhaite également publier ces messages sur Twitter et Mastodon, et éventuellement le premier sur Facebook (même si je pense que ce n'est pas l'endroit idéal pour ce type de contenu).

Après une mise en pratique plus approfondie, la technique présentée dans pnpm workspace et Docker build n'a pas fonctionné comme je l'attendais.

À cause de cette ligne du /demosite/pnpm-lock.yaml :

    dependencies:
      gibbon-replay-js:
        specifier: 0.2.0
        version: link:../packages/gibbon-replay-js

Pour générer un fichier pnpm-lock.yaml qui contient :

      gibbon-replay-js:
        specifier: 0.2.0
        version: 0.2.0

j'ai créé un script nommé demosite/scripts/generate-local-pnpm-lock-file.sh qui contient :

#!/usr/bin/env bash
# This script generates a pnpm-lock.yaml file in the local directory,
# without including dependencies from workspace projects.
# For example, the version of gibbon-replay-js installed is the version
# published on npmjs.
# This point is crucial to ensure the correct operation of the docker build
# command when creating the Docker image of the demo-site project.
set -e

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

export npm_config_link_workspace_packages=false
export npm_config_prefer_workspace_packages=false
export npm_config_shared_workspace_lockfile=false

pnpm install --lockfile-only

Cela me permet de générer un fichier pnpm-lock.yaml qui sera présent dans le dossier /demosite/ et utilisé lors de l'exécution de Docker build.

En complément de cela, j'utilise les paramètres suivants dans /demosite/.npmrc :

link-workspace-packages=true
prefer-workspace-packages=true
shared-workspace-lockfile=true

cela permet en phase de "développement", c'est-à-dire en dehors du build Docker, d'utiliser le fichier pnpm-lock.yaml à la racine et la version locale du package packages/gibbon-replay-js.

Tout cela me paraît un peu complexe, mais pour l'instant, je n'ai pas trouvé de méthode alternative permettant de configurer un environnement de développement répondant à ces deux exigences :

En mode développement, utiliser directement le code du packages/gibbon-replay-js sans qu'aucune action ne soit requise de la part du développeur.
Pouvoir générer l'image Docker en une seule commande.

Je suis ouvert à toute suggestion 🙂 (contact@stephane-klein.info).

J'écris cette note pour me souvenir pourquoi j'ai paramétré .npmrc avec les options suivantes :

link-workspace-packages=true
prefer-workspace-packages=true
shared-workspace-lockfile=false

Sans l'option link-workspace-packages=true, je devais configurer package.json comme ceci

"gibbon-replay-js": "workspace:*"

pour que /demosite utilise le package local /packages/gibbon-replay-js.

Cette contrainte me posait un problème, parce que /demosite/Dockerfile ne pouvait pas être buildé.

L'option link-workspace-packages=true permet de configurer la dépendance suivante

"gibbon-replay-js": "0.2.0"

qui pourra être installé correctement lors du build de l'image Docker.

Attention, cette version de gibbon-replay-js doit avoir préalablement été publiée sur npm registry.

Seconde option qui m'a été utile : shared-workspace-lockfile=false.

Avec cette option, pnpm install génère les fichiers /demosite/pnpm-lock.yaml et /app/pnpm-lock.yaml, fichiers indispensables pour build les images Docker.

Alexandre m'a partagé le projet Grafana Tanka.

Flexible, reusable and concise configuration for Kubernetes.

Je découvre ce thread Hacker News que je n'ai pas pris le temps de lire : Tanka: Our way of deploying to Kubernetes.

#JaiLu Why not Helm?.

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.

#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.

#JaiDécouvert SOPS: Secrets OPerationS #JeSouhaiteTester .

Je cherche depuis plusieurs années une solution pour surveiller la date d'expiration des noms de domaine en analysant le contenu de Whois.

#JaiDécouvert cet exporter Prometheus qui correspond exactement à mon besoin : https://github.com/shift/domain_exporter

En examinant l'historique du projet, je constate qu'il a été lancé en 2017. Il me semble pourtant avoir recherché ce type d'exporter en 2019 sans le trouver. Peut-être n'était-il pas encore assez mature à ce moment-là 🤔.

J'ai identifié aussi les projets suivants :

https://github.com/casnerano/domain-exporter qui semble confidentiel et moins complet, peut-être un simple POC ;
https://github.com/sorrowless/whois-exporter écrit en Python avec un seul commit... Peut-être que son auteur n'avait pas connaissance de https://github.com/shift/domain_exporter 🤔.

Pour le moment, je n'ai pas encore trouvé de dashboards Grafana pour cet exporter.

Note de type snippets concernant docker compose et l'utilisation de la fonctionnalité healthcheck et depends_on.

Cette méthode évite que le service webapp démarre avant que les services postgres et redis soient prêts.

# Fichier docker-composexyml
services:
    postgres:
        image: postgres:16
        ...
        healthcheck:
            test: ["CMD", "sh", "-c", "pg_isready -U $$POSTGRES_USER -h $$(hostname -i)"]
            interval: 10s
            start_period: 30s

	redis:
	    image: redis:7
	    ...
	    healthcheck:
	      test: ["CMD", "redis-cli", "ping"]
	      timeout: 10s
	      retries: 3
	      start_period: 10s

    webapp:
	    image: ...
        depends_on:
            postgres:
                condition: service_healthy
            redis:
                condition: service_healthy

Ici la commande :

$ docker compose up -d webapp

s'assure du lancement de ses dépendances, les services postgres et redis.

De plus, si le Dockerfile du service webapp contient par exemple :

# Fichier Dockerfile
...
RUN apt update -y; apt install -y curl
...
HEALTHCHECK --interval=30s --timeout=10s --retries=3 CMD curl --fail http://localhost:3000 || exit 1

Alors, je peux lancer webapp avec :

$ docker compose up -d webapp --wait

Avec l'option --wait docker compose "rend la main" lorsque le service webapp est prêt à recevoir des requêtes.

Ressources :

Je viens de créer Projet 12 - "Implémentation nodemailer-scaleway-transport".

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

Pour des raisons Developer eXperience — convivialité — j'apprécie d'avoir la possibilité de me connecter facilement à un serveur PostgreSQL distant, par exemple, pour :

Simplement ouvrir un terminal interactif psql ;
Exécuter un fichier SQL local sur un serveur distant ;
Exécuter un script local, Python, JavaScript ou autre sur un serveur distant.

Cependant, par choix déontologique, je préfère ne jamais ouvrir PostgreSQL sur l'extérieur.
Je me limite à ouvrir uniquement les services SSH et HTTP sur l'extérieur.

Pour contourner cette limitation, j'utilise des tunnels SSH pour accéder à mes serveurs PostgreSQL distants.

Dans ce dossier /deployment/develop, voici mes scripts idiosyncrasiques que j'ai l'habitude d'utiliser pour ouvrir ou fermer mes tunnels SSH :

Voici un exemple d'utilisation :

$ ./scripts/open_ssh_tunnel_postgres.sh
$ ./scripts/enter-in-pg.sh ../../init.sql
$ ../../import.js
$ ./scripts/close_ssh_tunnel_postgres.sh

Dans les scripts open_ssh_tunnel_postgres.sh et close_ssh_tunnel_postgres.sh, j'utilise simplement nohup pour exécuter ssh en tâche de fond et récuperer son PID.

#JaiDécouvert direnv : Automating development environment set-up with Direnv.

A utility for managing Jsonnet dashboards against the Grafana API .

Site officiel : https://grafana.github.io/grizzly/

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

Modern load testing for developers and testers in the DevOps era.

https://github.com/grafana/k6

Gotify est un logiciel de Messagerie push.

A simple server for sending and receiving messages in real-time per WebSocket. (Includes a sleek web-ui)

Site officiel : https://gotify.net/

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

Voir aussi : ntfy

https://www.gitops.tech/

Autre article intéressant au sujet de GitOps par Quentin Joly : https://une-tasse-de.cafe/blog/argocd/

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

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 ;