Implantação multicloud para GitOps usando GitLab: uma demonstração

Os fluxos de trabalho GitOps usam um repositório Git como uma fonte única de verdade para facilitar a colaboração, unindo equipes de infraestrutura para acelerar o desenvolvimento e a entrega de software. Quando as equipes de operações usam os fluxos de trabalho GitOps, os benefícios vão além do controle de versão ao usar o GitLab como o repositório central. As equipes usam o GitLab devido à sua plataforma colaborativa, facilidade de implantação de infraestrutura e compatibilidade com multicloud.

Esta demonstração explica como implantar aplicações em três servidores Kubernetes usando um fluxo de trabalho comum. As equipes aprenderão a implantar com sucesso aplicações usando o Auto DevOps, com tecnologia de CI do GitLab, com Helm e Kubernetes.
A primeira etapa é abrir o arquivo README.md do grupo gitops-demo, que mostra a estrutura do grupo gitops-demo. Existem alguns projetos e dois subgrupos: infraestrutura e aplicações.

Há quatro aplicações para essa demonstração: my-asp-net-app1, my-spring-app2, my-ruby-app3, my-python-app4, e três clusters Kubernetes, cada um correspondendo a um ambiente de nuvem diferente: Microsoft Azure (AKS), Amazon (EKS) e Google Cloud (GKE).

Clicar no botão Kubernetes no canto esquerdo revela que todos os clusters estão registrados no GitLab. Os escopos ambientais representam qual aplicação é implantada em cada nuvem.

AutoDevOps em ação

O primeiro exemplo é uma aplicação ASP.NET, equivalente a um aplicativo "Hello, World". Existem algumas modificações específicas de como essa aplicação é implantada, que estão no arquivo CI da aplicação.

A primeira etapa é importar o modelo principal do Auto DevOps configurando algumas variáveis. Depois, é importante substituir alguns comandos para as etapas que são mais aplicáveis ao código .NET e, finalmente, configurar o ambiente automaticamente para implantar a produção no 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

O pipeline será executado automaticamente e implantado corretamente. Ao visualizar o pipeline, é possível conferir como a implantação funciona.
As etapas do pipeline abrangem da criação até a produção da aplicação ASP.NET.

Uma conferida rápida dentro do pipeline mostra que todos os jobs foram concluídos corretamente. O Auto DevOps iniciou a etapa de criação, que cria um contêiner Docker e o carrega no registro Docker integrado. A fase de teste é abrangente e inclui análise de contêineres, gerenciamento de licenças, SAST e testes unitários. Para explorar mais a fundo os resultados dos testes, clique nas guias de segurança e licença. A aplicação é implantada em produção na etapa final do pipeline.

Dentro do cluster AKS

A aplicação ASP.NET está sendo implantada no cluster AKS. Acesse Operações > Ambientes para visualizar o ambiente configurado para esta aplicação. Métricas como taxas de erro HTTP, latência e taxa de transferência estão disponíveis, pois o Prometheus já está integrado aos clusters Kubernetes do GitLab.

O ambiente pode ser lançado diretamente ao clicar no URL ativo para ver a aplicação rodando no AKS. Não há muito código adicional além do que já está configurado no GitLab para instruir como a aplicação deve ser implantada. O recurso Auto DevOps cria um gráfico Helm e o implanta no Kubernetes e no AKS.

Na demonstração, você aprenderá a configurar a aplicação Spring de maneira semelhante à aplicação ASP.NET, usando um Dockerfile. O Dockerfile é inserido no diretório raiz do repositório.

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=${PORT} spring-boot:run" ]

A implantação da aplicação Spring difere da aplicação ASP.NET de uma maneira: não precisa de nenhuma substituição no modelo do Auto DevOps, pois usa o modelo padrão, implantando no GKE em vez do AKS. O fluxo de trabalho para implantação de aplicações é idêntico, independentemente de em qual nuvem a aplicação está sendo implantada. Isso facilita o uso de multicloud.

É importante produzir uma criação, teste e execução de produção semelhantes neste ambiente. Ao executar essa etapa, as equipes podem obter as mesmas métricas, como taxas de erro, latências e produtividade. Nesse caso, a aplicação está rodando automaticamente em um contêiner no Kubernetes no cluster GKE.

O exemplo final é uma aplicação Python que é implantada no EKS. Os componentes são semelhantes aos exemplos anteriores e usam o gitlab-ci.yml para mudar o ambiente de produção para o EKS, além de um Dockerfile para preparar o Helm Chart. Há também algumas substituições.

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

O arquivo de CI do GitLab informa à aplicação que ela deve ser implantada no EKS.

FROM python:3.7
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "/app/main.py"

O Dockerfile prepara o Helm Chart.

Assim como nos exemplos anteriores, o pipeline é executado da mesma forma que nas outras aplicações, com as fases de criação, teste e produção. Quando a aplicação for implantada no EKS, você poderá abrir o link ativo e acessar a aplicação Python na janela do seu navegador.

O GitLab é uma solução verdadeira de multicloud que permite que as empresas tomem decisões sobre qual provedor de nuvem desejam usar, sem fluxos de trabalho diferentes, mantendo boas práticas de GitOps. Tudo isso com uma interface uniforme e o mesmo fluxo de trabalho, facilitando a implantação em qualquer grande nuvem que execute Kubernetes integrado ao GitLab.

Uma boa prática de GitOps envolve fazer de um repositório Git a fonte única de verdade para todo o código. Embora qualquer repositório Git possa servir para uma boa prática de GitOps, há poucas ferramentas de DevOps que realmente abrangem os pilares fundamentais do GitOps: colaboração, transparência no processo e controle de versão.

Ferramentas como épicos, tíquetes e solicitações de merge, que são fundamentais no GitLab, promovem comunicação e transparência entre equipes. As equipes de infraestrutura podem criar código usando os modelos do Ansible ou Terraform no GitLab e implantar na nuvem usando a CI do GitLab. O GitLab é a verdadeira solução multicloud, permitindo que as equipes implantem uma aplicação em qualquer serviço de nuvem usando a CI do GitLab e o Kubernetes sem ter que aumentar significativamente seus fluxos de trabalho.

• O que é GitOps
• Saiba como o GitLab fortalece os fluxos de trabalho GitOps
• Entenda o futuro do GitOps com líderes do setor
• Baixe o guia para iniciantes em GitOps