GitLab CI/CD Pipeline Configuration. A quick recipe.

Here at 3Metas, our tool for CI/CD is GitLab, this is a quick recipe for configuration of the Pipeline and Job needed.

On our solution, we create a file named .gitlab-ci.yml. On that file we have something similar to this:

image: ruby:2.6.3

stages:
  - deploy

stage_deployment:
  environment: stage
  stage: deploy
  script:
    - which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )
    - eval $(ssh-agent -s)
    # Get the IP Address of the Deployment Runner. 
    - echo $(curl -s https://api.ipify.org)
    # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
    - bundle install --deployment --path vendor/bundle
    # - bundle exec rake db:migrate
    - bundle exec cap stage deploy
  only:
    - stage

What GitLab does is quite simple, this file says that every time that some code is merged into Stage, a few commands will run on the Job, including our already familiar Capistrano deployment command

First, a Docker instance will be created with Ruby 2.6.3, when that Docker Container is ready to go, it will install ssh-agent to allow us to run commands in the actual Stage server, we will connect the GitLab Runner with our server using an SSH Private Key.

Now, this instruction is quite important:

echo “$SSH_PRIVATE_KEY” | tr -d ‘\r’ | ssh-add → /dev/null

It is just a clever way to copy the private key from our GitLab environment to the Docker Container.

The SSH_PRIVATE_KEY variable was defined on the GitLab settings, CI/CD menu, there you will find a Variables option, just expand and add a new variable. The key name is SSH_PRIVATE_KEY and the value is your own private key that allows server login on the deployment target. Make a decision if the variable is protected o no, per GitLab documentation, if the variable is protected only protected branches get access to it. In our case stage is not a protected branch, so we have our variable unprotected.

Of course, we need access from the runner to our stage server, which could be tricky as GitLab runs their runners on a fleet of instances on Google Cloud.

This line,

— echo $(curl -s https://api.ipify.org)

Will put on the console the public IP Address of the runner, then you can add that machine to the security group if you are using AWS or set up any other network rules on your own environment. A quick search online returns all the public IPs of the runners, however, they change from time to time and it breaks the build. We ended creating our own Kubernetes cluster as it allows us to have better control over networking and security.

With this quick recipe, we are able to deploy our APIs multiple times to our stage environment and move even faster than agile on our development process. It is worth to try it.

Originally published on Medium in 3Metas.