Pointer
DATAPREV
Turma administration-t3

GitLab System Administration — turma 3

Remoto ao vivo · 8 h · 25/05/2027 a 27/05/2027 · Instrutor: Gustavo Costa

← Todas as turmas

Agenda

SessãoDataHorárioMódulos
s125/05/202709:00–11:00Arquitetura e instalação da plataforma GitLab Self-Managed com o pacote Linux
s225/05/202711:00–13:00GitLab Runner: tipos, executores, registro e operação; Usuários, autenticação e restrições da instância
s327/05/202709:00–11:00Backup, restauração e upgrade
s427/05/202711:00–13:00Monitoramento, logs e diagnóstico da instância; Plataforma GitLab: organização, visibilidade e papéis

Formulários

Presença

Registro de presença na sessão com o código informado pelo instrutor.

coleta fechada

Responder

Avaliação pré

Questionário antes do primeiro módulo (mede o conhecimento inicial).

coleta fechada

Responder

Avaliação pós

O mesmo questionário ao final da turma (mede a evolução).

coleta fechada

Responder

Satisfação

Pesquisa anônima sobre a turma, o instrutor e os laboratórios.

coleta fechada

Responder

Módulos

Arquitetura e instalação da plataforma GitLab Self-Managed com o pacote Linux · Avançado · 3 h

Objetivos

  • Identificar os componentes da plataforma GitLab e o fluxo de uma requisição (NGINX, Workhorse, Puma, Sidekiq, Redis, PostgreSQL, Gitaly).
  • Dimensionar a instância com base em requisições por segundo e nas arquiteturas de referência.
  • Instalar a versão 19.4 pelo pacote Linux e configurar external_url e HTTPS.
  • Aplicar alterações do /etc/gitlab/gitlab.rb com gitlab-ctl reconfigure.

Pré-requisitos: Plataforma GitLab: organização, visibilidade e papéis

Conteúdo

TópicoTierFonte
Componentes: NGINX, GitLab Workhorse, Puma, Sidekiq, Redis, PostgreSQL, Gitaly, GitLab ShellFreedocumentação
Requisitos: 8 vCPU e 16 GB de memória como base em nó único; PostgreSQL 17 para GitLab 19.x; Redis ou Valkey (Redis Cluster não suportado)Freedocumentação
Arquiteturas de referência: RPS como métrica principal; tamanhos de 1.000 a 50.000 usuários (pacote Linux) e S/M/L/XL (Cloud Native); arquiteturas a partir de 3.000 usuários com HA incorporadaFreedocumentação
Configuração em /etc/gitlab/gitlab.rb, external_url e gitlab-ctl reconfigureFreedocumentação
HTTPS: Let's Encrypt habilitado por padrão com external_url https sem outro certificado; certificado próprio em /etc/gitlab/ssl/Freedocumentação
gitlab-ctl status, restart e tailFreedocumentação
GitLab Runner: tipos, executores, registro e operação · Intermediário · 2 h

Objetivos

  • Criar e registrar um runner com token de autenticação (prefixo glrt-).
  • Configurar tags, execução de jobs sem tag e runner protegido.
  • Distinguir runners de instância, grupo e projeto e os executores ativos e em manutenção.
  • Interpretar os status de runner (online, offline, stale, never_contacted).

Pré-requisitos: ci-fundamentos

Conteúdo

TópicoTierFonte
Runners de instância, grupo e projeto; fila de uso justo dos runners de instânciaFreedocumentação
Fluxo de criação de runner com token de autenticação glrt-; token de registro legadoFreedocumentação
Executores Kubernetes, Docker, Docker Autoscaler e Instance; SSH, Shell, Parallels, VirtualBox e Custom em modo de manutençãoFreedocumentação
Tags, Run untagged jobs, runners protegidosFreedocumentação
config.toml (/etc/gitlab-runner/ como root), concurrent e recarga automática a cada 3 segundosFreedocumentação
Status de runner: online (contato nas últimas 2 h), offline, stale (mais de 7 dias), never_contactedFreedocumentação
Usuários, autenticação e restrições da instância · Avançado · 2 h

Objetivos

  • Configurar restrições de cadastro (desabilitar cadastro, aprovação pelo administrador).
  • Configurar 2FA obrigatório com período de carência.
  • Configurar autenticação LDAP no gitlab.rb e verificá-la com gitlab-rake gitlab:ldap:check.
  • Identificar usuários auditores e papéis administrativos customizados.

Pré-requisitos: Arquitetura e instalação da plataforma GitLab Self-Managed com o pacote Linux

Conteúdo

TópicoTierFonte
Restrições de novos usuários: cadastro aberto por padrão; aprovação do administrador habilitada por padrão em novas instâncias; domínios permitidos/negadosFreedocumentação
2FA obrigatório para todos os usuários ou para administradores, com período de carência em horasFreedocumentação
LDAP: gitlab_rails['ldap_servers']; verificação de status a cada hora em sessões ativas e sincronização diária; estado ldap_blockedFreedocumentação
SAML SSO para a instância Self-ManagedFreedocumentação
Usuários auditores (somente leitura em toda a instância)Premiumdocumentação
Papéis administrativos customizados (GA 18.3)Ultimatedocumentação
Backup, restauração e upgrade · Avançado · 3 h

Objetivos

  • Executar backup com gitlab-backup create e salvar separadamente gitlab-secrets.json e gitlab.rb.
  • Restaurar backup em instância da mesma versão e tipo (CE/EE).
  • Planejar o caminho de upgrade com as paradas obrigatórias da versão 19.
  • Verificar a conclusão das batched background migrations antes do próximo upgrade.

Pré-requisitos: Arquitetura e instalação da plataforma GitLab Self-Managed com o pacote Linux

Conteúdo

TópicoTierFonte
gitlab-backup create: conteúdo do arquivo (banco, repositórios, artefatos, registries, uploads, estados Terraform)Freedocumentação
Dados fora do backup: /etc/gitlab (gitlab-secrets.json, gitlab.rb), object storage, Redis, chaves TLS e SSHFreedocumentação
Diretório padrão /var/opt/gitlab/backups (gitlab_rails['backup_path']); STRATEGY=copy; SKIP=Freedocumentação
Restauração: mesma versão e tipo, parada de Puma e Sidekiq, gitlab-backup restore BACKUP=<id>Freedocumentação
Paradas obrigatórias de upgrade em x.2, x.5, x.8 e x.11 (19.2, 19.5, 19.8, 19.11); última versão de patchFreedocumentação
Batched background migrations: Admin > Monitoring > Background migrations e API administrativaFreedocumentação
Monitoramento, logs e diagnóstico da instância · Avançado · 2 h

Objetivos

  • Configurar a allowlist de IPs dos endpoints de monitoramento.
  • Consultar os endpoints de health, readiness e liveness.
  • Localizar logs da aplicação em /var/log/gitlab e acompanhar com gitlab-ctl tail.
  • Executar gitlab-rake gitlab:check e gitlab:env:info no diagnóstico.

Pré-requisitos: Arquitetura e instalação da plataforma GitLab Self-Managed com o pacote Linux

Conteúdo

TópicoTierFonte
Endpoints /-/health, /-/readiness (com all=1 valida banco, Redis e Gitaly) e /-/liveness; HTTP 503 em falhaFreedocumentação
Allowlist de monitoramento gitlab_rails['monitoring_whitelist']Freedocumentação
Prometheus e exporters incluídos no pacote Linux, ativos por padrão, em localhost:9090, sem autenticaçãoFreedocumentação
Logs: production_json.log, api_json.log, application_json.log em /var/log/gitlab/gitlab-rails/Freedocumentação
Rake tasks gitlab:check e gitlab:env:infoFreedocumentação
Plataforma GitLab: organização, visibilidade e papéis · Básico · 2 h

Objetivos

  • Criar grupo, subgrupo e projeto na hierarquia de um grupo de nível superior.
  • Configurar a visibilidade de grupo e projeto respeitando a restrição do grupo pai.
  • Atribuir papéis padrão a membros e identificar o papel efetivo herdado.
  • Distinguir as permissões dos papéis Guest, Planner, Reporter, Developer, Maintainer e Owner.

Conteúdo

TópicoTierFonte
Grupos, subgrupos (até 20 níveis de aninhamento) e projetosFreedocumentação
Visibilidade private, internal e public; visibilidade do projeto igual ou mais restritiva que a do grupo paiFreedocumentação
Visibilidade internal disponível apenas em GitLab Self-Managed e GitLab DedicatedFreedocumentação
Papéis padrão (Minimal Access, Guest, Planner, Reporter, Developer, Maintainer, Owner) e prevalência do papel mais alto na herançaFreedocumentação
Papel Security Manager (beta desde 18.11)Freedocumentação
Membros de projeto e de grupo, membros herdados e diretosFreedocumentação

Laboratórios

Cada aluno recebe um subgrupo com os projetos dos exercícios; a correção é automática, pela API da plataforma GitLab.

ExercícioTítuloObjetivoTierDuração
lab-plataforma-01Estruturar grupo, subgrupo e projeto com papéisCriar a hierarquia de um time e atribuir papéis padrão a membros.Free40 min