======== Configuración de nginx ========
Nada gente, resulta que ahora me tengo que sacar la certificación de
nginx así que vamos a ver los puntos que te dicen que tienes que tener
para tener el Certified™ Nginx™ Administrator™:
- Perform and verify an NGINX OSS installation
- Use NGINX as webserver
- HTTPS
- Use NGINX as load balancer
- Understand how NGINX uses modules
- Recognize functionallity, architecture and uses cases for NGINX
- Understand the use of share memory zones
- Read and interpret an NGINX log
- Understand the use of variables in an NGINX log
- Verify proper nginx operation (i.e. verify it is working)
- Provide the data that support will need when troubleshooting (esta no la veremos porque no tengo soporte contratado como comprendereis)
Se asumirá que estamos usando Debian, no estoy usando FreeBSD en este
caso debido a razones.
===== >Perform and verify an NGINX OSS installation =====
# Instalamos el paquete de nginx
$ sudo apt install -y nginx
# Verificamos que esté instalado
$ dpkg -l | grep nginx
Deberia salir en el output
===== >Use NGINX as Webserver =====
A ver, normalmente Debian inicia los servicios una vez se instalan,
así que en teoría ya estás usando nginx como servidor web, puedes
comprobarlo accediendo a la IP del servidor en el navegador o haciendo
desde la propia máquina con nginx algo así:
curl 127.0.0.1
Tendría que salirte un mensaje de nginx diciendo que: funciona
Para ver la configuración por defecto de nginx, veremos, en Debian,
vamos a ''/etc/nginx/sites-enabled/default'', que es la configuración
de un sitio web por defecto que trae la distribucion de nginx de
Debian (puede ser distinta en otras distros/OSes, por ejemplo FreeBSD
te tira el nginx.conf a tu suerte)
Así se ve un sitio configurado en ''/etc/nginx/sites-enabled/default''
server {
server_name tu-dominio.tld;
listen 127.0.0.1:80;
#charset koi8-r;
#access_log logs/host.access.log main;
root /var/www/html;
index index.html index.htm index.cgi;
# Páginas de error
error_page 404 /errdocs/404.html;
error_page 403 /errdocs/403.html;
error_page 410 /errdocs/410.html;
error_page 500 /errdocs/500.html;
error_page 502 /errdocs/502.html;
}
Y ya está. Esto es el nginx mas simple del mundo. Sirve HTML y páginas de error.
===== >HTTPS =====
(como generar certificados SSL, ya sea con certbot o openssl, se
escapa del ámbito de este artículo, así que asumiremos que ya los
tienes)
Al toque mi rey. Abajo de listen 80 en la configuración anterior, añadimos algo así:
listen 443 ssl;
ssl_certificate /etc/ssl/tu-dominio.pem
ssl_certificate_key /etc/ssl/private/tu-dominio.key
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
''service nginx restart'' y ya tienes HTTPS. ole.
===== >Use NGINX as load balancer =====
También muy sencillo. Asumiendo que ya tenemos todo montado y tienes dos servidores exactamente iguales en 10.0.0.1 y 10.0.0.2:
En el bloque http de la configuración (que está en ''/etc/nginx/nginx.conf'', agregamos nuestros mirrors:
upstream web {
server 10.0.0.1;
server 10.0.0.2;
}
Y luego en nuestro archivo de configuración:
location / {
proxy_pass http://myapp1;
}
Y eso sería todo (sigo pensando que haproxy es mejor para esto por
cierto). Luego puedes meterle la parafernalia de SSL si quieres
Podemos configurar como queremosd que balancee la carga para que no
use el por defecto, que es ''roundrobin''. Por ejemplo, least_conn;
para usar siempre el servidor menos concurrido:
upstream web {
least_conn;
server 10.0.0.1;
server 10.0.0.2;
}
O podemos usar que un server se use varias veces antes de pasar a otro
usando el parámetro weight:
upstream web {
least_conn;
server 10.0.0.1 weight=3;
server 10.0.0.2;
}
===== >Understand how NGINX uses modules =====
Sencillo, podemos ver en el ''nginx.conf'' de donde nginx carga los módulos:
''include /etc/nginx/modules-enabled/*.conf;''
Con estos archivos de configuración, nginx carga el shared object del
modulo en cuestión y puede usarlo. Hay módulos para código de perl,
http3.0 y esa clase de todas. Básicamente se cargan como una librería
cualquiera.
===== >Recognize functionallity, architecture and uses cases for NGINX =====
Esto suena a scalable cloud edge computing computer vision javascript
AI-powered. Pero vamos:
Funcionalidad: Servir archivos a través del protocolo HTTP. Además de
eso también puede servir aplicaciones web enteras escritas con un
framework (haciendo uso de sus funcionalidades de proxy inverso) y
demás cosas.
Arquitectura: Pues dependerá de como lo tengas montado. Lo mismo
tienes nginx o tienes haproxy. No me preguntes esto a mi anda.
Use cases: Cuando necesitas hacer un proxy inverso, servir un sitio
web estático, una aplicación web en PHP o cualquier cosa de estas
===== Understand the use of share memory zones =====
Esto nos sirve para que los workers threads de nginx se comuniquen
entre ellos y puedan recordar cosas. Como las requests, la IP de las
requests o limitar cosas como ela cceso a un recurso, directorio o lo
que sea. Según un compi de curro lo que almacena es una struct de C de
no mas de 32 bytes por lo cual dándole una memoría compartida de 10M
va que sobra. Para crear una zona y luego poder usarla para limitar
recursos, hacemos lo siguiente, antes del bloque server:
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
Esto lo que hace es recordar a los usuarios *por su dirección IP* y en
este ejemplo, en una zona llamada "mylimit" de 10 megabytes que pone
el límite en 1 request por segundo (por ejemplo). Para aplicar este
filtro, se pone dentro de un bloque de ''location''
server {
liten 80;
root /var/www/html;
location / {
limit_req zone=mylimit;
}
}
Con esto ya se aplicaría el límite y si vamos a dicho servidor web a
spammear el F5 notaremos como nos saldrá eventualmente "503 Service
Temporary Unavailable" Podemos añadir otros parámetros a la lista de
limit_req como ''burst'' y ''nodelay''. El primero es que solo cuenten
los primeros 5 requests para un request (por ejemplo, tu index.html
requiere 50 archivos .js para cargar, lol) y nodelay es para no
retrasar requests excesivos.
===== Read and interpret an NGINX log =====
127.0.0.1 - - [04/Jun/2025:12:56:33 +0000] "GET / HTTP/1.1" 200 2085 "http://5.249.160.173:80/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36"
Yo creo que esto se entiende, no? IP, fecha, request, como respondió el server, tamaño, a donde hizo el request, y el user agent. No creo que haya mucho que explicar aquí.
===== Understand the use of variables in an NGINX log =====
Ah si, una vez para usar goaccess tuve que cambiar el formato del log
de nginx para que goaccess lo entendiese.
Aquí están todas las que puedes usar, y si dependen de algún módulo:
https://nginx.org/en/docs/varindex.html
Ejemplo de configuración de log abstracta en nginx:
log_format compression '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
Es básicamente el por defecto, si os fijais. pero así podeis cambiar
las variables y añadir las que querais o cambiarlas para hacer el log
mas personalizado o que tenga menos cosas que no os interesan.
===== >Verify proper nginx operation (i.e. verify it is working) ====
Uhmm. ¿''systemctl status nginx'' y que esté en verde? ¿''netstat
-plnt'' y ver nginx?. También puedes testear la configuración de nginx
con ''nginx -t''
Hay cosas tan sencillas que me cuesta creer que se preguntan en
examenes oficiales de certificaciones de 500 euros.
===== >Provide the data that support will need when troubleshooting ====
Ah, la tipica. TODOS los logs de error (y debug también ya que estamos
teniendo un problema en producción) para mandarlo al soporte y que se
encarguen ellos. Pero vamos, podemos sacarla de /var/log/nginx/error.log
Tu valor en el mercado laboral acaba de subir 500 euros, aparentemente
{{:smile.png?200|}}