One place for hosting & domains

      GitLab

      Como Instalar e Configurar o GitLab no Ubuntu 16.04


      Introdução

      O GitLab CE, ou Community Edition, é uma aplicação open source usada principalmente para hospedar repositórios Git, com recursos adicionais relacionados ao desenvolvimento, como rastreamento de problemas. Ele é projetado para ser hospedado usando a sua própria infraestrutura, e fornece flexibilidade na implantação como um repositório interno para sua equipe de desenvolvimento, publicamente como uma forma de interagir com usuários, ou até mesmo aberto como forma de os colaboradores hospedarem seus próprios projetos.

      O projeto do GitLab torna relativamente simples a configuração de uma instância do GitLab em seu próprio hardware com um mecanismo de fácil instalação. Neste guia vamos cobrir como instalar e configurar o GitLab em um servidor Ubuntu 16.04.

      Pré-Requisitos

      Este tutorial irá assumir que você tem acesso a um novo servidor Ubuntu 16.04. Os requisitos de hardware publicados do GitLab recomendam a utilização de um servidor com:

      Embora você possa substituir algum espaço de swap por RAM, isso não é recomendado. Para este guia assumiremos que você tem os recursos acima, no mínimo.

      Para começar, você vai precisar de um usuário não-root com acesso sudo configurado no servidor. É também uma boa ideia configurar um firewall básico para fornecer uma camada adicional de segurança. Você pode seguir os passos em nosso tutorial Configuração Inicial de servidor com Ubuntu 16.04 para obter essa configuração.

      Quando tiver satisfeito os pré-requisitos acima, continue para iniciar o procedimento de instalação.

      Instalando as Dependências

      Antes que possamos instalar o GitLab propriamente dito, é importante instalar alguns dos softwares que ele aproveita durante a instalação e que ele usa de forma contínua. Felizmente, todos os softwares necessários podem ser facilmente instalados a partir dos repositórios padrão do Ubuntu.

      Já que esta é a nossa primeira vez usando o apt durante esta sessão, podemos atualizar o índice de pacotes local e depois instalar as dependências digitando:

      • sudo apt-get update
      • sudo apt-get install ca-certificates curl openssh-server postfix

      Você provavelmente já terá alguns desses softwares instalados. Para a instalação do postfix, selecione Internet Site quando solicitado. Na próxima tela, entre com o nome de domínio do seu servidor ou seu endereço IP para configurar de que forma o sistema enviará e-mail.

      Instalando o GitLab

      Agora que as dependências estão instaladas, podemos instalar o GitLab. Este é um processo direto que utiliza um script de instalação para configurar seu sistema com os repositórios do GitLab.

      Vá para o diretório /tmp e então baixe o script de instalação:

      • cd /tmp
      • curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh

      Fique à vontade para examinar o script baixado para assegurar-se de que você esteja confortável com as ações que ele irá tomar. Você pode encontrar uma versão hospedada do script aqui:.

      Quando estiver satisfeito com a segurança do script, execute o instalador:

      • sudo bash /tmp/script.deb.sh

      Este script irá configurar seu servidor para utilizar os repositórios mantidos pelo GitLab. Isso lhe permite gerenciar o GitLab com as mesmas ferramentas de gerenciamento de pacotes que você usa para seus outros pacotes de sistema. Quando estiver completo, você pode instalar a aplicação real do GitLab com o apt:

      • sudo apt-get install gitlab-ce

      Isto irá instalar os componentes necessários em seu sistema.

      Ajustando as Regras de Firewall

      Antes de configurar o GitLab, você precisará garantir que suas regras de firewall são permissivas o suficiente para permitir o tráfego web. Se você seguiu o guia vinculado nos pré-requisitos, você terá um firewall ufw ativado.

      Veja o status atual do seu firewall ativo digitando:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      Como você pode ver, as regras atuais permitem o tráfego SSH, mas o acesso a outros serviços está restrito. Como o Gitlab é uma aplicação web, devemos permitir acesso HTTP entrante. Se você tiver um nome de domínio associado com o seu servidor GitLab, o GitLab pode também solicitar e ativar um certificado gratuito TLS/SSL a partir do projeto Let's Encrypt para proteger a instalação. Também queremos permitir o acesso HTTPS nesse caso.

      um vez que o protocolo de mapeamento de portas para HTTP e HTTPS está disponível no arquivo /etc/services, podemos permitir tais tráfegos pelo nome. Se você ainda não ativou o tráfego do OpenSSH, permita também esse tráfego agora:

      • sudo ufw allow http
      • sudo ufw allow https
      • sudo ufw allow OpenSSH

      Se você verificar com o comando ufw status novamente, você deverá ver o acesso configurado para no mínimo esses dois serviços:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 80 ALLOW Anywhere 443 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 80 (v6) ALLOW Anywhere (v6) 443 (v6) ALLOW Anywhere (v6)

      A saída acima indica que a interface web do GitLab estará acessível assim que configurarmos a aplicação.

      Editando o Arquivo de Configuração do GitLab

      Antes de você poder usar a aplicação, você precisa atualizar um arquivo de configuração e executar um comando de reconfiguração. Primeiro, abra o arquivo de configuração do GitLab:

      • sudo nano /etc/gitlab/gitlab.rb

      Perto do topo está a linha de configuração external_url. Atualize-a para corresponder ao seu próprio domínio ou endereço IP. Se você tem um domínio, altere o http para https para que o GitLab redirecione automaticamente os usuários para o site protegido pelo certificado do Let´s Encrypt que estaremos solicitando.

      /etc/gitlab/gitlab.rb

      
      # If your GitLab server does not have a domain name, you will need to use an IP
      # address instead of a domain and keep the protocol as `http`.
      external_url 'https://seu_dominio'
      

      Em seguida, se seu servidor GitLab tem um nome de domínio, pesquise o arquivo pela configuração letsencrypt['enable']. Descomente a linha e defina-a para true. Isso dirá ao GitLab para solicitar um certificado Let´s Encrypt para seu domínio GitLab e configurar a aplicação para servir o tráfego com ele.

      Abaixo disso, procure a configuração letsencrypt['contact_emails']. Esta configuração define uma lista de endereços de e-mail que o projeto Let´s Encrypt pode utilizar para lhe contatar se houver problemas com seu domínio. É uma boa idéia descomentar e preencher isso também para que você saiba de quaisquer problemas:

      /etc/gitlab/gitlab.rb

      
      letsencrypt['enable'] = true
      letsencrypt['contact_emails'] = ['sammy@seu_domínio.com']
      

      Salve e feche o arquivo. Agora, execute o seguinte comando para reconfigurar o GitLab:

      • sudo gitlab-ctl reconfigure

      Isso irá inicializar o GitLab utilizando as informações que ele pode encontrar sobre seu servidor. Esse é um processo completamente automatizado, portanto você não vai ter que responder a nenhuma solicitação. Se você ativou a integração com o Let´s Encrypt, um certificado deve ser configurado para o seu domínio.

      Realizando a Configuração Inicial Através da Interface web

      Agora que o GitLab está executando e o acesso está permitido, podemos realizar algumas configurações iniciais da aplicação através da interface web.

      Efetuando o Login pela Primeira Vez

      Visite o nome de domínio do seu servidor GitLab em seu navegador:

      http://domínio_gitlab_ou_IP
      

      Se você ativou o Let's Encrypt e usou https em seu external_url, você deve ser redirecionado para uma conexão HTTPS segura.

      Em sua primeira visita, você deve ver uma solicitação inicial para definir uma senha para a conta administrativa:

      Na solicitação inicial de senha, forneça e confirme uma senha segura para a conta administrativa. Clique no botão Change your password quando tiver terminado.

      Você será redirecionado à página convencional de login do GitLab:

      Aqui, você pode efetuar o login com a senha que você acabou de definir. As credenciais são:

      Entre com esses valores nos campos para os usuários existentes e clique no botão Sign in. Você será autenticado no aplicativo e levado a uma página de entrada que solicitará que você comece a adicionar projetos:

      Agora você pode fazer algumas mudanças simples para configurar o GitLab da maneira que você quiser.

      Ajustando suas Configurações de Perfil

      Uma das primeiras coisas que você deve fazer após uma nova instalação é colocar o seu perfil na melhor forma. O GitLab seleciona alguns padrões razoáveis, mas estes geralmente não são apropriados quando você começa a usar o software.

      Para fazer as modificações necessárias, clique no ícone do usuário no canto superior direito da interface. No menu suspenso exibido, selecione Settings:

      Você será levado para a seção de perfil ou Profile nas suas configurações:

      Ajuste Name e Email trocando "Administrator" e "admin@example.com" para algo mais adequado. O nome que você selecionou será mostrado para os outros usuários, equanto o e-mail será utilizado para detecção padrão do avatar, notificações, ações no Git através da interface, etc.

      Clique no botão Update Profile setting na parte inferior quando terminar:

      Um e-mail de confirmação será enviado ao endereço que você forneceu.
      Siga as instruções no e-mail para confirmar sua conta para que você possa começar a utilização do GitLab.

      Alterando o Nome da Sua Conta

      A seguir, clique no item Account na barra de menu à esquerda:

      Aqui, você pode encontrar seu token de API privada ou configurar a autenticação de dois fatores. Contudo, a funcionalidade a qual estamos interessados no momento é a seção Change username.

      Por padrão, à primeira conta administrativa é dado o nome root. Como esse é um nome conhecido de conta, é mais seguro alterar esse nome para um diferente. Você ainda terá privilégios administrativos; a única coisa que irá mudar é o nome:

      Clique no botão Update username para fazer a alteração:

      Na próxima vez que você fizer o login no GitLab, lembre-se de utilizar seu novo nome de usuário.

      Adicionando uma Chave SSH à sua Conta

      Em muitos casos, você irá querer usar chaves SSH com Git para interagir com seus projetos GitLab. Para fazer isso, você precisa adicionar sua chave pública à sua conta do GitLab.

      Se você já tem um par de chaves SSH criado em seu computador local, você geralmente pode ver a chave pública digitando:

      Você deverá ver um grande pedaço de texto, como este:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMuyMtMl6aWwqBCvQx7YXvZd7bCFVDsyln3yh5/8Pu23LW88VXfJgsBvhZZ9W0rPBGYyzE/TDzwwITvVQcKrwQrvQlYxTVbqZQDlmsC41HnwDfGFXg+QouZemQ2YgMeHfBzy+w26/gg480nC2PPNd0OG79+e7gFVrTL79JA/MyePBugvYqOAbl30h7M1a7EHP3IV5DQUQg4YUq49v4d3AvM0aia4EUowJs0P/j83nsZt8yiE2JEYR03kDgT/qziPK7LnVFqpFDSPC3MR3b8B354E9Af4C/JHgvglv2tsxOyvKupyZonbyr68CqSorO2rAwY/jWFEiArIaVuDiR9YM5 sammy@mydesktop

      Copie esse texto e volte para a página de configurações do perfil na interface web do gitLab.

      Se, em vez disso, você receber uma mensagem parecida como isto, você ainda não tem um par SSH configurado em sua máquina:

      Output

      cat: /home/sammy/.ssh/id_rsa.pub: No such file or directory

      Se for o caso, você pode criar um par de chaves SSH digitando:

      Aceite os padrões e, opcionalmente, forneça uma senha para proteger a chave localmente:

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/home/sammy/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sammy/.ssh/id_rsa. Your public key has been saved in /home/sammy/.ssh/id_rsa.pub. The key fingerprint is: SHA256:I8v5/M5xOicZRZq/XRcSBNxTQV2BZszjlWaIHi5chc0 sammy@gitlab.docsthat.work The key's randomart image is: +---[RSA 2048]----+ | ..%o==B| | *.E =.| | . ++= B | | ooo.o . | | . S .o . .| | . + .. . o| | + .o.o ..| | o .++o . | | oo=+ | +----[SHA256]-----+

      Depois de ter isso, você pode exibir sua chave pública como acima, digitando:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMuyMtMl6aWwqBCvQx7YXvZd7bCFVDsyln3yh5/8Pu23LW88VXfJgsBvhZZ9W0rPBGYyzE/TDzwwITvVQcKrwQrvQlYxTVbqZQDlmsC41HnwDfGFXg+QouZemQ2YgMeHfBzy+w26/gg480nC2PPNd0OG79+e7gFVrTL79JA/MyePBugvYqOAbl30h7M1a7EHP3IV5DQUQg4YUq49v4d3AvM0aia4EUowJs0P/j83nsZt8yiE2JEYR03kDgT/qziPK7LnVFqpFDSPC3MR3b8B354E9Af4C/JHgvglv2tsxOyvKupyZonbyr68CqSorO2rAwY/jWFEiArIaVuDiR9YM5 sammy@mydesktop

      Copie o bloco de texto exibido e volte para as configurações do perfil na interface web do GitLab.

      Clique no item SSH keys no menu à esquerda:

      No espaço fornecido cole a chave pública que você copiou da sua máquina local. Dê a ela um título descritivo, e clique no botão Add key:

      Agora você deve conseguir gerenciar seus projetos e repositórios do GitLab a partir de sua máquina local sem ter que fornecer suas credenciais de conta do GitLab.

      Restringindo ou Desabilitando Inscrições Públicas (Opcional)

      Você deve ter notado que é possível que alguém se inscreva para uma conta quando visitar a página de destino da sua instância do GitLab. Isso pode ser o que você deseja se estiver hospedando um projeto público. No entanto, muitas vezes, configurações mais restritivas são desejáveis.

      Para começar, vá até a área administrativa clicando no ícone de chave inglesa na barra de menu principal na parte superior da página:

      Na página seguinte, você pode ver uma visão geral da sua instância do GitLab como um todo. Para ajustar as configurações, clique no item Settings na parte inferior do menu à esquerda.

      Você será levado para as configurações globais da sua instância do GitLab. Aqui, você pode ajustar várias configurações que afetam se novos usuários podem se inscrever e qual será o nível de acesso deles.

      Desabilitando Inscrições

      Se você deseja desabilitar completamente as inscrições (você ainda pode criar manualmente as contas para novos usuários), desça até a seção Sign-up Restrictions.

      Desmarque a caixa de seleção Sign-up enabled:

      Role para baixo até o final e clique no botão Save:

      A seção de inscrição agora deve estar removida da página inicial do GitLab.

      Restringindo Inscrições Por Domínio

      Se você estiver usando o GitLab como parte de uma organização que fornece endereços de e-mail associados a um domínio, poderá restringir as inscrições por domínio em vez de desativá-las completamente.

      Na seção Sign-up Restrictions, primeiro selecione a caixa Send confirmation email on sign-up permitindo somente que os usuários façam login depois de confirmarem seus e-mails.

      Em seguida, adicione o seu domínio ou domínios à caixa Whitelisted domains for sign-ups, uma por linha. Você pode utilizar o asterisco "*" para especificar domínios curinga.

      Role para baixo até o final e clique no botão Salvar:

      A seção de inscrição agora deve estar removida da página inicial do GitLab.

      Restringindo a Criação de Projetos

      Por padrão, novos usuários podem criar até 10 projetos. Se você deseja permitir que novos usuários externos tenham visibilidade e participação, mas quer restringir seus acessos ao criar novos projetos, você pode fazer isto na seção Account and Limit Settings.

      Lá dentro, você pode alterar o limite padrão de projetos em Default projects limit para 0 para desativar completamente a criação de projetos por novos usuários.

      Novos usuários ainda podem ser adicionados a projetos manualmente e terão acesso a projetos internos ou públicos criados por outros usuários.

      Role para baixo até o final e clique no botão Salvar:

      Agora, novos usuários poderão criar contas, mas não poderão criar projetos.

      Criando um Cron Job para Renovar Automaticamente os Certificados Let's Encrypt

      Por padrão, os certificados Let's Encrypt são válidos por 90 dias. Se você ativou o Let's Encrypt para o seu domínio do GitLab anteriormente, você precisará garantir que seus certificados sejam renovados regularmente para evitar interrupções no serviço. O GitLab fornece o comando gitlab-ctl renew-le-certs para solicitar novos certificados quando seus ativos atuais se aproximarem da expiração.

      Para automatizar este processo, podemos criar um cron job para executar automaticamente este comando regularmente. O comando somente irá renovar o certificado quando ele estiver perto da expiração, para que possamos executá-lo com segurança regularmente

      Para começar, crie e abra um arquivo em /etc/cron.daily/gitlab-le em seu editor de textos:

      • sudo nano /etc/cron.daily/gitlab-le

      Dentro dele, cole o seguinte script:

      /etc/cron.daily/gitlab-le

      
      #!/bin/bash
      
      set -e
      
      /usr/bin/gitlab-ctl renew-le-certs > /dev/null
      

      Salve e feche o arquivo quando tiver terminado.

      Marque o arquivo como executável digitando:

      • sudo chmod +x /etc/cron.daily/gitlab-le

      Agora, o GitLab deve verificar automaticamente todos os dias se seu certificado Let's Encrypt precisa ser renovado. Em caso afirmativo, o comando renovará o certificado automaticamente.

      Conclusão

      Agora você deve ter uma instância do GitLab em funcionamento hospedada em seu próprio servidor. Você pode começar a importar ou criar novos projetos e configurar o nível apropriado de acesso para sua equipe. O GitLab está regularmente adicionando recursos e atualizando sua plataforma, por isso confira a página inicial do projeto para se manter atualizado sobre quaisquer melhorias ou avisos importantes.

      Por Justin Ellingwood



      Source link

      Como Construir Imagens Docker e Hospedar um Repositório de Imagens Docker com o GitLab


      Introdução

      A containerização está rapidamente se tornando o método de empacotamento e deploy de aplicações mais aceito nos ambientes de nuvem. A padronização que ele fornece, juntamente com sua eficiência de recursos (quando comparado a máquinas virtuais completas) e flexibilidade, o tornam um grande facilitador da moderna mentalidade DevOps. Muitas estratégias interessantes de deployment, orquestração e monitoramento nativas para nuvem tornam-se possíveis quando suas aplicações e microsserviços são totalmente containerizados.

      Os containers Docker são de longe os tipos mais comuns de container atualmente. Embora os repositórios públicos de imagem do Docker como o Docker Hub estejam repletos de imagens de software opensource containerizado que você pode fazer um docker pull hoje, para código privado você precisará pagar um serviço para construir e armazenar suas imagens, ou executar seu próprio software para fazer isso.

      O GitLab Community Edition é um pacote de software auto-hospedado que fornece hospedagem de repositório Git, acompanhamento de projetos, serviços de CI/CD, e um registro de imagem Docker, entre outros recursos. Neste tutorial vamos utilizar o serviço de integração contínua do GitLab para construir imagens Docker a partir de uma aplicação de exemplo em Node.js. Estas imagens serão então testadas e carregadas para o nosso próprio registro privado do Docker.

      Pré-requisitos

      Antes de começarmos, precisamos configurar um servidor GitLab seguro, e um GitLab CI runner para executar tarefas de integração contínua. As seções abaixo fornecerão links e maiores detalhes.

      Um Servidor Gitlab Protegido com SSL

      Para armazenar nosso código fonte, executar tarefas de CI/CD, e hospedar um registro Docker, precisamos de uma instância do GitLab instalada em um servidor Ubuntu 16.04. Atualmente, o GitLab recomenda um servidor com pelo menos 2 núcleos de CPU e 4GB de RAM. Adicionalmente, iremos proteger o servidor com certificados SSL do Let’s Encrypt. Para fazer isto, precisaremos de um nome de domínio apontando para o servidor.

      Você pode completar esses pré-requisitos com os seguintes tutoriais:

      Um GitLab CI Runner

      O tutorial Como configurar pipelines de integração contínua com o GitLab CI no Ubuntu 16.04 fornecerá uma visão geral do serviço de CI ou integração contínua do GitLab e mostrará como configurar um CI runner para processar jobs. Vamos construir isso em cima da aplicação de demonstração e da infraestrutura do runner criados neste tutorial.

      Passo 1 — Configurando um GitLab CI Runner Privilegiado

      No pré-requisito do tutorial de integração contínua com o GitLab, configuramos um GitLab runner utilizando sudo gitlab-runner register e seu processo de configuração interativo. Este runner é capaz de executar builds e testes de software dentro de containers Docker isolados.

      Entretanto, para se construir imagens Docker, nosso runner precisa de acesso total ao próprio serviço do Docker. A maneira recomendada de se configurar isto é utilizar a imagem docker-in-docker oficial do Docker para executar os jobs. Isto requer conceder ao runner um modo de execução privileged ou privilegiado. Portanto, criaremos um segundo runner com este modo ativado.

      Nota: Conceder ao runner o modo privileged basicamente desativa todas as vantagens de segurança da utilização de containers. Infelizmente, os outros métodos de ativar runners compatíveis com o Docker também carregam implicações de segurança semelhantes. Por favor, veja a documentação oficial do GitLab no Docker Build para aprender mais sobre as diferentes opções de runners e qual é a melhor para a sua situação.

      Como existem implicações de segurança para a utilização de runner privilegiado, vamos criar um runner específico do projeto que aceitará somente jobs de Docker em nosso projeto hello_hapi (Os administradores de GitLab sempre podem adicionar manualmente esse runner a outros projetos posteriormente). A partir da página do nosso projeto hello_hapi, clique em Settings na parte inferior do menu à esquerda, em seguida clique em CI/CD no sub-menu:

      Agora, clique no botão Expand ao lado da seção de configurações de Runners:

      Haverá algumas informações sobre como configurar um Specific Runner, incluindo um token de registro. Tome nota desse token. Quando o utilizamos para registrar um novo runner, o runner será bloqueado apenas para este projeto.

      Estando nesta página, clique no botão Disable shared Runners. Queremos ter certeza de que nossos jobs de Docker sempre executarão em nosso runner privilegiado. Se um runner compartilhado não privilegiado estivesse disponível, o GitLab pode optar por utilizá-lo, o que resultaria em erros de build.

      Faça o login no servidor que possui o seu CI runner atual. Se você não tiver uma máquina já configurada com os runners, volte e complete a seção Installing the GitLab CI Runner Service do tutorial de pré-requisitos antes de continuar.

      Agora, execute o seguinte comando para configurar o runner privilegiado específico do projeto:

      • sudo gitlab-runner register -n
      • --url https://gitlab.example.com/
      • --registration-token seu-token
      • --executor docker
      • --description "docker-builder"
      • --docker-image "docker:latest"
      • --docker-privileged

      Output

      Registering runner... succeeded runner=61SR6BwV Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

      Certifique-se de substituir suas próprias informações. Nós definimos todas as opções do nosso runner na linha de comando em vez de usar os prompts interativos, porque os prompts não nos permitem especificar o modo --docker-privileged.

      Agora o seu runner está configurado, registrado e executando. Para verificar, volte ao seu navegador. Clique no ícone de chave inglesa na barra de menu principal do GitLab, em seguida clique em Runners no menu à esquerda. Seus runners serão listados:

      Agora que temos um runner capaz de criar imagens do Docker, vamos configurar um registro privado do Docker para carregar imagens para ele.

      Passo 2 — Configurando o Registro Docker do GitLab

      Configurar seu próprio registro do Docker permite que você envie e extraia imagens de seu próprio servidor privado, aumentando a segurança e reduzindo as dependências do seu fluxo de trabalho em serviços externos.

      O GitLab irá configurar um registro Docker privado com apenas algumas atualizações de configuração. Primeiro vamos configurar a URL onde o registro irá residir. Depois, iremos (opcionalmente) configurar o registro para usar um serviço de armazenamento de objetos compatível com S3 para armazenar seus dados.

      Faça SSH em seu servidor GitLab, depois abra o arquivo de configuração do GitLab:

      • sudo nano /etc/gitlab/gitlab.rb

      Role para baixo até a seção Container Registry settings. Vamos descomentar a linha registry_external_url e configurá-la para o nosso host GitLab com a porta número 5555:

      /etc/gitlab/gitlab.rb

      
      registry_external_url 'https://gitlab.example.com:5555'
      

      A seguir, adicione as duas linhas seguintes para dizer ao registro onde encontrar nossos certificados Let’s Encrypt:

      /etc/gitlab/gitlab.rb

      
      registry_nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.example.com/fullchain.pem"
      registry_nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.example.com/privkey.pem"
      

      Salve e feche o arquivo, depois reconfigure o GitLab:

      • sudo gitlab-ctl reconfigure

      Output

      . . . gitlab Reconfigured!

      Atualize o firewall para pemitir tráfego para a porta do registro:

      Agora mude para outra máquina com o Docker instalado e efetue o login no registro Docker privado. Se você não tiver o Docker no seu computador de desenvolvimento local, você pode usar qualquer servidor configurado para executar seus jobs do GitLab CI, já que ele tem o Docker instalado:

      • docker login gitlab.example.com:5555

      Você será solicitado para inserir o seu nome de usuário e senha. Use suas credenciais do GitLab para efetuar login.

      Output

      Login Succeeded

      Sucesso! O registro está configurado e funcionando. Atualmente, ele armazenará arquivos no sistema de arquivos local do servidor GitLab. Se você quiser usar um serviço de armazenamento de objetos, continue com esta seção. Se não, pule para o Passo 3.

      Para configurar um backend de armazenamento de objetos para o registro, precisamos saber as seguintes informações sobre o nosso serviço de armazenamento de objetos:

      • Access Key

      • Secret Key

      • Region (us-east-1) por exemplo, se estiver usando Amazon S3, ou Region Endpoint se estiver usando um serviço compatível com S3 (https://nyc.digitaloceanspaces.com)

      • Nome do Bucket

      Se você estiver usando o DigitalOcean Spaces, você pode descobrir como configurar um novo Space e obter as informações acima lendo Como Criar um Space e uma Chave de API na DigitalOcean.

      Quando você tiver suas informações sobre o amazenamento de objetos, abra o arquivo de configuração do GitLab:

      • sudo nano /etc/gitlab/gitlab.rb

      Novamente, role até a seção de registro do container. Procure pelo bloco registry['storage'], descomente o bloco e atualize-o para o seguinte, novamente certificando-se de substituir suas próprias informações, quando apropriado:

      /etc/gitlab/gitlab.rb

      
      registry['storage'] = {
        's3' => {
          'accesskey' => 'sua-key',
          'secretkey' => 'seu-secret',
          'bucket' => 'seu-bucket-name',
          'region' => 'nyc3',
          'regionendpoint' => 'https://nyc3.digitaloceanspaces.com'
        }
      }
      

      Se você estiver uando Amazon S3, você precisa apenas da region e não do regionendpoint. Se estiver usando um serviço S3 compatível, como o Spaces, você irá precisar do regionendpoint. Neste caso, region na verdade não configura nada e o valor que você digita não importa, mas ainda precisa estar presente e não em branco.

      Salve e feche o arquivo.

      Nota: Atualmente, há um bug em que o registro será encerrado após trinta segundos se seu bucket de armazenamento de objetos estiver vazio. Para evitar isso, coloque um arquivo no seu bucket antes de executar a próxima etapa. Você poderá removê-lo mais tarde, após o registro ter adicionado seus próprios objetos.

      Se você estiver usando o Spaces da DigitalOcean, você pode arrastar e soltar um arquivo para carregá-lo usando a interface do Painel de Controle.

      Reconfigure o GitLab mais uma vez:

      • sudo gitlab-ctl reconfigure

      Em sua outra máquina Docker, efetue login no registro novamente para ter certeza de que tudo está bem:

      • docker login gitlab.example.com:5555

      Você deve receber uma mensagem de Login Succeeded.

      Agora que temos nosso registro do Docker configurado, vamos atualizar a configuração de CI da nossa aplicação para criar e testar nossa app, e enviar as imagens Docker para o nosso registro privado.

      Passo 3 — Atualizando o gitlab-ci.yaml e Construindo uma Imagem Docker

      Nota: Se você não concluiu o artigo de pré-requisito do GitLab CI você precisará copiar o repositório de exemplo para o seu servidor GitLab. Siga a seção Copying the Example Repository From GitHub para fazer isto.

      Para que possamos fazer o building de nossa app no Docker, precisamos atualizar o arquivo .gitlab-ci.yml. Você pode editar este arquivo diretamente no GitLab clicando na página principal do projeto, e depois no botão Edit. Alternativamente, você poderia clonar o repositório para a sua máquina local, editar o arquivo, e então fazer um git push nele de volta para o GitLab. Isso ficaria assim:

      • git clone git@gitlab.example.com:sammy/hello_hapi.git
      • cd hello_hapi
      • # edit the file w/ your favorite editor
      • git commit -am "updating ci configuration"
      • git push

      Primeiro, exclua tudo no arquivo, depois cole nele a seguinte configuração:

      .gitlab-ci.yml

      
      image: docker:latest
      services:
      - docker:dind
      
      stages:
      - build
      - test
      - release
      
      variables:
        TEST_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:$CI_COMMIT_REF_NAME
        RELEASE_IMAGE: gitlab.example.com:5555/sammy/hello_hapi:latest
      
      before_script:
        - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN gitlab.example.com:5555
      
      build:
        stage: build
        script:
          - docker build --pull -t $TEST_IMAGE .
          - docker push $TEST_IMAGE
      
      test:
        stage: test
        script:
          - docker pull $TEST_IMAGE
          - docker run $TEST_IMAGE npm test
      
      release:
        stage: release
        script:
          - docker pull $TEST_IMAGE
          - docker tag $TEST_IMAGE $RELEASE_IMAGE
          - docker push $RELEASE_IMAGE
        only:
          - master
      

      Certifique-se de atualizar os URLs e nomes de usuários realçados com suas próprias informações e, em seguida, salve com o botão Commit changes no GitLab. Se você está atualizando o arquivo fora do GitLab, confirme as mudanças e faça git push de volta no GitLab.

      Este novo arquivo de configuração diz ao GitLab para usar a imagem mais recente do docker (image: docker:latest) e vinculá-la ao serviço docker-in-docker (docker:dind). Então, ele define os estágios de build, test, e release. O estágio de build cria a imagem do Docker usando o Dockerfile fornecido pelo repositório, em seguida o carrega para o nosso registro de imagens Docker. Se isso for bem sucedido, o estágio test vai baixar a imagem que acabamos de construir e executar o comando npm test dentro dele. Se o estágio test for bem sucedido, o estágio release irá lançar a imagem, irá colocar uma tag como hello_hapi:latest e irá retorná-la ao registro.

      Dependendo do seu fluxo de trabalho, você também pode adicionar mais estágios test, ou mesmo estágios deploy que levam o aplicativo para um ambiente de preparação ou produção.

      A atualização do arquivo de configuração deve ter acionado um novo build. Volte ao projeto hello_hapi no GitLab e clique no indicador de status do CI para o commit:

      Na página resultante, você pode clicar em qualquer um dos estágios para ver seu progresso:

      Eventualmente, todas as etapas devem indicar que eles foram bem sucedidos, mostrando ícones com a marca de verificação em verde. Podemos encontrar as imagens Docker que acabaram de ser construídas clicando no item Registry no menu à esquerda:

      Se você clicar no pequeno ícone "document" ao lado do nome da imagem, ele copiará o comando apropriado docker pull ... para a sua área de transferência. Você pode então baixar e executar sua imagem:

      • docker pull gitlab.example.com:5555/sammy/hello_hapi:latest
      • docker run -it --rm -p 3000:3000 gitlab.example.com:5555/sammy/hello_hapi:latest

      Output

      > hello@1.0.0 start /usr/src/app > node app.js Server running at: http://56fd5df5ddd3:3000

      A imagem foi baixada do registro e iniciada em um container. Mude para o seu navegador e conecte-se ao aplicativo na porta 3000 para testar. Neste caso, estamos executando o container em nossa máquina local, assim podemos acessá-la via localhost na seguinte URL:

      http://localhost:3000/hello/test
      

      Output

      Hello, test!

      Sucesso! Você pode parar o container com CTRL-C. A partir de agora, toda vez que enviarmos um novo código para a ramificação master do nosso repositório, vamos construir e testar automaticamente uma nova imagem hello_hapi: latest.

      Conclusão

      Neste tutorial, configuramos um novo GitLab runner para criar imagens do Docker, criamos um regisro privado do Docker para armazená-las, e atualizamos um app Node.js para ser construído e testado dentro de containers Docker.

      Para aprender mais sobre os vários componentes utilizados nesta configuração, você pode ler a documentação oficial do GitLab CE, GitLab Container Registry, e do Docker.

      Por Brian Boucheron



      Source link

      How To Install and Configure GitLab on Debian 9


      Introduction

      GitLab CE, or Community Edition, is an open-source application primarily used to host Git repositories, with additional development-related features like issue tracking. It is designed to be hosted using your own infrastructure, and provides flexibility in deploying as an internal repository store for your development team, a public way to interface with users, or a means for contributors to host their own projects.

      The GitLab project makes it relatively straightforward to set up a GitLab instance on your own hardware with an easy installation mechanism. In this guide, we will cover how to install and configure GitLab on a Debian 9 server.

      Prerequisites

      For this tutorial, you will need:

      The published GitLab hardware requirements recommend using a server with:

      Although you may be able to get by with substituting some swap space for RAM, it is not recommended. For this guide we will assume that you have the above resources as a minimum.

      • A domain name pointed at your server. For more information, see our documentation on how to get started with DNS on DigitalOcean. This tutorial will use the domain name example.com for demonstration purposes.

      Step 1 — Installing the Dependencies

      Before we can install GitLab itself, it is important to install some of the software that it leverages during installation and on an ongoing basis. Fortunately, all of the required software can be easily installed from Debian’s default package repositories.

      Since this is our first time using apt during this session, we can refresh the local package index and then install the dependencies by typing:

      • sudo apt update
      • sudo apt install ca-certificates curl openssh-server postfix

      You may have some of this software installed already. For the postfix installation, select Internet Site when prompted. On the next screen, enter your server’s domain name to configure how the system will send mail.

      Step 2 — Installing GitLab

      Now that the dependencies are in place, we can install GitLab itself. This is a straightforward process that leverages an installation script to configure your system with the GitLab repositories.

      Move into the /tmp directory and then download the installation script:

      • cd /tmp
      • curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh

      Feel free to examine the downloaded script to ensure that you are comfortable with the actions it will take. You can also find a hosted version of the script here:

      Once you are satisfied with the safety of the script, run the installer:

      • sudo bash /tmp/script.deb.sh

      The script will set up your server to use the GitLab maintained repositories. This lets you manage GitLab with the same package management tools you use for your other system packages. Once this is complete, you can install the actual GitLab application with apt:

      • sudo apt install gitlab-ce

      This will install the necessary components on your system.

      Step 3 — Adjusting the Firewall Rules

      Before you configure GitLab, you will need to ensure that your firewall rules are permissive enough to allow web traffic. If you followed the guide linked in the prerequisites, you will have a ufw firewall enabled.

      View the current status of your active firewall by typing:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      As you can see, the current rules allow SSH traffic through, but access to other services is restricted. Since GitLab is a web application, we should allow HTTP access. Because we will be taking advantage of GitLab's ability to request and enable a free TLS/SSL certificate from Let's Encrypt, let's also allow HTTPS access.

      We can allow access to both HTTP and HTTPS by allowing the "WWW Full" app profile through our firewall. If you didn't already have OpenSSH traffic enabled, you should allow that traffic now too:

      • sudo ufw allow "WWW Full"
      • sudo ufw allow OpenSSH

      Check the ufw status again, this time appending the verbose flag; you should see access configured to at least these two services:

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp (OpenSSH) ALLOW IN Anywhere 80,443/tcp (WWW Full) ALLOW IN Anywhere 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6) 80,443/tcp (WWW Full (v6)) ALLOW IN Anywhere (v6)

      The above output indicates that the GitLab web interface will be accessible once we configure the application.

      Step 4 — Editing the GitLab Configuration File

      Before you can use the application, you need to update the configuration file and run a reconfiguration command. First, open Gitlab's configuration file:

      • sudo nano /etc/gitlab/gitlab.rb

      Near the top is the external_url configuration line. Update it to match your domain. Change http to https so that GitLab will automatically redirect users to the site protected by the Let's Encrypt certificate:

      /etc/gitlab/gitlab.rb

      ##! For more details on configuring external_url see:
      ##! https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab
      external_url 'https://example.com'
      

      Next, look for the letsencrypt['contact_emails'] setting. This setting defines a list of email addresses that the Let's Encrypt project can use to contact you if there are problems with your domain. It's a good idea to uncomment and fill this out so that you will know of any issues:

      /etc/gitlab/gitlab.rb

      letsencrypt['contact_emails'] = ['sammy@example.com']
      

      Save and close the file. Run the following command to reconfigure Gitlab:

      • sudo gitlab-ctl reconfigure

      This will initialize GitLab using the information it can find about your server. This is a completely automated process, so you will not have to answer any prompts. The process will also configure a Let's Encrypt certificate for your domain.

      Step 5 — Performing Initial Configuration Through the Web Interface

      With GitLab running and access permitted, we can perform some initial configuration of the application through the web interface.

      Logging In for the First Time

      Visit the domain name of your GitLab server in your web browser:

      https://example.com
      

      On your first time visiting, you should see an initial prompt to set a password for the administrative account:

      GitLab initial password set prompt

      In the initial password prompt, supply and confirm a secure password for the administrative account. Click on the Change your password button when you are finished.

      You will be redirected to the conventional GitLab login page:

      GitLab first sign in prompt

      Here, you can log in with the password you just set. The credentials are:

      • Username: root
      • Password: [the password you set]

      Enter these values into the fields for existing users and click the Sign in button. You will be signed into the application and taken to a landing page that prompts you to begin adding projects:

      GitLab initial login landing page

      You can now make some simple changes to get GitLab set up the way you'd like.

      Adjusting your Profile Settings

      One of the first things you should do after a fresh installation is get your profile into better shape. GitLab selects some reasonable defaults, but these are not usually appropriate once you start using the software.

      To make the necessary modifications, click on the user icon in the upper-right hand corner of the interface. In the drop down menu that appears, select Settings:

      GitLab profile settings button

      You will be taken to the Profile section of your settings:

      GitLab profile settings page

      Adjust the Name and Email address from "Administrator" and "admin@example.com" to something more accurate. The name you select will be displayed to other users, while the email will be used for default avatar detection, notifications, Git actions through the interface, etc.

      Click on the Update Profile settings button at the bottom when you are done:

      GitLab update profile settings button

      A confirmation email will be sent to the address you provided. Follow the instructions in the email to confirm your account so that you can begin using it with GitLab.

      Changing Your Account Name

      Next, click on the Account item in the left-hand menu bar:

      GitLab account menu item

      Here, you can find your private API token or configure two-factor authentication. However, the functionality we are interested in at the moment is the Change username section.

      By default, the first administrative account is given the name root. Since this is a known account name, it is more secure to change this to a different name. You will still have administrative privileges; the only thing that will change is the name. Replace root with your preferred username:

      GitLab change username section

      Click on the Update username button to make the change:

      GitLab update username button

      Next time you log in to the GitLab, remember to use your new username.

      Adding an SSH Key to your Account

      In most cases, you will want to use SSH keys with Git to interact with your GitLab projects. To do this, you need to add your SSH public key to your GitLab account.

      If you already have an SSH key pair created on your local computer, you can usually view the public key by typing:

      You should see a large chunk of text, like this:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMuyMtMl6aWwqBCvQx7YXvZd7bCFVDsyln3yh5/8Pu23LW88VXfJgsBvhZZ9W0rPBGYyzE/TDzwwITvVQcKrwQrvQlYxTVbqZQDlmsC41HnwDfGFXg+QouZemQ2YgMeHfBzy+w26/gg480nC2PPNd0OG79+e7gFVrTL79JA/MyePBugvYqOAbl30h7M1a7EHP3IV5DQUQg4YUq49v4d3AvM0aia4EUowJs0P/j83nsZt8yiE2JEYR03kDgT/qziPK7LnVFqpFDSPC3MR3b8B354E9Af4C/JHgvglv2tsxOyvKupyZonbyr68CqSorO2rAwY/jWFEiArIaVuDiR9YM5 sammy@mydesktop

      Copy this text and head back to the Settings page in GitLab's web interface.

      If, instead, you get a message that looks like this, you do not yet have an SSH key pair configured on your machine:

      Output

      cat: /home/sammy/.ssh/id_rsa.pub: No such file or directory

      If this is the case, you can create an SSH key pair by typing:

      Accept the defaults and optionally provide a password to secure the key locally:

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/home/sammy/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/sammy/.ssh/id_rsa. Your public key has been saved in /home/sammy/.ssh/id_rsa.pub. The key fingerprint is: SHA256:I8v5/M5xOicZRZq/XRcSBNxTQV2BZszjlWaIHi5chc0 sammy@gitlab.docsthat.work The key's randomart image is: +---[RSA 2048]----+ | ..%o==B| | *.E =.| | . ++= B | | ooo.o . | | . S .o . .| | . + .. . o| | + .o.o ..| | o .++o . | | oo=+ | +----[SHA256]-----+

      Once you have this, you can display your public key as above by typing:

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDMuyMtMl6aWwqBCvQx7YXvZd7bCFVDsyln3yh5/8Pu23LW88VXfJgsBvhZZ9W0rPBGYyzE/TDzwwITvVQcKrwQrvQlYxTVbqZQDlmsC41HnwDfGFXg+QouZemQ2YgMeHfBzy+w26/gg480nC2PPNd0OG79+e7gFVrTL79JA/MyePBugvYqOAbl30h7M1a7EHP3IV5DQUQg4YUq49v4d3AvM0aia4EUowJs0P/j83nsZt8yiE2JEYR03kDgT/qziPK7LnVFqpFDSPC3MR3b8B354E9Af4C/JHgvglv2tsxOyvKupyZonbyr68CqSorO2rAwY/jWFEiArIaVuDiR9YM5 sammy@mydesktop

      Copy the block of text that's displayed and head back to your Settings in GitLab's web interface.

      Click on the SSH Keys item in the left-hand menu:

      GitLab SSH Keys menu item

      In the provided space paste the public key you copied from your local machine. Give it a descriptive title, and click the Add key button:

      GitLab add SSH Key

      You should now be able to manage your GitLab projects and repositories from your local machine without having to provide your GitLab account credentials.

      Step 6 — Restricting or Disabling Public Sign-ups (Optional)

      You may have noticed that it is possible for anyone to sign up for an account when you visit your GitLab instance's landing page. This may be what you want if you are looking to host public project. However, many times, more restrictive settings are desirable.

      To begin, make your way to the administrative area by clicking on the wrench icon in the main menu bar at the top of the page:

      GitLab administrative area button

      On the page that follows, you can see an overview of your GitLab instance as a whole. To adjust the settings, click on the Settings item at the bottom of the left-hand menu:

      GitLab administrative settings button

      You will be taken to the global settings for your GitLab instance. Here, you can adjust a number of settings that affect whether new users can sign up and their level of access.

      Disabling Sign-ups

      If you wish to disable sign-ups completely (you can still manually create accounts for new users), scroll down to the Sign-up Restrictions section.

      Deselect the Sign-up enabled check box:

      GitLab deselect sign-ups enabled

      Scroll down to the bottom and click on the Save changes button:

      GitLab save settings button

      The sign-up section should now be removed from the GitLab landing page.

      Restricting Sign-ups By Domain

      If you are using GitLab as part of an organization that provides email addresses associated with a domain, you can restrict sign-ups by domain instead of completely disabling them.

      In the Sign-up Restrictions section, select the Send confirmation email on sign-up box, which will allow users to log in only after they've confirmed their email.

      Next, add your domain or domains to the Whitelisted domains for sign-ups box, one domain per line. You can use the asterisk "*" to specify wildcard domains:

      GitLab restrict sign-ups by domain

      Scroll down to the bottom and click on the Save changes button:

      GitLab save settings button

      The sign-up section should now be removed from the GitLab landing page.

      Restricting Project Creation

      By default, new users can create up to 10 projects. If you wish to allow new users from the outside for visibility and participation, but want to restrict their access to creating new projects, you can do so in the Account and Limit Settings section.

      Inside, you can change the Default projects limit to 0 to completely disable new users from creating projects:

      GitLab set projects to zero

      New users can still be added to projects manually and will have access to internal or public projects created by other users.

      Scroll down to the bottom and click on the Save changes button:

      GitLab save settings button

      New users will now be able to create accounts, but unable to create projects.

      Renewing Let's Encrypt Certificates

      By default, GitLab has a scheduled task set up to renew Let's Encrypt certificates after midnight every fourth day, with the exact minute based on your external_url. You can modify these settings in the /etc/gitlab/gitlab.rb file. For example, if you wanted to renew every 7th day at 12:30, you could configure this as follows:

      /etc/gitlab/gitlab.rb

      letsencrypt['auto_renew_hour'] = "12"
      letsencrypt['auto_renew_minute'] = "30"
      letsencrypt['auto_renew_day_of_month'] = "*/7"
      

      You can also disable auto-renewal by adding an additional setting to /etc/gitlab/gitlab.rb:

      /etc/gitlab/gitlab.rb

      letsencrypt['auto_renew'] = false
      

      With auto-renewals in place, you will not need to worry about service interruptions.

      Conclusion

      You should now have a working GitLab instance hosted on your own server. You can begin to import or create new projects and configure the appropriate level of access for your team. GitLab is regularly adding features and making updates to their platform, so be sure to check out the project's home page to stay up-to-date on any improvements or important notices.



      Source link