PiServer con Docker – Parte 8: Planteamiento de un servidor web dockerizado.

En anteriores tutoriales hemos aprendido un montón de cosas: primero logramos instalar Docker y Docker Compose en un dispositivo con Linux (nos hemos centrado en Raspberrys pero hemos visto como hacerlo en Debian y Ubuntu). Hemos visto también cómo funciona Docker y un montón de comandos para gestionarlo y luego hemos aprendido a instalar unos cuantos Dockers diferentes.

Sin embargo los dockers que hemos instalado no han generado ninguna web que fuera accesible desde el exterior. Normalmente, cuando empresas o particulares quieren tener una página publicada en internet y no quieren complicarse la vida, contratan a una empresa de hosting para que albergue su web. Albergues hay miles y con montones de planes diferentes, pero os voy a contar los tipos de alojamientos que más he podido ver en empresas con las que he tratado.

Un momento... ¿Me he confundido de artículo? ¿No vas a hablarnos de cómo autohospedar una web usando Docker?

Claro que sí, usuario Anónimo, pero antes de empezar es bueno que veamos que alojar una web no es algo trivial. Es positivo que comparemos «la forma habitual» de hacer las cosas (la forma por la que optan el 90% de las empresas y particulares) con la que vamos a aprender en los siguientes tutoriales. Por eso vamos a ver los tipos de alojamientos más habituales junto con sus costes. Con estos datos podremos determinar las ventajas e inconvenientes que tendremos autoalojando una web en nuestra casa.

Opciones de hosting que tendríamos si no nos planteásemos tener un servidor personal.

1) Contratar un albergue para esa web en una empresa de hosting

Hay albergues gratuitos (con funcionalidades muy limitadas y dominios muy malos) y también hay albergues de pago. Y sobre éstos últimos hay también infinidad de posibilidades, pero normalmente se suele pagar por el tráfico y espacio de almacenamiento contratado. El problema es que si de repente tu web empieza a tener muchas visitas o tu web necesita más espacio de almacenamiento de lo previsto, sueles tener que contratar un hosting de mejores características y más caro. Para que os hagáis una idea de los costes, esto es un ejemplo de los precios de Dinahosting para albergues en este sentido, orientados a una web mínima.

Estaríamos hablando de un coste entre 15 y 142,56 euros al año. Y que conste que no me parece nada caro, sobre todo porque Dinahosting no pone límites en cuanto a la transferencia de datos, pero hay que tener en cuenta que nuestra web estaría compartiendo la velocidad del servidor en el que está instalado con otras webs alojadas en el mismo hosting, así que no podemos esperar grandes rendimientos en estas opciones.

Oye... ¿Cuánto te da Dinahosting por la publicidad? 

Nada Usuario Anónimo. Pongo estos datos porque la empresa en la que trabajo usa algunos servicios de este hosting y para el artículo quiero hablaros de servicios que conozco y que he usado personalmente (y he de decir que aunque muchos de los servicios de dinahosting no cuadran en absoluto para lo que queremos hacer en estos artículos, no están nada mal y he tenido muy buenas experiencias con ellos). De hecho en este artículo os hablaré de otras empresas similares más adelante.

¡Pero yo no quiero contratar nada! Estoy pelao. No me quiero gastar ni un duro. 

Puedes estar tranquilo. Recuerda que sólo estoy poniendo todo esto para poner en contexto los costes que nos podríamos ahorrar autoalojando nuestras webs. Y para el que se lo pregunte: sí… es mucho más cómodo pagar un hosting para colgar tu web que montarse un servidor particular, aunque sea en una Raspberry, pero además de aprender muchísimo sobre diferentes tecnologías, veremos que nos podemos ahorrar muchísimo dinero si nos animamos a autohospedar nuestras webs en un equipo de nuestro hogar. Repito: no somos una empresa, sinó usuarios particulares que quieren aprender a autohospedar servicios.

Además, algo muy importante es que un albergue como el que acabamos de ver en una empresa de hosting sólo serviría para alojar una web y correo. No nos permitiría montar nada que se salga de ahí (nada de montar un pi-hole y ya ni que decir tiene un aMule o similar). Así que por ejemplo esta opción ya no nos serviría para nada de lo que hemos hecho en los anteriores artículos.

2) Contratar un VPS (Virtual Private Server o Servidor Privado Virtual).

Con un VPS tenemos en el fondo algo similar. Contratamos también un espacio limitado en disco y el servidor es compartido entre varios usuarios, pero el servidor está virtualizado. Lo interesante de esta opción es que se contratan también un número determinado de «cores» del servidor, de forma que nos garantizamos un rendimiento mínimo. Cada VPS funciona de forma independiente como si fuera un servidor dedicado, pero en el fondo el servidor real está corriendo varios VPS simultáneamente. Con esta opción obtendremos siempre mejores rendimientos, pero también los costes se dispararían bastante. Fijaos.

Ya hablaríamos de entre 430 y 1600 euros al año (con la opción más barata, en dos años el gasto nos da para comprar un pequeño servidor mucho más potente que una Raspberry y aún nos sobraría dinero)… y seguimos sin poder hacer las maravillas que hemos hecho en tutoriales anteriores. DigitalOcean y otros proveedores sí que ofrecen servidores a los que les podemos instalar más cosas y a los que podemos acceder por SSH a unos precios bastante más competitivos (a costa de que nuestros datos acaben en el extranjero, por supuesto), pero luego veremos que aún así nos va a compensar para un proyecto personal montarnos algo a nivel casero.

3) Contratar directamente un servidor de verdad para ti solito.

Esta opción mola mucho porque tendríamos es un servidor al que podríamos acceder de la misma forma que accedemos a nuestra Raspberry (mediante SSH), que estaría mantenido por la empresa con la que contratemos y al que podremos instalarle lo que queramos. Pero os van a hacer gracia los costes. Fijaos.

Ya no me voy a poner a calcular el coste anual de estas últimas opciones y por supuesto no voy a discutir que son equipos muy potentes (y a años luz de nuestra Raspberry) con backups y mil opciones interesantes, pero a lo que quiero llegar es que con una simple Raspberry podemos llegar a montarnos un sistema que a nivel personal (no para una empresa, obviamente) pueda ofrecernos en algunos casos características mejores que cualquiera de estas opciones.

Espero que eso que estés diciendo sea una broma ¿No? ¿Me estás comparando mi cutri-Raspberry con un Lenovo SR630?

No, no es una broma. Un disco SSD de 2 TB puede llegar a costarnos 130 euros en Amazon. Si lo conectamos a nuestra Raspberry estaríamos superando en almacenamiento cualquiera de esas opciones. Y en cuanto a CPU’s nuestra raspberry con 4 núcleos podría hasta competir con el rendimiento de algunos VPS’s (por supuesto dependiendo de lo saturado del servidor VPS).

Vamos, que si lo que queremos es tener servicios web disponibles para nosotros en internet, como una nube de archivos personal, o una página web con un servicio determinado, pero a la que sólo vayamos a acceder nosotros o un grupo muy reducido de personas, tirarse a contratar servicios de alojamiento, si lo piensas es una verdadera locura. Con lo que te gastas en dos años en el VPS más grande de los que te he puesto, te pagas un servidor «de verdad» a años luz de una simple Raspberry, con mucho más almacenamiento, que te puede durar bastantes años, y todo esto junto con un buen sistema de copias de seguridad porque te ha sobrado dinero. De hecho muchas empresas están empezando a dejar de «adorar» la nube y montarse sus propias nubes con hardware propio. Y si lo estás pensando: el coste en electricidad de tener una Raspberry encendida las 24 horas del día es irrisorio. Incluso lo es el coste de tener encendido un pequeño ordenador las 24 horas del día. Yo tengo uno y, monitorizando lo que pago de luz, no he notado diferencias entre las facturas de antes y después de ponerlo.

En todo caso creo conveniente de nuevo aclarar una cosa: Estos últimos precios no son asumibles para una economía doméstica, pero evidentemente son algo muy a tener en cuenta en proyectos de determinadas empresas. Que no cuadre en absoluto con lo que vamos a hacer nosotros no quiere decir que sea un mal producto, sinó que está enfocado a un público muy distinto al de un usuario doméstico y el producto ofrece cosas completamente distintas a lo que queremos. Siguiendo el ejemplo que os puse antes, a lo mejor a una empresa le da un poco igual tener un TB o dos TB de espacio de almacenamiento, pero lo que no le va a dar igual es no tener las copias de seguridad y la fiabilidad que le puede dar la infraestructura de un hosting profesional.

Requisitos para poder autoalojar nuestras propias webs.

Algo que tenemos que tener muy en cuenta es que, para poder publicar nuestras páginas en internet colgadas únicamente de nuestro hardware, vamos a necesitar tener todo lo que os voy a indicar en la siguiente lista.

1) Hardware dónde vamos a almacenar nuestra web.

Para darle continuidad a nuestra serie de artículos de Docker sobre Raspberry, vamos a centrar todas estas instalaciones en una simple Raspberry. No vamos a necesitar ningún equipo más potente.

Pero una Raspberry es un equipo con un hardware muy limitado. No va a tener potencia para alojar una web.

Para tu información esta web que estás viendo estuvo alojada en una simple Raspberry Pi 2 desde el 2015, luego en una 3B+ y hubo que esperar hasta el 2020 para decidirme a hospedarla en un servidor Linux más grande (básicamente en un ordenador que tengo encendido en mi casa). Y si ahora no está alojada en una Raspberry créeme que no es porque no le llegue la potencia para mover la página, sino porque en el equipo en el que está alojada ahora mismo quería montar simultáneamente un montón de sistemas operativos a mayores (digamos… que esta web está montada en mi propio VPS). Te aseguro que cuando la tenía alojada en la Raspberry la web tenía un rendimiento muy similar al que tiene ahora.

Pero eso es porque no te visita ni el Tato. Si tienes muchas visitas en la web otro gallo cantaría. 

Por una vez tienes parte de razón (pero sólo parte). Esta web suele recibir unas 300-400 visitas al día. Alguna vez que ha salido en portada de algún medio importante de comunicación ha llegado a las 1.500 visitas diarias, que no está nada mal para un blog personal… y la Raspberry ni se ha enterado (y menos aún cuando ha pasado estando ya alojada en el nuevo servidor). Muchos pequeños blogs que tienen la suerte de acabar en la portada de «menéame» (Que es el principal agregador de noticias de España) sufren lo que se ha acabado por llamar «El efecto menéame» (Que no es otra cosa que el aumento exponencial del número de visitantes a la web) y si esa página está alojada en un sitio barato o con un tráfico contratado limitado, la web al final acaba con un mensaje de error porque se ha excedido del tráfico contratado. Eso es algo que no me ha pasado jamás desde que la autoalojo. Para un blog personal o una página que por el motivo que sea sólo la vas a usar tú, una Raspberry debería ser más que suficiente incluso con un volumen medio de visitas.

Venga, vale. Pero hay proyectos muy grandes como Nextcloud, que puedes enfocar para uso personal y que requieren más hardware que este cutri-blog. 

Te voy a poner de nuevo el mismo ejemplo. Simultáneamente a esta web, en mi Raspberry tuve una instalación de Nextcloud durante muchos años y te garantizo que la Raspberry puede con ella. Para el que no lo conozca, Nextcloud te crea una nube de almacenamiento de archivos muy similar a Dropbox o One Drive pero con muchas más funcionalidades. En todo caso es importante matizar una cosa: esa instalación la usábamos dos personas para uso personal. Si te planteas crear un Nextcloud que se use en una pequeña empresa en la que la subida y descarga de archivos sea constante y sea usado por varios usuarios de forma simultánea, deberías plantearte alojarlo en un equipo algo más potente (Sí… en ese caso usar algo tan básico como una Raspberry sería un suicidio). Pero tampoco sería como para contratar un servidor de miles de euros. De nuevo te podría hablar de una instalación que he hecho sobre un core i3 en la que se movía un nextcloud con 200 usuarios. Cero problemas en ningún momento. No hacen falta grandes equipos para este tipo de proyectos en Linux.

2) Dirección ip pública.

Este punto es muy importante. Si queremos autoalojar una web en un equipo enchufado a nuestra conexión de internet, es importantísimo que podamos acceder a la conexión desde fuera. Si nuestro proveedor de internet nos da una línea con CG-NAT (Es decir, que la ip a través de la cual accedemos a internet está compartida con varios clientes de la operadora), no podremos montar un servidor casero de forma medianamente decente. En ese caso lo mejor es llamar a nuestro proveedor y decirles que nos den una IP pública para nosotros sólos. Y si no nos la dan… lo mejor es cambiarse de operador de internet.

Pero hará falta una ip fija para nuestra web ¿No? Porque cada vez que reinicio el router la ip cambia. 

No necesariamente. Siempre es mejor tener una IP fija, pero si no la tienes vas a poder montar todo lo que vamos a ver en los siguientes tutoriales sin ningún problema. Una ip fija el mayor problema que tiene es que no te permite crear un servidor de correo en condiciones normales, pero aún en ese caso existen métodos para sortear esa limitación. En todo caso, como estos tutoriales son a nivel básico sólo vamos a ver cómo crear webs, no servidores de correo.

¡No me digas que no nos vas a explicar cómo crear un servidor de correo! ¡Pero si yo sé que tú has montado ya unos cuantos, gamberro!

Ya, pero un servidor de correo tiene muchísimos servicios diferentes corriendo a la vez. Es más complicado de lo que parece. No creo conveniente que en tutoriales de iniciación a Docker nos pongamos a instalar algo cuyo docker-compose.yml llega a 600 líneas de código.

Qué exagerado eres. Si hay servicios como mail-in-a-box o sobre todo IRedMail que tienen dockers-compose mucho más pequeñitos. Y lo sabes.

Venga va. Te doy la razón. He ido a por uno grandote y de hecho he usado IRedMail durante muchos años en una Raspberry (y me ha dado muchas alegrías), al igual que Mail-in-a-box en otros proyectos. Pero un servidor de correo tiene mil problemáticas asociadas: listas negras, un montón de puertos diferentes, diferentes tecnologías y protocolos, problemas con ip’s variables, baneos de dominios, etc… Crear un servidor de correo mola mucho, pero es algo que por si sólo ya da para una serie larga de tutoriales. A modo de recomendación, meteos en esos fregaos únicamente cuando hayáis dominado primero toda la problemática que conlleva el alojamiento de una página web en un servidor propio.

Volviendo a la problemática sobre CG-NAT, he de decir que en realidad conozco un método para sortear estos problemas y poder montar un servidor web sobre CG-NAT. Simplemente es usar el servicio de Cloudflare Tunnel, pero requiere que el dominio lo gestione la propia Cloudflare y a pesar de tener muchas ventajas, también tiene inconvenientes (el tráfico pasa por más sitios y vas a perder rendimiento). No os puedo recomendar que os metáis en estos fregaos, sobre todo si necesitáis rendimiento en la página web. Además no podemos olvidar que estamos en un tutorial de iniciación para crear páginas web, por lo que… olvídate de este comentario. Quédate con que no se puede colgar una web de una conexión a internet que use CG-NAT. Punto.

3) Dominio para nuestra web.

Cuando nos dirigimos a cualquier página web, normalmente en nuestro navegador tenemos que poner en la barra de direcciones su dominio. Por ejemplo, en el caso de este blog, para acceder a él pondríamos «flopy.es». Las webs que vamos a colgar van a necesitar también un dominio para poder dirigirnos a ellas.

Espera, espera... ¿Un dominio para cada una de ellas? ¿Eso quiere decir que si alojo 5 webs necesito comprar 5 dominios? Me da que este experimento puede salirnos por un ojo de la cara. 

No te asustes. Si queremos, con un dominio será más que suficiente para alojar todas las webs que queramos. Lo verás un poco más adelante en este mismo punto.

Como decíamos, necesitamos un dominio. Los dominios los suelo dividir en dos tipos:

Dominios gratuitos.

Hay algunos sitios en internet que nos ofrecen dominios de forma completamente gratuíta. Si no os queréis gastar ni un duro, recomiendo que le echéis un vistazo a éste sitio:

https://dnsexit.com

Ahí podréis conseguir un dominio «feo» pero válido para alojar una web y tener algunas herramientas interesantes para gestionarlo.

Bueno... lo de feo me da igual. Veo que puedo conseguir ahí direcciones del tipo "miweb.linkpc.net". No es algo como miweb.com pero no está mal si puedo hacer de todo con él. 

No te engañes. No puedes hacer de todo. Un dominio de este tipo te permitirá alojar una web sin problemas y te servirá para proyectos personales. Sin embargo el problema es que cualquier dominio «gratuito» siempre está señalado en listas negras, de forma que si en el futuro quieres montar en él por ejemplo un servidor de correo, te va a ser imposible que funcione correctamente aunque la configuración sea la más correcta del mundo. Los correos que envíes no llegarán nunca a su destino porque al ser el dominio principal gratuito y compartido por miles de usuarios, va a haber mucha gente que los use para mandar spam. Pero oye… una web sí que vas a poder alojarla. Si sólo es eso lo que quieres es una opción válida.

Por cierto… este problema no sólo ocurre con dominios «feos» como los que da DNSExit. También pasa con cualquier dominio que se pueda conseguir de forma gratuíta, como los míticos «.tk«. Son más «bonitos», pero cualquier dominio acabado en «.tk» va a estar baneado por el resto de servidores de correo.

En todo caso hay una cosa que debes tener muy en cuenta. Si no tienes una IP fija (como la mayoría de la gente que tiene una conexión a internet doméstica) vas a necesitar que la empresa que te ofrece el dominio te ofrezca también una herramienta que permita asociar el dominio con tu ip (que va a ir cambiando con el tiempo). Si no la ofrece vas a tener un problema serio. Por eso me gusta DNSExit. Esa herramienta la ofrece y es completamente gratuita tanto para dominios gratis como para los dominios de pago.

Dominios de pago

Evidentemente si optamos por comprar un dominio, dependiendo del dominio que vayas a comprar no vas a tener problemas para alojar lo que quieras.

¿Cómo que dependiendo del dominio? ¿Si compro un dominio de pago no puedo montar en él lo que me dé la gana?

Pues no. Hay dominios que históricamente se han usado para… digamos… cosas rarunas y poco legítimas, así que aunque sean de pago nadie se fia de ellos. Por ejemplo, conozco a una persona que compró un dominio del tipo «miweb.site» y luego se tiró de los pelos al comprobar que sus correos no llegaban porque cualquier dominio terminado en «.site» está en listas negras siempre.

Vale... entonces entiendo que estoy obligado a comprar un ".com" si quiero poder hacer cualquier cosa con el dominio. 

Para nada. Fíjate que este blog es un «.es». Ese dominio es más barato que un «.com». Personalmente he tenido que alojar también cosas en dominios terminados en «.com.es», «.org» y «.net» y cero problemas. Son dominios que siempre salen más baratos que un «.com» y elegirlos es una opción perfectamente válida.

¿Y lo que decías en los dominios gratuitos acerca de las ip's variables? Supongo que la herramienta para asignar la ip pública al dominio la ofrecen todos los proveedores de dominios de pago ¿No?

Pues va a ser que no. Personalmente, si se trata de dominios de pago, tengo muy buena experiencia con «Dondominio» precisamente por este tema: ofrecen una herramienta para asociar el dominio a la ip que funciona realmente bien (y de hecho es la que uso en este mismo blog). Sé que Dinahosting también tiene una herramienta similar pero personalmente no la he llegado a probar, así que no os puedo dar más referencias, pero supongo que será muy similar.

Y por cierto… tal y cómo os decía, con un único dominio nos llega. Si tenemos por ejemplo el dominio «berenjenas.com«, puedo poner una web de venta de Berenjenas en «berenjenas.com», un Nextcloud personal en «nextcloud.berenjenas.com» y una wiki con instrucciones de cómo prepararlas en «wiki.berenjenas.com». Con un único dominio podemos tener un montón de webs diferentes con tecnologías diferentes (incluso usando tecnologías incompatibles entre ellas). Un único dominio os servirá para muchísimos proyectos diferentes.

4) Certificado https.

Desde hace ya unos años, los navegadores de internet (Firefox, Google Chrome… ¿Existe algún otro? 🤣) exigen que las páginas web tengan un certificado de seguridad, de forma que si alguien intercepta las conexiones, el navegador muestra un error en el certificado. Si tu web no tiene ese certificado, la web no se podrá ver en los navegadores (más correctamente, dará un error al entrar). Así que es importante que nuestra web disponga de un certificado de seguridad. Además no podemos firmarlo nosotros, sinó una entidad de certificación.

¿Qué me dices? ¿Y cómo demonios voy a conseguir eso? ¿Me saldrá muy caro?

Hace unos años conseguir un certificado implicaba pagar uno en una de las entidades que los suministran. Por fortuna, desde que los navegadores han impuesto este tipo de certificados, ha surgido una entidad que se encarga de dar certificados gratuitos a todo el que los solicita: LetsEncrypt.

Hay algo que no me cuadra. Si le dan certificado a todo quisqui sin pagar un duro y sin control... Entonces el certificado no sirve para nada ¿No? Puedo pedir uno para tu web y luego usarlo yo para lo que me venga en gana. 

Pues no. Cuando lo solicitas lo haces para una web en concreto. Pero hay un control importante para garantizar que no estés pidiendo un certificado para una web que no es tuya y que deseas hackear. LetsEncrypt nos va a pedir al solicitar el certificado que coloquemos en un sitio muy raro de nuestra web un archivo determinado que nos proporcionan ellos y que sólo sirve para nuestro dominio. Sólo si ellos son capaces de acceder a ese archivo nos dan el certificado, y ese certificado y ese certificado es el que debemos poner en la configuración de la web. El certificado dura sólo tres meses y para renovarlo cada tres meses hay que hacer casi los mismos pasos, pero…

Espera, espera. Pedir el certificado parece que es un coñazo. La renovación suena también a proceso que hay que hacer con calma ¿y aún encima hay que hacer esto cada tres meses? ¡Quiero dedicar mi vida a algo más que renovar certificados!

No te asustes. Todo esto se puede automatizar. Hay muchos sistemas que automatizan tanto la petición del certificado como la renovación. De hecho en las webs que vamos a crear usaremos un programa para ello que va a permitir olvidarnos de todas las renovaciones, porque las hará sin que nos enteremos. Crear todo lo relativo al dominio (certificado incluído) no debería llevarnos en la practica más de 5 minutos.

En todo caso es importante saber que esto lo vamos a necesitar. Es una parte importante en las webs de hoy en día.

5) Software de servidor web.

Una página web necesita un software que funcione como servidor para que esté disponible en internet. Existen bastantes softwares de este tipo, aunque los más conocidos (y usados) son Apache y Nginx. Estos programas se encargarán de hacer que tu página web funcione y se la darán al ordenador que la pida, junto con el certificado de seguridad.

Cualquiera de estos servidores web tienen bastante lío de configuraciones (que si protocolos, que si certificados, plugins por aquí, versiones de php por allá, etc…), pero como nosotros lo vamos a dockerizar todo no nos van a dar la lata.

¿Cómo es el proceso de funcionamiento de una página web?

La forma en la que funciona una página web no es complicada de entender. Vamos a ver los pasos que se siguen cuando alguien accede a tu dominio.

Imaginemos que tienes en tu casa un servidor web configurado con el dominio «berenjenas.com» listo para ser usado. Tu hermana vegetariana está pasando mucha hambre hoy, así que encuentra tu dominio y lo escribe en el navegador.

Vegetariana dice... ¡si yo te contara...!

En ese momento, el navegador de tu hermana no accede directamente a tu servidor, sino que primero consulta con el servidor de DNS configurado en su ordenador (normalmente estos servidores vienen preconfigurados por el proveedor de internet) para averiguar a qué dirección IP pública corresponde el dominio. Si tu página web está bien configurada, el navegador recibirá la correspondencia entre la dirección web y tu IP pública.

Entonces, el navegador de internet enviará una solicitud a tu IP pública diciendo: «Hola, ¿hay por aquí algún servidor web? Necesito que alguien me dé la página berenjenas.com». Tu servidor web (Nginx, por ejemplo) responderá: «Aquí estoy yo y mis webs. Toma berenjenas.com. Ah, y voy a usar este certificado». El navegador de tu hermana cotejará el certificado que le ha entregado con los certificados raíz que tiene de LetsEncrypt (los navegadores tienen certificados raíz de las principales autoridades certificadoras) y si ve que el certificado es válido, mostrará la web.

Ufff... todo esto suena demasiado complicado. ¿Seguro que va a ser sencillo montar un servidor web?

Depende de cómo lo montes. Evidentemente os voy a dar los pasos para que nos sea increíblemente sencillo hacerlo, pero no siempre ha sido tan fácil. Fíjate en los siguientes puntos.

¿Cuál es la forma tradicional de montar un servidor web?

Históricamente para montar un servidor web debíamos seguir aproximadamente estos pasos.

1. Tener un dominio y dirigirlo a nuestra ip pública.
2. Si la ip pública es variable, habría que instalar un programa que vigile si cambia nuestra ip. Cada vez que cambie, ese programa debería actualizar la ip a la que nuestro dominio dirige las peticiones.
3. Los puertos 80 y 443 del router deberían estar mapeados hacia la ip local de nuestro servidor.
4. En el equipo en el que vamos a alojar las webs deberíamos tener un software que ofreciera las páginas que tenemos alojadas a los ordenadores que las soliciten (un servidor Web como Apache, Nginx, LiteSpeed, lighttp…). Deberíamos configurarlo para que ofreciera una página u otra distinta según la dirección del dominio que apunte hacia nuestra ip pública.
5. En cada web deberíamos gestionar su certificado https y gestionar su renovación.
6. Muchas de las webs actuales necesitan tecnologías a mayores (php, bases de datos como MySQL o MariaDB…). En ese caso deberíamos instalar y configurar todo lo relativo a estas tecnologías.
7. Rezar para que todo esto funcione y que si haces un cambio en una web no afecte al resto.

¿Cual es la forma que vamos a proponer para desplegar webs de forma sencilla?

El esquema va a variar bastante en los pasos finales. Fijaos.

1. Tener un dominio y dirigirlo a nuestra ip pública. Eso siempre lo vamos a necesitar.
2. Si tenemos ip varible, toca usar un programa que nos solucione la problemática. Este punto tampoco varía.
3. Mapear los puertos 80 y 443 a la ip pública de nuestro servidor. También es el mismo punto que antes.
4. En el equipo que haga de servidor, instalaremos un Proxy (en un Docker). Se trata de un programa que haga de intermediario entre el servidor final y el navegador que solicita la web. Cuando se le pida una web, dependiendo de la web que se le solicite, le pedirá al servidor real la página y se la ofrecerá al navegador. El proxy que vamos a usar permite configurar todo de forma gráfica (desde un panel de control) y ya gestiona él automáticamente toda la problemática de certificados https. No va a haber que andar escribiendo archivos de configuración ni nada de eso. Básicamente, primero debemos instalar el docker que nos generará la web que nos interesa, y luego debermos configurar el proxy desde su propio panel de control. No os asustéis que es muy sencillo.
5. Instalaremos un Docker por cada una de las páginas web que queramos instalar. Como ya están dockerizadas, cada una de estas páginas ya tendrá todo lo necesario para que funcionen (php, mysql, apache, etc…). Si por el motivo que sea una de las páginas falla, el resto no tendrían por qué verse afectadas en absoluto. Además los autores ya se han preocupado de configurar todas las tecnologías y dependencias para que funcionen correctamente. Será simplemente instalar y empezar a usar.

Si os fijáis, con este esquema nos olvidamos de:

• Configurar a mano tecnologías y particularidades de cada web (protocolos, versiones de php, bases de datos, conexiones entre tecnologías, etc…).
• Configurar y gestionar el certificado https (se hará sólo una vez y de forma gráfica cuando demos de alta cada una de las webs).
• En general, no vamos a tener que tocar archivos de configuración para nada. Una vez que creemos cada uno de los dockers, la configuración de cada web se hará de forma gráfica en el proxy.

Vamos... que lo gordo lo va a gestionar el proxy. ¿Y qué proxy vamos a usar? Porque supongo que habrá unos cuantos dónde elegir. 

Efectivamente. Todos los servidores Web se pueden configurar como proxys. Puedes hacer uno con Apache, Nginx, etc. Yo de hecho en algunas instalaciones uso Apache como proxy (sí… lo reconozco… soy más «Apachero» que «Nginxista»). Pero en lugar de instalar el servidor web y configurarlo como Proxy a pelo (que la configuración es un poco lío) podemos hacer algo mucho mejor. Vamos a Instalar un docker que nos instala un Nginx ya preparado para hacer de proxy (Llamado «Nginx Proxy Manager«). Además este docker tendrá un completo interfaz web desde el que podremos configurar absolutamente todo. Será algo como ésto:

Problemas de este esquema.

No os voy a engañar. Lo que vamos a hacer tiene un problema que…

¿Cómo que un problema? Si hay un problema seguro que sabes alguna otra forma de hacer la cosas sin ese problema. ¿Por qué no vas más al grano y nos dices la forma correcta de hacer las cosas en lugar de hacernos dar vueltas con ñapas?

Pues porque antes de construir cohetes hay que aprender a hacer avioncitos de papel, Usuario Anónimo. El proxy que vamos a emplear nos permitirá que las webs que vamos a poner en marcha funcionen sin ningún problema… excepto en cuanto al rendimiento bruto porque la conexión va a dar unas cuantas vueltas. Me explico.

Cuando alguien pida una página que tengamos alojada, la petición entrará por el router (por nuestra ip pública), que tiene los puertos del servidor web mapeados hacia nuestra Raspberry (host). Pero Docker tiene mapeado ese puerto hacia el Docker del nginx por lo que la conexión se va a ese Docker… Pero el nginx lo configuraremos para que coja la petición de un puerto concreto del host… Pero ese puerto del host es realmente del Docker dónde está la web…. Vamos, que la conexión va a parecer un canguro con tanto salto.

Ostras Pedrín. Pero ¿Esto que vamos a hacer no es una chapuza?

En cierto sentido sí que lo es. Pero ten en cuenta que lo que pretendo es no liaros la cabeza más de lo necesario. Este esquema es el que usa mucha gente para sus propios dockers y a pesar de que no es lo más óptimo para lograr altas velocidades de conexión, sí que nos permitirá que todo funcione al momento con un par de clicks de ratón. ¿Cuál es el problema que vamos a tener si somos frikis nivel 10? Imaginad que tenemos un docker que por el motivo que sea necesite un rendimiento extraordinario. Poned como ejemplo un docker que sea un simple Nextcloud (un sistema en el que puedes subir y bajar archivos a tu web). Si descargas un archivo de ese nextcloud, esa descarga en lugar de ir, por ejemplo, a 70-90 Mb/Seg irá a 10 – 30 Mb/seg (son cifras aproximadas) . Y pasaría lo mismo si tienes una web con cientos de miles de descargas. Tendrás ahí un cuello de botella importante.

¡Virgencita del traje de buzo! ¡Pero entonces esto es grave! ¡No nos va a servir para nada!

En absoluto. Tal y cómo os dije, estamos colgando todo esto de una Raspberry. No vamos a pretender tener unas velocidades de transferencia extraordinarias. No perdáis de vista que todo esto lo estamos enfocando a un uso personal, por lo que en la práctica, salvo en usos muy muy concretos no vais a tener ningún problema.

Pero... Pero... ¿Y si quiero tener todo el rendimiento? ¡Lo quiero todo! ¡¡¡¡TODOOOOO!!!!

Pues en ese caso por supuesto que hay soluciones. Si quieres no perder rendimiento te recomendaría usar Traefik en lugar de Nginx Proxy Manager, pero va a requerir trabajar mucho los proxys que tienes instalados, así como realizar bastantes configuraciones en Traefik. Repito: no es el objetivo de estos artículos, así que por el momento no nos vamos a meter en esos fregaos. Eso lo dejaremos para cuando tengamos claros los conceptos que intentamos transmitir en esta serie de tutoriales. El método que vamos a ver os va a sorprender de lo sencillo que es.

En fin: como este artículo se ha alargado demasiado, por hoy lo vamos a dejar aquí. En el próximo artículo instalaremos en nuestra Raspberry Nginx Proxy Manager, mapearemos los puertos necesarios a nuestra Raspberry, dirigiremos un dominio a nuestra ip pública y por último haremos que una dirección de nuestro dominio apunte a la web que nos ha generado el aMule (que al fin y al cabo es una web que ya tenemos funcionando y nos servirá perfectamente como ejemplo de lo que haremos más adelante). Además también generaremos un certificado de seguridad de forma que a esa web se pueda acceder por HTTPS desde internet en lugar de por HTTP. ¿Os parece complicado? ¿Habéis montado en algún momento algún tipo de servidor web o proxy? Me encantará leer vuestros comentarios al respecto.