Windows Azure: criando as famosas “startup tasks”

Um dos primeiros conceitos vistos quando somos introduzidos ao universo de cloud computing é o de PaaS (Platform as a Service). Evidentemente que isso é feito porque este modelo apresenta inúmeras vantagens em relação ao modelo tradicional de desenvolvimento. Escrevi um post aqui no site já há algum tempo falando sobre isso e você pode efetuar a leitura gratuitamente.

Se você acompanha este site, deve saber que durante um bom tempo fui especialista de Windows Azure na Microsoft Brasil. Uma de minhas principais atribuições neste período, era justamente a de apresentar o modelo de plataforma como serviço para desenvolvedores. Um fato interessante que sempre marcava as apresentações no momento de perguntas e respostas, era a realização da mesma pergunta quase sempre: “Fabrício, e se eu precisar de um ambiente personalizado em minha role do Azure. Consigo fazer?“. Ainda hoje, recebo uma quantidade considerável de perguntas através deste site sobre como personalizar roles do Azure para rodar tecnologias específicas.

Considerando este cenário, resolvi falar um pouco no post de hoje sobre as famosas “startup tasks“. Sim, elas são a saída para realizar personalizações no ambiente do Windows Azure como plataforma.

Entendendo o cenário das web roles

Conforme escrevi neste post, uma web role é, em linhas gerais, uma máquina virtual que é automaticamente criada e pré-configurada quando uma nova demanda de host é solicitada ao Windows Azure, conforme ilustra o esquema funcional apresentado pela Figura 1.

Figura 1. Esquema funcional das web roles no Windows Azure

Note, que a utilização da palavra “pré-configurada” para a máquina virtual, implica necessariamente no setup com as seguintes características:

1. Windows Server;
2. Internet Information Services (IIS);
3. ASP.NET Core;

A máquina virtual pode ser acessada através de endpoints HTTP/HTTPS. Sim, é possível acessar a máquina virtual utilizando ferramentas como Remote Desktop Connection (RDC) para administração. Este seria o melhor dos mundos, não fosse o limite imposto pelo modelo PaaS (e não pelo o Windows Azure, é importante que se diga) – a “reciclagem automática” das máquinas virtuais. Desta forma, toda configuração realizada poderá ser perdida ao findar de um ciclo e início de outro.

Para que esta ideia fique mais clara, imagine a seguinte situação: você instala o PHP 5 em sua role. Você faz isso porque deseja utilizar o PHP como ambiente de execução para sua aplicação. Você acessa via RDC a máquina, configura o IIS para “rodar PHP” e, em algum momento, sua aplicação simplesmente para de funcionar. Ao se conectar você percebe que todo setup realizado anteriormente não existe mais. Natural, uma vez que a role antiga foi “destruída” para que outra assumisse o controle.

Esta operação é realizada pela plataforma de nuvem por vários motivos, os quais não cabem a discussão aqui por não ser o foco do texto, entretanto, dentre outros benefícios, a segurança e qualidade do ambiente de execução.

A solução? Startup Tasks

A solução para a personalização de ambientes em modelo PaaS é conhecida como “startup task” ou em português brasileiro, “tarefas de inicialização”.

Como o próprio nome sugere, trata-se da implantação (implementação + execução) de um fluxo de execução de operações na inicialização da role que hospedará a aplicação, geralmente realizada através da implementação em um arquivo batch.

A ideia básica é, toda vez que a role associada à aplicação “acordar”, o ambiente seja configurado de forma automática através da execução do arquivo batch implementado. Com isso, é possível ter a independência da máquina virtual, uma vez que o batch estará associado à aplicação e assim, a nova role.

A Figura 2 ilustra o processo de execução de uma web role que utiliza startup task.

Figura 2. Fluxo de execução de uma role com startup task

Como fazer?

Para que possamos exemplificar a utilização das startup tasks, vamos imaginar um cenário (lúdico, é verdade) onde seria necessária a habilitação do chamado “ASP clássico” no ambiente.

Para criação do projeto de exemplo, estou utilizando o Visual Studio 2012 e a última SDK do Windows Azure. Você pode obter estas ferramentas gratuitamente seguindo os links a seguir.

• Visual Studio 2012 Express: http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-products
• SDK do Windows Azure: http://www.windowsazure.com/en-us/develop/net/

Passo 1: Crie um projeto de nuvem

Com o Visual Studio em execução, adicione um novo projeto do tipo cloud. Na tela seguinte, adicione um projeto ASP.NET, para que a role possa ser criada. Estas operações resultam no seguinte estado (Figura 3) da solution explorer.

Figura 3. A role exemplo

Passo 2: Criando a startup task

O passo seguinte consiste em criar nossa startup task. Para isso, utilizaremos o editor de textos ASCII mais famoso de todos: o Notepad. Você deve estar se perguntando: mas porquê o Notepad se temos a disposição o Visual Studio? O VS estrutura os arquivos CMD com uma estrutura diferenciada, adicionando cabeçalhos aos arquivos, o que faz com que as operações nele implementadas não sejam executadas na inicialização da role.

Para este exemplo, estou chamando o arquivo com o fluxo de operações de startup.cmd. O conteúdo que faz o setup da role para suportar ASP classic pode ser visualizado através da Figura 4. Antes que você se pergunte eu respond: sim, apenas essa linha faz tudo o que é preciso.

Figura 4. O comando que realiza o setup da role para suportar ASP clássico

Passo 3: Incorporando o arquivo a role

Com nosso batch criado, devemos como próxima etapa incorporar o mesmo à web role. Para isso, clique com o botão direito sobre o nome do projeto ASP.NET e selecione a opção “Add“ > “Existing item“. Selecione o arquivo “startup.cmd” e pressione “Ok”. O resultado da adição pode ser visualizado na Figura 5.

Figura 5. O arquivo executável adicionado ao projeto

Passo 4: Alterando o arquivo ServiceDefinition.csdef

Se você conhece um pouco mais de perto o Windows Azure, sabe que existem dois arquivos de fundamental importância para que uma aplicação web possa ser hospedada em uma web role: ServiceConfiguration.cscfg e ServiceDefinition.csdef. O primeiro armazena as configurações do ambiente e o segundo, as definições do ambiente. Falei sobre estes arquivos em mais detalhes neste post.

Para que o ambiente possa ser configurado, o Windows Azure precisa saber que arquivo de inicialização buscar. Para isso, faremos a alteração apresentada pela Listagem 1 no arquivo de definição.

[xml]

[/xml]

Listagem 1. A incorporação da task no arquivo de definição da role

Aqui chamamos a atenção para a linha 3, onde encontra-se a chamada para a execução das operações implementadas no arquivo “startup.cmd“. O atributo “ExecutionContext” informa ao Windows Azure que a operação deve ser elevada (elevated) com o nível de permissão “NT AUTHORITYSYSTEM“, ou seja, como administrador. Se a opção escolhida fosse “limited“, a operação não seria realizada como administrador.

Passo 5: Adicionando uma página de teste

Para testarmos o comportamento de nosso ambiente, adicionaremos uma página chamada “default.asp” com um código de boas vindas (Listagem 2).

[html]
<%@ Language=”javascript” %>

<% Response.write(“Rodando ASP clássico na Web Role do Azure ;)”); %>

[/html]

Agora, basta fazer o deploy da aplicação no Windows Azure. Se você não sabe como proceder, você pode efetuar a leitura deste excelente post que apresenta o procedimento.

Passo 6: Testando

Para testar nossa aplicação, o que precisamos fazer é chamar o endereço fornecido pelo Windows Azure e verificar a resposta. A Figura 7 a página respondendo com ASP clássico.

Figura 7. O resultado da execução do ASP classic

Conclusões

As startup tasks são o mecanismo mais importante que os desenvolvedores possuem para realizar a configuração de ambientes em ambientes tipicamente de plataforma.

É possível também, criar scripts de inicialização utilizando Power Shell. Esta pode ser uma opção interessante, uma vez que o power shell oferece maior poder para o desenvolvedor interagir com a camada do sistema operacional.

Era isso! Até a próxima!