Hola Gustavo,
A grandes razgos los contenedores son simplemente máquinas virtuales hiper livianas que utilizan las posibilidades del hardware + kernel sobre el anfitrión en que corren para generar entornos de ejecución modulares y flexibles.
Existen dos enfoques principales cuando hablamos de contenedores: los containers orientados a aplicaciones - como Docker - y aquellos orientados a la virtualización bajo nivel como LXC.
Docker - desarrollado principalmente para GNU+Linux y portado a FreeBSD, OS X y Windows - utiliza los recursos de los nuevos kernels (como cgroups, namespaces, etc.) para crear un bootstrap sobre el que bootear un OS mínimo. La idea es que al usar los recursos que provee el propio kernel del host + un sistema operativo básico tengas un entorno listo para instalar la(s) aplicación(es) que desees correr: idealmente los contenedores al ser máquinas virtuales muy livianas se utilizan para correr sólo una aplicación a modo de aprovechar al máximo la modularidad y flexibilidad del format0 - condensado en una palabra, microservicios.
Vamos con un ejemplo:
La forma tradicional de armar la solución que requerís implica instalar los distintos componentes (PostgreSQL, Kettle, foo, bar) sobre un sistema base - con todas las desventajas que conlleva, entre otras:
1. Siempre existe la posibilidad que algo salga mal y el sistema se rompa teniendo un downtime variable de acuerdo al tiempo que requiera repararlo o restaurarlo;
2. Fedora - como el resto de los SO que nombramos - no permite la instalación paralela de distintas versiones [0] de la misma aplicación (por lo menos no de forma oficial a través de los repositorios) con los problemas que conlleva: a) necesidad de distintos ambientes de testing para c/ versión del toolchain involucrado, b) sobrecarga de trabajo para administrar los sistemas, c) metodología engorrosa tanto para los desarrolladores como para los admines, d) planificación y testeo dedicado antes de actualizar versiones, e) etc.
3. Limitaciones tanto en la capacidad como en los procesos para escalar tu solución;
4. Capacidad de failover ante fallas técnicas o humanas;
5. Dificultad al momento de realizar el hardening de la solución;
6. ...
Un ambiente basado en contenedores de aplicación (microservicios) nos permite solucionar estos y muchos más de los problemas con los que nos encontramos al implementar y administrar una solución de SW.
Veamos ahora como sería el diseño de una arquitectura basada en contenedores Docker para instalar Pentaho (o parte de sus componentes):
1. Sobre una instalación de mínima de un SO anfitrión instalamos Docker y las herramientas base a nivel sistema que podamos necesitar (como Fish shell, tmux, Emacs, sshfs, Midnight Commander, etc.);
2. Paso seguido es crear imágenes base con las versiones de las herramientas necesarias armando archivos de instrucciones llamado Dockerfile: este archivo contiene los pasos necesarios para que Docker cree la imágen de acuerdo a nuestros requerimientos. Se define sistema operativo, pull del código + flags para compilación + parches que necesitemos aplicar (o simplemente instalación de la tool vía los repos oficiales del SO que usamos como base), creación de usuarios, directorios y compartición de acuerdo a lo que necesitemos realizar así como seteo de configuraciones - es decir se automatiza el proceso que generalmente hacemos a mano c/ vez que replicamos un ambiente similar;
3. Con la imágen base armada podemos entonces levantar un contenedor. Un contenedor es simplemente un layer o snapshot de la imágen anterior. Por ejemplo: nuestra imágen base es un CentOS 7 mínimo con la versión de los repositorios de PostgreSQL ya configurada y lista para acceder via un puerto o socket como si se tratara de un server Postgre corriendo en localhost u otra máquina; si más tarde realizamos un cambio en dicha imágen la imágen en si no se modifica sino que se crea un layer que contiene las modificaciones y así sucesivamente, se van apilando capas referenciadas con los nuevos cambios.
4. Supongamos que tiempo después se decide migrar a una nueva versión de Postgre: en un ambiente distino a producción (que bien podría incluir Dev / Stg / QA) se realizan las pruebas y eventualmente se decide el pase a producción; a) subimos la imágen con la versión de Postgre homologada a un registro interno; b) en el (o los) servidor(es) de Prod hacemos simplemente un pull de esa imágen y en un nuevo contenedor de Kettle apuntamos la app a que utilice el contenedor con la versión fresquita de Postgre... magia :D Downtime mínimo, failover automatizable (rápidamente podemos reutilizar la imágen anterior y volver al estado previo exacto del ambiente), mínimos recursos y sin tocar el sistema base.
5. En el paso 2 hablo de crear nuestra imágen (para ilustrar la flexibilidad de Docker) pero la mayoría de las herramientas utilizadas hoy en día ya tienen imágenes oficiales mantenidas por los propios desarrolladores que nos brindan la misma seguridad que si las instalaramos desde los repositorios del sistema operativo en cuestión por lo que siempre tenemos la posibilidad de bajarlas y realizar las modificaciones sobre ellas usando alguna herramienta de automatización tipo SaltStack, Ansible, Puppet o Chef.
6. Esta flexibilidad modular - por eso a Docker se lo ilustra como un carguero con 'contenedores' (cuak!) intercambiables - crea una dimensión completamente nueva al momento de crear ambientes de desarrollo y testing o diagramar soluciones escalables.
Supongamos que tu solución tiene picos de uso que superan los requerimientos normales de recursos de HW; con una arquitectura basada en contenedores es relativamente sencillo implementar un sistema de autoescalabilidad de acuerdo a los parámetros que nos interesen, por ejemplo: tenemos una webapp especializada en promociones que tiene picos de uso los fines de semana, podemos programar que en determinado momento - viernes por la tarde - o bajo una carga determinada de procesador o requests al servidor web principal se inicien varias imágenes, una con un load balancer que distribuya la carga entre las imágenes que ejecutan réplicas del servidor web principal - y todas ellas a su vez compartiendo el mismo directorio NFS o GlusterFS que aloja la información de la webapp. Una vez que la carga general del sistema (load average, webhits, whatever criterio elegido) regresa a los parámetros que consideramos normales (X load durante Y tiempo) se apagan los contenedores que ya no se necesitan.
Obviamente este un ejemplo burdo porque hoy los cloud providers nos permiten hacer exactamente esto de una forma mucho más práctica, fácil y segura - pero la idea general es exactamente la misma, lo que me interesa es que visualices cómo mejora radicalmente el workflow usar contenedores correctamente, sin dudas son un game-changer.
Esto sobre Docker o contenedores orientados a microservicios (hay algunos más).
Sobre los contenedores orientados a la virtualización, como los Linux Containers (LXC):
LXC fueron desarrollados para virtualizar hardware completo por lo que si bien se pueden usarse para microservicios no es lo ideal ya que carecen de la flexibilidad necesaria para ello.
Y no está mal, porque LXC brilla en todo lo relacionado a bajo nivel!
Sin entrar en detalle porque honestamente desconozco su funcionamiento más allá de algunas cuestiones superficiales los LXC permiten por ejemplo crear VMs hiperlivianas al estilo Docker pero más intimamente conectada al host [1] con lo por ejemplo podrías crear distintos contenedores corriendo un OS mínimo y c/u conectado a una VPN - y de esa forma conectarte a más de una VPN al mismo tiempo ruteando el acceso a la net de las aplicaciones que corras a través de c/u de esos contenedores, awesome!
De hecho los LXC son especialmente eficacez para la creación de networking virtualizado - otro gamechanger que está tomando muchísima velocidad.
Por último y aunque por ahí sea una obviedad es importante decir que mientras los contenedores (tanto de Docker, LXC u otros) cumplan con los requerimientos del engine corriendo en el sistema anfitrión son absolutamente intercambiables, es decir portables entre hosts y plataformas.El mismo contenedor que corre Kettle en tu propia máquina - o en un servidor al que te conectás remotamente, p.e. - funciona en otro SO siempre y cuando la versión del engine (Docker, LXC, etc.) sea la correcta.
Eventualmente y a medida que se vaya desarrollando la tecnología va a permitir crear aplicaciones multiplataforma con muy poco overhead ya que en realidad lo que se va a estar haciendo es correr la aplicación de cara al end-user sobre un micro sistema operativo.
Espero no haberte aburrido!
Saludos.
[0] Excepto, again, Project Atomic que está diseñado especialmente para solucionar estas limitaciones de diseño.
[1] Importante: existe la idea que los contenedores son más 'seguros' para correr aplicaciones potencialmente peligrosas - nada más lejos de la realidad. Justamente al tener un contacto tan estrecho con el sistema anfitrión pueden ser vectores de ataque hacia el sistema base. Si bien siempre buscan reducir los permisos al mínimo necesario para correr c/u de los servicios necesarios ('Deny all' de forma predeterminada) por su propia naturaleza es muy difícil de aislarlos completmente del host. Los contenedores NO SON SANDBOXES; por supuesto que son muy cómodos para testear software sin romper el sistema principal pero hay que tener en cuenta que un software potencialmente peligroso corriendo como root dentro de un container podría técnicamente escaparse al sistema principal.