Manual de Contenedores

Sesión 3.1. Manual de contenedores y Docker

(24 / Agosto 2018 )

En la sesión III inciso I se construye un manual de contenedores y Docker. Se recomienda leer la sesión III de un post anterior. La información presentada fue recopilada de las lecciones recibidas en la MCIC (Maestría de Ciencias de la Información y las Comunicaciones) de la Universidad Distrital en Bogotá-Colombia y de investigaciones adicionales.

CONTENEDORES

¿Qué es?

Los contenedores, conocidos también como “Operating-system-level virtualization” representan un enfoque óptimo y ligero de la virtualización, ya que solo provee “lo mínimo” que una aplicación requiere para desplegarse y ejecutarse. Múltiples aplicaciones aisladas o servicios pueden ser desplegados y ejecutados en un solo host que accede desde el mismo Kernel. Los contenedores pueden funcionar sobre un “host” local, instancias en la nube (cloud instances) y máquinas virtuales. (Rouse, 2017)

¿Para qué sirve?

El concepto de contenedores presenta el siguiente enfoque:



Cada aplicación es entregada junto con sus dependencias necesarias para su funcionamiento, pero sin incluir el sistema operativo. De manera que las aplicaciones se conectan directamente con el sistema operativo anfitrión (host), por lo tanto no existe ninguna capa adicional del sistema operativo invitado (guest). Esto resulta en un mejor desempeño y no se desperdician recursos. (Leszko, 2017).

Los contenedores resuelven un número de problemas que enfrentaba el despliegue y entrega de productos de software en los modelos tradicionales.

• Ambiente de desarrollo. Soluciona problemas relacionados con el ambiente de producción como las instalaciones de dependencias. 
• Aislamiento. Mantiene las aplicaciones separadas lo que impide daños en optros contenedores por software malicioso. 
• Organización de aplicaciones. 
• Portabilidad. “write once, run anywhere”.

¿Cuales herramientas existen?

La herramienta más utilizada en contenedores es Docker, qué es un proyecto open source diseñado para el despliegue de aplicaciones usando contenedores de software.

En la definición obtenida de la página de Docker se tiene:

"Los contenedores en Docker agrupan una pieza de software en un sistema de archivos completo que contiene todo lo necesario para ejecutarse: código, tiempo de ejecución, herramientas del sistema, librerias del sistema - todo lo que pueda ser instalado en el servidor, Esto garantiza que el software siempre se ejecute, independientemente del ambiente de desarrollo o producción." (Leszko, 2017)

Docker permite empaquetar una aplicación dentro de una imagen que puede ser ejecutada en cualquier lugar

Alternativas a Docker 

Docker no es el único sistema de contenedores disponibles en el mercado. De hecho las primeras versiones de Docker fueron basadas en el sistema libre (LXC Linux Containers), qué es otra alternativa para los contenedores.

Existen otras soluciones como:

• FreeBSD Jails.
• Open VZ. 
• Solaris Containers. 

No obstante Docker cuenta con mayores ventajas ya que puede ser instalado en gran número de OS, es ligero y cuenta con una amplia comunidad de soporte.

¿Cómo se configuran?

Centrando la atención en Docker, se tiene el siguiente diagrama, que explica su funcionamiento:



Una aplicación “dockerizada” como un web service se ejecuta sobre un “Docker Host” y es alcanzado y ejecutado directamente en la máquina anfitriona. Esto es posible gracias al “port Forwarding”.

Instalación Docker

“Docker puede ser instalado de forma nativa en MAC, Windows o Linux, sin embargo es importante entender que está basado en Linux Kernel.

Prerequisitos:

Mac: 2010 o un modelo nuevo, con soporte de hadware de Intel para la configuración de las unidades de memoria (MMU) virtualización.
macOS 10.10.3 Yosemite o mayor
Al menos 4GB de RAM
No tener VirtualBox instalado prevío a la versión 4.3.30


Windows:
64-bit Windows 10 Pro
El paquete de Hyper-V habilitado


Linux:
64-bit
Linux kernel 3.10 o mayor

Instalación en Linux (Ubuntu):

Docker puede ser instalado desde el repositorio:

$ sudo apt-get update

$ sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recvkeys

9DC858229FC7DD38854AE2D88D81803C0EBFCD88

$ sudo apt-add-repository 'deb [arch=amd64]

https://download.docker.com/linux/ubuntu xenial main stable'

$ sudo apt-get update

$ sudo apt-get install -y docker-ce

Una vez instalado, se habilitan los usuarios en docker group
$ sudo usermod -aG docker <username>

¿Cómo se lanzan imagenes?

Para comprobar su instalación se lanza el programa de prueba:

$ docker run hello-world

Unable to find image 'hello-world:latest' locally

latest: Pulling from library/hello-world

78445dd45222: Pull complete

Digest:

sha256:c5515758d4c5e1e838e9cd307f6c6a0d620b5e07e6f927b07d05f6d12a1ac8d7

Status: Downloaded newer image for hello-world:latest

Hello from Docker!

This message shows that your installation appears to be working correctly.

...

Referencias

Leszko, R. (2017). Continuous delivery with Docker and Jenkins: Delivering software at scale. Birmingham ; Mumbai: Packt Publishing.

DevOps, CDCI y Microservicios

Sesión 3. DevOps (Contenedores-Virtualización), Despliegue continuo y Microservicios

(24 / Agosto 2018 )

En la sesión III se describe el modelo o con mayor precisión el movimiento DevOps, y además de las diferencias entre virtualización y contenedores. La información presentada fue recopilada de las lecciones recibidas en la MCIC (Maestría de Ciencias de la Información y las Comunicaciones) de la Universidad Distrital en Bogotá-Colombia y de investigaciones adicionales.

Retomando la definición de DevOps en Sesión I

DevOps es un movimiento cultural que cambia el modo en el que los individuos piensan su trabajo, valora la diversidad del trabajo realizado, soporta intencionalmente los procesos, por los cuales las empresas generan valor, y mide los efectos del cambio social y técnico. Esta es una forma de pensar y de trabajar que permite a los individuos y organizaciones desarrollar y mantener practicas de trabajo sustentables. Es un marco cultural para intercambiar historias y desarrollar empatía, permitiendo a las personas y equipos practicar sus oficios de manera efectíva y duradera.

De manera que el modelo de DevOps exige ciclos cortos entre desarrollo ↔️despliegue, pasando por pruebas. Incluye las arquitecturas de microservicios, y tiene como caracteristicas:

• Integración Continua.
• Pruebas.
• Despliegue Continuo.

Según (Leszko, 2017) El despliegue continuo es la habilidad para llevar los cambios de todo tipo (incluyendo nuevas caracteristicas, cambios en la configuración, corrección de errores, y experimentos) en producción o en las manos del usuario, de forma segura y rápida de manera sostenible. En el flujo de trabajo tradicional, descrito en la siguiente imagen:

El despliegue continuo consiste cambiar cada fase del proceso de entrega tradicional en una secuencia de "scripts" llamado tuberia de despliegue automatico (""automated deployment pipeline). Como historia de exito, Yahoo implementó el despliegue continuo luego de comprar la compañia Flickr.

La caracteristica principal de DevOps son sus ciclos cortos que permiten entregar productos de valor en un periodo muy corto que incluye el desarrollo, prubas y despliegue.

La "automated deployment pipeline" incluye: Integración continua, pruebas de acceptación automática, y administración de configuración:

• Integración Continua: Esta fase verifica que el código escrito por diferentes desarroladores se integre.
• Pruebas de acceptación automática: Esta etapa reemplaza la fase de control de calidad manual, y verifica si las caracteristicas implementadas por los desarrolladores cumplen con los requerimientos del cliente.
• Administración de configuración: Reemplaza las operaciones manuales de configuración del ambiente y despliegue del software.

Retomando el concepto de Servicios de la Sesión II, "el servicio es contractual", eso quiere decir que el contrato es inmutable. Para acceder al servicio esté dispone de ciertas interfaces que pueden ser representadas con diagramas ULM de componentes o de clases.

Las interfaces utilizan API's ("Application Programming Interface"), las cuales son los puntos de entrada a un servicio, concretan el servicio y definen el contrato. Es fundamental la documentación de una API y se debe realizar automaticacmente.

Lo que define el contrato es:

• La función expuesta.
• Las caracteristicas.
• Protocolo de comunicación.
• Protocolo de representación de datos: XML, JSON (debe incluir la documentación de la estructura).

Retomando la arquitectura de microservicios y en general de la cultura DevOps, se incluyen dos caracteristicas importantes:

• Multicapa
• Multinivel: Tiene que ver con los nodos de despliegue. Y si son desplegados en Contenedores o máquinas virtuales.

n Microservicios ↔️n nodos de despliegue

Dos modelos de MUltinivel:

• Virtualización: Replicar un sistema completo a partir de emulación. Se basa en un imagen de la máquina virtaul, la cual puede ser clonada, apartir de una instantánea. TIene problemas de Uso de recursos.
• Contenedores: Replicación de un sistema apartir de la base que provee una aplicación MiddleWare. Se pueden agregar aplicaciones a los contenedores. En la siguiente imagen se describe el funcionamiento de los contenedores:

Para entender sus diferencias y ventajas, existe una analógía muy útil que trata sobre gatitos y ganado ("Kittens and Cattle"):

"La diferencia entre el despliegue tradicional de software y el despliegue basado en contenedores es expresado en la analogía de gatitos y ganados. Todo el mundo ama los gatitos, son únicos, cada uno tiene nombre y tratamiento especial a sus necesidades, son tratados con emoción, cuando mueren lloramos. Por el contrario, el ganado existe para satisfacer nuestras necesidad (algo discutiible), incluso tratamos al ganado en singular, solo como un paquete de animales considerados como un todo, no tienen nombres, ni son únicos. Seguramente ellos son únicos (como lo es cada servidor), pero eso es irrelevante. La conclusión es tratar los servidores como ganado, no como mascotas"

Taller 3 
Manual básico de tecnologías de virtualización y contenedores

Este Manual se encuentra alojado en: https://drive.google.com/drive/u/1/folders/16UCqocUe88P12DC3cgw_X_o7oKZv2i28, pero en una proxima entrada en el blog se expondrá.

Referencias

Leszko, R. (2017). Continuous delivery with Docker and Jenkins: Delivering software at scale. Birmingham ; Mumbai: Packt Publishing.

Servicios y Microservicios

Sesión 2. Servicios y Microservicios

(17 / Agosto 2018 )

La sesión II presenta un enfoque de las arquitecturas orientadas a microservicios y a servicios. La información presentadas fue recopilada de las lecciones recibidas en la MCIC (Maestría de Ciencias de la Información y las Comunicaciones) de la Universidad Distrital en Bogotá-Colombia y de investigaciones adicionales.

La mejor forma de iniciar con el estudio de los conceptos de Servicios y Microservicios, quizas sea a través de una analogía de la evolución del sofware explicada con tipos de "pasta".

La evolución en la arquitectura de software, de la manera como se desarrolla y despliega inicio (no oficialmente llamada de esa manera) como "spaguetti", es decir se tenia poco control del código, luego, logrando mayor organización, se distribuyó en capas (parecido a como se ve la "lasagna"), hoy se tiene una nueva generación basada en servicios y microservicios (tal como lucen unos "raviolis"). 

La idea general de los servicios y microservicios es que en vez de tener una gran base de datos en la capa inferior con una capa lógica y una capa de interfaz (UI) en el nivel superior, los microservicios dividen pequeñas partes de la lógica de negocio, la funcionalidad y los datos dentro de pequeñas unidades autónomas. (Kavaliauskaite, 2017)

Servicios

Los servicios se caracterizan por que pueden: ser descubiertos, cubren una necesidad, tienen o no un estado, exponen su funcionalidad a tráves de interfaces (la interfaz se refiere a la declaración de un acuerdo-contrato), tienen capacidad de comunicaciones, son integrables, pueden ser orquestados (dirigidos, bus de servicios empresariares) y/o coreografiados (mensajes, enfocado a microservicios), son medibles y es una unidad funcional de NEGOCIO que tiene un contrato definido y capacidad de composición.

Microservicios

Los microservicios no están asociados con valor, es decir no resuelve un requerimiento funcional del negocio, pero si puede resolver un requerimiento funcional. (esto es debatible debido a los distintos enfoques de las arquitecturas SOA y de microservicios).


En otras palabras:

• Unidades de negocios = Esencial.
• Unidades Funcionales de negocio = Servicios.
• Unidades Funcionales = Microservicios. 

"Los servicios y microservicios son modelos arquitectónicos"

Algunos autores consideran que los microservicios son una mejora del modelo de arquitectura orientada a servicios, mientras en la literatura tambien se puede encontrar descripciones de los microservicios como una arquitectura independiente coreografíada, a diferencia de los servicios que son orquestados.

Aquí se considerará que la arquitectura SOA es la base de la arquitectura de microservicios, teniendo presente que la primera es Orquestada (esta caracterizada por su bus "Enterprise Service Bus"y los protocolos de comunicación deben ser conocidos y fijos) y la segunda es coreografiada (los microservicios se exponen através de una API, con protocolos simples de comunicación sin un bus que lo dirija). A continuación se profundiza en las diferencias basado en las arquitecturas.

Visto desde el punto de vista arquitectónico se tiene:

• Arquitectura orientada a servicios (SOA): 

Es una arquitectura de software donde distintos componentes de una aplicación proveen servicios a otros componentes via protocolos de comunicación sobre la red. Estos distintos servicios llevan a cabo pequeñas funciones: como validar pago, crear una cuenta de usuario o log-in por redes sociales, etc.

SOA es menos relacionado en como modularizar una aplicación y más en como componer la aplicación a través de componentes de software distribuidos.

Existen dos roles importantes, "service provider" y "service consumer". La capa del consumo es el punto donde usuario (humanos, otras aplicaciones, y terceros) interactian con SOA, y la capa del proveedor es la encargada de todos los servicios dentro de SOA.

• Arquitectura Microservicios

La arquitectora de microservicios se puede considerar como el siguiente paso de SOA,  es una tipo de arquitectura que es una manera particular de desarrollar sofware, web y aplicaciones moviles como suites de servicios independientes. Con independencia quiere decir que pueden incluso ser escritos en otros lenguajes de programación y usar diferentes bases de datos. Ademas  casi no existen administradores de servicios y losmicroservicios usan comunicaciones ligeras como HTTP, REST o API's de terceros.

Diferencias

• Desarrollo: En SOA cada equipo necesita conocer un mecanismo de comunicación común, en cambnio en microserv9cios los servicios ṕueden operar independientemente facilitando el despliegue.
• Comunicaciones: En SOA existe un punto sigular de fallo que puede afectar todo el sistema, mientras que los microservicios son  más tolerantes a los errores.
• interoperabilidad: SOA provee distintos protocolos de comunicación, mientras que microservicios busca simplificarlo con un número reducido de opciones de integración.
• Tamaño: Microservicios es significatimanete más ligero que SOA.

 (Despodovski, 2017)

Taller 2.

Microservicio de sistema transmilenio con DevOps, donde se ejecute una función del sistema.

Para el desarrollo del taller se considero la funcipon de Consultar saldo de tarjeta. Se diseñaron diagramas de componentes y secuencia de la función y se implemento el servidor REST en Java. El repositorio se encuentra en:

https://github.com/jdaf2008/tallerMicroServicio 

Referencias

Kavaliauskaite, G. (2017, December 03). Microservices - Technology Or Team Size: An Interview with Technical Director Matt Meckes. Retrieved August 24, 2018, from https://cohaesus.co.uk/microservices-technology-or-team-size-an-interview-with-technical-director-matt-meckes/

Despodovski, R. (2017, November 12). Microservices vs. SOA – Is There Any Difference at All? - DZone Integration. Retrieved from https://dzone.com/articles/microservices-vs-soa-is-there-any-difference-at-al

Introducción Aplicaciones sobre la Nube

Sesión 1. Conceptos Básicos de aplicaciones sobre la Nube

(10 / Agosto 2018 )

La sesión I incluye los conceptos básicos de computación sobre la nube, los cuales son recopilados de las lecciones recibidas en la MCIC (Maestría de Ciencias de la Información y las Comunicaciones) de la Universidad Distrital en Bogotá-Colombia y de investigaciones adicionales.

Con el proposito de iniciar el estudio de computación en la nube es necesario comenzar con la definición de conceptos básicos que permitan su aplicación.

• Computación sobre la nube

Como una visión general, la computación en la nube puede ser entendida a partir de la siguiente definición:

"Provisión bajo demanda de servicios relacionados con tecnologías de la información en un plataforma accesible a través de protocolos de red" Es un disciplina para diseñar, desarrollar, mantener y operar, dichos servicios.

Recopilando las definiciones dadas por los más influyentes prestadores de servicios en la nube (AWS, Google Cloud Platform, Azure, Alibaba), estos coinciden en considerar la computación en la nube como la entrega por "Demanda de recursos computacionales, almacenamiento de bases de datos, aplicaciones, y otros recursos IT, a través de plataformas de servicios en la nube".

Tipos Básicos de computación en la nube

Una vez definido el concepto general de "cloud computing", es importante considerar que todos las cargas de trabajo en un escenario en la nube utilizan recursos que son operados por proveedores de servicios, de manera que los modelos de servicios en la nube definen que recursos son manejados completamente por infraestructura propia o por los proveedores. 

Dentro de los modelos se tiene:

• IaaS: Infraestructura como servicio. Para este enfoque la organización se encarga de la administración, mientras el proveedor por su parte le da a la organización la habilidad de crear y configurar recusos desde la capa de computación; esto incluye maquinas virtuales, contenedores, redes, accesorios, y otros recursos asociados con la infraestructura.

• PaaS: Plataforma como servicio. En este caso la organización solo se preocupa por la instalación de la aplicación. Es decir que el proveedor brinda un ambiente de trabajo sobre el sistema operativo.

• SaaS: Todo gestionado por terceros. Este modelo tiene los menores niveles de control por parte de la organización, de manera que no hay ningún control sobre el "backend", excepto por las tareas relacionadas con la aplicación.

Los conceptos anteriormente descritos se pueden entender mejor con la siguiente imagen:

Tipos Básicos de administración y despliegue en computación en la nube

Basicamente la administración y despliegue en la nube se categoriza en:

• Nube ("Cloud"): Donde la aplicación es totalmente desplegada en la nube y todas las partes de la aplicación se ejecutan en la nube.
• Hibrida ("Hybrid"): En este enfoque se conecta la infraestructura y las aplicaciones entre los recursos en la nube y los recursos existentes que no están localizados en la nube y que se alojan en una infraestructura "On-Premise".
• Nube privada ("On-Premise"): Se despliegan los recursos de la organización, usando virtualización o herramientas de administración. En otras palabras la organización administra todos los recursos.tecnologias en la nube

Tecnologías

Dentro de las tecnologías aplicacadas en la nube, se pueden encontrar:

• Virtualización.
• Contenedores.
• Big Data.
• Fast Data: Procesamiento de datos de streaming.
• Servicios Web.
• Aprendizaje de Máquina.

Algunos Paradigmas

Gracias al florecimiento del "cloud computing" o impulsando su desarrollo, han surgido paradigmas para el desarrollo, pruebas y despliegue:  

• DevOps (Desarrolllo y Operaciones).
• CICD (Integración Contínua, Despliegue Continuo).
• Control de Versiones.
• Automatización de pruebas.
• Arquitectura orientada a servicios y a microservicios.
• Single Page Application (Aplicaciones de una sola página).
• Desarrollo Ágil.

Servicios Básicos

Los servicios y recursos más comunes ofrecidos por los proveedores son, entre otros:

• Cómputo
• Almacenamiento: File System, Cache Storage, Object Storage.
• Base de datos (SQL, NoSQL)
• Red.
• Aprendizaje de máquina.
• Analítica.
• Seguridad o gestión de identidad.
• Realidad Aumentada, Realidad Virtual.
• Integración de aplicaciones.
• Internet de las Cosas.

Proveedores

Dentro de los proveedores de servicios en la nube más utilizados, se encuentran:

• Amazon Web Services
• Google Web Platform
• IBM cloud
• Azure
• Alibaba Cloud
• Oracle Infrastructure

Prestadores de servicios "Nubes Propias"

Se recomiendan especialmente en casos experimentales y académicos, pero no en proyectos empresariales, debido ol alto consumo de recursos y a la complejidad de su implementación.

Prestadores de servicios "Amazon Web Services" (AWS)

Entre las ventajas y herramientas que dispone AWS se encuentras:

• Portafolio Diversificado.
• Ideal para conocer aspectos fundamentales de la computación en la nube.
• Gestión por API, Consola o Interfaz Web.
• Cursos gratuitos.
• Ruta de certificación.

Servicios de AWS

• EC2.
• Autoscaling.
• Cloud formation.
• AWS IAM.
• Lambda (FaaS).
• S3 (Almacenamieto).
• Elastic Search (Análisis de Logs).
• Cloud Watch (Monitoréo de recursos).
• Kinesis.

Buenas Practicas de seguridad en AWS

Se recomienda habilitar MFA (Multifactor Authentication), ademas de administración de identidad y acceso IAM y limitar o restringir los permisos de roles y usuarios.

Para profundizar sobre los conceptos tratados en esta sesión se recomienda el siguiente video:

El primer Paradigma a considerar dentro del "desarrollo, pruebas y despliegue" de aplicaciones basadas en los recursos de la nube es:

DevOps

DevOps es un movimiento cultural que cambia el modo en el que los individuos piensan su trabajo, valora la diversidad del trabajo realizado, soporta intencionalmente los procesos, por los cuales las empresas generan valor, y mide los efectos del cambio social y técnico. Esta es una forma de pensar y de trabajar que permite a los individuos y organizaciones desarrollar y mantener practicas de trabajo sustentables. Es un marco cultural para intercambiar historias y desarrollar empatía, permitiendo a las personas y equipos practicar sus oficios de manera efectíva y duradera. (Davis & Daniels, 2016)⁠

DevOps en sí mismo es un acrónimo de "Desarrollo" y "Operaciones".


Desarrollo: "Plan, Code, Build, Test".
Operación: "Release, Deploy, Operate, Monitor".

En una sesión posterior será considerado con mayor profundidad DevOps.

Tecnologías en el flujo de trabajo de DevOps