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.
Algunos links interesantes:
https://docs.docker.com/linux/
https://kitematic.com/
https://coreos.com/
http://kubernetes.io/ - En el GCPNext16 que se hizo hace un par de días
hubo una talk awesome sobre Kubernetes, seguramente ya esté en YT
https://linuxcontainers.org/lxc/getting-started/
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.
2016-03-30 13:46 GMT-03:00 Gustavo Ibarra <ibarrags(a)gmail.com>:
Hola a todos.
Adrian y Martin...muchas gracias por las respuestas.
Martin, tal cual comentas ya evalúe esas alternativas agregando
OpenSatck. Desconocía
http://www.projectatomic.io/ super
interesante!!!. Pero la verdad es que no termino de entender del todo
el concepto de conetenedores (Docker). Son tantas las herramientas
"cloud" que no me dan el cuero para andar probando cada una de ellas.
Casi seguro que termine usando AWS/EC2 corriendo Pentaho sobre Fedora,
veremos cuan lejos llego.
Adrian. Evalué DonWeb como alternativa, nada mal, eh!. Pero, AWS te
permite apagar y prender el servicio cuando uno quiera, entonces en
teoría los costos se reducen ya que pagas mientras estés
"encendido"(el concepto de "elastic" EC2 también suma como punto a
favor!).....
Saludos,
Gustavo.-
2016-03-30 12:25 GMT-03:00 Martín Cigorraga <msx(a)archlinux.us>:
> Gustavo,
>
> Agrego a lo que comenta Adrián:
>
> 1. Si vos vas a gestionar tu infra investigá GCP (Google Compute
Platform) y
> AWS, éste último proveedor ofrece un tier gratis por un año tanto en
> instancias generales EC2 (VM), storage (S3) y RDS (instancias de
servidores
> de bases de datos relacionales);
> 2. En AWS tenés imágenes Fedora, CentOS, Red Hat y las propias de AWS:
> Amazon Linux (CentOS 6 optimizado para virtualizaciones cloud con kernel
> hardened y herramientas user-land actualizadas);
> 3. Si elegís Fedora, CentOS 7 o Red Hat 7 podés optar por una
arquitectura
> basada en contenedores (ideal!), de hecho Fedora tiene spins
especializados
> para este uso:
www.projectatomic.io
>
> Saludos.
>
>
>
>
> _______________________________________________
> argentina mailing list
> argentina(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/argentina@lists.fedoraproject.org
>
_______________________________________________
argentina mailing list
argentina(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/argentina@lists.fedoraproject.org