Pentaho en Fedora.-

[Gustavo Ibarra]

Hola a todos!

Buenos días y un gusto de saludarlos por lo menos por correo electrónico
 Creo que este es mi segundo correo a la lista.

Me encuentro evaluando trabajar con la suite Pentaho(Community) en un
servidor Fedora usando como motor de BDR PostgreSQL (+ PostGIS).. En
principio, y por ahora no necesito mas que trabajar con la herramienta
Kettle [1] - Data Integration versión community - que es una de las
herramientas de la suite, y creería que me alcanzaría en modo
workstarion[2]. Hasta ahora los documentos oficiales mencionan CentOS y
Ubuntu como SO....

Ahora bien, con respecto a Fedora y el mundo Pentaho estas son mi dudas
puntuales:

A) ¿Quien de ustedes tiene experiencia o sabe de algún caso de uso de
Pentaho sobre Fedora?
B) ¿Quien de ustedes podrían recomendar algún servicio tipo cloud para
alojar Pentaho sobre Fedora? ¿Tienen experiencia con AWS/EC2 de Amazon y/o
algún otro proveedor de VPS con Fedora?

Desde ya muchas gracias por todas las posibles respuestas.

Gustavo.-

[1] -
http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration+%28Kettle%29+Tu...
[2] - http://help.pentaho.com/Documentation/5.2/0D0/160/000#Workstation

[Chino Soliard]

Hola, Gustavo!

El 04/03/16 a las 15:45, Gustavo Ibarra escribió:
> Hola a todos!
>
> Buenos días y un gusto de saludarlos por lo menos por correo electrónico
>  Creo que este es mi segundo correo a la lista.
>
> Me encuentro evaluando trabajar con la suite Pentaho(Community) en un
> servidor Fedora usando como motor de BDR PostgreSQL (+ PostGIS).. En
> principio, y por ahora no necesito mas que trabajar con la herramienta
> Kettle [1] - Data Integration versión community - que es una de las
> herramientas de la suite, y creería que me alcanzaría en modo
> workstarion[2]. Hasta ahora los documentos oficiales mencionan CentOS y
> Ubuntu como SO....

Me mataste! La verdad no tenía idea de lo que era Pentaho hasta que leí
recién.

Por los requerimientos [0] parece que no debería haber problema en
correrlo en Fedora; Fedora se arrima mucho a CentOS, quizá podes seguir
los pasos que encuentres para hacerlo.
> Ahora bien, con respecto a Fedora y el mundo Pentaho estas son mi dudas
> puntuales:
>
> A) ¿Quien de ustedes tiene experiencia o sabe de algún caso de uso de
> Pentaho sobre Fedora?

Desconocía, inclusive, Pentaho.
> B) ¿Quien de ustedes podrían recomendar algún servicio tipo cloud para
> alojar Pentaho sobre Fedora? ¿Tienen experiencia con AWS/EC2 de Amazon
> y/o algún otro proveedor de VPS con Fedora?

No soy de usar servicios cloud, pero vi que DonWeb ofrece servidores VPS
con Fedora Server.
> Desde ya muchas gracias por todas las posibles respuestas.
>
> Gustavo.-
>
> [1] -
> http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration+%28Kettle%29+Tu...
> [2] - http://help.pentaho.com/Documentation/5.2/0D0/160/000#Workstation
>
> argentina mailing list
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]

Saludos, Gustavo
Espero tengas suerte.

[0] https://help.pentaho.com/Documentation/6.0/0D0/160/000

[Martín Cigorraga]

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.

[Gustavo Ibarra]

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 :
> Gustavo,
>
> Agrego a lo que comenta Adrián:
> 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
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]

[Martín Cigorraga]

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 :
> 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 :
> > Gustavo,
> >
> > Agrego a lo que comenta Adrián:
> > 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
> > [e-mail]
>
> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >
>
> argentina mailing list
> [e-mail]
>
> http://lists.fedoraproject.org/admin/lists/[e-mail]

[Gustavo Ibarra]

Hola Martín

2016-03-30 21:39 GMT-03:00 Martín Cigorraga :
> 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:
> 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):
> 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 :
> > 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 :
> > > Gustavo,
> > >
> > > Agrego a lo que comenta Adrián:
> > > 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
> > > [e-mail]
> > >
> > > http://lists.fedoraproject.org/admin/lists/[e-mail]
> >
> > argentina mailing list
> > [e-mail]
> >
> > http://lists.fedoraproject.org/admin/lists/[e-mail]
>
> argentina mailing list
> [e-mail]
> http://lists.fedoraproject.org/admin/lists/[e-mail]