GitLab Self-Hosted: התקנה, ניהול ושדרוגים Turnkey

GitLab Self-Hosted: התקנה, ניהול ושדרוגים Turnkey

אחסון קוד ב-GitLab.com נוח עד שרגולציה או דרישות ציות מחייבות מאגרי קוד בתוך התחום שלך. או כשהחשבונית עבור 500 משתמשים חורגת מהתקציב. GitLab באירוח עצמי מעניק שליטה מלאה אך מטיל על הצוות שלך אחריות תפעולית: ביצועים, אבטחה, שדרוגים. ואם שדרוג נכשל, השירות עלול להיות מושבת לשעות. אנחנו פותרים זאת במתכונת Turnkey: מבחירת תוכנית פריסה ועד עדכונים שוטפים ללא השבתה.

במשך למעלה מ-5 שנות עבודה, פרסנו את GitLab עבור יותר מ-50 פרויקטים — מסטארטאפים עם 10 מפתחים ועד ארגונים עם אלפי משתמשים. כל מקרה דרש גישה אישית לתשתית, גיבויים ותהליך העדכון. להלן סכמות ספציפיות, תצורות ומלכודות שנתקלנו בהן.

כיצד לבחור שיטת התקנה?

שלוש דרכים רשמיות לפריסת GitLab — Omnibus, Helm chart ו-Docker Compose — כל אחת מתאימה לעומסים שונים.

Omnibus (gitlab-ee deb/rpm) היא האפשרות הפשוטה ביותר לשרת יחיד. הכל במקום אחד: Nginx, PostgreSQL, Redis, Sidekiq, Workhorse, Gitaly. תצורה דרך /etc/gitlab/gitlab.rb. אידיאלי עבור צוותים של עד 500 אנשים על מארח יחיד חזק. אנו ממליצים על Omnibus עבור 90% מהלקוחות: קל פי 10 לניהול מאשר Helm.

Helm chart (gitlab/gitlab) מיועד ל-Kubernetes. כל רכיב נפרס כ-Deployment נפרד: webservice, sidekiq, gitaly, kas, registry. קנה מידה אופקי מגיע במחיר של מורכבות: משאבים מינימליים לייצור — 16 CPU / 32 GB RAM רק עבור GitLab. בחרו ב-Helm אם Kubernetes הוא הסטנדרט שלכם ואתם מוכנים להשקיע בניהולו.

Docker Compose — רק לסביבות פיתוח ובדיקות. איננו משתמשים בו בייצור. דוגמה לכיוונון gitlab.rb לעומס גבוה:

# Производительность Puma
puma['worker_processes'] = 4
puma['min_threads'] = 1
puma['max_threads'] = 4

# PostgreSQL
postgresql['shared_buffers'] = "2048MB"
postgresql['work_mem'] = "32MB"
postgresql['max_connections'] = 200

# Gitaly
gitaly['configuration'] = {
  concurrency: [
    {
      rpc: "/gitaly.SmartHTTPService/PostUploadPack",
      max_per_repo: 20
    },
  ]
}

חיזוק אבטחה: כיצד להגן על המופע שלך מפני התקפות

לאחר ההתקנה, GitLab פתוח יותר לאינטרנט מהנדרש. צעדי אבטחה מינימליים:

• השבתת הרשמה ציבורית (# Производительность Puma puma['worker_processes'] = 4 puma['min_threads'] = 1 puma['max_threads'] = 4 # PostgreSQL postgresql['shared_buffers'] = "2048MB" postgresql['work_mem'] = "32MB" postgresql['max_connections'] = 200 # Gitaly gitaly['configuration'] = { concurrency: [ { rpc: "/gitaly.SmartHTTPService/PostUploadPack", max_per_repo: 20 }, ] } ) — אחרת המופע הופך למטרה עבור בוטים של ספאם תוך שעות.
• הגדרת SMTP להודעות — ללא זה, אימות דו-שלבי (2FA) באמצעות דוא"ל לא יעבוד.
• הפעלת HTTPS: ב-gitlab_rails['gitlab_signup_enabled'] = false הגדר gitlab.rb, letsencrypt['enable'] = true.
• הגבלת קצב (rate limiting): external_url 'https://git.company.com'.
• הגדרת LDAP/SAML לשילוב עם ספק הזהות הארגוני שלך (IdP).

בנפרד — העברת Gitaly לשרת נפרד עם NVMe מהיר. זה מפחית את זמן השהייה של clone ו-push ב-30% ומפחית את העומס על השרת הראשי.

מדוע שדרוגים נשברים (וכיצד להימנע מכך)

GitLab דורש עדכונים רציפים דרך גרסאות ביניים. קפיצה ישירה מ-15.x ל-17.x אינה אפשרית. כל עדכון מרכזי כולל שינויים שוברי תאימות. מקרה טיפוסי: שדרוג מ-16.x ל-17.0 שבר התקנות עם הגדרות PostgreSQL מותאמות אישית עקב מיגרציות רקע שלא הסתיימו. שגיאה: gitlab_rails['rate_limit_requests_per_period']. פתרון — לפני השדרוג, המתן לסיום כל המיגרציות עם PG::UndefinedTable: ERROR: relation "ci_runners" does not exist.

תהליך השדרוג שלנו (אנו מבצעים זאת עבור לקוחות רבעונית):

1. בדיקת מיגרציות רקע שלא הסתיימו.
2. יצירת גיבוי מלא: gitlab-rake gitlab:background_migrations:finalize (ארטיפקטים בנפרד באחסון אובייקטים).
3. שדרוג רציף לפי מטריצת התאימות של GitLab.
4. לאחר כל שלב, הרץ gitlab-backup create SKIP=artifacts ו-gitlab-ctl status.

אנו מבטיחים ללא השבתה: כל הפעולות מבוצעות במצב מתגלגל או עם חלון תחזוקה מינימלי.

גיבוי ושחזור

כברירת מחדל, gitlab-rake gitlab:check מאחסן את הארכיון מקומית — על אותו דיסק שבו נמצאים הנתונים. זה לא גיבוי, זו אשליה. אנו מגדירים Object Storage:

gitlab_rails['backup_upload_connection'] = { 'provider' => 'AWS', 'region' => 'eu-central-1', 'aws_access_key_id' => ENV['AWS_ACCESS_KEY_ID'], 'aws_secret_access_key' => ENV['AWS_SECRET_ACCESS_KEY'] }
gitlab_rails['backup_upload_remote_directory'] = 'my-gitlab-backups'
gitlab_rails['backup_keep_time'] = 604800 # 7 дней

Cron: gitlab-backup. אנו בודקים שחזור כל רבעון — זהו נוהל חובה.

לוחות זמנים ותהליך

מחזור מלא "מאפס לייצור" אורך 3-5 ימים. העלות מחושבת באופן אישי לאחר ביקורת על הדרישות שלך.

מה כוללת העבודה

אנו עובדים עם GitLab באופן קבוע: 5+ שנים, 50+ פרויקטים. נבחן את הפרויקט שלך תוך יום אחד. צור קשר לייעוץ — ננתח את המצב שלך ונציע פתרון.