Tenho a sorte e o infortúnio de ter que escalar o meu local Drupal imediatamente. Está a ficar mais tráfego do que posso acomodar, por isso os próximos passos de escala têm de ser dados.

Acho que o site estava funcionando bem no Drupal 9. Mas eu melhorei para Drupal 10 e ficou muito, muito lento. Agora, eu não vou voltar para Drupal 9, mas é outro ponto de conversa e outra razão para não atualizar. Como eu escrevi sobre antes, nós gostamos de manter nossa pilha magra, então ao atualizar para uma próxima versão principal (1) não traz nenhum benefício perceptível, e (2) aumenta o consumo de recursos - nós realmente perguntamos se vale a pena. O que não é. Muitas vezes não vale a pena melhorar.

Seguindo em frente, vamos percorrer os passos que estou tomando para abordar problemas de desempenho e melhorar o desempenho geral do site.

Um primeiro passo que estou a dar é reconstruir o site com ansible. Isso significa escrever e configurar playbooks e papéis ansible para instalar o site em um SO nu. Estou a usar o Docker para isto internamente. Diria que é uma grande tarefa. Ainda assim, sinto-me muito mais confortável com infra-estrutura-como-código do que se eu não tenho esta capacidade. Então, vamos andando!

Tentarei também open-source a maioria do meu código enquanto avançamos. O código ansible está disponível aqui: https://github.com/wasya-co/wasya co ansible.git Se você não consegue encontrar nenhum do código que eu mencionei, ou acreditar que ele não tem sido open-sources e você gostaria de uma cópia - entre em contato comigo diretamente. Nota: `master` branch é quase nunca mais recente. O melhor ramo a usar é o ramo alfabeticamente mais recente.

Nota: Estou usando minhas próprias imagens docker, como piousbox/php83:0.0.2 Você pode conectar sua própria imagem, ou pm me se a minha não funcionar no nosso caso ou você precisar de algo específico, como outro módulo de apache.

Eu estarei trabalhando em meu site mais popular, https://piousbox.com Agora, após alguns dias, eu tenho o playbook que instala o site funcionando: playbooks/setup all drupal site.yml e você precisa de todos os valores de configuração para estar em vars/.yml ou algo similar. Você pode executá-lo com:

   ansible-playbook -i inventory/aws.yml -e @vars/piousbox_com.yml \ 
     --limit aws4 playbooks/setup_all_drupal_site.yml    -vv

Depois que eu escrevi, eu descobri que eu quero re-escrever para que eu possa solucionar a instalação localmente sem ansible. Isto é, embora eu queira conduzir tudo isto com ansible, quero ter a certeza de que funciona antes. A maneira de fazê-lo é empacotar o aplicativo como um projeto docker-compose. Assim, dividi https://github.com/wasya-co/docker drupal.git do ansible repo.

Claro, então eu posso ter que ter dois sistemas templating, para valores de configuração plugin. Isto já é realmente possível e eu pensei que a sobrecarga não é muito grande. No projeto docker drupal.git tenho scripts/update all , sripts/update dc (para docker-compose.yml) e scripts/update settings - esses scripts tomam um modelo e substituem valores .env no modelo.

Em seguida, reescrevo o papel ansible para, em vez de colocar cada arquivo necessário no servidor, colocar o repo docker drupal.git lá, e template-substitute alguns arquivos. Isso me permite conduzir automação com e sem ansible.

O projeto inclui uma base de dados mysql. Eu acredito que é a base de dados que é o gargalo de desempenho, mas eu também quero ter certeza, e eu quero ter a ferramenta para solucionar esses problemas precisamente no futuro.

Então, para simplificar as coisas, eu empacotei todos os meus temas e módulos drupal como módulos reais para o compositor. Anteriormente, eu iria git-checkout o que eu precisava de minhas próprias bases de código, no entanto, com o aumento da automação o método mais fácil tornou-se apenas incluir tudo no arquivo composer.json, que eu fiz. o docker drupal.git/compose.json tem os detalhes e é um exemplo de fazer isso. (Eu uso tags de versão semântica, excel no meu formalismo 1.0.0 é sempre um branch, enquanto v1.0.0 é uma tag de versão. O v no início deixa claro que não é, de fato, uma versão, uma vez que o v não faz parte do formalismo semver.)

Eu então realmente reescrevi meu ansible workspace repo - ou melhor, decidi que as únicas coisas compartilháveis serão os papéis. Assim, cada papel ansible é open-source em seu próprio repo. Exemplo: wasya-co/wasya co ansible role.git E os playboors e variáveis e as instruções para executar, estão em outro lugar, provavelmente na documentação. Desta forma, eu não tenho que open-source meu espaço de trabalho ansible, e eu ainda tenho o benefício de open-sourcing todo o trabalho pesado, que está dentro dos papéis ansible.