1. Implemente o GitOps com o Argo CD e o OCI Kubernetes Engine
  2. Implemente o GitOps com o Argo CD e o OCI Kubernetes Engine

Implemente o GitOps com o Argo CD e o OCI Kubernetes Engine

Este artigo descreve a arquitetura básica subjacente à implantação do GitOps com o Argo CD e o Oracle Cloud Infrastructure Kubernetes Engine.

GitOps é um tipo de CI/CD que usa repositórios Git como uma única fonte confiável para fornecer infraestrutura como código. Ele defende colocar a totalidade do aplicativo, a partir do código-fonte e da configuração do aplicativo, declarativamente em repositórios Git. Isso fornece uma maneira consistente de implantar alterações na configuração de um aplicativo e fornece controle de versão usando fluxos de trabalho Git bem conhecidos, como solicitações de extração e de mesclagem.

O uso dos princípios GitOps garante:
  • Um workflow padrão para desenvolvimento de aplicativos.
  • Maior segurança para definir os requisitos do aplicativo antecipadamente.
  • Maior confiabilidade com visibilidade e controle de versão por meio do Git.
  • Consistência em qualquer cluster, qualquer nuvem e qualquer ambiente local.
O Argo CD é uma ferramenta de entrega contínua declarativa criada especificamente para Kubernetes. Com o Argo CD, as configurações do Kubernetes são criadas uniformemente, por meio de alterações nos repositórios do Github. Isso permite que os repositórios Git sejam a única fonte confiável para todas as configurações de aplicativos entregues em um cluster do Kubernetes. O Argo CD usa um modelo pull, que verifica se há alterações nos repositórios Git, independentemente da origem da alteração. Essas alterações podem ser de um pipeline de CI ou podem ser uma configuração manual de um desenvolvedor ou administrador. Isso permite a separação do pipeline CI/CD. Uma vez que CI é para a construção de código, é mais adequado para ser mantido pelos desenvolvedores, enquanto CD é a preocupação da equipe Ops. A separação entre os dois permite que cada equipe faça modificações no pipeline CI/CD, independentemente um do outro.

É prática recomendada ter repositórios Git separados para código e configuração de origem do aplicativo, pois as alterações de configuração geralmente não exigem alterações no código de origem do aplicativo. Ter repositórios diferentes permite alterar a configuração do aplicativo sem acionar um build de CI.

O Argo CD suporta configurações do Kubernetes nestes formatos:
  • Manifestos do Kubernetes
  • Gráficos de Helm
  • Kustomize manifesta-se.
Para aplicativos gerenciados pelo Argo CD, a configuração do estado ativo do aplicativo é monitorada continuamente. Ele é comparado com o estado desejado especificado no repositório Git. Se o estado ativo se desviar do estado desejado, o CD do Argo identificará os aplicativos como OutOfSync e, em seguida, extrairá a configuração do repositório Git e aplicará as alterações.

Arquitetura

Essa arquitetura mostra um cluster do OCI Kubernetes Engine com a ferramenta de CD Argo implantada em seu próprio namespace.

Você pode acessar o aplicativo Argo CD por meio de sua interface web ou da interface de linha de comando Argo CD. A conectividade com a ferramenta de CD Argo é fornecida por um serviço de balanceador de carga implantado no cluster do OCI Kubernetes Engine. Depois que o CD do Argo for implantado, você o configurará para sincronizar com repositórios Git hospedados interna ou externamente com o Oracle Cloud Infrastructure, desde que o cluster do OCI Kubernetes Engine tenha conectividade IP nas portas necessárias e nas credenciais dos repositórios Git. Depois que o CD do Argo tiver sincronizado com os repositórios, quaisquer atualizações na configuração do aplicativo feitas no repositório serão aplicadas ao cluster do OCI Kubernetes Engine. Se forem feitas alterações no aplicativo fora do repositório do Git, o Argo CD considerará o aplicativo fora de sincronia e reverterá as alterações para que esteja de acordo com o estado desejado do repositório do Git.

O diagrama a seguir ilustra essa arquitetura de referência.

Veja a seguir a descrição da argocd.png
Descrição da ilustração argocd.png

argocd-oracle.zip

Esta arquitetura inclui os seguintes componentes:
  • Tenancy

    O Oracle Autonomous Transaction Processing é um banco de dados independente, com autoproteção e autorreparo otimizado para cargas de trabalho de processamento de transações. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. O Oracle Cloud Infrastructure lida com a criação do banco de dados, bem como com o backup, a aplicação de patches, o upgrade e o ajuste dele.

  • Região

    Região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, denominada domínios de disponibilidade. As regiões são independentes de outras regiões, e grandes distâncias podem separá-las (entre países ou até mesmo continentes).

  • Compartimento

    Os compartimentos são partições lógicas entre regiões em uma tenancy do Oracle Cloud Infrastructure. Use compartimentos para organizar seus recursos no Oracle Cloud, controlar o acesso aos recursos e definir metas de uso. Para controlar o acesso aos recursos em um determinado compartimento, você define políticas que especificam quem pode acessar os recursos e quais ações eles podem executar.

  • Domínios de disponibilidade

    Domínios de disponibilidade são data centers stand-alone e independentes dentro de uma região. Os recursos físicos de cada domínio de disponibilidade são isolados dos recursos de outros domínios de disponibilidade, o que oferece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura como energia ou refrigeração ou a rede interna do domínio de disponibilidade. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.

  • Domínios de falha

    Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falha no servidor físico, manutenção do sistema e falhas de energia dentro de um domínio de falha.

  • Rede virtual na nuvem (VCN) e sub-redes

    Uma VCN é uma rede personalizável definida por software que você configura em uma região do Oracle Cloud Infrastructure. Como as redes tradicionais de data center, as VCNs oferecem total controle sobre seu ambiente de rede. Uma VCN pode ter vários blocos CIDR não sobrepostos que você pode alterar após a criação da VCN. Você pode segmentar uma VCN em sub-redes, com escopo definido para uma região ou para um domínio de disponibilidade. Cada sub-rede consiste em um intervalo contíguo de endereços que não se sobrepõem a outras sub-redes da VCN. Você pode alterar o tamanho de uma sub-rede após a criação. Uma sub-rede pode ser pública ou privada.

  • Balanceador de carga

    O serviço Oracle Cloud Infrastructure Load Balancing fornece distribuição automatizada de tráfego de um único ponto de entrada para vários servidores no back-end. O balanceador de carga fornece acesso a diferentes aplicativos.

  • Repositório de Código do Código

    No serviço DevOps, você pode criar seus próprios repositórios de códigos privados ou estabelecer conexão com repositórios de códigos externos, como GitHub, GitLab e Bitbucket Cloud.

  • Lista de segurança

    Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que deve ser permitido dentro e fora da sub-rede.

  • Gateway NAT

    O gateway NAT permite que recursos privados em uma VCN acessem hosts na internet, sem expor esses recursos a conexões de internet de entrada.

  • Gateway de serviço

    O gateway de serviço fornece acesso de uma VCN a outros serviços, como o Oracle Cloud Infrastructure Object Storage. O tráfego da VCN para o serviço Oracle percorre a malha da rede Oracle e nunca atravessa a internet.

  • Cloud Guard

    Você pode usar o Oracle Cloud Guard para monitorar e manter a segurança de seus recursos no Oracle Cloud Infrastructure. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos quanto a pontos fracos de segurança e para monitorar operadores e usuários quanto a atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a tomar essas ações, com base nas receitas do respondedor que você pode definir.

  • Zona de segurança

    As zonas de segurança garantem as melhores práticas de segurança da Oracle desde o início, impondo políticas, como criptografar dados e impedir o acesso público a redes de um compartimento inteiro. Uma zona de segurança está associada a um compartimento com o mesmo nome e inclui políticas de zona de segurança ou uma "receita" que se aplica ao compartimento e seus subcompartimentos. Não é possível adicionar ou mover um compartimento padrão para um compartimento de zona de segurança.

  • Object Storage

    O armazenamento de objetos oferece acesso rápido a grandes quantidades de dados estruturados e não estruturados de qualquer tipo de conteúdo, incluindo backups de bancos de dados, dados de análise e conteúdo avançado, como imagens e vídeos. Você pode armazenar de forma segura e depois recuperar dados diretamente da internet ou de dentro da plataforma da nuvem. Você pode dimensionar facilmente o armazenamento sem prejudicar o desempenho ou a confiabilidade do serviço. Use o armazenamento padrão para armazenamento de acesso frequente que você precisa para acessar de forma rápida, imediata e com frequência. Use o armazenamento de arquivos compactados para armazenamento "frio" que você mantém por longos períodos de tempo e raramente acessa.

  • FastConnect

    O Oracle Cloud Infrastructure FastConnect fornece uma maneira fácil de criar uma conexão privada dedicada entre o seu data center e o Oracle Cloud Infrastructure. O FastConnect oferece opções de largura de banda maior e uma experiência de rede mais confiável quando comparado com conexões baseadas na internet.

  • LPG (Local peering gateway)

    Um LPG permite parear uma VCN com outra VCN na mesma região. Pareamento significa que as VCNs se comunicam usando endereços IP privados, sem o tráfego que passa pela internet ou que é roteado pela sua rede local.

  • Banco de dados autônomo

    Os bancos de dados autônomos do Oracle Cloud Infrastructure são ambientes de banco de dados totalmente gerenciados e pré-configurados que você pode usar para processamento de transações e cargas de trabalho de data warehousing. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. O Oracle Cloud Infrastructure lida com a criação do banco de dados, bem como com o backup, a aplicação de patches, o upgrade e o ajuste dele.

  • Autonomous Data Warehouse

    O Oracle Autonomous Data Warehouse é um serviço de banco de dados autônomo, de autoproteção e reparo otimizado para cargas de trabalho de data warehousing. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. O Oracle Cloud Infrastructure lida com a criação do banco de dados, bem como com o backup, a aplicação de patches, o upgrade e o ajuste dele.

  • Autonomous Transaction Processing

    O Oracle Autonomous Transaction Processing é um banco de dados independente, com autoproteção e autorreparo otimizado para cargas de trabalho de processamento de transações. Você não precisa configurar nem gerenciar nenhum hardware, nem instalar nenhum software. O Oracle Cloud Infrastructure lida com a criação do banco de dados, bem como com o backup, a aplicação de patches, o upgrade e o ajuste dele.

  • Sistema de BD Exadata

    O Exadata Cloud Service permite aproveitar o potencial do Exadata na nuvem. Você pode provisionar sistemas X8M flexíveis que permitem adicionar servidores de computação de banco de dados e servidores de armazenamento ao sistema à medida que suas necessidades aumentam. Os sistemas X8M oferecem rede RoCE (RDMA sobre Ethernet Convergente) para módulos de memória persistente (PMEM) de alta largura de banda e baixa latência e software Exadata inteligente. Você pode provisionar sistemas X8M usando uma forma equivalente a um sistema X8 de quarto de rack e, em seguida, adicionar servidores de banco de dados e de armazenamento a qualquer momento após o provisionamento.

Recomendações

Use as seguintes recomendações como ponto de partida ao implantar o GitOps com o Argo CD e o OCI Kubernetes Engine. Seus requisitos específicos podem ser diferentes da arquitetura descrita aqui.
  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Selecione blocos CIDR que não se sobreponham a nenhuma outra rede (no Oracle Cloud Infrastructure, no seu data center local ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.

    Depois de criar uma VCN, você poderá alterar, adicionar e remover seus blocos CIDR.

    Ao projetar as sub-redes, considere seus requisitos de fluxo de tráfego e segurança. Anexe todos os recursos dentro de uma camada ou atribuição específica à mesma sub-rede, que pode servir como um limite de segurança.

    Usar sub-redes regionais.

  • Segurança

    Use o Oracle Cloud Guard para monitorar e manter a segurança dos seus recursos no Oracle Cloud Infrastructure de modo proativo. O Cloud Guard usa receitas do detector que você pode definir para examinar seus recursos quanto a pontos fracos de segurança e para monitorar operadores e usuários quanto a atividades arriscadas. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e ajuda a tomar essas ações, com base nas receitas do respondedor que você pode definir.

    Para recursos que exigem segurança máxima, a Oracle recomenda o uso de zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita de políticas de segurança definida pela Oracle baseada nas melhores práticas. Por exemplo, os recursos de uma zona de segurança não devem ser acessíveis por meio da internet pública e devem ser criptografados usando chaves gerenciadas pelo cliente. Quando você criar e atualizar recursos em uma zona de segurança, o Oracle Cloud Infrastructure validará as operações de acordo com as políticas na receita de zona de segurança e negará as operações que violam qualquer uma das políticas.

  • Cloud Guard

    Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas de detector e respondedor. Essas receitas permitem que você especifique que tipo de violações de segurança geram um aviso e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública.

    Aplique o Cloud Guard no nível da tenancy para cobrir o escopo mais amplo e reduzir a carga administrativa de manutenção de várias configurações.

    Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.

  • Zonas de segurança

    Clone e personalize as receitas padrão fornecidas pela Oracle para criar receitas personalizadas de detector e respondedor. Essas receitas permitem que você especifique que tipo de violações de segurança geram um aviso e quais ações podem ser executadas nelas. Por exemplo, talvez você queira detectar buckets do Object Storage que tenham visibilidade definida como pública.

    Aplique o Cloud Guard no nível da tenancy para cobrir o escopo mais amplo e reduzir a carga administrativa de manutenção de várias configurações. Você também pode usar o recurso Lista Gerenciada para aplicar determinadas configurações aos detectores.

  • Grupos de segurança de rede (NSGs)

    Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança, porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo.

    Você pode usar NSGs para definir um conjunto de regras de entrada e saída que se aplicam a VNICs específicas. Recomendamos o uso de NSGs em vez de listas de segurança, porque os NSGs permitem que você separe a arquitetura de sub-rede da VCN dos requisitos de segurança do seu aplicativo.

  • Largura de banda do balanceador de carga

    Ao criar o balanceador de carga, você pode selecionar uma forma predefinida que forneça uma largura de banda fixa ou especificar uma forma personalizada (flexível), na qual você define uma faixa de largura de banda e permite que o serviço dimensione a largura de banda automaticamente com base nos padrões de tráfego. Com qualquer uma das abordagens, você pode alterar a forma a qualquer momento após criar o balanceador de carga.

Implante

O código do Terraform para essa arquitetura de referência está disponível como uma pilha de amostra no Oracle Cloud Infrastructure Resource Manager. Esta amostra de pilha do Terraform implanta um ambiente de aplicativo do OCI Data Flow, juntamente com políticas do IAM e buckets do OCI Object Storage (não armazenamento de terceiros). Por padrão, um aplicativo Python Spark de demonstração também será implantado. Você também pode fazer download do código em GitHub e personalizá-lo para atender às suas necessidades específicas.

  • Implante usando a pilha de amostra no Oracle Cloud Infrastructure Resource Manager:
    1. Clique Implantar para o Oracle Cloud.

      Se você ainda não tiver acessado, informe a tenancy e as credenciais do usuário.

    2. Selecione a região na qual você deseja implantar a pilha.
    3. Siga os prompts na tela e as instruções para criar a pilha.
    4. Após criar a pilha, clique em Ações do Terraform e selecione Planejar.
    5. Aguarde a conclusão do job e revise o plano.

      Para fazer qualquer alteração, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação Planejar novamente.

    6. Se nenhuma alteração adicional for necessária, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
  • Implante usando o código do Terraform em GitHub:
    1. Vá para GitHub.
    2. Clone ou faça download do repositório para seu computador local.
    3. Siga as instruções no documento README.

Além do código do Terraform fornecido em GitHub, os trechos de código abaixo ilustram como estabelecer conexão com o Amazon Web Services S3 e como consultar os dados.

  • Para estabelecer conexão e consultar dados de S3, você precisa incluir os pacotes hadoop-aws.jar e aws-java-sdk.jar. Você pode fazer referência a esses pacotes no arquivo pom.xml da seguinte forma:
    <dependency>
	<groupId>org.apache.hadoop</groupId>
	<artifactId>hadoop-aws</artifactId>
	<version>2.9.2</version>
	<exclusions>
	<exclusion>
		<groupId>org.apache.hadoop</groupId>
		<artifactId>hadoop-common</artifactId>
	</exclusion>
	</exclusions>
</dependency>
<dependency>
	<groupId>com.amazonaws</groupId>
	<artifactId>aws-java-sdk</artifactId>
	<version>1.7.4</version>
</dependency>
  • Use um código semelhante ao seguinte para se conectar ao Amazon Web Services S3. Informe a chave de acesso e a chave secreta. No trecho de código abaixo, esses valores são representados pelas variáveis ACCESS e SECRET, respectivamente:
    SparkSession spark = SparkSession.builder().master("local")
	.config("spark.hadoop.fs.s3a.impl", "org.apache.hadoop.fs.s3a.S3AFileSystem")
	.config("spark.hadoop.fs.s3a.access.key", ACCESS)
	.config("spark.hadoop.fs.s3a.secret.key", SECRET)
	.config("fs.s3a.connection.ssl.enabled", "false")
	.getOrCreate();
  • Use um código semelhante ao seguinte para consultar os dados usando o local S3 e o nome da tabela especificado.
    Dataset<Row> ds = sqlContext.read().format("csv").option("header","true").load("<S3 Location>");
ds.createOrReplaceTempView("<Table Name>");
Dataset<Row> result_ds = sqlContext.sql("<SQL Query Using <Table Name>>");

Explorar Mais

Saiba mais sobre o Argo CD e como usá-lo para implantar o GitOps com o OCI Kubernetes Engine.

Revise estes recursos adicionais:

Reconhecimentos

Autor: Chiping Hwang