Hola Martín
2016-03-30 21:39 GMT-03:00 Martín Cigorraga <msx(a)archlinux.us>:
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!
¿Aburrirme?....De lo bueno que esta ya leí tres veces este correo. Muy
didáctico y super clarificador !. Muchas gracias por escribir
semejante correo, gracias!
Es increíble el avance de estas tecnologías "pesadas" para administrar
en la nube y ahora convertidas en "plug and play" portables.
En breve regresare por este correo para continuar la charla del hilo
Un abrazo de gratitud para con vos.
> 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
>
>
>
> _______________________________________________
> argentina mailing list
> argentina(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/argentina@lists.fedoraproject.org
>