Chapitre 01
Contexte edge & poste d'ingénierie
Objectifs du chapitre
- Comprendre ce qu'est un edge device et le rôle qu'il joue dans une cellule d'automatisme : passerelle de données, horloge, point d'accès distant.
- Situer les briques logicielles qu'on va manipuler tout au long du cours : Debian, systemd, Docker, chrony, SSH.
- Se connecter la première fois depuis le laptop d'ingénierie et prendre ses repères sur une machine qu'on n'a pas installée soi-même.
- Adopter le réflexe de base de l'exploitation d'un edge en production : observer avant d'agir.
1. Qu'est-ce qu'un edge device ?
Un edge device (ou edge gateway) est un petit ordinateur industriel placé au plus près de la machine — dans l'armoire électrique, sur le réseau OT — dont le rôle est de faire le pont entre le monde de l'automate et le monde informatique. Concrètement, sur notre cellule il fait trois choses :
- Passerelle de données : il lit des variables dans le CPU S7-1500 (en OPC-UA, port 4840) et les republie vers un historian ou un broker MQTT — pour la supervision, la maintenance prédictive, un tableau de bord.
- Serveur de temps : il porte une horloge
chronyet distribue l'heure par NTP à l'automate et aux switches de la cellule (chapitre 5). Un edge bien réglé est souvent la référence de temps locale de l'îlot. - Point d'accès distant : câblé en permanence, il est le seul élément de la
cellule sur lequel on peut ouvrir une session
sshet faire tourner des outils. C'est depuis lui qu'on diagnostique le réseau (cf. le cours réseau), qu'on capture, qu'on scanne.
Matériellement, c'est souvent un PC industriel fanless (type IPC Siemens, Advantech, ou un Raspberry Pi durci) sous Debian ou une Debian dérivée. Peu de RAM, un disque SSD ou une carte industrielle, pas d'écran : on l'administre uniquement à distance.
ssh — c'est notre
unique porte d'entrée pour tout le cours.2. Le socle logiciel qu'on va manipuler
Inutile de tout connaître d'un coup ; voici la carte des briques et le chapitre qui les traite.
| Brique | Rôle sur l'edge | Chapitre |
|---|---|---|
sshd | serveur SSH — l'accès distant depuis le laptop | 2 |
| systemd | gestionnaire de services (démarrage, redémarrage, dépendances) | 3 |
journald | journalisation centralisée de tout le système | 4 |
chrony | client & serveur NTP — l'horloge de la cellule | 5 |
| Docker | exécution du service applicatif en conteneurs | 6–7 |
tar/rsync/timers | sauvegarde & restauration | 8 |
Le fil conducteur du cours est un service edge conteneurisé — appelons-le
edge-gateway — décrit par un fichier docker-compose.yml et lancé au boot par
une unité systemd. Autour de lui gravitent l'horloge (chrony), les journaux (journald) et l'accès
(sshd). Quand « le service edge ne répond plus », le coupable est presque toujours l'une de
ces briques : le cours t'apprend à les inspecter dans l'ordre.
3. Pourquoi Debian + systemd + Docker ?
Trois choix omniprésents sur les edges industriels, qu'il vaut la peine de comprendre :
- Debian — distribution stable, à cycle long, sans surprise : exactement ce qu'on veut sur une machine qui doit tourner des années sans qu'on y touche. La version courante, Debian 12 « bookworm », sert de référence dans tout le cours.
- systemd — le premier processus lancé au démarrage (PID 1). Il démarre, supervise et redémarre tous les services, gère les dépendances entre eux et centralise les journaux. Le maîtriser, c'est tenir 80 % de l'exploitation d'un edge.
- Docker — le service applicatif est livré en image de conteneur : tout son environnement (bibliothèques, runtime, dépendances) est figé dedans. On déploie une version testée à l'identique, on la met à jour ou on revient en arrière proprement. C'est ce qui rend le terrain reproductible.
4. Se connecter la première fois
Depuis le laptop, on ouvre une session SSH vers l'edge. On détaille SSH au chapitre 2 ; ici, la version minimale pour arriver au shell :
laptop:~$ ssh maint@192.168.0.10
The authenticity of host '192.168.0.10' can't be established.
ED25519 key fingerprint is SHA256:9r0c...k8Qe.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
maint@192.168.0.10's password: (saisie masquée)
Linux edge-cell12 6.1.0-18-amd64 #1 SMP Debian 6.1.76-1 x86_64
Last login: Tue Jul 1 08:12:03 2026 from 192.168.0.50
maint@edge-cell12:~$Trois choses à noter sur ce premier contact :
- La question sur le fingerprint n'apparaît qu'à la première connexion : SSH
mémorise l'empreinte de l'edge dans
~/.ssh/known_hosts. C'est une sécurité — on y revient au chapitre 2. - L'invite change :
maint@edge-cell12confirme qui tu es et sur quelle machine. Dans ce cours, l'invite vertemaint@edge-cell12:~$signale « tu es sur l'edge », l'invite bleuelaptop:~$« tu es sur le laptop ». - Le compte
maint(maintenance) est un utilisateur non-root : on passera parsudopour les actions privilégiées, jamais enrootdirectement.
Attention à où tu tapes tes commandes. Une erreur classique : lancer un
reboot ou un docker compose down en croyant être sur le laptop alors qu'on est
dans la session SSH sur l'edge. Regarde toujours l'invite. Un bon réflexe : personnaliser le prompt
de l'edge (couleur, hostname en évidence) pour qu'aucune confusion ne soit possible.
5. Prendre ses repères sur une machine inconnue
Tu hérites souvent d'un edge que quelqu'un d'autre a installé. Avant toute action, on fait le tour du propriétaire. Ces commandes sont en lecture seule : aucun risque.
Qui suis-je, quelle machine, quel OS ?
maint@edge-cell12:~$ hostnamectl
Static hostname: edge-cell12
Icon name: computer-embedded
Machine ID: 4f6c9d2b1a...e3
Boot ID: 7a1e...9c
Operating System: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.1.0-18-amd64
Architecture: x86-64Depuis combien de temps tourne-t-elle, et est-elle chargée ?
maint@edge-cell12:~$ uptime
08:20:14 up 87 days, 3:41, 1 user, load average: 0.18, 0.22, 0.2087 jours d'uptime : la machine est stable. Le load average (0.18 sur 1 minute) est faible — un edge n'est pas censé être très chargé ; s'il l'est, c'est déjà un signal.
Reste-t-il de la place disque ? (le tueur silencieux nº 1)
maint@edge-cell12:~$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 58G 19G 36G 35% /Sur un edge, la panne la plus fréquente n'est pas exotique : c'est le disque
plein. Des logs qui gonflent, des images Docker qui s'accumulent, une sauvegarde oubliée sur
place… et à 100 % d'occupation, les conteneurs ne redémarrent plus, la base locale se corrompt, le
journal cesse d'écrire. Le tout premier réflexe de diagnostic, avant même de regarder le service,
c'est df -h. On y reviendra aux chapitres 4, 6 et 8.
Que tourne-t-il déjà ? (aperçu)
maint@edge-cell12:~$ systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
0 loaded units listed.
# Aucun service en échec : bon signe. On détaille systemctl au chapitre 3.
maint@edge-cell12:~$ docker ps --format 'table {{.Names}}\t{{.Status}}'
NAMES STATUS
edge-gateway Up 87 days (healthy)
edge-mqtt Up 87 days
# Le service applicatif et son broker tournent. Détails au chapitre 6.Un tour de reconnaissance en quatre commandes, à faire à chaque prise en main : hostnamectl
(quelle machine), uptime (depuis quand / charge), df -h (place disque),
systemctl --failed + docker ps (état des services). En moins d'une minute, tu
sais si tu arrives sur une machine saine ou sur un incident en cours.
6. La règle d'or : observer avant d'agir
Un edge en marche remonte les données d'une ligne en production. Le redémarrer, arrêter un
conteneur, changer une config réseau : tout cela a des conséquences visibles côté exploitation. La
discipline, identique à celle du cours réseau, tient en une phrase : on lit l'état
(journaux, systemctl status, docker logs) avant de toucher quoi que ce
soit, et on ne redémarre qu'en connaissance de cause.
Deux gestes qui coupent l'accès distant — donc à proscrire à l'aveugle : (1) reconfigurer le
réseau ou sshd sans filet (chapitre 2 montre comment garder une porte de secours) ;
(2) un reboot « pour voir » sur une machine à laquelle tu n'as que l'accès
SSH : si elle ne remonte pas, tu es aveugle et il faut envoyer quelqu'un sur site. Sur un edge, le
redémarrage est un acte réfléchi, pas un réflexe.
Récapitulatif
- Un edge device = passerelle de données (OPC-UA → historian), serveur de temps (NTP) et point d'accès distant (SSH) d'une cellule, sous Debian.
- Le socle qu'on va manipuler : SSH (accès), systemd (services), journald (logs), chrony (temps), Docker (service applicatif), + sauvegarde.
- On administre tout à distance depuis le laptop d'ingénierie ; surveille l'invite pour ne jamais confondre laptop et edge.
- Tour de reconnaissance à la prise en main :
hostnamectl,uptime,df -h,systemctl --failed,docker ps. - Règle d'or : observer avant d'agir ; le disque plein est la panne
nº 1 ; un
rebootà l'aveugle peut te couper l'accès.
Exercices
Exercice 1 — Le tour de reconnaissance
Tu prends la main sur un edge inconnu. Écris la suite de commandes qui te dit, en moins d'une minute : quel OS, depuis quand il tourne, combien de place disque il reste, et quels services sont en échec.
Voir la solution
$ hostnamectl | head -3 # hostname + OS
$ uptime # uptime + charge
$ df -h / # place disque sur la racine
$ systemctl --failed # services en échecOn peut tout enchaîner d'un coup : hostnamectl; uptime; df -h /; systemctl --failed.
L'ordre n'a pas d'importance puisque ces commandes ne modifient rien. Le seul chiffre qui doit
déclencher une alarme immédiate : une colonne Use% proche de 100 % sur
/.
Exercice 2 — Laptop ou edge ?
Tu as deux terminaux ouverts et tu ne sais plus lequel est la session SSH sur l'edge. Quelle commande unique tranche à coup sûr, sans rien risquer ?
Voir la solution
$ hostname
edge-cell12 # → c'est la session sur l'edge
# vs sur le laptop :
$ hostname
eng-laptophostname (ou hostnamectl) est imparable. Encore mieux à long terme :
configurer le prompt de l'edge pour qu'il affiche le hostname en couleur — la confusion devient alors
impossible d'un simple coup d'œil, sans taper de commande.
Exercice 3 — Pourquoi pas un reboot ?
Un collègue propose : « le service déconne, on reboote l'edge, ça repartira ». Cite deux raisons de ne pas le faire tout de suite, et ce que tu regardes d'abord.
Voir la solution
Deux raisons : (1) si la machine ne remonte pas (config au boot cassée, disque plein, service enabled qui échoue), tu perds ton unique accès distant et il faut se déplacer physiquement ; (2) un reboot efface l'état courant — les journaux en RAM, les conteneurs en train de logger l'erreur — donc tu détruis les preuves avant d'avoir compris la panne.
Ce qu'on regarde d'abord : df -h (disque plein ?), systemctl status
edge-gateway et docker logs (que dit le service ?), journalctl -p err -b
(erreurs depuis le boot). Neuf fois sur dix, la cause se lit dans les logs et un simple
restart ciblé suffit — sans reboot. On construit cette démarche complète au chapitre 9.