GitLab Inc. offers a product that is a tool for the full DevOps cycle. On the manufacturer's website, we read that it can be both part of the software delivery chain, and it can be a whole. However, it should be remembered that it is primarily intended to store the source code of the applications we create. It is in it that their greatest value is contained. Is a local GitLab installation a good alternative to GitHub? What are its advantages and disadvantages and how to conduct it?
Introduction to GitLab
GitLab code repository is currently based on the most well-known version control system - Git. The product contains everything that every SVN should have. The choice between it and e.g. GitHub or BitBucket is not only related to usability, but also to what is equally important: maintenance costs, additional functionalities and security. If you want to increase the security of your stored code and develop it in a limited environment, you should consider installing GitLab in your own infrastructure. This will allow you to avoid the currently fashionable cloud, because, as we know, what is its advantage, can also be a disadvantage.
GitLab Licensing
There are several alternative platforms on the market, such as GitHub or BitBucket, but only GitLab's Community Edition allows free installation on your own server (this version is not a trial, but a fully functional version). It includes many of the options available in the paid GitLab plan and offers a number of possibilities for the user.
It is worth noting that using the free version does not limit you in any way - you can switch to the paid plan at any time. It is very beneficial for start-ups and enterprises which find it difficult to predict which functionalities they will need most at the beginning.
Meet LSB DATA Software House
Installing GitLab on your own server
GitLab Inc. has made it very easy to install the system on your own server. The first step is to decide whether it should be carried out on a dedicated virtual machine, or whether you will use cloud solutions (AWS, Google Cloud) or those in the form of containers via Kubernetes or Docker. There are many ready-made installation packages for Ubuntu Server, Debian, CentOS, OpenSUSE and Raspberry Pi (!). It is hard to imagine a situation in which our administrator will not find a suitable environment to install the system. We recommend setting up a virtual machine on Debian 10.
Preparation for installation
- disk space: officially it is not stated explicitly, but it is safest to accept a minimum of 50 GB for data storage (it depends, of course, on the capacity of our projects),
- number of cores: 4 cores. This is the recommended number of CPU cores assigned to a virtual machine. As stated on the official website, this is enough to support up to 500 users,
- RAM: 4 GB. This is the minimum amount of memory that we need to allocate to service up to 500 users. As you know, more memory can only positively affect the operation of the system.
If you use ready-made installers, do not worry about the version of the PostgreSQL database and its extensions.
Starting the installation
Stage 1: installation of updates and dependencies on our server.
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates perlStage 2 (optional): installation of the Postfix mail system for sending notifications (if we want to use another existing MTA system, this step can be skipped).
sudo apt-get install -y postfixStage 3: adding an official repository to the system and preparing for installation.
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bashStep 4: host configuration and start installation.
Please note that the selected domain must correctly point to our server, even if it is local. Therefore, it is a good idea to check correct name resolution and communication with the local DNS server before installation. If the domain is an external domain and we set the HTTPS protocol, GitLab will try to automatically generate and download the Let's Encrypt certificate. In further configuration, it is possible to install your own certificate - we strongly recommend this option.
sudo EXTERNAL_URL="https://gitlab.lsbdata.com" apt-get install gitlab-eeFirst connection
After correct installation on the server, connect via the browser. The first time you connect, you can set an administrator password. "Root" is used as the default login after installation. In the next step, you need to configure communication, authorization mechanisms and appearance.
Embedding CI / CD GitLab
Continuous Integration (CI) and Continuous Delivery (CD) are very important functions in the full software delivery chain. The GitLab system includes a function called GitLab Runners. It is a communication mechanism with systems that will execute specific commands for a given repository. One of the biggest advantages of GitLab Runners is the fact that the configuration of actions taken by these systems is stored directly in the code repository in the project. So it is not difficult to imagine that each change in the steps to be made within the CI / CD is introduced through the GIT repository mechanism. What do we gain from this? For example, the history of changes, the possibility of code review, etc.
What are GitLab Runners?
GitLab Runners to zewnętrzne systemy – agenci, których zadaniem jest wykonanie wskazanego kodu w ramach wydzielonego obszaru roboczego niezależnie od innych projektów. Każdy GitLab Runner to osobna maszyna wirtualna lub kontener Docker uruchomiony oraz autoryzowany na naszym serwerze GitLab. Autoryzacja wykonywana jest przez administratora GitLab na poziomie serwera, a do danego serwera możemy podłączyć wielu agentów. W przypadku większych projektów lub specyficznych wymagań możliwe jest przypisanie poszczególnego agenta do wybranych projektów.
Installation of GitLab Runner on a Docker container
If you do not have experience with preparing GitLab Runner configurations, it is a good idea to choose the option of preparing a container along with creating a volume with its configuration:
docker volume create gitlab-runner-configThen we run the container using the official image and point to the named volume:
docker run -d --name gitlab-runner --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v gitlab-runner-config:/etc/gitlab-runner \
gitlab/gitlab-runner:latestThe next step is to register the Runner on our GitLab server. To do this, you can use the command:
docker run --rm -it -v gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest registerAfter starting the registration, please follow the prompts. Make sure our container is communicating with the server before we start registering it.
Start with CI / CD in GitLab
First, create a .gitlab-ci.yml file in the repository - it will contain all the steps and processes that will occur during the operation on GitLab Runner. Below is an example of the content of the .gitlab-ci.yml file:
build-job:
stage: build
before_script:
- echo "Execute this command before any `script:` commands."
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
test-job1:
stage: test
script:
- echo "This job tests something"
test-job2:
stage: test
script:
- echo "This job tests something, but takes more time than test-job1."
- echo "After the echo commands complete, it runs the sleep command for 20 seconds"
- echo "which simulates a test that runs 20 seconds longer than test-job1"
- sleep 20
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."As you can see, it is a standard YAML file.
Its basic syntax is:
- task name,
- stage - the stage at which the task is to be performed,
- script - commands to be executed during the given task.
In the case of our installation, there was a need to prepare the agent before taking appropriate actions, so the "before_script" option became an important point in the file. Thanks to it, we can define commands to be executed before individual commands. What does this give us?
- Software Developer from the repository can install the necessary software package on GitLab Runner before performing tasks within the CI / CD without being authorized to do so.
- This allows for a one-time transfer of the key for authorization on the server of a given application. Please note that the official GitLab Runner is a simple system with only basic tools, so this feature allows you to customize it without any administrator intervention.
Advantages of a local GitLab installation
The main advantage of your own GitLab installation is increased security and control over the entire environment. In the case of a local installation, it is most often performed in the company's local network. Here are its advantages:
- connection from the outside only via a VPN connection (thanks to this we already have a kind of double user authorization),
- blocking connections with external services / systems, and thus limited data leakage,
- data storage security - they are stored in our infrastructure, which is not shared and managed by an external company,
- additional methods of authorization through internal IT systems, eg Active Directory or LDAP (very convenient for large enterprises), the use of SSO (Single Sign-on), central authorization management.
Are you starting new project? Looking for software house?
Disadvantages of local GitLab installation
If your own installation had only advantages, GitLab would not offer SaaS solutions. Therefore, it is worth mentioning that own installation, even in the free version, is not entirely without cost. When choosing this form of installation, it should be taken into account that we are responsible for:
- provision of infrastructure,
- creating and testing system backups,
- ensuring ongoing maintenance - i.e. updates, problem solving,
- providing support to users (at least in the first line),
- obligation to repair or restore the environment in the event of a failure.
The above potential disadvantages are of course relative, because companies that need systems such as GitLab often already have the appropriate infrastructure and qualified employees. The decision to choose the form of using GitLab depends on the specific situation of a given group of users.
Have an idea? Let's talk
