Tag: conteudo-wp

Observando, analisando e cuidando do servidor.

Observabilidade é a palavra chave quando pensamos em manter um servidor wordpress sempre saudável e estável. É observando e analisando logs e dados em realtime que podemos entender e descobrir o que pode ser mudado, ou até mesmo o que está causando lentidões e gargalos.

O que podemos monitorar e analisar ?

Existe uma centena de ferramentas pagas e opensource no mercado com foco em monitoramento de infraestrutura e serviços e não vou julgar qual é a melhor, pois cada uma pode atender um projeto em um determinado momento da empresa.

Para monitoramento do Nginx, PHP, MySQL e Hardware, podemos utilizar ferramentas como:

• Nginx Amplify
• Zabbix
• Prometheus e Grafana
• Site24x7
• NewRelic
• Dynatrace
• Datadog
• Etc

Nesse capítulo vamos utilizar o Nginx Amplify para o LEMP , mas seria interessante você também utilizar o Site24x7 por exemplo, para monitoramento de Rede,Disco,RAM,CPU e Validade do SSL.

Se você possui um e-commerce, ou qualquer projeto que realmente precise de cuidados 24×7, recomendo pesquisar mais sobre NewRelic, Prometheus com Grafana e Datadog. Por possuírem mais recursos e opções para nossa observabilidade de infraestrutura.

Monitoramento com Nginx Amplify

O Nginx Amplify é uma ferramenta totalmente gratuita e bem intuitiva na verdade. Para começarmos a configura-lo precisamos realizar o cadastro no site oficial pois é por lá que vamos acompanhar nossos dashboards.

Primeiro passo: Cadastro

Acessem o site oficial e realizem o cadastro através do link: https://amplify.nginx.com/login

Segundo passo: Instalação do Agente

Assim que você realiza o cadastro, você vai cair em uma tela onde será solicitado que você instale o agente do Nginx Amplify no servidor. É através desse agente que o Enginx Amplify consegue coletar dados e estatísticas dos nossos serviços.

Você vai acessar o servidor via SSH e executar as etapas 2, 3 e após concluir a etapa 3, clicar em Continue no navegador.

Em seguida o Ngin Amplify vai aguardar pelos dados recebidos do agente, sugiro aguardar os minutos que é apresentado na tela.

Após alguns minutos, você vai ser redirecionado para uma segunda página, e é apresentado o passo a passo do que fazer para configurar o Nginx para enviar os dados para o Amplify. E é isso que faremos agora!

Integrando o Amplify no Nginx

Siga os passos indicados na imagem, exatamente na mesma ordem e clica em continuar após executar as etapas. Nesse momento o Nginx Amplify irá aguardar os dados enviados pelo agente a respeito do serviço Nginx no servidor.

Após alguns minutos, conforme o seu site vá recebendo requisições, você notará que os dados começarão aparecer na tela. O básico do que aparecerá são:

• Requests no nginx
• Conexões correntes
• Erros 400
• Erros 500
• Memória consumida pelo Nginx
• CPU consumido pelo Nginx

E se clicar no menu em Overview verá também um resumo bem legal sobre as estatísticas de uptime, requests, erros 5xx,

Integrando o Amplify no PHP-FPM

Agora vamos configurar o Nginx Amplify para coletar dados e estatísticas de consumo do PHP-FPM. No painel não temos o passo a passo facilitado, mas felizmente vou comentar todos os passos aqui para você.

Acesse o servidor via SSH, e abra o arquivo do pool fpm default, com o comando abaixo:

nano /etc/php/8.0/fpm/pool.d/www.conf

Procure a linha pm.status_path e descomente-a.

Salve o arquivo e reinicie o PHP.

/etc/init.d/php8.0-fpm restart

No Nginx Amplify, clique em Graph e em seguida php-fpm, depois de um tempo começará ver os dados chegando, como: conexões queue, conexões, processos, requests lentas, etc.

Integrando o Amplify no MySQL

O agente do Nginx Amplify também consegue coletar métricas e processos de bancos de dados MySQL, mas para isso precisamos realizar alguns passos para que possamos deixar isso funcionando.

1. Acesse o MySQL pelo terminal de comando com o usuário root

mysql -uroot -p

2. Crie um usuário para o agente

# defina uma senha em xxxxxx
CREATE USER 'amplify-agent'@'localhost' IDENTIFIED BY 'xxxxxx';
exit;

3. Logue agora com o usuário amplify-agent e veja se está tudo ok

mysql -u amplify-agent -p

show global status;

exit;

4. Agora precisamos adicionar um conteúdo ao arquivo de configuração para que o agente consiga se conectar ao banco e coletar as métricas. Abra o arquivo de configurações do agente com o comando abaixo:

nano /etc/amplify-agent/agent.conf

Agora adicione o conteúdo na última linha, e lembre de colocar a senha do usuário do agente que criamos nos passos anteriores em password.

[extensions]
..
mysql = True

[mysql]
#host =
#port =
unix_socket = /run/mysqld/mysqld.sock
user = amplify-agent
password = xxxxxx

5. Por fim, restarte o serviço do Nginx Amplify

service amplify-agent restart

Agora o Nginx Amplify começará a enviar dados e estatísticas do banco de dados para o painel, uma nova aba irá abrir no dashboard ao lado de PHP-FPM.

Dependendo do tipo de banco de dados, pode ser que os dados não serão enviados, recomendo a leitura do blog post abaixo:

LEMP Stack Performance Monitoring With Nginx Amplify on Ubuntu 20.04/18.04

Conclusão

É importante entendermos o que está acontecendo dentro do nosso servidor, principalmente visualizar as métricas a respeito dos serviços que estão sendo executados. Nesse capítulo utilizamos uma ferramenta gratuita, possui suas limitações, mas que pode ser de grande serventia.

No entanto, para uma observabilidade mais refinada e profissional, softwares como Dynatrace, Prometheus com Grafana, Site24x7 e outros, podem ser uma ótima solução para seus negócios.

Se você está acompanhando desde o primeiro capítulo o nosso projeto de implantação de um servidor ubuntu para hospedagem wordpress, já viu que temos o nosso ambiente pronto.

Nesse capítulo vamos implementar algumas mudanças no nginx com foco em segurança, no entanto, isso não quer dizer que você está livre de toda e qualquer ameaça de ataques, mas as configurações aqui apresentadas podem minimizar os impactos.

SSL

Proteção no SSL

Nosso site wordpress nesse momento já possui o certificado SSL instalado, isso foi feito no segundo capítulo. No entanto, alguns usuários podem ainda tentar se conectar no nosso site pelo protocolo HTTP, quando nós adicionamos a diretiva Strict-Transport-Security aos cabeçalhos de resposta do servidor, garantirá que todas as futuras conexões sejam feitas sempre com o protocolo HTTPS.

Para realizar o procedimento, edite o nginx.conf com o comando abaixo:

sudo nano /etc/nginx/nginx.conf

E adicione o conteúdo abaixo dentro do bloco http assim como a imagem abaixo

add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";

Salve o arquivo e de um reload nas configurações do Nginx com o comando:

service nginx reload

Agora acesse o site do Qualys SSL Test e realize um teste de qualidade do nosso SSL.

Performance do SSL

Normalmente uma conexão HTTPS consome e demanda bastante recurso do servidor em comparação a uma conexão simples HTTP. Isso ocorre por conta do procedimento de handshake adicional necessário ao estabelecer uma conexão.

Mas podemos adicionar em cache os parâmetros da sessão SSL, o que evitará um handshake para cada conexão HTTPS do usuário. Logo, podemos melhorar levemente um pouco mais a performance do servidor.

Abra o arquivo de configuração do nginx novamente

sudo nano /etc/nginx/nginx.conf

Na diretiva abaixo de SSL Settings, adicione o conteúdo abaixo:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

Agora faça um reload do Nginx para que as configurações entrem em vigor:

sudo service nginx reload

Tipos de Ataques e Segurança com Nginx

Cross-Site Scripting (XSS)

Uma das formas que você desenvolvedor pode lidar com o XSS é garantir a validação e limpeza correta de todas as entradas do usuário no seu código, principalmente as áreas de administração do WordPress. Mas sabemos que tudo vira um caos quando existem vários plugins e templates de terceiros, é complicado você manter isso seguro.

Uma das formas que temos para poder diminuir os riscos de ataques XSS é configurando o Nginx para fornecer cabeçalhos de resposta adicionais. Mas como assim?

Imagine que um atacante conseguiu incorporar um arquivo JS malicioso no código-fonte do seu blog/site, seja por meio de um form de comentários ou algo do gênero. Por padrão, o navegador acaba permitindo que esse arquivo externo seja executado no momento do acesso, e poderá infectar o visitante ou até mesmo minerar criptomoedas torrando a CPU do seu usuário.

Quando inserimos uma política de segurança de conteúdo, o que permite definirmos uma lista de permissões de fontes totalmente aprovadas por nós para carregar ativos (JS,CSS,HTML,etc), a coisa muda de cenário. Se o script não estiver na lista de aprovados, ele não poderá ser carregado no browser do seu usuário. Legal, não?

Criar uma política de segurança é bem complicado para falar a verdade, hora ou outra acabamos bloqueando algum recurso de um template ou plugin e desconfigurando nosso site, então fica em um cenário de tentativa e erro.

Clickjacking

Clickjacking é um tipo de ataque que engana o seu usuário para que ele realize uma ação sem que ele perceba (induz o usuário a clicar), e é realizado através de iframes em uma página.
Não sou especialista em segurança, mas você pode ler um artigo que explica como funciona detalhadamente esse tipo de ataque do Clickjacking.

No Nginx podemos mitigar um pouco esse tipo de ataque, desabilitando completamente a incorporação de iframes de terceiros adicionando o cabeçalho X-Xss-Protection no nginx.conf.

Fortalecendo a segurança do WordPress com Nginx

Abra o seu nginx.conf e adicione os cabeçalhos para que os tipos de ataques acima sejam mitigados. Também inclui alguns outros cabeçalhos, que vão nos ajudar a evitar uma série de outros ataques web.

add_header Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval';" always;
add_header X-Xss-Protection "1; mode=block" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "origin-when-cross-origin" always;
add_header Permissions-Policy interest-cohort=();

A medida que atualizarmos esse capítulo com novos tipos de ataques iremos atualizar também as configurações do Nginx.

Conclusão

Antes de configurarmos as diretivas de segurança no Nginx com foco no nosso site WordPress, o resultado de um teste e análise dos cabeçalhos resultava a seguinte nota de segurança:

Após configurarmos os cabeçalhos, os resultados obtidos são maravilhosos:

Desse modo constatamos que configuramos os cabeçalhos e que ao menos alguns ataques vão ser bem difíceis de serem feitos no nosso servidor wordpress. Se você quer analisar o seu site, acesse o site: https://securityheaders.com/

A importância dos Backups

Ao longo do tempo vivenciei diversos projetos e vi na prática a importância que um backup tem para solucionar um problema. Já vi de perto vários projetos terem de recomeçar do zero pelo falta de backups.

Problemas técnicos acontecem, hora ou outra uma invasão ou infestação de malwares podem ocorrer, principalmente em projetos WordPress que são muito visados por atacantes e nessas horas se você não tem um backup limpo, irá chorar.

Nesse capítulo vamos configurar rotinas de backups no nosso servidor WordPress para termos cópias de segurança do nosso site.

Configurando Backup WordPress

A nossa configuração de backups será executada 1x por dia durante 7 dias, e após os 7 dias o último backup mais antigo será removido, desse modo você sempre terá salvo no seu servidor wordpress os últimos 7 dias de backups.

Se seu WordPress é muito pesado e o armazenamento do servidor ficar lotado, diminua a retenção dos backups de modo que o seu servidor consiga armazenar os backups sem travamentos.

Exemplo: Seu servidor possui 100GB de armazenamento e você possui um WordPress com 12GB de arquivos. Se você configurar o backup com retenção de 7 dias, será consumido 7 dias * 12GB de backups + 12GB do site principal, que dará um total de 96GB consumidos. Então analise bem!

No nosso servidor, vamos criar um diretório personalizado para que os backups sejam armazenados dentro dele.

mkdir -p /var/www/backups

Agora vamos criar um script shell básico para que o backup seja executado de modo que os arquivos do nosso WordPress e o banco de dados sejam salvos.

nano /var/www/backup.sh

Insira todo o conteúdo abaixo dentro do script e salve-o.

#!/bin/bash

DIA=$(date +%Y%m%d%H%M%S)
DB_BACKUP=${DIA}_database.sql
ARQUI_BACKUP=${DIA}_wp.tar.gz

DB_NAME=$(sed -n "s/define( *'DB_NAME', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_USER=$(sed -n "s/define( *'DB_USER', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_PASSWORD=$(sed -n "s/define( *'DB_PASSWORD', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)
DB_HOST=$(sed -n "s/define( *'DB_HOST', *'\([^']*\)'.*/\1/p" /var/www/html/wp-config.php)

# Backup do banco de dados
mysqldump --add-drop-table -u$DB_USERNAME -p$DB_PASSWORD -h$DB_HOST $DB_NAME > /var/www/backups/$DB_BACKUP 2>&1

# Comprimindo backup da DB
gzip /var/www/backups/$DB_BACKUP

# Backup do diretorio do WordPress
tar -zcf /var/www/backups/$ARQUI_BACKUP /var/www/html

Para que você não fique “boiando” sobre como esse script trabalha, ele tem as seguintes particularidades:

• É executado como um script bash
• Configura uma variável DIA com a data atual para os backups
• Recupera automaticamente as credenciais do banco de dados, para que automação consiga se conectar no banco
• Utiliza o gzip para comprimir o backup da database e com isso ocupar menos espaço

Agora dê permissão de execução

chmod u+x /var/www/backup.sh

Agora vamos colocar esse script no crontab para que ele seja executado todos os dias de madrugada, para que ele seja executado exatamente no horário que queremos temos que ajustar o horário do nosso servidor.

No entanto, configuramos o horário do servidor no primeiro capítulo desde guia. Mas verifique se a hora está correta:

date

Se tudo estiver correto, abra o crontab com o comando abaixo

crontab -e

Agora adicione o conteúdo abaixo

0 5 * * * cd /var/www/; /var/www/backup.sh  >/dev/null 2>&1

Esse cronjob irá acessar o diretório onde o script está armazenado e será executado as 05h da manhã todos os dias da semana.

Sempre que desejar verificar os backups salvos, basta executar o comando abaixo

ls -l /var/www/backups

Configurando Limpeza Automática

Até aqui já configuramos nosso script e colocamos ele na crontab para que seja executado todos os dias. Mas ainda não configuramos uma maneira de limpar os backups antigos, caso contrário em pouco tempo nosso servidor irá travar por falta de espaço.

Para isso vamos adicionar uma linha no nosso script bash, logo no final do arquivo

nano /var/www/backups.sh

Em seguida insira o conteúdo na última linha, feche e salve o arquivo

rm -f /var/www/backups/$(date +%Y%m%d* --date='1 week ago')

Agora nosso script sempre deixará salvo os últimos 7 dias de backups salvos no nosso servidor WordPress.

Conclusão

Backup de hospedagem WordPress é fundamental para a segurança e retenção dos dados, em um desastre você terá uma cópia dos arquivos e poderá utilizar sempre que precisar.

Tarefas Cron

O WordPress tem suporte integrado para tarefas cron, o que permite que alguns processos sejam executados em segundo plano nos horários programados. Quando você instala o WordPress ele já vem com as seguintes tarefas agendadas:

• Atualizações automáticas do WordPress
• Verificações de versão do WordPress
• Verificações de atualizações de plugins e templates
• Publicação de postagens agendadas

No entanto todo esse sistema é falho, se seu site não receber ao menos 1 visita durante um período de tempo, nenhuma dessas tarefas são executadas. Para resolver esses problemas utilizamos o cron do próprio sistema operacional Linux.

Como o cron é executado como um daemon, ele será executado com base na hora do sistema do servidor e não exigirá mais que um usuário visite o site para que as tarefas agendadas sejam executadas no seu WordPress.

Antes de configurar o cron, desabilite o WordPress de utilizar o cron interno dele. Adicione o conteúdo abaixo no arquivo wp-config do seu WordPress:

define('DISABLE_WP_CRON', true);

Abra o crontab do servidor e configure as tarefas cron que serão executadas pelo sistema:

crontab -e

Não vou entrar em detalhes sobre a sintaxe do crontab , mas adicione ao final do arquivo a cron do WordPress para que seja executada a cada 5 minutos:

*/5 * * * * cd /var/www/html; /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1

Agora salve o arquivo para finalizar. Pressione CTRL + X seguido de Y e Enter. Alguns artigos na internet sugerem o uso de wget ou curl para acionar o cron, mas o uso do WP-CLI é recomendado.

Agora você configurou o cron do servidor para que execute as tarefas agendadas do WordPress.

Configurando envios de e-mail com SMTP Relay Mailjet

No nosso servidor de hospedagem wordpress não configuramos nenhum serviço referente a envio de e-mails. Se você precisa redefinir uma senha ou enviar newsletter, só será possível se configurarmos um SMTP Relay para que os emails sejam enviados.

O Mailjet possui um serviço de SMTP Relay muito bom, inclusive o plano gratuito nos possibilita enviar até 6 mil envios mensal, para projetos pequenos isso é mais do que suficiente.

Para configurar o Mailjet no seu WordPress siga os passos abaixo.

1- Cadastro no Mailjet

Acesse o site oficial e clique em Get Started e realize o seu cadastro. Após preencher todas as etapas, acesse seu e-mail para confirmar seu cadastro.

https://www.mailjet.com/

Após confirmar o seu cadastro, você verá uma tela como a imagem abaixo. Clique em Get started na imagem Developer.

Em seguida escolha a opção SMTP Relay e prossiga para a próxima etapa

Nessa tela você pode clicar em continuar, mais adiante configuramos as credenciais do nosso SMTP.

2. Configurando SMTP

Agora que a nossa conta já está criada e pré-pronta, precisamos configurar nosso domínio no Mailjet e configurar nossas credenciais.

Na mesma janela que você está, desça a página até encontrar a opção 3 e clique em Add and validade domain.

Na nova janela que foi aberta clique no botão Add domain, insira o seu domínio e clique em Continue.

Na próxima etapa você vai ter duas opções para poder validar que você é o proprietário do seu domínio. Você pode subir um arquivo de texto para a raiz do WordPress ou criar um registro TXT no DNS.

Para ser mais objetivo e rápido, vou criar o arquivo de texto na raiz do meu WordPress, exatamente com o nome do arquivo que destaquei em vermelho na imagem acima.

No diretório home do meu WordPress eu criei o arquivo com o comando abaixo

touch nome_arquivo

Agora clico em Check now para validar o domínio.

Se o domínio foi validado, você verá uma mensagem como a imagem abaixo:

Mas ainda não acabou nossas configurações, precisamos realizar as autenticações para o domínio com registros SPF e DKIM caso contrário nossos e-mails podem cair sempre na caixa de spam ou até mesmo ser recusados pelo servidor de destino.

Clique em Authenticate this domain, e agora sim temos as duas configurações a serem feitas no nosso DNS. O SPF e o DKIM!

Antes de mais nada clique no botão amarelo para que o registro SPF seja gerado, e em seguida você verá o conteúdo a ser adicionado no DNS.

Após adicionar os registros, aguarde alguns minutos ou até mesmo horas para a propagação do DNS, assim que tudo estiver propagado você verá uma tela igual a imagem abaixo e isso significa que nosso domínio está autenticado e pronto para utilizar o Mailjet.

E para finalizar, vamos criar as chaves de API do nosso SMTP para que possamos conectar o WordPress ao SMTP. Clique no menu inicial para voltar a página inicial:

Em seguida clique em Setup my SMTP

Agora clique em Retrieve your API credentials

Agora sim, clicamos em Generate Secret Key para gerar nosso par de chaves

Guarde os dados de API Key e Secret Key, sugiro copiar e guardar em um local seguro, e será com essas credenciais que vamos configurar no WordPress agora.

Configurando SMTP no WordPress

Para configurar o Mailjet no WordPress vamos utilizar um plugin bem conhecido, o WP Mail SMTP by WPForms. No menu de pesquisa de plugins apenas coloque o nome do plugin e realize a sua ativação.

Assim que ativado, precisamos configura-lo. Clique em Vamos começar, para dar início.

Esse plugin é bem interessante pois ele oferece compatibilidade com diversos provedores de SMTP Relay como Google, Sendgrid, AWS SES, Mailgun e Outlook.

No entanto, vamos escolher a opção Outro SMTP e clicar em Salvar e continuar.

Agora colocamos as informações do nosso SMTP Mailjet, como nome do host usuário e senha que são as credenciais de API que geramos. Basta preencher os dados corretamente como as imagens abaixo:

Host: in-v3.mailjet.com

Para finalizar, clique em Salvar e continuar, nas três telas seguintes. Na quarta tela clique em Pular esta etapa, e na última tela clique em Concluir configuração.

Agora podemos testar se o nosso WordPress está enviando e-mails corretamente através do Mailjet. Para isso, podemos realizar um envio de e-mail de testes utilizando o plugin que acabamos de instalar. Clique no menu superior em E-mail de teste

Insira o nome do e-mail para quem deseja enviar um e-mail de teste e clique em Enviar e-mail

Rapidamente recebi o e-mail na caixa de entrada

Podemos constatar e verificar que o nosso WordPress está enviando e-mails corretamente. Qualquer atividade que envolva notificações, envios de redefinições de senhas, ou o que for, o WordPress utilizará o SMTP configurado para envios.

Conclusão

Quando configuramos um servidor para hospedagem wordpress também temos que pensar nos envios de e-mail, caso contrário toda e qualquer notificação o WordPress não irá conseguir enviar.

O Mailjet é uma opção gratuita e que é bem interessante para projetos pequenos, para projetos maiores como lojas e grandes portais o AWS SES pode ser a melhor opção para envios de e-mail e newsletter.

Nossa hospedagem WordPress já está configurada com todos os serviços que o WordPress precisa para executar. Você inclusive pode escolher o que fazer agora:

1. Instalar um WordPress Default
2. Migrar um WordPress para o servidor

A primeira opção você pode realizar de diversas formas, mas como temos o WP-CLI instalado no nosso servidor, podemos utiliza-lo para instalar o WordPress. A segunda opção é bem simples, basta você ter o conteúdo físico do WordPress + Banco de dados e enviar para o servidor.

Instalando o WordPress

Para instalar o WordPress via WP-CLI no terminal, esteja logado com o usuário que você criou no primeiro capítulo deste guia. E siga os passos abaixo:

cd /var/www/html
rm -rf *

O comando abaixo irá realizar o download dos arquivos core do WordPress

wp core download

O próximo comando irá criar o arquivo wp-config com os dados do banco de dados que configuramos. Lembre de trocar as palavras em negrito pelos respectivos nomes e senha que você configurou.

wp core config --dbname=dbwordpress --dbuser=wpuser --dbpass=senha

Agora acesse seu site e prossiga com a instalação:

Após realizar os passos básicos de instalação você já vai ter seu WordPress funcional na sua hospedagem WordPress.

Conclusão

Nesse capítulo realizamos a instalação de um WordPress em nosso servidor.

No próximo capítulo vamos começar a otimizar o nosso servidor, e com isso ganhar bastante performance no nosso WordPress.

Cache de Conteúdo Nginx

No Nginx podemos realizar uma série de configurações, uma delas é o cache de conteúdo. Ao ativarmos o cache de conteúdo, nosso site WordPress vai ganhar muito poder de performance, pois irá reduzir drasticamente o tempo de resposta e como consequência irá melhorar a experiência do usuário.

Podemos dizer bem a grosso modo como isso funciona. Quando uma página ou o resultado de uma página entrar for processada pelo PHP e MySQL, o Nginx irá armazenar o resultado no cache do servidor, e quando um segundo acesso for feito, o nginx irá responder muito mais rápido com o conteúdo da página. Isso é válido se a página não sofrer nenhuma alteração. As vantagens são:

• Diminuição do consumo de CPU e RAM
• Potencialização no número de conexões simultâneas que o WordPress poderá atender

Para configurar o Cache Nginx siga os passos abaixo.

1. Crie um diretório para que o Nginx utilize para armazenamento de cache persistente e de as permissões para que o usuário consiga manipular arquivos dentro do diretório do cache.

sudo mkdir -p /etc/nginx/cache
chown -R alex:alex /etc/nginx/cache

2. Abra o arquivo do bloco de configuração nginx do nosso wordpress

sudo nano /etc/nginx/sites-available/default

3. Adicione a linha abaixo logo na primeira linha do arquivo

fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=wordpress:100m inactive=60m;

4. Agora precisamos informar ao Nginx para que ele não coloque certas páginas em cache, como por exemplo a página de login ou telas do administrador.

Adicione o conteúdo antes da linha #### Locations

set $skip_cache 0;

# POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
    set $skip_cache 1;
}   
if ($query_string != "") {
    set $skip_cache 1;
}   

# Don’t cache uris containing the following segments
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
    set $skip_cache 1;
}   

# Don’t use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
    set $skip_cache 1;
}

5. A seguir, adicione as seguintes diretivas dentro do bloco do php:

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_cache wordpress;
fastcgi_cache_valid 60m;

Ficará assim:

Salve o arquivo usando CTRL + X seguido de Y e Enter.

Por fim, adicione as diretivas abaixo no seu nginx.conf , logo abaixo da linha de logs.

sudo nano /etc/nginx/nginx.conf

##
# Cache Settings
##

fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header Fastcgi-Cache $upstream_cache_status;

Salve o arquivo usando CTRL + X seguido de Y e Enter, e reinicie o Nginx para validar todas as novas configurações.

sudo service nginx restart

Terceiro Benchmark: Nginx com Cache

Agora que já habilitamos o cache do Nginx, podemos fazer um terceiro teste de carga. Eu espero que agora o servidor utilize menos ou praticamente nada do PHP e MySQL, e apenas o Nginx que trabalhe fornecendo o conteúdo já armazenado em cache.

Ao analisar o gráfico do teste simulando novamente os 100 usuários, dessa vez os resultados foram surpreendentes. Conseguimos realizar 19.856 solicitações com sucesso, nenhum erro 400/400, nenhum timeout e nenhum erro de rede.

Como o conteúdo em cache estava sendo fornecido pelo Nginx, mesmo no pico máximo de 100 usuários o tempo de resposta ficou em média 151ms, muito abaixo dos primeiros testes que superavam

Observe que durante o teste o consumo de CPU ficou em média 11% 20% no máximo, o consumo de memória ficou em média 278M e 240M, e o Load Average praticamente zerado.

Nos processos do sistema vimos apenas o procsso do Nginx trabalhando rs.

Plugin de Cache Nginx para WordPress

Você precisa instalar um plugin no WordPress para que ele consiga limpar o cache do servidor sempre que uma atualização for feita. Felizmente existe um plugin gratuito que é o Nginx Cache, você pode instalar esse plugin e seguir para a configuração.

Uma vez que o plugin está instalado, você precisa ativa-lo e configura-lo. No WordPres clique em Ferramentas – Nginx Cache, e insira no Cache Zone Path o caminho do servidor onde o Nginx armazena o cache. Também habilite o Purge Cache para que ele limpe o cache sempre que algo for atualizado.

Por fim, salve e faça alguns testes mudando o título do WordPress ou alguma palavra em alguma página e veja se o conteúdo é atualizado corretamente.

Cache de Objetos com Redis

O cache de objetos armazena os resultados da consulta do banco de dados para que, ao invéz de executar uma mesma consulta em cada acesso do usuário, os resultados sejam servidos a partir do cache.

Isso também melhora consideravelmente o desempenho do WordPress, pois elimina a necessidade de consultas ao banco de forma desnecessária e consumindo recursos a toa.

O Redis é um software de código aberto e conhecido em todo o mundo, é o melhor software para essa finalidade. E é ele quem iremos instalar no nosso servidor WordPress.

Para instalar o Redis execute os comandos abaixo:

sudo apt install -y redis-server
sudo service php8.0-fpm restart

Você pode instalar o módulo Redis Nginx em seu servidor para executar um cache, mas para que o WordPress use o Redis como um cache de objeto, você precisa instalar um plug-in de cache de objeto Redis. 

Após o plugin for instalado e ativo, você precisa ativar o cache de objetos, basta clicar em Ativar o cache de objeto.

Se tudo estiver ok, você verá uma tela como a imagem abaixo:

Agora que o cache de objetos está ativo, o servidor pode ter um leve aumento no consumo de memória RAM uma vez que o Redis armazena cache na memória RAM e não no disco. No entanto, várias consultas que outrora seriam enviados direto para o banco, não vão mais precisar incomoda-lo na maioria das vezes.

Conclusão

Nesse capítulo vimos como configurar o Cache Nginx no servidor e o cache de Objetos com o Redis. Esses dois tipos de cache vão melhorar e muito o desempenho dos nossos projetos WordPress e manter uma estabilidade no nosso servidor.

No próximo capítulo vamos revisar tarefas cron e implementação uma solução de envio de e-mails no nosso WordPress.

Nos últimos anos possuir um site otimizado se tornou praticamente crucial para o sucesso de um projeto. Para atingir este fim é necessário uma série de otimizações, seja a nível de código, seja a nível de servidor para que nossa hospedagem WordPress tenha performance.

Nesse capítulo você vai aprender a otimizar levemente o Nginx e o PHP do servidor. No entanto, as otimizações realizadas nesse capítulo não podem ser generalizadas a todo e qualquer projeto, muito menos a todo e qualquer servidor, para cada projeto e cada servidor, valores diferentes são utilizados.

Partimos do principio que estamos trabalhando com um site simples de pequeno porte e um servidor de 2GB e 1 núcleo de CPU.

Primeiro Benchmark: Teste de Carga e Análise de Performance

Antes de iniciarmos as otimizações no Nginx e PHP, vamos fazer alguns testes de performance e capacidade de carga do servidor, para termos um antes e depois e poder conferir as melhorias realizadas.

É muito difícil simular um tráfego real, não existe uma ferramenta que simule um acesso real de um cliente, mas podemos testar mesmo que robotizado esse processo.

Teste de Carga 100 pessoas simultâneas

Nosso teste de carga vai simular a entrada de 100 usuários simultâneos começando desde o primeiro usuário até o centésimo, tudo isso durante 1 minuto. Os “usuários” irão realizar requisições na pagina inicial do nosso site.

Mesmo sem otimizações o nosso servidor consumiu menos de 400MB de RAM, no entanto o único núcleo de CPU ficou em 100% de uso, apesar que eu já esperava pelo fato de termos apenas um único núcleo. O Load averange não cresceu praticamente nada.

Já analisando o relatório do teste pude perceber que não tive nenhum erro 400/500 e nenhum timeout. Todas as solicitações foram realizadas com sucesso, e na prática todos os 100 usuários conseguiram ficar online sem que o servidor caísse.

O único ponto negativo foi o tempo de resposta, tivemos um Average de 3323ms, ou seja, quando os 100 usuários estavam ao mesmo tempo no site, toda e qualquer página poderia estar muito lenta para uma boa navegação.

E se analisarem o gráfico, enquanto o número de clientes entravam no site aumentava o average aumentava proporcionalmente.

Análise de Performance

Sabemos que um template WordPress dos modelos default são bem otimizados e leves, e é justamente assim que os sites deveriam ser. Sempre priorizando o máximo de leveza para o usuário. O teste que realizamos não faz muito sentido eu realizar novamente, pois praticamente tiramos 100/100 em tudo.

Vale deixar claro que a localidade do servidor VPS e do servidor do Gtmetrix que realizou o teste pode influenciar na nota.

Tendo esses dados em mente, vamos partir para as otimizações e comparar no final do capítulo os resultados.

Otimizando o Nginx

O Nginx possui um arquivo de configuração principal que está localizado em: /etc/nginx/nginx.conf. Nesse arquivo podemos configurar e definir várias opções de otimizações que vão instruir como o Nginx vai trabalhar e processar as requisições.

Por padrão o Nginx já possui um arquivo default, mas vamos remover todo o conteúdo dele e recria-lo bem personalizado. Para isso, acesse o arquivo e apague todo o conteúdo do nginx.conf

nano /etc/nginx/nginx.conf

Uma vez que foi apagado todo o conteúdo, copie e cole o conteúdo abaixo no arquivo de configuração do nginx. Mas lembre de alterar o usuário em negrito pelo usuário que você criou anteriormente.

user alex;
worker_processes auto;
pid /run/nginx.pid;
error_log /var/log/nginx/error.log crit;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 2000;   
        use epoll;   
        multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        keepalive_timeout 65;
        types_hash_max_size 2048;        
        server_tokens off;
        access_log off;
        sendfile on;   
        tcp_nopush on;
        tcp_nodelay on;
        server_names_hash_bucket_size 64;
        server_name_in_redirect off;
        reset_timedout_connection on;  
        client_body_timeout 15;   
        send_timeout 5;
        keepalive_requests 60;
        client_max_body_size   16M;
        

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;
        
        ##
        # `gzip` Settings
        #
        #
        gzip on;
        gzip_disable "msie6";

        gzip_vary on;
        gzip_proxied any;
        gzip_comp_level 6;
        gzip_buffers 16 8k;
        gzip_http_version 1.1;
        gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
       
        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;


        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}

Salve o arquivo usando CTRL + X seguido de Y e Enter. E não esqueça de reiniciar o nginx:

sudo /etc/init.d/nginx restart

No vídeo onde gravamos a aula deste capítulo eu explico melhor sobre as diretivas que fazem parte desde arquivo de configuração e as otimizações que realizamos para garantir o máximo de performance.

Otimizando o PHP e PHP-FPM

Ajustes no PHP.INI

O PHP.INI é um arquivo de configurações do PHP, possui diretivas de como o PHP deve trabalhar e se comportar em relação ao uso de memória RAM, módulos e extensões instaladas, límites de usos e execuções, uploads e muito mais.

No geral, ele possui configurações que vão funcionar bem para projetos pequenos, mas pensando em projetos wordpress precisamos realizar minimamente algumas alterações visando otimizar nosso PHP.

Localize o arquivo php.ini e realize as seguintes alterações:

nano /etc/php/8.0/fpm/php.ini

post_max_size = 80M
upload_max_filesize = 80M
date.timezone = America/Sao_Paulo
max_execution_time = 600
max_input_vars = 1000
memory_limit = 256M
max_input_time = 600

Procure linha por linha e altere os valores, caso uma linha não exista, insira no final do arquivo. Você pode pesquisar por uma determinada palavra digitando no terminal CTRL + W , nome da diretiva e Enter.

Explicação:

• post_max_size: Configura o tamanho máximo dos dados postados. Esta configuração também afeta o upload de arquivos.
• upload_max_filesize: Tamanho máximo de um arquivo suportado no upload.
• date.timezone: Configura o fuso horário padrão utilizado por todas as funções de data e hora em um script
• max_execution_time: Isso configura o tempo máximo, em segundos, que um script é permitido executar antes de ser terminado.
• max_input_vars: Configura quantas variáveis de entrada serão aceitas, com o limte aplicado a cada super global $_GET, $_POST e $_COOKIE separadamente).
• memory_limit: Define a quantidade máxima de memória em bytes que um script pode alocar. Isto ajuda a prevenir que scripts mal escritos consumam toda a memória disponível no servidor.
• max_input_time: Configura o tempo máximo, em segundos, que um script é permitido dispender interpretando dados de entrada, como GET e POST.

PHP-FPM

O PHP-FPM é um gerenciador de processos que gerencia e trabalha com o FastCGI SAPI (Server API) em PHP. Ele funciona como um serviço independente, e pode ser utilizado em qualquer servidor web que seja compatível com o FastCGI, ex: Nginx.

Em servidores de hospedagem WordPress, o PHP-FPM deve ser otimizado visando garantir um pouco mais de performance para que um site WordPress consiga operar sem muitos esforços, uma vez que o WordPress é um CMS que pode rapidamente ficar denso e pesado.

Para o PHP-FPM precisamos otimizar o pool do PHP, que está localizado em:

nano /etc/php/8.0/fpm/pool.d/www.conf

Servidor com 1GB de RAM: (O PHP pode consumir até 512M de RAM, e só será usado se precisar)

pm = ondemand
pm.max_children = 2
pm.process_idle_timeout = 5s

# Comente as linhas abaixo para não quebrar seu FPM
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Servidor com 2GB de RAM: (O PHP pode consumir até 1G de RAM, e só se precisar)

pm = ondemand
pm.max_children = 5
pm.process_idle_timeout = 5s

# Comente as linhas abaixo para não quebrar seu FPM
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 3

Servidor com 4GB de RAM: (O PHP pode consumir até 2.5G de RAM, no entanto mesmo sem uso já consome recursos, modelo indicado para lojas e portais)

pm = dynamic
pm.max_children = 10
pm.start_servers = 5
pm.min_spare_servers = 1
pm.max_spare_servers = 5

Salve o arquivo usando CTRL + X seguido de Y e Enter.

Otimização OPCACHE

O OPcache melhora o desempenho do PHP armazenando bytecode de script pré-compilado na memória compartilhada, eliminando assim a necessidade do PHP carregar e analisar scripts em cada solicitação.

Para configurarmos o desempenho do PHP utilizando o opcache realize os passos abaixo:

nano /etc/php/8.0/fpm/conf.d/10-opcache.ini

Insira o conteúdo abaixo:

zend_extension=opcache.so
opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 4
opcache.max_accelerated_files = 60000
opcache.max_wasted_percentage = 5
opcache.use_cwd = 1
opcache.validate_timestamps = 0
opcache.validate_root= 1
opcache.file_update_protection = 2
opcache.revalidate_path = 0
opcache.save_comments = 1
opcache.load_comments = 1
opcache.fast_shutdown = 1
opcache.enable_file_override = 0
opcache.optimization_level = 0xffffffff
opcache.inherited_hack = 1
opcache.max_file_size = 0
opcache.consistency_checks = 0
opcache.force_restart_timeout = 60
opcache.error_log = "/var/log/php-fpm/opcache.log"
opcache.log_verbosity_level = 1
opcache.preferred_memory_model = ""
opcache.protect_memory = 0

Salve o arquivo usando CTRL + X seguido de Y e Enter. E reinicie o PHP:

/etc/init.d/php8.0-fpm restart

Segundo Benchmark: Teste de Carga

Agora que já otimizamos o nosso Nginx e PHP, podemos partir para um segundo teste de carga no servidor.

Esse segundo teste o servidor consumiu levemente alguns megas de RAM a menos, e o consumo de CPU e Load Average praticamente iguais ao teste anterior.

Já o relatório de carga também foi bem parecido, a diferença é que dessa vez os 100 usuários tiveram uma leve diminuição no tempo de resposta e consequentemente conseguiram realizar mais solicitações na página.

Se eu mudasse a quantidade de usuários no teste para números como 300/500/1000 usuários, os dados poderiam ser bem diferentes. Mas estamos baseando em projetos pequenos que poderiam ter até 100 usuários.

Conclusão

Nesse capítulo realizamos uma série de otimizações no Nginx, PHP, FPM e Opcache.

No próximo capítulo vamos continuar nossas otimizações, mas agora ativando o cache e você vai ficar impressionado com os resultados de um bom cache configurado no servidor.

No capítulo 1 do nosso guia, apresentei etapas iniciais para configuração e segurança de um servidor na Vultr com Ubuntu 20:04 para hospedagem WordPress. Neste capítulo, vou te guiar pelo processo de configuração do LEMP (Linux, Nginx, MySQL e PHP), como também instalarmos o SSL com Let’s Encrypt em nosso domínio.

Antes de prosseguir, já realize a conexão SSH no seu servidor utilizando o usuário criado no capítulo 1, caso não esteja com o terminal aberto.

Instalando o Nginx no Ubuntu

O Nginx é disparado um dos web servers mais rápidos que temos, e seu poder de processar milhares de requisições e conexões é surpreendente. Quando pensamos em uma hospedagem WordPress logo pensamos no Nginx, uma vez que performance e velocidade se tornou cada vez mais um fator determinante em projetos web.

Para instalarmos o Nginx vamos utilizar o repositório de pacotes mantido por Ondřej Surý que inclui os pacotes estáveis ​​mais recentes do Nginx.

Para instalar o Nginx, primeiramente adicione o repositório e atualize as listas de pacotes:

sudo add-apt-repository ppa:ondrej/nginx -y
sudo apt update
sudo apt dist-upgrade -y

Agora instale o Nginx:

sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Você pode verificar a versão do Nginx executando o comando:

nginx -v

Agora o Nginx está instalado em nosso servidor. E pelo menos nesse capítulo não vamos realizar nenhuma configuração avançada, isso será feito nos próximos capítulos onde iremos otimizar e realizar alguns ajustes para ter uma maior performance no nosso WordPress.

Instalação do PHP 8

Para instalarmos o PHP 8 em nosso servidor WordPress vamos utilizar novamente o repositório mantido por Ondřej Surý.

Adicione o repositório e atualize as listas de pacotes:

sudo add-apt-repository ppa:ondrej/php -y
sudo apt update

Agora instale o PHP 8 e todas as extensões do PHP que o WordPress precisa para executar corretamente.

sudo apt install php8.0-fpm php8.0-common php8.0-mysql \
php8.0-xml php8.0-xmlrpc php8.0-curl php8.0-gd \
php8.0-imagick php8.0-cli php8.0-dev php8.0-imap \
php8.0-mbstring php8.0-opcache php8.0-redis \
php8.0-soap php8.0-zip php8.0-intl -y

Note que estamos instalando também o php-fpm. FastCGI Process Manager (FPM) é uma implementação alternativa do PHP FastCGI com alguns recursos adicionais que funcionam muito bem com o Nginx. É o gerenciador de processos recomendado para usar ao instalar o PHP com Nginx.

Configurando o PHP 8 e PHP-FPM

Agora que temos instalado o Nginx e o PHP 8 precisamos configurar o usuário e o grupo sob o qual o serviço será executado. Para essa tarefa, precisamos alterar o arquivo de configuração de pool padrão do PHP.

sudo nano /etc/php/8.0/fpm/pool.d/www.conf

Altere todas as linhas que contém o usuário www-data, para o nome de usuário que você criou no capítulo 1.

user = www-data
group = www-data

listen.owner = www-data
listen.group = www-data

user = alex
group = alex

listen.owner = alex
listen.group = alex

Agora salve o arquivo para finalizar. Pressione CTRL + X seguido de Y e Enter.

Podemos agora reiniciar o nosso PHP 8 com o comando abaixo:

sudo service php8.0-fpm restart

Testando o Nginx e PHP

Nesse momento já podemos realizar um teste rápido para verificar se o Nginx está se comunicando corretamente com o PHP. Para isso, vamos editar o arquivo de configuração do nginx e habilitar os scripts PHP.

sudo nano /etc/nginx/sites-available/default

Encontre a seção onde os scripts PHP são configurados:

# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
#       include snippets/fastcgi-php.conf;
#
#       # With php-fpm (or other unix sockets):
#       fastcgi_pass unix:/run/php/php8.0-fpm.sock;
#       # With php-cgi (or other tcp sockets):
#       fastcgi_pass 127.0.0.1:9000;
#}

Podemos alterar deixando assim:

# pass PHP scripts to FastCGI server

location ~ \.php$ {
       include snippets/fastcgi-php.conf;

       # With php-fpm (or other unix sockets):
       fastcgi_pass unix:/run/php/php8.0-fpm.sock;
}

Salve o arquivo usando CTRL + X seguido de Y e Enter.

Agora altere o usuário que o nginx irá utilizar, pois isso vai tornar o gerenciamento de permissões muito mais tranquilo no futuro.

sudo nano /etc/nginx/nginx.conf

E troque o nome do usuário configurado no arquivo pelo usuário que você configurou:

user alex;
worker_processes auto;
pid /run/nginx.pid;

Salve o arquivo usando CTRL + X seguido de Y e Enter.

Reiniciamos o Nginx:

sudo service nginx restart

Vamos criar um arquivo de PHP simples na raiz da nossa hospedagem WordPress:

sudo nano /var/www/html/info.php

E inserimos o conteúdo abaixo para que quando acessemos pelo IP no navegador, possamos verificar todas as diretivas e informações do PHP. A execução desse arquivo corretamente significará que o PHP está em execução e em comunicação com o Nginx.

<?php
phpinfo();
?>

Salve o arquivo usando CTRL + X seguido de Y e Enter.

Agora abra o navegador e insira o IP ou o nome do host configurado para visualizar o conteúdo:

ip_server/info.php
ou
wpserver.seudominio.com/info.php

Depois de testar e ver que está funcionando bem, você pode excluir esse arquivo, por motivos de segurança, pois ele expõe informações sobre o servidor.

rm -r /var/www/html/info.php

Emitindo SSL com Let’s Encrypt

Para emitir certificados SSL com o Let’s Encrypt é necessário que você tenha configurado os apontamentos de DNS para o IP do seu servidor. Na CloudFlare eu configurei o apontamento de um subdomínio, pois irei instalar o WordPress em um subdomínio:

Se você vai instalar o WordPress no seu domínio principal, em Nome digite apenas “@”, ou edite a linha onde o seu domínio está apontado para um IP e insira o IP do seu servidor contratado. Lembre também de desativar a nuvem de Proxy, por default ela estará com a cor laranja.

Agora que você configurou o apontamento, podemos instalar o Let’s Encrypt no nosso servidor WordPress. Execute os comandos abaixo:

sudo apt install -y software-properties-common
sudo add-apt-repository universe
sudo apt update
sudo apt install -y certbot python3-certbot-nginx 

Para obter um certificado, agora você pode usar o plug-in Nginx Certbot, executando o seguinte comando. 

sudo certbot --nginx certonly -d seusite.com -d www.seusite.com

Após inserir seu endereço de e-mail e concordar com os termos e condições, o cliente Certbot gerará o certificado solicitado. Lembre de anotar onde o arquivo de certificado fullchain.pem e o arquivo de chave privkey.pem foram armazenados, pois você pode precisar deles em algum momento.

 NOTAS IMPORTANTES: 
 - Parabéns! Seu certificado e cadeia foram salvos em: 
   /etc/letsencrypt/live/blog.alexjunio.com.br/fullchain.pem 
   Seu arquivo de chave foi salvo em: 
   /etc/letsencrypt/live/blog.alexjunio.com.br/privkey.pem

Nginx Bloco de Servidor p/ WordPress

Para que o nosso servidor hospede um site WordPress corretamente, precisamos criar um arquivo de configuração do Nginx com foco em WordPress. Para essa atividade, execute os passos abaixo:

Limpe todo o conteúdo que está inserido no arquivo de configuração default:

sudo nano /etc/nginx/sites-available/default

Agora insira todo o conteúdo abaixo e substitua tudo o que está em negrito, colocando o nome do seu domínio.

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name blog.alexjunio.com.br www.blog.alexjunio.com.br;
    
    ####################################################################################
    # SSL
    ssl_certificate /etc/letsencrypt/live/blog.alexjunio.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/blog.alexjunio.com.br/privkey.pem;
    ####################################################################################    
    #### Logs
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
    ####################################################################################    
    root /var/www/html;
    index index.php;
    ####################################################################################
    #### Locations
    location / {
        try_files $uri $uri/ /index.php?q=$uri&$args;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        #fastcgi_pass unix:/var/run/php7.4-fpm.sock;
        fastcgi_pass unix:/run/php/php8.0-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location = /favicon.ico {
        access_log off;
        log_not_found off;
        expires max;
    }
    location = /robots.txt {
            access_log off;
            log_not_found off;
    }
    ####################################################################################
    # Cache Static Files For As Long As Possible
    location ~*
    \.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$
    {
            access_log off;
            log_not_found off;
            expires max;
    }
    # Security Settings For Better Privacy Deny Hidden Files
    location ~ /\. {
            deny all;
            access_log off;
            log_not_found off;
    }
    # Return 403 Forbidden For readme.(txt|html) or license.(txt|html)
    if ($request_uri ~* "^.+(readme|license)\.(txt|html)$") {
        return 403;
    }
    # Disallow PHP In Upload Folder
    location /wp-content/uploads/ {
            location ~ \.php$ {
                    deny all;
            }
    }

    

}

####################################################################################
##### Redirect http to https
server {
    listen 80;
    listen [::]:80;
    server_name blog.alexjunio.com.br www.blog.alexjunio.com.br;
    return 301 https://blog.alexjunio.com.br$request_uri;
}
####################################################################################

Salve o arquivo usando CTRL + X seguido de Y e Enter. Você pode validar se o Nginx está configurado corretamente executando: sudo nginx -t . Se visualizar uma mensagem como a imagem abaixo, significa que configurou corretamente.

Agora você já pode acessar o seu domínio pelo navegador, e inclusive verá o SSL instalado.

Por último, defina as permissões do diretório root do WordPress corretamente:

chown -R alex:alex /var/www/html/

Instalando o WP-CLI

O WP-CLI é uma ferramenta bem interessante, com ela podemos gerenciar o nosso site WordPress pela linha de comando. Podemos realizar tarefas como: atualização de plugins, atualizações do WordPress, desabilitar plugins, criar usuários e muito mais.

Siga os passos abaixo para instalar o WP-CLI:

cd ~/
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Agora digite no terminal o comando wp e veja se a ferramenta está executando corretamente.

Instalando o MariaDB

O MariaDB é um substituto imediato para o MySQL. Decidimos instalar o MariaDB no nosso servidor WordPress por oferecer mais recursos e melhorias de velocidade em relação ao MySQL.

Para instalar o MariaDB, adicione o repositório e atualize as listas de pacotes:

sudo apt-get install software-properties-common
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://mirrors.up.pt/pub/mariadb/repo/10.4/ubuntu focal main'

Agora instale o MariaDB Server:

sudo apt install mariadb-server -y

Execute o script abaixo para configurar corretamente uma senha para o administrador do MariaDB e realizar algumas configurações:

sudo mysql_secure_installation

Siga as instruções e responda às perguntas. Aqui estão minhas respostas:

alex@wpserver.alexjunio.com.br:~$ sudo mysql_secure_installation 


Switch to unix_socket authentication [Y/n] Y
Enabled successfully!
Reloading privilege tables..
 ... Success!

You already have your root account protected, so you can safely answer 'n'.

Change the root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
 ... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
 ... Success!

Cleaning up...

All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

Agora precisamos criar um usuário, uma database e deixa-lo configurado com seus devidos privilégios.

Criando uma base de dados

Para criar a base de dados e um usuário para a base do WordPress você precisa logar no MySQL utilizando o usuário root e a senha configurada anteriormente. No terminal digite o comando abaixo para login:

mysql -uroot -p

Uma vez logado, execute os comandos baixo para criar a database, usuário e definir os privilégios. Lembre de trocar as informações em negrito.

# Criando a database
CREATE DATABASE dbwordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;

# Criando um usuário 
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'senha';

# Dando permissões para o usuário 

GRANT ALL PRIVILEGES ON dbwordpress.* TO 'wpuser'@'localhost';

# Liberando os privilégios
FLUSH PRIVILEGES;

# Saindo do shell do MySQL
exit;

Muito bem! Já temos a nossa base de dados e um usuário para poder utilizar no processo de instalação do WordPress.

Conclusão

Neste capítulo configuramos o Nginx, PHP com PHP-FPM, MariaDB para nosso banco de dados, WP-CLI e habilitamos o SSL Let’s Encrypt para nosso domínio.

Introdução a VPS Vultr para WordPress

Este é um conjunto de artigos criado para ensinar, passo a passo, como configurar um VPS Ubuntu para hospedar WordPress na Vultr com segurança, otimização e alto desempenho. Acompanhe a sequência completa e configure seu servidor de forma profissional!

📌 Confira os artigos na ordem recomendada:

🔹 Parte 01 – Introdução: VPS WordPress na Vultr

🔹 Parte 02 – Configurando VPS Ubuntu Vultr com Nginx, PHP e MySQL

🔹 Parte 03 – Instalando o WordPress no Ubuntu Vultr

🔹 Parte 04 – Como otimizar o Nginx e PHP no VPS Ubuntu Vultr

🔹 Parte 05 – Configurando Cache no Nginx e Redis

🔹 Parte 06 – Configurações de Cron no VPS Ubuntu Vultr

🔹 Parte 07 – Configurando Backups Automáticos no Servidor

🔹 Parte 08 – Segurança no Nginx: Protegendo seu WordPress

🔹 Parte 09 – Monitoramento do VPS Ubuntu: Ferramentas Essenciais

Requisitos

Para configurar sua Hospedagem WordPress em um servidor privado na Vultr você vai precisar apenas de:

• Domínio válido com acesso a DNS
• Cadastro na Vultr

Criando um Servidor Privado na Vultr para seu WordPress

Neste tutorial não vamos abordar o processo inicial de criação do VPS na Vultr, pois temos uma aula ensinando todo o passo a passo e você pode visualizar a aula para aprender o processo.

O tutorial em vídeo também aborda o primeiro acesso via SSH no VPS, e é de suma importância que você aprenda minimamente a acessar o servidor.

No entanto escolha um VPS com os seguintes requisitos

• Ubuntu 20:04 LTS
• Mínimo 1GB RAM

No nosso tutorial eu escolhi um VPS do estilo Cloud Compute por ser um modelo de custo benefício, e nossa máquina é a de 2GB e 1CPU.

Você deve também selecionar uma região mais próxima de você para minimizar o máximo a latência. A Vultr tem data center em América/São Paulo, se sua aplicação WordPress precisa de uma latência bem pequena você pode escolher essa localidade.

Configurações Iniciais

Creio que você já assistiu o vídeo e aprendeu a criar o VPS e também acessar o servidor via SSH. Então está pronto para começarmos as nossas primeiras configurações no nosso servidor VPS WordPress.

Configurando o nome do host

Uma das primeiras coisas que devemos configurar no nosso servidor é o nome do host com um domínio totalmente qualificado (FQDN). Esse nome é único, mas não tem relação com o site WordPress que iremos configurar.

Realizar essa configuração vai facilitar bastante futuras conexões no servidor, uma vez que você poderá acessar o servidor sem utilizar o IP da máquina, e sim, apenas com o nome do host definido.

Para configurar o nome do host execute os comandos abaixo, substituindo o domínio.

echo "wpserver.alexjunio.com.br" > /etc/hostname
hostname -F /etc/hostname

Para colocar em vigor o nome do host associado ao seu domínio é necessário configura-lo no DNS do seu domínio. Nesse tutorial utilizo o DNS da CloudFlare, mas no geral o processo de configuração do apontamento do registro é o mesmo.

Note que eu configurei um registro do tipo (A) onde o nome (wpserver) está apontado para um IP, que será o IP do nosso servidor. Também desabilitei a nuvem de Proxy para não interferir futuramente na emissão do SSL.

Após realizar a configuração acima no seu provedor de DNS a propagação pode demorar de alguns minutos até algumas horas. Uma vez propagado, você vai poder realizar conexão via SSH utilizando o nome de host configurado, veja um exemplo abaixo:

ssh root@wpserver.alexjunio.com.br 

Configurando o horário do servidor

Ter o horário do nosso servidor configurado pode evitar vários problemas desde um agendamento de postagem no WordPress como até mesmo o horário do backup. Para realizar a configuração você precisa do pacote tzdata instalado no servidor, é através dele que definimos o timezone correto que é o America/Sao_Paulo.

Execute os comandos abaixo para instalar o tzdata e configurar o timezone do nosso servidor.

export DEBIAN_FRONTEND=noninteractive
ln -fs /usr/share/zoneinfo/America/Sao_Paulo /etc/localtime
apt-get install -y tzdata
dpkg-reconfigure --frontend noninteractive tzdata

Agora veja se o horário do servidor está corretamente atualizado executando o comando abaixo:

date

Atualizando o Sistema

Por mais que você contrate um servidor novo, alguns softwares instalados podem estar desatualizados. Vamos atualizar o nosso sistema para que tenhamos as listas de pacotes atualizados.

Execute os comandos abaixo.

apt update
apt upgrade -y

Quando todas as atualizações forem executadas, você verá quais pacotes foram instalados e também quais pacotes não são mais necessários para o sistema.

Para remover os pacotes desatualizados execute o comando abaixo:

apt autoremove

Configurando Usuário

Utilizar o usuário root do servidor para acessos ssh e tarefas básicas não é algo recomendado, inclusive é algo que deve ser evitado ao máximo. Para resolver esse problema, vamos criar um usuário adicional que será responsável por gerenciar e configurar tudo o que envolve a nossa hospedagem wordpress.

Esse usuário poderá ser utilizado para;

• Acesso SSH e SFTP
• Tarefas administrativas no código do WordPress
• Restart de serviços como MySQL, Nginx, PHP

Para que o usuário tenha todos os privilégios necessários para seu pleno funcionamento, vamos adiciona-lo ao grupo sudo. Desse modo, não terá problemas maiores na execução de comandos de administração.

Para criar o usuário execute os passos abaixo:

adduser alex

# obs: Insira um nome de usuário desejado na linha acima

Em seguida você precisará inserir informações sobre o usuário e também uma senha, lembre que a senha precisa ser minimamente complexa.

root@wpuser.alexjunio.com.br:~$ sudo adduser alex
Adicionando usuário `alex ...
Adicionando novo grupo `alex' (1002) ...
Adicionando novo usuário `alex' (1002) com o grupo `alex' ...
Criando o diretório inicial `/home/alex' ...
Copiando arquivos de `/etc/skel' ...
Nova Senha:
Redigite a nova senha:
passwd: senha atualizada com sucesso
Alterando as informações do usuário para alex
Insira o novo valor ou pressione ENTER para o valor padrão
    Nome Completo []: alex Rich
    Número do quarto []:
    Telefone de Trabalho []:
    Telefone residencial []:
    Outro []:
As informações estão corretas? [S/n]

Após confirmar e criar o usuário, adicione ao grupo sudo:

usermod -a -G sudo alex

Agora realize uma nova conexão SSH no seu servidor, no entanto utilizando o usuário que você acabou de configurar.

ssh alex@wpuser.alexjunio.com.br

Se a conexão foi bem sucedida, significa que você configurou o usuário corretamente e está pronto para a próxima etapa.

Configurando o Firewall

O Firewall vai nos ajudar bastante pois oferece uma camada adicional de segurança em nosso servidor WordPress, ele vai bloquear tráfego de rede de entrada. No Ubuntu o UFW é instalado por padrão, caso o seu sistema por algum motivo não tenha, instale executando o comando abaixo:

sudo apt install -y ufw 
sudo ufw enable
sudo systemctl start ufw 

Agora podemos liberar as portas que nossos serviços irão trabalhar, que respectivamente são as portas para protocolos http, https e ssh.

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

Configurando o Fail2ban

O Fail2ban é uma ferramenta gratuita que funciona junto com o firewall. Ele monitora as tentativas de acesso ao nosso servidor e pode bloquear um determinado atacante por um período de tempo. Caso ele detecte algo malicioso, o IP do atacante é bloqueado. Servidores profissionais WordPress precisam de segurança avançada e o Fail2ban pode nos ajudar nessa tarefa.

Para instalar o Fail2ban execute os comandos abaixo:

sudo apt install -y fail2ban
sudo service fail2ban start

Por padrão o Fail2ban irá monitorar e bloquear um usuário/host por 10 minutos após 6 tentativas de ataque ao SSH. Existem muitas configurações avançadas e personalizadas para Fail2ban focado em WordPress, traremos mais conteúdos sobre isso.

Para manter o servidor minimamente seguro sempre execute as tarefas abaixo:

• Atualizar o servidor
• Manter plugins e templates atualizados
• Evitar Nulled
• Configurar senhas complexas e fortes *mínimo 30 dígitos
• Configuração de Firewall
• Utilizar CloudFlare se possível ou Sucuri Firewall na camada Web

Conclusão

Nesse capítulo realizamos todas as configurações mínimas e necessárias para começar a trabalhar no nosso servidor para hospedagem WordPress. No próximo capítulo vou te ensinar a configurar o LEMP e emitir certificados SSL com Let’s Encrypt.