Fazendo o Deploy de uma aplicação NodeJs + Socket.io para um WebSite do Azure utilizando o Visual Studio Code

Standard

Neste post veremos como podemos fazer o deploy de aplicações NodeJs que possuam recursos de comunicação em tempo real (no caso utilizando Socket.io) para um WebSite do Azure utilizando o novo editor de código da Microsoft chamado Visual Studio Code

Nota: Para este exemplo vou estar utilizando a aplicação criada neste post que é feita em NodeJs + Socket.io onde exibe em tempo real o percentual de consumo da cpu.

Abaixo listo os tópicos que serão abordados ao longo do artigo:

– Configurando o VSCode e as permissões do git para habilitar Sync, Pull e Push pelo editor
– Criando um WebSite no Azure para sincronização automática com o Github
– Habilitando e configurando WebSockets na WebSite criada
– Configurando o arquivo web.config
– Rodando a aplicação com WebSockets e Long Pooling – Entendendo os transportes

Configurando o VSCode e as permissões do git para habilitar Sync, Pull e Push pelo editor

Já com o VSCode instalado, vamos executa-lo (caso precise, o mesmo fica localizado no diretório “C:\Users\user\AppData\Local\Code\”) e clicar em File > Open Folder…

Como nosso projeto já possui um repositório criado, se clicarmos no menu Git o mesmo já será aberto de forma sincronizada. Caso você ainda não possua um repositório criado, será necessário cria-lo clicando no botão “Initialize git repository”.

Para iniciarmos vamos criar um arquivo chamado web.config na raíz do projeto sem nenhum conteúdo, apenas para podermos realizar um commit/push para o servidor.

Feito isso, nosso arquivo web.config criado já ficará pendente de commit/push no menu Git. Neste ponto nós já podemos realizar commit do arquivo, porém, se suas credenciais do Git não estiverem definidas de forma global, muito provavelmente as opções de Sync, Pull e Push ficarão desabilitadas no ícone “More”, como mostrado abaixo:

Para habilitarmos o sync, pull e push (no caso foi o que EU precisei para habilitar, pode ser que em outros casos esses passos não sejam necessários) foi necessário definir minhas credenciais do Git de forma global, desta forma eu precisei entrar no Git Bash navegar até o diretório do projeto e inserir os comandos abaixo:

git config --global credential.helper wincred

E o primeiro push eu também precisei realizar pelo bash, como mostrado abaixo:

git push -u origin master

Após estes passos foi possível utilizar os comandos necessários!

Criando um WebSite no Azure para sincronização automática com o Github

Esta parte é bem simples, no portal do Azure vamos criar um novo WebSite seguindo as imagens abaixo:

Atente-se de marcar a opção “Publicar do controle de origem” para que seja possível realizar a publicação da aplicação no Azure a partir do repositório do Github automaticamente após algum push ou alteração, veremos isso nos passos seguintes:

Em seguida autorizamos a sincronização da conta Github com o Azure:

Habilitando e configurando WebSockets na WebSite criada

Com nossa WebbApp já criada precisamos habilitar o uso de WebSockets, para isso basta clicar no menu “Configurar” e ativar o recurso:

Configurando o arquivo web.config

Neste momento nossa aplicação já está ativa, porém, se entrarmos na url criada veremos o seguinte erro:

Isto ocorre pois tanto o NodeJs quando o IIS estão trabalhando juntos para hospedar nossa aplicação. O IIS por sua vez utiliza neste momento um recurso chamado iisnode (veja mais sobre aqui), para que tudo funcione corretamente será necessário inserir algumas configurações em nosso arquivo web.config.

Por padrão, toda aplicação NodeJs hospedada no Azure possui um web.config. Desta forma mesmo que sua aplicação não possua um web.config, um arquivo padrão será criado. Pegaremos como base este arquivo .config e vejamos abaixo como o mesmo deve ficar em nossa aplicação:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<?xml version="1.0" encoding="utf-8"?>
<!--
    This configuration file is required if iisnode is used to run node processes behind
    IIS or IIS Express.  For more information, visit:

    https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config
-->

<configuration>
 
  <system.web>
    <identity impersonate="false"/>
  </system.web>
 
  <system.webServer>
   
    <validation validateIntegratedModeConfiguration="false" />
   
    <!-- Visit http://blogs.msdn.com/b/windowsazure/archive/2013/11/14/introduction-to-websockets-on-windows-azure-web-sites.aspx for more information on WebSocket support -->
    <webSocket enabled="false" />
    <handlers>
      <!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
      <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>
    </handlers>
    <rewrite>
      <rules>
        <!-- Do not interfere with requests for node-inspector debugging -->
        <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
          <match url="^server.js\/debug[\/]?" />
        </rule>

        <!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>
        </rule>

        <!-- All other URLs are mapped to the node.js site entry point -->
        <rule name="DynamicContent">
          <conditions>
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          </conditions>
          <action type="Rewrite" url="server.js"/>
        </rule>
      </rules>
    </rewrite>

    <!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
    <security>
      <requestFiltering>
        <hiddenSegments>
          <remove segment="bin"/>
        </hiddenSegments>
      </requestFiltering>
    </security>

    <!-- Make sure error responses are left untouched -->
    <httpErrors existingResponse="PassThrough" />

    <!--
     You can control how Node is hosted within IIS using the following options:
       * watchedFiles: semi-colon separated list of files that will be watched for changes to restart the server
       * node_env: will be propagated to node as NODE_ENV environment variable
       * debuggingEnabled - controls whether the built-in debugger is enabled

     See https://github.com/tjanczuk/iisnode/blob/master/src/samples/configuration/web.config for a full list of options
   -->
    <!--<iisnode watchedFiles="web.config;*.js"/>-->
  </system.webServer>
</configuration>

Veja que estamos desabilitando o gerenciamento de websockets do iis na linha para que não ocorra nenhum tipo de conflito interno. Além de definirmos e como demonstrado neste artigo.

Este excelente artigo do Scott Hanselman aborda bem mais a fundo estas alterações, vale a pena conferir também.

Se realizarmos novamente o commit/push do nosso arquivo web.config agora teremos sucesso no consumo do WebSite 🙂

Rodando a aplicação com WebSockets e Long Pooling – Entendendo os transportes

Como mostrado acima podemos constatar tudo já está funcionando, porém, se olharmos na aba Network da “Developer Tool” (Ctrl + Shift + I) do browser veremos que está sendo utilizando pooling como transporte, ao invés de websockets:

Para altermos isto e utilizarmos websockets como default devemos alterar nosso server.js para que a definição require do socket.io fique como mostrado abaixo:

var io = require('socket.io')(http, {'transports': ['websocket', 'xhr-polling']});

Ou seja, estamos invertendo a ordem de prioridade para o broadcast de mensagens para que o websocket seja a primeira opção.

Conclusão

Acredito que futuramente a equipe do VSCode facilitará muito as coisas neste ponto de vista, esta sincronização com as contas do Git e esta parte de deploy para o Azure “acho” que serão facilitadas e automatizadas. Por hoje, podemos fazer desta forma que é “tiro e queda”.

Até a próxima!

Referências

http://www.hanselman.com/blog/EnablingWebsocketsForSocketioNodeAppsOnMicrosoftAzure.aspx
https://code.visualstudio.com/Docs/versioncontrol
http://www.aaronstannard.com/node-azure-emulator-500-error/
http://www.jokecamp.com/blog/getting-started-with-iisnode/

Leave a Reply

Your email address will not be published. Required fields are marked *