Implantar o GitLab para ativar pipelines de CI/CD no OCI

Arquitetura

Essa arquitetura de referência tem duas opções de implantação: uma implantação autônoma e outra distribuída.

Independente (<1,000 usuários)
A arquitetura stand-alone é a opção mais simples para o GitLab. Ele implanta todos os componentes do GitLab em uma única instância do serviço Compute em sua tenancy do OCI. Se você precisar atender até 1,000 usuários e não tiver requisitos de disponibilidade rigorosos, uma solução autônoma com backups frequentes será apropriada para muitas organizações. Uma única tenancy pode hospedar mais de um servidor GitLab. O diagrama a seguir ilustra esta arquitetura de referência:

Descrição da ilustração deploy_gitlab_sa.png
Distribuído (1000–2000 usuários)
A solução distribuída é uma arquitetura de várias camadas que separa os vários componentes de um servidor GitLab dedicado em instâncias separadas, cada uma designada para executar uma tarefa específica. Especificamente, a arquitetura distribuída tem um servidor PostgreSQL dedicado, Redis Server, Gitaly servers e instância de monitoramento Prometheus, que são todos necessários para uma implantação totalmente funcional do GitLab. Por recomendação da GitLab, esta implantação distribuída suporta aproximadamente 2,000 usuários. Tem um desempenho mais alto do que a implantação autônoma e maior tolerância a falhas devido a algumas redundâncias incorporadas. No entanto, a implantação distribuída não está altamente disponível.

Descrição da ilustração deploy_gitlab_dist.png

Essas arquiteturas têm os seguintes componentes:

Região
Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados 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 mesmo continentes).
Domínios de disponibilidade
Os domínios de disponibilidade são data centers independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura, como energia ou resfriamento, ou a rede de domínio de disponibilidade interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região. As instâncias implantadas como parte dessas arquiteturas de referência do GitLab entram em um único domínio de disponibilidade.
Rede virtual na nuvem (VCN) e sub-redes
Um VCN é uma rede definida por software que você configura em uma região OCI. As VCNs podem ser segmentadas em sub-redes, que podem ser específicas de uma região ou de um domínio de disponibilidade. As sub-redes específicas da região e do domínio de disponibilidade podem coexistir na mesma VCN. Uma sub-rede pode ser pública ou privada. Você pode implantar essa arquitetura GitLab em um VCN existente que contenha uma sub-rede pública e privada ou configurá-la para criar um VCN com as sub-redes necessárias.
- Sub-rede do host Bastion
  A sub-rede bastion host é uma sub-rede pública dedicada que contém a instância bastion host. O bastion host é um componente opcional dessa arquitetura e não será necessário se o GitLab estiver diretamente conectado à internet ou à sub-rede pública.
- Sub-rede do balanceador de carga
  A sub-rede do balanceador de carga é uma sub-rede pública dedicada que contém o balanceador de carga.
- Sub-rede privada do GitLab
  A sub-rede privada do GitLab contém os dois servidores do GitLab, os servidores Gitaly, o servidor Redis, o servidor Postgres, o servidor Prometheus-Grafana (monitoramento) e qualquer executor opcional do GitLab.
Balanceador de carga
O balanceador de carga contém o IP voltado ao público usado para estabelecer conexão com as instâncias do GitLab. Se quiser um nome de domínio personalizado para sua instância do GitLab, registre o endereço IP do balanceador de carga no provedor DNS. O balanceador de carga usa uma política de verificação de integridade de roubo redondo para monitorar os servidores do GitLab.
Compute
Para o GitLab, somente uma única instância do GitLab Server Compute é criada. Para a arquitetura distribuída, um total de oito instâncias do serviço Compute são criadas. Cada uma dessas instâncias fornece os seguintes serviços:
- Servidores GitLab
  A aplicação principal baseada na Web do GitLab é instalada nos dois servidores GitLab. A administração do GitLab é executada nessas instâncias e o balanceador de carga atua como front-end.
- Servidor PostgreSQL
  Armazena informações persistentes do banco de dados para o aplicativo GitLab. Por exemplo, usuários, permissões, problemas ou outros metadados são armazenados no banco de dados PostgreSQL.
- Servidor Redis
  A aplicação GitLab usa o Redis como um backend de banco de dados não persistente para informações de jobs, metadados e jobs de entrada.
- Servidores Gitaly
  O serviço Gitaly fornece armazenamento de arquivos para repositórios Git. Todos os arquivos que fazem parte de um repositório no GitLab são armazenados nos servidores Gitaly. Duas instâncias Gitaly são criadas para provar um nível de capacidade extra. Você pode personalizar qual servidor armazena os dados de um determinado projeto por repositório.
- Servidor PostgreSQL
  O GitLab armazena informações persistentes do banco de dados no servidor PostgreSQL. Exemplos de dados persistentes incluem usuários, permissões, problemas e outros metadados do projeto.
- Servidor Redis
  A aplicação GitLab usa o Redis como um backend de banco de dados não persistente para informações de jobs, determinados tipos de metadados e jobs de entrada.
- Servidor Prometheus + Grafana (monitoramento)
  O servidor Prometheus + Grafana é um servidor de monitoramento de sistemas e serviços. Ele coleta métricas de alvos configurados em intervalos determinados, avalia expressões de regra, exibe os resultados e pode acionar alertas quando condições especificadas são observadas.
- Executores
  Os executores do GitLab são máquinas dedicadas que trabalham com o GitLab CI/CD para executar jobs em um pipeline. Geralmente, eles são implantados em seu ambiente do GitLab depois que as instâncias do GitLab estão ativas, em execução e testadas. Eles não são criados como parte da implantação.
Object Storage
A implantação distribuída cria uma série de buckets de Armazenamento de Objetos na tenancy do OCI, projetados para armazenar vários tipos de dados associados aos projetos do GitLab, incluindo backups.

Recomendações

Use as recomendações a seguir como ponto de partida ao implantar o GitLab para ativar pipelines de CI/CD no Oracle Cloud Infrastructure. Seus requisitos podem ser diferentes da arquitetura descrita aqui.

Calcular formas

Essa arquitetura usa uma imagem do SO Oracle Linux e suporta todas as famílias de formas de Computação, padrão ou flexíveis. A GitLab recomenda os seguintes parâmetros de configuração para a implantação independente e distribuída:

Standalone

Serviço

Configuração

Servidor GitLab

4 OCPU, 8 GB RAM

Executores do GitLab (N opcional)

1 OCPU, 4 GB RAM

Distribuído

Serviço

Configuração

Servidor Bastion (opcional)

1 OCPU, 2 GB RAM

Servidores GitLab (2)

4 OCPU, 8 GB RAM

PostgreSQL

1 OCPU, 8 GB RAM

Redis

1 OCPU, 4 GB RAM

Gitaly (1 obrigatório, 2 opcional)

2 OCPU, 16-GB RAM

Nó de monitoramento

1 OCPU, 2 GB RAM

Executores do GitLab (N opcional)

1 OCPU, 4 GB RAM

A GitLab recomenda essas configurações, mas você pode personalizá-las no momento da implantação.

VCN
Ao criar VCN e sub-redes, use blocos CIDR que não se sobreponham a nenhuma outra rede (no OCI, no seu data center local ou em outro provedor de nuvem) para a qual você pretenda configurar conexões privadas. Os blocos CIDR do VCN são editáveis após a criação.

Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos de uma camada ou função específica à mesma sub-rede, que pode servir como um limite de segurança.
Segurança
Use o Oracle Cloud Guard para monitorar e manter a segurança de seus recursos no OCI de forma proativa. O Cloud Guard usa receitas de detectores que você pode definir para examinar seus recursos quanto a deficiências de segurança e monitorar operadores e usuários quanto a atividades de risco. Quando qualquer configuração incorreta ou atividade insegura é detectada, o Cloud Guard recomenda ações corretivas e auxilia nessas ações, com base nas receitas do respondedor que você pode definir.

Para recursos que exigem segurança máxima, a Oracle recomenda que você use zonas de segurança. Uma zona de segurança é um compartimento associado a uma receita definida pela Oracle de políticas de segurança baseadas nas melhores práticas. Por exemplo, os recursos em 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ê cria e atualiza recursos em uma zona de segurança, o OCI valida as operações em relação às políticas na receita da zona de segurança e nega operações que violem qualquer uma das políticas.
Executores
Você pode implantar executores do GitLab na mesma sub-rede privada que as instâncias existentes do GitLab ou em uma VCN ou sub-rede dedicada.

Considerações

Considere os pontos a seguir ao implantar esta arquitetura de referência.

Desempenho
Todas as formas de Computação default iniciadas como parte dessa arquitetura seguem as recomendações fornecidas na documentação do GitLab. No entanto, se um nó de partícula precisar de mais recursos, você poderá dimensionar as formas do serviço Compute. A arquitetura distribuída tem um desempenho mais alto do que uma implantação independente. As arquiteturas têm as seguintes opções de métricas de desempenho esperadas.
Segurança
Exceto para o balanceador de carga e o host bastion, se houver, todos os componentes da arquitetura GitLab estarão na sub-rede privada. As instâncias do serviço Compute na arquitetura distribuída têm firewall ativado, com o iptables ativado e apenas as portas necessárias abertas para permitir a comunicação entre os nós.
Disponibilidade
Os servidores GitLab são implantados como um par e balanceados pelo balanceador de carga. Todas as instâncias são implantadas em um único domínio de disponibilidade. Essa arquitetura de referência também cria vários buckets do serviço Object Storage para armazenar vários tipos de dados. O Object Storage é um serviço regional e não está vinculado a nenhuma instância ou domínio de disponibilidade específico do serviço Compute. Você pode acessar dados de qualquer lugar dentro ou fora do contexto do OCI, desde que tenha conectividade com a Internet e possa acessar um dos pontos finais do Object Storage. Esta implantação usa um gateway de serviço para estabelecer conexão com os buckets de armazenamento de objetos. Um gateway de serviço permite conectividade com os pontos finais públicos do Object Storage a partir de endereços IP privados em sub-redes privadas
Backups e restauração
A implantação distribuída cria um bucket do Object Storage para armazenar backups e define todas as definições de configuração necessárias para fazer upload de dados para esse bucket. Ele também cria um job cron na instância principal do servidor GitLab, que cria backups diários dos dados do GitLab, faz upload para o bucket e armazena uma cópia na máquina. O arquivo gitlab-secrets.json contém dados confidenciais e não está incluído neste backup. Recomendamos que você mantenha uma cópia do diretório /etc/gitlab ou do arquivo /etc/gitlab/gitlab-secrets.json em um local seguro que exista fora dessa implantação por um administrador. Considere se você deseja backups mais frequentes e defina políticas de retenção apropriadas no bucket do Object Storage.
```
## Run a backup everyday at 1am.
0 1 * * * sudo gitlab-backup create
 
## Run a separate backup for configuration settings (creates a tar archive in /etc/gitlab/config_backup)
0 2 * * * sudo gitlab-ctl backup-etc
```
Você pode fazer backup não apenas de dados GitLab, mas de todo o servidor GitLab. O serviço OCI Block Volume permite que você execute backups de volume em blocos automaticamente em uma programação e os retenha com base na política de backup selecionada. Para obter mais detalhes, consulte a documentação de Backups Baseados em Política.
Custo
O custo dessa arquitetura está relacionado a qualquer infraestrutura implantada do OCI, como instâncias do serviço Compute, balanceador de carga de rede e armazenamento de dados, além de quaisquer compras de licenciamento do GitLab. Para obter mais informações sobre o custo dos serviços OCI, consulte a página Lista de Processos do Oracles Cloud.
URL Público
Considere o uso do provedor DNS para associar o endereço IP público da instância do GitLab a um nome de domínio personalizado. Na arquitetura distribuída, o URL personalizado deve ser associado ao endereço IP público do balanceador de carga. Você pode definir o nome do domínio do URL externo no momento da implantação e, em seguida, associar o URL ao endereço IP na implantação do GitLab após. Você sempre pode alterar o URL personalizado após o fato.

Implantar

O código Terraform desta arquitetura de referência está disponível como uma pilha de amostra no Oracle Cloud Infrastructure Resource Manager. Você também pode fazer download do código do GitLab e personalizá-lo para atender aos seus requisitos específicos.

Implantar usando a pilha de amostra no Oracle Cloud Infrastructure Resource Manager:
1. Clique em.
  Se você ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.
2. Selecione a região em que deseja implantar a pilha.
3. Siga os prompts e instruções na tela para criar a pilha.
4. Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
5. Aguarde a conclusão do job e revise o plano.
  Para fazer alterações, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação Plano novamente.
6. Se nenhuma outra alteração for necessária, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
Implante usando o código Terraform no GitLab:
1. Vá para o GitLab.
2. Clone ou faça download do repositório para o computador local.
3. Siga as instruções no documento README.

Explorar Mais

Saiba mais sobre a implantação do GitLab para ativar pipelines de CI/CD no Oracle Cloud Infrastructure.

Revise estes recursos adicionais: