Categories
54cuatro

FinOps: La Clave para una Gestión Eficiente de los Costos en la Nube

FinOps representa la gestión financiera de los servicios en la nube y es esencial para las empresas que buscan equilibrar la excelencia operativa con la eficiencia en costos. Este enfoque es particularmente crucial en organizaciones grandes y complejas, donde los costos asociados con la infraestructura en la nube pueden escalar rápidamente sin una gestión adecuada. #FinOps no solo ayuda a mantener los gastos bajo control, sino que también integra las áreas técnicas, administrativas y financieras para una gestión holística y estratégica de los recursos en la nube.

El proceso de FinOps sigue un ciclo virtuoso, similar al de #DevOps, que incluye operar la plataforma de nube, informar sobre los costos y optimizar los recursos continuamente. Este ciclo involucra a diversos actores dentro de la empresa, incluidos los equipos de ingeniería, compras, finanzas y productos. Cada uno de estos grupos desempeña un papel vital en la implementación de las estrategias de FinOps, trabajando juntos para asegurar que los recursos en la nube se utilicen de manera eficiente y económica.

Los pilares fundamentales de FinOps son varios y abarcan aspectos clave de la gestión empresarial y tecnológica:

  • Colaboración entre Equipos: Promueve la cooperación en tiempo real entre los departamentos de finanzas, tecnología, productos y negocios para maximizar el rendimiento de la nube.
  • Decisiones Impulsadas por Valor: Se enfoca en decisiones que equilibran costo, calidad y velocidad, subrayando el valor empresarial de cada inversión en la nube.
  • Responsabilidad en el Uso de la Nube: Fomenta la descentralización del control de los costos, permitiendo que los ingenieros tomen decisiones desde el diseño hasta las operaciones.
  • Datos de FinOps Accesibles y Oportunos: Asegura que la información sobre costos sea compartida rápidamente para permitir una utilización más efectiva de los recursos.
  • Un Equipo Centralizado para FinOps: Un equipo dedicado que centraliza la optimización de tarifas y promueve las mejores prácticas para aprovechar las economías de escala.
  • Aprovechando el Modelo de Coste Variable de la Nube: Utiliza un modelo de costo variable para adaptar los gastos a las necesidades reales, permitiendo ajustes continuos que optimizan el uso de la nube.

El impacto de una gestión ineficaz de los recursos en la nube puede ser significativo, llevando a un sobreprovisionamiento y a un gasto excesivo. Las investigaciones indican que las empresas pueden pagar hasta un 35% más en servicios en la nube debido a la falta de una estrategia de FinOps efectiva. Por otro lado, una gestión adecuada puede reducir estos costos y mejorar la eficiencia operativa.

El objetivo final de FinOps es apoyar un marco de arquitectura que combine resiliencia, seguridad y excelencia operativa con costos ajustados. Esto se logra a través de una comprensión profunda y detallada de los gastos en la nube, promoviendo la transparencia y la colaboración interdepartamental. Al alinear los gastos con el valor empresarial generado, FinOps transforma la gestión de costos en una ventaja estratégica que no solo controla los gastos, sino que también impulsa la innovación y la eficiencia en toda la organización.

En conclusión, FinOps es más que una práctica de gestión; es una filosofía empresarial que requiere una adopción integral y un compromiso a largo plazo para optimizar las inversiones en la nube y garantizar un crecimiento sostenido y rentable. Su implementación efectiva es crucial para cualquier empresa que dependa significativamente de la tecnología en la nube para sus operaciones diarias.

Categories
54cuatro

El camino hacia el análisis y la modernización de los datos

La mayoría de las organizaciones aspiran a estar un paso por delante de la competencia, capaces de tomar decisiones más informadas sobre su negocio y sus clientes para que no sólo tengan éxito, sino que prosperen en un panorama empresarial en constante cambio. Sin embargo, aunque muchas organizaciones tienen los datos para hacerlo, a menudo carecen de la tecnología, los procesos y las personas para optimizar por completo su valor. 

¿Qué es la modernización de datos?  

La modernización no es sólo la palabra de moda más reciente, aunque parece que todos tienen su propia forma de definirla. La modernización de datos tampoco se trata de una sola acción o de implementar un conjunto de herramientas. Es repensar cómo usas los datos y el análisis como empresa. ​ 

Embracing the Future - The Push for Data Modernization Today

A menudo, las personas caracterizan la modernización de datos como simplemente trasladarse a la nube; pero el enfoque que adopta y las ventajas que obtiene van más allá de la simple adopción de la nube. Las soluciones modernas exponen capacidades analíticas avanzadas que ayudan a los usuarios de su negocio a tomar decisiones más inteligentes.  

La modernización de datos requiere principios de gestión de datos modernos. Implica pasar de bases de datos y arquitecturas heredadas a plataformas modernas basadas en la nube y arquitecturas escalables, y migrar a herramientas de análisis modernas.  

¿Cuáles son los beneficios de seguir el camino de la modernización de datos? 

A medida que hay más datos disponibles y los usuarios comerciales requieren análisis mejores y más avanzados, la organización debe poder actuar rápidamente para satisfacer esas demandas.  

La modernización de datos permite escalar y ser flexible, integrar nuevas fuentes de datos, obtener información más rápidamente, democratizar los datos y planificar de manera efectiva el futuro del negocio. 

Los cinco pilares para migrar y modernizar los datos. 

1.) Estrategia de datos 

Es la base de todo lo que haces en el futuro. Va a actuar como una guía para la organización en términos de cómo abordar los #datos y el análisis, no sólo desde una perspectiva técnica, sino también desde una perspectiva de personas y procesos.  

2.) Arquitectura de datos 

Se necesita un pipeline de datos ágil, basado en la nube y preparado para el futuro que permita un acceso más fácil, rápido y flexible a grandes volúmenes de datos y diferentes fuentes de datos.  

3.) Gestión y gobierno de datos  

La gestión moderna de datos requiere que los datos sean precisos y estén disponibles para las personas adecuadas en el momento adecuado.  

4.) Herramientas de análisis 

La migración a herramientas de análisis más nuevas proporcionará mejores capacidades de análisis, incluido análisis en tiempo real, análisis integrado, colaboración mejorada y más.  

5.) Las personas y procesos adecuados 

Es fundamental entender que un esfuerzo de modernización no es sólo un cambio en la tecnología, sino que también un cambio en las habilidades y la formación constante en el “cómo lo uso”. Se necesitan desarrollar las fortalezas y capacidades de la nueva herramienta, y no simplemente tratar de recrear conceptos que funcionaban en la herramienta anterior.  

Conclusión

Las organizaciones deben continuar evolucionando y hacer de la modernización de los datos una prioridad ya que las nuevas tendencias fuerzan cambios significativos en la estrategia de gestión de datos. La modernización requiere que las organizaciones adopten una visión integral de su entorno de aplicaciones e infraestructura.  

Darse cuenta de los beneficios de la modernización de datos requiere pensar más allá de las aplicaciones y la infraestructura y expandirse para considerar cómo impactan y son impactadas por los procesos comerciales, las personas, los datos nuevos, el desarrollo de una cultura #DevOps, el crecimiento de la compañía y sus futuras ventas. 

Categories
54cuatro

¿Cuantos tipos de Testing de Software existe? (parte 2)

Ya revisamos algunas pruebas en la Parte 1 de la entrada.

Continuando con pruebas existentes en el ambiente del Test de Software vamos a seguir con la lista:

Prueba de regresión

El último test mencionado en la entrada anterior hacía referencia a las pruebas de humo. Cuando se configuran pruebas dentro de Pipelines CI/CD, dijimos que ejecutarán pruebas de humo en casi todas las confirmaciones, y como complemento de esas configuraciones, es necesario agregar #pruebas de regresión que pueden ejecutarse a intervalos establecidos o en funciones grandes para garantizar una integración continua sin problemas; esto dado que este tipo de #testing esta orientado a verificar si alguna característica previamente funcional ha cambiado o se ha roto repentinamente.

Pruebas de Carga/Performance

En este caso lo que se busca probar es el rendimiento de un nuevo desarrollo ante una determinada cantidad de carga/tráfico/sesiones; y cual es su respuesta ante la variabilidad de estas condiciones.

Durante esta etapa, es de mucha utilidad probar determinadas situaciones de incremento de tráfico controlado para conocer los límites que la plataforma puede soportar, como también simular el incremento repentino para entender como respondería por ejemplo ante un estampido de conexiones provocadas por DDOS.

Pruebas de Seguridad

Durante estas pruebas, se llevan a cargo ejecuciones controladas donde se busca vulnerar el sistema. Este tipo de test, también llamado Penetration Test, busca controlar los niveles de solidez en materia de seguridad y protección de la información.

Este tipo de pruebas, también es alterada debido a la adopción de #DevSecOps, donde se busca que el aseguramiento de lo que se va desarrollando se haga desde etapas tempranas del desarrollo, controlando librerías, frameworks, llamadas, y todo tipo de cuestiones a medida que se va creando una aplicación, para evitar hacer los controles todos juntos al final; esto da como resultado un software de código mas limpio, con mejores tiempos de entrega y con mayor seguridad.

Testing free icon

Ingeniería del Caos

Estas pruebas, fueron desarrolladas por el equipo ingeniería de Netflix; y consiste en la prueba sobre todo el sistema para entender como se comporta ante fallos inesperados que son generados de forma random para provocar situaciones de desastres.

Esta disciplina nos permite conocer el comportamiento de la aplicación ante ataques, fallas, errores humanos, outages de los datacenters, etc. Cada prueba busca entender como afecta a la aplicación productiva y crear una acción correctiva de manera de ir creando un sistema resiliente capaz de soportar situaciones imprevistas.

La herramienta principalmente conocida para estas pruebas es Chaos Monkey.

Conclusión

Repasamos algunos de los conceptos mas estándares del ciclo de pruebas de software. En la actualidad, se busca incorporar el #testing dentro del esquema #DevOps, como mencionamos en alguna nota posterior, ya existe el término de TestOps y es cada día de mayor importancia el enfoque de agilidad llevado a las pruebas.

Categories
54cuatro

¿Cuantos tipos de Testing de Software existe? (parte 1)

El testing del software es una práctica habitual y que es llevada día a día por miles de testers y especialistas de QA. Pero en la actualidad, el despliegue de pipelines #DevOps obligan a integrar el #testing como parte de los pipelines CI/CD.

Developer free icon

Por eso, hacemos esta entrada para adentrarnos en temas de pruebas de #software.

Esta es una lista de los tipos de pruebas existentes:

Prueba Unitaria

La prueba unitaria nos facilita el test de una parte de código que está realizando alguna acción determinada. Durante la prueba unitaria solamente probamos esa porción de código. Por ejemplo, si estamos haciendo una llamada a una base de datos, posiblemente aun no tengamos la base disponible y emulemos la prueba para saber si el código funciona.

Para esta prueba existen herramientas para los lenguajes mas habituales. En pruebas Java tiene JUnit , Python tiene PyUnit o PyTest , JavaScript tiene Mocha entre otros, .NET tiene xUnit, etc.

Prueba de Integración

En este caso, la prueba de integración nos permite hacer el test sobre varios componentes juntos. Siguiendo con el ejemplo de la prueba unitaria, en este caso, la diferencia sería que la llamada a la base la probaríamos haciendo la llamada realmente a la base destino.

El propósito de este test es justamente probar la interacción entre los diferentes componentes de la app, las relaciones y comunicaciones de los mismos.

Pruebas E2E (Extremo a Extremo)

En este caso las pruebas de Extremo a Extremo, hacen referencia a la ejecución de test sobre toda la aplicación. Seria el broche final de las Pruebas Unitarias y las Pruebas de Integración. En el test E2E, se ejecuta desde principio a fin toda la aplicación y muchas veces es el mismo usuario solicitante el que se encarga de ejecutar este tipo de prueba. Aplicaciones como Cucumber o Postman suelen ser herramientas amigables para la ejecución de estas pruebas.

Las 3 pruebas mencionadas hasta aquí suelen ser probadas en un ambiente aislado, con la función específica de conocer el comportamiento de las nuevas piezas de software.

Prueba de aceptación

En este caso, la prueba de aceptación nos lleva a un bloque de pruebas orientado a recibir la aceptación formal de un Cliente o Usuario, confirmando que los requerimientos solicitados fueron cumplidos tal como fueron pedidos.

Debido a la adopción de metodologías ágiles y de testing como TDD, las pruebas de aceptación suelen ser mas cortas que antaño, ya que el usuario suele estar involucrado durante las fases de desarrollo y el testing se va ejecutando como parte del proceso desarrollo (al igual que las pruebas de seguridad y de performance)

Pruebas de Humo (Smoke Testing)

Este tipo de pruebas, tiene vital importancia durante la configuración de los pipelines CI/CD, ya que las pruebas de humo permiten saber si la compilación del software implementado es estable, a partir de la ejecución de un conjunto mínimo de pruebas al azar que se corren en cada compilación para probar las funcionalidades del software.

Este tipo de testing suele llamarse Test de Confianza y como se mencionó anteriormente, agregar este nuevo bloque de pruebas en el pipeline proporcionará una validación de que la aplicación pasó todos los casos de prueba. 

En otra entrada vamos a continuar con testing focalizados a la Performance y la Seguridad.

Categories
54cuatro

El testing dentro de CI/CD

Desde antes de la fiebre #DevOps que sabemos que había que automatizar las pruebas de software, pero no se hizo. Los equipos de desarrollo fueron haciendo mayor énfasis en las pruebas de interfaz de usuario que en pruebas unitarias, y por consiguiente se fue deformando el enfoque propuesto por Mike Cohn, denominada ‘Pirámide Ágil de Automatización de Testing’.

test automation strategy
Agile test automation pyramid – Mike Cohn

Esta pirámide es quizás la mejor definición de como deberíamos ejecutar las pruebas, y concentrarnos en la interfaz de usuario genera un patrón basado en Detectar Errores, cuando lo que debiéramos hacer es Prevenir Errores.

Pruebas unitarias

Esto tipo de testing es el que se realiza en la etapa de desarrollo, ejecutando pruebas unitarias después de cada compilación se consiguen datos específicos para un programador; ej: hay un error y está en la línea 1143.

Además habitualmente las pruebas unitarias se realizan en el mismo lenguaje que la pieza de software de manera que los programadores suelen mantener una cierta comodidad escribiendo pruebas.  

Capa de Integración

En esta capa, se suele probar la integración de todos los componentes. Es donde se controla que todos los componentes funcionen correctamente y donde se busca comprobar que la lógica del software se encuentra alineada al requerimiento. Estas pruebas no solo aplicación a arquitecturas orientadas a servicios (SOA) sino también a variantes modernas de microservicios. En el caso de pruebas de API, necesita saber cuándo fallan sus API, por qué fallaron y necesita un circuito de retroalimentación ajustado para alertarlo lo antes posible. Es importante el testing en esta capa ya que si bien el end-to-end de las aplicaciones están compuestas de varios servicios que se concatenan entre si, hay muchos casos de prueba que deben invocarse de manera individual dado que no todos pueden ser ejecutados a través de la interfaz de usuario.

Pruebas de Interfaz de Usuario

Llegamos al tope de la pirámide. Y es justamente el tope de la pirámide porque este tipo de pruebas deben realizarse lo menos posible. Por motivos varios, son costosas, difíciles de preparar y requieren mucho tiempo. Ademas de que suelen salir muchos falsos negativos y falsos positivos. Pero de todas modas no debe evitarse esta etapa, dado que probando la interfaz de usuario se logra una prueba de extremo a extremo, para verificar el sistema en su totalidad. 

El equipo de desarrollo de Google sugiere que las pruebas deben ser realizadas 70% de pruebas unitarias, 20% de pruebas de integración y 10% en la capa superior.

Integrando el testing en un modelo CI/CD

Which one is right for you: Waterfall or Agile? |

Recordemos que CI/CD es un pilar de #DevOps que busca desplegar aplicaciones de software por medio de la automatización; y como es bien sabido que el #testing es parte de todo esto, debemos tener integradas las pruebas para poder seguir con el circulo virtuoso que propone DevOps.

Integrar el testing bajo el concepto de “Testing Continuo” permite detectar errores de forma temprana y por ende resolverlos con gran rapidez.

Algunos test que son potencialmente automatizables son las pruebas de regresión, funcionales, de integración y de rendimiento. Algunas herramientas nos permiten facilitar las tareas de automatización de testing, aunque no menos importante es encontrar que será automatizado, y también orquestar inteligentemente las pruebas.

Herramientas para Pruebas Continuas

  • #Katalon. Esta herramienta ofrece una plataforma integral para realizar pruebas automatizadas para interfaz de usuario web, servicios web, servicios API y dispositivos móviles.
  • #Travis CI. Travis CI es un servicio de integración continua alojado que se utiliza para crear y probar proyectos de software alojados en GitHub y Bitbucket.
  • #Selenium es una herramienta de prueba compatible con la mayoría de los navegadores convencionales, como Chrome, Firefox, Safari e Internet Explorer.
  • #Azure Test Plan. En lo que refiere a ambientes #cloud, #Microsoft tiene una gran oferta de soluciones dentro de su suite Azure DevOps, y en este caso un kit de herramientas de pruebas exploratorias y manuales con una interfaz intuitiva e integrada.

Conclusión

Este tema da para largo y en próximas entradas seguiremos explorando el testing en el marco de DevOps, haciendo foco en Microservicios, API e incluso en Data.

El testing como parte de una cadena CI/CD es muy beneficioso, pero también pueden muy desafiante. Es necesario tener un buen plan de testing tradicional antes de incorporar este procedimiento de prueba.

Posterior a tener un buen marco de pruebas es recomendable trabajar en las estrategias de incorporación del flujo de pruebas al pipeline.

Gracias por leernos!


Contactate
Categories
54cuatro

¿Y ahora MLOPS?

Quienes nos siguen dirán, ¿Otro nuevo Ops en familia? Y si, tenemos que contarles sobre #MLOPS.

Repasemos. #DevOps conjuga la unión de los equipos de Desarrollo con Operaciones. #DataOps va acerca de la integración de datos en pos de soluciones analíticas. #GitOps nos ayuda a con el despliegue continuo sobre plataformas de contenedores. Y ahora nos toca describir MLOPS.

¿Que es MLOPS?

El nombre viene de la conjugación de Machine Learning y Operaciones. Y su filosofía gira en torno a lo mismo que sus familiares *Ops, la de generar un espacio colaborativo, en este caso entre Científicos de Datos y Operaciones. Es importante destacar que hace un tiempo se puso de moda el termino #AIOPS, pero esta mas orientado a una implementación de Inteligencia Artificial a las operaciones de TI, de manera que podria ser confundible con MLOPS.

Empecemos a descubrir MLOPS.

MLOps Principles

¿Que soluciona MLOPS?

MLOps es un descendiente directo de DevOps, y continuando con el éxito busca resolver la integración de los equipos de operaciones (en este caso quienes operan los datos) con aquellos que requieren de esa data para generar informacion de valor.

MLOps incorpora al juego a los científicos de datos, quienes requieren obtener conjuntos de datos de manera automatizada desde donde poder desarrollar sus modelos analíticos.

¿MLOPS requiere de un Pipeline?

Correcto, MLOPS tiene su propio concepto de Pipeline, solo que el CI/CD, esta orientado a integraciones de datos, y junto con ello, capacidades de gobernanza, transparencia y protección de la informacion.

  • En CI ademas de probar y validar código y componentes, se deben validar datos, esquemas y modelos.
  • En CD ademas de desplegar un paquete, debe implementar todo un servicio de manera automática.

En resumidas fases podriamos mencionar que MLOPS requiere de 4 pasos fundamentales:

  • Ingestar datos hacia un almacenamiento.
  • Procesar los datos almacenados.
  • Entregar esos datos para ser entrenados dentro de modelos de #MachineLearning.
  • Entregar el output del modelo, dependiendo el caso de negocio requerido.
Gartner on ML pipeline
Esquema MLOPS propuesto por Gartner

¿Como comienzo mi camino hacia MLOPS?

Es importante destacar que la comunidad que impulsa MLOPS crece dia a dia. Y ese crecimiento lleva a tener mas opciones que simplifican la adopción de MLOPS. Tanto #AWS, #GCP, #Azure, #IBM y otros proveedores tienen su propio stack tecnológico para hacer frente a una implementación de MLOPS, y como todo, no existe un método único, pero si buenas practicas recomendadas a seguir.

Para empezar, debemos crear una cultura de automatización.

El objetivo de MLOps es automatizar los pasos completos del flujo de trabajo de ML sin intervención manual. A partir de ello debemos dividir las tareas en fases que al final de la historia se ejecuten como un pipeline. Estas tareas son:

  1. Adquirir los datos desde las fuentes que identifiquemos. Y dentro de esta fase de adquisición vamos a Catalogar los Datos, Ingestarlos a nuestro almacenamiento, Procesarlos para generar nuestra data correcta, y finalmente Entregarlos para su consumo.
  2. Desarrollar los modelos. En esta fase (quizás la mas importante) un científico de datos generara interacciones con distintos modelos analíticos, validando la data recibida, e identificando la performance de los análisis. En caso de que la data recibida no sea suficiente o de la calidad esperada, el pipeline debe ser reajustado en el paso 1. Pero si los modelos tienen buenos rendimientos se pasara a la siguiente fase.
  3. Despliegue de los modelos. Como mencionamos anteriormente, si un modelo tiene buenos rendimientos y sus outputs son confiables, esta listo para ser pasado a producción. Tener un modelo productivo permite integrarlo a nuestro software, dejar una API para consultas, alimentar un sistema, etc. Pero atención, el modelo requiere de cuidados, y es por eso que existe una ultima etapa.
  4. Monitoreo de modelos. Como vamos a tener corriendo todo de forma automatizada, es importante monitorear como es la performance de los modelos. Cualquier desvio en la cantidad y/o calidad de los datos que se reciben pueden alterar el funcionamiento de nuestro desarrollo. Y es por eso que en un modelo MLOPS, vamos a determinar un control para conseguir que nuestro pipeline siempre asegura la entrega de información de valor para el negocio.

Conclusión final

Para ejecutar un proyecto exitoso basado en ciencia de datos es imprescindible implementar MLOps y para ello se debe llevar a cabo una orquestación de las herramientas tecnológicas con las habilidades para integrarlas.

Consultas?

Contactate
Categories
54cuatro

DevOps – Los desarrolladores están en el centro de la innovación

No solo sus competidores tradicionales lo reconocen: hay nuevos competidores que comienzan a lanzar #software innovador, trabajando dentro de su sector, pero al revés.

¿Usted elegiría software creado por un puñado de desarrolladores aislados o software creado por miles de personas que trabajan en colaboración para construir algo más sólido? 

Innove a gran escala. Confíe en lo que entrega.

Microsoft #Azure es la nube con servicios de desarrollador integrados y #GitHub construye sobre esta base para convertirse en la Plataforma #DevOps central de #Microsoft.

Aproveche Microsoft DevOps con GitHub para entregar innovación rápida y eficiente. ​

Innovación de producto

Herramientas de administración confiables y escalables en todos los niveles, además de una comunidad diversa detrás de todo

Rapidez de entrega

Para innovar, las empresas deben moverse rápidamente.

Flexibilidad y control

Cualquier desarrollador, cualquier #nube. Use las herramientas que elija, solo traiga el código.

Seguridad

Un líder confiable en seguridad, el mejor.

Acelere la entrega con #DevOps.

Su producto necesita llegar rápidamente a los clientes
y mantenerse disponible.

  • Objetivos y herramientas compartidos
  • Colaboración
  • Automatización de procesos
  • Entrega y mejora continuas

Implementación continua y conforme con la normativa

Servicios integrados de #seguridad, #monitoreo y administración de nivel empresarial

GitHub: El desarrollador de plataformas
nro 1 en el planeta

  • Mayores contribuciones: 1,100 millones en 2018
  • Más desarrolladores: 33 millones
  • Mayor crecimiento: 8 millones de nuevos desarrolladores en 2018
  • Más Repos: 96 millones
  • Mayor actividad: 200 millones de PR, 800 millones de solicitudes diarias de #API 
  • Más estudiantes: 1.1 millones
  • Más organizaciones: 2.2 millones
  • Mayor seguridad: 5 millones de alertas de vulnerabilidad en 2018

Desea crear su plan de desarrollo para implementar DevOps, contactenos

Contactate
Categories
54cuatro

Creando un Pipeline CI/CD DevOps

Creación de un pipeline CI/CD desde Azure DevOps a KongHQ

En este post Silvio Ricagno y Alejandro Orozco nuestros especialistas en Microservicios nos van a explicar cómo ejecutar una integración entre Azure DevOps, Docker hub, ArgoCD, Rancher y KongHQ.

Información útil sobre este ejemplo

  • La idea principal del ejemplo es resolver de una manera muy sencilla la comunicación entre estas herramientas usando varias características que nos facilita .Net sobre Visual Studio y Azure #DevOps.
  • Tanto KongHQ como Argo CD ya se encuentran instalados y configurados sobre Rancher.
  • El Framework del proyecto usado es .Net Core 3.1.
  • Es recomendable tener instalado y actualizado, en la PC donde estés trabajando con el Visual Studio, Docker Desktop.
  • El archivo .sln y .csproj deben estar en carpetas distintas.

Herramienta que usamos

En nuestra demo usamos la siguientes herramientas

Estructura de la solución

  • Para genera la configuración necesaria para contenedores, usamos la opción de “compatibilidad con orquestador de contenedores” disponible haciendo clic derecho en el nombre del proyecto en el submenú “agregar”. Aquí elegimos “Kubernetes/Helm”.
  • Es muy importante que el Dockerfile esté a la altura del .sln, esto nos ahorrará varios dolores de cabeza. Si bien en la siguiente imagen aparece a la altura del .csproj, éste no se usa.

Dockerfile

  • Debemos asegurarnos que la ruta del COPY del .csproj (en este caso en la línea 7) sea correcto, tiene como punto de vista la carpeta donde está el Dockerfile (aclarado en el apartado anterior).
  • En este caso la aplicación correrá sobre #Linux.

Código del Dockerfile

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["API_Test/API_Test.csproj", "API_Test/"]
RUN dotnet restore "API_Test/API_Test.csproj"
COPY . .
WORKDIR "/src/API_Test"
RUN dotnet build "API_Test.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "API_Test.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "API_Test.dll"]

Edición del Helm Chart

Value.yaml

Una gran facilidad que nos brinda esta herramienta es la posibilidad de establecer determinadas variables, para que en el CD (en esta caso con Argo) se genere dinámicamente el deploy, el service y el ingress.

Entonces cargamos el archivo de la siguiente manera.

fullnameOverride: api-test-k8s
replicaCount: 1

image:
  repository: docker.io/sricagno/test-api10
  tag: 35
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80

deployment:
  containerPort: 80

ingress:
  enabled: true
  annotations: {}
  host: api-test-k8s.54cuatrocicd.10.63.32.30.xip.io
  path: /weatherforecast

Ingress.yaml:

Ahora editamos el ingress.yaml en la sección de rules del archivo.

El archivo original:

Finalmente lo dejamos así:

{{- end }}
  rules:
    - host: {{ .Values.ingress.host }}
      http:
        paths:
          - path: {{ $ingressPath }}
            backend:
              serviceName: {{ $fullName }}
              servicePort: http
{{- end }}

Sacamos el “range” de la línea 34 y 42 (“{{- end}}”), ya que no queremos tener más de un host. Por último en host ponemos el nombre de la variable de host que vamos a usar en este caso .Values.ingress.host.

Pipeline CI en Azure DevOps

Creamos un pipeline en Azure DevOps, al crear un nuevo Pipeline en la parte inferior nos permite seleccionar “usar el editor clásico” y así es como continuamos: seleccionamos la rama del repositorio a implementar y elegimos “empty job”.

Nos mostrará una pantalla como las siguientes. Agregamos un por una las 3 tareas.

Tarea 1

Tarea 2

Tarea 3

Como repositorio de #Docker usamos Docker Hub.

Si no tenemos registrado en Azure DevOps el repositorio de Dockers, lo podemos administrar desde “Manage”, debemos dar de alta el repositorio donde almacenaremos la imagen Docker.

CD con ArgoCD

Como mencionamos al principio, teníamos instalado y configurado #ArgoCD sobre #Rancher.

Dentro de Argo, previamente, conectamos el repositorio de Azure.

Creamos una aplicación nueva

Establecemos los siguientes parámetros.

Nota

Si lo ingresado anteriormente está bien, se puede leer el Helm un poco más abajo. Como aparece a continuación.

Finalmente le damos a Create y luego sincronizamos.

Si todo se ejecutó de manera correcta se debería haber desplegado la imagen, creado un servicio y un ingress, en Rancher:

En Rancher

Despliegue

Servicio

Ingress

Probamos la aplicación

Finalmente accedemos a la aplicación, esto se rutea a través de KongHQ.

Respuesta

Video relacionado

Contactate

    Please prove you are human by selecting the heart.