Sisk

Implantando sua aplicação Sisk

Esta página foi traduzida automaticamente do inglês. Ler o original

O processo de implantação de uma aplicação Sisk consiste em publicar seu projeto em produção. Embora o processo seja relativamente simples, vale a pena observar detalhes que podem ser letais para a segurança e estabilidade da infraestrutura da implantação.

Idealmente, você deve estar pronto para implantar sua aplicação na nuvem, após realizar todos os testes possíveis para que sua aplicação esteja pronta.

Publicando sua aplicação #

Publicar sua aplicação ou serviço Sisk é gerar binários prontos e otimizados para produção. Neste exemplo, compilaremos os binários para produção para serem executados em uma máquina que tenha o .NET Runtime instalado.

Você precisará do .NET SDK instalado em sua máquina para compilar sua aplicação, e do .NET Runtime instalado no servidor de destino para executá‑la. Você pode aprender como instalar o .NET Runtime em seu servidor Linux aqui, Windows e Mac OS.

Na pasta onde seu projeto está localizado, abra um terminal e use o comando de publicação do .NET:

Shell
$ dotnet publish -r linux-x64 -c Release

Isso gerará seus binários dentro de bin/Release/publish/linux-x64.

Nota

Se sua aplicação usa um arquivo de configuração portátil, você deve copiar seu service-config.json para o servidor host junto com todos os binários gerados pelo dotnet publish. Você pode deixar o arquivo pré‑configurado, com variáveis de ambiente, portas de escuta e hosts, e configurações adicionais do servidor.

O próximo passo é levar esses arquivos para o servidor onde sua aplicação será hospedada.

Depois disso, conceda permissões de execução ao seu arquivo binário. Neste caso, vamos considerar que o nome do nosso projeto é “my-app”:

Shell
$ cd /home/htdocs
$ chmod +x my-app
$ ./my-app

Após executar sua aplicação, verifique se ela produz alguma mensagem de erro. Se não houver mensagens, é porque sua aplicação está em execução.

Neste ponto, provavelmente não será possível acessar sua aplicação pela rede externa fora do seu servidor, pois regras de acesso como o firewall ainda não foram configuradas. Consideraremos isso nos próximos passos.

Você deve ter o endereço do host virtual onde sua aplicação está escutando. Isso é definido manualmente na aplicação e depende de como você está instanciando seu serviço Sisk.

Se você não estiver usando um arquivo de configuração portátil, deve encontrá‑lo onde definiu sua instância de HttpServer:

C#
HttpServer server = HttpServer.Emit(5000, out HttpServerConfiguration config, out var host, out var router);
// sisk deve escutar em http://localhost:5000/

Associando um ListeningHost manualmente:

C#
config.ListeningHosts.Add(new ListeningHost("https://localhost:5000/", router));

Ou se você estiver usando um arquivo de configuração portátil, no seu service-config.json:

JSON
{
  "Server": { },
  "ListeningHost": {
    "Ports": [
      "http://localhost:5000/"
    ]
  }
}

A partir disso, podemos criar um proxy reverso para escutar seu serviço e disponibilizar o tráfego na rede aberta.

Proxy reverso da sua aplicação #

Usar um proxy para seu serviço significa não expor diretamente seu serviço Sisk a uma rede externa. Essa prática é muito comum em implantações de servidores porque:

  • Permite associar um certificado SSL na sua aplicação;
  • Criar regras de acesso antes de acessar o serviço e evitar sobrecargas;
  • Controlar largura de banda e limites de requisições;
  • Separar balanceadores de carga para sua aplicação;
  • Prevenir danos de segurança à infraestrutura falha.

Você pode servir sua aplicação através de um proxy reverso como o Nginx ou o Apache, ou pode usar um túnel http‑over‑dns como o Cloudflared.

Além disso, lembre‑se de resolver corretamente os cabeçalhos de encaminhamento do seu proxy para obter as informações do cliente, como endereço IP e host, através de resolvers de encaminhamento.

O próximo passo após criar seu túnel, configurar o firewall e ter sua aplicação em execução, é criar um serviço para sua aplicação.

Nota

Usar certificados SSL diretamente no serviço Sisk em sistemas não‑Windows não é possível. Isso se deve à implementação do HttpListener, que é o módulo central de como o gerenciamento de filas HTTP é feito no Sisk, e essa implementação varia de um sistema operacional para outro. Você pode usar SSL no seu serviço Sisk se associar um certificado ao host virtual com o IIS. Para outros sistemas, usar um proxy reverso é altamente recomendado.

Criando um serviço #

Criar um serviço fará sua aplicação estar sempre disponível, mesmo após reiniciar a instância do servidor ou em caso de falha não recuperável.

Neste tutorial simples, usaremos o conteúdo do tutorial anterior como exemplo para manter seu serviço sempre ativo.

  1. Acesse a pasta onde os arquivos de configuração do serviço estão localizados:

    Shell
    cd /etc/systemd/system
  2. Crie seu arquivo my-app.service e inclua o conteúdo:

    my-app.serviceINI
    [Unit]
    Description=<description about your app>
    
    [Service]
    # define o usuário que iniciará o serviço
    User=<user which will launch the service>
    
    # o caminho ExecStart não é relativo ao WorkingDirectory.
    # defina-o como o caminho completo para o arquivo executável
    WorkingDirectory=/home/htdocs
    ExecStart=/home/htdocs/my-app
    
    # configure o serviço para sempre reiniciar em caso de falha
    Restart=always
    RestartSec=3
    
    [Install]
    WantedBy=multi-user.target
  3. Reinicie o módulo do gerenciador de serviços:

    Shell
    $ sudo systemctl daemon-reload
  4. Inicie o serviço recém‑criado a partir do nome do arquivo que você definiu e verifique se ele está em execução:

    Shell
    $ sudo systemctl start my-app
    $ sudo systemctl status my-app
  5. Agora, se sua aplicação está em execução (“Active: active”), habilite seu serviço para continuar rodando após uma reinicialização do sistema:

    Shell
    $ sudo systemctl enable my-app

Agora você está pronto para prosseguir e apresentar sua aplicação Sisk a todos.

Digite para pesquisar na documentação e na referência da API.