Miroirs et un second site

Un miroir est un dépôt sur une installation Arkvory qui est une copie en lecture seule d’un dépôt d’une autre installation, la source. L’installation miroir tire les changements de la source via HTTPS. Elle conserve sa propre base de données, son propre stockage, ses propres comptes et ses propres clés.

Utilisez un miroir pour servir les téléchargements depuis un second emplacement, et pour conserver un second site capable de prendre le relais lorsque la source est perdue. Un miroir n’est pas une sauvegarde de la source, et ce n’est pas une haute disponibilité automatique. Vous effectuez la bascule vous-même. Pour d’autres protections, voir Sauvegardes et Passerelles de lecture.

Ce qu’est un miroir

Pour un dépôt mis en miroir, l’installation miroir copie :

• Les fichiers publiés, avec leurs octets et les mêmes ID d’artefact que sur la source.
• Les étiquettes, les métadonnées et les collections.
• L’enregistrement UPack, les étapes et les chemins de fichiers actuels.
• Les images de conteneurs, les objets Git LFS et les paquets npm du dépôt.
• Les suppressions. Un fichier supprimé sur la source est supprimé sur le miroir.

Les téléchargements par ID, par paquet (version, plage, étape) et par chemin de fichier répondent sur le miroir comme ils le faisaient sur la source à la dernière synchronisation. Ils continuent de fonctionner lorsque la source est indisponible.

Un miroir ne copie pas :

• Les comptes, les groupes, les clés et les autorisations. Le miroir a les siens, et ils sont indépendants : révoquer une clé sur la source n’affecte pas le miroir.
• Les références qui protègent les fichiers du nettoyage, les pièces jointes des builds, les pistes d’audit et les politiques de stockage.
• L’historique des chemins de fichiers antérieur à la première synchronisation. Les numéros de révision des étiquettes et des chemins sur le miroir lui sont propres.

Les clients ne peuvent pas écrire dans un dépôt mis en miroir. Les téléversements, les changements d’étiquettes, les chemins de fichiers, les étapes, la suppression et la promotion y reçoivent HTTP 409 avec la raison mirror_read_only. Les autres dépôts de l’installation miroir fonctionnent normalement. Les politiques de stockage ne s’exécutent pas dans un dépôt mis en miroir, et seule la synchronisation y supprime.

Configurer un miroir

Il vous faut une clé sur la source et une commande sur le miroir.

Créer une clé sur la source

Le miroir a besoin d’une clé qui ne peut que lire le dépôt source. Une clé d’écriture n’est pas nécessaire.

1. Sur la source, ouvrez Accès des services avec la clé de récupération ou une clé d’opérateur.
2. Sélectionnez Créer un compte de service, et dans Autorisations sur les dépôts ajoutez le dépôt. Sélectionnez Préréglage lecture pour renseigner les autorisations dont un miroir a besoin. Elles incluent artifact.list, artifact.read, content.read, annotation.read, asset.read et package.read.
3. Sélectionnez Émettre la clé, copiez le secret, confirmez J’ai enregistré le secret et sélectionnez Activer la clé. Une clé non activée expire après 15 minutes.
4. Enregistrez le secret dans un fichier sur le serveur miroir. Le fichier ne contient que la clé, sur une ligne, 16 à 4000 caractères imprimables. Seuls root ou le groupe Administrateurs peuvent le lire.

La source doit être une version avec le flux de changements. La commande de l’étape suivante le vérifie.

Attacher le dépôt sur le miroir

Utilisez un nom de dépôt nouveau et vide sur le miroir. La synchronisation rend le dépôt identique à la source, mais elle ne supprime jamais ce que la source n’a jamais eu.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases \
  --mirror-upstream https://arkvory.example \
  --mirror-token-file /root/mirror-releases.key

$root = 'C:\ProgramData\ProAnima\Arkvory'
& 'C:\Program Files\ProAnima\Arkvory\arkvory.ps1' configure --root $root `
  --mirror releases --mirror-upstream https://arkvory.example `
  --mirror-token-file C:\secure\mirror-releases.key

Option	Signification
--mirror NAME	Le dépôt sur cette installation. 1–64 caractères : lettres minuscules, chiffres, _ et -, en commençant par une lettre ou un chiffre
--mirror-upstream URL	L’origine de la source : https://host, sans chemin, sans identifiants et sans requête. http:// simple n’est accepté que pour localhost, 127.0.0.1 et [::1]
--mirror-token-file FILE	Un chemin absolu vers le fichier de clé
--mirror-source NAME	Le dépôt sur la source. Par défaut : le même nom que --mirror
--mirror-ca-file FILE	Un fichier PEM avec l’autorité de certification de la source. Voir HTTPS avec votre propre autorité de certification

Donnez un seul dépôt à une seule commande. Vous ne pouvez pas combiner une modification de miroir avec des modifications de HTTPS, du stockage des sauvegardes ou des mises à jour dans le même appel.

1. La commande vérifie la source avec la clé avant de modifier quoi que ce soit. La source doit annoncer le flux de changements des miroirs, et le flux du dépôt source doit répondre.
2. Elle stocke la clé dans config/mirrors/NAME.token, écrit config/mirrors/mirrors.json et définit ARKVORY_MIRRORS_FILE dans config/runtime.json.
3. Elle redémarre l’API et le worker et attend qu’ils soient prêts. Si quelque chose échoue, elle restaure les fichiers précédents et redémarre à nouveau.

Dans Docker Compose, la commande écrit aussi config/compose.mirrors.yml, qui monte les fichiers de miroir dans les conteneurs de l’API et du worker. Ajoutez-la aux commandes Compose que vous exécutez vous-même.

Pour remplacer la clé d’un dépôt, répétez la commande avec seulement --mirror et le nouveau --mirror-token-file. La source, les étapes et les autorités de certification restent inchangées, et une commande répétée ne transforme jamais un miroir en import. La commande redémarre l’API et le worker. Le worker relit aussi le fichier de clé après chaque échec, donc un fichier de clé remplacé à la main fonctionne sans redémarrage.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-token-file /root/new-mirror-releases.key

Lorsque la source refuse la clé, la commande s’arrête avant de modifier quoi que ce soit et indique pourquoi : la clé n’est pas acceptée (401), elle n’a pas le droit de lire le dépôt (403), ou le dépôt n’existe pas sur la source (404). Un dépôt qui met déjà en miroir une source refuse une autre source avec le message NAME mirrors another source; detach it first.

Sur l’installation miroir, donnez aux personnes et aux outils l’accès au dépôt. Un dépôt existe dès qu’une autorisation ou une politique de service le nomme. Utilisez Gérer l’accès aux dépôts dans Utilisateurs et accès pour les personnes, et une politique de service pour les outils. Les autorisations de la source ne sont pas transférées.

HTTPS avec votre propre autorité de certification

Si la source utilise un certificat d’une autorité d’entreprise ou auto-signée, ajoutez --mirror-ca-file /path/ca.pem à la commande --mirror. La commande vérifie que chaque certificat peut être lu et n’a pas expiré, et elle stocke 1 à 64 certificats dans config/mirrors/ca.pem (le fichier ne peut pas dépasser 1 MiB). Le worker leur fait alors confiance en plus des certificats standard.

• Le fichier sert tous les miroirs de l’installation. Un nouveau --mirror-ca-file s’y ajoute, et un certificat déjà présent n’est conservé qu’une fois. Détacher le dernier miroir supprime le fichier.
• Le worker fait confiance à l’ensemble pour toutes ses connexions, pas seulement pour un miroir.
• La vérification des certificats n’est jamais désactivée.

Ce qui est copié et à quelle fréquence

Le worker de l’installation miroir effectue la synchronisation. Il n’y a pas de service distinct. Pour chaque dépôt mis en miroir, il exécute ces étapes :

1. Remplissage initial. Le worker note la position actuelle du flux de changements de la source. Il lit ensuite la liste des artefacts, des paquets et des chemins de fichiers page par page et rend le miroir identique.
2. Suivi. Le worker lit le flux de la source. Lorsqu’il est à jour, il vérifie à nouveau toutes les 10 secondes. Il enregistre sa position après chaque changement appliqué.
3. Copie des fichiers. Un fichier est copié par parties. Le worker vérifie le SHA-256 de chaque partie et du fichier entier. Après une interruption, il reprend à la première partie manquante. Une partie attend dans mirror-staging à l’intérieur du répertoire de stockage du miroir.
4. Après une erreur. Le worker répète l’étape après une pause qui commence à 2 secondes et double jusqu’à 5 minutes. Un miroir en échec n’arrête pas les autres.

Une installation peut avoir jusqu’à 64 dépôts mis en miroir. Les copies comptent dans la limite de capacité et sur le disque du miroir, donc prévoyez le même espace que celui dont le dépôt source a besoin. Voir Stockage.

Si la clé de la source est révoquée ou si la source est inaccessible, le miroir continue de servir ce qu’il possède déjà et affiche l’erreur dans son état.

Vérifier l’état de synchronisation

Dans la console

Miroirs dans le menu liste chaque miroir et chaque import dont vous pouvez lire le dépôt, avec sa source, son état, sa dernière synchronisation et ce qui a été copié. Les administrateurs voient toujours la page ; tant qu’il n’y a aucun miroir, elle explique comment en configurer un. La page se rafraîchit d’elle-même toutes les 20 secondes.

État	Signification
Synchronisé	À jour avec la source
Rattrapage en cours	Copie les changements effectués par la source depuis la dernière vérification
Démarrage	Configuré, et le worker ne l’a pas encore atteint
Première copie	Le remplissage initial, ou un nouveau remplissage après la restauration de la source
Erreur de synchronisation	La dernière tentative a échoué. Les téléchargements continuent de fonctionner, et le worker réessaie de lui-même

Lorsque la synchronisation s’est arrêtée, la page indique pourquoi et quoi faire ensuite, et affiche la commande qui corrige le problème lorsqu’il y en a une, par exemple une nouvelle clé après que la source a refusé l’ancienne. Les textes suivent les codes d’erreur.

Connectée à un dépôt mis en miroir, la console affiche aussi un badge au-dessus du catalogue : Miroir, Miroir · synchronisation ou Miroir · erreur de synchronisation. La raison et l’étape suivante apparaissent en dessous tant que la synchronisation est arrêtée, et le badge suit le serveur sans rechargement. Ouvrez l’aide du badge (À propos de ce miroir) pour voir la source et l’heure de la dernière synchronisation. La console masque les boutons de téléversement et de modification dans un dépôt mis en miroir.

Avec l’API

getRepositoryMirror renvoie l’état d’un dépôt. Il nécessite le droit de lire le dépôt. Pour un dépôt ordinaire, la réponse est 404.

Champ	Signification
mode	mirror ou import
phase	pending (le worker n’a pas commencé), seeding (remplissage initial) ou following
caughtUp	true lorsque la position enregistrée égale la position la plus récente de la source. null avant la fin du remplissage initial
checkedAt, syncedAt	Quand le worker a lu le flux pour la dernière fois, et quand il a été à jour pour la dernière fois
copiedArtifacts, copiedBytes	Totaux copiés jusqu’ici (copiedBytes est une chaîne décimale)
conflicts	Entrées de la source mises de côté : count, oldestAt et jusqu’à 10 entrées dans sample. Voir Entrées mises de côté
errorCode, errorAt	Le dernier échec d’une étape, ou null

Codes d’erreur

errorCode	Signification et marche à suivre
mirror_mismatch	Le même ID d’artefact a un contenu différent sur la source. Le miroir conserve son fichier. Enquêtez sur l’artefact ; ne supprimez aucune des deux copies avant d’en connaître la cause
mirror_source_changed	Le dépôt contient déjà une copie d’une autre source. Détachez-le, ou mettez en miroir la nouvelle source dans un nouveau dépôt
mirror_source_behind	La source a été restaurée ou réinstallée : le changement à la position du miroir n’est pas celui qu’il y a appliqué. Le miroir relit la source, et le code disparaît lorsqu’il est à jour. Les fichiers absents de la source restaurée restent sur le miroir
mirror_delete_blocked	La source a supprimé un fichier que le miroir ne peut pas supprimer, car quelque chose ici l’utilise encore, comme une référence ou un historique de chemin de fichier
mirror_detached	Le dépôt a été détaché et a ses propres changements. Il n’est plus jamais synchronisé. Mettez la source en miroir dans un nouveau dépôt
mirror_package_conflict	Une version de la source a une version de paquet que ce dépôt détient avec d’autres octets. L’entrée est mise de côté et la synchronisation continue : voir Entrées mises de côté. Les versions précédentes du produit s’arrêtaient ici
mirror_id_taken	Un artefact de la source est détenu par un autre dépôt de cette installation. L’entrée est mise de côté, voir Entrées mises de côté ; dans une modification de tags d’images, d’objets Git LFS ou de paquets npm, elle arrête la synchronisation. Un dépôt source ne peut remplir qu’un seul dépôt ici
mirror_unreachable	La source est injoignable : la connexion est refusée ou expire, ou le nom ne se résout pas. Le worker réessaie de lui-même. Vérifiez le réseau, le pare-feu et que la source est en marche
mirror_certificate	Le certificat de la source n’est pas approuvé, a expiré ou ne correspond pas à son nom. Ajoutez son autorité avec --mirror-ca-file (voir HTTPS avec votre propre autorité de certification)
mirror_failed	Un échec sans code plus précis. Lisez le journal du worker
autres codes	Le code de la requête échouée : unauthorized lorsque la source n’accepte plus la clé (donnez-en une nouvelle au miroir), forbidden lorsque la clé n’a pas le droit de lire le dépôt, not_found lorsque le dépôt source n’existe plus, capacity_exceeded lorsque le miroir est plein

Le journal du worker (component vaut mirror) contient mirror.started, mirror.step_failed avec errorCode et attempts, mirror.recovered et mirror.stopped.

Entrées mises de côté

Certaines modifications de la source ne peuvent pas être appliquées ici sans casser ce qui existe déjà. Le worker met une telle entrée de côté et poursuit avec les autres modifications, si bien qu’une version ne bloque pas toutes les suivantes. Rien n’est ignoré en silence : chaque entrée mise de côté reste visible jusqu’à sa résolution.

Code	Signification	Que faire
mirror_package_conflict	La version a une version de paquet (groupe, nom et version) que ce dépôt détient avec d’autres octets. Les clients continuent de recevoir la version qui est ici ; le fichier copié reste sans enregistrement de paquet	Retirez l’étape ou la version sur la source, ou publiez-la sous une autre version. Dans un import, vous pouvez aussi supprimer la version ici
mirror_id_taken	Un autre dépôt de cette installation détient l’ID de l’artefact	Un dépôt source remplit un seul dépôt ici. Détachez l’autre miroir ou import, ou supprimez l’autre copie

• Le worker réessaie chaque entrée 10 minutes après sa dernière tentative, jusqu’à 8 entrées chaque fois qu’il est à jour. Une entrée est retirée quand elle s’applique, ou quand la source ne l’a plus : la version y a été supprimée ou, pour un import, son étape a été retirée.
• L’état indique conflicts : le nombre d’entrées mises de côté, la date de la plus ancienne et jusqu’à 10 d’entre elles avec l’ID de l’artefact, la modification (action et detail), le code, la première et la dernière tentative et le nombre de tentatives.
• La console affiche leur nombre sur Miroirs et sous le badge du dépôt. L’état ne change pas, car le reste continue de se synchroniser.
• Le journal du worker contient mirror.conflict_set_aside (warning, avec artifactId, action, errorCode et attempts) à chaque tentative échouée, et mirror.conflict_resolved quand une entrée est retirée.
• La métrique arkvory_mirror_conflicts les compte, et la règle ArkvoryMirrorConflicts avertit quand il y en a pendant 30 minutes.

Les modifications de tags et de manifestes d’images, d’objets Git LFS et de paquets npm ne sont jamais mises de côté : leur ordre compte, et en appliquer une plus tard pourrait annuler une modification plus récente. Un conflit dans ces modifications arrête la synchronisation avec son code jusqu’à sa résolution.

Superviser les miroirs

L’API de l’installation miroir expose quatre métriques pour chaque dépôt mis en miroir, avec les étiquettes repository et mode :

• arkvory_mirror_last_sync_timestamp_seconds : la dernière fois que le miroir a été à jour.
• arkvory_mirror_last_check_timestamp_seconds : la dernière fois qu’il a lu le flux.
• arkvory_mirror_failing : 1 tant que la dernière tentative a échoué ; pas pendant que le miroir relit une source restaurée (mirror_source_behind).
• arkvory_mirror_conflicts : le nombre d’entrées mises de côté.

Les règles Prometheus prêtes à l’emploi sont ArkvoryMirrorStale (pas à jour depuis plus d’une heure, pendant 15 minutes) et ArkvoryMirrorFailing (l’échec dure 15 minutes). Voir Supervision. Un miroir que le worker n’a pas encore atteint n’a pas d’heure de synchronisation, donc la règle stale ne se déclenche pas avant sa première synchronisation. ArkvoryMirrorConflicts avertit quand des entrées restent mises de côté pendant 30 minutes.

Import par étape

Avec --mirror-stages, le dépôt de la seconde installation n’est pas un miroir. C’est un dépôt ordinaire accessible en écriture qui reprend les versions portant l’une des étapes de la source. Utilisez-le pour déplacer des builds d’un serveur de développement vers un serveur de production.

sudo arkvory configure --root /opt/proanima-arkvory \
  --mirror releases --mirror-upstream https://dev.example \
  --mirror-token-file /root/dev.key --mirror-stages release

• Vous listez 1 à 16 noms d’étapes différents, séparés par des virgules.
• Une version est copiée une seule fois, avec le même ID, les mêmes octets, les mêmes étiquettes et le même enregistrement UPack, et avec les étapes correspondantes.
• Ensuite, elle appartient à cette installation. Les modifications, le retrait d’étape et la suppression sur la source ne l’atteignent pas. Une version que vous supprimez ici n’est jamais réimportée. Une étape que vous retirez ici reste retirée. Lorsque la source attribue plus tard à la version une autre étape configurée, seule cette étape est ajoutée.
• Les téléversements et la politique de stockage du dépôt fonctionnent normalement.
• Les données de registre d’images de conteneurs, Git LFS et npm ne sont pas transférées.
• Un changement d’étapes démarre un nouveau remplissage initial. Il n’apporte que les versions qui ne sont pas encore ici et laisse telles quelles celles qui y sont.
• Une version de la source dont ce dépôt détient déjà la version de paquet avec d’autres octets est mise de côté avec mirror_package_conflict, et l’import continue avec les versions suivantes. Les clients continuent de recevoir la version qui est ici. Voir Entrées mises de côté.

Deux installations peuvent importer l’une depuis l’autre. Par exemple, la production reprend release depuis la préproduction, et la préproduction reprend hotfix depuis la production. Une version garde son ID des deux côtés, donc rien n’est copié deux fois ni ne tourne en boucle :

• Une version créée en préproduction qui revient de la production reçoit seulement la nouvelle étape.
• Une version supprimée d’un côté n’est jamais réimportée depuis l’autre, même si l’autre côté lui attribue une étape plus tard.
• Une suppression n’est jamais transmise : l’autre côté garde sa copie jusqu’à ce que vous la supprimiez là aussi.

Utilisez des étapes différentes pour les deux sens. Avec la même étape dans les deux sens, une étape que vous retirez d’un côté revient lorsque l’autre côté attribue de nouveau cette étape à la version.

La console affiche le badge Importation, ou Importation · erreur de synchronisation lorsque la dernière tentative a échoué. La clé sur la source a besoin des mêmes autorisations en lecture seule que pour un miroir.

Basculer lorsque la source est perdue

Il s’agit d’un basculement manuel pour deux installations indépendantes sur deux sites. Il n’est pas automatique. Les changements que le miroir n’avait pas encore tirés sont perdus.

Préparer à l’avance

1. Installez le second site avec la même version que la source lorsque vous le pouvez, avec son propre PostgreSQL et son propre disque. Les deux sites ne partagent rien.
2. Créez une clé en lecture seule sur la source et attachez chaque dépôt comme miroir. Un dépôt créé plus tard sur la source n’apparaît pas tout seul sur le miroir, donc attachez-le de la même manière.
3. Sur le miroir, émettez les clés que vos consommateurs utiliseront, y compris des clés capables d’écrire après la bascule. Les autorisations de la source ne sont pas transférées, donc une source compromise ne donne pas accès au miroir.
4. Configurez les consommateurs (CI, agents de déploiement) avec l’adresse du miroir comme solution de repli pour les téléchargements. Cela soulage aussi le lien vers la source.
5. Sauvegardez la source dans un stockage des sauvegardes en dehors de son site. Voir Sauvegardes. Un miroir ne remplace pas cela.
6. Supervisez le miroir avec les règles ci-dessus.

Bascule

1. Assurez-vous que la source est vraiment indisponible pour les clients et qu’elle ne reviendra pas d’elle-même. Deux sites qui acceptent tous deux des écritures vers un même dépôt logique ne peuvent pas être fusionnés plus tard. Si la source est partiellement joignable, arrêtez ses services ou fermez son port.

2. Sur le miroir, lisez syncedAt de chaque dépôt. Les changements sur la source après cette heure ne sont pas sur le miroir.

3. Détachez chaque dépôt mis en miroir sur le miroir. Il devient un dépôt ordinaire accessible en écriture avec les mêmes ID d’artefact et toutes ses données.

   sudo arkvory configure --root /opt/proanima-arkvory --mirror-detach releases,prod

   Indiquez plusieurs dépôts séparés par des virgules, ou all pour tous les miroirs et imports. La commande redémarre l’API et le worker une seule fois, attendez-vous donc à une courte interruption.

4. Faites pointer les clients qui écrivent vers le miroir, via le DNS ou la configuration de votre CI.

5. Téléversez et téléchargez un fichier de contrôle sur le miroir.

Ce que voient les clients :

• Avant la bascule, les téléchargements depuis le miroir fonctionnent, et les écritures reçoivent 409 mirror_read_only.
• Après le détachement, les écritures fonctionnent. Le badge disparaît.
• Les clés et les mots de passe de la source ne fonctionnent pas sur le miroir, sauf si vous y avez créé les mêmes comptes.

Il n’y a pas de retour en arrière. Un dépôt détaché ne peut pas être rattaché comme miroir : sa synchronisation s’arrête avec mirror_detached. Pour faire revenir l’ancienne source, videz-la ou réinstallez-la et attachez les dépôts du nouveau primaire comme miroirs. N’exécutez jamais l’ancienne source et le nouveau primaire côte à côte avec les écritures activées.

Répéter l’exercice

Répétez la bascule chaque trimestre et après les mises à jour. Détachez un dépôt sur une copie de secours, vérifiez syncedAt, un téléchargement et un téléversement, et notez la date et le résultat. Testez séparément la restauration d’une sauvegarde de la source dans une installation vide. Voir Tester régulièrement une restauration.

Limites

• Un miroir est en lecture seule jusqu’à ce que vous le détachiez. Un dépôt détaché ne peut pas redevenir un miroir.
• Le miroir n’est pas une sauvegarde. Il n’a pas de copie des comptes, des clés ou des autorisations, et il ne copie pas les références, les pièces jointes, les pistes d’audit ni les politiques de stockage.
• Le mode import ne copie pas les images de conteneurs, Git LFS ni les données npm.
• Un nouveau remplissage initial ne fait qu’ajouter et mettre à jour : après une restauration de la source, les fichiers que la source a perdus restent sur le miroir.
• Un dépôt source remplit un seul dépôt d’une installation : les ID d’artefact sont les mêmes des deux côtés, donc un second miroir ou import de ce dépôt est refusé lors de sa configuration. Pour la même raison, deux installations qui importent l’une de l’autre doivent utiliser le même nom de dépôt des deux côtés : une version venue de l’autre côté ne peut pas être reprise ici dans un autre dépôt, et elle est mise de côté avec mirror_id_taken.
• Une version dont la version de paquet est déjà détenue ici avec d’autres octets est copiée, puis mise de côté avec mirror_package_conflict. La copie reste dans le dépôt sans enregistrement de paquet jusqu’à ce que vous la supprimiez.
• Une entrée mise de côté n’est pas ici tant qu’elle n’est pas résolue. Un conflit dans une modification de tags d’images, d’objets Git LFS ou de paquets npm arrête toujours la synchronisation.
• Après une restauration de l’installation miroir depuis une sauvegarde, les versions importées puis supprimées après la prise de la sauvegarde peuvent être importées de nouveau.
• Les deux installations sont mises à jour séparément. La source doit offrir le flux de changements des miroirs.
• L’ensemble des autorités de confiance de la source s’applique à tout le worker.
• Il n’y a pas de basculement automatique, pas de fencing de l’ancienne source ni de synchronisation inverse.

Pages associées

• Sauvegardes
• Passerelles de lecture
• Stockage
• Supervision
• Variables d’environnement
• Comptes et accès