הפייפליין שלך ממתין בתור כבר 15 דקות בזמן שהראנרים המשותפים של GitLab.com עמוסים? או שצוות האבטחה שלך דורש שקונטיינרים של בנייה לעולם לא יעזבו את השרתים שלך? המהנדסים שלנו מקימים ראנרים עצמיים של GitLab Runner כבר 5 שנים — עבור פרויקטים עם עומסים של 10 עד 500+ ג'ובים ביום. למעלה מ-50 התקנות מוצלחות בחברות מסטארטאפים ועד ארגונים גדולים. נבחן את תשתית ה-CI שלך ביום אחד ונציע ארכיטקטורה שתקצר משמעותית את זמני ההמתנה.
איך להקים GitLab Runner עם Docker executor?
האפשרות הפופולרית ביותר היא Docker executor, שבו כל ג'וב רץ בקונטיינר מבודד. רשמו ראנר עם פקודה אחת:
gitlab-runner register \
--non-interactive \
--url "https://gitlab.company.com" \
--token "glrt-xxxxxxxxxxxx" \
--executor "docker" \
--docker-image "alpine:latest" \
--docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \
--docker-privilegedהדגל gitlab-runner register \ --non-interactive \ --url "https://gitlab.company.com" \ --token "glrt-xxxxxxxxxxxx" \ --executor "docker" \ --docker-image "alpine:latest" \ --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \ --docker-privileged נדרש רק עבור Docker-in-Docker (dind). אם dind לא נדרש, אל תשתמשו בו: הוא מרחיב הרשאות קונטיינר למארח, מה שיוצר סיכוני אבטחה. חלופה היא להשתמש ב---docker-privileged כקונטיינר צדדי (sidecar).
הגדרות מפתח ב-config.toml
לאחר הרישום, התצורה נמצאת ב-docker:dind. הפרמטר /etc/gitlab-runner/config.toml קובע כמה ג'ובים הראנר מבצע במקביל. בחרו ערך בהתאם למשאבי המארח: עבור מכונה עם 4 ליבות, 4–8 הוא סביר. concurrent מקצר את זמן ההתחלה של ג'ובים כי התמונות נשמרות במטמון מקומי. ללא הגדרה זו, הראנר מבצע pull_policy = ["if-not-present"] עבור כל ג'וב, מה שמאט את הפייפליין ומעמיס על הרישום.
concurrent = 10
[[runners]]
name = "docker-runner-prod"
url = "https://gitlab.company.com"
token = "glrt-xxxxxxxxxxxx"
executor = "docker"
[runners.docker]
image = "alpine:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
pull_policy = ["if-not-present"]
השוואת executors
| Executor | בידוד | זמן התחלה | אבטחה | קנה מידה |
|---|---|---|---|---|
| Shell | אין | מיידי | נמוכה | ידני |
| Docker | כן | 1–3 שניות | בינונית | ידני/אוטומטי |
| Kubernetes | כן | 10–30 שניות | גבוהה | אוטומטי |
ה- Kubernetes executor מנצח בקנה מידה: הוא מתחיל אוטומטית Pod עבור כל ג'וב, וכשהעומס בשיא, ה- cluster autoscaler מוסיף צמתים. זה יעיל פי 3–5 מראנר Docker סטטי כשהעומס ביום גבוה פי 10 מהעומס בלילה.
למה לבחור ב- Kubernetes executor?
עבור צוותים עם עומס משתנה (CI כמעט לא בשימוש בלילה, שיאים במהלך היום), ההתקנה האופטימלית היא ראנר ב- Kubernetes עם Karpenter או Cluster Autoscaler. אנו פורסים את הראנר באמצעות Helm:
helm repo add gitlab https://charts.gitlab.io
helm install gitlab-runner gitlab/gitlab-runner \
--namespace gitlab-runner \
--set gitlabUrl=https://gitlab.company.com \
--set runnerToken=glrt-xxxxxxxxxxxx \
--set rbac.create=true \
--set runners.config="$(cat runner-config.toml)"
ב-docker pull עבור ה- Kubernetes executor, ציינו משאבים: concurrent = 10 [[runners]] name = "docker-runner-prod" url = "https://gitlab.company.com" token = "glrt-xxxxxxxxxxxx" executor = "docker" [runners.docker] image = "alpine:latest" privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0 pull_policy = ["if-not-present"] , helm repo add gitlab https://charts.gitlab.io helm install gitlab-runner gitlab/gitlab-runner \ --namespace gitlab-runner \ --set gitlabUrl=https://gitlab.company.com \ --set runnerToken=glrt-xxxxxxxxxxxx \ --set rbac.create=true \ --set runners.config="$(cat runner-config.toml)" , runner-config.toml. זה מבטיח שכל ג'וב לא יעמיס על הקלאסטר. כשהצמתים לא מספיקים, Karpenter מתחיל חדשים תוך 60–90 שניות.
השוואת אסטרטגיות מטמון
| סוג מטמון | זמן כתיבה | חיסכון בזמן | מורכבות התקנה |
|---|---|---|---|
| ללא מטמון | 0 שניות | 0% | אין |
| מקומי (דיסק) | 1–3 שניות | עד 30% | נמוכה |
| S3 (MinIO/AWS) | 2–5 שניות | עד 40% | בינונית |
עם מטמון S3, זמני הבנייה מחדש מצטמצמים ב-35–40%, ועלויות האחסון מינימליות. אנו מתחברים לכל bucket תואם S3.
מה כלול בהקמת GitLab Runner במפתח מוכן?
המסירה הסטנדרטית שלנו כוללת:
- בחירת ה- executor האופטימלי בהתאם לפרופיל העומס.
- רישום ראנר ותצורת
cpu_request: 100mעם מדיניות pull, cache ואבטחה נכונה. - הקמת מטמון S3 (MinIO, AWS S3, Yandex Object Storage) כדי להאיץ בניות עוקבות — חוסך עד 40% זמן בג'ובים חוזרים.
- אינטגרציה עם cluster autoscaler ו- Karpenter לקנה מידה אוטומטי.
- מדיניות RBAC ו- NetworkPolicies לבידוד מאובטח.
- תיעוד תפעולי ו- runbook לאירועים טיפוסיים.
- אחריות על עבודת התצורה: אם משהו נשבר תוך חודש, נתקן בחינם.
פתרון זה מפחית את עלויות תשתית ה-CI ב-30–50% בחודש בהשוואה לראנרים משותפים.
בעיות טיפוסיות בהקמה עצמית
הראנר מתנתק לאחר עדכון טוקן. מאז GitLab 16.0, לטוקנים יש פורמט cpu_limit: 2. ראנרים ישנים עם memory_limit: 2Gi מפסיקים לעבוד ודורשים רישום מחדש. פתרון: config.toml עם הטוקן החדש.
המטמון לא עובד בין ג'ובים. הנתיב ב-glrt- חייב להיות יחסי. לדוגמה, השתמשו ב-GR1348 עבור npm, לא בנתיב מוחלט gitlab-runner verify && gitlab-runner register. אחרת, המטמון לא ישוחזר.
Docker socket לעומת dind. הרכבת cache.paths נותנת לג'וב גישת root ל- Docker על המארח — חור אבטחה חמור. עדיף להשתמש ב-- .npm/ כקונטיינר שירות. כן, זה מאט בניות ב-10–20%, אבל אבטחה חשובה יותר. GitLab ממליץ רשמית על dind לבניות מבודדות.
לוח זמנים ועלות
הקמת ראנר יחיד עם Docker executor אורכת 2–4 שעות אם כבר יש לכם מארח. תצורת פתרון בר-קנה מידה על Kubernetes עם מטמון S3 ו- RBAC אורכת 1 עד 3 ימים. העלות נקבעת לאחר ביקורת של עומס ה-CI שלכם — צרו קשר, ונעריך את הפרויקט תוך יום עסקים אחד. אתם מקבלים תשתית מוכנה עם אחריות לפעולה יציבה. בקשו ייעוץ, ונכין הצעה מותאמת אישית.