Implementación multinube para GitOps con GitLab: una demostración
Cómo la compatibilidad multinube admite los flujos de trabajo de GitOps: Esta demostración muestra cómo implementar aplicaciones en tres servidores Kubernetes con un flujo de trabajo común.
Los flujos de trabajo de GitOps utilizan un repositorio de Git como una fuente única de la verdad para permitir la colaboración, reuniendo a los equipos de infraestructura para acelerar el desarrollo y la entrega de software. Cuando los equipos de operaciones usan flujos de trabajo de GitOps, existen ventajas que van más allá del control de versiones al usar GitLab como repositorio principal. Los equipos utilizan GitLab por su plataforma de colaboración, la facilidad de las implementaciones de infraestructura y la compatibilidad multinube.
Esta demostración muestra cómo implementar aplicaciones en tres servidores Kubernetes con un flujo de trabajo común. Los equipos aprenderán cómo implementar aplicaciones con éxito a través de Auto DevOps, con tecnología de GitLab CI, con Helm y Kubernetes.
El primer paso es abrir el archivo del grupo gitops-demo README.md, que muestra la estructura del grupo gitops-demo. Verá algunos proyectos y dos subgrupos: infraestructura y aplicaciones.
Hay cuatro aplicaciones para esta demostración: my-asp-net-app1, my-spring-app2, my-ruby-app3 y my-python-app4. Además, hay tres clústeres de Kubernetes, cada uno de los cuales corresponde a un entorno de nube diferente: Microsoft Azure (AKS), Amazon (EKS) y Google Cloud (GKE).
Al hacer clic en el botón de Kubernetes en la esquina izquierda, se revela que todos los clústeres están registrados en GitLab. Los alcances ambientales representan qué aplicación se implementa en cada nube.
AutoDevOps en el trabajo
El primer ejemplo es una aplicación ASP.NET, que es el equivalente a una aplicación Hello, World. Hay algunas modificaciones que son específicas sobre cómo se implementa esta aplicación, que se encuentra en el archivo CI de la aplicación.
El primer paso es importar la plantilla principal de Auto DevOps configurando un par de variables. Luego, es importante reemplazar algunos comandos para las etapas que son más aplicables al código .net y, por último, configurar el entorno automáticamente para implementar la producción en AKS.
include:
- template: Auto-DevOps.gitlab-ci.yml
variables:
DEPENDENCY_SCANNING_DISABLED: "true"
test:
stage: test
image: microsoft/dotnet:latest
script:
- 'dotnet test --no-restore'
license_management:
stage: test
before_script:
- sudo apt-get update
- sudo apt-get install -y dotnet-runtime-2.2 dotnet-sdk-2.2
production:
environment:
name: aks/production
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
El pipeline se ejecutará automáticamente y se implementará con éxito. Al visualizar el pipeline, es posible ver cómo funciona la implementación.
Las etapas del pipeline desde la compilación hasta la producción para la aplicación ASP.NET.
Un vistazo rápido dentro del pipeline muestra que todos los jobs se aprobaron con éxito. La funcionalidad de Auto DevOps inició la etapa de compilación, que crea un contenedor de Docker y lo carga en el registro de Docker incorporado. La fase de prueba es completa e incluye análisis de contenedores, gestión de licencias, SAST y pruebas unitarias. Para profundizar en los resultados de las pruebas, haga clic en las pestañas de seguridad y licencia. La aplicación se implementa en producción en la etapa final del pipeline.
Dentro del clúster de AKS
La aplicación ASP.NET se está implementando en el clúster de AKS. Vaya a Operaciones > Entornos para ver el entorno configurado para esta aplicación. Las métricas como las tasas de errores de HTTP, las tasas de latencia y el rendimiento están disponibles, porque Prometheus ya está integrado en los clústeres de Kubernetes de GitLab.
El entorno se puede iniciar directamente mediante un clic en la URL en vivo para ver la aplicación ejecutándose en AKS. No hay mucho código adicional más allá del que ya se configuró en GitLab que le diga a la aplicación cómo implementar. La funcionalidad de Auto DevOps crea un gráfico Helm y lo implementa en Kubernetes y AKS.
En la demostración, aprenderá cómo configurar la aplicación Spring de manera similar a la aplicación ASP.NET mediante un Dockerfile. El Dockerfile se coloca en el directorio raíz del repositorio.
ROM maven:3-jdk-8-alpine
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN mvn package
ENV PORT 5000
EXPOSE $PORT
CMD [ "sh", "-c", "mvn -Dserver.port= spring-boot:${PORT} run" ]
La implementación de la aplicación Spring tiene una diferencia con respecto a la aplicación ASP.NET: no necesita ninguna anulación de la plantilla de AutoDevOps, ya que utiliza la plantilla predeterminada, y se implementa en GKE en lugar de AKS. El flujo de trabajo para la implementación de la aplicación es idéntico independientemente de la nube en la que se implemente la aplicación. Esto hace que la multinube sea fácil.
Es importante producir una compilación, prueba y producción similares en este entorno. Al dar este paso, los equipos pueden obtener las mismas métricas, tasas de error, latencias y rendimientos. En este caso, la aplicación se ejecuta automáticamente en un contenedor en Kubernetes en el clúster de GKE.
El último ejemplo es una aplicación de Python que se implementa en EKS. Los componentes son similares a los ejemplos anteriores y usan gitlab-ci.yml para cambiar el entorno de producción a EKS, así como un Dockerfile para preparar el gráfico Helm. También hay algunas anulaciones.
``yaml
include:
- template: Auto-DevOps.gitlab-ci.yml
test:
image: python:3.7
script:- pip install -r requirements.txt
- pip install pylint
- pylint main.py
production:
environment:
name: eks/production
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
El archivo de CI de GitLab le indica a la aplicación que se implemente en EKS.
{: .note.text-center}
```docker
FROM python:3.7
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/main.py"
El Dockerfile prepara el gráfico Helm.
Al igual que en los ejemplos anteriores, el pipeline funciona de la misma manera que en las otras aplicaciones con fases de compilación, prueba y producción. Una vez que la aplicación se implemente en EKS, puede abrir el enlace activo y ver la aplicación de Python en la ventana de su navegador.
GitLab es una verdadera solución multinube que permite a las empresas tomar decisiones sobre qué proveedor de nube desean usar, sin tener flujos de trabajo dispares ni abandonar las prácticas recomendadas de GitOps. Se trata de una interfaz coherente con el mismo flujo de trabajo, lo que facilita las implementaciones en cualquier nube principal con Kubernetes integrado con GitLab.
Una práctica recomendada de GitOps es hacer de un repositorio de Git la fuente única de la verdad para todo el código. Si bien cualquier repositorio de Git podría ser suficiente para tener un buen procedimiento de GitOps, hay pocas herramientas de DevOps que abarcan de verdad los pilares centrales de GitOps: colaboración, transparencia en el proceso y control de versiones.
Las herramientas como épicas, tickets y solicitudes de fusión, que son el quid de GitLab, fomentan la comunicación y transparencia entre los equipos. Los equipos de infraestructura pueden crear código utilizando Terraform o plantillas de Ansible en GitLab e implementarlo en la nube utilizando la CI de GitLab. GitLab es la verdadera solución multinube que permite a los equipos implementar una aplicación en cualquier servicio en la nube mediante la CI de GitLab y Kubernetes sin tener que aumentar significativamente sus flujos de trabajo.
¿Todo listo para comenzar?
Descubra lo que su equipo puede hacer con una plataforma de DevSecOps unificada.