Reading time: 5 minutes
Today I’m going to show you how you can self-deploy your project on a remote machine by pulling from a branch called main_release using Gitlab CI/CD.
Generate RSA Key for SSH Connection
The first thing we’re going to do is create an RSA key to allow access to the remote machine using SSH.
To create an SSH private key on Ubuntu, you can follow these steps:
- Open a terminal in Ubuntu.
- Execute the following command to generate the SSH key:
ssh-keygen -t rsa -b 4096
- The above command will create the private and public key in the default directory
~/.ssh/
. You can specify a different path and filename if desired. - When prompted, enter a passphrase to protect your private key.
- The public key will be saved in the file
~/.ssh/id_rsa.pub
. You can view it by executing the following command:
cat ~/.ssh/id_rsa.pub
- Copy the public key and paste it into your GitLab account settings or the
authorized_keys
file on the remote machine you want to connect to via SSH. - Now you can use the private key to connect to the remote machine via SSH.
For example, to connect to the remote machine with the IP address192.168.0.1
, use the following command:
ssh user@192.168.0.1 -i ~/.ssh/id_rsa
Replace user
with the username to connect to the remote machine.
To use the SSH key to log in to Ubuntu, follow these steps:
- Copy your SSH private key (
id_rsa
file) to your local machine. If you don’t have it on your local machine, you can copy it from the remote machine usingscp
:
scp user@remote_host:~/.ssh/id_rsa ~/path/to/local/directory/
Replace user
with your username on the remote machine and remote_host
with the IP address or hostname of the remote machine.
- On your local machine, open a terminal and execute the following command to change the permissions of the private key:
chmod 600 ~/path/to/local/directory/id_rsa
- Then, to log in to the remote machine, execute the following command in your local machine’s terminal:
ssh user@remote_host -i ~/path/to/local/directory/id_rsa
Replace user
with your username on the remote machine and remote_host
with the IP address or hostname of the remote machine.
- If prompted, enter the passphrase for the private key that you set when creating the SSH key.
Once you have successfully logged in to the remote machine using the SSH key, you can execute commands and perform other tasks on the remote machine from your local machine.
Now let’s generate the Gitlab CI/CD file that will handle the self-deployment of the project on the specified machine. It will also connect via SSH using the previously created key and perform a PULL in the specified directory (for this, we need to create an RSA key again and assign it to GITLAB).
Gitlab CI/CD
To generate a .gitlab-ci.yml
file that automatically deploys your code to a remote machine every time you make a pull request to the main branch (main
_release), follow these steps:
- Open your project in GitLab and click on the
Settings
button in the left sidebar. - Select the
CI/CD
option from the dropdown menu and then click onVariables
.
- Add a variable named
SSH_PRIVATE_KEY
and copy the SSH private key that allows you to connect to the remote machine.
- Click the
Add variable
button to save the variable. - Create a
.gitlab-ci.yml
file in the root of your project
Paste the following code:
image: docker:latest services: - docker:dind stages: - deploy deploy: stage: deploy only: - main_release script: - apk add --no-cache openssh-client - eval $(ssh-agent -s) - ssh-add <(echo "$SSH_PRIVATE_KEY") - ssh -o StrictHostKeyChecking=no ageinglab@vps130.cesvima.upm.es "cd html/mgbiomed/ && git remote set-url origin git@gitlab.com:<usuario-proyecto>/<nombre-proyecto>.git && git pull"
- Replace
/path/to/project
with the path to your project on the remote machine and/path/to/deploy
with the directory where you want the code to be deployed. Remember to have the code already deployed on your machine first. - Replace
user@server
with the username and IP address of the remote machine. - Replace
git@gitlab.com:<usuario-proyecto>/<nombre-proyecto>.git
with what appears in the repository of your Gitlab under clone (the one that says SSH):
- Save the
.gitlab-ci.yml
file and push it to your repository. - Every time you make a pull request to the
main
_release branch, GitLab will automatically run thedeploy
job that deploys the code to the remote machine.
RSA Key for Remote Gitlab Pull
In order to perform a remote pull, we need an RSA key from GitLab. To generate it, follow these steps:
Go to your user and select SSH Keys
- Generate a local RSA key:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
This will generate a private key and a public key in the specified path.
- Add the public key to GitLab:
- Copy the content of the public key (
cat ~/.ssh/id_rsa.pub
) to your clipboard. - Open GitLab and navigate to your profile > Settings > SSH Keys.
- Click on “Add SSH Key”.
- Give a name to the key (e.g., “My GitLab SSH Key”).
- Paste the content of the public key into the “Key” field.
- Click “Add Key”.
- Add the private key to your local machine:
- Copy the private key (
cat ~/.ssh/id_rsa
) to a local file (e.g.,gitlab_rsa
). - Restrict permissions for the private key (
chmod 400 gitlab_rsa
) to prevent other users from reading it. - Add the private key to your SSH agent (
ssh-add gitlab_rsa
).
If the ssh-add command didn’t work, you can use this command instead:
sudo ssh-agent sh -c 'ssh-add .ssh/gitlab_rsa'
Now you should be able to pull without entering the username and password each time.
To make the Git repository work with SSH key, use the following command (included in the Pipeline, but you can do it manually and skip this step).
git remote set-url origin git@gitlab.com:<usuario-proyecto>/<nombre-proyecto>.git
If the key doesn’t work, you can rename it to ./.ssh/id_rsa
If the key works with root, you need to copy the key to the directory /root/.ssh/id_rsa
Providing the information from the clone section.
Now, every time you make a pull to the specified branch, a Pipeline will appear and you will be able to see the status of the task.
You will be able to see if they have been executed correctly or where they have failed.