Olá pessoal, tudo bem?
Vamos ao objetivo Choose a deployment strategy for a Windows Azure web application, que fala de conceitos de deploy voltados para o Azure.
Fazendo In-Place Upgrade E VIP Swap
Em casos de web farm, o Azure oferece 3 maneiras de atualizar sua aplicação: deletando e redeployando, In-Place Upgrade e VIP Swap.
Deletar seu cloud service e redeployar é fácil, mas requer um downtime para seu serviço. Você deve usar essa opção em casos de mudança de número de endpoints, porta, firewall, certificados, etc.
In-Place Upgrade
Para entender o In-Place Upgrade, é necessário entender os conceitos de Upgrade Domain e Fault Domain. Upgrade Domain é uma unidade lógica da sua aplicação, enquanto Fault Domain é uma unidade física.
Vamos supor que você precisa de 5 instâncias para sua aplicação. Automaticamente (isso não é controlável por você), o Azure vai distribuir cada instância entre o número de Upgrade Domains que você configurou no atributo upgradeDomainCount no arquivo Service Definition (valor padrão: 5, valor máximo: 20). Na hora do deploy da sua aplicação (In-Place Upgrade), o Azure atualiza um Upgrade Domain por vez, evitando downtime para o seu serviço.
Fault Domain, também automaticamente atribuído pelo Azure, é quando as instâncias são separadas em servidores físicos diferentes. Somente com 2 Fault Domains o Azure garante o SLA de 99.95%.
Para entender melhor esses conceitos, recomendo esse post: https://blog.tompawlak.org/windows-azure-fault-and-upgrade-domain. Vamos em frente.
Você tem 2 opções para disparar um deploy In-Place Upgrade. A primeira é diretamente pelo portal do Azure, fazendo o upload do pacote direto para seu Cloud Service. A outra é pelo Visual Studio, que necessita de um certificado emitido pelo portal para identificação:
Como dito antes, ao fazer um deploy, o Azure vai atualizar seus Upgrade Domains um por um. Então se você tiver mais do que 2 Upgrade Domains, no momento do deploy eles terão diferentes versões da sua aplicação. Isso pode ser um problema caso haja alterações no schema do banco de dados, por exemplo. Para resolver isso, existe uma técnica de deploy chamada VIP Swap.
VIP Swap
Um Cloud Service no Azure tem 2 ambientes: produção e staging. Ambos têm o mesmo hardware, diferenciando apenas o virtual IP (VIP) e a URL do serviço.
O VIP Swap é quando o VIP e a URL dos ambientes de produção e staging são trocados. Isso significa que você pode fazer o deploy da nova versão da sua aplicação no ambiente de staging, testá-la, e promovê-la para produção instantaneamente com o VIP Swap. Depois, você pode deletar o ambiente de staging para evitar custos.
Isso permite que você atualize todas as instâncias de uma só vez, evitando diferentes versões em produção ao mesmo tempo. Ainda vai haver requests que estão apontando para a versão antiga, mas o problema é bastante minimizado com essa técnica.
Para realizar um VIP Swap, primeiro você precisa fazer o upload da nova versão da aplicação para o ambiente de staging, seja por deletando o serviço e redeployando ou via In-Place Upgrade. Depois de validado, basta ir no portal do Azure no ambiente de staging e clicar no botão Swap:
Criando E Configurando Input E Internal Endpoints
Há dois tipos de endpoints para suas instâncias de Cloud Services: Input Endpoint e Internal Endpoint. Um Input Endpoint é usado para conexões externas (internet) feitas via HTTP, HTTPS ou TCP. Internal Endpoints são usados para conexões internas entre as instâncias do Cloud Services via HTTP ou TCP.
Seu Cloud Service pode ter 25 endpoints de cada tipo, que podem ser espalhados entre as roles. Quando você cria um projeto Cloud com uma web role e uma worker role, o arquivo ServiceDefinition.csdef fica assim:
A web role por padrão vem com um input endpoint na porta 80, padrão para conexões HTTP. A worker role não tem endpoints por padrão, mas você pode adicionar um input endpoint sem problemas:
<Endpoints>
<InputEndpoint name="WorkerRoleInput" port="8080" protocol="http" localPort="8080"/>
</Endpoints>
Agora o load balancer encaminha os requests na porta 8080 para a worker role. Dentro dela, você pode usar um HttpListener para lidar com os requests:
Um ponto importante é que no Windows Azure emulator, as portas são remapeadas para a próxima porta disponível, para evitar conflitos. Isso significa que a porta 80 será remapeada para 81 e a 8080 para 8081.
Você também pode editar as configurações de endpoint diretamente do Visual Studio, clicando duas vezes no nome da role no projeto Cloud Services:
Ao selecionar o tipo do endpoint, há uma terceira opção chamada InstanceInputEndpoint. Nela você pode especificar um range de portas externas que são mapeadas para uma única porta. A configuração fica assim:
<InstanceInputEndpoint name="Endpoint2" localPort="1000" protocol="tcp">
<AllocatePublicPortFrom>
<FixedPortRange min="10016" max="10020"/>
</AllocatePublicPortFrom>
</InstanceInputEndpoint>
O elemento InstanceInputEndpoint especifica a porta local para onde os requests serão direcionados e o protocolo, enquanto o elemento AllocatePublicPortFrom especifica o range de portas públicas que serão ouvidas.
Especificando Configurações Do Sistema Operacional
Quando você cria um projeto Cloud Services, há dois arquivos de configuração: o ServiceDefinition.csdef, que especifica as configurações do Cloud Service como um todo, e o ServiceConfiguration.cscfg para configurações específicas das roles, como o número de instâncias, configurações de diagnostics, certificados, etc.
Uma configuração importante para o exame é a especificação da versão do sistema operacional. Ao criar um novo projeto Cloud com uma web role e uma worker role, o arquivo .cscfg fica assim:
O atributo osFamily é o número da família do sistema operacional. A especificação completa das famílias e o suporte de cada uma delas pode ser vista aqui.
O atributo osVersion especifica exatamente a versão do Guest OS em que sua role vai rodar. O valor * significa sempre a última versão. Para colocar uma versão específica, o seguinte formato deve ser utilizado: WA-GUEST-OS-M.m_YYYYMM-nn, onde WA-GUEST-OS é um valor fixo, M.m é o número da versão, YYYY o ano, MM o mês e nn um número sequencial para diferenciar os releases.
Terminamos mais um objetivo 🙂
Obrigado pela leitura e fique de olho no próximo post, que será sobre o objetivo 5.3: Configure a web application for deployment.
Até mais!
Pingback: Certificação Microsoft 70-487: Developing Microsoft Azure and Web Services | Blogs da Lambda3()