As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Use scripts de sessão para gerenciar a experiência de streaming de seus usuários AppStream 2.0

AppStream 2.0 fornece scripts de sessão na instância. Você pode usar esses scripts para executar seus próprios scripts personalizados quando eventos específicos ocorrerem em sessões de streaming dos usuários. Por exemplo, você pode usar scripts personalizados para preparar seu ambiente AppStream 2.0 antes do início das sessões de streaming dos usuários. Você também pode usar scripts personalizados para limpar instâncias de streaming depois que os usuários concluem as sessões de streaming.

Os scripts de sessão são especificados em uma imagem AppStream 2.0. Esses scripts são executados no contexto do usuário ou do sistema. Se os scripts de sessão usarem a saída padrão para gravar informações, erro ou mensagens de depuração, opcionalmente, eles poderão ser salvos em um bucket do Amazon S3 na sua conta da Amazon Web Services.

Executar scripts antes de iniciar sessões de streaming

Você pode configurar seus scripts para serem executados, no máximo, 60 segundos antes de iniciar aplicativos de seus usuários e as sessões de streaming começarem. Isso permite que você personalize o ambiente AppStream 2.0 antes que os usuários comecem a transmitir seus aplicativos. Quando os scripts de sessão forem executados, um símbolo giratório de carregamento será exibido para os usuários. Quando os scripts forem concluídos ou o tempo de espera máximo expirar, a sessão de streaming dos usuários começará. Se seus scripts não forem concluídos, uma mensagem de erro será exibida para os usuários. No entanto, os usuários não podem usar a sessão de streaming.

Ao especificar um nome de arquivo em uma instância do Windows, você deve usar duas barras invertidas. Por exemplo: .

C:\\Scripts\\Myscript.bat

Se você não usar uma barra invertida dupla, um erro será exibido para notificá-lo de que o arquivo.json está formatado incorretamente.

Quando você executa scripts antes do início das sessões de streaming e a estrutura dinâmica do aplicativo AppStream 2.0 não está habilitada, ocorre o seguinte processo:

Para obter informações sobre a estrutura dinâmica de aplicativos AppStream 2.0, consulteUsar o framework dinâmico de aplicações do AppStream 2.0 para criar um provedor dinâmico de aplicações.

Quando você executa scripts antes do início das sessões de streaming e a estrutura dinâmica do aplicativo AppStream 2.0 é ativada, ocorre o seguinte processo:

Executar scripts após sessões de streaming

Você também pode configurar seus scripts para execução após sessões de streaming dos usuários. Por exemplo, você pode executar um script quando os usuários selecionam Encerrar sessão na barra de ferramentas AppStream 2.0 ou quando atingirem a duração máxima permitida para a sessão. Você também pode usar esses scripts de sessão para limpar seu ambiente AppStream 2.0 antes que uma instância de streaming seja encerrada. Por exemplo, você pode usar scripts para liberar bloqueios de arquivo ou fazer upload de arquivos de log. Quando você executar scripts após sessões de streaming, o seguinte processo ocorrerá:

Criar e especificar scripts de sessão

Você pode configurar e especificar scripts de sessão para frotas sempre ativas, sob demanda e elásticas.

Arquivo de configuração de scripts de sessão

Para localizar o arquivo de configuração dos scripts de sessão em uma instância do Windows, navegue até C:\\ AppStreamSessionScripts\ config.json. Em uma instância Linux, navegue até /opt/appstream/ SessionScripts /config.json. O arquivo é formatado da maneira a seguir.

{
  "SessionStart": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  },
  "SessionTermination": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  }
}

Você pode usar os seguintes parâmetros no arquivo de configuração de scripts de sessão.

Usando PowerShell arquivos do Windows

Para usar PowerShell arquivos do Windows, especifique o caminho completo para o PowerShell arquivo no filename parâmetro:

"filename": 
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",

Em seguida, especifique seu script de sessão no parâmetro arguments:

"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",

Por fim, verifique se a Política de PowerShell Execução permite que seu PowerShell arquivo seja executado.

Registro da saída do script de sessão

Quando essa opção está habilitada no arquivo de configuração, o AppStream 2.0 captura automaticamente a saída do script de sessão que é gravado na saída padrão. Essa saída é carregada em um bucket do Amazon S3 em sua conta. Você pode analisar os arquivos de log para solução de problemas ou para fins de depuração.

Usar conectores de armazenamento com scripts de sessão

Quando os conectores de armazenamento AppStream 2.0 estão habilitados, eles começam a ser montados quando os scripts de início da sessão são executados. Se seu script depende da montagem dos conectores de armazenamento, você pode esperar que os conectores estejam disponíveis. AppStream 2.0 mantém o status de montagem dos conectores de armazenamento no registro do Windows em instâncias do Windows, na seguinte chave:

<provided user name>HKEY_LOCAL_MACHINE\ SOFTWARE\ Amazon\\ Storage\\ AppStream <Storage connector>

Os valores de chave de registro são os seguintes:

Cada chave de registro do conector de armazenamento contém um valor MountStatusDWORD. A tabela a seguir lista os valores possíveis para MountStatus.

Em instâncias Linux, você pode verificar o status de montagem da pasta inicial observando o valor de appstream_home_folder_mount_status no arquivo ~/.config//-status. appstream-home-folder appstream-home-folder-mount

Habilitar o armazenamento de buckets do Amazon S3 para logs de script de sessão

Quando você ativa o registro do Amazon S3 na configuração do script da sessão, o AppStream 2.0 captura a saída padrão do script da sessão. A saída é carregada periodicamente em um bucket do S3 na sua conta da Amazon Web Services. Para cada AWS região, AppStream 2.0 cria um bucket em sua conta que é exclusivo para sua conta e para a região.

Você não precisa executar tarefas para gerenciar esses buckets do S3. Eles são totalmente gerenciados pelo serviço AppStream 2.0. Os arquivos de log armazenados em cada bucket são criptografados em trânsito usando endpoints SSL do Amazon S3 e em repouso usando chaves de criptografia gerenciadas pelo Amazon S3. Os buckets são nomeados em um formato específico da seguinte forma:

appstream-logs-region-code-account-id-without-hyphens-random-identifier

Por exemplo, se você especificar scripts de sessão em uma imagem na região Oeste dos EUA (Oregon) (us-west-2) na conta número 123456789012, AppStream 2.0 cria um bucket Amazon S3 dentro da sua conta nessa região com o nome exibido. Somente um administrador com permissões suficientes pode excluir esse bucket.

appstream-logs-us-west-2-1234567890123-abcdefg

Desabilitar os scripts de seção não exclui nenhum arquivo de log armazenado no bucket do S3. Para excluir permanentemente os arquivos de log, você ou outro administrador com permissões adequadas deve fazer isso usando o console ou a API do Amazon S3. AppStream 2.0 adiciona uma política de bucket que evita a exclusão acidental do bucket. Para obter mais informações, consulte a seção Políticas do IAM e do bucket da Amazon S3 para persistência de configurações do aplicativo em Identity and Access Management para Amazon AppStream 2.0.

Quando os scripts de sessão são habilitados, uma pasta exclusiva é criada para cada sessão de streaming que é iniciada.

O caminho para a pasta em que os arquivos de log são armazenados no bucket do S3 em sua conta usa a seguinte estrutura:

bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event

A estrutura da pasta de exemplo a seguir aplica-se a uma sessão de streaming iniciada na pilha de teste e na frota de teste. A sessão usa a API do ID do usuáriotestuser@mydomain.com, de um Conta da AWS ID de123456789012, e o grupo de configurações test-stack na região Oeste dos EUA (Oregon) (us-west-2):

appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/

Essa estrutura de pasta de exemplo contém um arquivo de log para um script de início de sessão do contexto do usuário e um arquivo de log para um script de início de sessão do contexto do sistema, se aplicável.

Use scripts de sessão em frotas com várias sessões

Ao usar scripts de sessão em frotas com várias sessões, há requisitos e considerações adicionais para garantir desempenho e segurança ideais.

Requisitos

Em uma frota de sessão única, em uma determinada instância, é garantido que os SessionTerminationganchos SessionStarte funcionem apenas uma vez. Isso ocorre porque há um mapeamento 1:1 das sessões para as instâncias. Ao usar frotas de várias sessões, há um mapeamento N:M de sessões para instâncias, em que cada sessão é executada por conta própria e gancho. SessionStartSessionTermination Isso significa que os SessionTerminationganchos SessionStarte podem ser executados várias vezes em uma determinada instância e em muitas ordens diferentes. Para obter a melhor experiência, o seguinte deve ser válido para seus scripts de sessão quando usados em frotas de várias sessões:

Muitos desses requisitos podem ser atendidos mantendo a lógica do script de sessão focada na sessão específica do usuário para a qual o script está sendo executado.

Considerações sobre segurança

AppStream As imagens 2.0 não devem ser configuradas para permitir a permissão de gravação em arquivos de script de sessão por nenhum usuário. Isso introduz um vetor de ataque crítico para usuários mal-intencionados, onde eles podem modificar arquivos de script. Esses arquivos podem então ser executados como SYSTEM ou outro usuário, dependendo da sua configuração.

O seguinte deve ser válido para seus arquivos de imagens e scripts de sessão:

Os executáveis dos scripts de sessão devem ser armazenados em um local seguro, onde estejam protegidos contra modificações em tempo de execução.

Se o serviço detectar que um script de sessão executável foi modificado, ele falhará em qualquer execução subsequente desse hook nessa instância, fará o upload dos arquivos de log para o Amazon S3 (se o registro no Amazon S3 estiver ativado) e você verá a seguinte mensagem:

O script da sessão não foi executado porque o executável foi modificado após o provisionamento da instância. A execução foi ignorada por motivos de segurança.

Se seu caso de uso exigir a modificação do executável do script de sessão em tempo de execução (por exemplo, se você apontar para um arquivo EXE modificado por um processo de atualização automática em tempo de execução), isso falhará nas verificações acima. Nesse caso, use um script para redirecionar a execução para o executável modificado. Deixe o script inalterado em tempo de execução quando o serviço realizar verificações de segurança.

Se seus arquivos de script de sessão forem excessivamente grandes (mais de 100 MB), isso pode causar atrasos no provisionamento da instância e da sessão, e as verificações de segurança levarão mais tempo (dependendo do tipo de instância e dos recursos disponíveis). Se seu caso de uso exigir scripts de sessão grandes, considere usar scripts menores para redirecionar a execução. Isso melhorará as experiências de provisionamento de instâncias e sessões.

Observe que o serviço está verificando apenas o executável definido nos scripts de sessão config.json, e esse é apenas um mecanismo alternativo/melhor esforço. É sua responsabilidade garantir que todos os caminhos de código nos executáveis dos scripts de sessão sejam seguros e não possam ser modificados pelos usuários finais.