Configurando o Tomcat na unidade compartilhada para ambiente em cluster

Question

Temos um ambiente de produção com servidores Tomcat com balanceamento de carga externo sendo executados em vários servidores, atendendo a solicitações HTTP e mantendo sessões em espera.

Devido à falta de um processo completo de desenvolvimento e implantação (infelizmente não vejo isso em nenhum lugar no futuro próximo!), há uma equipe de operações, que é responsável por copiar arquivos JSPs / Classes / recursos estáticos / propriedades ou até mesmo alterando struts-config.xml (às vezes web.xml!) manualmente. Nós não construímos WARs!

Como o trabalho manual é intensivo, um erro humano cria muitos problemas, pois as mesmas etapas devem ser executadas em vários ambientes (em um dia de implementação, pelo menos 10 máquinas) e isso torna a depuração complicada.

Eu entendo que estamos longe do ambiente de produção ideal (até mesmo para ambientes de produção práticos), mas eu estava apenas pensando e se pudéssemos instalar (copiar) o Tomcat em SAN de alta velocidade e montá-lo como um compartilhamento compartilhado unidade em cada servidor para que, pelo menos, as alterações vão para todos os nós simulatenously.

Por favor, deixe-me saber seus pensamentos e críticas especialmente nesta abordagem.

Obrigado.

    

Answer 1

Embora seja possível compartilhar alguns dos diretórios em uma implantação do Tomcat (consulte esta questão ), não é seguro compartilhar os que você está querendo compartilhar, e embora possa funcionar se você tomar o cuidado de localizar o ./work e ./temp diretórios, você está pedindo problemas para solucionar problemas se você tentar, sem mencionar a introdução de um ponto único de falha em sua infraestrutura.

Como desenvolvedor, tenho a sorte de trabalhar de perto com meus desenvolvedores e desenvolvi implantações automatizadas para vários aplicativos complicados e confusos. Meu conselho nessa área é que, se você conseguir que sua equipe compre o objetivo de automatizar sua implantação, comece pequeno e automatize um pouco mais a cada iteração, à medida que sua equipe de desenvolvimento e sua equipe de operações se acostumarem com o processo e trabalhe as torções.

Para minha recomendação sobre o problema exato aqui, se for possível montar uma única unidade compartilhada em suas máquinas de produção, a melhor solução provavelmente será manter uma imagem canônica da configuração do tomcat na unidade compartilhada, e, em seguida, escreva alguns scripts (que podem ser simples) para atualizar todos ou parte dos tomcats implantados em cada servidor de aplicativos quando forem feitas alterações. Isso facilitaria a implantação gradual das alterações (se você fizer isso), abortar as alterações que não estão funcionando e verificar se tudo está sincronizado em todos os servidores de aplicativos.

Se seus desenvolvedores pudessem obter acesso de gravação a essa unidade compartilhada, você poderia até mesmo ajudar os funcionários do ops removendo o processo de edição propenso a erros e apenas precisando pedir a eles que implementassem arquivos ou diretórios específicos. Uma vez que você tenha implementado a infraestrutura e o processo, você pode começar a automatizar as coisas: os desenvolvedores podem gravar os scripts de automação e salvá-los na unidade compartilhada para que os ops funcionem e construírem a partir daí.

    

Answer 2

Não estou no tomcat, mas talvez eu possa compartilhar o que estou fazendo para tarefas semelhantes:

1. Apenas prepare a pasta com todas as atualizações (como eu posso ter seed12/etc/apache2/apache2.conf e seed12/var/www/index.php ) - somente os arquivos que você atualizou, colocados nas pastas correspondentes, sempre começando pelo root.

2. Em seguida, crie um script simples que use scp -r para todas as máquinas. Você pode adicionar ao script alguns comandos ssh para reiniciar seus serviços, se necessário.

Uma vantagem extra é que é um pouco auto-documentável - apenas mantenha as pastas "seed" e, assim, tenha log de todas as alterações.

Quanto à crítica (você perguntou!) à sua abordagem - ela adiciona um ponto de falha desnecessário em sua configuração redundante.

    

Answer 3

Você não quer fazer isso, ele pode migrar tudo de uma vez, o registro seria complicado e os rollbacks ficarão confusos. Use a jóia do assassinato para distingui-lo.