Semana passada fiz uma palestra no TDC 2014 na trilha de Arquitetura .NET, o tema da minha palestra foi “Arquitetura de Big Data no Microsoft Azure”.

Na palestra falei um pouco sobre Big Data, Azure e HDInsight. Depois disso falei um pouco sobre o livro Developing Big Data Solutions on Microsoft Azure HDInsight, publicado pelo time de Patterns & Practices e que fui um dos revisores. No livro existem quatro cenários bastante interessantes para o uso de Big Data: iterativo, ETL, Data Warehousing e BI.

O PPT da minha sessão pode ser encontrado abaixo:

Abs.,

RG

Olá pessoal,

Com o recente anúncio do GA (General Availability) da região sul do Brasil, muitos clientes estão me perguntando como podem migrar suas máquinas virtuais das outras regiões para a região brasileira. A realidade é que não existe um procedimento automatizado para que esta migração ocorra, sendo necessário passos manuais para a migração ocorrer.

Em linhas gerais, os principais passos são os seguintes:

1. Listar as VMs de um determinado Cloud Service
2. Para cada VM
   1. Desligar a VM se ela estiver rodando
   2. Criar um snapshot para o disco do sistema operacional
   3. Criar um snapshot para cada data disk
   4. Ligar a VM se ela estivesse rodando
3. Para cada snapshot criado, copiar o Blob uma outra conta de storge
4. Esperar a cópia de todos os Blobs
5. Importar a configuração das VMs existentes
6. Substituir os discos, tanto do sistema operacional quanto de dados, pelos novos Blobs
7. Criar as novas VMs em um outro Cloud Service

Ufa!!! São vários passos, mas para facilitar podemos utilizar os Cmdlets PowerShell de gerenciamento do Azure. Vamos detalhar cada um dos passos acima.

Listar as VMs de um determinado Cloud Service:

Para listar as VMs de um Cloud Service basta utilizar o Cmdlet Get-AzureVM, passando o nome do Cloud Service como parâmetro:

$vms = Get-AzureVM -ServiceName $sourceCloudServiceName

Desligar a VM se ela estiver rodando

Antes de criarmos os snapshots dos discos é importante que a VM esteja desligada, pois isso irá garantir que todos os dados que eventualmente estão em algum cache foram efetivamente gravados em disco, minimizando a perda de alguma informação e garantindo a integridade das informações.

Nesta etapa, primeiro é necessário verificar se a VM está rodando. Isso é feito verificando a propriedade InstanceStatus da VM. Se ela for ReadyRole significa que ela está no ar.

Para desligar a VM, basta utilizar o Cmdlet Stop-AzureVM, conforme abaixo:

Stop-AzureVM -ServiceName $sourceCloudServiceName -Name $vmName –StayProvisioned

O parâmetro StayProvisioned é importante para mantermos o endereço IP da VM e permitir que ela seja religada de maneira mais rápida nos próximos passos.

Criar um snapshot para o disco do sistema operacional

A tarefa de criar um snapshot do disco do sistema operacional é um pouco complexa. O primeiro passo é ter acesso ao disco, isso é feito através do Cmdlet Get-AzureOSDisk:

$osDisk = $vm | Get-AzureOSDisk

Em seguida, é necessário acessar o Blob que o disco está utilizando. A propriedade MediaLink do disco contém o endereço deste Blob. O acesso ao Blob pode ser feito com o Cmdlet Get-AzureStorageBlob.

Utilizando o objeto de Blob retornado, é possível criar o snapshot através da interface ICloudBlob da API .NET, conforme abaixo:

$snapshot = $blob.ICloudBlob.CreateSnapshot()

Criar um snapshot para cada data disk

Para criar um snapshot para cada data disk, o primeiro passo é ter acesso aos data disks. Isso é feito pelo Cmdlet Get-AzureDataDisk:

$dataDisks = $vm | Get-AzureDataDisk

A principal diferença dos passos acima, é que o Get-AzureDataDisk retorna uma coleção de discos, sendo necessário trata-los individualmente, o que pode ser feito com um foreach. Os outros passos são muitos similares ao que foi apontado acima.

Ligar a VM se ela estivesse rodando

Para ligar a VM, basta utilizar o Cmdlet Start-AzureVM:

Start-AzureVM -ServiceName $sourceCloudServiceName -Name $vmName

Para cada snapshot criado, copiar o Blob uma outra conta de storage

Para facilitar a cópia de arquivos grandes, caso dos discos das VMs, o Azure possui uma API de cópia assíncrona em background que ocorre do lado do servidor. O time do Azure storage fez um post chamado Introducing Asynchronous Cross-Account Copy Blob detalhando essa API.

O PowerShell possui o Cmdlet Start-AzureStorageBlobCopy que utiliza essa API, conforme abaixo:

Start-AzureStorageBlobCopy -ICloudBlob $snapshot -DestContext $destinationStorageAccountContext -DestContainer "vhds" -DestBlob $snapshot.Name

Esperar a cópia de todos os Blobs

Para esperar que a cópia dos Blobs ocorra, o PowerShell possui um Cmdlet chamado Get-AzureStorageBlobCopyState, que retorna informações sobre a situação da cópia.

Importar a configuração das VMs existentes

Depois que os discos foram copiados, o próximo passo seria configurar as novas VMs. Para isso é necessário realizar dois passos: exportar a configuração atual e depois importar esta configuração:

$vmSource | Export-AzureVM -Path $env:TEMP\$($vmSource.Name).xml
$vmDestination = Import-AzureVM -Path $env:TEMP\$($vmSource.Name).xml

Substituir os discos, tanto do sistema operacional quanto de dados, pelos novos Blobs

Nesta etapa são vários passos. Primeiro é necessário encontrar o novo Blob copiado que está relacionado com o disco da configuração atual, isso é feito da seguinte maneira:

$osDisk = Get-AzureDisk -DiskName $vmSource.VM.OSVirtualHardDisk.DiskName
$blob = $blobs | Where-Object {$_.Name -eq $osDisk.MediaLink.Segments[2]}

Depois criar um novo disco e substituir o disco da nova VM:

$newOSDisk = Add-AzureDisk -DiskName ($destinationCloudServiceName + "-" + $osDisk.DiskName) -MediaLocation $blob.ICloudBlob.Uri.AbsoluteUri -OS $osDisk.OS

$vmDestination.OSVirtualHardDisk.DiskName = $newOSDisk.DiskName

Para os Data Disks o procedimento é muito parecido, com algumas pequenas diferenças:

• Uma VM pode ter vários Data Disks, então isso deve ser tratado em um loop
• Utilizar a propriedade DataVirtualHardDisks da VM, ao invés da propriedade OSVirtualHardDisk
• Ao criar o disco com o Cmdlet Add-AzureDisk, não informar o parâmetro –OS

Criar as novas VMs em um outro Cloud Service

A criação das novas VMs é um passo bastante simples, basta utilizar o Cmdlet New-AzureVM. Este comando recebe uma coleção de configurações de VMs, então todas podem ser criadas em um único passo:

New-AzureVM -ServiceName $destinationCloudServiceName -VMs $vmDestination

Se as VMs originais estiverem configuradas em uma Virtual Network, também é possível especificar esse parâmetro na criação das VMs:

New-AzureVM -ServiceName $destinationCloudServiceName -VMs $vmDestination -VNetName $vnetName

Script

Para facilitar, criei um script PowerShell que faz os passos acima e um pouco mais. O download pode ser feito aqui.

Para o script funcionar, são necessários os seguintes requisitos:

1. O Cloud Service de destino deve existir
2. A conta de storage de destino deve existir
3. Um container chamado vhds deve existir no storage de destino
4. Tanto os Cloud Services de origem e destino, quanto as contas de storage de origem e destino devem estar na mesma assinatura do Azure
5. Se uma rede virtual está sendo utilizada, é necessário que a rede de destino tenha as mesmas configurações de sub rede da rede de origem

Para rodar o script, utilize a seguinte sintaxe:

Copy-AzureVM $sourceCloudServiceName $destinationCloudServiceName $destinationStorageAccountName $vnetName

Abs.,

RG

Recentemente tenho trabalhado com alguns clientes na migração de aplicações da Amazon para o Azure, principalmente de arquivos armazenados no S3 para os Blobs do Azure.

Em relação à essa migração, do lado do Azure, uma técnica que pode ser utilizada é o uso da API de cópia assíncrona de Blobs, no .NET o método StartCopyFromBlob. Este método permite a cópia do lado do servidor entre Blobs diferentes. Por Blobs diferentes significa que eles podem estar em containers, contas de storage ou até mesmo assinaturas de Azure diferentes. Além disso, esse método também possui uma sobrecarga que recebe uma url pública, permitindo a cópia assíncrona do lado do servidor de arquivos externos ao Azure acessíveis pela internet.

Em linhas gerais, um programa para fazer a migração desses arquivos deve realizar os seguintes passos:

1. Listar os arquivos de um bucket do S3
2. Para cada arquivo, gerar uma url pública de acesso
3. Para cada arquivo, realizar a cópia para o Azure utilizando o método StartCopyFromBlob
4. Monitorar o status da cópia do lado do Azure

Para facilitar o trabalho, criei um projeto no CodePlex chamado AWS S3 To Azure Blob. Esta é uma aplicação de linha de comando que realizar os passos acima. O projeto foi publicado como Git, fique à vontade para colaborar.

Abs.,

RG

Uma das coisas que pouca gente percebeu é que é possível rodar aplicações ASP clássicas no Azure Web Sites.

Para conseguir rodar um site ASP não é necessária nenhuma configuração especial. De fato, na lista de documentos padrão já temos pré-cadastrado o bom e velho Default.asp.

Para testar, basta criar um arquivo com a extensão ASP, por exemplo, Default.asp e em seguida editar seu conteúdo com algum comando ASP. O exemplo abaixo mostra a versão do IIS rodando no ambiente:

<%
     Response.Write(Request.ServerVariables("SERVER_SOFTWARE"))
%>

Em seguida, basta fazer deploy por um dos vários métodos que o Azure Web Sites suporta, eu utilizei FTP para fazer deploy deste exemplo, e por último acessar o site.

Abs.,

RG

Algumas pessoas me perguntam como melhorar o desempenho de uma aplicação rodando no Microsoft Azure. Existem várias possibilidades de otimização, uma delas é o uso de cache, fazendo com que a aplicação diminua a latência no acesso aos dados e consequentemente tenha um melhor tempo de resposta ao usuário.

O primeiro passo no uso do cache é a criação de uma instância do serviço de cache (no momento que este post foi escrito o serviço estava em preview). Para isso, selecione o botão New, em seguida Data Services, Cache, Quick Create e forneça o endpoint que o cache será acessado, a região que o serviço ficará localizado e o seu tamanho, que pode variar entre 128MB até 150GB.

Depois do cache criado, o processo de criação pode levar alguns minutos para ser concluído, o próximo passo é utilizar o cache. Em um projeto ASP.NET no Visual Studio, vc pode adicionar referências aos componentes de cache via NuGet, pesquisando por Windows Azure Cache.

Além de instalar todas as referências, o NuGet também faz algumas modificações no arquivo web.config, facilitando bastante o uso do cache. Vc deve informar o endpoint do serviço de cache, no formato <Nome>.cache.windows.net, substituindo o conteúdo [Cache role name or Service Endpoint] do elemento autoDiscover. Vc encontra o endereço do endpoint no dashboard do serviço de cache:

O próximo passo é fornecer a chave de acesso para autenticação do cache. Para isso, descomente a sessão secutiryProperties do web.config e forneça a chave de acesso, substituindo o texto [Authentication Key]. A chave de acesso pode ser encontrada através da opção Manage Keys do portal de gerenciamento:

Finalmente, o próximo passo é utilizar o cache no código da sua aplicação. O primeiro passo é criar um objeto da classe DataCache, disponível no namespace Microsoft.ApplicationServer.Caching. Se o construtor padrão for utilizado uma conexão com o cache padrão será criada.

O cache possui vários métodos para interagir com o seu conteúdo, mas um padrão bastante comum utilizado é o Cache-Aside, onde ser verifica se o conteúdo já existe no cache, se não existir deve-se buscar o conteúdo no repositório de dados, em seguida adicionar o conteúdo no cache e depois retornar, conforme diagrama abaixo:

Criei um projeto padrão ASP.NET MVC no Visual Studio 2013 e modifiquei o método About do controller HomeController para utilizar o cache. No método GetAboutMessageFromRepository, faço um Thread.Sleep de 10 segundos para simular a demora de uma consulta complexa em um banco de dados:

public ActionResult About()
{
        ViewBag.Message = GetAboutMessage();

        return View();
}

private static string GetAboutMessage()
{
    const string AboutMessage = "AboutMessage";
    DataCache cache = new DataCache();

    object aboutMessage = cache.Get(AboutMessage);

    if (aboutMessage == null)
    {
        aboutMessage = GetAboutMessageFromRepository();
        cache.Add(AboutMessage, aboutMessage);
    }
   
    return aboutMessage.ToString();
}

private static string GetAboutMessageFromRepository()
{
    Thread.Sleep(10000);
    return "Your application description page.";
}

Nos próximos posts pretendo detalhar um pouco a classe DataCache, com seus principais métodos, como controlar a expiração de conteúdo e também como utilizar o cache integrado com o ASP.NET para controlar sessão e o output cache das páginas.

Abs.,

RG

Geralmente quando discuto a arquitetura de aplicações que tirem proveito dos benefícios dos Cloud Services no Windows Azure, muitas dessas aplicações precisam proteger conteúdos sensíveis, como, informações pessoais e dados de login das aplicações.

O processo para se utilizar HTTPS nas aplicações é bastante simples, envolvendo algumas tarefas no portal de gerenciamento e outras tarefas no Visual Studio, e pode ser resumido da seguinte forma:

Tarefas no portal de gerenciamento:

1. Criar o Cloud Services
2. Fazer upload do certificado digital

Tarefas no Visual Studio:

1. Fazer referência à um certificado
2. Adicionar um endpoint HTTPS utilizando essa referência

Entretanto, existe um pré-requisito muito importante que precisa ser satisfeito antes de iniciarmos os passos acima, que é ter acesso ao certificado digital. Se vc está fazendo a publicação de uma aplicação em produção, muito possivelmente vc já adquiriu o certificado digital de uma entidade certificadora e pode passar para os próximos passos. Agora, se vc está fazendo o deploy de um sistema que está em desenvolvimento, é bem provável que vc queira utilizar um certificado auto assinado (self signed certificate). Tecnicamente este tipo de certificado funciona, mas como ele não é assinado por uma entidade certificadora os navegadores emitem um aviso e seu uso não é indicado para ambientes de produção.

O Visual Studio possui uma ferramenta que facilita a geração de certificados auto assinados, é a ferramenta Makecert (na verdade o Makecert pode ser instalado com vários SDKs). Vc pode gerar um desses certificados utilizando a seguinte sintaxe:

makecert -sky exchange -r -n "CN=<Nome do certificado>" -pe -a sha1 -len 2048 -ss My <Nome do certificado>.cer

Para entender melhor o exemplo acima, vamos ver detalhes de todos os parâmetros utilizados:

• -sky exchange: indica que o certificado pode ser utilizado para encriptar os dados;
• -r: cria um certificado auto assinado;
• -n “CN=<Nome do certificado>”: indica o nome do certificado;
• -pe: marca a chave privada como sendo possível de ser exportada;
• -a sha1: algoritmo utilizado para assinatura;
• -len 2048: tamanho, em bits, da chave do certificado;
• -ss My: indica em qual certificate store o certificado será salvo;
• <Nome do certificado>.cer: arquivo que terá o certificado salvo.

Com o certificado criado, podemos voltar para os passos elencados anteriormente no portal de gerenciamento e depois no Visual Studio.

A primeira tarefa no portal de gerenciamento é a criação do Cloud Service. Acredito que a maneira mais fácil de criar um Cloud Service é através da opção Quick Create do portal de gerenciamento. Para isso, acesse a opção New, Compute, Cloud Service, Quick Create e forneça o nome do Cloud Service, que terá uma URL no formato <NomeDoCloudService>.cloudapp.net, e também a região que ele estará localizado.

O próximo passo é fazer upload do certificado gerado no portal de gerenciamento. Para isso precisamos exportar o certificado no formato .pfx, conforme os seguinte passos:

Abra o gerenciador de certificados do Windows executando o comando certmgr.MSc

Encontre e abra o certificado que foi gerado com o Makecert.

Acesse a aba Details e em seguida clique no botão Copy to File…

No wizard, escolha a opção para exportar a private key.

Mantenha as opções padrão apresentadas e forneça uma senha quando tiver a possibilidade.

Por último, forneça o endereço que o arquivo será exportado e finalize o wizard.

Agora devemos fazer upload do certificado no portal de gerenciamento. Abra o Cloud Service recém criado na guia de certificados e escolha a opção upload:

Na tela apresentada, forneça o arquivo .pfx exportado e a senha utilizada:

Com isso vc deve ter um resultado similar à tela abaixo. Copie o thumbprint, destacado em amarelo na imagem, que ele será utilizado nos próximos passos dentro do Visual Studio.

Já no Visual Studio, abra as propriedades da sua Web Role e adicione um novo certificado informando o thumbprint do certificado que foi feito upload.

Feito isso, é hora de adicionar é hora de adicionar um endpoint Https fazendo referência para esse certificado, que pode ser escolhido na lista de seleção da coluna SSL Certificate Name.

Agora é só fazer o deploy do seu projeto e acessar a sua aplicação via Https.

Como estamos utilizando um certificado self signed, é bastante provável que o seu navegador gere uma mensagem de erro ao acessar o endereço. Para acessar a aplicação deve-se escolher a opção de continuar.

Abs.,

RG

Entre os dias 5 e 6 (sábado e domingo) de outubro deste ano (2013) tivemos o evento Community Zone na Microsoft. Neste evento tive a oportunidade de ministrar um TTT de Windows Azure para os ITPros.

A minha apresentação pode ser encontrada abaixo:

É interessante notar que fora o slide de título, a apresentação tinha apenas mais um slide para o conteúdo. Este slide de conteúdo contém uma série de links que os ITPros podem utilizar para se preparar quanto ao uso de Windows Azure.

O último link de conteúdo é o Windows Azure Training Kit, que traz uma série de hand-on labs, demos e apresentações que podem ser reutilizadas.

Abs.,

RG

Para quem não sabe, o Windows Azure possui uma camada de APIs REST que permitem realizar o gerenciamento do seu ambiente, chamada de Windows Azure Service Management REST API. O interessante é que tudo que interage com o ambiente do Azure utiliza essas APIs, ou seja, tanto o portal de administração, o Visual Studio, System Center e ferramentas de linhas de comando.

Isso é excelente, afinal praticamente tudo que pode ser administrado no ambiente é feito por essas APIs. Entretanto, esse processo não é fácil. Como a API é muito poderosa, sua documentação é bastante extensa e seu uso pode ficar um pouco confuso.

Quando esse tipo de situação ocorre, eu recorro ao PowerShell. Os cmdlets do Windows Azure possuem mecanismos de depuração que retornam a chamada REST realizada na API, e o PowerShell gerencia essas informações de depuração com variáveis de preferências que são capazes de modificar o comportamento do script. Dessas variáveis, uma muito importante é a $DebugPreference que indica como o PowerShell deve tratar as informações de depuração e pode ter os seguintes valores:

• Stop: exibe a mensagem de depuração e finaliza a execução do script
• Inquire: exibe a mensagem de depuração e pergunta se deve continuar a execução do script
• Continue: exibe a mensagem de depuração e continua a execução do script
• SilentlyContinue: é o valor padrão. Não exibe a mensagem de depuração e executa o script sem interrupção

Logo, se mudarmos o valor da variável $DebugPreference para algum valor diferente do padrão temos informações úteis das chamadas aos serviços REST. Vou utilizar o script de criação de VMs de um post que fiz anteriormente, apenas alterando as informações de depuração.

clear

$DebugPreference = "Continue"

$imageName = "a699494373c04fc0bc8f2bb1389d6106__Win2K8R2SP1-Datacenter-201306.01-en.us-127GB.vhd"

$user = "<SeuUsuario>"

$password = "<SuaSenha>"

New-AzureVMConfig -Name "<NomeDaSuaMaquina>" -InstanceSize "Small" -ImageName $imageName |

Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $password |

New-AzureVM -ServiceName "<NomeDoSeuServico>" -Location "East US"

Com isso, é possível perceber que o PowerShell realizar uma série chamadas REST ao Windows Azure:

Primeiro ele verifica se o serviço ainda não existe:

DEBUG: 11:59:50 - NewAzureVMCommand begin processing with ParameterSet 'CreateService'.

DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:

GET

Absolute Uri:

https://management.core.windows.net/<SubscriptionId>/services/hostedservices/<NomeDoSeuServico>/deploymentslots/Production

Headers:

x-ms-version : 2013-06-01

x-ms-client-id : <GuidDaChamada>

User-Agent : WindowsAzurePowershell/v0.6.16.1

Body:

Depois envia um comando para criar o serviço e recebe o id da operação como resposta:

DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:

POST

Absolute Uri:

https://management.core.windows.net/<SubscriptionId>/services/hostedservices

Headers:

x-ms-version : 2013-06-01

x-ms-client-id : <GuidDaChamada>

User-Agent : WindowsAzurePowershell/v0.6.16.1

Body:

<?xml version="1.0" encoding="utf-16"?>

<CreateHostedService xmlns="https://schemas.microsoft.com/windowsazure" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">

    <ServiceName><NomeDoSeuServico></ServiceName>

    <Label>cmdvZGluaG9kYmc=</Label>

    <Description>Implicitly created hosted service2013-07-22 14:59</Description>

    <Location>East US</Location>

</CreateHostedService>

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:

Created

Headers:

x-ms-servedbyregion : ussouth

x-ms-request-id : <IdDaOperacao>

Content-Length : 0

Cache-Control : no-cache

Date : Mon, 22 Jul 2013 14:59:58 GMT

Location : https://management.core.windows.net/subscriptions/<SubscriptionId>/compute/<NomeDoSeuServico>

Server : 33.0.6198.68 (rd_rdfe_stable.130710-0833) Microsoft-HTTPAPI/2.0

Body:

Depois ele fica em um loop verificando o status da operação até ela ser finalizada com sucesso:

DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:

GET

Absolute Uri:

https://management.core.windows.net/<SubscriptionId>/operations/<IdDaOperacao>

Headers:

x-ms-version : 2013-06-01

x-ms-client-id : <GuidDaChamada>

User-Agent : WindowsAzurePowershell/v0.6.16.1

Body:

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:

OK

Headers:

x-ms-servedbyregion : ussouth

x-ms-request-id : <NovoIdDaOperacao>

Content-Length : 232

Cache-Control : no-cache

Content-Type : application/xml; charset=utf-8

Date : Mon, 22 Jul 2013 14:59:58 GMT

Server : 33.0.6198.68 (rd_rdfe_stable.130710-0833) Microsoft-HTTPAPI/2.0

Body:

<?xml version="1.0" encoding="utf-16"?>

<Operation xmlns="https://schemas.microsoft.com/windowsazure" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">

    <ID><IdDaOperacao></ID>

    <Status>Succeeded</Status>

    <HttpStatusCode>200</HttpStatusCode>

</Operation>

Agora sim ele manda criar a VM:

DEBUG: ============================ HTTP REQUEST ============================

HTTP Method:

POST

Absolute Uri:

https://management.core.windows.net/<SubscriptionId>/services/hostedservices/<NomeDoSeuServico>/deployments

Headers:

x-ms-version : 2013-06-01

x-ms-client-id : <GuidDaChamada>

User-Agent : WindowsAzurePowershell/v0.6.16.1

Body:

<?xml version="1.0" encoding="utf-16"?>

<Deployment xmlns="https://schemas.microsoft.com/windowsazure" xmlns:i="https://www.w3.org/2001/XMLSchema-instance">

    <Name><NomeDoSeuServico></Name>

    <DeploymentSlot>Production</DeploymentSlot>

    <Label><NomeDoSeuServico></Label>

    <RoleList>

        <Role i:type="PersistentVMRole">

            <RoleName><NomeDoSeuServico>1</RoleName>

            <OsVersion i:nil="true"></OsVersion>

            <RoleType>PersistentVMRole</RoleType>

            <ConfigurationSets>

                <ConfigurationSet i:type="WindowsProvisioningConfigurationSet">

                    <ConfigurationSetType>WindowsProvisioningConfiguration</ConfigurationSetType>

                    <ComputerName><NomeDaSuaMaquina></ComputerName>

                    <AdminPassword><SuaSenha></AdminPassword>

                    <EnableAutomaticUpdates>true</EnableAutomaticUpdates>

                    <ResetPasswordOnFirstLogon>false</ResetPasswordOnFirstLogon>

                    <WinRM>

                        <Listeners>

                            <Listener>

                                <Protocol>Https</Protocol>

                            </Listener>

                        </Listeners>

                    </WinRM>

                    <AdminUsername><SeuUsuario></AdminUsername>

                </ConfigurationSet>

                <ConfigurationSet i:type="NetworkConfigurationSet">

                    <ConfigurationSetType>NetworkConfiguration</ConfigurationSetType>

                    <InputEndpoints>

                        <InputEndpoint>

                            <LocalPort>3389</LocalPort>

                            <Name>RDP</Name>

                            <Protocol>tcp</Protocol>

                        </InputEndpoint>

                        <InputEndpoint>

                            <LocalPort>5986</LocalPort>

                            <Name>WinRmHTTPs</Name>

                            <Protocol>tcp</Protocol>

                        </InputEndpoint>

                    </InputEndpoints>

                </ConfigurationSet>

            </ConfigurationSets>

            <DataVirtualHardDisks></DataVirtualHardDisks>

            <Label><NomeDaSuaMaquina></Label>

            <OSVirtualHardDisk>

                <MediaLink>https://<SuaContaDeStorage>.blob.core.windows.net/vhds/<NomeDoSeuServico>-<NomeDaSuaMaquina>-2013-7-22-11-59-58-332-0.vhd</MediaLink>

                <SourceImageName>a699494373c04fc0bc8f2bb1389d6106__Win2K8R2SP1-Datacenter-201306.01-en.us-127GB.vhd</SourceImageName>

            </OSVirtualHardDisk>

            <RoleSize>Small</RoleSize>

        </Role>

    </RoleList>

</Deployment>

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:

Accepted

Headers:

x-ms-servedbyregion : ussouth

x-ms-request-id : <IdDaOperacao>

Content-Length : 0

Cache-Control : no-cache

Date : Mon, 22 Jul 2013 15:00:02 GMT

Server : 33.0.6198.68 (rd_rdfe_stable.130710-0833) Microsoft-HTTPAPI/2.0

Body:

Novamente ele fica em um loop verificando o status da requisição, vou omitir aqui pq a chamada é muito parecida com a anterior, e finalmente finaliza a execução do script.

RG

Essa semana fiz a apresentação “Projetando aplicações para o Windows Azure” na trilha de Arquitetura .NET do evento TDC2013. Para quem tiver interesse, abaixo é possível encontrar o arquivo da minha apresentação.

RG

Hoje vou comentar sobre como criar uma VM no Windows Azure utilizando comandos PowerShell.

Neste post vou criar uma VM à partir de uma image. Eu também poderia utilizar um disco existente, mas vou deixar para outro post. Então, a primeira coisa à ser feita, é identificar qual a imagem que será utilizada. Para facilitar, o Windows Azure possui um cmdlet chamado Get-AzureVMImage, que traz a lista de todas as imagens que podem ser utilizadas. Devemos utilizar o conteúdo do retorno da propriedade ImageName para indicar qual imagem será utilizada na criação da nossa VM.

Devemos em seguida, criar uma nova configuração de VM através do cmdlet New-AzureVMConfig. Para este comando, devemos informar o nome da máquina, seu tamanho e o nome da imagem que deve ser utilizada.

O próximo passo é adicionar informação de provisionamento do sistema operacional, indicando se é uma imagem Windows ou Linux, como também nome do usuário administrador e sua senha.

Por último, efetivamos a criação da VM através do cmdlet New-AzureVM, informando o nome do Cloud Services e também sua localização. Abaixo vemos um script completo de criação de uma VM utilizando os cmdlets acima através da estrutura de pipe do PowerShell:

#Get-AzureVMImage | Select ImageName

$imageName = "a699494373c04fc0bc8f2bb1389d6106__Win2K8R2SP1-Datacenter-201306.01-en.us-127GB.vhd"

$user = "<SeuUsuario>"

$password = "<SuaSenha>"

New-AzureVMConfig -Name "<NomeDaSuaMaquina>" -InstanceSize "Small" -ImageName $imageName |

Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $password |

New-AzureVM -ServiceName "<NomeDoSeuServico>" -Location "East US"

Uma variação desse script pode ser a criação de uma segunda máquina no mesmo Cloud Service, onde deve ser informado o nome da VM, o mesmo nome de Cloud Service e deve ser omitido o parâmetro de localidade, afinal o Cloud Service já existe. Uma possibilidade interessante pode ser o uso do parâmetro –WaitForBoot, onde o PowerShell somente retornaria depois que a VM estivesse no ar.

#Get-AzureVMImage | Select ImageName

$imageName = "a699494373c04fc0bc8f2bb1389d6106__Win2K8R2SP1-Datacenter-201306.01-en.us-127GB.vhd"

$user = "<SeuUsuario>"

$password = "<SuaSenha>"

New-AzureVMConfig -Name "<NomeDaSuaSegundaMaquina>" -InstanceSize "Small" -ImageName $imageName |

Add-AzureProvisioningConfig -Windows -AdminUsername $user -Password $password |

New-AzureVM -ServiceName "<NomeDoSeuServico>" –WaitForBoot

Além disso, também seria possível realizar outras configurações na VM, como adicionar discos através do cmdlet Add-AzureDataDisk ou endpoints utilizando o cmdlet Add-AzureEndpoint.

RG