GitLab Installation, Configuration, and Usage

Preface

Last week I attended the “China Digital Economy Innovation and Development Conference,” then got busy with a new project, so the blog went without updates for a while again. Today is Monday and things are relatively quiet, so I’m starting to write right away—there’s quite a bit worth recording lately~

On to the main topic: we recently set up a GitLab instance and migrated all the project code we’re developing to our self-hosted GitLab. The whole process was fairly smooth~~ (it just uses a lot of memory~~

PS: Immediately ordered four 16G memory sticks for this server to run in quad-channel~

Before this, our team had been using Gitee Enterprise Edition for code management. However, as cybersecurity and information security controls have become increasingly strict, and with the new policies in May tightening control over domestic open-source projects, we decided it would be better to put our code on a more controllable platform.

After comparing Gitea and GitLab, we decided to use GitLab to set up our team’s own code management system.

Getting Started

GitLab has a free open-source Community Edition with enough features. If we need more features later, we can still switch to the Enterprise Edition.

So to make subsequent upgrades convenient, we chose to use the Enterprise Edition image. Without activation it is no different from the Community Edition; if we need to upgrade, we just purchase its subscription and can smoothly upgrade to the Enterprise Edition.

As for the deployment method, in the cloud-native era we of course use Docker~

As usual, I’ll use my favorite Compose to orchestrate the image.

Find a disk with enough space, create a gitlab directory, then create a docker-compose.yml file.

The configuration is as follows

version: "3"
services:
  gitlab:
    image: gitlab/gitlab-ee:latest
    restart: always
    hostname: gitlab
    ports:
      - 1100:80
      - 1101:443
      - 1102:22
    volumes:
      - /etc/localtime:/etc/localtime
      - ./config:/etc/gitlab
      - ./logs:/var/log/gitlab
      - ./data:/var/opt/gitlab

You can define the specific port mapping rules yourself, and the volume mappings can also be changed, but remember that the first /etc/localtime is fixed—it passes the host’s time to the GitLab image.

After saving, run docker-compose up in the directory and it will start up.

First Login

GitLab’s default admin user is root

The password is in the /etc/gitlab/initial_root_password file

You can go inside the container to view it

Optimizing Memory Usage

GitLab’s reputation as a memory hog is well deserved

The server we’re using has 32G of memory. Under the default configuration it kept filling up all the memory; we even frequently ran into various 5xx errors during use, and then we’d look and see only a few hundred MB left……

It really is a memory tiger~

Then I tried various configurations, and after a few days of tinkering, I finally got memory usage down to around 16G

Edit the configuration file. Inside the GitLab container, this file is at /etc/gitlab/gitlab.rb

We mapped it in docker compose earlier, so you can also edit the ./config/gitlab.rb file in the host directory

puma['worker_timeout'] = 30
gitlab_rails['time_zone'] = 'Asia/Shanghai'
puma['worker_processes'] = 2
postgresql['shared_buffers'] = "256MB"
sidekiq['max_concurrency'] = 8
postgresql['max_worker_processes'] = 4
puma['per_worker_max_memory_mb'] = 600
prometheus_monitoring['enable'] = false
sidekiq['min_concurrency'] = 8

After making changes, you need to go into the container and run one of the following commands (reload the configuration or restart GitLab) for the changes to take effect

gitlab-ctl reconfigure
gitlab-ctl restart

Clone URL

Right after starting it up, the clone URL looks like this—that won’t do. You can’t copy it and clone directly to local; it needs to be configured

HTTP domain configuration is relatively simple: go to menu->admin->settings->general->Visibility and access controls->Custom Git clone URL for HTTP(S)

Fill in GitLab’s URL and port number and click save for it to take effect

But HTTP requires logging in, which is too much hassle; we usually use SSH

The SSH URL doesn’t seem configurable from the frontend; you need to edit the configuration file

Still the same configuration file mentioned earlier; edit these two lines to configure the IP address and port respectively

gitlab_rails['gitlab_ssh_host'] = 'ssh.域名或IP地址'
gitlab_rails['gitlab_shell_ssh_port'] = 1102

Just reload the configuration~

external_url Configuration

This URL configuration is involved in several places, such as the jump links in sent emails, the jump links when editing code snippets, etc.~

Still edit it in the configuration file

Find this line, # external_url 'GENERATED_EXTERNAL_URL'

Remove the # comment at the beginning, and change the URL to GitLab’s internal network address http://ip:1100 (we previously mapped 1100 to port 80)

One thing to note is that GitLab will decide the port for providing the web service based on the port in this URL

So if you set this URL, you need to update the port mapping configuration in docker-compose.yml accordingly

For example, if you set 1100 here, then update docker-compose.yml to

ports:
  - 1100:1100

Done~

References

• GitLab Deployment Notes (Docker): https://www.hash070.top/archives/gitlab-withdocker.html
• GitLab Latest Version Limiting Memory Size puma Commands: https://blog.csdn.net/m0_46542378/article/details/125344764
• GitLab Changing Ports and Changing the Prefix of Email Jump Addresses: https://www.52jingya.com/aid4087