En nuestro artículo “nginx, el servidor web rápido y so­s­te­ni­ble” re­su­mía­mos el proceso de in­s­ta­la­ción en el sistema y las ca­ra­c­te­rí­s­ti­cas básicas de nginx. En el siguiente tutorial ofrecemos un resumen de los comandos básicos y opciones de co­n­fi­gu­ra­ción de este moderno servidor web. 

La unidad central de control: nginx.conf

A di­fe­re­n­cia de Apache, nginx no se basa en procesos, sino en eventos. Las so­li­ci­tu­des in­di­vi­dua­les se cla­si­fi­can como eventos y no como nuevos procesos de trabajo para los que es necesario cargar todos los módulos. Estos eventos son di­s­tri­bui­dos en los procesos exi­s­te­n­tes, que son ma­n­te­ni­dos en fu­n­cio­na­mie­n­to por el proceso principal. La cantidad de procesos exi­s­te­n­tes y la manera en la que se dividen las so­li­ci­tu­des del servidor (es decir, los eventos) se definen en el archivo de co­n­fi­gu­ra­ción nginx.conf. Por defecto, este archivo lo puedes encontrar en los di­re­c­to­rios /usr/local/nginx/conf, /etc/nginx o /usr/local/etc/nginx.

Gestionar procesos y adoptar nuevas co­n­fi­gu­ra­cio­nes

Una vez fi­na­li­za­da la in­s­ta­la­ción, nginx se iniciará au­to­má­ti­ca­me­n­te –aunque también se puede iniciar ma­nua­l­me­n­te uti­li­za­n­do el siguiente comando:

sudo service nginx start

Cuando el software se ha puesto en marcha, los procesos (sobre todo el proceso principal) se controlan con el parámetro –s y una señal (signal) es­pe­cí­fi­ca. La sintaxis del comando co­rre­s­po­n­die­n­te es tan sencilla como:

sudo nginx -s signal

Como “señal” tienes las si­guie­n­tes cuatro opciones:

  • stop: finaliza nginx in­me­dia­ta­me­n­te.
  • quit: nginx se termina después de que todas las so­li­ci­tu­des activas han sido co­n­te­s­ta­das.
  • reload: el archivo de co­n­fi­gu­ra­ción se vuelve a cargar.
  • reopen: se reinician los archivos de registro.

La opción reload con la que se vuelve a cargar el archivo de co­n­fi­gu­ra­ción es una manera práctica de aplicar cambios al mismo sin tener que finalizar y reiniciar el servidor. En cualquier caso, y para para que el sistema acepte y guarde los cambios, es necesario decidirse por una variante que reinicie el servidor por completo o por una que realice úni­ca­me­n­te el nginx reload. Si quieres elegir la opción más elegante, es decir la segunda, y ejecutar el comando, el proceso principal recibe una in­di­ca­ción para aplicar los cambios en el archivo nginx.conf:

sudo nginx -s reload

Para este propósito el primer paso es verificar la sintaxis. En caso de que esta sea correcta, el proceso principal inicia otros procesos de trabajo con la nueva co­n­fi­gu­ra­ción y, si­mu­l­tá­nea­me­n­te, detiene los procesos antiguos. Si la co­m­pro­ba­ción de la sintaxis falla, la co­n­fi­gu­ra­ción previa se mantiene. Todos los procesos activos se terminan tan pronto como se han procesado todas las so­li­ci­tu­des activas. 

Recuerda que también es posible abordar procesos de nginx di­re­c­ta­me­n­te uti­li­za­n­do he­rra­mie­n­tas como kill. Todo lo que necesitas es el ID del proceso que en­co­n­tra­rás en el archivo nginx.pid en el di­re­c­to­rio /usr/local/nginx/logs, o al­te­r­na­ti­va­me­n­te en /var/run. Así, si el proceso tiene, por ejemplo, el ID 1628, puede ser fi­na­li­za­do en el ciclo suave con la señal quit y con kill: 

sudo kill -s quit 1628

El programa de utilidad ps te presenta una lista con todos los procesos nginx que se están eje­cu­ta­n­do:

sudo ps -ax | grep nginx

Cómo controlar la entrega de contenido estático

Es muy probable que utilices tu servidor web para su­mi­ni­s­trar contenido como imágenes, vídeos o contenido HTML estático. Por razones de efi­cie­n­cia, es re­co­me­n­da­ble se­le­c­cio­nar varios di­re­c­to­rios locales para los di­fe­re­n­tes tipos de contenido, tal como eje­m­pli­fi­ca­re­mos a co­n­ti­nua­ción.

Comienza creando el di­re­c­to­rio /data/html y, en él, el documento HTML index.html y la carpeta /data/fotos, junto con algunas imágenes de muestra.  

En el siguiente paso los dos di­re­c­to­rios deben ser movidos al archivo de co­n­fi­gu­ra­ción, ma­n­te­nié­n­do­los en la directiva bloque-servidor, que es a su vez, una su­b­di­re­c­ti­va de la directiva del bloque-HTTP. Por defecto, allí en­co­n­tra­rás algunas in­s­tru­c­cio­nes que han sido pre­via­me­n­te re­gi­s­tra­das pero que puedes des­ac­ti­var en cualquier momento (off). A co­n­ti­nua­ción, solo necesitas añadir una in­s­tru­c­ción adicional al bloque-Servidor: 

http {
    server {
    }
}

Ahora, ambos di­re­c­to­rios (uno con fotos y otro con el documento HTML) deben aparecer en el bloque-Servidor. El resultado co­rre­s­po­n­die­n­te se verá de la siguiente manera:

server {
    location / {
        root /data/html;
    }
    location /bilder/ {
        root /data;
    }
}

Esta co­n­fi­gu­ra­ción es, por defecto, un ajuste estándar de un servidor que se escucha en el puerto 80 y es accesible a través del host local. Todas las so­li­ci­tu­des cuyas URI (Ide­n­ti­fi­ca­dor de recursos uniforme) comienzan con /fotos/ so­li­ci­ta­rán datos del di­re­c­to­rio /data/fotos. Si el archivo co­rre­s­po­n­die­n­te no existe, aparecerá el mensaje de error. Todos los eventos nginx cuyas URI no empiezan con /fotos/ se remiten al di­re­c­to­rio /data/html. 

Recuerda que debes cargar de nuevo o reiniciar nginx para aplicar los cambios.

Co­n­fi­gu­ra­ción de un servidor proxy nginx simple

A menudo, nginx es utilizado para dirigir un servidor proxy que, re­em­pla­za­n­do al servidor real, es el encargado de recibir las pe­ti­cio­nes entrantes, de fi­l­trar­las bajo de­te­r­mi­na­dos criterios y de entregar las re­s­pe­c­ti­vas re­s­pue­s­tas a los clientes. Los se­r­vi­do­res proxy caché son es­pe­cia­l­me­n­te populares, pues entregan el contenido estático al­ma­ce­na­do di­re­c­ta­me­n­te y solo tra­n­s­mi­ten pe­ti­cio­nes entrantes al servidor. Los co­r­ta­fue­gos proxy que filtran co­ne­xio­nes inseguras o in­de­sea­das también son muy conocidos. A co­n­ti­nua­ción eje­m­pli­fi­ca­mos el an­te­rio­r­me­n­te me­n­cio­na­do proxy caché, quien debe re­pro­du­cir las imágenes so­li­ci­ta­das desde el di­re­c­to­rio local y reenviar todas las so­li­ci­tu­des al servidor web. El primer fragmento define el servidor principal en nginx.conf:  

server {
    listen 8080;
    root /data/up1;
    location / {
    }
}

A di­fe­re­n­cia del ejemplo anterior, utiliza la directiva Listen, pues el puerto que se debe utilizar para las so­li­ci­tu­des entrantes es 8080 y no el puerto pre­de­te­r­mi­na­do. Establece /data/up1 como di­re­c­to­rio de destino y coloca allí la página index.html.  

Po­s­te­rio­r­me­n­te, uti­li­za­n­do la directiva ProxyPass, define el servidor proxy y su función para entregar contenido de la imagen, in­clu­ye­n­do in­fo­r­ma­cio­nes sobre el servidor principal (Protocolo (http), Nombre (localhost) y Puerto (8080):

server {
    location / {
        proxy_pass http://localhost:8080;
    }
    location ~ \.(gif|jpg|png) $ {
        root /data/bilder;
    }
}

El segundo bloque Location designa al servidor proxy la tarea de responder por sí mismo a todas las so­li­ci­tu­des cuyas URI tengan te­r­mi­na­cio­nes típicas como .gif, .jpg y .png, mientras que el contenido co­rre­s­po­n­die­n­te es re­cu­pe­ra­do desde el di­re­c­to­rio /data/fotos. Las demás so­li­ci­tu­des son enviadas al servidor principal. Al igual que con la co­n­fi­gu­ra­ción anterior, guarda las imágenes proxy con la señal reload en el proceso principal o por medio de restart nginx. Si quieres conocer otras di­re­c­tri­ces para gestionar co­n­fi­gu­ra­cio­nes del proxy más complejas, consulta el manual en inglés en la página web oficial de nginx.

Ir al menú principal