Estou tendo problemas em encaminhar sua documentação, o que significa que eu ainda não tomei meu café (verdade) ou estamos perdendo alguma documentação.
Quando você declara apps no seu snapcraft.yaml , isso resulta em um wrapper binário sendo gerado na instalação e colocado em /snap/bin/ , nomeado após o nome do pacote e aplicativo (observe que se o aplicativo for um serviço, esse wrapper será em vez disso, um arquivo systemd .service).
Esse wrapper contém a maior parte do ambiente sob o qual o aplicativo será executado. As duas variáveis de ambiente mais relevantes para essa questão são SNAP_DATA e SNAP_USER_DATA .
-
SNAP_DATAé uma área gravável em todo o sistema (em/var/snap/). Isso pode ser usado para hospedar logs de serviços, por exemplo. -
SNAP_USER_DATAé uma área gravável específica do usuário no diretório inicial do usuário que está executando o aplicativo (especificamente/home/<user>/snap/). Isso pode ser usado para arquivos de configuração específicos do usuário, etc.
Ambos os diretórios são muito importantes para a funcionalidade de atualização / reversão, já que ambos são versionados . Ou seja, cada versão de um dado snap tem sua própria cópia desses diretórios. Deixe-me explicar com um exemplo.
Digamos que você instale a versão 1 do snap "foo". Isso criará dois diretórios:
-
/var/snap/foo/1(SNAP_DATA) -
/home/<user>/snap/foo/1(SNAP_USER_DATA)
Agora diga "foo" usa os dois. Talvez tenha um serviço que hospede um banco de dados em SNAP_DATA e um binário que use arquivos de configuração em SNAP_USER_DATA .
Agora, a versão 2 de "foo" é lançada e atualizada automaticamente. A primeira coisa que acontece é que /var/snap/foo/1 é copiado em /var/snap/foo/2 e /home/<user>/snap/foo/1 é copiado em /home/<user>/snap/foo/2 . Então a nova versão é ativada. Ele deve notar que está sendo executado em dados antigos e talvez tenha algumas migrações de banco de dados para serem executadas no banco de dados em SNAP_DATA . Ele faz isso e vai embora.
Agora, diga que essas migrações falham por qualquer motivo e esse aplicativo precisa ser revertido. Ele começa a usar a versão antiga do aplicativo / snap / foo, em que SNAP_DATA estava apontando para /var/snap/foo/1 e SNAP_USER_DATA estava apontando para /home/<user>/snap/foo/1 . Isso pega as coisas na versão antiga no ponto antes de as migrações serem executadas, uma vez que essas operações foram executadas em uma cópia dos dados.
Resumindo: não use a interface home para armazenar dados que você pode armazenar em SNAP_DATA ou SNAP_USER_DATA , pois eles são parte integrante da estratégia de atualização / reversão. Aproveite-os!
UPDATE para v2.0.10:
Dois novos diretórios de dados também foram introduzidos:
-
SNAP_COMMONfica ao lado deSNAP_DATA, mas é especificamente não versionado . Cada revisão do snap específico tem acesso a este diretório, portanto, ele não é copiado na atualização / reversão, etc. Isso pode ser usado para arquivos particularmente grandes e sem versão (por exemplo, dados brutos que não são realmente específicos à versão). -
SNAP_USER_COMMONfica ao lado deSNAP_USER_DATA, mas é novamente especificamente não versionado . Pode ser usado para armazenar dados não específicos da versão por usuário.
UPDATE para v2.15:
Os arquivos colocados dentro de /snap/bin não são mais wrappers que definem o ambiente, mas sim links para /usr/bin/snap . Portanto, a maneira de determinar o ambiente sob o qual um aplicativo é executado seria usar snap run --shell <snap>.<app> , por exemplo:
$ 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