Como gerir eficientemente várias instalações de uma aplicação web?

https://stackoverflow.com/questions/502774

20-08-2019
|

Pergunta

Da minha experiência, um dos maiores problemas nos deparamos durante nosso processo de webdevelopment está mantendo diferentes configurações atualizados e seguros em diferentes servidores.

Minha empresa tem seu próprio CMS que atualmente está instalado em toda 100+ servidores. No momento, nós usamos uma abordagem baseada em FTP corte-ish, combinado com scripts de atualização em locais específicos para atualizar todos os nossos setups CMS. Eficientemente gerenciar essas configurações se torna cada vez mais difícil e arriscado quando existem vários módulos personalizados envolvidos.

Qual é a melhor maneira de manter várias configurações de uma aplicação web segura e up-to-date?
Como você fazê-lo?
Existem algumas dicas específicas sobre modularidade em aplicações, a fim de manter a flexibilidade para com os nossos clientes, mas ainda assim ser capaz de gerir de forma eficiente vários "galhos" de uma aplicação?

Algumas informações contextuais: desenvolvemos principalmente na LAMP-stack. Um dos principais fatores que nos ajuda a vender o nosso CMS é que podemos plugin de praticamente qualquer coisa que nosso cliente quer. Isto pode muito dos 10 aos de 10.000 linhas de código personalizado.

Um monte de trabalhos por encomenda consiste em muito pequenos pedaços de código; gestão de todos esses pequenos pedaços de código no Subversion parece muito tedioso e ineficiente para mim (desde que entregar cerca de 2 sites a cada semana, isso resultaria em um muito de ramos).

Se há algo que eu estou com vista, eu adoraria ouvir isso de você.

Agradecemos antecipadamente.

Roundup: em primeiro lugar, obrigado por todas as suas respostas. Todos estes são realmente útil.

A mais provável usar uma abordagem baseada em SVN, o que torna benlumley 's solução mais próxima do que vou usar . Desde que a resposta a esta pergunta pode ser diferente em outros casos de uso, eu vou aceitar a resposta com a maioria dos votos no final da corrida.

Por favor examinar as respostas e voto para os que você acha que tem o maior valor acrescentado.

Solução

Acho que usando um sistema de controle de versão e "ramificação" da parte dos códigos que você tem que modificar poderia vir a ser a melhor abordagem em termos de robustez e eficiência.

Um sistema de versão distribuída poderia ser mais adequado para suas necessidades, uma vez que permitem que você atualize o seu "core" apresenta sem problemas em diferentes "ramos", mantendo algumas mudanças local, se necessário.

Editar: eu tenho certeza que manter tudo o que até à data com um sistema de versão distribuído seria muito menos tedioso do que aquilo que parecem esperar: você pode manter as mudanças que você está certo 'nunca vamos precisar de outro lugar local, e os meios de aspecto distribuídos cada um de seu aplicativo implantado na verdade é independente dos outros e só a correção que você quer dizer para propagar irá propagar.

Outras dicas

Se a personalização de seu aplicativo envolve mudar muitas peças pequenas de código, isso pode ser um sinal de que o design do seu aplicativo é falho. Sua aplicação deve ter um conjunto de código do núcleo estável, pontos de extensibilidade para bibliotecas personalizadas para ligar a, a capacidade de aparência mudança usando modelos, ea capacidade de mudança de comportamento e instalar plugins usando arquivos de configuração. Desta forma, você não precisa de um ramo SVN separado para cada cliente. Em vez disso, manter o código do núcleo e extensão plug-in bibliotecas no controle de origem como normal. Em outro repositório, crie uma pasta para cada cliente e manter todos os seus modelos e arquivos de configuração lá.

Por enquanto, criando ramos SVN pode ser a única solução que ajuda você a manter sua sanidade. Em seu estado atual, é quase inevitável que você vai cometer um erro e atrapalhar site de um cliente. Pelo menos com ramos que você está garantido para ter uma base de código estável para cada cliente. A única pegadinha com ramos SVN é se você mover ou renomear um arquivo em um ramo, é impossível para mesclar que a mudança de volta para o tronco (você teria que fazê-lo manualmente).

Boa sorte!

EDIT: Para um exemplo de um aplicativo bem projetado usando todos os princípios que descrevi acima, consulte Magento E-Commerce . Magento é o mais poderoso, extensível e fácil de personalizar aplicativo web Eu tenho trabalhado com até agora.

Posso estar errado, mas parece-me que Aron é depois é não controle de versão. Versionamento é grande, e eu tenho certeza que eles estão a usá-lo já, mas para gerenciar atualizações em centenas de instalações personalizadas, você precisa de algo mais.

Estou pensando em algo ao longo das linhas de um sistema de pacotes construído propositadamente . Você vai querer todas as versões de um módulo para manter o controle de suas dependências individuais e 'compatibilidades garantidos', e usar essas informações para atualizar automaticamente apenas os módulos 'seguros'.

por exemplo. Digamos que você tenha construído uma nova versão 3 do seu módulo 'Wiki'. Você deseja propagar a nova versão para todos os servidores executando o seu aplicativo, mas você tiver feito alterações para uma das interfaces dentro do módulo Wiki desde a versão 2. Agora, para todas as instalações padrão, isso não é problema, mas que iria quebrar instalações com extensões personalizadas no topo da interface antiga. Um sistema de pacotes bem planejada iria cuidar disso.

Para abordar a questão de segurança, você deve olhar para usar assinaturas digitais em seus patches. Há muitas boas bibliotecas disponíveis para assinaturas baseadas-chave pública, então, basta ir com o que parece ser o padrão para sua plataforma escolhida.

Não tenho certeza se alguém disse isso, há uma série de respostas longas aqui, e eu não lê-los todos.

Eu acho que a melhor abordagem para o seu controle de versão seria a de ter o seu CMS sentou-se em seu próprio em seu próprio repositório e cada projeto em seu próprio. (Ou, tudo isso poderia ser subpastas dentro de um repo eu acho)

Você pode então usar seu tronco (ou um ramo / tag específica, se você preferir) como um svn: external em cada projeto que exige. Desta forma, todas as atualizações feitas no CMS pode ser comprometida de volta ao seu repositório, e será puxado para outros projetos como e quando eles são svn atualizada (ou o externo é svn: switch 'ed).

Como parte de fazer isso mais fácil, você precisa ter certeza de que o CMS eo sit funcionalidade personalizada em pastas diferentes, de modo que externals svn funciona corretamente.

IE:

project
 project/cms <-- cms here, via svn external
 project/lib <-- custom bits here
 project/www <-- folder to point apache/iis at

(você poderia ter cms e lib na pasta www se necessário)

Isso permitirá que você ramo / tag cada projeto como desejar. Você também pode alternar o svn:. Local externo em uma base por ramo / tag

Em termos de obtenção de mudanças vivo, eu sugiro que você imediatamente se livrar de ftp e usar rsync ou svn checkout / exportações. Ambos funcionam bem, a escolha é até você.

Eu tenho mais experiência com a rota rsync, rsyncing uma exportação svn para o servidor. Se você enveredar por este caminho, escrever alguns scripts shell, e você pode criar um shell script de teste para mostrar-lhe os arquivos que ele irá carregar sem enviá-las bem, usando o sinalizador -n. Eu geralmente uso um par de roteiros para cada ambiente -. Um teste, e um para realmente fazê-lo

A autenticação de chave compartilhada para que você não precisa de uma senha para enviar uploads-se também pode ser útil, dependendo de como proteger o servidor para ser dado o acesso é.

Você também pode manter outro script shell para fazer atualizações em massa, que simplesmente chama o script shell relevantes para cada projeto que você deseja atualizar.

Você já olhou para Drupal? Não, não implantar e substituir o que você tem, mas para ver como eles lidam com personalizações e módulos específicos do site?

Basicamente, há uma pasta "locais" que tem um diretório para cada site que você está hospedando. Dentro de cada pasta é uma settings.php separado que permite que você especifique um banco de dados diferente. Finalmente, você pode (opcionalmente) têm "temas" e "módulos" pastas dentro de sites.

Isso permite que você para fazer personalizações específicas do local de módulos específicos e limitar certos módulos para esses sites. Como resultado, você acaba com um site que a grande maioria de tudo é perfeitamente idênticos e somente as diferenças se duplicado. Combine isso com a maneira como ele lida com atualizações e upgrades e você pode ter um modelo viável.

Construir no código um processo de auto-atualização.
Ele irá verificar se há atualizações e executá-los quando / onde / como você configurou-lo para o cliente.

Você terá que criar algum tipo de uma lista de módulos (personalizado ou não) que precisam ser testados com a nova compilação antes de roll-out. Ao implantar uma atualização você terá que garantir que estes sejam testados e integrados corretamente. Esperemos que o seu projeto pode lidar com isso.

As atualizações são idealmente alguns passos importantes.

a) Backup para que possa voltar para fora. Você deve ser capaz de voltar atrás toda a atualização a qualquer momento. Assim, que significa a criação de um arquivo local do pedido e da base de dados em primeiro lugar.

b) Atualização processo de monitoramento -. Ter o telefone de casa sistema de CMS para procurar uma nova compilação

c) Agendamento de atualização da disponibilidade - Provavelmente, você não quer que a atualização para executar o segundo estiver disponível. Isto significa que você terá que criar um cron / agente de algum tipo para fazer a atualização do sistema automaticamente no meio da noite. Você também pode considerar os requisitos do cliente para atualizar nos fins de semana ou em dias específicos. Você também pode cambalear lançando suas atualizações para que você não atualizar 1000 clientes em um dia e obter tecnologia inferno apoio. Escalonada roll-out de algum tipo pode ser benéfica para você.

d) Adicionar modo de manutenção para atualizar o site -. Chute o site em modo de manutenção

e) SVN checkout ou pacotes para download - idealmente você pode implantar via svn checkout, e se não, a configuração do seu servidor para entregar pacotes svn gerados em um arquivo que pode ser implantado em sites de clientes.

f) Scripts Deploy DB - Faça backup dos bancos de dados, atualizá-los, preenchê-los

g) Atualizar código do site -. Todo este trabalho para um passo

h) Executar alguns testes nele. Se o seu código tem auto-testes integrados, seria ideal.

Aqui está o que eu faço ...

específica do cliente caminho de inclusão

Shared, código comum é em / current_version / lib /
código específico do site está em clientes / foo.com / lib
O caminho de inclusão é definido para incluir a partir dos clientes / foo.com / lib , e em seguida, share / lib
A coisa toda está em um sistema de controle de versão

Isso garante que os usos de código de arquivos compartilhados, sempre que possível, mas se eu precisar substituir uma determinada classe ou arquivo, por algum motivo, eu posso escrever uma versão específica do cliente em sua pasta.

Alias ??arquivos comuns

A minha configuração de host virtual irá conter uma linha como

Alias /common <path>/shared/current_version/public_html/common

O que permite que os elementos comuns de interface do usuário, ícones, etc, para ser compartilhados entre projetos

Tag do código comum com cada lançamento do site

Depois de cada lançamento site, eu marcar o código comum através da criação de um ramo para congelar eficazmente naquele momento. Isso me permite implantar / shared / version_xyz / para o servidor ao vivo. Então eu posso ter um uso host virtual uma versão específica dos arquivos comuns, ou deixá-lo apontando para o current_version se eu quero isso para pegar as últimas atualizações.

Você já olhou para ferramentas como Puppet (para a administração do sistema incl. Implantação app) ou < a href = "http://www.capify.org/" rel = "nofollow noreferrer"> Capistrano (implantação de aplicativos em RubyOnRails mas não se limitando a estes)?

Uma opção seria a criação de um sistema de controle de versão só de leitura (Subversion). Você poderia integrar o acesso ao repositório em seu CMS e invocar as actualizações através de um menu, ou automaticamente, se você não quer que o usuário tem uma escolha sobre uma atualização (poderia ser crítico). Usando um sistema de controle de versão também permite que você mantenha diferentes ramos facilmente

Como as pessoas já mencionamos que o uso de controle de versão (eu prefiro Subversion devido à funcionalidade) e ramificação seria a melhor opção. Outro software de fonte aberta disponível no SourceForge chamado cruisecontrol. Sua incrível, você configure cruisecontrol com a subversão em sach uma maneira que qualquer modificação do código ou novo código adicionado na serversion, Controle de velocidade saberá automaticamente e fará construir para você. Ele vai salvar o seu inferno de tempo.

Eu tenho feito da mesma maneira em minha empresa. temos quatro projetos e tem que implantar esse projeto em servidores diferentes. Eu tenho cruiseconrol configuração de tal forma que qualquer modificação na base de código dispara construção automática. e outro script vai implantar essa configuração no servidor. o seu é bom para ir.

Se você usar uma pilha LAMP Eu definitivamente transformar os arquivos de soluções em um pacote de sua distribuição e usá-lo para alterações propagar. Eu recomendo para que o assunto Redhat / Fedora por causa de RPM e é o que eu tenho experiência em. De qualquer forma você pode usar qualquer distribuição baseada no Debian também.

Algum tempo atrás eu fiz uma solução LAMP para o gerenciamento de um ISP servidores de hospedagem. Eles tinham vários servidores para cuidar de hospedagem na web e eu precisava de uma maneira de implantar as alterações do meu gerente, porque cada máquina era auto-suficiente e teve um gerente online. Fiz um pacote RPM que contém os arquivos de solução (PHP principalmente) e alguns scripts Implantando que Gerido com o RPM.

Para a atualização automatizada tivemos nosso próprio conjunto repositório RPM em cada servidor yum.conf. Eu definir um trabalho crontab para atualizar os servidores diariamente com as últimas RPMs de que repositório confiável.

trustiness pode ser atingir também, porque você pode usar as configurações de confiança nos pacotes RPM, como assiná-los com o seu arquivo de chave pública e aceitar somente os pacotes assinados.

Hm poderia ser uma idéia para adicionar arquivos de configuração? Você escreveu que um monte de pequeno script está fazendo algo. Agora, se você construí-los em fontes e os guiou com arquivos de configuração que não deve "facilitar" isso?

Nos outros ramos mão ter para cada cliente se parece com um crescimento exponencial para mim. E como você "saber" quais as áreas que você fez alguma coisa e não se esqueça de mudanças "make" em todos os outros ramos também. Que se parece muito feio para mim.

Parece uma combinação de controles de revisão, opções de configuração e / ou recibos de implantação parece ser um "bom" ideia .....

Com que muitas variações sobre o seu software núcleo, eu acho que você realmente precisa de um sistema de controle de versão para ficar em cima de empurrar alterações do tronco para os locais do cliente individual.

Então, se você acha que o Subversion seria tedioso, você tem um bom senso para o que os pontos de dor será ... Pessoalmente, eu não recomendo Subversion para isso, uma vez que não é realmente tão bom em administrar e rastreamento ramos. Embora a sugestão de benlumley para externos de uso para o seu software de núcleo é uma boa, Isso quebra se você precisa ajustar o código do núcleo para seus sites de clientes.

Olhe em Git para controle de versão, ele é construído para ramificação, e é rápido.

Confira Capistrano para gerenciar suas implementações. É um script ruby, muitas vezes usado com Rails, mas pode ser usado para todos os tipos de gerenciamento de arquivos em servidores remotos, até mesmo sites não-rubi. Ele pode obter o conteúdo para a extremidade remota através de vários stragegies incluindo ftp, scp, rsync, assim verificando como automaticamente a versão mais recente do seu repositório. O agradável recursos que ele oferece incluem ganchos de retorno de chamada para cada etapa do processo de implantação (por exemplo, para que você possa copiar os arquivos específicos do local de configuração que pode não estar em controle de versão), e um sistema de log lançamento - feito através de links simbólicos - assim você pode rapidamente reverter para uma versão anterior em caso de problemas.

Eu recomendo um arquivo de configuração com a lista de ramos e sua localização hospedado, em seguida, executar por isso com um script que verifica a cada ramo, por sua vez e carrega as últimas alterações. Isso poderia ser cron'd fazer atualizações noturnas automaticamente.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow