SurrealDB est une base de données puissante, dont la version 1.0 a été lancée en 2023. C'est une nouvelle génération de base de données, qui peut être avec ou sans schéma .Dans cet article, nous nous concentrerons sur la partie avec schéma de SurrealDB.

Même si la documentation officielle de SurrealDB est assez complète concernant les requêtes du langage SurrealQL, elle manque un peu d'informations sur les types disponibles dans une table avec schéma. Cet article vise à combler cette lacune.

Rappel sur la création d'une table et d'un champ​

Pour créer une table dans SurrealDB, vous devez avoir déjà défini une base de données et un espace de noms. Ensuite, vous pouvez créer une table avec la commande suivante :

DEFINE TABLE product SCHEMAFULL;

Puis, pour définir un champ dans une table, vous pouvez utiliser la commande suivante :

DEFINE FIELD my_field ON TABLE product TYPE data_type;

Types disponibles dans une table SurrealDB avec schéma

Types de base​

Any​

DEFINE FIELD my_field ON TABLE product TYPE any;

Booléens​

DEFINE FIELD active ON TABLE product TYPE bool;

Nombres​

Tout nombre​

DEFINE FIELD price ON TABLE product TYPE number;

Entier​

DEFINE FIELD price ON TABLE product TYPE int;

Flottant​

DEFINE FIELD price ON TABLE product TYPE float;

Décimal​

DEFINE FIELD price ON TABLE product TYPE decimal;

Null​

DEFINE FIELD price ON TABLE product TYPE null;

String​

DEFINE FIELD name ON TABLE product TYPE string;

Bytes​

DEFINE FIELD icon ON TABLE product TYPE bytes;

Uuid​

DEFINE FIELD ext_id ON TABLE product TYPE uuid;

Types relatifs à la date et la durée​

Datetime​

DEFINE FIELD created_at ON TABLE product TYPE datetime;

Duration​

DEFINE FIELD duration ON TABLE product TYPE duration;

Point​

DEFINE FIELD location ON TABLE product TYPE point;

Record​

DEFINE FIELD created_by ON TABLE product TYPE record;

Types composés​

Les types composés sont formés en combinant des types de base avec composed_type<type>.

Type optionnel​

Par défaut, tous les champs sont obligatoires. Si vous voulez rendre un champ optionnel, vous pouvez utiliser le type optional.

DEFINE FIELD description ON TABLE product TYPE option<string>;

Type multiple​

Si vous voulez autoriser plusieurs types pour un champ, vous pouvez utiliser le type either.

DEFINE FIELD additional_propertie ON TABLE product TYPE string|number;

Tableau​

DEFINE FIELD tags ON TABLE product TYPE array<string>;

Set​

DEFINE FIELD tags ON TABLE product TYPE set<string>;

Géometrie​

DEFINE FIELD location ON TABLE product TYPE geometry<line>;

Dans ce cas, les seuls types autorisés sont ceux définis dans la documentation de SurrealDB. Ces types respectent le format GeoJSON (défini dans rfc7946).

Cours complet sur SurrealDB​

Si vous voulez en savoir plus sur SurrealDB, vous pouvez vous abonner à notre newsletter pour être informé du cours que nous préparons. Et bénéficier d'une réduction lors de sa sortie.

Mes besoins étaient les suivants :

• Un système utilisateur
• Des analyses
• Un système de blog
• Un système de documentation
• Une base de données me permettant de tester rapidement de nouvelles choses
• La stack technologique doit être facilement auto-hébergeable

Choisir une base de données​

Le choix de la base de données est délicat. Dois-je opter pour SQL ou NoSQL ?

À mon avis, nous devrions choisir une base de données qui s'adapte à la forme de nos données, et non modifier nos données pour les faire rentrer dans la base de données. Et si vous connaissez un peu les docker-composes, c'est une structure de données très complexe à stocker, car assez incohérente (je veux dire, même si c'est basé sur YAML, il existe tellement de possibilités différentes). Le stocker dans une base de données SQL serait un cauchemar, la seule "solution facile" serait de le considérer comme du texte brut et de le stocker dans une cellule texte (ou octets, peu importe).

Oui, je pourrais utiliser la cellule JSON de PostgreSQL pour créer un moyen de le stocker commodément, mais rappelez-vous de notre besoin : garder les choses simples.

J'ai donc choisi NoSQL pour sa capacité à stocker des données non structurées.

Mais quelle base de données NoSQL ?​

Choisir une base de données NoSQL n'est que la moitié du chemin pour choisir une base de données. Il reste encore tellement de questions à se poser. Mais rappelez-vous toujours ceci quand vous êtes une petite équipe ou un développeur solo : garder les choses simples.

Je vais donc me concentrer sur ces questions :

• Existe-t-il un driver TypeScript facile à utiliser ?
• La base de données est-elle sécurisée ?
• Puis-je l'auto-héberger ?
• Y a-t-il une grande communauté ?

J'ai pensé à SurrealDB et MongoDB. Ils ont tous deux un SDK TS, n'ont pas de nouvelles CVE chaque matin, et sont entièrement auto-hébergeables.

SurrealDB​

SurrealDB pourrait être une très bonne option, car il peut être utilisé comme une base de données SQL pour ma partie utilisateur et NoSQL pour mon traitement de données et mes tâches.

Mais le grand inconvénient est le manque de maturité. Même si les développeurs sont rapides pour répondre aux problèmes soumis, il n'y a pas beaucoup de ressources sur Stack Overflow ou d'autres espaces de connaissances à son sujet.

Le choix final : MongoDB​

J'ai finalement choisi MongoDB car il me permettrait de modifier rapidement le modèle de données de mes entités, et il existe une documentation et des connaissances beaucoup plus importantes à son sujet.

À ce stade, je savais que j'utiliserais NextJS + MongoDB, mais qu'en est-il du système de blog, de la documentation et des analyses ?

La partie auto-hébergement​

Avant d'aller plus loin, j'ai commencé ma première version bêta avec très peu d'utilisateurs. J'avais donc besoin d'auto-héberger la stack. Mes deux plus grandes préoccupations étaient : je veux que ce soit peu coûteux et facile.

J'ai choisi hetzner.com car ils sont vraiment peu coûteux et fiables. 4,51 € /mois pour 2 CPU, 4 Go de RAM, 20 To de bande passante et 40 Go de SSD. Pour gérer mon serveur privé virtuel, j'ai choisi Coolify, car c'est entièrement open-source et me permet de déployer facilement de nouveaux services.

Les analyses, le blog et la documentation :​

Le choix des analyses était très simple pour moi car j'utilise Umami Analytics depuis 2020. C'est entièrement auto-hébergé, open source et conforme au RGPD.

Mes besoins en matière de blog étaient un peu particuliers car je voulais quelque chose de headless avec une interface d'administration et auto-hébergeable. J'aurais pu opter pour Strapi, mais j'ai finalement choisi Directus sans raison particulière, les deux pouvant parfaitement convenir à mon cas d'utilisation.

Concernant la documentation, mon choix a été guidé par : peu coûteux et rapide. J'aurais donc pu choisir n'importe quelle solution de documentation basée sur Markdown. Voici quelques bons choix :

• Docusaurus
• Hugo
• mkDocs
• markdoc

J'ai opté pour Docusaurus car il est basé sur React, et à l'avenir, si nécessaire, je pourrais facilement ajouter des composants personnalisés.

N'y a-t-il pas de problèmes de référencement en utilisant différentes technologies pour la documentation et le blog ?​

Pour éviter les problèmes de référencement associés aux sites web multi-domaines comme composecraft.com, docs.composecraft.com, blog.composecraft.com.

J'ai opté pour une approche différente :

Premièrement, mon système de blog est plus un système de bibliothèque. Directus m'aide uniquement à gérer les entrées, mes données contiennent un champ markdown qui alimente directement mon NextJS, donc pour la partie blog (ou bibliothèque comme vous voulez), tout est sous composecraft.com/library et NextJS le gère avec la bibliothèque next-remote-mdx.

Bien que j'aurais pu utiliser le même modèle pour ma documentation, j'ai choisi Docusaurus. Pourquoi ? Parce que ma documentation va rapidement évoluer, et je ne veux pas me soucier des questions NextJS lors de la rédaction. Je veux simplement écrire des fichiers markdown sans me préoccuper de la réactivité mobile, des performances ou autre. Utiliser Docusaurus impose automatiquement à ma documentation d'être structurée, facile à éditer et facile à utiliser par mes utilisateurs.

J'ai donc simplement configuré mon proxy inverse pour rediriger toute requête sous /doc vers le Docker Docusaurus géré par Coolify.

Le proxy inverse :​

À mon avis, surtout pour choisir un proxy inverse pour un site web de faible à moyenne charge, choisissez celui que vous aimez. Il n'y a pas de choix "informatique" meilleur entre nginx, traefik, apache ou caddy tant que vous restez sur un serveur simple sans équilibrage de charge ou routage complexe.

Les sauvegardes ?​

Comment m'assurer que ma base de données auto-hébergée ne disparaisse pas quand mon serveur va brûler à cause de mes trop nombreux utilisateurs ?

Jusqu'à présent, mon serveur est loin de brûler à cause de mes trop nombreux utilisateurs, mais quoi qu'il en soit, j'ai intégré un mécanisme de sauvegarde. Lequel ? Chaque jour à 3h du matin, une sauvegarde complète de la base de données est programmée et stockée sur un S3 distant chez un fournisseur cloud (différent de mon fournisseur de serveur privé virtuel pour éviter qu'ils ne placent le compartiment S3 dans le même centre de données que mon serveur de production).

Dernière préoccupation : le CDN​

En tant que petit produit utilisé dans le monde entier, j'ai été confronté à un problème : mes utilisateurs américains se plaignaient de la latence, et en effet, le serveur est situé en Europe.

Réponse facile : je pourrais avoir une instance aux États-Unis !

Mais... rappelez-vous que c'est un petit projet et je veux que ce soit peu coûteux et facile. J'ai donc choisi de faire appel à Cloudflare avec leur CDN gratuit. Oui, ce n'est pas une stack entièrement auto-hébergée respectueuse de la confidentialité. Mais pour une petite équipe de produit, c'est le meilleur compromis coût/performance que je pouvais faire.

Le schéma final :​

Quelques réflexions​

Aurais-je pu le construire plus simplement ?

Oui, définitivement : si mon client final était totalement non technique, j'aurais travaillé davantage sur la documentation et réutilisé directement Directus pour gérer ma documentation en même temps que mes bibliothèques. Et si le client ne veut absolument pas interagir avec un serveur Linux : utiliser MongoDB Atlas et des solutions cloud pour les analyses, et quelque chose comme Vercel, Netlify ou fly.io pour déployer mon application NextJS sans état.

Mais comme je suis un amateur de Linux et que je n'ai pas peur de mettre la main à la pâte, je pense que c'est la stack la plus économique et la plus facilement maintenable qui me convienne.

Envie d'aller plus loin ?​

Je vais bientôt créer des articles sur le pipeline CI/CD et un autre sur la logique interne de NextJS. Restez informé des nouveaux articles en vous abonnant à la newsletter ci-dessous :

Nous allons principalement nous concentrer sur la magie qui se passe au sein de l'application Next.js.

Les besoins :​

Ce que nous voulons construire est une interface graphique nodale pour gérer les données de Docker Compose.

De ce besoin produit, nous pouvons extraire certaines réponses techniques :

• Une gestion efficace des données Docker Compose.
• Un outil pour nous aider avec l'interface graphique nodale.
• Un système de gestion d'état permettant des mutations complexes et profondément imbriquées, de manière efficace.

Choisir une bibliothèque de données pour gérer Docker Compose efficacement​

Docker Compose a une structure de données très complexe : elle est profondément imbriquée, et certains objets en bas de la hiérarchie sont liés à ceux du haut. J'ai cherché une bibliothèque Docker Compose en TypeScript, mais n'en ai trouvé aucune, donc j'ai construit la mienne à partir de zéro.

Elle n'est actuellement pas open-source, mais nous avons un formulaire pour demander un accès.

Cette bibliothèque centralise tous les états dans une grande classe Compose. En gérant l'état d'une seule instance de Compose, il devient simple de rester à jour avec toutes les données liées aux tâches.

Gestion de l'état avec React​

Dès le début, nous savions que nous devions gérer l'état de Compose côté client, car de nombreuses mutations d'état ont lieu sur la page du playground.

Mais quel outil choisir entre React UseState, Zustand, Recoil, Redux... ?

Nous avons choisi Zustand pour la gestion d'état grâce à sa bonne intégration avec Next.js et sa capacité à modifier l'état en passant une fonction plutôt qu'un nouvel objet.

Pourquoi cela importe-t-il ?
Avec une approche traditionnelle, en utilisant setData(newData), un nouvel objet Compose serait recréé à chaque mise à jour de l'état, comme ceci :

const [compose, setCompose] = useComposeState()

setCompose(new Compose(whatever you change))

Cela entraînerait une nouvelle instance de Compose à chaque fois, ce qui pourrait causer des inefficacités ou des re-rendus inutiles.

Avec Zustand, nous pouvons passer une fonction de modification, permettant d'appliquer directement les changements à l'objet existant sans en créer un nouveau :

const [compose, setCompose] = useComposeState()

setCompose((oldCompose) => oldCompose.whateverChange(anyParamsNeeded))

Cette approche permet des mises à jour ciblées tout en gardant l'instance intacte. Pour des changements plus précis, vous pouvez modifier directement les propriétés au sein de l'état :

const [compose, setCompose] = useComposeState()

setCompose((oldCompose) => {
    oldCompose.service1.name = "nouveau nom"
})

En utilisant cette méthode, nous maintenons la simplicité et l'efficacité des mises à jour d'état sans compromettre l'intégrité de l'instance Compose.

Mais vous vous demandez peut-être, à quoi ressemble le store Zustand ?

"use client";

import { create } from "zustand";
import { Compose } from "@entrecompetents/composecraftLib";
import { generateRandomName } from "@/lib/utils";

interface ComposeState {
    compose: Compose;
    setCompose: (updater: (currentCompose: Compose) => void) => void;
}

export const useComposeStore = create<ComposeState>((set) => ({
    compose: new Compose({ name: generateRandomName() }),
    setCompose: (updater: (currentCompose: Compose) => void) => {
        set((state) => {
            updater(state.compose);
            return { compose: state.compose };
        });
    },
}));

La bibliothèque GUI nodale​

Les options étaient : JointJS, react flow, mermaidJS (peut-être d'autres, mais nous n'avons pas exploré plus loin).

Voici un petit tableau récapitulatif de notre choix :

Nous avons finalement choisi React Flow pour son interactivité et le fait qu'il soit open source.

Cependant, gardez à l'esprit que ce n'est pas la voie la plus simple, car React Flow nécessite beaucoup de développement personnalisé.

Le schéma du playground :​

Conclusion :​

Créer une interface graphique nodale pour gérer les données Docker Compose dans une application Next.js est un processus à plusieurs niveaux combinant gestion d'état efficace, une bibliothèque GUI robuste, et des outils développés sur mesure. À travers cette exploration, nous avons :

1. Créé une bibliothèque TypeScript adaptée à la complexité et à la nature imbriquée de la structure Docker Compose.
2. Optimisé la gestion de l'état client avec Zustand, permettant des mises à jour efficaces sans recréer d'objets ou d'instances entiers.
3. Choisi React Flow comme bibliothèque GUI nodale, en exploitant son interactivité et sa personnalisation, tout en surmontant une courbe d'apprentissage importante avec des développements ciblés.

Cette intégration, représentée dans le schéma final, montre un flux de travail rationalisé où les modifications d'état profondément imbriquées, les interactions GUI et les communications avec le backend fonctionnent harmonieusement ensemble. Les outils choisis répondent non seulement aux exigences fonctionnelles mais aussi aux objectifs de performance, d'ergonomie et d'évolutivité.

Ces efforts aboutissent à une page de playground offrant une expérience utilisateur interactive et cohérente, tout en respectant les meilleures pratiques techniques.

La récente sortie de Traefik v3 apporte de nombreuses nouvelles fonctionnalités. Cet article n'a pas pour but d'expliquer toutes les nouveautés de Traefik v3, mais de vous montrer comment l'utiliser avec Docker compose.

Prérequis​

Avant de commencer, vous devez avoir Docker et Docker compose installés sur votre machine. Si vous ne les avez pas installés, vous pouvez suivre la documentation officielle pour les installer.

Créer un fichier Docker compose​

Créons un fichier docker-compose.yml simple pour déployer un serveur web et Traefik v3.

version: '3.8'
services:

  traefik:
    image: traefik:v3.0
    networks:
      - web
    ports:
        - target: 80
          published: 80
          protocol: tcp
          mode: host
        - target: 443
          published: 443
          protocol: tcp
          mode: host
    environment:
      - TZ=Europe/Paris
    command:
        - --providers.swarm.endpoint=unix:///var/run/docker.sock
        - --providers.docker.exposedbydefault=false
        - --providers.swarm.network=fdp_web
        - --accesslog
        - --entryPoints.websecure.address=:443
        - "--certificatesresolvers.myresolver.acme.tlschallenge=true"
        #- "--certificatesresolvers.myresolver.acme.caserver=https://acme-staging-v02.api.letsencrypt.org/directory"
        - "--certificatesresolvers.myresolver.acme.email=organisation@lesfousdupeloton.com"
        - "--certificatesresolvers.myresolver.acme.storage=/letsencrypt/acme.json"
        - "--entryPoints.web.forwardedHeaders.trustedIPs=10.0.0.0/24,10.0.2.0/24,192.168.100.0/24"
        - "--entryPoints.websecure.forwardedHeaders.trustedIPs=10.0.0.2/24,10.0.2.0/24,192.168.100.0/24"
        - --accesslog.filepath=/log/acces/access.log
        - "traefik.http.middlewares.exclude-ip-log.ipwhitelist.sourceRange=217.72.195.109"  # Adresse IP à exclure pour le ping
    volumes:
        - ./certs:/letsencrypt
        - /var/run/docker.sock:/var/run/docker.sock:ro
        - ./log:/log
    deploy:
        placement:
          constraints:
            - node.role == manager
        restart_policy:
          condition: on-failure
          delay: 5s
          max_attempts: 3
          window: 120s
        labels:
          - "traefik.enable=false"

  frontend:
    image: registry.gitlab.com/entrecompetents/lesfousdupeltoton/frontend:1.0.8
    hostname: frontend.lfdp
    networks:
      - web
    deploy:
      mode: replicated
      replicas: 1
      labels:
        - "traefik.enable=true"
        - traefik.http.services.frontend.loadbalancer.server.port=8080
        - traefik.http.routers.frontend.rule=Host(`lesfousdupeloton.com`)
        - "traefik.http.routers.frontend.entrypoints=websecure"
        - "traefik.http.routers.frontend.tls.certresolver=myresolver"
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
    healthcheck:
      test: ["CMD", "curl", "--fail", "http://localhost:8080/"]  # Commande de vérification de santé utilisant curl
      interval: 5s  # Intervalle de vérification de santé
      timeout: 2s    # Délai d'attente pour la vérification de santé
      retries: 3     # Nombre de tentatives avant de marquer le conteneur comme non sain
      start_period: 10s  # Délai avant de commencer les vérifications de santé après le démarrage du conteneur

  
networks:
  web:

Lorsque l'on travaille sur une API, il est important de pouvoir déboguer cette dernière. 

Les outils de débogage d'API peuvent se diviser en deux classes : ceux qui permettent d'éditer les requêtes HTTP envoyées, et ceux qui permettent d'inspecter le réseau pour voir ce qui a été envoyé a posteriori.

Dans la première catégorie, on retrouve des outils assez connus comme Postman, Insomnia ou Curl.

Dans la seconde catégorie, Wireshark supplante la plupart des solutions disponibles. Heureusement, il est open-source et gratuit.

Dans quel(s) cas utiliser Wireshark ?​

Wireshark nous permet d'intercepter les requêtes du réseau, il est donc utile quand :

• On souhaite connaître les requêtes réseau d'un outil sans avoir accès à son code.
• On souhaite vérifier le contenu des requêtes envoyées par un service.

Ci-dessous on montre que wireshark est non intrusif dans l'envoi ou la réception des requêtes HTTP, il se pose en observateur du réseau.

Comment utiliser Wireshark ?​

Pour installer Wireshark, vous pouvez suivre la page officielle d'installation.

Une fois installé, à l'ouverture, Wireshark présente les réseaux disponibles sur l'ordinateur ainsi que leur activité. (c.f capture d'écran ci-dessous)

Une fois les interfaces sélectionnées, l'utilisateur peut lancer la capture des requêtes. Il faut noter que les requêtes en HTTPS seront capturées, mais illisibles, car chiffrées.

Comme sur la capture d'écran ci-dessous l'utilisateur peut aussi ajouter des filtres pour n'afficher que les requêtes utiles.

L'interface d'inspection des requêtes est particulièrement utile. Elle permet de regarder en détail le contenu de la requête HTTP et comprendre ce qu'a reçu le destinataire.

Ainsi cet atout "non intrusif" de Wireshark en fait un allié précieux pour le débogage d'applications.

De nombreux outils sont disponibles pour déboguer le réseau, que cela soit pour déboguer une API REST ou pour analyser le traffic sur un routeur ou un réseau local.

Un comparatif est fait sur notre article sur Wireshark.

Tshark est la version CLI de wireshark, et vous permet de faire des captures avec votre outil préféré quand vous n'avez pas accès à une GUI, ou que tout simplement le serveur en CLI ne possède pas d'environnement graphique.

L'avantage c'est que vous pouvez exporter la capture réseau et l'ouvrir sur votre PC avec Wireshark ! Nous verrons cela en fin d'article.

Comment utiliser Tshark ?

Installation de tshark​

Vous pouvez suivre la documentation officielle, sur du debian-based il suffit de tapper apt install tshark.

Vous avez également tshark en installant Wireshark. Et tout comme wireshark, tshark utilise Dumpcap comme moteur de capture.

Tshark a l'avantage d'être un outil léger et puissant, qui s'installe sur de nombreuses plateformes.

A l'installation vous pouvez choisir de donner l'accès à l'analyse réseau à tous les utilisateurs ou uniquement aux sudoers.

Comment capturer des paquets avec Tshark ?​

Commandes de bases utiles​

Pour voir la liste des interfaces capturables : tshark -D. Vous avez l'avantage de voir également les interfaces virtuelles.

Pour capturer : tshark ou tshark -i <interface_name>.

Vous pouvez faire des filtres complexes avec tshark -f "${filter} comme tcp port 80, de la même manière que les filtres sur wireshark.

Pour aller plus loin​

La documenation officielle est très complète, et la commande tshark --help est très utile, tout comme le man.

Exporter et ouvrir la capture sur Wireshark​

Un énorme atout de tshark c'est l'intercompatibilité et le format de capture.

Pour enregistrer une capture dans un fichier il faut utiliser l'option -w comme ceci : tshark -w <filename>.pcap.

Pour lire un fichier pcap, vous avez deux options :

• ouvrir en GUI avec Wireshark
• ouvrir avec tshark en colorant avec : tshark -r <filename>.pcap --color

Docker commit [nom du container] [nom de image]:[tag]

Cette commande permet de créer une image en faisant une sorte de "snapshot" du container ciblé. Mais, je me demandais quelles sont les différences avec docker build (mis à part le Dockerfile) ?

J'ai pris du temps pour étudier un cas très simple et regarder les différences que cela produit :

Les différences entre docker commit et docker build :​

Les deux commandes docker commit et docker build permettent de créer des images docker. Mais docker commit permet de la créer à partir d'un container existant et docker build permet de la créer à partir d'un Dockerfile .

Protocole de test de comparaison de docker commit et docker build :​

1. Construire une image nginx:1.24.0 à laquelle on ajoute le paquet iputils-ping .
2. Faire cet ajout en une seule ligne de commande.

Le Dockerfile :

FROM nginx:1.24.0

RUN apt update && apt install iputils-ping -y

Dans ce cas on observe une différence de 1254 Octets, soit envion 0.0001mb.

Les poids exacts des images sont de :

• 155 182 582 octets pour le docker build
• 155 183 836 octets pour le docker commit

Différences d'attributs​

Si la taille des images n'a que très peu changé, les attributs eux sont radicalement modifiés :

L'image créée avec docker build à perdu les attributs suivants :

• Cmd
• EntryPoint
• Env
• Labels
• Exposed ports
• Stop signal
• Docker version
• Parent

Conclusion des différences entre docker commit et docker build :​

Il n'y a pas de meilleure solution, elles ont juste des buts différents :

Docker commit devrait surtout être utilisé pour customiser une image docker pour simplifier l'utilisation de celle-ci par la suite.

Exemple :​

Ajouter un paquet, modifier rapidement une image à des fins de test...

Docker build devrait être utilisé quand on crée un nouveau cas d'utilisation et notamment que l'on souhaite garder une version scriptée de son image sous forme de Dockerfile. Ce qui est bien plus pérenne qu'une image stockée dans un registry.

Les sources de mon expérience et toute ma démarche sont disponibles sur ce repos : https://github.com/LucasSovre/sourcesCommitVsBuild/tree/main

Normalement cela ne devrait rien changer à la mécanique étudiée, mais les tests ont été faits avec un processeur ARM (m1)

Sources​

• Dockerfile commit officielle
• Docker build documentation officielle
• Docker commit documentation officielle
• Code sources

À quoi servent ces outils ?​

Ces deux outils servent à collecter des listes d'emails, puis envoyer des emails en masse.

Où trouver ces outils ?​

Site officiel de Listmonk

Site officiel de MailChimp

MailChimp un outil ultra-complet​

MailChimp est un outil "tout-en-un". Serveur mails, automatisation, collecte de données, formulaires d'inscription… Presque rien ne manque.

Listmonk, un outil focalisé sur les mails​

Listmonk lui ne s'encombre pas de toutes les fonctionnalités d'automatisation ou d'un éditeur de wysiwyg (Ce qui serait quand même bien agréable). Mais ce qu'il fait il le fait bien, et surtout, il utilise des serveurs mails externes.

Coté finance​

En termes de prix Listmonk est imbattable puisqu'il est gratuit. Même si l'on compte le prix des serveurs et de fournisseurs de serveurs mail : les prix de Mailchimp restent beaucoup plus haut.

Avec une base d'utilisateurs de 10 000 utilisateurs et un envoi moyen de 5 mails par personne et par mois :

MailChimp a : au 3 décembre 2023 un coût de 125€/mois.

En partant du principe que vous utilisez Amazon SES pour les mails (0,09€/1k emails). MailChimp vous coûtera 4,5€ par mois.

Il faudrait que votre infrastructure (uniquement celle dédiée à Listmonk) vous coûte plus de 120€ par mois pour que MailChimp soit plus intéressant.

On voit donc qu'en termes d'économies Listmonk peut être vraiment très intéressant. Sachant que avec Listmonk vos listes d'abonnés sont illimitées.

Comment combler les manques de fonctionnalités de Listmonk ?​

Comme dit précédemment : Listmonk n'as pas d'automatisation des parcours utilisateurs ou d'envoi automatiques d'emails. Mais à l'aide d'un n8n auto-hébergé, vous pourrez très facilement créer des automatisations encore plus poussées en no-code.

Voici, ci-dessous : un exemple d'automatisation n8n-lismonk. Ce workflow est déclenché par l'appel d'un webhook, recupère les informations de l'utilisateur depuis la base de de données, crée l'utilisateur dans la base listmonk si necessaire puis, lui envoi un mail.

Dans l'exemple suivant, ce worklow permet de programmer l'envoi d'un mail transactionel dans n jours|heures|minutes à un utilisateur.

Seul l'éditeur wysiwyg de MailChimp manque vraiment, mais quelques templates de mails vous suffirons surement et vous pouvez facilement vous en procurer pour quelques euros.

Vous pourrez trouver le noeud n8n listmonk sur ce package npm

Comment installer Listmonk ?​

La page d'installation de Listmonk est très complète, mais voici un petit résumé en accéléré :

Vous pouvez utiliser la commande suivante si vous n'avez pas déjà de base de donnée PostgreSQL :

mkdir listmonk && cd listmonk
sh -c "$(curl -fsSL https://raw.githubusercontent.com/knadh/listmonk/master/install-prod.sh)"

Si vous avez déjà une base de donnée alors il vous suffit de lancer un conteneur avec la configuration associée.

Comment intégrer Listmonk dans votre infrastructure ?​

Voici un schéma qui reprend tous les éléments précédents pour donner un exemple d'intégration de Listmonk dans vos outils.

Sources​

• https://mailchimp.com
• https://listmonk.app
• https://listmonk.app/docs/
• https://aws.amazon.com/fr/ses/
• https://n8n.io