¿De donde sale GitOps?

Weaveworks on Twitter: "Great article on #GitOps by @wbiller: "GitOps – Continuous Deployment für Kubernetes". #CICD #kubernetes #k8s https://t.co/nUi05zj9DR… https://t.co/PH2fn1qZmc"

GitOps surge principalmente de la necesidad de administración de clústeres de Kubernetes y la entrega de aplicaciones. Para esto es necesario usar #Git, la herramienta numero 1 de #desarrollo. GitOps, se basada en usar Git como única fuente de verdad para aplicaciones e infraestructura declarativa, de esta manera, las herramientas de #GitOps como #ArgoCD (la cual pueden ver como funciona en este post) puede alertar sobre cualquier diferencia existente entre Git y lo que está configurado en K8s, y si hay una diferencia, los reconciliadores de Kubernetes actualizan o revierten automáticamente la configuración. El objetivo por cierto es acelerar y simplificar las implementaciones de aplicaciones como las tareas de operaciones en Kubernetes.

¿GitOps es un reemplazo de DevOps?

Nos suelen hacer esta pregunta cuando hablamos de DevOps. Y la respuesta es: NO!

DevOps es una practica que tiene en cuenta factores culturales, de procesos y de tecnología. En DevOps, la cultura es parte fundamental para asegurarse de que las personas se alineen y trabajen de forma fluida. Pero GitOps incluye aquellas mejores prácticas que unifican la implementación, la gestión y la supervisión de aplicaciones, y la administración de clústeres de #containers.

GitOps por tanto, es un complemento de DevOps, con mayor orientación al desarrollo Cloud Native, Container First, o Serverless.

Además del repositorio de codigo, GitOps hace uso de herramientas de IaC (infrastructure as code) con el fin de administrar los despliegues de infraestructura con un control de versionado de la misma. Herramientas como #Puppet, #Ansible o #Terraform, permiten desplegar servidores y orquestar su implementación, pero el crecimiento exponencial del uso de contenedores junto al despliegue de las aplicaciones que corren sobre ellos potenció la necesidad de contar con herramientas que además de la infra puedan orquestar el despliegue aplicativo.

De esta manera, “recetas” de despliegue de infraestructura pueden ser respaldadas en Git para que sus archivos de configuración puedan ser “mergeados” con flujos de trabajo GitOps. Esto genera una super receta que al ejecutarse permitirá desplegar un servidor junto con su aplicación, con un control exacto de versiones.

¿Cuál son sus beneficios?

El principal es el de simplificar las administraciones de las implementaciones. La configuración de las aplicaciones y sus entornos de implementación son realizadas de manera declarativas (yaml/json).

Existe un control de versiones tanto de la infra como de las apps. Cualquier desviación de la configuración de versión es detectada y corregida de inmediato.

Todos los despliegues permiten una rápida vuelta atrás, además de dejar un registro de auditoria de sus ejecuciones.

Las implementaciones de aplicaciones son rápidas y confiables.

[popup_anything id=”2076″]

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

Visual Studio 2019
Docker Desktop
Azure DevOps
#Docker Hub
#Helm
#Kubernetes
#Argo CD
#Rancher
#KongHQ

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.