Red Hat provee imágenes en formato qcow2, listas para ser desplegadas en entornos que permitan el uso de cloud-init, como por ejemplo OpenStack o RHEV.

Basandome en una idea de Eduardo Minguez he creado un pequeño script en bash, guestimageinstall.sh, que hace lo siguiente:

  • Si no le pasamos la imagen qcow revisa el directorio definido (/opt/qcow2 por defecto) y nos permite elegir entre las imagenes qcow2 que haya disponibles.
  • Luego automaticamente selecciona un fichero de template en función de la versión.
  • En esta plantilla hacemos lo siguiente:
    • Creamos un usuario y le añadimos su clave ssh pública
    • Añadimos password para el usuario root
    • Cambiamos la timezone y la configuración del teclado
    • Activamos/desactivamos algunos servicios y reiniciamos
  • Cambiamos el hostname en la plantilla de meta data
  • Copiamos los ficheros de las plantillas y generamos el fichero clouditnit.iso usando genisoimage
  • Instalamos la nueva maquina virtual usando este fichero de cloudinit.iso

Más detalles en la página de github del proyecto.

Aunque hay miles de posts sobre como y porque usar un servidor ssh como Proxy Socks, este me parece bastante instructivo, yo simplemente voy a hacer este post para aclarar los pasos necesarios en RHEL 7 o Fedora 19/20, con SELinux activado y con firewalld funcionando.

SELinux

En nuestro ejemplo, nuestro proxy Socks va a usar el puerto 443 para que sea factible usarlo desde la mayoría de los firewalls desde donde nos conectemos.
El problema es que este puerto es el vinculado al servicio HTTPS y uno de los mecanismos de seguridad que nos ofrecen las políticas de SELinux es el vincular los números de puerto al servicio esperado, así que lo primero que tenemos hacer es modificar la política de SELinux, para ello usamos el siguiente comando:

semanage port -m -t ssh_port_t -p tcp 443 

Firewalld

Con SELinux configurado lo siguiente es abrir el puerto en nuestro firewall, en este caso firewalld, para ello con los siguientes comandos lo que hacemos es aceptar de forma permanente el trafico hacia nuestro servidor por el puerto 443 desde la zona pública y recargar las reglas:

firewall-cmd –permanent –zone=public –add-port=443/tcp
firewall-cmd –reload 

SSH

Por último nos queda la configuración de ssh, para ello simplemente editamos el fichero /etc/ssh/sshd_config para definir los puertos donde escuchar:

Port 22 
Port 443 

A continuación reiniciamos el servicio:

systemctl restart sshd.service 

Lo siguiente es ejecutar el siguiente comando en nuestra máquina local:

ssh -N -D localhost:1080 mi_servidor_remoto -p 443 

Las opciones que usamos son:

  • -N” Para no ejecutar comandos remotos
  • -D localhost:1080” Para definir el puerto local desde el que vamos a hacer la redirección
  • -p 443” Para definir el puerto al que nos vamos a conectar

Si quisieramos ejecutar el comando en segundo plano, podríamos usar la opción -f

ssh -f -N -D localhost:1080 mi_servidor_remoto -p 443

Por último nos quedaría configurar nuestras aplicaciones, por ejemplo el navegador, para que use localhost:1080 como Proxy.

Openshift es la “Plataforma como servicio” (PAAS en inglés) de Red Hat. El concepto de PaaS lo que intenta es abstraer a los desarrolladores de todo lo relacionado con la infraestructura, la forma en que lo hace OpenShift a groso modo es la siguiente:

Soy un desarrollador y quiero desplegar una aplicación, supongamos para el ejemplo un blog con WordPress, primero elijo el tamaño que quiero que tenga mi aplicación, en términos de RAM y de espacio en disco, le pongo un nombre, a continuación añado mediante “cartuchos” las tecnologías a usar, en este caso PHP y MySQL, al añadir los cartuchos obtengo los datos de conexión necesarios para poder desplegar mi código o mi base de datos, si en algún momento mi aplicación necesita más recursos, puedo activar el autoescalado y ni siquiera preocuparme de morir de éxito.

Antes de pasar a la parte más técnica, quiero enumerar algunas ventajas/características que tiene OpenShift:

  • Tiene versión Online y versión para desplegar internamente en nuestra infraestructura, llamada OpenShift Enterprise.
  • La versión online se puede usar gratuitamente, aunque con limitaciones: Sólo 3 aplicaciones, el tamaño de estas es del tipo pequeño, no tiene soporte, etcétera.
  • La versión interna se puede desplegar en cualquier infraestructura virtual, ya sea RHEV, VMWare, OpenNebula, OpenStack… Evidentemente si se mantiene un ecosistema Red Hat, usando RHEV u OpenStack, tienes documentos de referencia y más articulos en la Knowledge Base 
  • La versión interna dispone a su vez de una versión comunidad, Origin 
  • Hay una gran comunidad de usuarios detrás, por lo que es fácil encontrar bastantes ejemplos de como desplegar aplicaciones, y no sólo ejemplos, sino guias rápidas con las que poder desplegar aplicaciones con sólo 2 clicks.
  • Es agnóstico al lenguaje de programación, hay cartuchos de python, php, perl, ruby, java e incluso .net
  • Hay bastante documentación:

¿Cómo funciona técnicamente OpenShift Online?

  1. Te creas una cuenta, que como ya he dicho hay una versión gratuita que permite hasta 3 aplicaciones.
  2. Creas la aplicación mediante la consola web , usando Eclipse , o la línea de comandos 
  3. A la hora de crear la aplicación eliges el tamaño de “Gear” hay 3 tamaños ya predefinidos, todos con 1 GB de espacio en disco inicial, y con 512MBs de RAM (Pequeño), 1GB de RAM (Mediano) y 2GB de RAM (Grande)
  4. En la aplicación recién creada, agregamos los cartuchos necesarios 
  5. Al agregar los cartuchos creamos a su vez repositorios privados de git dónde poder aplicar cambios con comandos git estandares.
  6. Una vez subido el codigo, OpenShift usa herramientas como Maven, Jenkins o Apache para completar el despliegue.
  7. En caso de activar el auto escalado, OpenShift inserta un HA-Proxy delante de la aplicación para monitorizarla y escalar en caso de que sea necesario.

¿Cómo funciona técnicamente OpenShift Enterprise/Origin?

Básicamente se compone de 2 elementos principales:

  1. Los “Broker” que son el punto de contacto para todas las actividades de gestión de una aplicación. Logins, DNS, monitorización de la aplicación, etcétera. Los usuarios no acceden directamente al broker sino que interactúan con él gracias a la API basada en REST, ya sea mediante la consola web, el cliente de línea de comandos o un IDE. El broker usa MCollective para los sistemas donde realmente residen las aplicaciones, los “Nodos”.
  2. Los Nodos albergan los cartuchos preconstruidos asi como las aplicaciones de los usuarios contenidas en “Gears”. En cada Nodo hay un cliente MCollective encargado de recibir y ejecutar las peticiones del Broker.

La comunicación entre los clientes MCollective de los Nodos y el Broker se hace usando un servicio de cola de mensajes. Tanto Enterprise como Origin usar ActiveMQ inicialmente, pero cualquier otro sistema compatible con AMQP como RabbitMQ debe funcionar.

Las topologías a poder usar son multiples, por ejemplo:

  • Todos los componentes en un solo sistema.
  • Un sistema con un broker y ActiveMQ y multiples sistemas Nodo.
  • Varios brokers balanceados, un sistema dedicado en exclusiva para ActiveMQ, con varios servidores MongoDB replicados y múltiples sistemas Nodo.

Como hemos dicho antes, los Gears, representan las porciones de CPU, memoria RAM y espacio en disco que están disponibles para una determinada aplicación. Una aplicación nunca puede sobrepasar el uso de estos recursos, a excepción del espacio en disco cuya cuota es ampliable por el administrador. Las tecnologías en las que se basa OpenShift para aislar los Gears y para controlar sus cuotas son SELinux y cgroups

Esto último cambiará próximamente puesto que OpenShift va a empezar a adoptar Docker , el problema de Docker, es que tiene algunos aspectos no muy pulidos:

  • ¿ Cual es la mejor manera de desplegar una aplicación en un contenedor recién creado?
  • ¿ Cómo conectar un montón de contenedores para formar una sola aplicación?
  • ¿ Cómo hacer desde el punto de vista de red que estos contenedores aparezcan como una simple aplicación al mundo exterior?
  • ¿ Cuando despliego un contenedor, he instalado todo lo necesario?

Aquí es donde GearD llega al rescate, e inicialmente se centrará en:

  • Convertir fuentes de aplicaciones en imagenes de Docker
  • Proveer conexiones elásticas entre varios contenedores
  • Facilitar los despliegues

De hecho, como ya he comentado en mi anterior post hay un nuevo proyecto llamado Project Atomic, que combina Docker, GearD y cockpit, así que no me extrañaría que pudiera usarse para desplegar “Nodos”

Últimamente hay mucho ruido alrededor de un nuevo proyecto open source llamado Docker  asi que voy a intentar tratar de aportar mi granito de arena.

Empecemos por la descripción de Docker: “Un proyecto open source para empaquetar, distribuir y ejecutar cualquier aplicación como un contenedor ligero”. Muy bonito, pero ¿Que es un contenedor?

Un contenedor es una forma ligera de virtualizar de forma que los recursos que ya se están ejecutando en la maquina host son compartidos con los contenedores, por ejemplo los contenedores no necesitan ejecutar su propia instancia del kernel, lo que permite una carga mucho menor, así como un arranque muy rápido y una gestión simplificada de los mismos. Es decir sería algo parecido a chroot con esteroides, en el sentido de que no sólo se usa para aislar una sola aplicación.

La tecnología de contenedores es conocida desde hace mucho tiempo y existen varias, cómo lxc , openvz , FreeBSD Jails o Solaris Containers .

Entonces ¿Que aporta Docker?. Pues como su descripción indica, Docker aporta las herramientas para tratar a los contenedores como si fueran repositorios de código, es decir, combinar paquetería y código todo en uno, de forma que se puedan desplegar, clonar, hacer vuelta atrás de versiones, etcétera con un simple comando.

Otra forma de desplegar contenedores que permite docker es mediante los Dockerfile, que son recetas en las que especificas el contenedor base y todos los cambios que quieres aplicar en un solo fichero.

La tecnología Docker es reciente y por eso, y tal como dicen en su web, “Aún no está preparado para produción”, no obstante tiene mucha tracción, por ejemplo Amazón ha anunciado recientemente su soporte  

Red Hat ha anunciado el “Project Atomic” que además de Docker, usa systemd , GearD y cockpit para crear una versión de RHEL especialmente destinada a usarse como “hypervisor” de contenedores.

Red Hat también ha anunciado que ha incluido Docker en su programa de High Touch Beta de forma que los clientes que participen en este programa puedan probarlo y reportar feedback, y se espera que este incluido en RHEL 7, aunque no en las primeras versiones.

Si quereis probar Docker, recomiendo hacer el tutorial interactivo de Docker.

Leyendo el post de Ramón Ramón  sobre “La falsa creencia de la propiedad y las licencias privativas” se me ha ocurrido escribir sobre otro aspecto diferencial entre el software libre y el software propietario: El soporte.

Primero un gran disclaimer: Trabajo para Red Hat  y además he trabajado para el departamento de Soporte  , y aunque intento siempre ser objetivo a veces mi pasión por el software libre me puede :) También tengo amigos que trabajan o han trabajado en departamentos de soporte de otras grandes empresas como Canonical, Oracle, RSA o Rackspace. Además quiero dejar claro que este post es una opinión puramente personal y no tiene vinculación ningún con mi empresa.

Ahora al lío: El tipo de licencia de un software no tiene nada que ver con el soporte que vas a recibir por él, como dice el post de Ramón Ramón , la licencia de un software privativo sólo te da derecho a usarlo, de hecho normalmente no es que te dé derecho a usarlo, sino que te restringe en que puedes usarlo y en que no, además durante un tiempo determinado. Además la empresa propietaria del software se guarda el derecho a no renovarte la suscripción, aumentar el precio en el futuro o simplemente descontinuar el producto.

Sobre el soporte del software libre hay 2 tipos bien diferenciados, el soporte de “la comunidad” y el soporte empresarial que ofrecen muchas empresas como Suse, Canonical o Red Hat.

El soporte “comunitario” no es más que aquel que puedes encontrar por parte de usuarios o desarrolladores de ese software, ya sea en blogs, foros, wikis, es decir contenido “estático” o mediante interacciones: Listas de correo, herramientas para reportar problemas (tipo http://bugzilla.redhat.com) o canales de irc

Este tipo de soporte tiene sus ventajas: es muy abundante, es gratis y en muchas ocasiones te puedes encontrar interactuando con el creador(es) del propio software. Pero también tiene sus problemas: falta de organización, no tiene tiempos de respuesta definidos y evidentemente no tienes forma de “quejarte” si crees que no estas recibiendo el soporte adecuado.

Pero es mentira que el software libre no disponga de soporte empresarial, como ya he nombrado hay muchas empresas que si dan soporte:
Red Hat
Canonical
Suse
Puppetlabs 

Desconozco en detalle como trabajan otras empresas de software libre, pero estoy seguro de que ofrecen un soporte excelente, pero puedo aprovechar para hacer una breve introducción al soporte de Red Hat, que espero que ayude a desmitificar la idea de con el software libre todo tienes que hacerlo tu mismo.

  • Red Hat Enterprise Linux ofrece un ciclo de vida de soporte de 10 años, extensibles otros 3 años, con diferentes etapas. Aunque personalmente me parece una mala idea tener en produción un software con tanto tiempo.
  • Como ya he dicho, Red Hat ofrece tiempos de respuesta definidos, además para ciertos tipos de incidencias , aquellas en las que se está impactando la produción, el soporte es 24×7
  • La forma de acceder al soporte de Red Hat puede ser via web (mediante casos de soporte o via chat una vez abierto el caso), por email (una vez abierto el ticket via web) o por telefono. Además en algunas ocasiones se pueden tener sesiones remotas 
  • La base de datos de conocimiento de Red Hat  es el mejor sitio para buscar información, los artículos que aparecen son artículos aprobados por Red Hat, basados en casos reales, se van actualizando y puedes comentarlo en un caso abierto con soporte. Personalmente hay 2 cosas que no me gustan: Que requiera login para ver los artículos (aunque cualquiera puede crearse una cuenta) y el motor de búsqueda no funciona del todo fino.
  • Que está incluido en el soporte de Red Hat? Pues la regla básica es “Lo que distribuimos es lo que soportamos”  Pero ante la duda siempre abrid un caso y preguntar.
  • El soporte de Red Hat no está solo para incidencias, sino que está también para otras muchas cosas: petición de nuevas funcionalidades  , reportar problemas, mejoras de la documentación, revisiones de arquitectura de ciertos productos (Cluster o RHEV por ejemplo), grupos de discusion , laboratorios de soporte  , certificación de hardware, etcétera
  • Si la atención que se recibe no te parece satisfactoria siempre puedes requerir una escalación  o incluso llamar directamente al móvil a uno de los directores de soporte de tu respectiva zona horaria .
  • A la hora de abrir casos de soporte, Red Hat tiene varias herramientas que se utilizan para recopilar información sobre los sistemas, de forma que sea más fácil resolver los problemas: sosreport  , kdump-crash , spacewalk-debug , etcétera
  • Además dependiendo del nivel de soporte necesario, Red Hat ofrece otros servicios asociados como Technical Account Manager  o Support Relationship Manager 

  • Han mejorado el sistema de suscripciones e informes, donde hay mas niveles de reportes de consumo de suscripciones
  • Analisis de clientes: Red Hat Satellite 5.6 integra ABRT para proveer informacion centralizada de “crash” en aplicaciones de los clientes
  • Mejor el Inter-Satellite Sync (ISS) de forma que permite refinar el nivel de acceso a la hora de sincronizar Satellites
  • PostgreSQL (Por fin!!!!) El uso de PostgreSQL como base de datos, de forma interna o externa, ya esta totalmente soportado
  • Mejoras de Escalabilidad: Debido al uso de PostgreSQL, ahora es posible desplegar la base de datos en una maquina externa sin la intervencion de un DBA.
  • La base de datos interna por defecto ahora es PostgreSQL lo que provee la posibilidad de ejecutar backups en caliente.
  • Provisionamiento automatico en entornos sin PXE al agregar el soporte para Cobbler Build ISO en Satelite, lo que permite creacion de ISOs personalizadas.
  • Junto con la salida de Red Hat Network Satellite 5.6 se ha publicado una nueva herramienta para la “autogeneracion” de certificados de Satellite, lo que permite crear certificados con el detalle de las suscripciones a usar

Más detalles en:

http://gb.redhat.com/about/news/press-archive/2013/10/red-hat-releases-red-hat-satellite-5-6
https://access.redhat.com/site/articles/477863

Voy a intentar ir creando entradas en el blog comentado productos de Red Hat , que dejo hace mucho tiempo de ser una empresa de “sólo” un sistema operativo.

Hoy quiero comentar 2 productos orientados a tener acceso a software de desarrollo mas reciente, aunque con ciclos de soporte mas cortos que los hasta 13 años de ciclo de vida de RHEL:

Red Hat Software Collections tiene un ciclo de vida de 3 años e incluye:
  • Ruby 1.9.3
  • Python 2.7
  • Python 3.3
  • PHP 5.4
  • Perl 5.16.3
  • node.js 0.10 (Technology Preview)
  • MariaDB 5.5
  • MySQL 5.5
  • PostgreSQL 9.2

Más información:

http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
https://www.redhat.com/about/news/press-archive/2013/9/red-hat-extends-red-hat-enterprise-linux-platform-with-latest-versions-of-popular-programming-languages-and-databases
https://access.redhat.com/site/discussions/482093
https://access.redhat.com/support/policy/updates/rhscl/

Red Hat Developer Toolset tiene un ciclo de vida de 2 años e incluye:

  • Eclipse 4.3 (Kepler)
  • gcc 4.8
  • Dyninst 8.0
  • Strace 4.7

Más información:

http://developerblog.redhat.com/2013/09/12/rh-dts2-ga/
https://access.redhat.com/site/products/Red_Hat_Enterprise_Linux/Developer/#dts
https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/User_Guide/index.html
https://access.redhat.com/support/policy/updates/dts/

En ambos casos el acceso a software se hace mediante canales (repositorios) de Red Hat Network o Red Hat Network Satellite, es decir no hay una iso descargable.


Ademas aprovecho para comentar algunas novedades que se han publicado hoy:

Satellite 5.6:

Bueno, pues hoy salgo camino a Munich para los 2 dias de “Charlas de Orientacion” para los nuevos empleados que suele dar RedHat, por lo que cuentan estan muy bien:

  • Estructura de la compañia
  • Evangelizacion sobre el Software Libre
  • Consejos sobre como atender a los clientes cuando se les da soporte.

Y bueno lo realmente interesante es que te regalan tu Fedora Roja y que el lunes por la tarde te enseñan Munich y te llevan de Cervezas y cena gratis.
Espero hacer muchas fotos y ponerlas por aqui.

Bueno, intentare contar lo máximo posible sobre como es mi día a día trabajando en RedHat. En mi primer lugar comentar que mi puesto es el de Técnico de Soporte, lo que significa que estoy para ayudar a clientes que tienen problemas con la instalación o configuración de cualquiera de los productos que tiene RedHat.
Bueno ya os he contado la parte aburrida, ahora tocan los detalles que hacen a este trabajo y a esta empresa diferentes:

  • Lo primero es que no hay control sobre la hora que entras o sales, todo se rige por la coordinación con los compañeros. Y eso consigue que al final te sientas como parte de un equipo y nunca salgas dejando algo urgente a medias o si la carga de trabajo es grande echar un rato mas.
  • El acceso al edificio y a las distintas salas se hace mediante una tarjeta electronica que pasas por delante de los sensores adecuados para abrir las distintas puertas, además no hay ni un solo interruptor en todo el edificio, todo se enciende o apaga en función de sensores de detección de presencia.
  • En cada planta hay una cocina donde hay lavavajillas, frigorífico, microondas y tostadora. Además hay una maquina de café y otra de agua caliente para infusiones, todo esto completamente gratis. También hay una maquina expendedora de chocolatinas, patatas y refrescos, que si bien no es gratis, todos los productos valen 20p, practicamente simbólico, y también tenemos varias fuentes con fruta fresca que cambian cada día.
  • En nuestra planta hay una mini-sala comedor y una sala con un futbolin, una wii y varios sofás por si hace falta “desconectar”. En la planta de arriba hay una sala con 2 sofás grandes y un salón comedor para unas 30 personas.
  • Se fomenta mucho la formacion, de hecho como ya he comentado yo en mi primer mes he obtenido una de las certificaciones que Red Hat ofrece.Toda esta formación siempre es gratuita y la única restricción de nuevo es la coordinacion con tus compañeros.
  • Internamente usamos irc como herramienta de comunicación e incluso hay un sistema de puntos, en los que la gente te va dando/quitando puntos en funcion de si haces algo positivo/negativo
  • Los viernes hay un desayuno puesto por parte de la empresa para que nos juntemos no solo la gente de soporte sino el resto de departamentos: ventas, formación, marketing, etcétera.
  • Cada 2 miércoles también se piden pizzas y nos reunimos todos en una sala a disfrutarlas mientras se comentan temas técnicos.
  • Todos los jueves se va a algún pub de Farnborough, y la primera ronda la paga la empresa.

Seguro que me dejo algunas cosas que comentar y en general solo he listado las características, pero tal vez no he hecho énfasis sobre lo que por ahora es lo mejor del trabajo: El conjunto de compañeros funciona realmente como un equipo y todo el mundo siempre esta dispuesto a ayudarte, y la gente sabe mucho, muchisimo de todo lo que os podais imaginar sobre linux. Y aún asi tienen un rato para explicar tal o cual tema.