03 de fevereiro de 2021 • 4 min de leitura
Desmistificando o Nginx: parte 1
NGINX é um software de código aberto para serviço da Web, proxy reverso, cache, balanceamento de carga, streaming de mídia e muito mais.
Ele começou como um servidor web projetado para máximo desempenho e estabilidade. Além de seus recursos de servidor HTTP, o NGINX também pode funcionar como proxy para e-mail (IMAP, POP3 e SMTP) e um proxy reverso e load balancer para servidores HTTP, TCP e UDP.
Nesse cenário será utilizado o CentOs7 como sistema operacional, o processo de instalação pode variar dependendo da distribuição utilizada.
Instalação
As etapas neste tutorial requer que o usuário tenha privilégios de root.
1- Adicionar o repositório EPEL
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
2- Instalar o Nginx
yum install nginx
3- Habilitar e iniciar
systemctl enable nginx
systemctl start nginx
4- Ajustar o firewall e SELinux Caso utilize firewalld basta adicionar as seguintes regras:
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload
Para que o nginx possa utilizar operar sem maiores problemas, é indicado que o libere também no SELinux, basta executar o comando:
semanage permissive -a httpd_t
Com o Nginx instalado e habilitado, seguiremos com a configuração do mesmo.
Configuração
Abordaremos algumas configurações e opções que são úteis no dia a dia, para você que a administra um servidor Nginx e para os que estão migrando.
Criando um Vhost
Será utilizado o arquivo .conf
padrão do nginx:
vim /etc/nginx/nginx.conf
Podemos limpar o arquivo nginx.conf
e deixar apenas o esqueleto do nosso Vhost, utilizaremos o path default do Nginx para o exemplo:
events {}
http {
include mime.types;
server {
listen 80;
server_name 192.168.18.3;
root /usr/share/nginx/html/;
}
}
Configurado isso, acesse o diretório /usr/share/nginx/html
, pode remover todos os arquivos, crie o nosso index.html
apenas com um Hello World:
<!DOCTYPE html>
<html>
<head>
<title> Hello World Nginx! </title>
</head>
<body>
<h1> Hello World Nginx! </h1>
</body>
</html>
Feito isso, basta recarregar o nginx com o comando:
nginx -s reload
Pronto, colocando o ip da nossa máquina pelo navegador já deve ter o acesso sem problemas.
Locations
O location é usado para definir como o Nginx deve lidar com solicitações de diferentes recursos e URLs para o servidor, conhecido como subpastas, dessa forma podemos definir o que acontece quando acessamos: http://IP/Teste
se desejamos criar uma subpasta para ele ou se desejamos configurar regras.
A partir disso criaremos um location chamado Teste. Informaremos ao servidor web que deverá retornar o status code 200 além de repassar na tela uma informação diferente do nosso Hello World inicial. Observe:
events {}
http {
include mime.types;
server {
listen 80;
server_name 192.168.18.3;
root /usr/share/nginx/html/;
location ^~ /Teste {
return 200 'Hello World NGINX "/Teste" location.';
}
}
}
Após ajustado, realize o reload do nginx nginx -s reload
e tente acessar o url: http://IP/Teste
Variáveis
O Nginx possui algumas variáveis que podem ser configuradas para facilitar o gerenciamento de algumas informações, nos aprofundaremos mais na parte de proxy reverso, no qual aplicaremos algumas configurações no redirecionamento.
O próprio Nginx possui uma página que reúne várias variáveis e as suas aplicabilidades basta clicar aqui.
Dessa forma, crie uma location para retornar na tela algumas informações para inspecionarmos:
events {}
http {
include mime.types;
server {
listen 80;
server_name 192.168.18.3;
root /usr/share/nginx/html/;
location ^~ /Inspect{
return 200 '$host\n$uri\n';
}
}
}
Feito isso, basta fazer o reload do nginx e acessar o url http://IP/Inspect
verá que será retornado na tela algumas informações do host.
Rewrites e Redirects
Os Rewries e Redirects são amplamente utilizados, um cenário para isso seria quando precisamos forçar que todas as requisições sejam feitas utilizando https, dessa forma realizamos um rewrite.
O redirecionamento simplesmente informa ao cliente para onde deverá ir o redireciona, por exemplo:
O visitante acessa http://IP/redirect e o servidor redireciona o url movendo o visitante para o url http://IP/new-redirect
O Rewrite, faz o mesmo processo porém de forma interna e transparente, em poucas palavras, ele redirecionará e o url não será alterado.
Observe algumas configurações de locations para cada cenário:
location ^~ /Redirect{
return 307 /Destino-Redirect;
}
location ^~ /Rewrite{
rewrite ^/Rewrite/\w+ /Desino-Rewrite ;
}
Quando acessado o url /Redirect
veremos que a sua url será alterado para /Destino-Redirect
. diferente no Rewrite, que por fazer o direcionamento de forma transparente para o usuário, redirecionará o acesso para /Destino-Rewrite
porém irá manter o url /Rewrite
.
Esse é o funcionamento básico de como funciona os redirecionamentos, existem outras formas e caso tenham interesse basta acessar o link.
Logs
O Nginx grava registros de seus eventos em dois tipos de logs, logs de acesso e logs de erro. Os logs de acesso gravam informações sobre solicitações do cliente e os logs de erros gravam informações sobre os problemas do servidor e do aplicativo.
Para configurarmos os logs basta adicionar a diretiva e o caminho absoluto cujo o arquivo será gerado:
...
http {
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
...
Os logs também podem ser formatados, com a configuração da diretiva log_format
, isso permite adaptar as informações que serão armazenadas no log, ou remover informações não necessárias, o mais comum e o padrão adotado é o log_format combined
que reúne várias informações suficientes para análise.
Workers
O NGINX pode executar vários processos, cada um capaz de processar um grande número de conexões simultâneas. É possível controlar o número de workers e como eles lidam com as conexões com as seguintes diretivas:
worker_processes
: O número de workers, o padrão é 1. Na maioria dos casos, a execução de um processo de trabalho por núcleo da CPU funciona bem, e recomendamos definir essa diretiva como automática para conseguir isso. Há momentos em que você pode querer aumentar esse número, como quando os processos de trabalho precisam fazer muita E/S de disco.
worker_connections
: Essa diretiva define o número máximo de conexões que cada processo de trabalho pode manipular simultaneamente. O padrão é 512, mas a maioria dos ambientes possuim recursos suficientes para suportar um número maior.
Dessa forma basta configurar o worker_processes
como auto e ajustaremos a quantidade de conexões em 1024:
...
worker_processes auto;
events {
worker_connections 1024;
}
...
Para não ficarmos com muito conteúdo e várias abordagens, daremos continuidade com a parte de Performance, Segurança e Proxy na parte dois desse artigo, espero que tenham gostado do material, tentei trazer o máximo de informações sobre as principais configurações que tenho tido vivencia.
Até a próxima.