פריסה בלתי ניתנת לשינוי: שחזור שחרור מובטח

"עובד בסביבת staging, לא עובד ב-prod" — קלאסיקה שכמעט תמיד מסתכמת בדבר אחד: לשרתי הייצור יש מצב מצטבר. מישהו התקין חבילה ידנית בלי לבצע commit. מישהו ערך קובץ הגדרות ישירות. קבצים מפריסות ישנות מצטברים. Immutable Deployment מבטל את קטגוריית הבעיות הזו לחלוטין: השרת לא משתנה — הוא מוחלף. הרעיון מתואר במאמר על תשתית בלתי ניתנת לשינוי. אנו מיישמים אסטרטגיה זו באופן מלא, מביקורת ועד הגדרת GitOps, ומבטיחים יכולת חיזוי לכל שחרור. הניסיון שלנו: למעלה מ-6 שנים ב-DevOps, למעלה מ-40 פרויקטי הטמעת GitOps מוצלחים. החיסכון השנתי מביטול סחיפת תצורה יכול להיות משמעותי, וזמן הפתרון הממוצע יורד ל-5–10 דקות — מהיר פי 6–8 בהשוואה לגישה הניתנת לשינוי.

למה Immutable Deployment עדיף על שרתים ניתנים לשינוי?

שרתים ניתנים לשינוי הם כמו כדור שלג — כל פעולה ידנית משאירה סימן. עם הזמן, ההבדלים בין dev ל-prod הופכים לקטסטרופליים: גרסאות ספריות שונות, תצורות, הרשאות. הגישה הבלתי ניתנת לשינוי מבטלת זאת: אותן הוראות בנייה מייצרות את אותה תמונה על כל מכונה ובכל זמן. התמונה נבנית פעם אחת, מתויגת עם hash של ה-commit או גרסה סמנטית, ואותה תמונה עוברת דרך כל הסביבות — מ-dev ועד prod. אין apt-get upgrade בייצור, אין sed -i על תצורות חיות. זה מקצר את זמן החזרה לאחור מ-20–30 דקות ל-2–3 דקות, ומספר התקריות הקשורות לסחיפת תצורה יורד ב-95%. אפילו תדירות הפריסה יכולה לעלות מפעם בשבוע למספר פעמים ביום — ללא אובדן יציבות.

ב-Docker זה נראה כך: לתמונת הבסיס חייבת להיות גרסה מדויקת, לא latest:

FROM python:3.11.9-slim-bookworm
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER nonroot
ENTRYPOINT ["gunicorn", "app:wsgi"]

תג התמונה ב-Kubernetes Deployment הוא תמיד ספציפי, אף פעם לא FROM python:3.11.9-slim-bookworm WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . USER nonroot ENTRYPOINT ["gunicorn", "app:wsgi"] :

spec: containers: - name: api image: registry.example.com/api:a3f8c21d imagePullPolicy: IfNotPresent 

:latest — אם התמונה עם התג הזה כבר קיימת על הצומת, אל תמשוך שוב. עם תגים בלתי ניתנים לשינוי, זה בטוח.

איך לגרסאות תצורה?

חוסר השינוי של התמונה אומר שתצורת הסביבה — סודות, URLs, דגלי תכונה — לא יכולה להיות חלק מהתמונה. היא מועברת דרך משתני סביבה או ConfigMap/Secret מותקן. חשוב: ConfigMap ו-Secret צריכים להיות גם הם עם גרסאות. spec: containers: - name: api image: registry.example.com/api:a3f8c21d imagePullPolicy: IfNotPresent היא גרסה חדשה של התצורה, imagePullPolicy: IfNotPresent נשארת ומשמשת את ה-pods הישנים במהלך עדכון מתגלגל. לאחר המעבר המלא, הגרסה הישנה נמחקת.

ה-External Secrets Operator + Vault מטפל בזה בצורה נקייה יותר: סודות מאוחסנים ב-Vault, ESO מסנכרן אותם ל-Kubernetes Secrets, ויוצר אותם מחדש כאשר Vault משתנה.

פריסה באמצעות החלפה, לא עדכון

ה-api-config-v3 הסטנדרטי מבצע עדכון מתגלגל: ה-pods הישנים נעלמים, חדשים נכנסים. זה בלתי ניתן לשינוי ברמת ה-pod, אבל אובייקט ה-Deployment נשאר ניתן לשינוי. גישה נקייה יותר היא GitOps: כל שינוי רק דרך PR ב-Git, ArgoCD מסנכרן את הקלאסטר עם המאגר.

---
# argocd/application.yaml
spec:
  source:
    repoURL: https://github.com/company/k8s-manifests
    targetRevision: HEAD
    path: apps/api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

api-config-v2 — אם מישהו מריץ ידנית kubectl set image, ArgoCD מחזיר אותו למה שיש ב-Git. זה חוסר שינוי ברמת מצב הקלאסטר.

חזרה לאחור היא פריסה של התמונה הקודמת

עם אסטרטגיה בלתי ניתנת לשינוי, חזרה לאחור היא פשוט פריסת התג הישן. אין # argocd/application.yaml spec: source: repoURL: https://github.com/company/k8s-manifests targetRevision: HEAD path: apps/api syncPolicy: automated: prune: true selfHeal: true קסום שמשחזר את ה-ReplicaSet הקודם. פשוט שנה את התג במניפסט (דרך Git revert) ו-ArgoCD מסנכרן.

git revert HEAD # откатываем последний коммит с новым тегом
git push origin main # ArgoCD увидит изменение и задеплоит старый образ

זה לוקח 2-3 דקות. צפוי וניתן לשחזור. העלות הממוצעת של תקריות סחיפת תצורה יכולה להיות משמעותית, כך שחזרה מהירה לאחור משתלמת מיד.

תהליך היישום: מדריך שלב אחר שלב

1. ביקורת תשתית: בדוק Dockerfiles לגרסאות מדויקות, CI/CD לתגים ניתנים לשינוי, קלאסטרים של Kubernetes למצב.
2. הגדרת pipeline: build → tag (SHA + סביבה) → push → deploy. כל התגים בלתי ניתנים לשינוי.
3. הגדרת GitOps: פריסת ArgoCD או FluxCD עם מדיניות self-heal ו-prune.
4. גרסאות ConfigMap ו-Secret: כל תצורה מקבלת גרסה; כאשר משתנה, נוצרת חדשה, הישנה נמחקת לאחר המעבר.
5. בדיקת חזרה לאחור: ודא שהחזרה לאחור עובדת דרך Git revert.
6. תיעוד והדרכה: כתוב runbook וערוך סדנה לצוות.

---
stages:
  - build
  - push
  - deploy
variables:
  IMAGE_TAG: ${CI_COMMIT_SHORT_SHA}
build:
  stage: build
  script:
    - docker build -t registry.example.com/app:${IMAGE_TAG} .
    - docker tag registry.example.com/app:${IMAGE_TAG} registry.example.com/app:latest-production
push:
  stage: push
  script:
    - docker push registry.example.com/app:${IMAGE_TAG}
deploy:
  stage: deploy
  script:
    - sed -i "s|image:.*|image: registry.example.com/app:${IMAGE_TAG}|g" k8s/deployment.yaml
    - git commit -m "Update image tag to ${IMAGE_TAG}"
    - git push
---

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

• ביקורת תשתית: Dockerfiles, CI/CD, קלאסטרים של Kubernetes
• מעבר לתגים בלתי ניתנים לשינוי עם hashes של commits
• הגדרת GitOps (ArgoCD/Flux) עם מדיניות self-heal
• גרסאות ConfigMap ו-Secret עם תמיכה בעדכון מתגלגל
• תיעוד runbook והדרכת צוות
• תמיכה לאחר שחרור למשך שבועיים

העלות מחושבת באופן אישי לאחר ביקורת. קבל ייעוץ — נעריך את הפרויקט שלך ביום אחד. בקש ביקורת תשתית היום כדי למנוע בעיות סחיפת תצורה. שירותי מהנדסי ה-DevOps שלנו להקמת פריסה חלקה יעזרו לך להקים pipeline של CI/CD.