Cet article explique comment déployer vos logiciels sur une infrastructure de edge computing exploitée par Rapid.Space... ou par vous-même avec le logiciel libre "SlapOS". Pour reproduire les étapes de l'article, vous aurez besoin d'un Raspberry Pi connecté à votre box Internet : il jouera le rôle d'infrastructure de edge computing.

Nous prendrons comme exemple l'application Matomo, une alternative à Google Analytics ayant l'avantage d'être open source et compatible avec le RGPD. Vous pourrez alors créer automatiquement plusieurs instances de Matomo sur votre Raspberry Pi et y accéder depuis partout dans le monde grâce au réseau de diffusion de contenu (CDN) de Rapid.Space.

Au-delà de Rapid.Space, vous pourrez aussi déployer automatiquement un nombre quelconque d'instances de Matomo sur toutes les infrastructures de cloud public ou privé qui sont déjà compatibles avec SlapOS : Teralab, OVH, Scaleway, AWS, Alicloud, VMWare, Vates, etc. Vous pourrez également ajouter votre propre infrastructure quelle que soit la plateforme (x86, ARM) ou la distribution Linux (Debian, Ubuntu, Red Hat, etc.).

Du cloud au edge

Pour certains développeurs, le cloud c'est "l’ordinateur de quelqu’un d’autre" hébergé dans un grand data center. Pour Richard Stallman c'est "un piège visant à forcer davantage de personnes à acheter des systèmes verrouillés et propriétaires qui leur coûteraient de plus en plus cher au fil du temps". Et plus récemment pour David Heinemeier Hansson, le créateur de "Ruby on Rails", ce sont des factures "obscènes".

Mais ces images d'Épinal font oublier que le cloud est avant tout une technologie pour automatiser le déploiement et l'exploitation d'un service informatique. Le cloud est à la moissonneuse-batteuse ce que l'administrateur système est à l'ouvrier agricole : une révolution industrielle inéluctable qui remplace des travaux manuels par des automatismes.

Le cloud, c'est donc surtout le logiciel qui permet de se passer d'administrateurs systèmes. Lorsque vous commandez un service de base de données chez un hyperscaler, ou chez Rapid.Space, votre commande est prise en compte dans un système de gestion central, une sorte d'ERP de cloud. Elle est ensuite exécutée par des démons présents dans chaque serveur de l'infrastructure de cloud. Votre service de base de données est alors livré, surveillé, sauvegardé, réparé si besoin et facturé... sans aucune intervention humaine.

Rien n'interdit alors de faire tourner les démons qui automatisent le cloud sur des serveurs présents dans vos locaux et sur une machine qui vous appartient : un Raspberry Pi par exemple. Il est alors possible de bénéficier de tous les avantages du cloud en matière d'automatisation sans dépendre de l'ordinateur de quelqu'un d'autre, que ce soit pour du IaaS, du PaaS ou du SaaS.

C'est l'idée du edge computing : une infrastructure constituée de milliers de sites avec quelques serveurs plutôt que de quelques sites avec des milliers de serveurs. Cette idée, imaginée en 2008 par les fondateurs de Rapid.Space avec la création du logiciel libre "SlapOS", a depuis été mise en oeuvre avec succès pour Airbus, Kyorin, la ville de Munich, SANEF, Stellantis, Toyota, etc. sur des services critiques dont certains sont utilisés par plus de deux millions d'utilisateurs. Le edge de Rapid.Space est également déployé dans des essaims de drones autonomes, des infrastructures de télécommunication 5G, des machines-outils, etc.

Et si le logiciel du cloud, les plans de l'infrastructure et les procédures d'exploitation sont tous publiés en licence libre, il n'y a plus de "piège" possible ni de "facture obscène". C'est l'idée du "Fully Open" : vous êtes libre de monter à l'identique votre propre fournisseur de edge cloud en quelques semaines si vous n'êtes pas satisfait des prix ou du service de Rapid.Space. Tout ce dont vous avez besoin est publié sur https://handbook.rapid.space.

Ainsi, avec le edge computing et les offres "Fully Open" il n'y a désormais plus aucune raison de ne pas adopter les technologies de cloud.

Un serveur de edge avec un Rasberry Pi

Avant de passer aux travaux pratiques, vous aurez besoin d'un Raspberry Pi 4 ou d'un Olimex LIME2 qui devront être connectés à votre box Internet. Ils serviront d'infrastructure de edge computing.

Vous aurez aussi besoin d'une carte micro-SD "EdgePacer" que vous pouvez acquérir en ligne sur https://shop.rapid.space/edge. Avec le code de réduction "PROGRAMMEZ", elle ne coûte que 5€. Toutes les procédures pour générer cette carte sont publiques et n'utilisent que des logiciels libres. Mais, faute d'espace et pour une meilleure intégration, il nous a semblé plus simple de les omettre pour cet article et de proposer une carte pré-configurée.

Lorsque vous recevrez votre carte "EdgePacer", suivez la procédure fournie d'enregistrement en ligne en créant un compte sur https://panel.rapid.space puis en cliquant sur le lien d'invitation à usage unique que vous aurez reçu par mail. Vous devriez alors voir apparaître dans la liste des "Projects" accessible depuis le panneau latéral un projet "EdgePacer Tutorial".

Après avoir cliqué sur le nom du projet, vous verrez un service "edgepacerN-theia" et un serveur "EdgePacerN". Le serveur correspond à votre Raspberry Pi 4, qui héberge le service.

Vous avez la possibilité d'inviter d'autres utilisateurs enregistrés sur Rapid.Space dans ce projet en générant un lien d'invitation avec le bouton "Invite User".

Attendez bien que tous les indicateurs colorés soient verts avant de continuer.

Theia : un IDE pour le edge

La carte micro-SD "EdgePacer" est déjà préconfigurée avec l'IDE Theia. Theia est un IDE Web qui facilite énormément le déploiement d'applications sur le edge de Rapid.Space. Theia a été créé par une société allemande appelée Typefox. Il fait désormais partie du portefeuille de logiciels de la fondation Eclipse. Il est utilisé par des entreprises telles que SAP, Ericsson, etc. Il est aujourd'hui bien intégré à SlapOS et soutenu financièrement par Rapid.Space. Vous pouvez en apprendre plus sur theia-ide.org.

Accédez à Theia

Pour accéder à votre Theia, cliquez sur le nom du service.

Il est possible que vous voyiez un message vous avertissant que votre contrat est désactivé. Vous pouvez le fermer et l'ignorer pour les besoins de ce tutoriel, un contrat actif est seulement requis pour demander des services sur les serveurs commerciaux de Rapid.Space.

Copiez ensuite dans les paramètres de connexion le mot de passe dans le champ "password", et cliquez sur le lien dans le champ "url".

Entrez le nom d'utilisateur "admin" et le mot de passe précédemment copié pour accéder à votre Theia.

Si des petites fenêtres de dialogue s'ouvrent dans le coin inférieur droit, vous pouvez les accepter ou les fermer.

Changez le thème de couleur (optionnel)

Dans la suite de ce tutoriel nous utilisons le thème sombre de Theia. Si vous souhaitez faire de même, changez le thème avec File > Preferences > Color Theme et choisissez "Dark (Theia)".

Vous pouvez aussi accéder à tous les paramètres avec File > Preferences > Open Settings.

Ouvrez l'explorateur de fichiers

Ouvrez l'explorateur de fichiers en cliquant sur l'icône d'une double feuille de papier en haut du bord gauche.

Dans le répertoire "slapos", le sous-dossier "software" contient une liste de toutes les versions de logiciels disponibles dans Theia. La liste est basée sur le dépôt officiel de logiciels de SlapOS.

Ouvrez un terminal

Vous pouvez fermer l'onglet "Problems" qui s'ouvre parfois en même temps que votre premier terminal.

Vous pouvez drag-and-drop le terminal où vous le voulez, par exemple dans la barre latérale droite, ce qui permet de le minimiser en cliquant sur l'icône.

Préparez l'état initial

Exécutez les commandes suivantes dans le terminal pour fixer l'état initial du répertoire "slapos". Ceci sert à garantir la reproductibilité de ce tutoriel pour que le point de départ soit toujours le même.

cd ~/srv/project/slapos
git fetch --all
git reset --hard 1.0.306

SlapOS utilise des tags pour fixer les versions de ses logiciels, et garantir que la construction d'un logiciel à une version donnée soit reproductible même des années plus tard.

Buildout : tout pour tout automatiser

Buildout est le langage utilisé par SlapOS pour automatiser toutes les facettes du déploiement de Matomo sur le edge :

1. build (le code binaire de Matomo qui sera exécuté)
2. allouer (les ressources dans l'infrastructure)
3. instancier (Matomo avec des ressources suffisantes)
4. configurer (Matomo en fonction des paramètres fournis par l'utilisateur)
5. orchestrer (Matomo en connectant automatiquement PHP à MariaDB)
6. surveiller (l'état de Matomo à travers une liste extensible de compteurs et d'alarmes)
7. auto-réparer (Matomo en optimisant sa configuration ou en réallouant le service ailleurs)
8. planifier la continuité technique (de Matomo en restaurant une sauvegarde sur un autre noeud d'infrastructure)
9. compter (les ressources utilisées par Matomo qui ne peuvent être allouées à un autre service)
10. facturer (les ressources utilisées par Matomo qui doivent être facturées à quelqu'un)
11. suivre les incidents (de Matomo et comment ils ont été résolus)
12. tester (les nouvelles versions de Matomo et leur conformité à toutes les exigences avant de mettre à jour l'infrastructure)

Cet article ne couvre que les étapes allant de la construction (1) à la surveillance (6). Les six autres étapes seraient nécessaires pour un déploiement commercial de Matomo sous forme de service de edge ou de cloud.

Nous allons maintenant apprendre à SlapOS comment construire Matomo. C'est le but du fichier software.cfg.

Une des magies de SlapOS est qu'il est indépendant des plateformes et des distributions. Il peut même, en théorie, supporter d'autres systèmes d'exploitation que Linux : FreeBSD, NuttX, etc. Et tout ce qui est construit par buildout est garanti de ne pas appeler d'appels système ou d'instructions CPU manquants, contrairement à ce qui se passe parfois avec les distributions binaires, y compris les images Docker.

Cela nécessite de décrire et de construire toutes les dépendances... jusqu'à la glibc. En définissant toutes les dépendances, on s'assure également de pouvoir reconstruire exactement la même chose même 20 ans plus tard. Et comme on garde une copie des sources téléchargées dans shacache (shacache.nexedi.com), on peut reconstruire même si le code source a été dépublié.

Heureusement, la plupart de ce travail a déjà été fait et peut être réutilisé en utilisant l'instruction "extends" de buildout.

Créez software.cfg

Chaque logiciel dans Slapos commence avec un fichier de configuration du logiciel. Slapos commencera d'abord à télécharger et compiler les composants nécessaires en fonction du contenu du fichier software.cfg.

Le répertoire "slapos" contient plusieurs sous-dossiers, dont trois qui nous intéressent : "slapos/software", "slapos/component" et "slapos/stack" :

• "slapos/software" contient des fichiers de configurations de logiciels qui correspondent à des services complets
• "slapos/component" contient des fichiers de configurations pour de nombreux composants individuels dont dépendent les logiciels dans "slapos/software"
• "slapos/stack" contient des fichiers de configuration génériques pour des fonctionnalités particulières utilisés par les logiciels dans "slapos/software"

Créez un nouveau dossier nommé matomo-tutorial dans "slapos/software/" (clic droit sur le dossier software, sélectionnez New Folder) pour mettre tous les fichiers concernant le déploiement.

Ensuite, créez un nouveau fichier software.cfg dans ce dossier (clic droit sur le dossier "matomo-tutorial", sélectionnez New File. Veillez bien au moment de nommer le fichier qu'il soit dans "slapos/software/matomo-tutorial/". Si ce n'est pas le cas, annulez puis cliquez d'abord ailleurs avant de refaire le clic droit sur "matomo-tutorial").

Écrivez le code suivant dans le fichier software.cfg :

[buildout]
# stack/lamp installs Apache, MariaDB and PHP
# and deploys the specified web application.
extends =
  ../../stack/lamp/buildout.cfg

[application]
# Download the web application that stack/lamp will run.
url = https://builds.matomo.org/matomo-4.13.3.tar.gz
md5sum = 6fb7750818e7371b0d624e4d24538952
archive-root = matomo

L'application Matomo s'appuie sur un ensemble de logiciels libres couramment utilisés pour construire des serveurs web et communément désigné par l'acronyme LAMP : Linux, Apache, MySQL, PHP. Pour installer Matomo, nous avons donc aussi besoin d'installer PHP, le serveur web Apache et une base de données SQL.

SlapOS fournit déjà une configuration pour installer LAMP, avec MariaDB comme base de données à la place de MySQL (MariaDB est à l'origine un fork de MySQL entièrement sous licence libre). Il suffit de l'étendre avec l'instruction "extends" de buildout. Cette configuration LAMP est même conçue pour être étendue, et prévoit des points de personnalisation qui permettent en quelques lignes de définir quelle application web déployer - Matomo en l'occurrence - et comment l'obtenir. C'est le rôle de la section [application].

Personnalisez la base de données MariaDB (optionnel)

La configuration précédente suffit déjà à déployer Matomo, mais avant de ce faire ajoutons une petite amélioration :

Par défaut, la base de donnée MariaDB déployée par "stack/lamp" a pour nom "lamp" et pour nom d'utilisateur "lamp" également. Pour personnaliser ça en "matomo" et "matomo", ajoutez les lignes suivantes à la fin du fichier :

[custom-application-deployment]
# Customize the database name and username
db-name = matomo
db-user = matomo

Installez Matomo

Ces quelques lignes suffisent à déployer Matomo. Prouvons-le !

Dans un terminal, exécutez :

slapos supply ~/srv/project/slapos/software/matomo-tutorial/software.cfg slaprunner

Dans cette commande, "~/srv/project/slapos/software/matomo-tutorial/software.cfg" indique l'emplacement d'une configuration buildout et "slaprunner" est l'identifiant d'un noeud de l'infrastructure de cloud. Cette commande a pour effet de renseigner des informations dans une base de données de l'infrastructure de cloud : ces informations indiquent que le noeud "slaprunner" doit avoir "~/srv/project/slapos/software/matomo-tutorial/software.cfg" installé.

Dans une infrastructure de cloud commerciale comme celle de Rapid.Space, cette base de données n'est autre que "l'ERP de cloud" décrit au début de cet article, et le noeud est l'un des serveurs de l'infrastructure de cloud. Cette commande est lancée par un administrateur du cloud pour installer sur ce noeud l'ensemble de logiciels nécessaires à un service. Lorsque plus tard un utilisateur demandera une instance de ce service, elle pourra alors être allouée sur ce serveur.

Dans Theia, la base de donnée est en fait une simple base SQLite intégrée dans l'instance de Theia, et le noeud "slaprunner" est contenu dans le sous-dossier "~/srv/runner". C'est en quelque sorte une mini infrastructure de cloud à échelle réduite, avec un seul noeud ("slaprunner"), entièrement contenue dans un seul service (Theia) dans une seule machine (votre Raspberry Pi 4). Cela permet de facilement développer une nouvelle configuration buildout pour déployer un service de cloud, en testant le déploiement localement dans Theia. Plus tard ça fonctionnera de la même manière dans une infrastructure commerciale de cloud à grande échelle.

C'est aussi ce qui nous permet d'utiliser un chemin local pour identifier notre configuration, au lieu d'une URL universellement accessible.

Dans un deuxième temps, le noeud d'infrastructure va interroger la base de donnée, découvrir la nouvelle entrée, récupérer le fichier de configuration et installer les logiciels requis à l'aide de buildout. Ce n'est qu'à ce moment-là que l'installation se fait. Pour lancer ce processus manuellement, exécutez :

slapos node software

Dans un noeud d'une infrastructure commerciale, cette opération se fait automatiquement en arrière-plan à intervalles réguliers (s'il n'y a pas de nouvelle entrée, le noeud ne fait rien). Cette approche asynchrone est un élément fondamental de la philosophie de SlapOS : elle décentralise les responsabilités. La base de donnée est un composant passif qui se contente de répertorier l'état souhaité de chaque noeud. Les noeuds sont les composants actifs qui convergent indépendamment vers l'état souhaité.

Dans le noeud "slaprunner" de votre Theia, cette exécution automatique en arrière-plan a été préalablement désactivée : nous allons être amené à modifier et réinstaller "software.cfg" au cours de ce tutoriel, or le fonctionnement automatique normal du noeud suppose que la configuration ne change jamais (hypothèse entièrement justifiée pour un service en production). Pour développer, ça nous gênerait donc plus qu'autre chose. Vous pourrez toujours réactiver ce paramètre plus tard depuis le panel de Rapid.Space.

Attendez que la commande finisse de s'exécuter. Cela peut prendre plusieurs heures puisqu'il faut compiler tous les logiciels dans la stack LAMP. Il peut arriver occasionnellement que l'installation s'interrompe avec une erreur, par exemple si un téléchargement échoue à cause d'un problème réseau temporaire. Dans ce cas relancez la commande jusqu'à ce qu'elle réussisse.

Pour relancer la commande à intervalles réguliers jusqu'à ce qu'elle réussisse, lancez :

while ! slapos node software; do sleep 20; done

L'ensemble de logiciels requis pour Matomo sera installé dans le noeud "slaprunner", dans un sous-dossier de "~/srv/runner/software/". Pour trouver le sous-dossier d'installation de Matomo, vous pouvez lancer :

find ~/srv/project/runner/software -name matomo

Vous devriez voir une liste de plusieurs fichiers s'afficher.

Instanciez Matomo

Exécutez :

slapos request matomo-1 ~/srv/project/slapos/software/matomo-tutorial/software.cfg

Cette commande permet à un client d'allouer une instance d'un service. Ici, "matomo-1" est le nom choisi pour l'instance, et "~/srv/project/slapos/software/matomo-tutorial/software.cfg" identifie le service. Comme slapos supply, cette commande se contente d'interagir avec la base de données de l'infrastructure de cloud. Elle va d'abord trouver un noeud sur lequel le service a été préalable pourvu avec slapos supply, puis elle alloue le service sur ce noeud, c'est-à-dire qu'elle renseigne dans la base de données des informations pour indiquer que ce noeud doit avoir instancié le service souhaité. L'instance est uniquement identifiée par son nom et le client qui l'a demandée : un client ne peut avoir plusieurs instances du même nom.

Dans une infrastructure de cloud commerciale, cette action est plus souvent faite à travers une interface web comme le panel de Rapid.Space. Dans Theia, le seul noeud est "slaprunner" et nous venons d'y pourvoir "~/srv/project/slapos/software/matomo-tutorial/software.cfg" à l'étape précédente, c'est donc forcément là que le service sera instancié.

Ensuite, comme pour l'installation, le noeud va dans un deuxième temps interroger la base de donnée, découvrir cette nouvelle allocation et instancier le service.

Pour lancer ce processus manuellement, exécutez :

slapos node instance

Cette commande sert à instancier des services alloués avec slapos request, tout comme slapos node software sert à installer des logiciels nécessaires à un service, pourvus avec slapos supply. Le design de SlapOS sépare intentionnellement l'étape de construction de l'étape d'instanciation : ça permet d'installer une fois sur une machine les logiciels nécessaires à un service, puis de déployer ensuite de multiples instances de ce service sur cette machine.

La première exécution va terminer avec une erreur. C'est normal, l'instanciation demande des ressources qui ne sont pas prêtes immédiatement. Il s'agit notamment de "frontends" dans le réseau CDN de Rapid.Space, qui servent ici à fournir un nom de domaine à votre service web Matomo : sans ça le service n'est accessible qu'à travers une IPv6 publique. Mais grâce au CDN de Rapid.Space, votre instance Matomo sera accessible de n'importe où dans le monde en IPv4, y compris si votre réseau local utilise des adresses privées. Il faut cependant le temps que la demande aboutisse et qu'un nom de domaine soit alloué.

Relancez la commande à intervalles réguliers jusqu'à ce qu'elle réussisse. Cela peut prendre plusieurs minutes.

Pour éviter de devoir relancer la commande manuellement, vous pouvez lancer une boucle qui s'arrêtera quand la commande réussit, comme

while ! slapos node instance; do sleep 20; done

Dans un noeud d'une infrastructure commerciale, slapos node instance s'exécute automatiquement en arrière-plan à intervalles réguliers, comme slapos node software.

La commande slapos node instance assure plusieurs fonctions :

• interroger la base de données pour obtenir la liste des services allouées sur le noeud
• appliquer la configuration buildout de l'instance (créer des fichiers de configuration, des scripts, etc)
• lancer les processus qui font fonctionner le service (définis par la configuration buildout)
• vérifier régulièrement que l'instance fonctionne bien (à l'aide de tests définis par la configuration buildout)

Comme les conditions de bon fonctionnement sont propres à chaque service, l'instance définit un ensemble de tests de bon fonctionnement ("promesses") qui sont vérifiés à intervalles réguliers. Par exemple : est-ce qu'on peut se connecter à la base MariaDB ? est-ce qu'on peut accéder à l'URL du frontend ? C'est la fonction de surveillance (point 6) mentionnée au début. Si l'instance diverge de son fonctionnement normal (par exemple, si un processus meurt de façon imprévue et que ça fait échouer une promesse), la configuration buildout finit par être appliquée à nouveau pour faire converger l'instance vers le fonctionnement souhaité.

Ne passez à la suite qu'une fois que slapos node instance s'exécute avec succès.

Examinez les services déployés

Chaque instance est allouée dans un dossier dédié qui contiendra ses fichiers de configuration et les données propres à l'instance. On parle de "partitions" d'un noeud d'infrastructure. Une "partition" possède aussi des ressources dédiées à l'instance, comme des adresses IPv6 accessibles publiquement. Ces partitions sont créées au moment de la configuration initiale du noeud.

Dans Theia, les données des instances sont stockés dans des sous-dossiers de "~/srv/runner/instance" : chaque instance aura son propre sous-dossier "~/srv/runner/instance/slappart0", "~/srv/runner/instance/slappart1", "~/srv/runner/instance/slappart2"...

Dans un noeud comme celui fourni par la carte EdgePacer dans votre Raspberry Pi, chaque instance correspond en outre à un utilisateur dédié, qui n'a pas accès aux données des autres instances. Les "partitions" se trouvent alors généralement dans "/srv/slapgrid". C'est d'ailleurs dans une telle partition que se trouve votre service Theia. Vous pouvez vous en rendre compte avec la commande pwd qui indique le chemin du répertoire actuel.

La stack LAMP va en réalité déployer 3 instances : l'instance "matomo-1" que vous avez demandée demande à son tour deux sous-instances. Il s'agit d'une instance "Mariadb" qui va contenir la base de donnée et d'une instance "apache-php" qui va déployer l'application web. Cela forme un arbre d'instances avec "matomo-1" à la racine. Cette dernière se contente de connecter "apache-php" à "Mariadb". C'est la fonction d'orchestration (point 5) mentionnée au début.

Pour voir les processus de chaque partition, exécutez

slapos node status

Vous remarquerez que chaque instance lance plusieurs processus pour assurer le fonctionnement du service. Certains ont fini de s'exécuter ("EXITED") : ils n'ont qu'une fonction ponctuelle. D'autres sont en cours d'exécution ("RUNNING") : ce sont ceux qui assurent le fonctionnement continu des différents aspects du service Matomo (serveur web, base de donnée, monitoring...).

Accédez à Matomo

Lorsque l'instance s'instancie, elle transmet des informations à la base de données : typiquement les paramètres de connexion qui vont permettre d'accéder au service.

Pour obtenir ces paramètres, relancez la commande :

slapos request matomo-1 ~/srv/project/slapos/software/matomo-tutorial/software.cfg

Cette commande est idempotente : comme la requête est déjà dans la base de donnée, elle n'aura aucun effet. Mais elle a une deuxième fonction : elle affiche les paramètres de connexion stockés par l'instance dans la base de données.

Lors de la première exécution l'instance n'existait pas encore et il n'y avait donc aucun paramètre à afficher. Maintenant vous devriez obtenir quelque chose comme :

{'backend-url': 'https://[2001:67c:1254:135::9ccf]:9988/',
 'mariadb-url-list': "['mysql://matomo:QOKKGVLhToj4sqbp@10.0.3.25:2099/matomo']",
 'monitor-base-url': 'https://softinst180275.host.vifib.net',
 'monitor-setup-url': 'https://monitor.app.officejs.com/#page=settings_configurator&url=https://softinst180275.host.vifib.net/public/feeds&username=admin&password=NPKYesweTIkdZesA',
 'url': 'https://softinst180276.host.vifib.net'}

Le paramètre "backend-url" correspond à l'accès en IPv6 du service. Le paramètre "url" correspond au nom de domaine du "frontend" fournit par le CDN de Rapid.Space, qui redirige vers "backend-url". Les paramètres "monitor-base-url" et "monitor-setup-url" permettent d'accéder à l'état des promesses du service ("monitoring"). Le paramètre "mariadb-url-list" contient une URL d'accès à la base de données MariaDB.

Suivez le lien fournit par "url" (ctrl + clic sur le lien dans le terminal, ou copiez-le dans un nouvel onglet).

Vous accédez alors au service web de Matomo, qui vous propose un formulaire de configuration. Cliquez sur suivant jusqu'à arriver à l'étape 3 "Installation de la base de données".

Les paramètres à rentrer peuvent être obtenus en décortiquant l'URL de la base MariaDB : dans l'ordre, dans mysql://matomo:QOKKGVLhToj4sqbp@10.0.3.25:2099/matomo :

• le premier matomo correspond au nom d'utilisateur
• QOKKGVLhToj4sqbp est le mot de passe
• 10.0.3.25:2099 est l'adresse du serveur
• le dernier matomo correspond au nom de la base

Mais au lieu de rentrer ces paramètres manuellement, nous pouvons améliorer notre fichier de configuration pour pré-remplir ces champs dans le formulaire !

Améliorez software.cfg

Complétez software.cfg de façon à obtenir :

[buildout]
# stack/lamp installs Apache, MariaDB and PHP
# and deploys the specified web application.
extends =
  ../../stack/lamp/buildout.cfg

[application]
# Download the web application that stack/lamp will run.
url = https://builds.matomo.org/matomo-4.13.3.tar.gz
md5sum = 6fb7750818e7371b0d624e4d24538952
archive-root = matomo

[custom-application-deployment]
# Customize the database name and username
db-name = matomo
db-user = matomo
# Include custom configuration in the instance deployed by stack/lamp
path = ${custom-instance-configuration:output}

[custom-instance-configuration]
# Define custom configuration for the instance deployed by stack/lamp
recipe = slapos.recipe.template
output = ${buildout:directory}/custom-matomo-instance-configuration.cfg
inline =
  [apache-php-service]
  # Pre-fill the database installation form with the required values
  environment =
    MATOMO_DATABASE_HOST=$${mariadb-urlparse:host}:$${mariadb-urlparse:port}
    MATOMO_DATABASE_ADAPTER=mysql
    MATOMO_DATABASE_TABLES_PREFIX=matomo_
    MATOMO_DATABASE_USERNAME=$${mariadb-urlparse:username}
    MATOMO_DATABASE_PASSWORD=$${mariadb-urlparse:password}
    MATOMO_DATABASE_DBNAME=$${mariadb-urlparse:path}

La configuration additionnelle est un peu plus compliquée et s'appuie sur plus ample une connaissance de l'implémentation de "stack/lamp" (qui peut s'obtenir en lisant les fichiers dans "stack/lamp") et de buildout.

Premièrement, la ligne path = ${custom-instance-configuration:output} permet de fournir un fichier contenant un bout de configuration qui sera inclus dans la configuration de l'instance déployée par "stack/lamp".

Ensuite la section [custom-instance-configuration] va créer le fichier qui contiendra le bout de configuration à inclure, à partir du contenu de "inline". La section [apache-php-service] est déjà définie dans la configuration de l'instance déployée par "stack/lamp" : c'est elle qui se charge de lancer le serveur web Apache qui va déployer l'application Matomo. Elle est ici étendue pour modifier les variables d'environnement définies au moment de lancer le processus d'Apache : Matomo utilise justement ces variables d'environnement (quand elles sont définies) pour pré-remplir le formulaire. Les expressions telles que $${mariadb-urlparse:host} seront remplacés par les différents fragments de l'URL de MariaDB.

Reconstruisez et redéployez Matomo

Nous venons de modifier le fichier software.cfg après avoir déjà installé et déployé le service défini par le contenu précédent. Par défaut, SlapOS va supposer que le contenu du fichier n'a pas changé et slapos node software et slapos node instance ne tiendront pas compte des changements.

Pour forcer SlapOS à réinstaller le service, lancez :

slapos node software --all

Une fois que la commande termine sans erreurs, lancez :

slapos node instance --all

jusqu'à ce que la commande réussisse, plusieurs fois si nécessaire.

Il n'y a pas besoin de lancer slapos supply et slapos request cette fois puisque les entrées sont déjà dans la base de données.

On aurait pu à la place définir un nouveau fichier avec un nouveau nom, par exemple "software-v2.cfg" au lieu de modifier "software.cfg", mais dans ce cas il faudrait de nouveau appeler slapos supply avec le chemin de "software-v2.cfg", puis tout installer à nouveau avec slapos node software, puis appeler slapos request avec le nouveau chemin mais avec le même nom d'instance "matomo-1" (ce qui mettrait l'instance existante à jour au lieu d'en demander une nouvelle), puis slapos node instance. C'est en fait ainsi - à peu de choses près - que sont mis à jour les services déployés en production. Mais c'est bien moins pratique pour développer un service qu'on modifie constamment.

Pour tenir compte du changement dans le processus "apache-php", redémarrez les processus avec :

slapos node restart all

(en réalité on n'a besoin de redémarrer que le processus dont le nom contient "apache-php" ; vous pouvez lister les processus avec slapos node status).

Finalisez la configuration de Matomo

Rechargez la page : les champs vont se pré-remplir automatiquement. Vous pouvez maintenant directement cliquer sur "suivant" et finaliser la configuration de votre service Matomo.

À l'étape 5, vous devrez vous créer un compte super utilisateur avec un nom d'utilisateur et un mot de passe de votre choix, et un courriel valide.

Puis à l'étape 6 vous pouvez entrer le premier site web que vous voulez analyser avec Matomo. Matomo vous fournira alors un petit script Javascript à intégrer au HTML de votre site. À vous de jouer !

Automatisez votre slaprunner

Votre Theia est livré avec l'exécution automatique de slapos node software et slapos node instance en arrière-plan désactivée. Maintenant que Matomo est prêt à l'emploi, vous pouvez activer cette fonctionnalité pour que le bon fonctionnement du service soit régulièrement vérifié, et que l'instance converge toujours automatiquement vers l'état souhaité. Notamment, si un processus du service s'arrête de manière imprévue, il sera redémarré automatiquement. C'est le cadre d'opération d'un service déployé sur un noeud en production.

Retournez sur la page de votre service Theia du panel de Rapid.Space, et changez le paramètre intitulé "Automatically Run Software/Instance" en "running".

Accédez au monitoring de votre instance

Votre instance Matomo, en plus de définir ses promesses de bon fonctionnement, déploie aussi un serveur web dédié au monitoring qui publie l'état et l'historique des promesses. L'application web https://monitor.app.officejs.com permet de s'abonner à de tels serveurs pour afficher et organiser ces données. L'ensemble des serveurs que vous suivez est simplement stocké localement dans le navigateur, vous n'avez donc pas besoin de compte.

Suivez l'URL donnée par le paramètre de connexion "monitor-setup-url" vu précédemment (ctrl + clic sur le lien dans le terminal, ou copiez-la dans un nouvel onglet). Cela va ouvrir monitor.app.officejs.com et vous abonner au monitoring de Matomo. Par la suite, tant que les données locales de votre navigateur sont préservées, il suffira d'accéder à monitor.app.officejs.com pour retrouver l'état et l'historique des promesses de toutes les instances suivies.

On retrouve ici les promesses de l'instance "matomo-1", ainsi que de ses deux sous-instances "Mariadb" et "apache-php".

Devenir opérateur de SaaS résilient et souverain

Nous avons dans ce tutoriel montré comment automatiser les 6 premières facettes ("build" à "surveiller") de ce qui pourrait à terme devenir un SaaS (Software as a Service) de Matomo capable de fournir une alternative souveraine à Google Analytics. Grâce au edge computing de Rapid.Space, il suffit d'un petit serveur derrière une connexion fibre optique grand public pour se lancer dans cette aventure. Et pour que ce service soit résilient, il suffit de dupliquer cette infrastructure modeste chez un partenaire ou un ami, en prenant soin de chiffrer la partition de données pour éviter toute fuite, ce que proposent la plupart des distributions Linux.

Pour finaliser un tel SaaS, il reste encore 6 facettes ("auto-réparer" à "tester") à ajouter à la configuration buildout. 5 de ces 6 facettes sont déjà fournies par le logiciel libre SlapOS de façon standardisée et ne nécessitent qu'un effort de configuration. La seule facette qui nécessite un effort constant est "auto-réparer".

La vie d'un système de edge ou de cloud est parsemée d'incidents. Tous les clouds, y compris les plus célèbres, sont en panne en moyenne environ 8 heures pas an. Chaque panne est l'occasion d'une démarche qualité par analyse d'origine de la panne, comme dans une usine automobile, selon la méthode des cinq pourquoi. Pourquoi Matomo a-t-il crashé ? Parce qu'il n'y avait plus d'espace disque. Pourquoi la promesse de prédiction de fin d'espace disque n'a-t-elle pas fonctionné ? Parce que la croissance de l'espace disque s'est accélérée en raison d'un pic de fréquentation. Pourquoi le pic de fréquentation n'est-il pas pris en compte ? Parce que cela coûte trop cher en ressources. Et ainsi de suite.

Il faudra alors définir comment éviter à l'avenir un tel incident : en créant une limite d'usage de ressources, en facturant plus cher une meilleure prévision de l'espace de stockage, en supprimant automatiquement les données les plus anciennes, en déplaçant Matomo sur un autre serveur, etc. Le choix de la méthode dépendra autant de critères commerciaux que techniques. Chaque incident ainsi pris en compte par un automatisme permettra de réduire les coûts d'exploitation du SaaS et donc de le proposer à plus d'utilisateurs, conduisant ainsi à de nouveaux incidents. L'amélioration d'un SaaS est un effort continu... et un signe de son succès.

Le fait que la technologie SlapOS de Rapid.Space soit 100% libre présente un avantage pour mener à bien cet effort : les incidents induits par l'environnement de edge cloud n'ont pas besoin d'être "contournés" car ils peuvent être directement résolus en modifiant SlapOS. C'est un peu comme avec les systèmes d'exploitation : lorsque Windows a un bug, il faut le contourner ou attendre qu'il soit corrigé, alors qu'avec Linux, chacun est libre de modifier immédiatement le code source du noyau. En outre, dans le cloud comme dans les systèmes d'exploitation, une offre 100% libre est aussi une garantie de ne pas subir une augmentation tarifaire soudaine à laquelle il est impossible de s'opposer.