One place for hosting & domains


      Install GitLab on Ubuntu 18.04

      Updated by Linode

      Contributed by


      GitLab is a complete solution for all aspects of your software development life-cycle. At its core, GitLab serves as your centralized Git repository. It also features built-in tools that represent every task in your development workflow, from planning to testing to releasing. You can host your own GitLab instance on a Linode, instead of using third-party hosting. Self-hosting your software development with GitLab offers total control of your codebase while providing an easy to use interface for team members. GitLab is the most popular self-hosted Git repository, so you’ll benefit from a robust set of integrated tools and an active community.

      This guide will walk you through the steps to install GitLab on an 8GB Linode running Ubuntu 18.04. This installation can support up to 100 users.

      System Requirements

      Before installing GitLab you should consider how many users will collaborate on your self-hosted instance, the size of the repositories you will store, and the recommended minimum system requirements. This criteria will will effect the needed storage, CPU, and memory. This guide will use an 8GB Linode plan to fulfill GitLab’s minimum system requirements. The suggested hardware is as follows:

      • Storage The required storage depends on the size of the repositories you will store in GitLab. You should plan to have at least as much free space as all the repositories combined require.
      • CPU: 2 cores is the recommended number and supports up to 500 users. While you can use 1 CPU core to support 100 users, the application may run slower because all workers and background jobs will run on the same core.
      • Memory: 8 GB to support up to 100 users.

      Before You Begin

      1. Familiarize yourself with our Getting Started guide and complete the steps for setting your Linode’s hostname and timezone.

      2. This guide will use sudo wherever possible. Complete the sections of our Securing Your Server to create a standard user account, harden SSH access and remove unnecessary network services.

      3. Add a domain zone, NS record, and A/AAA record for the domain you will use to access your GitLab installation. See the DNS Manager guide for details. If you will access your GitLab instance via your Linode’s IP address, you can skip this step.

      4. Create an SSL Certificate, if you will be using SSL encryption for your domain (this is recommended). Be sure to note the location that Certbot uses to store all generated keys and issued certificates.

      5. Update your system:

        sudo apt-get update && sudo apt-get upgrade

      Install GitLab

      1. Install all required dependencies:

        sudo apt-get install -y curl openssh-server ca-certificates
      2. Install Postfix to send email notifications:

        sudo apt-get install -y postfix

        When prompted, select Internet Site and press Enter. Use your server’s external DNS for mail name and press Enter.

      3. Add the GitLab package repository:

        curl | sudo bash
      4. Install the GitLab package. Replace with the domain you will use to access your GitLab installation. The installation will automatically configure and start GitLab.

        sudo EXTERNAL_URL="" apt-get install gitlab-ee
      5. In your browser of choice, navigate to the URL you provided in the previous step. You will be redirected to GitLab’s password reset screen. You should provide a password for the GitLab administrator account.

        GitLab password reset

      6. You will be redirected to the login screen. Enter root as the username and the password you just created to log in.

        GitLab welcome screen

      Configure SSL Encryption


      If you did not generate an SSL certificate using Certbot prior to the installation of GitLab, you may need to first stop GitLab and then generate the SSL certificate to bypass any errors related to Certbot’s certificate challenge. To stop GitLab run the following command:

        sudo gitlab-ctl stop

      Once you are done generating the certificate, restart GitLab with the following command:

        sudo gitlab-ctl start
      1. Edit the /etc/gitlab/gitlab.rb to use HTTPS. This is done by modifying the value of external_url to use https instead of http:

        ## GitLab URL
        ##! URL on which GitLab will be reachable.
        ##! For more details on configuring external_url see:
        external_url ''
      2. Edit the /etc/gitlab/gitlab.rb file to point to the location of your SSL certificate and key. The path should be the location used by Certbot to store the certificates when they were initially created.

        nginx['ssl_certificate'] = "/etc/letsencrypt/live/"
        nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/"
      3. Redirect all HTTP traffic to HTTPS:

        nginx['redirect_http_to_https'] = true
      4. Issue the following command to enable your new configurations:

        sudo gitlab-ctl reconfigure
      5. Navigate to your GitLab instance domain and verify that you are directed to https.

      You are now ready to begin using GitLab as your remote version control system. Refer to GitLab’s official documentation for details on how to get started administering your GitLab instance.

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

      Install GitLab with Docker

      Updated by Linode

      Contributed by


      GitLab is a free Git repository management application, like GitHub or Bitbucket, that you can run on your own Linode. This guide will show you how to install GitLab using the official GitLab Docker image.

      The GitLab application has a number of services it depends on, including PostgreSQL, Nginx, and Redis. A major benefit of using Docker to install GitLab is that these dependencies are isolated to a single easy-to-update and self-contained image.

      Before You Begin

      Choose An Appropriately Sized Linode

      GitLab is a resource-intensive application. To get the most out of GitLab, we recommend a Linode with at least 8GB of memory and at least 2 CPU cores. For more information on system requirements, visit the GitLab Hardware Requirements page.


      This guide was written for and tested with Ubuntu 18.04. You may be able to adapt this guide to other operating systems supported by Docker. When following this guide under another OS, use the Docker installation instructions for that OS.

      Secure your Server

      Review and implement the measures in the How to Secure your Server guide, including creating a limited user account.

      Change your Linode’s Default SSH Port

      One of GitLab’s features is the ability for you to push and fetch code changes to and from your repository over SSH. When installing GitLab, the software will need to bind to port 22, which is the standard port for SSH. Your system’s SSH service already runs on this port by default, so you will receive an error from GitLab if you don’t address this conflict.

      To fix this, you’ll want to change the port that your system’s SSH service listens on. This can be accomplished by editing your Linode’s /etc/ssh/sshd_config file and changing the Port assignment. The example snippet below changes the port from 22 to port 26:


      When editing the file, you may also need to uncomment the Port line by removing the # character from the start of the line, if one is present. After updating this file and saving the change, restart the SSH service:

      sudo systemctl restart sshd

      Close your current SSH session and create a new one, making sure to specify the new port. You can do this by supplying the -p flag:

      ssh your_limited_user@ -p 26

      (Optional) Update your DNS Records

      Assign a domain or subdomain to your GitLab server. This step is optional, as you can always access GitLab via your server’s IP address. However, using a domain is necessary if you would like to take advantage of GitLab’s built in SSL support, which uses Let’s Encrypt to issue certificates. This guide’s examples will use

      It takes some time for DNS changes to propagate through the internet, so it’s suggested that you do this before you set up GitLab. There are several options for updating your DNS records:

      • If you already use Linode’s name servers, or if you would like to use them for your domain, review the DNS Manager guide. You will need to set up an A record which is assigned your Linode’s IP address.

      • If you use a different DNS provider, review that provider’s documentation for setting up a new A record.

        Updating DNS records at common nameserver authorities

        The following support documents describe how to update DNS records at common nameserver authorities:

      You can test to see if your DNS changes have propagated with the dig command:

      dig +short

      Once your changes have propagated, you can move forward with the installation.

      Install Docker

      You must have Docker installed on your Linode to continue.

      These steps install Docker Community Edition (CE) using the official Ubuntu repositories. To install on another distribution, see the official installation page.

      1. Remove any older installations of Docker that may be on your system:

        sudo apt remove docker docker-engine
      2. Make sure you have the necessary packages to allow the use of Docker’s repository:

        sudo apt install apt-transport-https ca-certificates curl software-properties-common
      3. Add Docker’s GPG key:

        curl -fsSL | sudo apt-key add -
      4. Verify the fingerprint of the GPG key:

        sudo apt-key fingerprint 0EBFCD88

        You should see output similar to the following:

        pub   4096R/0EBFCD88 2017-02-22
                Key fingerprint = 9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
        uid                  Docker Release (CE deb) 
        sub   4096R/F273FCD8 2017-02-22
      5. Add the stable Docker repository:

        sudo add-apt-repository "deb [arch=amd64] $(lsb_release -cs) stable"
      6. Update your package index and install Docker CE:

        sudo apt update
        sudo apt install docker-ce
      7. Add your limited Linux user account to the docker group:

        sudo usermod -aG docker $USER


        After entering the usermod command, you will need to close your SSH session and open a new one for this change to take effect.

      8. Check that the installation was successful by running the built-in “Hello World” program:

        docker run hello-world

      Install the GitLab EE Image

      After installing Docker, download the latest GitLab Enterprise Edition Docker image from DockerHub. This image contains everything GitLab needs in order to run: PostgreSQL, Nginx, Redis, etc. To download the image, run the following pull command:

      sudo docker pull gitlab/gitlab-ee:latest

      Community Edition or Enterprise Edition?

      The GitLab Enterprise Edition software does not actually require you to have a license to use it. If you do not supply a license after installation, it will automatically show you the GitLab Community Edition feature set instead.

      If you’d like, you can instead opt to download GitLab Community Edition. This will offer the same features as an unlicensed Enterprise Edition installation. The key difference between these software packages is that the features of the EE installation can be upgraded at any time by entering a license.

      The primary reason someone might download the Community Edition is if they prefer to only download open source software. For more information on GitLab’s licensing, review the GitLab article on this subject. To download the GitLab CE Docker image, run this command:

      sudo docker pull gitlab/gitlab-ce:latest

      It may take a few minutes to download the image. When the download is complete, you can view a list of all installed Docker images with the images command:

      sudo docker images

      Configure and Run GitLab

      In order to configure and run the GitLab container, you need to provide a few options at runtime.

      1. Consider the following command, a version of which you will use to start the GitLab container:

        sudo docker run --detach 
          --publish 443:443 --publish 80:80 --publish 22:22 
          --name gitlab-linode 
          --restart always 
          --volume /srv/gitlab/config:/etc/gitlab 
          --volume /srv/gitlab/logs:/var/log/gitlab 
          --volume /srv/gitlab/data:/var/opt/gitlab 
          --env GITLAB_OMNIBUS_CONFIG="external_url '';" 

        Descriptions for each option

        --detach runs the Docker container as a background process, as opposed to running it in the foreground.

        --hostname defines the container’s internal hostname.

        --publish tells the container to publish ports, or ranges of ports, to the host. Because GitLab accepts connections on the HTTP (80), HTTPS (443), and SSH (22) ports, this option is declared three times. If you wanted to access GitLab from a non-standard port on your host, you would provide the host port first, and the container port second after the semi-colon. For instance if you wanted to access GitLab SSH on port 3333, you would write --publish 3333:22.

        --name allows you to apply a label to your container, for use when referencing the container within a Docker network.

        --restart specifies a restart policy for the container. Here it is set to always, meaning that the container, if exited, will automatically be restarted.

        --volume defines the host mounted volumes the container uses to store persistent data. These three volumes store application data, log files, and configuration files. The value to the left of the the semi-colon is the local location, and the value to the right is the container location.

        --env supplies the variable GITLAB_OMNIBUS_CONFIG, which can hold a series of values, separated by a colon, that correspond to the GitLab Omnibus configuration settings. In this case, an external URL is supplied. Some additional settings might include SMTP configuration values so that GitLab can send activity emails.

        As of GitLab 10.7, if you provide an external URL with a HTTPS protocol, GitLab will automatically set up SSL certificates using Let’s Encrypt, and all traffic will be forwarded to HTTPS. For more information about this functionality, read the GitLab SSL Documentation

        As an alternative to specifying the GITLAB_OMNIBUS_CONFIG variable via the --env option, you can edit the GitLab configuration file directly. For more instructions on how to do that, visit the Configure GitLab documentation.

      2. In the above command, replace the values for the --hostname option and for the external_url configuration setting with the domain or subdomain for your GitLab site. If you did not set up DNS for your site, enter http://your_linode_ip (not https) for the external_url setting. Then, run the command.


        If you are using the GitLab Community Edition image, replace gitlab/gitlab-ee:latest with gitlab/gitlab-ce:latest

        The container may take a few moments to start. After it starts, you’ll be given a container ID like the following:

      3. It will take an additional few minutes to be able to access GitLab in your browser after the container starts. You can find out more information about the startup process by monitoring the logs:

        sudo docker logs -f gitlab-linode

        To exit from the log monitoring process, enter CTRL-C. This will not stop the container from running.

      4. Load the GitLab site in your web browser. If you try to load it too shortly after starting the container, you may see an HTTP 502 error. If this happens, try waiting for a few more minutes and then refresh your page.

      5. The first time you access the site it will prompt you to enter an administrative password. Enter a complex password and record it somewhere safe.

      6. Log in to your GitLab site by entering root as the user along with the password you created in the previous step.

      Create your First Project

      Each repository in GitLab belongs to a project. A project includes: a repository for your files, an issues tracker, a section for merge requests, a wiki, continuous integration and continuous delivery (CI/CD) pipelines, and other features to support your development.

      1. To create your first repository, click Create a project.

        From the welcome screen, click "Create a project"

      2. You will be taken to the New Project page. Enter the project name. You can optionally alter the project’s slug, enter a description, or change the visibility of the project. Once you’re done, click Create project.

        Fill out the required information to make a new project

      3. Once your project has been created, you’ll be provided with an empty project repository:

        An empty project on GitLab

      4. If you didn’t have GitLab create a file during project setup, instructions on how to start using your repository from the command line will be shown.

        Enter those commands on your computer to add a new to your repository and push it back up to your GitLab repository. Change the domain in the git clone command to your site’s domain:

        git clone
        cd example-project
        touch  # Or create the file in your editor and enter a project description
        git add
        git commit -m "add README"
        git push -u origin master

      Manage the GitLab Container

      To view all of your running containers, you can issue the ps command:

      sudo docker ps

      To stop the GitLab container, issue the stop command by supplying the container ID you procured with the ps command, or supply the container name:

      sudo docker stop gitlab-linode

      To start a stopped container, issue the start command by supplying the container ID or container name:

      sudo docker start gitlab-linode

      Once the container has stopped, you can remove the container using the rm command, again supplying the container ID or container name:

      sudo docker container rm gitlab-linode


      Removing the container will not delete your projects and repositories.

      Upgrading GitLab

      To upgrade GitLab to the newest version, you must stop and remove the container, pull the newest image, and then recreate the container:

      sudo docker stop gitlab-linode
      sudo docker rm gitlab-linode
      sudo docker pull gitlab/gitlab-ee:latest
      sudo docker run --detach 
        --publish 443:443 --publish 80:80 --publish 22:22 
        --name gitlab-linode 
        --restart always 
        --volume /srv/gitlab/config:/etc/gitlab 
        --volume /srv/gitlab/logs:/var/log/gitlab 
        --volume /srv/gitlab/data:/var/opt/gitlab 
        --env GITLAB_OMNIBUS_CONFIG="external_url '';" 

      Remember to provide your own hostname, name, and external URL. If you are using GitLab Community Edition, specify the gitlab/gitlab-ce:latest image instead.

      Next Steps

      GitLab offers many features that are worth taking the time to understand and utilize. Here are a few next steps to take after you’ve completed this guide:

      • Upload an SSH key to your GitLab account so that you can transfer files over SSH.

      • Explore CI/CD pipelines to streamline your development practices.

      • Using your root GitLab account, explore the Admin settings to customize the functionality of GitLab.

      • Review Linode’s Git documentation:

      More Information

      You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

      Find answers, ask questions, and help others.

      This guide is published under a CC BY-ND 4.0 license.

      Source link

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


      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.


      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:

      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:


      image: node:latest
        - build
        - test
          - node_modules/
        stage: build
          - npm install
            - node_modules/
        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:

        - 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:

          - 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:

        stage: build
          - npm install
            - 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:

        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 -o /tmp/

      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/

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

      • sudo bash /tmp/

      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.

      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:


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

      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.


      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