A implantação alterando o link simbólico afetará as solicitações em execução no momento?

Empacotar conteúdo como um diretório, como você sugere, tem a vantagem de facilitar o versionamento, o arquivamento, a instalação e a reversão.

Não é necessário alterar o caminho do conteúdo na configuração httpd. A intenção de servir a versão atual do aplicativo implantado não mudou. A atualização de diretórios de conteúdo em servidores httpd acontece o tempo todo.

Minimizar o tempo de transição ajuda a reduzir a janela de distorção de versão onde apenas alguns arquivos são diferentes. O uso de links simbólicos torna as trocas atômicas possíveis, não estritamente necessárias, mas também podem tentar uma transição limpa.

ln -s /var/www/build-1 /var/www/current
ln -s /var/www/build-2 /var/www/new/current
mv /var/www/new/current /var/www/current

(Ou excho programa a partir do util-linux 2.40 pode trocar diretórios reais atomicamente, mas é somente para Linux.)

Em sistemas POSIX, em geral, arquivos abertos que são removidos continuam abertos. Os identificadores de arquivo são por inode, não por nome. No entanto, essa é a versão antiga. Qualquer coisa de execução longa deve ser informada de alguma forma para fechar o que eles abriram.

PHP é relevante para os detalhes de implementação. Muitas instalações hoje em dia são processos php-fpm separados. Enviar o sinal USR2 recarregará graciosamente os workers e sua configuração. Leia a documentação do seu gerenciador de serviços para saber como enviar isso, como no systemd Linux systemctl reload

Recarregar o servidor http também pode ser necessário. Quando ele serve conteúdo estático diretamente. Para linguagens em processo como httpd com mod_php. Para alterações de configuração. Mesma coisa, geralmente há um sinal de recarga elegante.

Alta disponibilidade é o design e a implementação do que você quer que seja sua meta de tempo de atividade. Uma recarga elegante de php-fpm e nginx pode causar apenas um breve sinal de falha no serviço quando os novos workers são iniciados. Por si só, isso pode ser bom para alguns casos de uso. No entanto, mesmo que as atualizações de conteúdo quase não causem tempo de inatividade, eventualmente será necessária uma reinicialização para atualizações de software. Se esses poucos minutos de tempo de inatividade da infraestrutura forem um problema para sua organização, mesmo a recarga mais elegante não é uma solução de HA completa.

Iniciar vários servidores http e colocá-los atrás de um balanceador de carga é um padrão descrito em todo lugar. Colocá-los em hosts diferentes evita que uma variedade de falhas interrompa o serviço completamente, melhorando o tempo de atividade. Além disso, torna-se possível drenar todas as conexões de um processo e fazer qualquer manutenção nele quando quiser.

Alguns desses métodos de implantação pretendem que diferentes versões sejam executadas ao mesmo tempo. Disciplina durante o desenvolvimento ajuda, especialmente para recursos compartilhados ou APIs. Talvez haja uma oportunidade de reestruturar consultas de banco de dados na versão 2. Um período de transição em que o banco de dados pode fazer consultas da versão 1 ou 2 torna a implantação mais fácil. A instalação e o recarregamento contínuos, um backend de cada vez, levam algum tempo para verificar um número tolerável de erros. Fácil de colocar a versão 1 de volta ou concluir a instalação da 2.

Para serviços de alta disponibilidade, alternar o symlink pode causar problemas com solicitações ativas referenciando diferentes builds. Recarregar o Nginx é uma abordagem melhor para implantações com tempo de inatividade zero.