Dois pools de aplicativos ou diretórios virtuais raiz em um site

Question

Isso pode soar como uma pergunta muito idiota, então deixe-me primeiro dizer o que eu quero alcançar e, em seguida, respondo à minha pergunta sobre como eu imaginaria algo assim trabalhando.

Estou tentando implantar de forma transparente o aplicativo da Web no IIS (sem interromper usuários ou conexões ativas).

A maneira que imagino esse trabalho é ter dois diretórios virtuais raiz compartilhando o mesmo site. Por diretório virtual raiz, quero dizer aquele que o IIS cria internamente e atribui à raiz de cada site ou aplicativo da web; exceto aqui, eu quero ter dois desses vdirs raiz (cada um vinculado ao seu próprio pool de aplicativos, mas ambos referenciando exatamente o mesmo aplicativo de pastas diferentes ). Durante a operação normal, um dos vdirs estaria inativo.

Ao fazer uma implantação, colocaria o novo código em outra pasta referenciada pelo segundo vdir (inativo) e, em seguida, marcaria como ativo. O que eu quero realizar é o IIS começar a enviar todas as conexões novas (solicitando o mesmo site) para o segundo vdir com o novo código, mas mantendo o antigo também vivo & ativo até que todas as conexões restantes estejam inativas (algumas, como uploads de arquivos, podem ser executadas por muito tempo). Depois que todas as conexões remanescentes estiverem inativas, o antigo conjunto de vdir / app se tornará inativo e o segundo com o novo código se tornará o único ativo.

Espero que isso faça sentido.

Se isso não acontecer, aqui está minha tentativa alternativa de explicá-lo com um exemplo.

--- Web Site ("mysite.com")
    --- Root VDir#1 (IIS Internal, App Pool: AppPool#1, Virtual Path: /, Physical Path: C:\inetpub\MySite.v1084\). ACTIVE
    --- Root VDir#2 (IIS Internal, App Pool: AppPool#2, Virtual Path: /, Physical Path: NONE). INACTIVE

Durante uma implantação, o VDir2 # do Root se tornaria ativo e seu Caminho Físico mudaria para C: \ inetpub \ MySite.v1085. Esse seria o vdir padrão que o IIS serviria para todas as novas conexões. Uma vez que todas as sessões / conexões ativas com o Root VDir # 1 morrem, isso se torna inativo.

É algo assim possível? Existem maneiras alternativas de fazer algo assim (eu sei que há alguma forma de balanceamento de carga interno no IIS ("Web Farms"?), Mas não estou muito familiarizado com ele).

    

Answer 1

O que você está propondo soa como uma troca A / B. ( Pergunta semelhante )

Existe uma ferramenta addin do IIS da Microsoft chamada Web Deploy . Ele automatizará a maioria dos movimentos físicos de implantação de código atualizado no IIS, mas sua necessidade de migração contínua é o ponto de fixação, pois você tem transações de arquivos de longa duração. A melhor maneira de lidar com isso é obter um balanceador de carga, executar duas instâncias de produção do seu site ao mesmo tempo e ter uma terceira instância para atualizações de teste.

(BTW, o Azure está fazendo algo assim com o "Cloud Services" - há um comando "Swap" para fazer exatamente isso).

Voltando à sua configuração específica, considere esta configuração:

Uma máquina do IIS, dois sites. Web Site A e Web Site B. Eles não apontam para os mesmos arquivos. Eles têm suas próprias pastas. O site A está on-line e atende a usuários em produção, enquanto o Site B está off-line. Quando você estiver pronto para atualizar, você atualiza o Site B, depois troca On / Off Web Site A. Agora B está online e A está offline. Esta é uma rotação A / B. Mais tarde, quando você fizer sua próxima atualização, atualize A e, em seguida, ative / desative com B. Agora, A está on-line e B está off-line.

Nesse exato momento, quando você troca, existe a possibilidade de perder tráfego - (e você provavelmente vai matar essas transferências de arquivos), mas se o seu aplicativo estiver com volume baixo, talvez ninguém perceba (você decide). No entanto, se isso for de missão crítica, alto volume, site - obtenha um balanceador de carga e use-o como os outros descreveram.

O que o WebDeploy não fará, (até onde eu sei) é o site A e o site B de troca / desativação. Para isso, você precisará escreva um script e faça isso na linha de comando .

O benefício dos scripts do Web Deploy + é que você pode eventualmente automatizar isso e talvez vinculá-lo a um sistema de implantação contínua.

As transferências de arquivos de longa duração são provavelmente impossíveis de salvar com essa configuração. Outro desafio é qualquer estado de memória do seu aplicativo. Se o seu aplicativo da Web foi criado com dados na memória, você o perderá quando fizer a troca A / B. Se os programadores estiverem usando a sessão, você poderá ativar o serviço da sessão. Os dados da sessão não estarão no mesmo processo com o restante do aplicativo e poderão sobreviver à troca A / B. Converse com seus programadores sobre como o aplicativo gerencia dados na memória. Talvez não tenha realmente nenhum. Talvez ele possa ser facilmente recriado assim que o aplicativo for recarregado - (por exemplo, reconstruindo um cache do banco de dados)