GitLab Server o'rnatish va sozlash

Kirish

Tasavvur qiling: kompaniyangizda 10 ta dasturchi ishlaydi, loyiha kodi maxfiy — tashqi cloud service'larga qo'yish mumkin emas. Yoki bankda ishlaysiz — regulator kodning O'zbekiston hududidagi serverlarda saqlanishini talab qiladi. Yoki oddiy holat — GitHub/GitLab.com'da bepul private repo limiti bor, serveringiz esa bepul va cheksiz.

GitLab (opens in a new tab) aynan shu muammolarni hal qiladi. Bu open-source DevOps platforma — source code management, CI/CD, project management hammasi bitta joyda. Eng muhimi — uni o'z serveringizga o'rnatib olishingiz mumkin.

Real hayotdan misollar — qachon self-hosted GitLab kerak:

Fintech/Bank — regulator talabi: kod va ma'lumotlar mamlakat ichida saqlanishi shart
Davlat tashkilotlari — maxfiy loyihalar, internet cheklangan tarmoqlar
O'rta/katta kompaniyalar — 50+ dasturchi, GitHub Enterprise juda qimmat ($21/user/oy), GitLab self-hosted bepul
Startaplar — byudjet cheklangan, lekin professional DevOps workflow kerak
Outsource kompaniyalar — har bir mijoz uchun alohida group/permission sozlash kerak

Ushbu qo'llanmada GitLab serverni noldan o'rnatamiz, production darajasida sozlaymiz, Runner ullab real CI/CD pipeline ishga tushiramiz.

GitLab qanday ishlaydi?

GitLab o'rnatilganda serverda bir nechta service birgalikda ishga tushadi. Ularning har biri o'z vazifasini bajaradi:

+-------------------------------------------------------------------+
|                        GITLAB SERVER                              |
|                                                                   |
|  +----------+    +-----------+    +------------+    +-----------+ |
|  |          |    |           |    |            |    |           | |
|  |  Nginx   |--->| Workhorse |--->|    Puma    |--->|  Sidekiq  | |
|  | (Proxy)  |    | (Fayllar) |    |  (Asosiy   |    | (Fon      | |
|  |          |    |           |    |   ilova)   |    |  ishlar)  | |
|  +----------+    +-----------+    +------+-----+    +-----------+ |
|                                         |                         |
|                  +----------------------+----+                    |
|                  |                      |    |                    |
|           +------+-----+    +----------+-+  +-------+------+     |
|           |            |    |            |  |              |     |
|           | PostgreSQL |    |   Redis    |  |    Gitaly    |     |
|           |   (DB)     |    |  (Cache)   |  | (Git repos)  |     |
|           |            |    |            |  |              |     |
|           +------------+    +------------+  +--------------+     |
|                                                                   |
+-------------------------------------------------------------------+

Qisqacha:

Nginx — brauzerdan kelgan so'rovlarni qabul qiladi va to'g'ri joyga yo'naltiradi
Workhorse — katta fayllar bilan ishlaydi (upload/download), Puma'ni yuklamaslik uchun
Puma — GitLab'ning asosiy ilovasi. Web interfeys, API, login — hammasi shu yerda
Sidekiq — fon ishlarini bajaradi: email yuborish, webhook, pipeline yaratish
PostgreSQL — barcha ma'lumotlar saqlanadigan database
Redis — kesh va session boshqaruvi
Gitaly — Git repositorylar bilan ishlaydigan service

Bu komponentlarning hammasini siz alohida o'rnatmaysiz — GitLab Omnibus paketi hammasini avtomatik o'rnatib sozlab beradi. Shuning uchun alohida Nginx, PostgreSQL yoki Redis o'rnatish shart emas.

GitLab CE yoki EE — qaysi birini tanlash kerak?

GitLab ikki versiyada chiqadi. Farqi quyidagicha:

	GitLab CE (Community Edition)	GitLab EE (Enterprise Edition)
Narxi	Bepul, open-source	Bepul (core) + pullik rejalar
CI/CD	To'liq ishlaydi	Qo'shimcha: merge trains, multi-project pipelines
Xavfsizlik	Asosiy funksiyalar	SAST, DAST, dependency scanning
Qo'llab-quvvatlash	Faqat community	Rasmiy texnik support
Kimga mos	Kichik jamoalar, shaxsiy loyihalar	Katta tashkilotlar, korxonalar

Qaysi birini o'rnatish kerak? Agar kelajakda pullik funksiyalar kerak bo'lishi mumkin deb o'ylasangiz — GitLab EE o'rnating. Bepul rejada CE bilan deyarli bir xil ishlaydi, lekin kerak bo'lganda pullik funksiyalarni yoqib olish imkoniyati qoladi. Aksariyat hollarda EE tavsiya etiladi.

O'rnatish usullari

GitLab'ni bir necha xil usulda o'rnatish mumkin:

Usul	Tavsif	Qachon ishlatiladi
Linux paketi (Omnibus)	VM yoki bare-metal serverga to'g'ridan-to'g'ri o'rnatish	Eng keng tarqalgan, production uchun tavsiya etiladi
Docker	Docker container ichida ishga tushirish	Tez sinab ko'rish, kichik jamoalar uchun
Kubernetes (Helm chart)	K8s clusterga deploy qilish	Katta tashkilotlar, auto-scaling kerak bo'lganda
Source'dan	Kodni o'zingiz compile qilish	Faqat maxsus holatlar uchun, tavsiya etilmaydi

Biz ushbu qo'llanmada Linux paketi (Omnibus) usulidan foydalanamiz — Ubuntu VMga o'rnatamiz. Bu eng ko'p ishlatiladigan va GitLab tomonidan rasman tavsiya etiladigan usul. Barcha componentlar (Nginx, PostgreSQL, Redis va boshqalar) bitta paket ichida keladi.

Ishni boshlash

Server talablari

Minimum Server talablari

Host	OS	RAM	CPU	Xotira	Static IP
gitlab	Ubuntu 20.04+	8GB	4 vCPU, 2 core	80GB	Ha, kerak

8GB RAM — bu 500 tagacha foydalanuvchi uchun yetarli. Agar jamoangiz kattaroq bo'lsa, 16GB yoki undan ko'p RAM tavsiya etiladi. Disk hajmi esa repositorylar soniga qarab o'sadi.

DNS sozlash

GitLab server uchun domen kerak — biz shu domen orqali brauzerdan GitLab'ga kiramiz va Git operatsiyalarini bajaramiz.

DNS hostingizdan domenga (yoki subdomenga) GitLab server IP manzilini ko'rsatishingiz kerak. Quyida ahost.uz (opens in a new tab) uchun namuna:

Domen sozlamalaridan DNS xosting bo'limiga o'ting:

Bizda helm.uz (opens in a new tab) domeni bor. Unga gitlab subdomenini qo'shamiz:

Name -> gitlab (subdomen nomi)
Type -> A
TTL -> 14400
RDATA -> GitLab server Static IP manzili

GitLab o'rnatish

DNS sozlab bo'lgach, o'rnatishni boshlaymiz.

1-> Serverni yangilaymiz va kerakli paketlarni o'rnatamiz.

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl openssh-server ca-certificates tzdata perl

2-> Email notifikatsiyalar uchun Postfix o'rnatamiz. GitLab foydalanuvchilarga xabar yuborish uchun mail server ishlatadi.

sudo apt install -y postfix

O'rnatish vaqtida konfiguratsiya oynasi chiqadi:

Birinchi oynada "Internet Site" ni tanlang
Ikkinchi oynada serveringiz domenini yozing (masalan, gitlab.helm.uz)

3-> GitLab'ni o'rnatamiz. CE yoki EE — qaysi birini tanlaysiz, shunga mos tabni bosing:

GitLab CE
GitLab EE

GitLab CE repositoryni qo'shamiz va o'rnatamiz:

curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

EXTERNAL_URL ga o'zingizning domeningizni yozing:

sudo EXTERNAL_URL="https://gitlab.helm.uz" apt install gitlab-ce

Muvaffaqiyatli o'rnatilganda quyidagi natija chiqadi:

O'rnatish 5-10 daqiqa vaqt olishi mumkin. Tugagach konsolda admin parol haqida xabar chiqadi — root foydalanuvchining paroli /etc/gitlab/initial_root_password faylida saqlanadi. Bu fayl 24 soatdan keyin avtomatik o'chiriladi, shuning uchun parolni darhol ko'chirib oling!

4-> Brauzerdan domeningizni oching (bizda gitlab.helm.uz). Login sahifasi ochilishi kerak.

root username bilan kiring. Parolni quyidagi buyruq bilan oling:

sudo cat /etc/gitlab/initial_root_password

Admin panel: gitlab.helm.uz/admin — bu yerda server haqida umumiy ma'lumotlarni ko'rishingiz mumkin.

GitLab Server sozlash

GitLab o'rnatildi, endi ishlatishdan oldin bir nechta muhim sozlashlarni qilib olishimiz kerak.

1. Admin parolini o'zgartirish

Hozir root username va avtomatik generatsiya qilingan parol bilan kirganmiz. Bularni o'zgartiramiz.

Profilga o'ting → Edit profile → Account bo'limi:

root o'rniga o'zingizning username'ingizni yozing va Update username bosing:

Password bo'limiga o'tib yangi parol o'rnating:

Saqlangandan keyin login sahifasiga qaytarilasiz — yangi ma'lumotlar bilan kiring:

2. Ochiq registratsiyani yopish

Default holatda GitLab'ga har kim ro'yxatdan o'ta oladi — login sahifasida Register now tugmasi bor. Bu xavfli, chunki begona odamlar ham serveringizga kirib olishi mumkin.

Buni o'chirish uchun:

Admin Area ga o'ting:

General → Sign-up restrictions bo'limini toping:

Sign-up enabled checkboxini olib tashlang va saqlang:

Endi foydalanuvchilarni faqat admin o'zi yarata oladi.

3. SSL sertifikatni avtomatik yangilash

GitLab o'rnatilganda Let's Encrypt orqali SSL sertifikat avtomatik olinadi. Lekin sertifikatni har 90 kunda yangilash kerak. Buni avtomatik qilish uchun:

sudo nano /etc/gitlab/gitlab.rb

Quyidagi qatorlarni toping va izohdan chiqaring (yoki qo'shing):

# /etc/gitlab/gitlab.rb
 
letsencrypt['auto_renew'] = true
letsencrypt['auto_renew_hour'] = "12"
letsencrypt['auto_renew_minute'] = "30"
letsencrypt['auto_renew_day_of_month'] = "*/7"
letsencrypt['auto_renew_log_directory'] = '/var/log/gitlab/lets-encrypt'

Bu sozlama har 7 kunda soat 12:30 da sertifikatni tekshiradi va kerak bo'lsa yangilaydi.

O'zgarishlarni qo'llaymiz:

sudo gitlab-ctl reconfigure

4. Production uchun GitLab sozlash (gitlab.rb tuning)

Default sozlamalar kichik jamoalar uchun yetarli, lekin 20+ foydalanuvchi bo'lsa yoki server resurslarini tejash kerak bo'lsa, gitlab.rb faylini optimizatsiya qilish kerak.

sudo nano /etc/gitlab/gitlab.rb

# /etc/gitlab/gitlab.rb — Production tuning
 
# Puma worker soni — har bir worker ~1GB RAM oladi
# Formula: CPU core soni + 1, lekin RAM ga qarab kamaytiring
# 8GB RAM, 4 CPU uchun:
puma['worker_processes'] = 4
 
# Sidekiq — fon ishlarini bajaradigan worker
# Default 1 ta, ko'p foydalanuvchi bo'lsa 2-3 ga oshiring
sidekiq['max_concurrency'] = 20
 
# PostgreSQL — shared_buffers RAM ning 25% bo'lishi tavsiya etiladi
# 8GB server uchun:
postgresql['shared_buffers'] = "2048MB"
 
# Monitoring — Prometheus va Grafana
# gitlab.helm.uz/-/grafana orqali server holatini kuzating
prometheus_monitoring['enable'] = true
grafana['enable'] = true
 
# Container Registry — Docker image saqlash uchun
# gitlab.helm.uz:5050 orqali ishlatiladi
registry_external_url 'https://gitlab.helm.uz:5050'
 
# Backup sozlamalari
gitlab_rails['backup_keep_time'] = 604800  # 7 kun (soniyada)

RAM hisoblash formulasi: GitLab o'zi ~4GB RAM ishlatadi. Har bir Puma worker +700MB, har bir Sidekiq worker +1GB. 8GB RAM serverda 4 ta Puma worker va 1 ta Sidekiq — bu chegaraga yaqin. Agar serverda boshqa service'lar ham ishlayotgan bo'lsa, worker sonini kamaytiring.

O'zgarishlarni qo'llaymiz:

sudo gitlab-ctl reconfigure

5. Group va Repository yaratish

GitLab'da loyihalarni gruppalash mumkin. Masalan, DevOps nomli group ochib, unga tegishli barcha repositorylarni joylashtirish qulay:

Guruh ichida yangi repository yaratamiz:

Local kompyuterdan loyihani push qilamiz:

GitLab Runner o'rnatish

GitLab'ning o'zi CI/CD pipelinelarni yaratadi, lekin ularni bajaradigan alohida agent kerak — bu GitLab Runner. Runner pipeline'dagi har bir job'ni oladi va bajaradi: kod build qilish, testlarni ishga tushirish, deploy qilish.

Runner turlari

+------------------------------------------------------------------+
|                      GITLAB SERVER                                |
|                                                                   |
|   +-------------------+     +-------------------+                 |
|   |    Project A      |     |    Project B      |                 |
|   +--------+----------+     +--------+----------+                 |
|            |                         |                            |
+------------------------------------------------------------------+
             |                         |
    +--------v----------+    +---------v---------+
    |  Shared Runner    |    | Specific Runner   |
    |  (Barcha loyihalar |    | (Faqat bitta      |
    |   uchun umumiy)   |    |  loyiha uchun)    |
    +--------+----------+    +---------+---------+
             |                         |
    +--------v----------+    +---------v---------+
    |   Docker          |    |   Shell            |
    |   Executor        |    |   Executor         |
    +-------------------+    +--------------------+

Shared Runner — barcha loyihalarga xizmat qiladi. Umumiy build/test vazifalar uchun qulay
Specific Runner — faqat bitta loyiha yoki guruhga biriktiriladi. Maxsus muhit kerak bo'lganda ishlatiladi

Executor — Runner job'ni qayerda bajaradi:

Docker executor — har bir job uchun yangi Docker container yaratiladi (izolyatsiya yaxshi, tavsiya etiladi)
Shell executor — job'lar to'g'ridan-to'g'ri serverning o'zida ishlaydi (oddiy, lekin xavfli)

Runner o'rnatish

1-> GitLab Admin Area'dan runner yaratamiz: Admin Area → CI/CD → Runners → New instance runner

Runner uchun tag va sozlamalarni belgilang:

GitLab sizga token va ro'yxatdan o'tkazish buyrug'ini ko'rsatadi:

2-> Endi serverga o'tib GitLab Runner o'rnatamiz:

# Binary faylni yuklab olamiz
sudo curl -L --output /usr/local/bin/gitlab-runner \
  https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
 
# Ishga tushirish ruxsatini beramiz
sudo chmod +x /usr/local/bin/gitlab-runner
 
# GitLab Runner uchun alohida user yaratamiz
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
 
# Service sifatida o'rnatib ishga tushiramiz
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

3-> Biz Docker executor ishlatmoqchimiz, shuning uchun serverda Docker ham o'rnatilgan bo'lishi kerak. Linux serverlarga Docker o'rnatish (opens in a new tab) qo'llanmasidan foydalaning.

4-> Runner'ni GitLab'ga ulaymiz. GitLab bergan token bilan:

gitlab-runner register \
  --url https://gitlab.helm.uz \
  --token glrt-xxxxxxxxxxxxxxxxxxxx

Ro'yxatdan o'tish jarayonida bir nechta savol so'raladi:

Runner name: runner1 — bu faqat identifikatsiya uchun, xohlagan nomni yozing

Executor: docker — Docker container ichida job'larni bajarish uchun

Default Docker image: ubuntu:latest — agar .gitlab-ci.yml da image ko'rsatilmasa, shu ishlatiladi

5-> Runner'ni ishga tushiramiz:

sudo gitlab-runner run

GitLab'dan View runner bosib tekshiring — yashil holat ko'rsatishi kerak:

Runner konfiguratsiyasi

Runner ro'yxatdan o'tgach, config.toml faylida sozlamalarni ko'rib chiqamiz:

sudo nano /etc/gitlab-runner/config.toml

# /etc/gitlab-runner/config.toml
 
concurrent = 4          # Bir vaqtda nechta job bajarishi mumkin
check_interval = 0      # GitLab'dan yangi job'lar uchun so'rov intervali (0 = default 3s)
shutdown_timeout = 0    # Shutdown oldidan kutish vaqti
 
[session_server]
  session_timeout = 1800  # Interactive web terminal uchun timeout (soniya)
 
[[runners]]
  name = "runner1"
  url = "https://gitlab.helm.uz/"
  token = "glrt-xxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "ubuntu:latest"        # Default Docker image
    privileged = true              # Docker-in-Docker uchun kerak
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]           # Job'lar orasida kesh saqlash
    shm_size = 0

privileged = true haqida: Bu Docker-in-Docker (ya'ni Docker ichida Docker) ishlashi uchun kerak. Masalan, CI pipeline ichida Docker image build qilmoqchi bo'lsangiz. Lekin bu xavfli — container host serverga to'liq kirish huquqiga ega bo'ladi. Agar Docker build kerak bo'lmasa, privileged = false qo'ying.

Runner'ga Docker ishlatish ruxsatini beramiz:

sudo usermod -aG docker gitlab-runner

O'zgarishlar kuchga kirishi uchun restart:

sudo gitlab-runner restart

Birinchi CI/CD Pipeline

Hammasi tayyor — GitLab o'rnatildi, sozlandi, Runner ulandi. Endi birinchi pipeline'ni ishga tushiramiz.

CI/CD qanday ishlaydi?

+----------+     +-----------+     +------------+     +----------+
|          |     |           |     |            |     |          |
|   Dev    |---->|   GitLab  |---->|   GitLab   |---->|  Natija  |
| (git push)|    |  (pipeline |    |   Runner   |     | (pass/   |
|          |     |   yaratadi)|    | (job bajara-|    |   fail)  |
+----------+     +-----------+     |    di)     |     +----------+
                      |            +------------+
                      |                  |
                      |   .gitlab-ci.yml |
                      +------------------+

Dasturchi kodini o'zgartirib git push qiladi
GitLab repository'da .gitlab-ci.yml faylini topadi va pipeline yaratadi
Runner job'ni oladi va Docker container ichida bajaradi
Natija (muvaffaqiyat yoki xatolik) GitLab interfeysida ko'rinadi

Pipeline yozish

Repository'ning root papkasiga .gitlab-ci.yml fayl yaratamiz. Quyida ikkita real misol — oddiy va production darajasida:

Oddiy pipeline — faqat build tekshirish:

# .gitlab-ci.yml — oddiy variant
 
stages:
  - build
 
build:
  stage: build
  image: node:20
  before_script:
    - npm install -g pnpm
  script:
    - pnpm install
    - pnpm next build
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - node_modules/
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  tags:
    - shared

Production pipeline — build, test, Docker image yaratish va deploy:

Real loyihalarda odatda bir necha bosqich bo'ladi. Masalan, Node.js loyiha uchun:

# .gitlab-ci.yml — production variant
 
stages:
  - install
  - test
  - build
  - docker
  - deploy
 
variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
  DOCKER_IMAGE_LATEST: $CI_REGISTRY_IMAGE:latest
 
# Dependency'larni o'rnatish — keyingi bosqichlar uchun keshlanadi
install:
  stage: install
  image: node:20
  script:
    - npm install -g pnpm
    - pnpm install --frozen-lockfile
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - node_modules/
  tags:
    - shared
 
# Testlarni ishga tushirish
test:
  stage: test
  image: node:20
  script:
    - npm install -g pnpm
    - pnpm test
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - node_modules/
    policy: pull       # Faqat o'qiydi, yozmaydi (tezroq)
  tags:
    - shared
 
# Loyihani build qilish
build:
  stage: build
  image: node:20
  script:
    - npm install -g pnpm
    - pnpm build
  artifacts:
    paths:
      - .next/         # Build natijasini keyingi bosqichga uzatish
    expire_in: 1 hour
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - node_modules/
    policy: pull
  tags:
    - shared
 
# Docker image yaratish va GitLab Container Registry'ga push qilish
docker:
  stage: docker
  image: docker:24
  services:
    - docker:24-dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $DOCKER_IMAGE -t $DOCKER_IMAGE_LATEST .
    - docker push $DOCKER_IMAGE
    - docker push $DOCKER_IMAGE_LATEST
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  tags:
    - shared
 
# Serverga deploy qilish (SSH orqali)
deploy:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - mkdir -p ~/.ssh
    - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
  script:
    - ssh $DEPLOY_USER@$DEPLOY_HOST "
        docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY &&
        docker pull $DOCKER_IMAGE_LATEST &&
        docker compose -f /app/docker-compose.yml up -d
      "
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  when: manual         # Deploy faqat qo'lda tasdiqlanganda ishlaydi
  tags:
    - shared

Production pipeline'dagi muhim tushunchalar:

artifacts — build natijasini keyingi bosqichga uzatadi (masalan, .next/ papkasini docker bosqichiga)
cache: policy: pull — test va build bosqichlarida keshni faqat o'qiydi, vaqt tejaydi
$CI_REGISTRY — GitLab'ning o'rnatilgan Container Registry'si. Alohida Docker Hub kerak emas
when: manual — deploy bosqichi avtomatik ishlamaydi, admin GitLab interfeysidan qo'lda tasdiqlaydi
$SSH_PRIVATE_KEY, $DEPLOY_HOST — bu o'zgaruvchilar Settings → CI/CD → Variables bo'limida saqlanadi (kodda emas!)

Faylni repository'ga qo'shib main branch'ga push qiling — pipeline avtomatik ishga tushadi.

Pipelines bo'limiga o'ting:

Muvaffaqiyatli o'tgan pipeline:

Tafsilotlarni ko'rish uchun ustiga bosing:

Bu yerda biz faqat bitta build bosqichli oddiy pipeline yozdik. GitLab CI'da test, deploy, multi-stage pipeline va boshqa ko'p narsalar qilish mumkin. Batafsil: GitLab CI bilan CI/CD (opens in a new tab)

Xavfsizlik va Backup

GitLab serverini o'rnatib qo'yish yetarli emas — uni himoya qilish va ma'lumotlarni yo'qotmaslik choralarini ko'rish ham kerak.

Firewall sozlash

Serverda faqat kerakli portlarni oching, qolganlarini yoping:

sudo ufw allow OpenSSH    # SSH (22-port) — serverga terminal orqali kirish uchun
sudo ufw allow 80/tcp     # HTTP — Let's Encrypt sertifikat olish uchun kerak
sudo ufw allow 443/tcp    # HTTPS — GitLab web interfeysi
sudo ufw enable
sudo ufw status

Backup sozlash

Real hayotda server'lar buziladi, disklar ishdan chiqadi, xodimlar xato qiladi. Backup bo'lmasa — barcha kodlar, issue'lar, CI/CD konfiguratsiyalar yo'qoladi. Shuning uchun backup — bu "kerak bo'lsa qilamiz" emas, balki birinchi kundan sozlash kerak.

Backup nima saqlaydi:

Barcha Git repositorylar
Database (foydalanuvchilar, issue'lar, merge requestlar, CI/CD konfiguratsiyalar)
LFS ob'ektlar va uploadlar

Backup nima saqlamaydi (alohida qilish kerak):

/etc/gitlab/gitlab.rb — server konfiguratsiyasi
/etc/gitlab/gitlab-secrets.json — encryption kalitlari (busiz backup'dan tiklash imkonsiz)

# Backup'ni qo'lda olish
sudo gitlab-backup create
 
# Backup fayllari shu yerda saqlanadi:
ls /var/opt/gitlab/backups/
# Natija: 1710100800_2024_03_11_16.9.1_gitlab_backup.tar

Avtomatik backup + konfiguratsiya fayllarni ham backup qilish:

sudo crontab -e

# Har kuni soat 2:00 da to'liq backup
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
 
# Konfiguratsiya fayllarni alohida backup (har kuni soat 2:30)
30 2 * * * cp /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/gitlab.rb.$(date +\%F)
30 2 * * * cp /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/gitlab-secrets.json.$(date +\%F)

Muhim: Backup'ni shu serverning o'zida saqlash yetarli emas! Agar disk buzilsa — backup ham yo'qoladi. Real production'da backup'ni boshqa joyga ko'chiring:

# Masalan, boshqa serverga rsync bilan
rsync -avz /var/opt/gitlab/backups/ backup-user@backup-server:/gitlab-backups/
 
# Yoki S3 compatible storage'ga (MinIO, AWS S3)
# gitlab.rb da:
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'us-east-1',
  'aws_access_key_id' => 'ACCESS_KEY',
  'aws_secret_access_key' => 'SECRET_KEY',
  'endpoint' => 'https://s3.example.com'
}
gitlab_rails['backup_upload_remote_directory'] = 'gitlab-backups'

Backup'dan tiklash (restore):

# GitLab service'larni to'xtatamiz (database va cache ishlab tursin)
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
 
# Backup'dan tiklaymiz (fayl nomidagi timestamp'ni ko'rsating)
sudo gitlab-backup restore BACKUP=1710100800_2024_03_11_16.9.1
 
# Konfiguratsiya fayllarni qaytaramiz
sudo cp /backup/gitlab.rb /etc/gitlab/gitlab.rb
sudo cp /backup/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json
 
# Reconfigure va restart
sudo gitlab-ctl reconfigure
sudo gitlab-ctl restart

Xavfsizlik checklist

Production serverda quyidagi choralarni albatta amalga oshiring:

1. SSH kalitlari — parolni o'chiring:

gitlab.rb faylida:

# Parol bilan git clone/push ni o'chirish — faqat SSH kalit orqali
gitlab_rails['gitlab_shell_ssh_port'] = 22

Foydalanuvchilar User Settings → SSH Keys bo'limidan o'z SSH public key'larini qo'shishlari kerak. Keyin:

# Parol o'rniga SSH kalit bilan ishlash
git clone git@gitlab.helm.uz:devops/loyiha.git

2. 2FA (Two-Factor Authentication) — majburiy qilish:

Admin Area → Settings → General → Sign-in restrictions dan:

Two-factor authentication ni yoqing
Grace period ni 3 kun qo'ying — foydalanuvchilar 3 kun ichida 2FA sozlashi kerak

3. Muntazam yangilash:

GitLab xavfsizlik patch'lari har oyda chiqadi. Real production'da yangilash jarayoni:

# Yangilashdan oldin backup oling!
sudo gitlab-backup create
 
# Yangilash
sudo apt update && sudo apt upgrade gitlab-ee -y
sudo gitlab-ctl reconfigure
 
# Tekshirish
sudo gitlab-ctl status
sudo gitlab-rake gitlab:check SANITIZE=true

4. Monitoring — server holatini kuzatish:

Yuqorida gitlab.rb da Prometheus va Grafana'ni yoqqan edik. Endi gitlab.helm.uz/-/grafana orqali kirib, tayyor dashboardlardan server holatini kuzating: CPU, RAM, disk, so'rovlar soni, pipeline statistikasi.

5. Rate limiting — brute-force himoyasi:

# /etc/gitlab/gitlab.rb
 
# Login sahifasiga minutiga 10 dan ko'p so'rov yuborish mumkin emas
gitlab_rails['rate_limiting_response_text'] = 'Retry later'

GitLab loglarini ko'rish

Biror muammo chiqganda loglar eng yaxshi do'stingiz. GitLab'da har bir component o'z logini yozadi:

sudo gitlab-ctl tail              # Barcha loglar (real-time)
sudo gitlab-ctl tail puma         # Web application loglari
sudo gitlab-ctl tail nginx        # Proxy loglari
sudo gitlab-ctl tail sidekiq      # Background job loglari
sudo gitlab-ctl tail gitaly       # Git operatsiya loglari
sudo gitlab-ctl tail postgresql   # Database loglari

Agar muammo aniq bo'lmasa, umumiy diagnostika ishlatib ko'ring:

sudo gitlab-rake gitlab:check SANITIZE=true

Bu komanda GitLab'ning barcha componentlarini tekshirib, muammolarni ko'rsatadi.

Qo'shimcha

Qo'shimcha Resurslar

Qo'llanma uchun foydalanilgan resurslar

Sana: 2024.06.13(2024-yil 13-iyun)

Oxirgi yangilanish: 2026.03.11(2026-yil 11-mart)

Muallif: Otabek Ismoilov

Telegram (opens in a new tab)	GitHub (opens in a new tab)	LinkedIn (opens in a new tab)

Gitlab CI Gitlab CI Release && Integrations