💾 Archived View for costas.dev › posts › entorno-web-local.gmi captured on 2022-03-01 at 15:04:04. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
El otro día configuré un entorno de desarrollo en local en mi sistema Artix Linux (edición Runit) para una pequeña aplicación web en Go. De este modo, tenía un "dominio" apuntando a mi servidor, un NGINX sirviendo las peticiones o haciendo de proxy inverso, y un certificado HTTPS.
De este modo, puedo imitar mucho mejor el comportamiento de mi aplicación una vez se ha desplegado, ya que en vez de conectarme directamente al servidor uso el mismo proxy inverso que el propio servidor «de producción».
Esta guía debería funcionar en Arch y derivados con systemd, omitiendo los paquetes específicos para cada Init y usando systemd.
Primero, instalamos todos los paquetes necesarios: mkcert (del repositorio de Arch), nginx y nginx-runit. Una vez instalados, activamos nginx en el sistema con los comandos habituales:
# ln -s /etc/runit/sv/nginx /run/runit/service/ # sv start nginx
Después, tocará elegir el dominio que queramos. Generalmente se usa un dominio `.local`, pero personalmente prefiero el `.lan` o `.test` ya que puede haber algún problema de DNS. En mi caso, voy a configurar `example.lan` y por tanto ejecuto lo siguiente para generar mi certificado autofirmado en la carpeta de NGINX:
# cd /etc/nginx # mkcert example.lan # mkcert -install
Si tienes algún navegador web abierto, debes reiniciarlo para que cargue la nueva CA que mkcert se ha inventado para nuestro equipo. Nota que no es un certificado "real", en el sentido de que si otra persona intenta acceder a nuestro servidor, le saldrá un problema de seguridad porque el certificado no es válido.
Teniendo ya nuestro certificado, editamos el archivo `/etc/hosts` con nuestro editor preferido, y añadimos la siguiente línea, con un tabulador entre la IP y el dominio:
127.0.0.1 example.lan
De este modo, cuando visitemos example.lan, nos llevará a 127.0.0.1 en lugar de intentar resolver el dominio por DNS (que no funcionaría, ya que no tenemos eso configurado).
Ahora configuraremos NGINX, para que escuche con nuestro certificado. En el archivo `/etc/nginx/nginx.conf` puedes borrar el bloque `server{}` que incluye por defecto activado, y añadir el siguiente:
server {
listen 443 ssl;
server_name example.lan;
ssl_certificate example.lan.pem;
server_certificate_key example.lan-key.pem;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
# Ubicaciones, raíces de archivos y demás
root /opt/www;
index index.html index.htm;
location / {
autoindex on;
}
}
Tras hacer esto, debemos probar la configuración con `nginx -t` y reiniciarlo (si es correcta) con `nginx -s reload`.
En este caso, hemos configurado un servidor de archivos estáticos, que servirá el contenido de `/opt/www`. Esto es un ejemplo que se puede cambiar para ajustarse a nuestras necesidades (proxy inverso, por ejemplo). Suponiendo que queremos dejar esto, crearíamos `/opt/www` como root y nos aseguramos de que NGINX tenga permisos de lectura.
# mkdir /opt/www # echo "hola web" >> /opt/www/hola.txt
Y si ahora visitamos `https://example.lan` en cualquier navegador Web, deberíamos ver un listado de la carpeta configurada, con un único archivo "hola.txt" que al visitar nos muestre su contenido ("hola web").
Si consultamos el certificado, vemos que es un certificado válido de nuestra CA local, y que nos valdrá durante un par de años.
--
El contenido de esta página está cedido bajo licencia