A estas alturas, si recopilamos todo lo que hemos hecho gracias a Docker en los 14 artículos que llevamos realizados, aún podemos hacer un listado interesante: Plex, Pi-hole, aMule, Nginx Proxy Manager, Nextcloud… y unas cuantas aplicaciones más que no pongo por no aburrir al personal.
Ahora vamos a instalar algo que seguro que nos será muy útil en nuestro día a día. Vamos a instalar Vaultwarden, que es un gestor de contraseñas en nube que…
¡PARA! ¡Que te he pillao! Nos quieres duplicar un artículo. Eso ya lo explicaste en este enlace. No nos vengas a reexplicar lo ya explicado.
No Usuario Anónimo. Soy consciente de que la instalación de VaultWarden se explicó muy ampliamente en ese artículo que nos dices, pero en esta serie de tutoriales estamos viendo cómo instalar todo sobre Docker Compose y en esa instalación usamos en su momento Docker CLI (os recuerdo que las diferencias entre ambos las vimos en este otro artículo).
Así que en este artículo no vamos a explicar cómo se usa VaultWarden ni las ventajas de usar un gestor de contraseñas. Para todo eso os remito a ese mismo artículo. Aquí lo que vamos a explicar es cómo instalarlo mediante Docker Compose, pero sobre todo me interesa que sepáis convertir un Docker CLI en un Docker Compose, y por eso nos viene de perlas ese mismo artículo. Quiero que cuando terminéis de leer el artículo no os dé miedo tener que convertir cualquier Docker CLI que hayáis visto en internet en un Docker Compose.
Recordad que Docker Cli (Command Line Interface) es la herramienta más básica que existe para interactuar con Docker, pero sólo puede ejecutar un contenedor a la vez.
Docker Compose sin embargo nos permite definir y ejecutar aplicaciones que usan múltiples contenedores (los gestionamos todos a la vez mediante un único archivo de configuración que estamos llamando siempre docker-compose.yml).
Y… ¡Qué caray! Estamos haciendo todo en Docker Compose y hemos conseguido tener todos los dockers super ordenados. No vamos a dejar un contenedor descolgado usando Docker CLI ¿Verdad?
Hemos visto en nuestro último artículo cómo instalar la última version de Raspberry Pi OS en una Raspberry, de forma que quede lista para funcionar como servidor. A partir de ahora vamos a ver cómo instalar varios programas que harán que nuestra Raspberry se convierta en un magnífico servidor doméstico. Sin embargo vamos a instalarlos de una forma un poco especial. En lugar de instalar los programas directamente en el sistema operativo, vamos a usar Docker para meter cada uno en un contenedor separado para que…
Espera, espera. ¿Por qué te complicas tanto la vida? ¿Para qué me va a interesar hacer cosas raras con los programas que vamos a instalar si al final el objetivo es simplemente que funcionen? ¿No podemos simplemente instalarlos y ya está? Hay que ver cómo te gusta retorcer las cosas, majete.
Si no tuviera sentido no estaría aquí dando la chapa y estaría escribiendo sobre otra cosa, Usuario Anónimo. En realidad, sobre todo en servidores, tiene mucho sentido usar Docker en lugar de instalaciones directas de los programas. En este artículo vamos a ver, en primer lugar las ventajas de usar Docker respecto a hacer instalaciones directas para montar un servidor. Luego analizaremos qué tipos de Dockers son los más adecuados para su uso en pequeñas instalaciones y por último aprenderemos a instalar Docker tanto en una Raspberry como en un servidor Debian.
Vale... lo que quieras, pero ¿Qué demonios es eso de docker?
Tiene razón. Debería haber comenzado por ahí. Hazte la imagen mental de que Docker es como un conjunto de archivos empaquetados, sólo que con la característica de que tienen todo lo necesario para que funcione la aplicación que quieres usar (y cuando digo todo lo necesario me refiero a TODO. Archivos, dependencias, librerías, configuraciones, etc…). En lugar de hacer la instalación de la aplicación, haces la instalación de ese docker en concreto, y si lo has hecho correctamente, todo debería funcionar exactamente igual que haciendo la instalación de la forma «tradicional».
Que sí. Vale. Hurra por empaquetar todo, pero ¿Eso de qué me sirve? Si me estás diciendo que al final va a funcionar todo igual. Sigo preguntándome para qué te complicas tanto la vida.
Te voy a poner varios ejemplos en los que vas a ver claro que instalar de esta forma las aplicaciones en un servidor tiene su utilidad.
1) Ventajas de usar Docker en un servidor.
Caso 1: Aplicaciones separadas que requieren versiones diferentes de componentes del sistema (Gestión de dependencias)
Imagina que, por ejemplo, quieres instalar en un único equipo dos aplicaciones que actúen como servidores independientes, por ejemplo, un servidor de Nextcloud y un servidor de OSTicket (podrían ser otro tipo de servicios. Esto sólo es un ejemplo). Puede que la configuración que requiera uno de estos servicios sea diametralmente opuesta a la que requiere el otro. Por ejemplo, puede que uno necesite un componente de linux superior a la versión 8, pero el otro sólo pueda trabajar con versiones inferiores a la 7. En este caso no podrían coexistir las dos instalaciones en el mismo sistema. Docker resuelve este problema, porque cada una de las instalaciones se convertiría en completamente independiente de la otra al estar empaquetadas en dos contenedores distintos. Cada una podría tener sus componentes y ser incompatibles los de un contenedor con el otro, pero funcionar de forma independiente. Cada contenedor sólo debe preocuparse en satisfacer las dependencias de sus componentes, sin preocuparse de las dependencias de otros contenedores que corran en el mismo sistema operativo base.
Caso 2: Paradas, cuelgues o reinicios controlados de una única aplicación.
Imagina ahora que tenemos de nuevo dos aplicaciones en el mismo hardware. Ambas usan el servidor Apache y hemos hecho cambios en una de ellas, pero hemos metido la pata hasta el fondo y ahora, por el motivo que sea, el servicio apache no arranca. Si hubiéramos hecho la instalación de las dos aplicaciones sobre el mismo servidor sin «empaquetarlas», ambas se verían afectadas por la incidencia y ninguna de las dos funcionaría. Con Docker, al correr cada una de forma independiente en dos servidores Apache independientes, lo que hagamos en una no interfiere nunca en lo que hagamos en la otra, por lo que nos podemos equivocar y estropear uno de los dockers pero el otro no se vería afectado en absoluto. Se habrá caído el primero y lo deberemos arreglar, pero el segundo ni se entera. Es más… podemos parar o reiniciar completamente uno de los Dockers y el otro simplemente seguiría funcionando sin preocuparse de lo que hubiera pasado fuera de su empaquetado. Al final, la única forma en la que un contenedor de Docker pueda afectar a otros es que esos contenedores compartan recursos (almacenamiento o tráfico de red). Por ejemplo, si un contenedor se pone a escribir datos en el disco sin parar y llena el disco, evidentemente puede poner todo el sistema en riesgo, pero supongo que entiendes que es un caso muy concreto y obvio.
Caso 3: Rollbacks controlados..
Ahora imagina que sólo tenemos una aplicación. Le hemos realizado una actualización pero descubrimos que esta nueva versión tiene un fallo crítico o no es compatible con ciertos componentes del sistema. En un entorno sin Docker, volver al estado anterior (rollback) puede llegar a ser complicado y arriesgado. A lo mejor tenemos que revertir cambios en todo el sistema y podríamos estar afectando a otras aplicaciones. Sin embargo, con Docker, podemos realizar rollbacks de manera controlada y aislada. Podemos volver a una versión anterior de la imagen de Docker de esa aplicación específica sin afectar otras partes del sistema. Esto nos daría tranquilidad a la hora de deshacer cambios (sabríamos que aunque tocáramos esa aplicación, el resto del sistema se mantendría estable).
Caso 4: Portabilidad
Si hemos desplegado nuestra aplicación en Docker, podremos llevarla junto con todas sus dependencias a cualquier otro equipo que tenga Docker instalado, ya sea en la nube o en un servidor local. Y esto en particular es algo que está muy bien. Por ejemplo, podemos probar nuestra aplicación en un entorno local y si vemos que funciona correctamente, luego podemos migrarla a entorno de producción o a una máquina en la nube sin tener que preocuparnos por configuraciones complicadas o diferencias en el sistema operativo principal de la máquina. Por ejemplo, podemos pasar una aplicación que ya está funcionando en un Debian a un Red Hat o viceversa. Y de nuevo… ¡¡Esto mola mucho!!
Caso 5: Escalabilidad
Esto es algo que viene derivado del caso 4. Imaginaos que tenemos una aplicación en producción (por ejemplo una página web). Funciona perfectamente, pero vemos que nuestra página ha tenido un éxito inusitado y cada vez entra más y más gente y nuestro servidor empieza a no ser suficiente para tramitar tantas peticiones. Las solicitudes de nuestros usuarios empiezan a ir más lentas e incluso se caen. La portabilidad de Docker nos permitirá migrar todo a un servidor más rápido de forma sencilla, otorgándole más recursos en un nuevo sistema.
Y para los más técnicos sólo una puntualización sobre este último punto: para escalar de forma eficiente hay más herramientas que facilitan esta labor y que no vamos a explicar en este artículo (como kubernetes). De momento no vamos a entrar en ellas.
Podría poner más ejemplos, pero creo que a grandes rasgos se entiende que en un servidor mola mucho tener las aplicaciones dockerizadas. Te da mucha libertad a la hora de cambiar la aplicación de servidor y el hecho de tener dependencias separadas puede resolver muchos problemas.
Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.
