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

[popup_anything id=”2076″]

Categories
54cuatro

El shift&lift no convierte tus aplicaciones a microservicios

Nota publicada originalmente en Linkedin.

Alguien lo tenia que decir. Hablando con clientes, conocidos y amigos, creo que hay un poco de confusión respecto al concepto de containers y al de microservicios.

El container permite correr una app de forma isolada del sistema operativa. Una VM en cambio debe correr siempre un sistema operativo. En un contenedor el kernel y partes de la infraestructura del SO se comparten. Para la máquina virtual, se debe incluir un SO completo.

Diferencia entre VM y Container

El #microservicio es la visión funcional de lo que estamos armando, y podriamos hacerlo en containers y también con #VMs. Los microservicios son conceptualmente la división de las aplicaciones en componentes pequeños e independientes entre sí. A diferencia de un enfoque tradicional y monolítico sobre las aplicaciones, en el que todo se crea en una única pieza, los microservicios están separados y funcionan conjuntamente para llevar a cabo las mismas tareas. Dada la historia de #SOA, los microservicios no son realmente tan nuevos como una idea. Sin embargo, los microservicios se han vuelto más viables gracias a los avances en las tecnologías de “contenedorización” (se dice asi???).

Acá es donde veo habitualmente un concepto erróneo. Tomar una aplicación #PHP corriendo en un #LAMP y subirla a #Docker es tan solo un #shift&lift. Tiene ventajas? Si, claro que tiene ventajas. Sacamos varios componentes del medio, dependencias de librerías, y la aplicación es mucho mas portable. Ahora, por hacer eso no convertimos nuestra app a microservicio.

Para que la aplicación sea un microservicio necesitamos transformarla. Mínimo que hable API.

Aquí viene el desafío. Un microservicio requiere mucho mas esfuerzo que resolver la parte técnica. Un equipo desarrollando microservicios necesita mucha mas autonomía para testing, seguridad, operación, etc, que el habitual modelo de silos instaurado en las organizaciones.

Melvyn Conway en 1967 dijo: “Cualquier organización que diseñe un sistema producirá un diseño cuya estructura sea una copia de la estructura de comunicación de la organización.”.

Haciendo foco en esa mención, y apoyado por este gráfico de Martin Fowler es que necesitamos realizar modificaciones organizacionales para construir aplicaciones como microservicios.

Tiene ventajas desarrollar en microservicios? Claro. Los microservicios son versátiles, se pueden portar de una instalación on-premise a cloud en segundos (y viceversa), son fáciles de escalar y de mejorar de forma constante, mejora las tolerancias a fallas. Pero también tienen contras. Por ejemplo, hemos visto que las pruebas integrales son mas complicadas, es necesario evitar la expansión sin control dado que son difíciles de gestionar y controlar, algo que puede ser minimizado recurriendo a procesos automatizados de orquestacion.

Mientras redactaba esta nota me tope con este manual técnico de Manuel Barrios sobre Docker. Para los sysadmin de la vieja escuela, les recomiendo la lectura.https://blog.mymware.com/2019/03/19/docker-desde-cero-p1.html

La idea de la nota no era desalentar el shift&lift, muy por el contrario, larga vida!

Entendiendo bien cada caso puntual tiene muchos beneficios que tienen que ver con mayor eficiencia, disminución de recursos de hardware, reducción de costos de licenciamiento, portabilidad y muchas otras ventajas.

[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″]