Etiqueta: docker

#camino-docker: elección de la plataforma

#camino-docker: elección de la plataforma

Cuando una organización decide adoptar Docker debe decidir de qué runtime utilizará. En forma simplificada y a muy grandes rasgos podríamos decir que hay 2 estrategias posibles:

  1. Correr directamente docker-machine/docker-compose en sus servers
  2. Correr una plataforma de administración/orquestación de contenedores

Entre estos dos extremos hay algunas otras opciones que están a mitad de camino como ser Nomad, que combinándose con otras herramientas puede proveer funcionalidades comparables con las de un administrador/orquestador.

Personalmente la opción 1 me parece medio precaria y no aplicable a algunos escenarios ya que implica tener que resolver N cuestiones adicionales que en la opción 2 ya vienen resueltas como ser escalabilidad y disponibilidad.

Entonces, suponiendo que uno elige la opción 2 aparece otra decisión a tomar: qué plataforma de administración de contenedores utilizar. En este sentido Kubernetes, la plataforma de administración de contenedores open source desarrollada por Google, viene con un crecimiento muy importante. Este crecimiento está evidenciado por el hecho de que varios vendors (Microsoft, RedHat, IBM, Amazon, etc) han generado productos/servicios basados en Kubernetes. Un punto a tener presente para tomar esta decisión es si uno pretende correr on-premises o en la nube pues a partir de ello uno tendrá ciertas opciones para correr su propio cluster de Kubernetes o podrá directamente utilizar «Kubernetes as a  Service» transfiriendo el costo de administración del cluster a un proveedor.

Personalmente, en términos de cloud he estado en proyectos utilizando el servicio de Kubernetes de Google, mientras que en escenarios on-premises he estado en proyectos utilizando OpenShift. Actualmente estoy en un proyecto que utiliza la solución on-promises de IBM que está basada en Kubernetes. Hay dos opciones bastante populares con las que aún no he tenido oportunidad de trabajar: Amazon EKS y Azure AKS.

El camino organizacional hacia Docker (nueva serie #camino-docker)

Docker vino para quedarse. Los grandes vendors lo vieron, le dieron su visto bueno y se sumaron al negocio. Microsoft, IBM,Google, Amazon y RedHat son algunos de los vendors que están ofreciendo productos y/o servicios para correr Docker ya sea en la nube como también On-Premises. En lo que va de este año he trabajado con 3 organizaciones en su camino de adopción de Docker y esta semana participé de una reunión en la que se debatió este tema. A partir de eso es que se ocurrió escribir una serie de artículos compartiendo algunas de las lecciones que he aprendido al trabajar con distintas organizaciones en su camino de adopción de Docker. Por el momento tengo en mente escribir sobre los siguientes temas:
  • Elección de la plataforma
  • Creación de contenedores / Dockerfiles
  • Manejo de configuración
  • El proceso de despliegue
A modo de introducción comparto algunos artículos de terceros para ir entrando en tema:

Herramientas varias para Docker

Quiero compartir algunas herramientas que me han resultado muy útiles al trabajar con Docker/Kubernetes.

En https://access.redhat.com/containers/ se puede encontrar una interesante cantidad de imágenes Docker curadas por Red Hat.

El Red Hat Container Development Kit, es un conjunto de herramientas para facilitar el desarrollo de contenedores. Entre estas herramientas se encuentra una variante de Minishift.

Minishift una herramienta que permite correr un cluster de OpenShift de forma local en cualquier notebook.

Source to Image es una herramienta que permite crear imágenes de una forma repetible trabajando a un cierto nivel de abstracción sin necesidad de escribir Dockerfiles.

 

Nueva edición del Taller de Prácticas DevOps incluyendo OpenShift/Kubernetes

El próximo jueves 3 de mayo voy a dictar una nueva edición de mi taller de prácticas devops, pero esta vez con nuevo agregado: OpenShift, la plataforma de gestión de contenedores desarrollada por Red Hat y basada en Kubernetes.

Hacía tiempo que tenía ganas de incorporar al taller algún ejercicio de Kubernetes pero no lograba buscarle para vuelta para que me dieran los tiempos. Finalmente decidí sacar un ejercicio de Puppet para agregar uno de OpenShift/Kubernetes.

Los interesados en participar pueden completar este formulario y los contactaré en breve:

← Back

Se ha enviado tu mensaje

 

Candidate Architecture: OpenShift + Java/Spring + React

I am working in a project with some folks at 10Pines. The client is a big company with operations in most countries of LatinAmerica. From a functional point of view, the project is not so complex, but it has some interesting challenges:

  1. The redesign of  delivery process
  2. The enhacement of the SCM strategy
  3. The design and implementation of a new infrastructure based on OpenShift

In this article I want to focused on points 2 and 3.

Regarding SCM we are using Git (BitBucket) to store code …..and configuration, yes, configuration. We store configuration in a Git repository and make it accesible via Spring Cloud Config. At the same time we manage infrastructure as code, that is: the definition of all the infrastructure is written in code, basically Dockerfiles and other scripts. And of course this is also stored in a Git repository.

Regarding the new infrastructure we are using Docker on Kubernetes, or more specifically OpenShift. We consider we are taken too much risk, so we are not using all OpenShift features, for example we are not using the integrated Jenkins or the configMaps. We continue using our previous build process with some minor extensions, that is: our old and solid Jenkins takes care of the CI process, when we have a feature ready we build the corresponding artifact and publish it in Artifactory. Then Jenkins interacts with OpenShift to trigger the build of the corresponding Docker Image. The process of building the Docker image runs inside OpenShift and implies downloading the corresponding artifact from Artifactory. Once the new image is built and publish, a new deployment is automatically triggered. The following picture represents our build pipeline.

openshift_2

In terms of runtime, our application includes 2 artifacts: a RestAPI (built on Spring-Boot) and a React application (that is served by Nginx). Each of these artifacts is packaged into a Docker container. Finally we have 2 pods, each of them runs 2 docker containers: one that contains part of the application and another one that runs Spring Cloud Config. The following picture shows a summary of this runtime architecture.

 

It worth e mentioning that Spring Cloud Config container is instantiated in each pod but it is only accesible inside the pod.

To be continue…

 

 

Descubriendo OpenShift

Recientemente la gente de 10 Pines me invitó a participar en uno de sus proyectos para dar una mano con las cuestiones de infraestructura. Resulta que lograron convencer a uno de sus clientes para usar contenedores como infraestructura de producción.  Al parecer el área de arquitectura de este cliente ya venía estudiando la posibilidad de usar contenedores a partir de la implementación de OpenShift. Finalmente los planetas se alinearon y allí estaré yo colaborando en el diseño e implementación del esquema de desarrollo y deployment sobre OpenShift.

OpenShift es el nombre de «una marca» creada por RedHat y que incluye:

  • OpenShift Origin, que es el proyecto de código abierto
  • OpenShift Online, que es una instancia de OpenShift administrada por RedHat, que corre en la nube y que se ofrece como servicio
  • OpenShift Enterprise, es que la plataforma que RedHat vende como producto para instalación on-premise

OpenShift está basado en Kubernetes (el orquestador de contenedores desarrollado por Google) y agrega a este una serie de servicios/funcionalidades complementarios que facilitan mucho su uso y administración.

A medida que vaya aprendiendo más de OpenShift, iré compartiendo más información.

A producción con Docker

Hace un par de semanas comencé a trabajar en un nuevo proyecto para dar una mano con cuestiones de infraestructura. Un punto interesante que me llevó a involucrarme en el proyecto es que se planea utilizar docker en el ambiente productivo. El equipo ya se encuentra utilizando docker + compose sobre sus servidores virtuales, pero la idea es utilizar el servicio de contenedores de Amazon.

Dicho servicio de contenedores no es completamente compatible con Docker-Compose. En primera instancia el servicio de Amazon provee un conjunto mucho más amplio de funcionalidades pero al mismo tiempo algunas funcionalidades soportadas por Compose están diseñadas de forma distinta en Amazon. Es interesante que Amazon provee entre sus herramientas una que convierte los Docker-Compose al formato de Task Definition que utiliza Amazon.

Continuará…