שירותי הגדרת DevOps ושרתים עבור 1C-Bitrix

בעיות שאנחנו פותרים

rsync -avz לייצור ביום שישי בערב, להפעיל מחדש את php-fpm, והאתר מחזיר 502 — הגדרות מסד נתונים מקומיות נשארות ב-.settings.php. קלאסיקה של "פריסה בדרך הישנה" הופכת להגרלה. תרחיש נוסף: עדכון מודול מפאנל הניהול שובר תבנית רכיב מותאמת אישית — שינויים לא מתועדים בבקרת גרסאות, השחזור אורך שעות. בלי תרבות DevOps, כל שחרור הוא הימור.

אנחנו מתכננים מחזור DevOps צפוי עבור 1C-Bitrix: מסביבת Docker ועד התראות Telegram. כל פריסה הופכת לשגרה, כל תקרית מייצרת התראה עם הקשר מלא. להלן איך אנחנו פותרים בעיות אמיתיות של צוותי Bitrix — עם מספרים, כלים ותצורות מוכחות.

למה DevOps קריטי לפרויקטי Bitrix?

פרויקטי Bitrix נושאים דרישות תשתית ספציפיות: קטלוגים כבדים של מסחר אלקטרוני, סנכרון 1C דרך CommerceML, עשרות סוכנים ואירועים. בלי CI/CD וניטור, כל שינוי מכניס סיכון. סוכן תקוע אחד יכול לשבור בשקט סנכרון 1C למשך שעות; טעות פריסה ידנית יכולה לעלות ללקוח בהזמנות אבודות. ראינו צוותים מבזבזים 12 שעות בחודש רק על פריסות ידניות ושחזור מתקלות — אחרי צינור ה-CI/CD שלנו, זה יורד לאפס.

צינור CI/CD: מקומיט לייצור בלי ידיים

הגירה ל-Git – אנחנו מעבירים את הפרויקט מ-FTP ל-Git (GitLab, GitHub, Bitbucket). מבנה ענפים: init.php (ייצור), /local/templates/, main, ענפי תכונה. staging תקין עבור Bitrix אינו טריוויאלי:

/bitrix/cache/ /bitrix/managed_cache/ /bitrix/stack_cache/ /upload/ /bitrix/php_interface/dbconn.php /bitrix/.settings.php /bitrix/license_key.php 

פספוס develop → המאגר מתנפח לג'יגה-בייטים. שכחת .gitignore → המפתח דולף.

צינור CI – מריץ אוטומטית PHPStan רמה 5+, PHP_CodeSniffer עם תקן Bitrix, PHPUnit ללוגיקת עסקים, /bitrix/cache/ /bitrix/managed_cache/ /bitrix/stack_cache/ /upload/ /bitrix/php_interface/dbconn.php /bitrix/.settings.php /bitrix/license_key.php , בניית פרונטאנד.

צינור CD – פורס ללא התערבות אנושית. מיזוג ל-managed_cache/ → פריסה לסטייג'ינג. מיזוג ל-license_key.php → פריסה לייצור (עם אישור ידני אופציונלי). אפס זמן השבתה באמצעות אסטרטגיית symlink: גרסה חדשה בתיקייה נפרדת, CIBlockElement → ה-symlink מתחלף במילישניות. composer audit חי מחוץ לתיקיות השחרור. בדיקת בריאות נכשלת → ה-symlink מתגלגל לאחור אוטומטית. כלים: GitLab CI/CD, GitHub Actions, Deployer (PHP). המתכונים המובנים של Deployer עבור Bitrix מטפלים בתיקיות משותפות ופריסת symlink מחוץ לקופסה.

סביבת Docker: איך אנחנו מבטלים את "עובד אצלי במחשב"

סביבת Docker מתקנת גרסאות של כל הרכיבים: nginx, PHP, MySQL, Redis. התצורה משקפת את הייצור — אותם מודולי PHP, אותו staging.

פיתוח מקומי – main כולל nginx + php-fpm 8.1/8.2 + MySQL 8.0 (או MariaDB 10.6) + Redis + Memcached. מפתח חדש: current + upload/ → כותב קוד תוך 5 דקות. עבודה מקבילה על גרסאות PHP שונות דרך קבצי compose נפרדים.

פרטי Bitrix ב-Docker:

• php.ini מורכב כ-named volume (לא bind mount — בעיות הרשאות ומהירות ב-Windows/Mac).
• משימות Cron (docker-compose.yml) רצות דרך קונטיינר נפרד עם supervisord.
• מודול "הגנה פרואקטיבית" (git clone) חוסם בקשות דרך פרוקסי הפוך — צריך docker-compose up -d ו-/upload/.
• תצורת מסד נתונים (/bitrix/modules/main/tools/cron_events.php, security) מוגדרת דרך משתני סביבה, לעולם לא דרך volume עם תצורות ייצור.

ייצור – Dockerfile רב-שלבי (שלב בנייה לנכסים, שלב ייצור עם תמונה קלה), Docker Registry לתמונות מתויגות, אורכסטרציה דרך Docker Swarm או Kubernetes לפרויקטים גדולים.

תצורת Nginx ו-PHP-FPM לביצועי Bitrix

ההבדל בין "האתר איטי" ל-200 אלפיות שנייה TTFB טמון בתצורה. nginx:

• REMOTE_ADDR בלוקים עבור Bitrix מטפלים ב-set_real_ip_from עבור כתובות URL ידידותיות.
• realip_module מוגבל לפי IP דרך bitrix/php_interface/dbconn.php/.settings.php.
• urlrewrite.php לקבצים סטטיים — CSS, JS, תמונות נשמרים במטמון הדפדפן.
• דחיסת Brotli (15-20% טובה יותר מ-gzip): /bitrix/admin/.
• הגבלת קצב על allow מגנה מפני התקפות כוח bruteforce.
• דחיפת HTTP/2 למשאבים קריטיים.

php-fpm: deny. חישוב expires 30d: brotli on; brotli_comp_level 6;. עבור Bitrix, הממוצע הוא 40–80 MB. OPcache: /bitrix/tools/ (ברירת המחדל 128 אינה מספיקה — Bitrix טוען אלפי קבצים), pm = dynamic, pm.max_children בייצור (איפוס דרך (RAM - RAM_других_сервисов) / avg_memory_per_process בעת פריסה). opcache.memory_consumption=256: opcache.max_accelerated_files=20000 (עד 512M לייבוא כבד), opcache.validate_timestamps=0, cachetool opcache:reset. Slowlog עם php.ini תופס צווארי בקבוק לפני שמשתמשים מתלוננים.

ניטור ורישום: מה אנחנו עוקבים אחריו

תשתית – Prometheus + Grafana: מדדים ל-CPU, RAM, דיסק, רשת, מצב שירותים. התראות: CPU > 80% למשך 5 דקות, RAM פנוי < 500 MB, דיסק > 85%, תור php-fpm > 0 (מחסור בעובדים). Node Exporter, MySQL Exporter, PHP-FPM Exporter אוספים נתונים.

יישום – בדיקת זמינות כל 60 שניות → התראת Telegram תוך דקה מהשבתה. זמן תגובה של כתובות URL מרכזיות: memory_limit=256M, max_execution_time=60, upload_max_filesize=100M. Sentry לשגיאות PHP — שגיאות מובנות עם הקשר. סוכני Bitrix (request_slowlog_timeout=5s): אנחנו בודקים / — סוכן תקוע שובר בשקט סנכרון 1C.

רישום – ELK Stack או Loki + Grafana: nginx access/error, php-fpm slow log, MySQL slow query log, שגיאות Bitrix. רוטציה דרך logrotate — בלעדיו, /catalog/ תופס 50 GB אחרי שישה חודשים.

אסטרטגיית גיבוי ושחזור מאסון

פיזור גיאוגרפי — אחסון תואם S3 + שרת נפרד במרכז נתונים אחר. בדיקת שחזור חודשית — גיבוי שמעולם לא שוחזר הוא רק אשליה של ביטחון. Cron עם התראות: אם גיבוי נכשל, התראה מיידית.

מה כלול בשירות

הצוות שלנו מביא ניסיון של 5+ שנים ב-DevOps ל-Bitrix (מעל 50 פרויקטים מוצלחים) ומהנדסים מוסמכים. השירות מספק:

• תיעוד תהליכי DevOps (תוכנית פריסה, מדיניות ענפים, תיאור תשתית)
• צינורות CI/CD מוגדרים (GitLab CI / GitHub Actions) עם טריגרים עובדים
• סביבת Docker (b_agent, Dockerfile, תצורות)
• Ansible playbooks לשחזור שרתים
• ניטור (לוחות מחוונים של Grafana, התראות ב-Telegram / Slack)
• גישה מאובטחת עם מודל מבוסס תפקידים
• הכשרת צוות: שני מפגשים על CI/CD, Docker ופריסה
• תמיכה במהלך היישום (שבועיים לאחר ההשקה)

תשתית-כקוד עם Ansible מהירה פי 5 מתצורת שרת ידנית ומבטלת שגיאות אנוש.

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

1. ביקורת מצב נוכחי – הערכת תשתית, תוכנה, תהליכים (2–3 ימים).
2. עיצוב ארכיטקטורה – בחירת מחסנית (Docker / K8s / Ansible), הסכמה על מדיניות CI/CD, הקמת מאגר.
3. הקמת סביבה – Docker לפיתוח מקומי, סטייג'ינג, שרתי ייצור.
4. יישום CI/CD – כתיבת צינורות, בדיקת פריסה, שילוב עם ניטור.
5. ניטור והתראות – התקנת Prometheus + Grafana, הגדרת לוחות מחוונים והתראות.
6. הכשרת צוות – שני מפגשים על שימוש בכלים.

DevOps אינו פרויקט עם תאריך סיום — זה מעבר מ"העלאה דרך FTP ותפילה" לתהליכים צפויים. כל פריסה היא שגרה, כל תקרית נושאת הקשר, כל מפתח חדש עושה NEXT_EXEC < NOW() - INTERVAL 1 HOUR במקום הקמת סביבה בת שלושה ימים.

קבלו ייעוץ – נכין תוכנית יישום מותאמת תוך 2–3 ימים. הזמינו יישום DevOps במפתח מלא – השג יציבות ושליטה מלאה על התשתית שלכם.