One place for hosting & domains

      Configurar

      Como Configurar Pipelines de Integração Contínua com o GitLab CI no Ubuntu 16.04


      Introdução

      O GitLab Community Edition é um provedor de repositório Git auto-hospedado com recursos adicionais para ajudar no gerenciamento de projetos e no desenvolvimento de software. Um dos recursos mais valiosos que o GitLab oferece é a ferramenta embutida de integração e entrega contínua chamada GitLab CI.

      Neste guia, vamos demonstrar como configurar o GitLab CI para monitorar seus repositórios por mudanças e executar testes automatizados para validar código novo. Começaremos com uma instalação do GitLab em execução, na qual copiaremos um repositório de exemplo para uma aplicação básica em Node.js. Depois de configurarmos nosso processo de CI, quando um novo commit é enviado ao repositório o GitLab irá utilizar o CI runner para executar o conjunto de testes em cima do código em um container Docker isolado.

      Pré-requisitos

      Antes de começarmos, você precisará configurar um ambiente inicial. Vamos precisar de um servidor GitLab seguro configurado para armazenar nosso código e gerenciar nosso processo de CI/CD. Adicionalmente, precisaremos de um local para executar os testes automatizados. Este pode ser o mesmo servidor em que o GitLab está instalado ou um host separado. As seções abaixo cobrem os requisitos em mais detalhes.

      Um Servidor GitLab Protegido com SSL

      Para armazenar nosso código-fonte e configurar nossas tarefas de CI/CD, precisamos de uma instância do GitLab instalada em um servidor Ubuntu 16.04. Atualmente o GitLab recomenda um servidor com no mínimo 2 núcleos de CPU e 4GB de RAM. Para proteger seu código de ser exposto ou adulterado, a instância do GitLab será protegida com SSL usando o Let’s Encrypt. Seu servidor precisa ter um nome de domínio associado a ele para completar essa etapa.

      Você pode atender esses requisitos usando os seguintes tutoriais:

      Estaremos demonstrando como compartilhar CI/CD runners (os componentes que executam os testes automatizados). Se você deseja compartilhar CI runners entre projetos, recomendamos fortemente que você restrinja ou desative as inscrições públicas. Se você não modificou suas configurações durante a instalação, volte e siga a etapa opcional do artigo de instalação do GitLab sobre como restringir ou desabilitar as inscrições para evitar abusos por parte de terceiros.

      Um ou Mais Servidores para Utilizar como GitLab CI Runners

      GitLab CI Runners são os servidores que verificam o código e executam testes automatizados para validar novas alterações. Para isolar o ambiente de testes, estaremos executando todos os nossos testes automatizados em containers Docker. Para fazer isso, precisamos instalar o Docker no servidor ou servidores que irão executar os testes.

      Esta etapa pode ser concluída no servidor GitLab ou em outro servidor Ubuntu 16.04 para fornecer isolamento adicional e evitar contenção de recursos. Os seguintes tutoriais instalarão o Docker no host que você deseja usar para executar seus testes:

      Quando estiver pronto para começar, continue com este guia.

      Copiando o Repositório de Exemplo a partir do GitHub

      Para começar, vamos criar um novo projeto no GitLab contendo a aplicação de exemplo em Node.js. Iremos importar o repositório original diretamente do GitHub para que não tenhamos que carregá-lo manualmente.

      Efetue o login no GitLab e clique no ícone de adição no canto superior direito e selecione New project para adicionar um novo projeto:

      Na página do novo projeto, clique na aba Import project:

      A seguir, clique no botão Repo by URL. Embora exista uma opção de importação do GitHub, ela requer um token de acesso Pessoal e é usada para importar o repositório e informações adicionais. Estamos interessados apenas no código e no histórico do Git, portanto, importar pela URL é mais fácil.

      No campo Git repository URL, insira a seguinte URL do repositório GitHub:

      https://github.com/do-community/hello_hapi.git
      

      Deve se parecer com isto:

      Como esta é uma demonstração, provavelmente é melhor manter o repositório marcado como Private ou privado. Quando terminar, clique em Create project.

      O novo projeto será criado baseado no repositório importado do Github.

      Entendendo o arquivo .gitlab-ci.yml

      O GitLab CI procura por um arquivo chamado .gitlab-ci.yml dentro de cada repositório para determinar como ele deve testar o código. O repositório que importamos já tem um arquivo .gitlab-ci.yml configurado para o projeto. Você pode aprender mais sobre o formato lendo a documentação de referência do .gitlab-ci.yml.

      Clique no arquivo .gitlab-ci.yml na interface do GitLab para o projeto que acabamos de criar. A configuração do CI deve ser algo assim:

      .gitlab-ci.yml

      
      image: node:latest
      
      stages:
        - build
        - test
      
      cache:
        paths:
          - node_modules/
      
      install_dependencies:
        stage: build
        script:
          - npm install
        artifacts:
          paths:
            - node_modules/
      
      test_with_lab:
        stage: test
        script: npm test
      

      O arquivo utiliza a sintaxe de configuração YAML no GitLab CI para definir as ações que devem ser tomadas, a ordem na qual elas devem executar, sob quais condições elas devem ser executadas e os recursos necessários para concluir cada tarefa. Ao escrever seus próprios arquivos de CI do GitLab, você pode checar com um validador indo até /ci/lint em sua instância GitLab para validar que seu arquivo está formatado corretamente.

      O arquivo de configuração começa declarando uma image ou imagem do Docker que deve ser usada para executar o conjunto de testes. Como o Hapi é um framework Node.js, estamos usando a imagem Node.js mais recente:

      image: node:latest
      

      Em seguida, definimos explicitamente os diferentes estágios de integração contínua que serão executados:

      stages:
        - build
        - test
      

      Os nomes que você escolhe aqui são arbitrários, mas a ordenação determina a ordem de execução dos passos que se seguirão. Stages ou estágios são tags que você pode aplicar a jobs individuais. O GitLab vai executar jobs do mesmo estágio em paralelo e vai esperar para executar o próximo estágio até que todos os jobs do estágio atual estejam completos. Se nenhum estágio for definido, o GitLab usará três estágios chamados build, test, e deploy e atribuir todos os jobs ao estágio test por padrão.

      Após definir os estágios, a configuração inclui uma definição de cache:

      cache:
        paths:
          - node_modules/
      

      Isso especifica arquivos ou diretórios que podem ser armazenados em cache (salvos para uso posterior) entre execuções ou estágios. Isso pode ajudar a diminuir o tempo necessário para executar tarefas que dependem de recursos que podem não ser alterados entre execuções. Aqui, estamos fazendo cache do diretório node_modules, que é onde o npm instala as dependências que ele baixa.

      Nosso primeiro job é chamado install_dependencies:

      install_dependencies:
        stage: build
        script:
          - npm install
        artifacts:
          paths:
            - node_modules/
      

      Os jobs podem ter qualquer nome, mas como os nomes serão usados na interface do usuário do GitLab, nomes descritivos são úteis. Normalmente, o npm install pode ser combinado com os próximos estágios de teste, mas para melhor demonstrar a interação entre os estágios, estamos extraindo essa etapa para executar em seu próprio estágio.

      Marcamos o estágio explicitamente como “build” com a diretiva stage. Em seguida, especificamos os comandos reais a serem executados usando a diretiva script. Você pode incluir vários comandos inserindo linhas adicionais dentro da seção script.

      A sub-seção artifacts é utilizada para especificar caminhos de arquivo ou diretório para salvar e passar entre os estágios. Como o comando npm install instala as dependências do projeto, nossa próxima etapa precisará de acesso aos arquivos baixados. A declaração do caminho node_modules garante que o próximo estágio terá acesso aos arquivos. Estes estarão também disponíveis para visualizar ou baixar na interface de usuário do GitLab após o teste, assim isso é útil para construir artefatos como binários também. Se você quiser salvar tudo que foi produzido durante o estágio, substitua a seção path inteira por untracked: true.

      Finalmente, o segundo job chamado test_with_lab declara o comando que realmente executará o conjunto de testes:

      test_with_lab:
        stage: test
        script: npm test
      

      Colocamos isso no estágio test. Como esse é o último estágio, ele tem acesso aos artefatos produzidos pelo estágio build que são as dependências do projeto em nosso caso. Aqui, a seção script demonstra a sintaxe YAML de linha única que pode ser usada quando há apenas um único item. Poderíamos ter usado essa mesma sintaxe no job anterior, já que apenas um comando foi especificado.

      Agora que você tem uma ideia básica sobre como o arquivo .gitlab-ci.yml define tarefas CI/CD, podemos definir um ou mais runners capazes de executar o plano de testes.

      Disparando uma Execução de Integração Contínua

      Como o nosso repositório inclui um arquivo .gitlab-ci.yml, quaisquer novos commits irão disparar uma nova execução de CI. Se não houver runners disponíveis, a execução da CI será definida como “pending” ou pendente. Antes de definirmos um runner, vamos disparar uma execução de CI para ver como é um job no estado pendente. Uma vez que um runner esteja disponível, ele imediatamente pegará a execução pendente.

      De volta à visão do repositório do projeto do GitLab hello_hapi, clique no sinal de adição ao lado do branch e do nome do projeto e selecione New file no menu:

      Na próxima página, insira dummy_file no campo File name e insira algum texto na janela principal de edição:

      Clique em commit changes na parte inferior quando terminar.

      Agora, retorne à página principal do projeto. Um pequeno ícone de pausa será anexado ao commit mais recente. Se você passar o mouse sobre o ícone, ele irá exibir “Commit:pending”:

      Isso significa que os testes que validam as alterações de código ainda não foram executados.

      Para obter mais informações, vá para o topo da página e clique em Pipelines. Você será direcionado para a página de visão geral do pipeline, na qual é possível ver que a execução CI está marcada como pending e rotulada como “stuck”:

      Nota: Do lado direito há um botão para a ferramenta CI Lint. É aqui que você pode verificar a sintaxe de qualquer arquivo gitlab-ci.yml que você escreve.

      A partir daqui, você pode clicar no status pending para obter mais detalhes sobre a execução. Esta visão mostra os diferentes estágios de nossa execução, bem como os jobs individuais associados a cada estágio:

      Finalmente, clique no job install_dependencies. Isso lhe dará detalhes específicos sobre o que está atrasando a execução:

      Aqui, a mensagem indica que o trabalho está preso devido à falta de runners. Isso é esperado, uma vez que ainda não configuramos nenhum. Quando um runner estiver disponível, essa mesma interface poderá ser usada para ver a saída. Este é também o local onde você pode baixar os artefatos produzidos durante o build.

      Agora que sabemos como é um job pendente, podemos atribuir um runner de CI ao nosso projeto para pegar o job pendente.

      Instalando o Serviço CI Runner do GitLab

      Agora estamos prontos para configurar um CI Runner do GitLab. Para fazer isso, precisamos instalar o pacote CI runner do GitLab no sistema e iniciar o serviço do runner. O serviço pode executar várias instâncias do runner para projetos diferentes.

      Como mencionado nos pré-requisitos, você pode completar estes passos no mesmo servidor que hospeda sua instância do GitLab ou em um servidor diferente se você quiser ter certeza de evitar a contenção de recursos. Lembre-se de que, seja qual for o host escolhido, você precisa do Docker instalado para a configuração que usaremos.

      O processo de instalação do serviço CI runner do GitLab é similar ao processo usado para instalar o próprio GitLab. Iremos baixar um script para adicionar um repositório GitLab à nossa lista de fontes apt. Depois de executar o script, faremos o download do pacote do runner. Podemos então configurá-lo para servir nossa instância do GitLab.

      Comece baixando a versão mais recente do script de configuração do repositório do GitLab CI runner para o diretório /tmp (este é um repositório diferente daquele usado pelo servidor GitLab):

      • curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh

      Sinta-se à vontade para examinar o script baixado para garantir que você está confortável com as ações que ele irá tomar. Você também pode encontrar uma versão hospedada do script aqui:

      • less /tmp/gl-runner.deb.sh

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

      • sudo bash /tmp/gl-runner.deb.sh

      O script irá configurar seu servidor para usar os repositórios mantidos pelo GitLab. Isso permite gerenciar os pacotes do runner do GitLab com as mesmas ferramentas de gerenciamento de pacotes que você usa para os outros pacotes do sistema. Quando isso estiver concluído, você pode prosseguir com a instalação usando apt-get:

      • sudo apt-get install gitlab-runner

      Isso irá instalar o pacote CI runner do GitLab no sistema e iniciar o serviço GitLab runner.

      Configurando um GitLab Runner

      Em seguida, precisamos configurar um CI runner do GitLab para que ele possa começar a aceitar trabalho.

      Para fazer isso, precisamos de um token do GitLab runner para que o runner possa se autenticar com o servidor GitLab. O tipo de token que precisamos depende de como queremos usar esse runner.

      Um runner específico do projeto é útil se você tiver requisitos específicos para o runner. Por exemplo, se seu arquivo gitlab-ci.yml define tarefas de deployment que requeiram credenciais, um runner específico pode ser necessário para autenticar corretamente dentro do ambiente de deployment. Se o seu projeto tiver etapas com recursos intensivos no processo do CI, isso também pode ser uma boa ideia. Um runner específico do projeto não irá aceitar jobs de outros projetos.

      Por outro lado, um runner compartilhado é um runner de propósito geral que pode ser utilizado por vários projetos. Os runners receberão jobs dos projetos de acordo com um algoritmo que contabiliza o número de jobs que estão sendo executados atualmente para cada projeto. Esse tipo de runner é mais flexível. Você precisará fazer login no GitLab com uma conta de administrador para configurar os runners compartilhados.

      Vamos demonstrar como obter os tokens de runner para esses dois tipos de runner abaixo. Escolha o método que melhor lhe convier.

      Coletando Informações para Registrar um Runner Específico de Projeto

      Se você quiser que o runner seja vinculado a um projeto específico, comece navegando até a página do projeto na interface do GitLab.

      A partir daqui, clique no item Settings no menu à esquerda. Depois, clique no item CI/CD no submenu:

      Nesta página, você verá uma seção Runners settings. Clique no botão Expand para ver mais detalhes. Na visão de detalhes, o lado esquerdo explicará como registrar um runner específico do projeto. Copie o token de registro exibido na etapa 4 das instruções:

      Se você quiser desativar quaisquer runners compartilhados ativos para este projeto, você pode fazê-lo clicando no botão Disable shared Runners no lado direito. Isso é opcional.

      Quando estiver pronto, avance para aprender como registrar seu runner usando as informações coletadas nesta página.

      Coletando Informações para Registrar um Runner Compartilhado

      Para encontrar as informações necessárias para registrar um runner compartilhado, você precisa estar logado com uma conta administrativa.

      Comece clicando no ícone de chave inglesa na barra de navegação superior para acessar a área administrativa. Na seção Overview do menu à esquerda, clique em Runners para acessar a página de configuração do runner compartilhado.

      Copie o token de registro exibido na parte superior da página:

      Usaremos esse token para registrar um runner do GitLab CI para o projeto.

      Registrando um Runner do GitLab CI com o Servidor GitLab

      Agora que você tem um token, volte para o servidor em que seu serviço do runner do GitLab CI está instalado.

      Para registrar um novo runner, digite o seguinte comando:

      • sudo gitlab-runner register

      Você será solicitado a responder uma série de questões para configurar o runner:

      Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/)

      Insira o nome de domínio do seu servidor GitLab, usando https:// para especificar SSL. Você pode, opcionalmente, anexar /ci ao final do seu domínio, mas as versões recentes serão redirecionadas automaticamente.

      Please enter the gitlab-ci token for this runner

      Insira o token que você copiou na última seção.

      Please enter the gitlab-ci description for this runner

      Insira um nome para esse runner particular. Isso será exibido na lista de runners do serviço, na linha de comando e na interface do GitLab.

      Please enter the gitlab-ci tags for this runner (comma separated)

      Estas são tags que você pode atribuir ao runner. Os jobs do GitLab podem expressar requisitos em termos dessas tags para garantir que eles sejam executados em um host com as dependências corretas.

      Você pode deixar isso em branco neste caso.

      Whether to lock Runner to current project [true/false]

      Atribua o runner ao projeto específico. Ele não poderá ser utilizado por outro projeto.

      Selecione “false” aqui.

      Please enter the executor

      Insira o método usado pelo runner para completar jobs.

      Escolha “docker” aqui.

      Please enter the default Docker image (e.g. ruby:2.1)

      Insira a imagem padrão utilizada para executar jobs quando o arquivo .gitlab-ci.yml não incluir uma especificação de imagem. É melhor especificar uma imagem geral aqui e definir imagens mais específicas em seu arquivo .gitlab-ci.yml como fizemos.

      Vamos inserir “alpine:latest” aqui como um padrão pequeno e seguro.

      Depois de responder às questões, um novo runner será criado, capaz de executar os jobs de CI/CD do seu projeto.

      Você pode ver os runners que o serviço de runner do GitLab CI tem atualmente disponíveis digitando:

      Output

      Listing configured runners ConfigFile=/etc/gitlab-runner/config.toml example-runner Executor=docker Token=e746250e282d197baa83c67eda2c0b URL=https://example.com

      Agora que temos um runner disponível, podemos retornar ao projeto no GitLab.

      Visualizando a Execução de CI/CD no GitLab

      De volta ao seu navegador, retorne ao seu projeto no GitLab. Dependendo de quanto tempo passou desde o registro do seu runner, ele pode estar em execução no momento:

      Ou ele já pode ter sido concluído:

      Independentemente do estado, clique no ícone running ou passed (ou failed se você se deparou com um problema) para ver o estado atual da execução da CI. Você pode ter uma visualização semelhante clicando no menu superior Pipelines.

      Você será direcionado para a página de visão geral do pipeline, na qual poderá ver o status da execução do GitLab CI:

      No cabeçalho Stages, haverá um círculo indicando o status de cada um dos estágios da execução. Se você clicar no estágio, poderá ver os jobs individuais associados ao estágio:

      Clique no job install_dependencies dentro do estágio build. Isso o levará para a página de visão geral do job:

      Agora, em vez de exibir uma mensagem de nenhum runner estar disponível, a saída do job é exibida. Em nosso caso, isso significa que você pode ver os resultados do npm instalando cada um dos pacotes.

      Ao longo do lado direito, você pode ver alguns outros itens também. Você pode ver outros jobs alterando o estágio e clicando nas execuções abaixo. Você também pode visualizar ou baixar quaisquer artefatos produzidos pela execução.

      Conclusão

      Neste guia, adicionamos um projeto demonstrativo à instância do Gitlab para mostrar os recursos de integração contínua e de deployment do GitLab CI. Discutimos como definir um pipeline nos arquivos gitlab-ci.yml para construir e testar suas aplicações e como atribuir jobs aos estágios para definir a relação um com o outro. Em seguida, configuramos um runner do GitLab CI para pegar tarefas de CI para nosso projeto e demonstramos como encontrar informações sobre execuções individuais da CI do GitLab.

      Por Justin Ellingwood



      Source link

      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