Saltar para o conteúdo principal
Versão Next

Instalação via Argo CD (GitOps)

Esta secção descreve o processo de instalação dos componentes do TDP Kubernetes utilizando o Argo CD como ferramenta de GitOps.

dica

Antes de iniciar a instalação via Argo CD, certifique-se de que os pré-requisitos foram cumpridos e que o Argo CD já esteja instalado no cluster.
Caso ainda não tenha instalado o Argo CD, consulte os passos 1 e 2 da instalação via Helm.

Visão Geral​

O Argo CD é uma ferramenta de entrega contínua (CD) baseada no modelo GitOps.
Neste modelo, o utilizador descreve a infraestrutura que deseja ter — quais componentes, em qual versão, com quais configurações — em ficheiros YAML chamados manifests, e os armazena em um repositório Git.
O Argo CD monitora esse repositório e garante que o cluster Kubernetes sempre reflita o que está declarado nesses ficheiros.

Diferença entre a instalação com o Argo CD e Helm​

CritérioHelm CLIArgo CD (GitOps)
RastreabilidadeComandos manuais, sem histórico automáticoCada mudança fica registada no Git
AutomaçãoExecução manual de cada chartSincronização automática contínua
RollbackRequer reexecução de comandosUm clique ou um comando
VisibilidadeSomente via terminalInterface web com status em tempo real
AuditoriaDifícilCompleta, via histórico do Git

Conceitos essenciais para instalação com o Argo CD​

Antes de começar, é importante entender os conceitos centrais desta instalação:

Manifest : Um ficheiro YAML que descreve um recurso Kubernetes ou Argo CD.
Neste contexto, cada manifest define uma Application do Argo CD — ou seja, instrui o Argo CD a instalar um determinado chart Helm.
Os ficheiros são criados com base nos modelos fornecidos nesta documentação e armazenados no repositório Git indicado.

Application : O objeto central do Argo CD.
Uma Application orienta o Argo CD no sentido de obter um determinado chart Helm do Registry e instalá-lo em um determinado namespace do cluster.
Cada componente do TDP (Kafka, Airflow, Trino, etc.) é representado por uma Application separada.

Repositório : É a origem dos artefatos que o Argo CD irá utilizar.
Pode ser um repositório Git (onde ficam os seus manifests) ou um registry OCI1 (onde ficam os Helm Charts da Tecnisys).
Ambos precisam de ser registados no Argo CD antes de criar as Applications.

Sincronização : O processo pelo qual o Argo CD compara o estado declarado nos manifests com o estado real do cluster.
Se houver diferença, o Argo CD aplica as mudanças necessárias — automaticamente (se configurado) ou mediante comando manual.

App of Apps : Um padrão que permite gerir todos os componentes com uma única Application raiz.
Em vez de aplicar vários manifests um a um, permite a aplicação de um único ficheiro que instrui o Argo CD a descobrir e instalar todos os demais automaticamente.

Ordem de Instalação​

A instalação dos componentes deve seguir uma ordem específica para garantir que as dependências sejam atendidas:

OrdemChartComponenteVersãoDependências
1tdp-postgresqlPostgreSQL17.5.0Nenhuma
2tdp-kafkaKafka (Strimzi)4.1.0Nenhuma
3tdp-hive-metastoreHive Metastore4.0.0Nenhuma
4tdp-deltalakeDelta Lake4.0.0Nenhuma
5tdp-icebergIceberg1.10.0Nenhuma
6tdp-ozoneApache Ozone2.0.0Nenhuma
7tdp-rangerRanger2.7.0tdp-postgresql
8tdp-nifiNiFi1.28.0Nenhuma
9tdp-sparkSpark4.0.0Nenhuma
10tdp-trinoTrino478Nenhuma
11tdp-airflowAirflow3.0.2tdp-postgresql
12tdp-jupyterJupyterLab5.3.0Nenhuma
13tdp-clickhouseClickHouse25.8.11.66Nenhuma
14tdp-cloudbeaverCloudBeaver25.2.3tdp-postgresql
15tdp-openmetadataOpenMetadata1.9.11tdp-postgresql
16tdp-supersetSuperset5.0.0tdp-postgresql

A coluna Versão refere-se à versão do componente (ex.: Kafka 4.1.0, Airflow 3.0.2). A versão do chart Helm é 3.0.0 para todos os charts TDP.

nota

O Argo CD (incluindo os CRDs necessários) é pré-requisito deste procedimento: o cluster já deve ter o Argo CD operacional (veja a instalação via Helm).
Os charts tdp-argo-crds e tdp-argo não entram na sequência, pois não são instalados por este fluxo GitOps.

aviso

O tdp-postgresql é uma dependência e deve estar operacional antes dos componentes que o utilizam, como: Airflow, OpenMetadata, Ranger, Superset e CloudBeaver.
Ao usar o padrão App of Apps, o Argo CD tenta criar todos ao mesmo tempo; esses componentes podem apresentar falhas temporárias até que o PostgreSQL esteja pronto — o selfHeal2 os reconciliará automaticamente.

Passo 1 – Ligação do registry OCI ao Argo CD​

O primeiro passo é informar ao Argo CD onde estão os Helm Charts do TDP.
Os charts ficam no registry OCI privado da Tecnisys (registry.tecnisys.com.br).
Para que o Argo CD consiga obtê-los, é necessário registar esse endereço como um repositório Helm com suporte a OCI.
Esse registo não instala nada — apenas permite ao Argo CD aceder ao registry como fonte de artefatos.
As credenciais de acesso devem ser obtidas junto à Tecnisys.

1. Aceda à interface do Argo CD no navegador. O endereço depende da forma de exposição HTTP configurada no seu ambiente. Se o ambiente utilizar Ingress, descubra o host com:

Terminal input
kubectl get ingress -n argocd

Exemplo de resultado:

NAME                CLASS   HOSTS                      PORTS
tdp-argocd-server   nginx   argocd.<cluster-domain>    80
Figura 1 - Descobrir o host exposto - get ingress
Figura 1 - Descobrir o host exposto - get ingress

Abra https://argocd.<cluster-domain> no navegador.

Figura 2 - Acesso ao Argo CD
Figura 2 - Acesso ao Argo CD
Gateway API

Se o ambiente utilizar Gateway API em vez de Ingress, descubra o host exposto com:

Terminal input
kubectl get httproute -n argocd

Consulte Ingress vs Gateway API para mais detalhes sobre as duas abordagens suportadas.

2. No menu lateral, aceda a Settings → Repositories.

3. Clique em Connect Repo e preencha os campos:

CampoValor
Repository TypeHelm
Repository URLregistry.tecnisys.com.br
Enable OCItrue (marcar o checkbox)
Username<usuario>
Password<palavra-passe>

4. Clique em Connect.
O repositório deve aparecer na lista com status de ligação bem-sucedida.

Figura 3 - Repo Connect
Figura 3 - Repo Connect

Passo 2 – Criação do Repositório GitOps​

É necessária a criação de um repositório Git para armazenar os manifests das Applications.
Esse repositório é o ponto de verdade do seu ambiente: o Argo CD o monitora continuamente e aplica qualquer alteração que for enviada para ele.

nota

Deve criar este repositório Git na sua plataforma de preferência (GitHub, GitLab, Gitea, etc.) e dar ao Argo CD acesso de leitura a ele.
O repositório pode ser privado — nesse caso, registe-o também no Argo CD via Settings → Repositories, da mesma forma que fez com o registry OCI, mas selecionando o tipo Git e fornecendo as credenciais de acesso.

Estrutura recomendada​

Crie o repositório com a seguinte organização de pastas e ficheiros:

tdp-gitops/
├── app-of-apps.yaml               # Application raiz — aplique este ficheiro para iniciar tudo
├── apps/                          # Um manifest por componente TDP
│   ├── tdp-postgresql.yaml
│   ├── tdp-kafka.yaml
│   ├── tdp-hive-metastore.yaml
│   ├── tdp-deltalake.yaml
│   ├── tdp-iceberg.yaml
│   ├── tdp-ozone.yaml
│   ├── tdp-ranger.yaml
│   ├── tdp-nifi.yaml
│   ├── tdp-spark.yaml
│   ├── tdp-trino.yaml
│   ├── tdp-airflow.yaml
│   ├── tdp-jupyter.yaml
│   ├── tdp-clickhouse.yaml
│   ├── tdp-cloudbeaver.yaml
│   ├── tdp-openmetadata.yaml
│   └── tdp-superset.yaml
└── values/                        # Configurações personalizadas por componente (opcional)
    ├── tdp-postgresql-values.yaml
    ├── tdp-kafka-values.yaml
    └── ...
nota

O que o utilizador cria: os ficheiros YAML em apps/ (os manifests das Applications) e o app-of-apps.yaml.
Os modelos estão fornecidos no Passo 3.

Os ficheiros values/ são opcionais e permitem personalizar a instalação de cada componente — por exemplo, definir senhas, limites de recursos ou parâmetros específicos.
Se não existirem, cada componente usará os valores padrão do chart.

Os Helm Charts em si são fornecidos pela Tecnisys no registry OCI.
Você não precisa criar nem modificar os charts.

Passo 3 – Criação dos Manifests das Applications​

Cada componente do TDP Kubernetes é representado por um ficheiro YAML que define uma Application do Argo CD.
Copie os modelos abaixo para os ficheiros correspondentes em apps/ do seu repositório, substituindo <namespace> pelo namespace que escolheu para o seu ambiente (ex.: tdp-producao, tdp-dev, meu-namespace).

Entender o Manifest​

Antes de copiar os modelos, entenda o que cada campo significa:

CampoO que define
metadata.nameNome da Application no Argo CD (deve ser único)
metadata.namespaceNamespace onde o Argo CD está instalado — normalmente argocd
spec.source.repoURLEndereço do registry OCI onde o chart está armazenado
spec.source.chartNome do chart Helm a ser instalado
spec.source.targetRevisionVersão do chart — use 3.0.0 para todos os charts TDP
spec.source.helm.valueFilesFicheiros de personalização (opcional; criados pelo utilizador em values/)
spec.destination.serverCluster de destino — use https://kubernetes.default.svc para o cluster local
spec.destination.namespaceNamespace onde o componente será instalado
syncPolicy.automated.pruneSe true, remove do cluster recursos que foram removidos do manifest
syncPolicy.automated.selfHealSe true, reverte alterações manuais feitas diretamente no cluster
syncOptions.CreateNamespaceCria o namespace automaticamente se ainda não existir
Figura 4 - Criação do Manifest - exemplo para PostgreSQL
Figura 4 - Criação do Manifest - exemplo para PostgreSQL

1. PostgreSQL​

O PostgreSQL é o banco de dados relacional utilizado como dependência por vários componentes da plataforma: Airflow (metadados dos DAGs e histórico de execuções), OpenMetadata (catálogo de dados), Ranger (políticas de segurança), Superset (metadados dos dashboards) e CloudBeaver (configurações). Deve estar operacional antes desses componentes.

apps/tdp-postgresql.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-postgresql
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-postgresql
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

2. Kafka (Strimzi)​

O Apache Kafka é a plataforma de mensagens e de streaming de eventos da plataforma. É gerido pelo operador Strimzi, que automatiza a criação, o escalonamento e a recuperação dos brokers e tópicos Kafka no Kubernetes.

apps/tdp-kafka.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-kafka
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-kafka
    targetRevision: 3.0.0
    helm:
      valueFiles:
        - values.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

3. Hive Metastore​

O Hive Metastore é o serviço de catálogo de metadados de tabelas. Armazena o esquema (colunas, tipos, partições) das tabelas geridas pela plataforma, sendo utilizado pelo Spark e pelo Trino para descobrir e aceder aos dados.

apps/tdp-hive-metastore.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-hive-metastore
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-hive-metastore
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

4. Delta Lake​

O Delta Lake é uma camada de armazenamento open source que adiciona transações ACID, versionamento e controle de esquema ao armazenamento de objetos. Permite operações confiáveis de leitura e escrita em grande escala.

apps/tdp-deltalake.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-deltalake
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-deltalake
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

5. Iceberg​

O Apache Iceberg é um formato de tabela open source de alto desempenho para grandes volumes de dados analíticos. Oferece evolução de esquema, particionamento oculto e viagem no tempo (time travel), sendo amplamente compatível com motores de consulta como Trino e Spark.

apps/tdp-iceberg.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-iceberg
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-iceberg
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

6. Apache Ozone​

O Apache Ozone é um sistema de armazenamento de objetos distribuído, compatível com a API S3. Em ambientes on-premise, atua como alternativa ao Amazon S3 ou MinIO, sendo o armazenamento primário de dados da plataforma.

apps/tdp-ozone.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-ozone
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-ozone
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

7. Ranger​

O Apache Ranger é o componente de segurança e governança de acesso. Centraliza as políticas de autorização para todos os serviços da plataforma — quem pode aceder a quais dados, em quais tabelas ou tópicos — e regista o histórico de acessos para auditoria. Depende do PostgreSQL.

apps/tdp-ranger.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-ranger
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-ranger
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

8. NiFi​

O Apache NiFi é a ferramenta de ingestão e roteamento de dados. Por meio de uma interface visual, permite criar fluxos de dados (pipelines) que movem, transformam e integram dados entre fontes externas e a plataforma.

apps/tdp-nifi.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-nifi
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-nifi
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

9. Spark​

O Apache Spark é o motor de processamento distribuído da plataforma. Utilizado para processamento em lote (batch), transformações de dados em larga escala e pipelines de machine learning.

apps/tdp-spark.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-spark
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-spark
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

10. Trino​

O Trino é o motor de consulta SQL distribuída. Permite executar consultas SQL analíticas diretamente sobre os dados armazenados no Ozone/S3, Delta Lake ou Iceberg, sem a necessidade de mover os dados para outro sistema.

apps/tdp-trino.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-trino
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-trino
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

11. Airflow​

O Apache Airflow é a ferramenta de orquestração de pipelines de dados. Permite criar, agendar e monitorar workflows (DAGs — Directed Acyclic Graphs) que coordenam a execução de tarefas de ingestão, transformação e carga de dados. Depende do PostgreSQL.

apps/tdp-airflow.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-airflow
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-airflow
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

12. JupyterHub​

O JupyterHub é o servidor multi-utilizador de notebooks. Permite que analistas e cientistas de dados executem notebooks Jupyter diretamente no cluster, com acesso aos dados e à capacidade computacional da plataforma.

apps/tdp-jupyter.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-jupyter
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-jupyter
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

13. ClickHouse​

O ClickHouse é o banco de dados analítico OLAP (Online Analytical Processing) da plataforma. Otimizado para consultas analíticas de alta velocidade sobre grandes volumes de dados, é ideal para dashboards e relatórios em tempo real.

apps/tdp-clickhouse.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-clickhouse
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-clickhouse
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

14. CloudBeaver​

O CloudBeaver é a interface web de administração de bancos de dados. Permite conectar-se a diferentes bancos de dados (PostgreSQL, ClickHouse, etc.) e executar queries diretamente no navegador. Depende do PostgreSQL.

apps/tdp-cloudbeaver.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-cloudbeaver
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-cloudbeaver
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

15. OpenMetadata​

O OpenMetadata é o catálogo de dados e plataforma de governança da plataforma. Permite descobrir, documentar e gerir todos os ativos de dados — tabelas, pipelines, dashboards — com linhagem automática e controle de qualidade. Depende do PostgreSQL.

apps/tdp-openmetadata.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-openmetadata
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-openmetadata
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

16. Superset​

O Apache Superset é a ferramenta de visualização e BI (Business Intelligence) da plataforma. Permite criar dashboards interativos e gráficos conectados ao ClickHouse, Trino e outros bancos de dados da plataforma. Depende do PostgreSQL.

apps/tdp-superset.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-superset
  namespace: argocd
spec:
  project: default
  source:
    repoURL: oci://registry.tecnisys.com.br/tdp
    chart: tdp-superset
    targetRevision: 3.0.0
  destination:
    server: https://kubernetes.default.svc
    namespace: <namespace>
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Passo 4 – Criação do Manifest App of Apps​

O padrão App of Apps permite iniciar toda a instalação com um único comando.
Em vez de aplicar os vários manifests um a um, é possível criar uma Application raiz (app-of-apps.yaml) que aponta para a pasta apps/ do seu repositório Git.
O Argo CD lê essa pasta, descobre todos os manifests e cria automaticamente todas as Applications definidas ali.

Crie o ficheiro app-of-apps.yaml na raiz do seu repositório.
Substitua a URL de repoURL pela URL do seu repositório Git (onde armazenou os ficheiros do Passo 3):

app-of-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: tdp-stack
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.seu-servidor.com.br/seu-usuario/tdp-gitops.git
    targetRevision: main
    path: apps
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
nota

O campo spec.source.repoURL deve apontar para o repositório Git que criou no Passo 2, onde estão os manifests das Applications. Se o repositório for privado, registe-o previamente no Argo CD via Settings → Repositories.

Figura 5 - Criação do Manifest app-of-apps - exemplo
Figura 5 - Criação do Manifest app-of-apps - exemplo

Passo 5 – Aplicação do App of Apps​

Com o repositório GitOps criado e os manifests prontos, aplique a Application raiz para iniciar a instalação de todos os componentes.

  1. Faça o clone do repositório Git no seu terminal local
Terminal input
git clone https://git.seu-servidor.com.br/seu-usuario/tdp-gitops.git
Figura 6 - Git Clone - exemplo
Figura 6 - Git Clone - exemplo
  1. Aplique o ficheiro:
Terminal input
cd tdp-gitops
kubectl apply -f app-of-apps.yaml
Figura 7 - Aplicando o ficheiro - exemplo
Figura 7 - Aplicando o ficheiro - exemplo

A partir desse momento, o Argo CD descobrirá todos os manifests em apps/ e iniciará a instalação de todos os componentes do TDP Kubernetes.

Acompanhar o Progresso​

Terminal input
argocd app list
Figura 8 - app list
Figura 8 - app list

Políticas de sincronização​

Os manifests nesta documentação utilizam syncPolicy.automated — o Argo CD sincroniza automaticamente sempre que detecta diferenças.
Os dois parâmetros de controle são:

ParâmetroEfeito quando true
pruneRemove do cluster recursos que foram removidos do manifest no Git
selfHealReverte no cluster alterações feitas manualmente (fora do Git)

Para ambientes que exigem maior controle, remova o bloco automated do manifest.
Nesse caso, a sincronização deve ser iniciada manualmente:

Terminal input
argocd app sync tdp-postgresql
Figura 9 - app sync
Figura 9 - app sync

Footnotes​

  1. OCI (Open Container Initiative) é o padrão moderno para armazenar não apenas imagens de contêiner, mas também pacotes Helm. Por isso, ao registar o registry, é necessário marcar a opção Enable OCI — sem ela, o Argo CD tentará tratar o endereço como um repositório Helm convencional baseado em index.yaml e a ligação falhará. ↩

  2. Reconciliação automatica com o Git ↩