J'ai du mal à vous référer à la documentation, ce qui signifie que je n'ai pas encore pris mon café (vrai) ou qu'il nous manque une documentation ( mise à jour : une documentation ici )
Lorsque vous déclarez des applications dans votre snapcraft.yaml
, il en résulte un wrapper binaire généré lors de l'installation et placé dans/snap/bin/
, nommé d'après votre nom de package et d'application (notez que si l'application est un service, ce wrapper est plutôt un fichier systemd .service).
Ce wrapper contient la plupart de l'environnement dans lequel l'application s'exécutera. Les deux variables d'environnement les plus pertinentes pour cette question sont SNAP_DATA
et SNAP_USER_DATA
.
SNAP_DATA
est une zone accessible en écriture à l'échelle du système (en /var/snap/
). Cela peut être utilisé pour héberger des journaux de services, par exemple.
SNAP_USER_DATA
est une zone inscriptible spécifique à l'utilisateur dans le répertoire personnel de l'utilisateur exécutant l'application (en particulier /home/<user>/snap/
). Cela peut être utilisé pour les fichiers de configuration spécifiques à l'utilisateur, etc.
Ces deux répertoires sont très importants pour la fonctionnalité de mise à niveau / restauration, car ils sont tous deux versionnés . Autrement dit, chaque version d'un composant logiciel enfichable donné a sa propre copie de ces répertoires. Permettez-moi de vous expliquer avec un exemple.
Supposons que vous installez la version 1 du composant logiciel enfichable "foo". Cela créera deux répertoires:
/var/snap/foo/1
( SNAP_DATA
)
/home/<user>/snap/foo/1
( SNAP_USER_DATA
)
Maintenant, dites "foo" utilise les deux. Peut-être qu'il a un service qui héberge une base de données dans SNAP_DATA
, et un binaire qui utilise des fichiers de configuration dans SNAP_USER_DATA
.
Maintenant, la version 2 de "foo" est sortie et elle est automatiquement mise à jour. La première chose qui se produit est /var/snap/foo/1
copiée /var/snap/foo/2
et /home/<user>/snap/foo/1
copiée dans /home/<user>/snap/foo/2
. Ensuite, la nouvelle version démarre. Il devrait remarquer qu'il fonctionne sur d'anciennes données, et peut-être qu'il a des migrations de base de données pour s'exécuter vers la base de données SNAP_DATA
. Il fait cela, et c'est parti.
Supposons maintenant que ces migrations échouent pour une raison quelconque et que cette application doit être annulée. Il commence à utiliser l'ancienne version de l'application / snap / foo, où SNAP_DATA
pointait /var/snap/foo/1
et SNAP_USER_DATA
pointait /home/<user>/snap/foo/1
. Cela reprend les choses sur l'ancienne version au point avant l'exécution des migrations, car ces opérations ont été exécutées sur une copie des données.
Pour faire court: n'utilisez pas l' home
interface pour stocker des données dans lesquelles vous pouvez stocker SNAP_DATA
ou SNAP_USER_DATA
, car elles font partie intégrante de la stratégie de mise à niveau / restauration. Profitez-en!
MISE À JOUR pour v2.0.10:
Deux nouveaux répertoires de données ont également été introduits:
SNAP_COMMON
se trouve à côté SNAP_DATA
, mais est spécifiquement sans version . Chaque révision du composant logiciel enfichable spécifique a accès à ce répertoire, il n'est donc pas copié lors de la mise à niveau / restauration, etc. Cela peut être utilisé pour des fichiers particulièrement volumineux et non versionnés (par exemple, des données brutes qui ne sont pas vraiment spécifiques à la version).
SNAP_USER_COMMON
se trouve à côté SNAP_USER_DATA
, mais est à nouveau spécifiquement sans version . Il peut être utilisé pour stocker des données non spécifiques à la version par utilisateur.
MISE À JOUR pour v2.15:
Les fichiers placés à l'intérieur /snap/bin
ne sont plus des wrappers qui définissent l'environnement, mais des liens symboliques vers /usr/bin/snap
. Ainsi, la façon de déterminer l'environnement dans lequel une application s'exécute serait d'utiliser snap run --shell <snap>.<app>
, par exemple:
$ sudo snap install hello-world
$ snap run --shell hello-world
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.
$ env | grep SNAP
SNAP_USER_COMMON=/home/kyrofa/snap/hello-world/common
SNAP_REEXEC=
SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:
SNAP_COMMON=/var/snap/hello-world/common
SNAP_USER_DATA=/home/kyrofa/snap/hello-world/27
SNAP_DATA=/var/snap/hello-world/27
SNAP_REVISION=27
SNAP_NAME=hello-world
SNAP_ARCH=amd64
SNAP_VERSION=6.3
SNAP=/snap/hello-world/27
SNAP_USER_COMMON
répertoire n'est-il pas créé automatiquement par snapd? Le script de lancement dans/snap/bin/
ne le crée pas et sa création manuelle dans le composant logiciel enfichable échoue (autorisation refusée). L'exécutionsnap run app
crée ce dossier, cependant (mais la commande échoue avecexecv failed: No such file or directory
... je ne sais pas comment utiliser cette commande).