Carregamentos com tempo de inatividade zero / Reversão no IIS

Question

Não tenho certeza se esse é o jeito certo de fazer essa pergunta, mas basicamente o que eu gostaria de fazer:

1.) Enviar um conjunto de alterações para um site no IIS.
2.) Não interrompa os usuários.
3.) Ser capaz de reverter sem esforço.

Então, há algumas coisas que eu sei que precisam acontecer:

1.) Sessão fora do processo - manipulado
2.) Fora do cache Proc - manipulado

Então as perguntas que permanecem:
1.) Como eu evito interromper os usuários? Se eu apenas enviar os arquivos para o lixo, o aplicativo recicla e leva mais de 10 segundos para voltar a ficar online | 2.) Como faço para retroceder sem esforço?

Eu estava pensando que uma possível solução seria ter dois sites configurados no IIS, um público e outro privado. Os uploads vão para o privado e são aquecidos. Após o aquecimento, os sites são trocados. Uma reversão envolve apenas a troca para privado sem um upload.

Isso parece sólido em teoria, mas não tenho certeza da mecânica. Alguma idéia?

    

Answer 1

Aqui está como eu abordaria esse problema - lembre-se de que eu não fiz isso antes, são apenas conceitos que testei um pouco no meu ambiente de desenvolvimento. Você deve ser capaz de configurar uma estrutura bastante robusta usando isso e alguns scripts no idioma de sua escolha. Basicamente, vamos configurar um ambiente de balanceamento de carga do gueto e usá-lo para alternar entre o novo site e o site antigo.

Para configurá-lo, você precisará:

• Módulo Roteamento de solicitação de aplicativo do IIS (ARR)
• Ferramenta Implantação do IIS na Web (msdeploy)
• 3 sites do IIS diferentes (com 3 endereços IP diferentes - apenas o uso de portas ou cabeçalhos de host pode não funcionar aqui)

Instale o ARR para começar.

Configure os 3 sites no IIS:

• O site 1 será o site em que seus usuários realmente se conectam, digamos http://192.168.1.1/ . Este é também o site da ARR. Basta configurar um diretório vazio para o qual apontar e colocá-lo em seu próprio pool de aplicativos. Configure o pool de aplicativos para não expirar o tempo de acordo com estas instruções .
• Os sites 2 e 3 serão os sites que realmente hospedam seu conteúdo. Eles precisam estar em seus próprios IPs e devido a como o ARR funciona, em uma porta diferente do website 1. Digamos que eles sejam http://192.168.1.2:8080 e http://192.168.1.3:8080 . Eles também devem estar em seus próprios pools de aplicativos e apontar para diretórios diferentes no sistema de arquivos (mas ambos os diretórios possuem o mesmo conteúdo normalmente)

Depois de instalar o ARR, haverá uma nova categoria no Gerenciador do IIS chamada "Farms de servidores" - clique com o botão direito do mouse e crie um novo farm.

• dê um nome que seja significativo para você
• adicione Webserver 2 e Webserver 3 como os servidores - certifique-se de clicar no botão "advanced settings", abra a categoria "applicationRequestRouting" e altere o httpPort para 8080 para cada servidor
• Conclua o assistente - você será perguntado se deseja criar regras de regravação de URL - clique em Sim
• Agora você tem um farm de servidores - para concluir a configuração, vá até o farm e clique no botão Configuração do proxy - ative "host de reconfiguração reversa nos cabeçalhos de resposta" e aplique as alterações
• No Gerenciador do IIS, vá para a categoria do servidor de nível raiz e clique no botão URL Rewrite. Haverá uma regra criada para o farm
  • clique duas vezes na regra para acessar as configurações
  • abra a caixa Condições
  • adicione uma nova condição para {SERVER_PORT} não corresponder a 8080
  • aplicar as alterações

Neste ponto, você tem o básico sobre o que precisamos para realizar sua solicitação. Se você for para http://192.168.1.1/ , você obterá o seu website do Website 1 ou do Website 2, mas será completamente perfeito que existam outros sites.

Agora, o que você pode fazer quando quiser implantar uma nova versão do seu aplicativo é:

• drenar 1 dos servidores em seu farm (nas ferramentas de farm de servidores, vá para "Monitoramento e gerenciamento", escolha um servidor e escolha "Tornar servidor indisponível indisponivelmente")
• implemente sua nova versão do site no sistema que está off-line
• aquecer o site que está off-line usando seu IP / porta alternativo
• disponibilize o site para a fazenda novamente
• repita o processo para o outro servidor

A ferramenta Web Deployment entra em cena quando você fala sobre querer fazer script de tudo isso. Isso torna super fácil criar um pacote para seu aplicativo e implantá-lo a partir da linha de comando. Você também pode reverter esse pacote facilmente se houver problemas. O ARR também é programável por script usando o Microsoft.Web.Administration dlls.

Uma outra coisa - se você está realmente no Windows 2008 R2 (que é o IIS 7.5), dê uma olhada no Warmup de aplicativo módulo - deve facilitar também o aquecimento desta parte de você.

    

Answer 2

MattB bateu na água. + Eu responderei com mais detalhes, mas não quero tirar os pontos dele. Eu adicionarei ao que ele disse.

Eu tenho uma configuração semelhante ao que ele descreveu e funciona muito bem. O ARR é o caminho a percorrer, mesmo em um único servidor.

No entanto, algumas coisas eu adicionaria.

Crie os dois sites, como Matt recomendou. Chame-os de algo como yoursite.com01 e yoursite.com02.

Crie duas regras de reescrita de URL. Um para www.seudominio.com e mais um staging.yourdomain.com. Para produção, use {HTTP_HOST} com um valor de (^ www.yourdomain.com $) | (yourIP). (ou qualquer ligação que você preferir) Para teste, use {HTTP_HOST} com um valor de (^ staging.yourdomain.com $). Ligue para as regras yoursite.com e staging.yoursite.com.

Regra de vinculação = yoursite.com para o site = yoursite.com01 e rule = staging.yoursite.com para o site = yoursite.com02.

Configure o FTP no staging.yoursite.com.

O tráfego de produção agora está indo para Rule = staging.yoursite.com e Site = yoursite.com01. Stagging para o oposto.

Você pode implantar a plataforma em qualquer ponto, teste, pré-spin-up, teste de outras pessoas, etc. Faça isso durante o dia, não importa. Implante na mesma conta de FTP a cada vez. Funciona muito bem com servidores de compilação.

Então, quando você estiver pronto para ir ao vivo, faça 3 alterações: - Mover a ligação FTP de yoursite.com02 para yoursite.com01 - altere a regra de regravação de URL yoursite.com para apontar para yoursite.com02 - altere a regra de regravação de URL staging.yoursite.com para apontar para yoursite.com01

Agora você tem zero tempo de inatividade, troca instantânea, com funcionalidade imediata de retrocesso!

Sua única pegadinha a considerar é o seu estado de sessão fora do processo. Certifique-se de que seu servidor de estado aceite os dois códigos de site para que você não perca o estado da sessão durante a troca.

Observe também que isso é apenas da web e não do banco de dados.

Para scripts, use o Editor de configuração. Faça as alterações desejadas e clique em "Gerar Script". Ele lhe dará código C #, appcmd ou AHAdmin.

Eu tive isso por alguns meses com um front-end de página para trocar instâncias e nunca olhei para trás. Isso torna as implantações tão atualizadas em comparação às implantações tradicionais.