Vue normale
C’est Noël : deux outils géniaux et un nouveau Wiki !
Les conteneurs indispensables en Lab : Uptime Kuma, Dozzle, IT Tools, ConvertX et surtout Traefik
Ackify CE : preuve de lecture cryptographique en Go + Vue3
Ackify CE est une plateforme open-source (AGPL v3) permettant de générer des preuves de lecture cryptographiquement vérifiables pour des documents internes.
Le problème
Les organisations doivent souvent prouver qu'un collaborateur a lu un document (politique RGPD, charte de sécurité, formation obligatoire). Les solutions existantes sont soit trop lourdes (signature électronique qualifiée comme DocuSign à 10-30€/utilisateur/mois), soit non sécurisées (simple email).
La solution
Ackify génère des preuves de lecture cryptographiques avec :
- Signatures Ed25519 (même algo que SSH)
- Horodatage immutable (PostgreSQL triggers)
- Hash chain blockchain-like
- Vérification offline possible
Cas d'usage
- Validation de politiques internes (sécurité, RGPD)
- Attestations de formation obligatoire
- Prise de connaissance de procédures
- Accusés de réception contractuels
Différence avec DocuSign
Ackify n'est pas une alternative à DocuSign pour des contrats juridiques. C'est une solution simple pour des besoins internes où la signature qualifiée est overkill.
N'hésitez pas si vous avez des questions techniques !
- lien nᵒ 1 : Ackify.eu
- lien nᵒ 2 : Github
- lien nᵒ 3 : Documentation
Installation
curl -fsSL https://raw.githubusercontent.com/btouchard/ackify-ce/main/install/install.sh | bash
cd ackify-ce
nano .env # Configurer OAuth2
docker compose up -d
Installation complète en ~5 minutes.
Stack technique
Backend
- Go 1.24 (Clean Architecture / DDD)
- PostgreSQL 16
- Chi Router
- OAuth2 (Google, GitHub, GitLab, custom) ou Magic Link (passwordless)
Frontend
- Vue 3 + TypeScript
- Tailwind CSS
- i18n (FR, EN, ES, DE, IT)
DevOps
- Docker distroless < 30 MB
- CI/CD GitHub Actions
- Tests : 72,6% couverture (180 tests unitaires + 33 intégration)
Commentaires : voir le flux Atom ouvrir dans le navigateur
Production-Grade Container Deployment with Podman Quadlets | Larvitz Blog
Une approche intéressante pour héberger des containers (Podman en l'occurrence) : les gérer avec systemd, le gestionnaire de service de nombreuses distributions Linux.
C'est moins standard qu'un Docker Compose mais ça peut avoir un intérêt pour les admins sys pure souche qui retrouveront ainsi des outils familiers.
— Permalink
Production-Grade Container Deployment with Podman Quadlets | Larvitz Blog
Une approche intéressante pour héberger des containers (Podman en l'occurrence) : les gérer avec systemd, le gestionnaire de service de nombreuses distributions Linux.
C'est moins standard qu'un Docker Compose mais ça peut avoir un intérêt pour les admins sys pure souche qui retrouveront ainsi des outils familiers.
— Permalink
Modern Docker Management, Designed for Everyone.
Proxmox, Prometheus et Grafana, les 3 mousquetaires (avec Traefik ça fait 4 …)
GitHub - tarampampam/microcheck: 🧪 Lightweight health check utilities for Docker containers
Très pratique ça ! Des tout petits binaires pour mettre en place des healthchecks dans vos containers Docker qui exposent des services HTTP ou TCP.
Tout petits comme 75 ko au lieu de – par exemple – curl et ses ~10 Mo.
— Permalink
GitHub - tarampampam/microcheck: 🧪 Lightweight health check utilities for Docker containers
Très pratique ça ! Des tout petits binaires pour mettre en place des healthchecks dans vos containers Docker qui exposent des services HTTP ou TCP.
Tout petits comme 75 ko au lieu de – par exemple – curl et ses ~10 Mo.
— Permalink
Arcane : alternative à Portainer + agents
Je cherchais à découvrir une alternative à Portainer, qui me permette de gérer très simplement des Dockers (MàJ, add, remove, prune) sur un hôte comme des machines distantes (j’en ai déjà 3 au garage).
J’ai le plaisir d’être tombé sur Arcane de Kyle Mendell : open source, beau, complet sans tomber dans l’excès d’options, traduit en plusieurs langues, permet de visualiser les containers, images, volumes, réseaux, de les créer/retirer/mettre à jour (avec notifications), créer des stacks etc. On peut accéder à des templates de la communauté ou autres, parcourir les registres DockerHub, GitHub et compagnie. Et ça s’installe/configure très facilement en prime.
En bref : ça claque !

Suivre la documentation pour installer Arcane et celle pour ses agents. Pour ces derniers, le AGENT_BOOTSTRAP_TOKEN est juste un mot de passe de son choix (qui ne sert qu’au 1er lancement).
Exemples chez moi où je place le serveur sur un NAS Synology.
services:
arcane:
image: ghcr.io/getarcaneapp/arcane:latest
container_name: arcane
restart: always
ports:
- 3552:3552
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /volume1/docker/arcane/data:/app/data
- /volume1/docker/arcane/projects:/app/data/projects
environment:
- APP_URL=http://localhost:3552
- PUID=1000
- PGID=1000
- ENCRYPTION_KEY=o2XKBfUGHw76fN89Ipr8CGqzO75HllzZ9iebkxMo3Aw=
- JWT_SECRET=2OfmGSZa3Bfef1lzgeFI3SiEJCoK15TZ3F4UiCCWsk4=
labels:
- com.centurylinklabs.watchtower.enable=true
Et les agents (en changeant de mot de passe à chaque fois)
services:
arcane-agent:
image: ghcr.io/getarcaneapp/arcane-headless:latest
container_name: arcane-agent
restart: always
ports:
- 3553:3553
environment:
- AGENT_MODE=true
- AGENT_BOOTSTRAP_TOKEN=sXtNKgdWb93KSykAr
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /home/aerya/docker/agent-data:/app/data
labels:
- com.centurylinklabs.watchtower.enable=true
Il suffit ensuite d’ajouter les agents pour pouvoir les gérer

Seul bémol, y’a de la statistique d’envoyée, ici bloquée par mon serveur AdGuardHome, et j’ai pas trouvé d’option pour désactiver ça.

C’est peut-être pas votre cas mais moi j’ai mis du temps à trouver comment accéder à mes agents distants ^^’

Voici un aperçu de l’outil







![]()
-
- GitHub - louislam/dockge: A fancy, easy-to-use and reactive self-hosted docker compose.yaml stack-oriented manager
Upgrader une instance PostgreSQL docker
Du commit GitHub au container à jour : workflow Docker simplifié
Il arrive que des gens publient un code sur GitHub avec un Dockerfile mais sans package. Le container est donc à construire soi-même, localement.
Ça peut se faire directement depuis un compose
services:
applicationABC:
build:
context: https://github.com/user/applicationABC.git
dockerfile: Dockerfile
container_name: applicationABC
restart: always
ports:
- 8080:8080
Mais dans ce cas la mise à jour automatisée via WatchTower ne fonctionne pas puisqu’il n’y a pas d’image à aller chercher.
labels:
- com.centurylinklabs.watchtower.enable=true
Du coup voici une solution de contournement, simple et surtout qui n’implique pas d’outil tiers ou de cloner un dépôt GitHub et faire/tenir à jour un package moi-même.
Ce bout de code va checker les commits d’un dépôt GitHub à intervalles réguliers et, au besoin, construire un container à jour localement et relancer le tout.
Avec notification Discord, parce que j’aime ça.
applicationABC-autoupdate:
image: alpine:latest
container_name: applicationABC-autoupdate
restart: always
environment:
GITHUB_REPO: https://github.com/user/applicationABC.git
DISCORD_WEBHOOK: https://canary.discord.com/api/webhooks/xxx/xxx
POLL_INTERVAL: 172800 # secondes
SERVICE_NAME: applicationABC
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /tmp:/repo
command: >
sh -c "
apk add --no-cache git bash curl docker-cli jq &&
mkdir -p /repo &&
cd /repo &&
git clone --depth 1 \$GITHUB_REPO . || true &&
REPO_NAME=\$(basename -s .git \$GITHUB_REPO) &&
DEFAULT_BRANCH=\$(curl -s https://api.github.com/repos/\$(echo \$GITHUB_REPO | sed 's|.*/||;s|.git||') | jq -r .default_branch) &&
git fetch origin \$DEFAULT_BRANCH &&
git checkout \$DEFAULT_BRANCH &&
LAST_COMMIT=\$(git rev-parse HEAD) &&
while true; do
git fetch origin \$DEFAULT_BRANCH &&
NEW_COMMIT=\$(git rev-parse origin/\$DEFAULT_BRANCH) &&
if [ \"\$NEW_COMMIT\" != \"\$LAST_COMMIT\" ]; then
echo \"[$(date)] Nouveau commit détecté sur \$DEFAULT_BRANCH, rebuild...\"
git reset --hard origin/\$DEFAULT_BRANCH &&
docker compose -f /repo/docker-compose.yml build \$SERVICE_NAME &&
docker compose -f /repo/docker-compose.yml up -d \$SERVICE_NAME &&
REPO_LINK=\$GITHUB_REPO &&
COMMIT_LINK=\"\$GITHUB_REPO/commit/\$NEW_COMMIT\" &&
curl -H 'Content-Type: application/json' -X POST -d '{\"content\": \"\$REPO_NAME mis à jour automatiquement !\nBranche : \$DEFAULT_BRANCH\nCommit : \$NEW_COMMIT\nDépôt : <\$REPO_LINK|\$REPO_NAME>\nLien du commit : <\$COMMIT_LINK|voir commit>\"}' \$DISCORD_WEBHOOK &&
LAST_COMMIT=\$NEW_COMMIT
else
echo \"[$(date)] Aucun changement sur \$DEFAULT_BRANCH.\"
fi
sleep \$POLL_INTERVAL
done
"
Le travail est effectué dans le dossier temporaire.
Il suffit d’éditer les variables voire le nom du container, histoire de faire propre
applicationABC-autoupdate:
image: alpine:latest
container_name: applicationABC-autoupdate
restart: always
environment:
GITHUB_REPO: https://github.com/user/applicationABC.git
DISCORD_WEBHOOK: https://canary.discord.com/api/webhooks/xxx/xxx
POLL_INTERVAL: 172800 # secondes
SERVICE_NAME: applicationABC
Attention, la variable SERVICE_NAME doit être le nom exact du service à reconstruire/relancer
services:
applicationABC:
build:
context: https://github.com/user/applicationABC.git
dockerfile: Dockerfile
container_name: applicationABC
restart: always
ports:
- 8080:8080
![]()
-
- GitHub - Stirling-Tools/Stirling-PDF: #1 Locally hosted web application that allows you to perform various operations on PDF files
GitHub - Stirling-Tools/Stirling-PDF: #1 Locally hosted web application that allows you to perform various operations on PDF files
![]()
Stirling-PDF is a robust, locally hosted web-based PDF manipulation tool using Docker. It enables you to carry out various operations on PDF files, including splitting, merging, converting, reorganizing, adding images, rotating, compressing, and more. This locally hosted web application has evolved to encompass a comprehensive set of features, addressing all your PDF requirements.
— Permalien
Pulse : monitoring Docker (et Proxmox)
Merci Holaf pour la découverte.
Je n’ai plus de Proxmox depuis des années à la maison, je le teste avec Docker : Ubuntu, Synology et UNRAiD.
Ça fait penser à Beszel mais en plus puissant et complet bien entendu.
Pulse s’utilise en toute logique avec un serveur et des agents. Le tout s’installe en Docker ou en dur.
C’est très musclé et sécurisé, ça permet la découverte de réseaux pour ajouter des nodes Proxmox notamment. Je l’utilise de manière très simple pour ce test :
services:
pulse:
image: rcourtman/pulse:latest
container_name: pulse_serveur
ports:
- 7655:7655
volumes:
- /mnt/user/appdata/pulse:/data
restart: always
On peut ensuite définir un compte d’accès



Je souhaite ajouter des clients Docker

Il faudra pour ça générer un token par client


Et tout est ensuite expliqué pour l’installer ou le retirer. C’est très bien fait.

Mais pour ma machine sous UNRAiD je préfère passer par un container Docker
docker run -d \
--name pulse-docker-agent \
-e PULSE_URL="http://192.168.0.195:7655" \
-e PULSE_TOKEN="a297b11d70d16c15e4eb9241ace555a19bff4279c98ffaa92de5bd9d0bc9bab7" \
-e PULSE_TARGETS="http://192.168.0.195:7655|a297b11d70d16c15e4eb9241ace555a19bff4279c98ffaa92de5bd9d0bc9bab7" \
-v /var/run/docker.sock:/var/run/docker.sock \
--restart always \
ghcr.io/rcourtman/pulse-docker-agent:latest
Et je l’ai tout de suite dans ma liste de clients



Pour un NAS Synology je passe aussi par Docker. En revanche je suis leur recommandation pour ajouter un client sur la machine Ubuntu.
curl -fsSL http://192.168.0.195:7655/install-docker-agent.sh | bash -s -- --url http://192.168.0.195:7655 --token bc6f2c3e562d5c030a1b2b925a6f145050e214359542b3670a79a4a94a971c18
root@StreamBox:/home/aerya# curl -fsSL http://192.168.0.195:7655/install-docker-agent.sh | bash -s -- --url http://192.168.0.195:7655 --token bc6f2c3e562d5c030a1b2b925a6f145050e214359542b3670a79a4a94a971c18
== Pulse Docker Agent Installer ==
[INFO] Primary Pulse URL : http://192.168.0.195:7655
[INFO] Install path : /usr/local/bin/pulse-docker-agent
[INFO] Log directory : /var/log/pulse-docker-agent
[INFO] Reporting interval: 30s
[INFO] API token : provided
[INFO] Docker host ID : cf13d13b-a0e2-4bc6-b755-2535f80b4932
[INFO] Targets:
[INFO] • http://192.168.0.195:7655
[INFO] Downloading agent binary
/usr/local/bin/pulse-docker-agent 100%[=======================================================================================================================================================================================================================================>] 6.85M --.-KB/s in 0.03s
[ OK ] Agent binary installed
[ OK ] Cleared any previous stop block for host
== Configuring systemd service ==
[ OK ] Wrote unit file: /etc/systemd/system/pulse-docker-agent.service
[INFO] Starting service
Created symlink /etc/systemd/system/multi-user.target.wants/pulse-docker-agent.service → /etc/systemd/system/pulse-docker-agent.service.
== Installation complete ==
[INFO] Agent service enabled and started
[INFO] Check status : systemctl status pulse-docker-agent
[INFO] Follow logs : journalctl -u pulse-docker-agent -f
[INFO] Host visible in Pulse : ~30 seconds
Et j’ai bien mes 3 clients


Pulse est un outil sécurisé, très simple, très beau, trés complet, très léger. J’adopte !
![]()