Pular para o conteúdo principal

Executando um script personalizado durante a criação da VM - VmStartupScript (versão prévia)

Introdução

Este recurso está em versão prévia. Você pode começar a usá-lo hoje e nos enviar seus comentários. As instruções sobre como entrar em contato conosco são fornecidas no final do artigo. Observe que o suporte técnico é limitado durante a versão prévia.
O VmStartupScript permite executar um script personalizado nas máquinas virtuais (VMs) usadas no PlayFab Multiplayer Servers (MPS). O MPS é otimizado para a hospedagem de servidores de jogo, facilitando a escala dinâmica do seu título de acordo com a demanda. Para facilitar a personalização rápida de um grande número de servidores durante a inicialização das VMs, o script personalizado pode ser executado em todas as VMs subjacentes que hospedam seus servidores de jogo. Ele pode ser usado para realizar tarefas como instalar software personalizado, modificar configurações de segurança, usar um serviço personalizado para registrar a saída e as métricas dos servidores de jogo e muito mais.
Este é um recurso avançado que deve ser usado com extrema cautela. O script em execução é executado no nível da máquina virtual (VM) com privilégios de administrador (root). Se não for usado corretamente, ele poderá interromper o fluxo normal dos servidores de jogo em execução ou até mesmo impedir que eles sejam executados. O usuário final é responsável pelo conteúdo do script.

Como usar o VmStartupScript

Para usar o recurso VmStartupScript, você precisa fornecer um script personalizado e todo o software relevante (opcional) que planeja instalar. O script começa a ser executado quando a máquina virtual é inicializada. Essa operação ocorre antes que os servidores de jogo sejam iniciados em cada VM. Depois que o script terminar de ser executado com êxito, o serviço MPS prossegue para concluir a inicialização dos servidores de jogo e os coloca no estado StandingBy. Para saber mais sobre os diferentes estados do servidor de jogo, consulte Ciclo de vida de um servidor multijogador. Para usar este recurso em um ambiente de produção real, consulte o Fluxo de trabalho recomendado para desenvolvedores antes de começar.

Criar um script

  • Crie um arquivo chamado PF_StartupScript.sh para VMs Linux ou PF_StartupScript.ps1 para VMs Windows.
  • Adicione comandos de configuração/execução ao arquivo. Se precisar, veja algumas variáveis de ambiente usadas com frequência que você pode usar no script. Algumas ações não têm suporte ou fariam com que as VMs não iniciassem com êxito, gerando cobranças indesejadas. Para obter detalhes, consulte a seção O que não tem suporte.
Para ver exemplos de scripts, consulte VmStartupScriptGallery.

Criar e carregar o arquivo zip

  1. Reúna em uma pasta todo o software relevante que seu script planeja usar ou chamar. Se o seu script instalar software de terceiros, ele poderá baixá-lo durante a execução, ou o software pode ser incluído no arquivo zip. Ignore esta etapa se não for instalar nada.
  2. Crie um arquivo zip (.zip) com o script (.sh ou .ps1) que você criou na seção anterior e com o software reunido na etapa anterior, se necessário. O arquivo de script deve estar na raiz do arquivo zip, e não dentro de um diretório. Além disso, se o arquivo de script não se chamar PF_StartupScript.sh (Linux) ou PF_StartupScript.ps1 (Windows), ele não será executado, e os servidores de jogo não iniciarão.
  3. Carregue o arquivo zip usando um dos seguintes métodos:
Recomendamos incluir no arquivo zip todos os binários e ativos necessários para o seu script, pois isso resultará em uma execução mais rápida e em menos tempo para o MPS disponibilizar seus servidores de jogo. Inclua os ativos da plataforma relevante em que seus servidores de jogo serão executados. Por exemplo, se você usar servidores Linux, deverá incluir pacotes Debian/Ubuntu “amd64”.

Aplicar o script personalizado a novos builds

Depois de carregar o arquivo .zip, use a API do MPS para criar um novo build depois de configurar a propriedade VmStartupScriptAssetReference. Para obter instruções, consulte Como criar builds usando a API do MPS.
  • Adicione a propriedade VmStartupScriptConfiguration.VmStartupScriptAssetReference, que inclui uma referência ao arquivo de ativos carregado. Essa propriedade faz parte de todas as APIs relacionadas a “CreateBuild”, como CreateBuildWithCustomContainer, CreateBuildWithManagedContainer e CreateBuildWithProcessBasedServer.
  • Adicione um valor válido para a propriedade VmStartupScriptAssetReference.FileName. Esse valor deve ser igual ao nome do seu arquivo de ativos, por exemplo, vmstartupscriptassets.zip.
  • A propriedade VmStartupScriptAssetReference.MountPath deve estar vazia, pois não tem suporte no recurso VmStartupScript.
Se você definir um valor para a propriedade MountPath, a operação de criação do build falhará.
O exemplo de código abaixo cria um build com contêineres Linux e, em seguida, usa o script em vmstartupscriptassets.zip para personalizar as VMs:
O VmStartupScript é executado durante o estágio de “Propping” (preparação) da VM e deve terminar com êxito para que os servidores de jogo sejam iniciados. Se falhar (código de saída diferente de 0), a VM não passará para o estado “Running”, e você precisará se conectar à VM por RDP/SSH para depurar. Para saber mais, consulte o Fluxo de trabalho recomendado para desenvolvedores. A VM continuará tentando executar o VmStartupScript.

Considerações especiais

No Linux, preciso marcar o arquivo PF_StartupScript.sh como executável?

Antes de executar o arquivo de script, o MPS o marca como executável e converte todas as terminações de linha do Windows (“\r\n”) para as do Linux (“\n”). Portanto, você não precisa se preocupar com essas duas coisas.

Variáveis de ambiente

Veja a seguir as variáveis de ambiente que você pode usar no seu script de inicialização.

O que não tem suporte

Você não deve executar estas ações a partir do seu script, pois há uma grande chance de interromper o ciclo de vida da VM e dos servidores de jogo:
  • Não bloqueie durante a execução do script de inicialização. O script deve terminar com êxito para que os servidores de jogo sejam criados. Se precisar que algo seja executado em segundo plano, você pode instalá-lo como um serviço systemd no Linux ou como um serviço do Windows.
  • Não use portas a partir de 30000, pois elas são usadas pelos servidores de jogo, nem a porta 56001, pois ela é usada pelo processo VmAgent (o executável orquestrador de servidores de jogo do MPS).
  • Não modifique nenhum dos arquivos nos caminhos D: (Windows) ou /mnt (Linux), pois esses arquivos são necessários para a operação do VmAgent (exceto as pastas com conteúdo editável, como PF_SHARED_CONTENT_FOLDER_VM).
  • Você não deve usar o GSDK de dentro do VmStartupScript ou de um aplicativo iniciado por ele. O GSDK só deve ser usado a partir dos GameServers.
  • Você não deve reiniciar manualmente a máquina virtual, pois essa operação criará problemas na comunicação com o plano de controle do MPS.

Portas

Ao usar o recurso VmStartupScript, é possível solicitar que várias portas sejam expostas em cada VM. Essas portas podem ser usadas por quaisquer programas iniciados pelo seu script e são diferentes das portas que o MPS abre para seus servidores de jogo.

Uso

Você pode solicitar até cinco portas para cada VM. Para cada porta, você deve especificar o protocolo (TCP ou UDP) e um nome. Veja um exemplo de como solicitar duas portas:
Se você solicitar portas, as seguintes variáveis de ambiente estarão disponíveis para o seu script, para ajudar a obter informações sobre as portas: Por exemplo, para as duas portas solicitadas no script de exemplo acima, você deve esperar encontrar estas variáveis de ambiente no seu VmStartupScript:
Assim como nas portas que abrimos para os servidores de jogo, cabe a você autenticar os clientes que se conectam às suas portas. O MPS não fornece nenhum mecanismo de autenticação para essas portas.
Os clientes perceberão que as portas alocadas começam a partir do número 20000. No entanto, recomendamos que você não codifique esse valor nos seus scripts, pois ele pode mudar no futuro; use sempre as variáveis de ambiente para obter as informações corretas das portas.

Desenvolvimento/depuração

Antes de usar o recurso VmStartupScript, recomendamos que você confira estes scripts de exemplo no nosso repositório de código aberto no GitHub (VmStartupScriptGallery). Contribuições são bem-vindas!

Fluxo de trabalho de desenvolvimento recomendado

Inicialmente, você deve criar um build de teste com uma única VM. Essa VM deve ter especificações semelhantes às da VM em que você planeja implantar seu build de produção. Quando essa VM única estiver implantada, você poderá se conectar por RDP/SSH, copiar os arquivos necessários e tentar editar/executar o script até que ele funcione. Depois que essa VM estiver em execução e você verificar que seu script se comporta conforme o esperado, você poderá colocar o script e os ativos em um arquivo .zip. Em seguida, você poderá carregá-lo e tentar criar um build com ele. Tente criar novamente um build com uma única VM para economizar custos e aumente a escala quando tiver certeza de que seu script funciona. Se você encontrar problemas para executar seu script, poderá depurar fazendo logon na VM por RDP/SSH e verificando os arquivos PF_StartupScriptStdOut.txt e PF_StartupScriptStdErr.txt, que contêm, respectivamente, os fluxos de saída padrão e de erro padrão do script. Esses arquivos ficam na unidade D: no Windows ou em /mnt no Linux. O script deve ser idempotente, pois há uma chance de ele ser executado mais de uma vez. Por exemplo, se o script tentar baixar um recurso externo e falhar devido a um problema de rede, o MPS repetirá toda a execução do script.

Suporte

O serviço MPS executará o que estiver no seu VmStartupScript. No entanto, a equipe não fornecerá suporte para as ações individuais e os executáveis instalados/executados como parte do script. Durante a versão prévia, obtenha suporte e envie comentários usando os Fóruns da comunidade do PlayFab e o Discord. Se você tiver problemas com algum script do repositório VmStartupScriptGallery ou quiser solicitar um novo, abra um problema no GitHub.
Última modificação em 20 de outubro de 2026