💾 Archived View for costas.dev › posts › entorno-web-local.gmi captured on 2022-06-03 at 23:01:20. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-03-01)

🚧 View Differences

-=-=-=-=-=-=-

Entorno de desarrollo web local en Artix

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.

Requisitos previos

Instalación

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;
	ssl_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.

---

© 2022 Ariel Costas. Hacer copias exactas de esta página completa está permitido, siempre que se preserve este texto.