Toute la documentation

Démarrer

  1. 01Pour commencer
  2. 02Installation
  3. 03Suivi

Fonctionnalités

  1. 04Le tableau de bord
  2. 05Objectifs
  3. 06Liens courts
  4. 07Sources et agents IA
  5. 08Rapports par e-mail
  6. 09Vérification planifiée
  7. 10Interrogez votre IA

Référence

  1. 11Configuration
  2. 12API HTTP

Plateformes

  1. 13Serveur autonome
  2. 14PHP
  3. 15WordPress
  4. 16Drupal
  5. 17Craft CMS
  6. 18Python
  7. 19Rails
  8. 20Ruby
  9. 21Go
  10. 22Java
  11. 23.NET
  12. 24Elixir
  13. 25Rust

Confiance

  1. 26Confidentialité

Plateformes

Ruby

Runlight tourne sous Ruby 3.2 ou plus récent, dans une application Rack comme Sinatra, Hanami ou Roda, ou sur son propre domaine en serveur autonome.

La gem Ruby, c’est Runlight réécrit en Ruby. Elle sert le même tableau de bord et la même API, et elle donne à chaque requête la même réponse que la bibliothèque TypeScript. Ses chiffres vont dans les mêmes tables, donc chacune peut lire une base de données écrite par l’autre. Il lui faut Ruby 3.2 ou plus récent, et elle garde ses données par ActiveRecord, qu’elle apporte avec elle. Pour une application Rails, la page Rails propose un engine et un générateur qui font la configuration à votre place.

Installation

Ajoutez la gem avec le pilote de votre base de données.

bash

bundle add runlight sqlite3

Utilisez pg pour Postgres, ou trilogy ou mysql2 pour MySQL et MariaDB, à la place de sqlite3.

Créer l’instance

Créez une instance au démarrage de l’application et partagez-la.

runlight.rb

require "runlight"

RL = Runlight.new(
  store: Runlight::Stores.sqlite("data/runlight.db"),
  site: { name: "example.com", hostnames: ["example.com"], timezone: "Europe/London" },
)

Les options portent les noms de Configuration, écrits en snake case, donc sites, trust_proxy, rate_limit, mail et managed_sites fonctionnent tous comme là-bas. Les tables sont créées à la première requête.

Stockages

Les tables de Runlight commencent par rl_. Chaque stockage accepte prefix: à utiliser à la place, comme Runlight::Stores.sqlite(path, prefix: "wp_rl_"), pour que deux applications qui partagent une base gardent chacune leurs propres tables. Un préfixe compte jusqu’à 32 lettres, chiffres et tirets bas, et ne commence pas par un chiffre. store.tables liste les tables du stockage par leur nom, pour une application qui retire Runlight.

SQLite

ruby

Runlight::Stores.sqlite("data/runlight.db")

Gardez le fichier hors de tout dossier que sert le serveur web. Le dossier est créé s’il manque, et la base tourne en mode WAL, donc plusieurs processus peuvent la partager.

MySQL et MariaDB

ruby

Runlight::Stores.mysql("mysql://runlight:password@127.0.0.1:3306/runlight")

Ce stockage fonctionne avec MySQL 8.0.20 ou plus récent et MariaDB 11.4 ou plus récent, par la gem trilogy quand elle est installée et par mysql2 sinon. Une URL mariadb:// fonctionne aussi. statement_timeout: 30_000 arrête toute requête SQL au bout de ce nombre de millisecondes, 120000 par défaut, comme dans Configuration.

Postgres

ruby

Runlight::Stores.postgres("postgres://runlight:password@127.0.0.1:5432/runlight")

Ce stockage a besoin de la gem pg. Il accepte aussi statement_timeout:, et schema: "analytics" garde les tables dans leur propre schéma. Runlight::Stores.url choisit le stockage d’après un DATABASE_URL qui commence par postgres://, mysql://, mariadb:// ou sqlite:.

La base ActiveRecord d’une application

ruby

Runlight::Stores.active_record

Ce stockage garde les tables de Runlight dans la base à laquelle l’ActiveRecord de l’application se connecte déjà, à côté des tables de l’application. Passez une classe de modèle abstraite, comme Runlight::Stores.active_record(AnalyticsRecord), pour utiliser une autre des bases de l’application. Ses écritures rejoignent une transaction ouverte par l’application.

Applications Rack

Placez Runlight devant l’application dans config.ru.

config.ru

require_relative "runlight"
require_relative "app"

use Runlight::RackApp, runlight: RL, base_path: "/runlight"
run App

Runlight répond aux chemins sous /runlight, aux liens courts sur /go et à tout domaine de liens que vous ajoutez dans les Réglages, et transmet toutes les autres requêtes à l’application. Il enregistre aussi au passage les requêtes des agents IA, ce qui ne prend aucun temps pour les autres visiteurs. Runlight vérifie lui-même ses requêtes, donc il se place avant tout middleware CSRF. Ajoutez le script à chaque page, juste avant </head>.

html

<script defer src="/runlight/s.js"></script>

Définissez ensuite RUNLIGHT_TOKEN avec une longue chaîne aléatoire et ouvrez une fois /runlight/?token= suivi de cette chaîne pour vous connecter, comme l’explique Pour commencer. Avec accounts: true dans les options et un RUNLIGHT_SECRET, chacun se connecte avec son propre e-mail et son propre mot de passe, comme dans Comptes. Passez token: pour définir le jeton dans le code, où une chaîne vide garde le tableau de bord fermé et nil le laisse ouvert à tout le monde.

RL.rack_app(base_path: "/runlight") est la même application sans rien derrière, pour un config.ru qui la monte sur son propre chemin avec map.

Un lien court sur /go/<name> sans lien de ce nom continue vers l’application, donc sa propre page 404 y répond, comme celle de Rails. RL.rack_app n’a aucune application derrière lui et y répond lui-même avec un 404. Sur un domaine de liens, /go/<name> est un 404 comme tout autre chemin qui n’est pas l’un des liens de ce domaine.

La vérification planifiée

La vérification planifiée envoie les rapports par e-mail et garde les données en ordre. Appelez-la toutes les quelques minutes depuis cron, un planificateur de tâches ou un thread à vous.

ruby

RL.check

Quand rien dans l’application ne peut la lancer à intervalles réguliers, définissez CRON_SECRET et faites appeler /runlight/api/check avec lui par un planificateur externe, comme le montre Vérification planifiée.

Le serveur autonome

La commande runlight de la gem fait tourner Runlight sur son propre domaine, comme stats.example.com, à la manière du serveur autonome. Elle sert le tableau de bord à la racine, gère les sites depuis le tableau de bord, et propose des comptes de connexion et des liens courts sur n’importe quel domaine que vous faites pointer vers elle.

bash

mkdir stats && cd stats
bundle init && bundle add runlight sqlite3 puma
bundle exec runlight serve

Le serveur écoute sur le port 3000, ou sur PORT. Il tourne sous Puma quand la gem est présente et sous WEBrick sinon, et le config.ru du dossier le fait tourner sous n’importe quel autre serveur Rack. Les données vivent dans runlight-data, dans le dossier depuis lequel vous le lancez. À son premier démarrage, il affiche un lien avec un code à usage unique qui crée le premier compte, et bundle exec runlight setup affiche le lien à nouveau. Les rôles, les invitations, la connexion à deux facteurs et l’ajout de sites fonctionnent comme sur le serveur autonome.

Les réglages viennent des variables d’environnement que lit le drop-in PHP, comme RUNLIGHT_URL, DATABASE_URL, DATA_DIR, RUNLIGHT_SECRET, TRUST_PROXY et RUNLIGHT_GEO, ou d’un config.rb dans le dossier qui renvoie un Hash avec les mêmes noms. Les variables d’environnement l’emportent quand les deux sont définis. Le serveur lance la vérification planifiée toutes les cinq minutes, et bundle exec runlight cron la lance depuis cron pour un serveur qui ne tourne pas en permanence.

Les autres tâches de la commande sont décrites dans bundle exec runlight --help. password donne un nouveau mot de passe à un compte et l’affiche, migrate met à jour les tables tout de suite, et agents lit les agents IA dans le journal d’accès d’un serveur web, comme le fait celle du drop-in PHP.

Différences avec la bibliothèque TypeScript

La gem Ruby passe les tests de conformité imposés à la bibliothèque TypeScript, sur SQLite, Postgres, MySQL et MariaDB. Les différences viennent de la façon dont tournent les applications Ruby.

  • Le pool de connexions est celui d’ActiveRecord. Chaque stockage qui ouvre sa propre base a un pool de cinq connexions par processus, et le pool ActiveRecord de l’application sert Runlight::Stores.active_record.
  • Ce que la bibliothèque TypeScript fait en arrière-plan, comme supprimer des visites après le choix d’une durée de conservation plus courte, s’exécute une fois la réponse envoyée, quand le serveur Rack ferme le corps de la réponse.
  • Les limites de mots de passe erronés sont gardées dans la base, donc tous les processus les partagent. La limite de débit du traceur vit dans de petits fichiers du dossier temporaire du système, que partagent tous les processus d’une même machine.
  • Les rapports par e-mail mettent en forme les nombres, les dates, les montants et les noms de pays à partir d’une copie des données ICU qu’utilise Node, puisque Ruby n’en a pas.