Neste artigo, vamos abordar os códigos necessários para a construção e implantação de uma aplicação usando o GitLab CI/CD. Assim exploraremos os estágios de construção, construção do container Docker, implantação e externalização. Dessa forma esses estágios são essenciais para garantir um processo de desenvolvimento e implantação suave e automatizado. Vamos detalhar cada parte dos processos para que você possa entender como eles se encaixam e como aplicar as práticas recomendadas.

Pré-requisitos

Antes de prosseguirmos, é importante ter alguns pré-requisitos em mente:

• Um ambiente GitLab CI/CD configurado e funcionando corretamente.
• Acesso a um servidor remoto para implantação da aplicação.
• Conhecimento básico de Docker e Dockerfile.

Estágio de construção (build)

No estágio de construção, configuramos o ambiente de desenvolvimento. Sendo assim veja o código abaixo:

build:
  stage: build
  image: node:14
  services:
    - docker:dind
  script:
    - npm ci
    - mkdir -p ~/.ssh
    - ssh-keyscan $SSH_HOST >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  artifacts:
    paths:
      - package*.json
      - ~/.ssh

Explicação detalhada:

• image: node:14 define a imagem Docker que será usada para construir a aplicação. Neste caso, estamos usando a imagem do Node.js na versão 14.
• services: - docker:dind indica que precisamos do serviço Docker para criar um ambiente Dockerizado durante o estágio de construção.
• script é onde definimos os comandos que serão executados durante o estágio. Neste exemplo, usamos os seguintes comandos:
• npm ci para instalar as dependências do projeto.
• mkdir -p ~/.ssh para criar o diretório ~/.ssh caso ele não exista.
• ssh-keyscan $SSH_HOST >> ~/.ssh/known_hosts para adicionar a chave de host SSH do servidor remoto ao arquivo known_hosts dentro do diretório ~/.ssh.
• chmod 644 ~/.ssh/known_hosts para definir as permissões corretas no arquivo known_hosts.
• artifacts é usado para especificar os arquivos que serão salvos como artefatos e estarão disponíveis para os estágios subsequentes. Neste exemplo, estamos salvando os arquivos package*.json e o diretório ~/.ssh.

Estágio de construção do container Docker (docker-build)

No estágio “docker-build”, Em seguida vamos construir o container Docker da nossa aplicação. Sendo assim veja o código abaixo:

docker-build:
  stage: build
  image: docker:stable


  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2375
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - rm -rf .git
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -f Dockerfile .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  needs:
    - build

Explicação detalhada:

• image: docker:stable define a imagem Docker que será usada para construir o container Docker da aplicação.
• services: - docker:dind indica que precisamos do serviço Docker para criar um ambiente Dockerizado durante o estágio de construção do container Docker.
• variables são usadas para definir variáveis específicas do ambiente de execução do GitLab CI/CD. Neste caso, estamos definindo a variável DOCKER_HOST para apontar para o serviço Docker.
• before_script é onde definimos os comandos a serem executados antes do script principal. Neste exemplo, usamos docker login para autenticar no registro de imagens Docker configurado.
• script é onde definimos os comandos principais a serem executados durante o estágio. Neste caso, os comandos são:
• rm -rf .git para remover o diretório .git antes de construir a imagem Docker.
• docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA -f Dockerfile . para construir a imagem Docker a partir do Dockerfile presente no diretório atual (.).
• docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA para enviar a imagem Docker construída para o registro de imagens Docker configurado.
• needs: - build indica que este estágio precisa do estágio “build” para ser executado antes dele.

Estágio de implantação (deploy)

No estágio “deploy”, Em seguida vamos implantar a aplicação no servidor remoto. Sendo assim confira o código abaixo:

deploy:
  stage: deploy
  image: ubuntu:latest
  before_script:
    - apt-get update
    - apt-get install -y openssh-client
  script:
    - mkdir -p ~/.ssh
    - ssh-keyscan $SSH_HOST >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa

    - ssh root@$SSH_HOST "docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY && docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
    - ssh root@$SSH_HOST "docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA marketing-app-site:$CI_COMMIT_SHORT_SHA  &&  docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA marketing-app-site:latest"
    - ssh root@$SSH_HOST "docker rm -f marketing-app-site || true && docker run -d --name marketing-app-site --restart always marketing-app-site"
  only:
    - master
  needs:
    - docker-build

Explicação detalhada:

• image: ubuntu:latest define a imagem Docker que será usada para executar os comandos relacionados à implantação da aplicação.
• before_script é onde definimos os comandos a serem executados antes do script principal. Neste exemplo, usamos apt-get para atualizar os pacotes e instalar o cliente SSH.

• script é onde definimos os comandos principais a serem executados durante o estágio. Aqui estão os comandos executados no servidor remoto:
• mkdir -p ~/.ssh para criar o diretório ~/.ssh caso ele não exista.
• ssh-keyscan $SSH_HOST >> ~/.ssh/known_hosts para adicionar a chave de host SSH do servidor remoto ao arquivo known_hosts dentro do diretório ~/.ssh.
• chmod 644 ~/.ssh/known_hosts para definir as permissões corretas no arquivo known_hosts.
• echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa para armazenar a chave SSH privada no arquivo id_rsa dentro do diretório ~/.ssh.
• chmod 600 ~/.ssh/id_rsa para definir as permissões corretas no arquivo id_rsa.
• ssh root@$SSH_HOST "docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY && docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" para autenticar no registro de imagens Docker e puxar a imagem Docker do registro para o servidor remoto.
• ssh root@$SSH_HOST "docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA marketing-app-site:$CI_COMMIT_SHORT_SHA && docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA marketing-app-site:latest" para criar tags para a imagem Docker puxada, usando o hash do commit atual.
• ssh root@$SSH_HOST "docker rm -f marketing-app-site || true && docker run -d --name marketing-app-site --restart always marketing-app-site" para remover o contêiner anterior da aplicação (se existir) e iniciar um novo contêiner Docker com a imagem atualizada.
• only: - master especifica que este estágio será executado apenas quando o pipeline for executado no branch “master”.
• needs: - docker-build indica que este estágio precisa do estágio “docker-build” para ser executado antes dele.

Estágio de externalização (externalize)

No estágio “externalize”,Em seguida configuramos a conexão da aplicação com o Nginx. Por fim veja o código abaixo:

externalize:
  stage: deploy
  image: ubuntu:latest
  before_script:
    - apt-get update
    - apt-get install -y openssh-client
  script:
    - mkdir -p ~/.ssh
    - ssh-keyscan $SSH_HOST >> ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
    - echo "$SSH_PRIVATE_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh root@$SSH_HOST "docker network connect nginx-manager_default marketing-app-site"
  only:
    - master
  needs:
    - deploy

Explicação detalhada:

• Este estágio é semelhante ao estágio de implantação, mas aqui estamos configurando a conexão da aplicação com o Nginx.
• Os comandos executados no servidor remoto são:
• docker network connect para conectar o contêiner da aplicação à rede do Nginx.
• only: - master especifica que este estágio será executado apenas quando o pipeline for executado no branch “master”.
• needs: - deploy indicará que este estágio precisa do estágio “deploy”, para ser executado antes dele.

Conclusão

Neste artigo, Em síntese exploramos os estágios de construção, construção do container Docker, implantação e externalização usando o GitLab CI/CD. Assim cobrimos os pré-requisitos necessários, explicamos cada parte dos processos e fornecemos exemplos completos de código para referência. Portanto seguindo essas práticas recomendadas, você poderá automatizar e simplificar o processo de desenvolvimento e implantação de sua aplicação. Em conclusão esperamos que este artigo tenha sido útil para você implementar o GitLab CI/CD em seus projetos.