Categories
54cuatro

Administrando contenedores con GitOps

Como analizamos en notas anteriores acerca de #GitOps, es importante destacar que su adopción permite gestionar las configuraciones usando Git, y cobra vital importancia cuando hablamos de contenedores dado que se construyende forma declarativa, la configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).

¿Porque es importante GitOps cuando hablamos de contenedores?

Recordemos que cuando desplegamos un #container basicamente pulleamos código. De esta manera, poder tener un control de versiones permite controlar los despliegues de los #contenedores, por ejemplo para recuperarse de cualquier implementación fallida.

Ademas por medio de herramientas es mucho mas transparente realizar cambios operativos, por ejemplo, solucionar un problema de producción mediante un ‘pull request’ en lugar de realizar cambios en todo el sistema productivo.

Las herramientas GitOps como ArgoCD o FluxCD permiten actuar como una fuente unica de verdad, garantizando los estados de los clusteres a partir del control de las configuraciones.

Deployment Pipeline

Usando CI/CD con GitOps

Estas herramientas estan monitoreando los repos con las configuraciones para detectar cambios o imágenes nuevas, de manera de desencadenar automáticamente implementaciones o cambios de configuraciones.

Estas herramientas actuan como CI/CD sin requerir de herramientas adicionales, y el despliegue se encuentra asegurado debido a que funcionan en un formato denominado “atomico y transaccional”, de manera que existen logs que garantizan que las transacciones se realicen correctamente o en caso de fallar no sean aplicados los cambios.

GitOps en la nube

El desarrollo de implementacionees en #kubernetes requiere el despliegue de aplicaciones, clusteres, entornos, etc; y los despliegues en la nube no son una excepción.

Por ese motivo, comprender como GitOps se integra con aplicaciones #cloud es importante para poder crear #pipelines CI/CD.

En el caso de #Azure, se propone la creación de una integración con la solucion #AzureDevOps.

Arquitectura de CI/CD con GitOps
  • El repositorio de aplicaciones contiene el código de la aplicación. Las plantillas de implementación de la aplicación residen en este repositorio en un formato genérico, como Helm o Kustomize. Cualquier cambio en este repo dispara el proceso de implementación.
  • El registro de contenedor contiene todas las imágenes propias y de terceros que se usan en los entornos de Kubernetes.
  • En este caso la integración esta realizada con #FluxCD, como servicio que se ejecuta en cada clúster y es responsable de mantener el estado deseado. Como mencionamos mas arriba, este servicio sondea el repositorio de GitOps en busca de cambios en su clúster y los aplica.
  • Dentro de este esquema propuesto por Microsoft incorporan #AzureArc, una herramienta que ofrece una administración simplificada para Windows, Linux, SQL Server y para este caso particular, los clústeres de Kubernetes. En este caso,  Azure Arc sirve para los diferentes entornos necesarios para la aplicación. Por ejemplo, un único clúster puede atender a un entorno de desarrollo y QA a través de espacios de nombres diferentes. 

Beneficios y Conclusión

Git es el estándar de facto de los sistemas de control de versiones y es una herramienta de desarrollo de software común para la mayoría de los desarrolladores y equipos de software. Esto facilita que los desarrolladores familiarizados con Git se conviertan en colaboradores multifuncionales y participen en GitOps. Ademas un sistema de control de versiones le permite a un equipo rastrear todas las modificaciones a la configuración de un sistema.

GitOps aporta transparencia y claridad a las necesidades de infraestructura de una organización en torno a un repositorio central ue resuelven de forma muy simple las implementaciones y los rollbacks en infraestructuras complicadas.


[popup_anything id=”2076″]
Categories
54cuatro

SRE: Observabilidad y Monitoreo

Nota publicada originalmente por el CTO de #54cuatro en Linkedin.

La #observabilidad es una característica dentro de un sistema de control que permite dar con una solución prediseñada a un problema que surja. Dentro del mundo TI, la observabilidad de un sistema permite evaluar resultados para llegar a conclusiones sobre los estados de un recurso.

Si bien han surgido distintos puntos de vista sobre la definición, a partir de la masificación de #DevOps (y #SRE), el crecimiento de las instalaciones #Cloud, el uso intensivo que hacen las plataformas de #bigdata y la adopción de #Contenedores, la observabilidad se volvió una palabra en constante crecimiento.

A diferencia de las actividades de monitoreo tradicionales, donde el objetivo es “observar” el estado, la salud y #performance de #Redes, #Servidores, #Servicios, #Redes, Aplicaciones, etc para luego tomar acciones, la observabilidad podriamos definirla como un componente mas del diseño de una aplicación que permite tener en cuenta todos los elementos de la misma para saber como monitorearlas y operarlas.

Al igual que el análisis de la seguridad en nuevos desarrollos (#DevSecOps), es de esperar que también se realicen los diseños de monitoreo de los componentes en etapas tempranas de la construcción del software y no al momento de la implementación.

Sin ir a mas, en el sitio de SRE de Google, indican que la operación exitosa de un servicio implica una amplia gama de actividades: desarrollar sistemas de monitoreo, capacidad de planificación, responder a incidentes, asegurar que se aborden las causas fundamentales de las interrupciones, y ponen esta pirámide que permite ver los elementos que intervienen para hacer que un servicio sea confiable, desde el más básico hasta el más avanzado.

No hay texto alternativo para esta imagen

Diseñar y desarrollar aplicaciones “observables” permite ser proactivo y prever los posibles puntos de fallas, con el objetivo de lograr rápidas recuperaciones ante fallos y administrar de forma eficiente el capacity planning y junto a ello la performance.

Podemos pensar un sistema observable a partir del control de todas las partes, conociendo como se desarrolló, como estará montado y como se comportará, podremos definir el monitoreo horizontal (servidores, redes, transacciones, logs) y el monitoreo vertical (experiencia de usuario, tracing, debug) mas acorde. El Monitoreo y la Observabilidad son cosas diferentes y también complementarios.

De hecho, el concepto de observabilidad no tiene que estar ligado al incidente. Una aplicación observable puede reportar datos que permitan mejorar la arquitectura, la performance, el escalamiento automático sin la necesidad que haya un perjuicio o incidencia dentro de la plataforma.

Para ir finalizando, podemos decir que debemos de adoptar una estrategia que consista en diseñar aplicaciones observables desde su nacimiento, diseñando de que manera vamos a controlar y monitorear la nueva aplicación, entendiendo que componentes vamos a usar y cuales son las mejores métodos y/o herramientas para respaldas la salud de esas aplicaciones; de allí el nacimiento de grandes conjuntos de tools que funcionan muy bien juntas. Se me vienen a la cabeza soluciones basadas en #ELK, en #Influx o la dupla #Prometheus y #Grafana, básicamente Prometheus recopila datos y métricas de diferentes servicios y los almacena de acuerdo con un identificador único, el nombre de la métrica, y una marca de tiempo (en una base time series) y Grafana se encarga de realizar hermosos dashboards donde mirar dicha información. Toda esta informacion puede ser “cruzada” con aquellos datos adicionales que tengamos configurada en nueva navaja suiza del monitoreo como las experiencias de los usuarios y con toda la correlación de los eventos determinar que todos los servicios de monitoreo estén vivos y saludables.

Video de Monitoreo de Infra

No hay texto alternativo para esta imagen

Video de Monitoreo #Netflow

Como siempre… Gracias por leerme! Hasta la próxima!

[popup_anything id=”2076″]

Categories
54cuatro

Containers vs Virtual Machines

¿Cuál es la diferencia entre los contenedores y la virtualización basada en Hipervisores?

El concepto de contenedor no es nuevo. Desde hace muchos años existe la creación de contenedores en sistemas corriendo #Solaris, #HP-UX o #AIX. Ahora parece que la contenerización sobre Linux llegó para quedarse a partir de buenas herramientas como #Docker o RKT.

Para diferenciar ambos modelos de virtualización podemos aclarar que en un entorno virtual se debe instalar un servidor físico con un #hypervisor, que dentro contendrá máquinas virtuales cada una con su sistema operativo corriendo.

En el caso de un entorno mediante #contenedores, el servidor físico ejecuta un solo sistema operativo que será compartido con la cantidad de #containers creados. Cada container hace uso del núcleo compartido del sistema con modalidad de “solo lectura”.

¿Qué beneficios conlleva compartir el núcleo de un solo sistema?

En la práctica los contenedores son más livianos, fáciles de administrar y consumen menos recursos que una vm.

Mientras que un container solamente lleva instalado sus aplicaciones particulares, una virtual machine lleva encima todo un sistema operativo instalado.

De esa manera, en un equipo físico se pueden agrupar muchos más contenedores que máquinas virtuales.

A nivel funcional, usar contenedores permite mucha flexibilidad para el escalamiento de recursos, y por otro lado la administración se ve simplificada al tener en un solo kernel toda la plataforma de software de base, dependencias y demás componentes.

¿Los contenedores tienen puntos en contra?

La respuesta es sí. Para cada solución que se busque se debe analizar que conviene. Mientras que para algunos entornos es más apropiado un container, en otros casos la vm es lo apropiado.

Los contenedores suelen tener asociada la impresión de que ante una falla en el sistema operativo host, todos los contenedores se ven afectados, lo que es una realidad. A nivel seguridad en caso de verse comprometido un único sistema operativo, se vería afectado la totalidad de los containers.

De todos modos, los containers existen hace mucho tiempo y tienen larga vida por delante. Muchos artículos suelen enfrentar la tecnología de containers contra la tecnología de virtualización sobre hipervisores. En nuestro modo de ver, creemos que no son competencia sino más bien un complemento uno de otro y que incluso podrían optarse por tener ambientes mixtos.

Por mencionar el caso, Microsoft anuncio que la versión de Hyper-V disponible a partir de Windows Server 2016 permitirá la creación de containers, lo que es un claro mensaje que ambas tecnologías pueden convivir y entre ambas poder brindar soluciones a necesidades cada día más complejas.

Gonzalo D’Angelo

[email protected]

[popup_anything id=”2076″]