La pasada semana, junto a mi compañero @alberto_molina hemos impartido en la Universidad de Almería, un curso sobre infraestructura Cloud, donde hemos tratado temas como la instalación automática y la administración de OpenStack, y la relación entre OpenStack y los contenedores, centrándonos principalmente en Kubernetes. Puedes acceder al curso completo en la siguiente dirección:

Curso de infraestructura Cloud con OpenStack. Universidad de Almería

Introducción

Instalación automática de OpenStack

Contenedores en OpenStack

Otros

En una entrada anterior, explicamos cómo trabajar con Heroku, en concreto instalamos un CMS Drupal utilizando la herramienta heroku-cli. En este artículo vamos a desplegar una aplicación web desarrollada en python utilizando el framework bottle utilizando sólo la aplicación web Heroku (Heroku Dashboard).

Heroku es una aplicación que nos ofrece un servicio de Cloud Computing PaaS (Plataforma como servicio). Como leemos en la Wikipedia es propiedad de Salesforce.com y es una de las primeras plataformas de computación en la nube, que fue desarrollada desde junio de 2007, con el objetivo de soportar solamente el lenguaje de programación Ruby, pero posteriormente se ha extendido el soporte a Java, Node.js, Scala, Clojure y Python y PHP. La funcionalidad ofrecida por heroku esta disponible con el uso de dynos, que son una adaptación de los contenedores Linux y nos ofrecen la capacidad de computo dentro de la plataforma.

Este artículo lo escribo como apoyo para la asignatura de Lenguajes de Marcas, que imparto en el ciclo de Grado Superior de Administración de sistemas Informáticos, por lo que vamos a recordar las características de la capa gratuita de Horoku:

  • Podemos crear un dyno, que puede ejecutar un máximo de dos tipos de procesos. Para más información sobre la ejecución de los procesos ver: https://devcenter.heroku.com/articles/process-model.
  • Nuestro dyno utiliza 512 Mb de RAM
  • Tras 30 minutos de inactividad el dyno se para (sleep), además debe estar parado 6 horas cada 24 horas.
  • Podemos utilizar una base de datos postgreSQL con no más de 10.000 registros
  • Para más información de los planes ofrecido por heroku puedes visitar: https://www.heroku.com/pricing#dynos-table-modal

Veamos los pasos que tenemos que realizar para desplegar nuestra aplicación python bottle en Heroku:

Continue reading

Programando infraestructura en la nube

El pasado 23 de febrero participé, junto a mi compañero Alberto Molina en las IV Jornadas de Informática de la Universidad de Almería. Nos invitaron a dar una charla sobre Cloud Computing y decidimos presentar un tema que estamos trabajando en los últimos meses: la importancia y necesidad de programar la infraestructura. Por lo tanto, con el título “Programando infraestructura en la nube” abordamos el concepto de Cloud Computing, centrándonos en las dos capas que más nos interesaban: en el SaaS (Software como servicio) y en el IaaS (Infraestructura como servicio). Mientras que todo el mundo entiende que el SaaS es programable (generalmente mediante APIs), la pregunta que nos hacíamos era: ¿la IaaS se puede programar?

¿Por qué programar la infraestructura en la nube?

Podemos indicar varias razones:

  • Las nueva metodología DevOps que trata de resolver el tradicional conflicto entre desarrollo y sistemas, con objetivos y responsabilidades diferentes. ¿Cómo solucionarlo?, pues indicábamos que habría que utilizar las mismas herramientas y que se deberían seguir las mismas metodologías de trabajo, pasando de “integración continua” a “entrega continua o a despliegue continuo”. En este escenario resulta imprescindible el uso de escenarios replicables y automatización de la configuración.
  • Una de las características más importantes y novedosas de los servicios que podemos obtener en la nube es la elasticidad, está nos proporciona la posibilidad de obtener más servicios (en nuestro caso más infraestructura) en el momento que la necesitamos. Poníamos de ejemplo un escenario donde tuviéramos una demanda variable sobre nuestro servicio web, es decir al tener un pico de demanda podemos, mediante la elasticidad, realizar un escalado horizontal, añadiendo más recursos a nuestro cluster. En este escenario también es necesario la automatización en la creación y destrucción de servidores web que formarán parte de nuestro cluster.
  • Se está pasando de crear aplicaciones monolíticas a crear aplicaciones basadas en “microservicios”.  Normalmente para implementar está nueva arquitectura se utilizan contenedores. Los contenedores se suelen ejecutar en cluster (por ejemplo kubernetes o docker swarm). Pero el software que vamos a usar para orquestar nuestros contenedores utiliza una infraestructura de servidores, almacenamiento y redes. También llegamos a la conclusión que la creación y configuración de esta infraestructura hay que automatizarlas.
  • En los últimos tiempo se empieza hablar de la “Infraestructura como código”, es decir, tratar la configuración de nuestros servicios como nuestro código, y por tanto utilizar las mismas herramientas y metodologías al tratar nuestra configuración: usar metodologías ágiles, entornos de desarrollo, prueba y producción, entrega / despliegue continuo. En este caso estamos automatizando la configuración de nuestra infraestructura.
  • “Big Data”: En los nuevos sistemas de análisis de datos se necesitan una gran cantidad de recursos para los cálculos que hay que realizar y además podemos tener cargas variables e impredecibles. Por lo tanto la sería deseable que la creación y configuración de la infraestructura donde se van a realizar dichos cálculos se cree y configure de forma automática.
  • Quizás esta razón, no es tan evidente, ya que se trata de la solución cloud “Función como servicio” o “serverless” que nos posibilita la ejecución de un código con características cloud (elasticidad, escabilidad, pago por uso,…) sin tener que preocuparnos por los servidores y recursos necesarios. Evidentemente, y no por el usuario final, será necesario la gestión automática de una infraestructura para que este sistema funcione.
  • Por último, y quizás como una opción donde todavía hay que llegar, señalamos la posibilidad de desarrollar aplicaciones nativas cloud, entendiendo este tipo de aplicaciones, aquellas que pudieran autogestionar la infraestructura donde se esté ejecutando, creando de esta manera aplicaciones resilientes y infraestructura dinámica autogestionada.

Continue reading

bart-simpson-utf8

Cuando mis alumnos se enfrentan a realizar su proyecto de fin de curso creando una aplicación web en python casi siempre se encuentran con la problemática de las diferentes codificaciones con las que trabaja python. Normalmente trabajan con variables locales de tipo cadena que están codificada en utf-8, sin embargo cuando leen datos que provienen de una API web se puede dar el caso que la codificación sea unicode. En estos casos siempre les cuesta mucho trabajo tratar con los caracteres no ingleses codificados de diferente forma.

En estos días estoy desarrollando una aplicación web y me estoy encontrado con el mismo problema. Por lo tanto el objetivo de escribir esta entrada en el blog es hacer un resumen de cómo python gestiona las diferentes codificaciones y que sirva como material de apoyo para la realización de los proyectos de mis alumnos.

Codificaciones de caracteres

Entendemos un carácter como el componente más pequeño que puede formar un texto. Aunque muchos caracteres son iguales en los distintos idiomas, hay caracteres específicos para cada alfabeto, que tienen grafías diferentes. Evidentemente para guardar en un ordenador cada uno de los caracteres es necesario asignar a cada uno un número que lo identifique, y dependiendo del sistema que utilicemos para asignar estos “códigos” nacen las distintas codificaciones de caracteres.

En los principios de la informática los ordenadores se diseñaron para utilizar sólo caracteres ingleses, por lo tanto se creó una codificación de caracteres, llamada ascii (American Standard Code for Information Interchange) que utiliza 7 bits para codificar los 128 caracteres necesarios en el alfabeto inglés. Por lo tanto con esta codificación, es imposible representar caracteres específicos de otros alfabetos, como por ejemplo, los caracteres acentuados.

Posteriormente se extendió esta codificación para incluir caracteres no ingleses. Al utilizar 8 bits se pueden representar 256 caracteres. De esta forma para codificar el alfabeto latino aparece la codificación ISO-8859-1 o Latín 1. Puedes ver las tablas de estos códigos en la siguiente tabla. Continue reading