Olá pessoal,
O objetivo deste post é compartilhar um cenário pelo qual passei esta semana, onde tive a necessidade de colocar alguns conceitos básicos em que – muitas vezes – vistos de forma isolada as pessoas não dão muita atenção, porém quando reunidos e colocados em prática podem lhe poupar tempo, trabalho, dinheiro e maiores problemas.
Cenário
Um website baseado em wordpress rodando no Azure e está configurado em modo Shared/Compartilhado com uma única instância.
Problemas
Novos recursos foram adicionados sem serem testados em um ambiente de teste/homologação, ocasionando a quebra de algumas funcionalidades e acesso ao Portal de Administração.
Como foi resolvido
1 – Algumas funcionalidades dentro do WebSites são oferecidas apenas quando está sendo executado em modo Standard, como por exemplo, o recurso de backup do WebSites onde basicamente o Azure compacta todo o seu projeto e armazena no Storage do Azure.
O que muitos não se atentam é que para se manter uma agenda de Backup constante você realmente precisa manter o site em modo Standard, porém por segurança nada te impede de alterar o modo em que o seu site está rodando temporariamente para Standard e executar o processo de Backup do seu ambiente.
Com isso em alguns minutos, no meu caso cerca de 15/20 minutos, antes mesmo de ter tido o problema relatado acima, eu executei a rotina de Backup e mantive uma cópia atualizada do meu ambiente.
2 – Após a mal sucedida atualização em um ambiente de produção, criei um slot vinculado ao meu projeto para que pudesse restaurar o conteúdo relacionado ao Backup previamente executado. Criando o slot isso me proporcionou ter um ambiente de homologação para poder restaurar o backup do meu ambiente, validar o conteúdo, funcionalidades, etc… utilizando um ambiente totalmente isolado.
3 – Para fechar após aprovar o “novo” ambiente, bastou utilizar o recurso de SWAP e alternar os ambientes, ou seja, no meu caso eu defini que o ambiente que anteriormente estava em produção fosse promovido para o ambiente/slot de staging/homologação e o slot de staging (ambiente restaurado) fosse promovido para produção.
Feito isso consegui ter novamente o meu ambiente em produção rodando como se deve e na sequencia ter a tranquilidade de excluir o slot utilizado temporariamente para restaurar o conteúdo do backup e retornar meu WebSite para o modo compartilhado.
Nota: Como o WebSIte é cobrado por hora, o fato de eu ter alterado para o modo Standard e executado a rotina terei um custo adicional à minha conta de aproximadamente R$0,34 (o custo por hora é R$0,17 por hora para uma máquina de tamanho small, como mantive 2 ambientes terei o custo relativo a ambos) e mais alguns centavos referentes ao armazenamento do backup.
Conclusão
Pequenas ações e cuidados podem lhe poupar tempo, dinheiro e problemas com o seu ambiente e clientes. Portanto conheça todas as funcionalidades possíveis com os recursos do Azure que esteja utilizando, analize quais as oportunidades que você possui para poder criar o melhor cenário de Custo X Benefício e que atenda a todas as necessidades da sua demanda. Não importa se a sua necessidade seja básica como um simples processo de Backup executado manualmente ou até mesmo a construção de um cenário de alta disponibilidade rodando múltiplas instâncias em diversas regiões e integrados com outros recursos do Azure ou externos…. pesquise, estude e implemente!
Links de referência:
- Azure Websites Backups: http://azure.microsoft.com/en-us/documentation/articles/web-sites-backup/
- To Add a Deployment Slot to a Website: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#Add
- About Configuration for Deployment Slots: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#AboutConfiguration
- To Swap Deployment Slots: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#Swap
- To Delete a Site Slot: http://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/#Delete
Divirtam-se e sucesso a todos!
No Comments