Ovaj korak-po-korak vodič pokazuje kako instalirati i podesiti GitLab na Linuxu, sa fokusom na osnovne zahteve, bezbednosne postavke i optimizaciju performansi. Pokrićemo pravljenje rezervnih kopija pre promena, konfiguraciju vatrozida i SSL certifikata, kao i integraciju CI/CD procesa za povećanje produktivnosti. Obratite pažnju na rizik gubitka podataka i izlaganja portova prilikom loše konfiguracije. Namena: sigurna, skalabilna i održiva GitLab instanca.
Vrste GitLab instalacija
U praksi najčešće se sreću tri modela instalacije: Omnibus, Docker i instalacija iz izvornog koda, dok se funkcionalnosti dalje dele između GitLab Community Edition (CE) i GitLab Enterprise Edition (EE). Omnibus paket integriše više od 10 servisa (Rails, Gitaly, Sidekiq, PostgreSQL, Redis, NGINX) i omogućava brzo pokretanje u produkciji sa najmanje podešavanja. Any preporuka za većinu timova: počnite sa Omnibus ili Docker zbog brže implementacije i jednostavnijih backup procedura.
- Omnibus – kompletan paket, najbrže pokretanje
- Docker – kontejnerizovana fleksibilnost i orkestracija
- Izvorni kod – maksimalna kontrola, veći zahtevi za održavanje
- CE – besplatno, open-source
- EE – dodatne enterprise funkcije i podrška
| Omnibus | Automatizovan paket koji sadrži GitLab i sve zavisnosti; dobar za brz start i manje operativno održavanje. |
| Docker | Kontejneri omogućavaju izolaciju servisa i lakšu integraciju sa CI/CD pipeline-ima i Kubernetesom. |
| Izvorni kod | Ručno sastavljanje iz izvora nudi najveću fleksibilnost, ali zahteva opsežno upravljanje servisima i nadzor. |
| Community Edition (CE) | Besplatna edicija sa osnovnim funkcijama: repozitorijumi, CI/CD, issue tracking – idealna za SMB i open-source projekte. |
| Enterprise Edition (EE) | Komercijalne funkcije za velike timove: Geo, audit log, napredne kontrole pristupa i SLA podrška. |
Community Edition
CE nudi sve osnovne alate: git hosting, CI/CD, issue/merge request workflow i osnovne integracije. Primer: start-up tim od 20 developera može pokrenuti CE preko Omnibus za manje od 30 minuta, ali će skaliranje i sigurnosne politike zavisiti od sopstvenih resursa i konfiguracije.
Enterprise Edition
EE donosi napredne mogućnosti kao što su Geo replikacija, audit logovi, napredna autorizacija i administratorska izvještavanja; tipično se koristi u organizacijama sa više stotina developera gde su potrebni visoki nivoi dostupnosti i podrške.
Za dodatne informacije, EE uključuje komercijalne planove (npr. Premium, Ultimate) sa podrškom i SLA; funkcije kao što su Geo, grupne politike pristupa, SAML SSO i napredni sigurnosni skeneri znatno olakšavaju usklađivanje sa regulativom i smanjuju rizik u okruženjima sa >200 korisnika, ali zahtevaju pažljivo upravljanje licencama i redovne backup i restore provere.
Vodič korak po korak za instalaciju
Sledeći redosled operacija pruža jasan plan za brzu i bezbednu instalaciju GitLaba: ažuriranje sistema, dodavanje zvaničnog repozitorijuma, instalacija paketa i osnovna konfiguracija. Obavezno napravite backup postojećih podataka i koristite root ili sudo nalog; reconfigure korak može potrajati i promeniti servise, zato pratite izlaz komandi.
Koraci i opisi
| Korak | Opis |
|---|---|
| 1. Ažuriranje | sudo apt update && sudo apt upgrade -y – priprema sistema |
| 2. Zavisnosti | Instalirajte curl, openssh-server, ca-certificates, tzdata |
| 3. Repozitorijum | curl -sS https://packages.gitlab.com/… | sudo bash – dodajte GitLab repo |
| 4. Instalacija | sudo apt-get install gitlab-ce -y – instalira GitLab CE paket |
| 5. Konfiguracija | Uredite /etc/gitlab/gitlab.rb, postavite external_url |
| 6. Reconfigure | sudo gitlab-ctl reconfigure – primena konfiguracije |
| 7. Firewall | Otvorite portove 80, 443, 22 i proverite SELinux/ufw |
| 8. Provera | gitlab-ctl status i pristup preko browsera; pronađite inicijalnu lozinku |
Prerequisites
Potrebno je 64-bit Linux okruženje, preporučeno najmanje 4 GB RAM i 2 CPU jezgra, te ≥10 GB slobodnog diska za osnovnu instancu. Takođe morate imati root/sudo pristup, registrovani domen koji pokazuje na server i otvorene portove 80/443/22 radi web, HTTPS i SSH pristupa.
Installation Process
Prvo instalirajte zavisnosti: apt install curl openssh-server ca-certificates tzdata; zatim dodajte GitLab repozitorijum preko skripte sa packages.gitlab.com i pokrenite sudo apt-get install gitlab-ce. Nakon instalacije, podesite /etc/gitlab/gitlab.rb (external_url) i izvršite sudo gitlab-ctl reconfigure da primenite promene.
Dodatno: proces reconfigure obično traje 10-30 minuta zavisno od resursa; pratite izlaz preko sudo gitlab-ctl tail i proverite inicijalnu lozinku u logu ili u /etc/gitlab/initial_root_password. Ako planirate SSL, koristite Let’s Encrypt automatsku opciju ili postavite sopstvene certifikate pre reconfigure-a; takođe podesite redovan backup koristeći gitlab-rake gitlab:backup:create i cron.
Konfigurisanje GitLab-a
Sledeći koraci fokusiraju se na produkcijska podešavanja: definišite external_url (npr. https://gitlab.example.com), obezbedite SSL za portove 80/443, i podesite DNS zapise. Proverite firewall i SSH port (podrazumevano 22, može se promeniti na 2222) kako biste sprečili neočekivane prekide i sigurnosne propuste.
Initial Configuration
Podesite /etc/gitlab/gitlab.rb sa tačnim external_url, zatim pokrenite sudo gitlab-ctl reconfigure. Resetujte administratorsku lozinku komandom sudo gitlab-rake “gitlab:password:reset[root]”, konfigurišite SMTP za notifikacije i omogućite LetsEncrypt ako imate javni domen.
Advanced Settings
Fokusirajte se na rezervne kopije, skladištenje objekata (S3), monitoring i skaliranje CI traka: za manje timove podesite Puma na 2-4 radnika, Sidekiq na 25-50 niti, i aktivirajte Prometheus za metrike. Nepravilna konfiguracija objekt skladišta može dovesti do trajnog gubitka podataka.
- Backup politika i raspored
- Objektno skladištenje (S3/MinIO)
- Performanse: Puma, Sidekiq, PostgreSQL
Ključne opcije
| Opcija | Preporuka |
|---|---|
| external_url | HTTPS domen, validan certifikat |
| backup | Dnevni snapshot, zadržati 7 kopija |
| objektno skladište | Korišćenje S3 sa verzionisanjem i politikom zadržavanja |
Za primer: na instanci sa ~50 aktivnih developera koristite Puma 3 radnika i Sidekiq concurrency 30, redovno vršite backup komandom sudo gitlab-rake gitlab:backup:create i sinhronizujte tar fajlove u S3 bucket naziva gitlab-backups-prod. Testirajte restore najmanje jednom mesečno kako biste potvrdili integritet podataka.
- Proverite /etc/gitlab/gitlab.rb i verzionisite konfiguraciju
- Automatizujte backup i verifikaciju
- Monitorišite metrika i prilagodite resurse po opterećenju
Korisne komande
| Komanda | Opis |
|---|---|
| sudo gitlab-ctl reconfigure | Primena promena u gitlab.rb |
| sudo gitlab-rake “gitlab:password:reset[root]” | Reset administratorske lozinke |
| sudo gitlab-rake gitlab:backup:create | Kreiranje backup paketa (db, uploads, builds) |
Saveti za optimalne performanse
Da bi GitLab ostao responzivan pod opterećenjem, optimizujte CPU, RAM i I/O pre nego što skalirate usluge; preporuka za male timove je najmanje 4 CPU i 8 GB RAM, dok produkcija sa >100 korisnika često zahteva 8 CPU/16 GB+. Aktivno koristite monitoring (Prometheus/Grafana), ograničite zadržavanje artefakata na npr. 30 dana i podešavajte NGINX worker-e prema broju jezgara. This obezbeđuje da klasteri ostanu stabilni i da se brzo detektuju uska grla.
- CPU: uskladiti worker_processes sa jezgrama
- RAM: rezervisati dovoljno za PostgreSQL i Redis
- Disk I/O: SSD sa visokim IOPS za repozitorijume
Resursi sistema
Za produktivne instance koristite SSD disk (preporučeno NVMe), odvojenu particiju za PostgreSQL, i ciljate na najmanje 1000 IOPS; za baze sa 100k+ repozitorijuma planirajte > 500 GB prostora i rezervu za rast. Swap držite s pažnjom (previše swap-a usporava GitLab), a podešavanje vm.swappiness на ~10 poboljšava performanse.
Redovno održavanje
Planirajte automatizovane backup-e svakodnevno (koristite gitlab-rake gitlab:backup:create), mesečna ažuriranja za bezbednosne zakrpe i redovno čišćenje artefakata (>30 dana) kako biste smanjili zauzeće diska i ubrzali CI/CD pipeline.
Detaljnije, koristite politiku zadržavanja backup-a npr. 7 dnevnih, 4 nedeljna, 6 mesečnih, testirajte restore najmanje jednom kvartalno, automatizujte vacuum i analyze za PostgreSQL preko cron-a, pratite gitlab-ctl tail logove za greške i postavite alert-e u Prometheus za visok load ili long-running migrations.
Faktori koje treba razmotriti pre instalacije
Pre instalacije obavezno procenite kapacitet, dostupnost i bezbednosne zahteve; fokusirajte se na GitLab, ciljnu Linux distribuciju i očekivani broj korisnika jer to direktno utiče na CPU, RAM i I/O zahteve. Planirajte backup, mrežnu propusnost i politiku ažuriranja; SSD skladište i monitoring su često presudni za stabilnost.
- Hardver: vCPU, RAM, I/O
- Skladište: SSD, kapacitet, objektni storage
- Mreža: propusnost, latencija, sigurnosni segmenti
- Backup i DR: učestalost, testiranje
- Bezbednost: TLS, firewall, RBAC
- Integracije: LDAP/AD, CI runners, registri
- Skalabilnost i HA: vertikalno vs horizontalno
- Monitoring i alerting: Prometheus, Grafana
Server Requirements
Za osnovnu instalaciju preporučuje se minimum 4 vCPU, 8 GB RAM i ~25 GB disk prostora, dok produkcioni sistemi često zahtevaju 8-16 vCPU i 32-64 GB RAM; za CI/CD workload planirajte dodatne diskove i zasebne runnere. Upotrebite SSD i brzu mrežu, te obezbedite rezervni kapacitet za rast.
Use Case Analysis
Procena slučaja upotrebe počinje identifikacijom broja developera, učestalosti CI zadataka i veličine repozitorijuma; za tim od ~10 korisnika dovoljna je skromnija konfiguracija, dok timovi od 100+ zahtevaju više resursa i distribuisane runners. Obratite pažnju na zahtev za zadržavanje podataka i compliance.
Na primer, kompanija sa 200 developera je odlučila za arhitekturu sa 16 vCPU, 64 GB RAM, ~2 TB brzo dostupnog skladišta i odvojenim CI runner klasterom; to je omogućilo stabilne pipelajne i minimalne kašnjenja. Kritično je planirati objektno skladište za velike artefakte i redovno testirati backup proceduru kako bi se izbegao gubitak podataka.
Prednosti i nedostaci korišćenja GitLab-a
Mnogi timovi koriste GitLab zbog integrisanih CI/CD funkcionalnosti, privatnog registry-ja i upravljanja projektima u jednoj aplikaciji; to često smanjuje vreme isporuke za 30-50% u praktičnim slučajevima. S druge strane, treba računati na povećane zahteve za resursima i potencijalne troškove Enterprise licenci pri skaliranju.
Tabela: Prednosti i nedostaci
| Prednosti | Nedostaci |
|---|---|
| Sve-u-jednom: repo, issue tracker, CI/CD, container registry | Visoki zahtevi za CPU/RAM i disk I/O u produkciji |
| Powerful CI: paralelni jobovi, cache, artifacts i autoscaling runners | Neke važne funkcije (Geo, advanced RBAC) su u EE/plaćenim planovima |
| Podrška za self-hosting i GitLab.com SaaS | Kompleksnost nadogradnje i migracije između verzija |
| Snažna integracija sa DevOps procesima i pipeline vizualizacijom | Kriva učenja za administratore i DevOps inženjere |
| Detaljno praćenje pristupa i auditorija (audit logs u EE) | Licencni i operativni troškovi za velike timove |
| Velika zajednica i dokumentacija, otvoreni core model | Ograničenja third‑party integracija u određenim planovima |
| Automatizacija deploy-a i Canary/Rollback mogućnosti | Potencijalni sigurnosni rizici ako se ne primene pravilne politike |
| Skalabilne opcije (Grupe, projekti, namespace-ovi) | Performanse mogu opasti bez optimizacije baza i keširanja |
Prednosti
U praksi, integrisana CI/CD omogućava automatizaciju build/test/deploy procesa: timovi često konfigurišu pipeline-e za paralelno izvršavanje, cache i artefakte što smanjuje vreme CI ciklusa; primer: tim sa 50 developera može postići 2-3x brže iteracije primenom GitLab CI optimizacija.
Nedostaci
Glavni izazov je operativni trošak-self-hosted instalacija zahteva snažan server (npr. >8 CPU, >32 GB RAM za srednje opterećenje) i redovno održavanje; takođe, ključne enterprise funkcije su često dostupne samo u plaćenim planovima.
Dodatno, administratori moraju planirati backup, high-availability i nadogradnje: bez pažljivog upravljanja, postoje rizici prekida usluge pri migracijama i povećanom opterećenju, pa se preporučuje testno okruženje i automatizovane procedure za rollback i monitoring.
Zaključak
U zaključku, pravilna instalacija i podešavanje GitLaba na Linux sistemu obezbeđuje stabilan i siguran razvojni okruženje; pratite preporučene korake za zahteve sistema, sigurnosne postavke, rezervne kopije i ažuriranja, verifikujte mrežne portove i korisnička prava, te automatizujte održavanje. Dosledna provera konfiguracije i politika pristupa smanjuje rizike i održava visok nivo dostupnosti i performansi.
FAQ
Q: Kako da pripremim Linux server i instaliram GitLab CE korak po korak?
A: Pre instalacije proverite sistemske zahteve (preporučeno ≥4 CPU, ≥8 GB RAM za srednja okruženja, dovoljno prostora na disku). Ažurirajte paketni menadžer (Ubuntu/Debian: sudo apt update && sudo apt upgrade -y; RHEL/CentOS: sudo yum update -y). Postavite hostname (sudo hostnamectl set-hostname gitlab.example.com) i dodajte zapise DNS za vašu domenu. Instalacija preko Omnibus paketa: na Debian/Ubuntu dodajte GitLab repo i instalirajte paket: curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash && sudo EXTERNAL_URL=”http://gitlab.example.com” apt install gitlab-ee -y; na RHEL/CentOS koristite odgovarajući script.rpm.sh i yum/dnf install. Nakon instalacije, uredite /etc/gitlab/gitlab.rb, podesite external_url, eventualno SMTP i storage puteve, pa pokrenite sudo gitlab-ctl reconfigure. Proverite status sudo gitlab-ctl status i otvorite veb interfejs na external_url da kreirate administratorski nalog.
Q: Kako da podesim HTTPS (Let’s Encrypt ili sopstveni sertifikat) i otvorim potrebne portove?
A: Ako koristite Let’s Encrypt, u /etc/gitlab/gitlab.rb postavite external_url = “https://gitlab.example.com” i omogućite letsencrypt: letsencrypt[‘enable’] = true; dodajte letsencrypt[‘contact_emails’] = [‘[email protected]’] i pokrenite sudo gitlab-ctl reconfigure. Za sopstveni certifikat postavite nginx[‘ssl_certificate’] i nginx[‘ssl_certificate_key’] na putanje .crt i .key fajlova, ili postavite reverse proxy ispred GitLaba. Otvorite portove 80 i 443 u firewallu (UFW: sudo ufw allow http; sudo ufw allow https; firewalld: sudo firewall-cmd –permanent –add-service=http; sudo firewall-cmd –permanent –add-service=https; sudo firewall-cmd –reload). Ako koristite cloud provider, podesite sigurnosne grupe/NSG da dozvole pristup na 80/443. Proverite da DNS A/AAAA zapis ukazuje na IP servera pre izdavanja sertifikata.
Q: Kako napraviti rezervne kopije, vratiti GitLab i rešavati česte probleme nakon instalacije?
A: Za backup koristite ugrađeni alat: sudo gitlab-rake gitlab:backup:create STRATEGY=copy; backup fajlovi se nalaze u /var/opt/gitlab/backups. Potrebno je backupovati i /etc/gitlab i /var/opt/gitlab/gitlab-rails/uploads ako imate velike priloške datoteke. Za restore zaustavite servise sudo gitlab-ctl stop unicorn && sudo gitlab-ctl stop sidekiq, postavite odgovarajući BACKUP env var i pokrenite sudo gitlab-rake gitlab:backup:restore BACKUP=timestamp, zatim sudo gitlab-ctl reconfigure i restart. Za nadogradnju koristite paketni menadžer (Ubuntu: sudo apt update && sudo apt install gitlab-ee) i obavezno pročitajte release notes za breaking changes. Česti problemi: usluga ne pokreće (koristiti sudo gitlab-ctl reconfigure && sudo gitlab-ctl restart i proveriti logove u /var/log/gitlab), problemi sa dozvolama (proveriti vlasništvo fajlova u /var/opt/gitlab), konfliktnI port (proveriti koji proces koristi port sa sudo ss -tulpen), SELinux (privremeno permissive ili podesiti pravila), i SMTP neuspeh (proveriti konfiguraciju u gitlab.rb i testirati slanje mejla). Korisni komandni pregledi: sudo gitlab-ctl status, sudo gitlab-ctl tail za logove u realnom vremenu, sudo gitlab-rake gitlab:check –trace za dijagnostiku.