הגדרת פריסה ל-Azure App Service

הגדרת פריסת Azure App Service

תארו לעצמכם שאתם דוחפים קוד לענף הראשי ובתוך דקה הוא חי בייצור ללא שנייה אחת של השבתה. ללא העלאות FTP ידניות, ללא שגיאות 502 באמצע הלילה. זה בדיוק איך נראית פריסת Azure App Service מוגדרת כראוי. ראינו עשרות פרויקטים שבהם שגיאות תצורה קטנות — ריצה שגויה, משתני סביבה חסרים, CI/CD שבור — הובילו לשעות של השבתה. הנה איך להימנע מכך.

הגדרה נכונה של Azure App Service כוללת מספר רכיבים מרכזיים: בחירת התוכנית הנכונה, אוטומציה של בניות ופריסות, ארגון סביבות באמצעות Deployment Slots, והגדרת קנה מידה אוטומטי. להלן הצעדים הקונקרטיים שאנו מיישמים בכל פרויקט.

יצירת App Service

תוכנית ה-App Service היא הבסיס. לייצור, אנו בוחרים לפחות רמת B2 כדי להבטיח מרווח ביצועים עבור PHP 8.3 או Node.js. פקודת Azure CLI:

az group create --name myapp-rg --location westeurope
az appservice plan create \
  --name myapp-plan \
  --resource-group myapp-rg \
  --sku B2 \
  --is-linux
az webapp create \
  --name myapp-prod \
  --resource-group myapp-rg \
  --plan myapp-plan \
  --runtime "PHP|8.3"

הפריסה הראשונה יכולה להתבצע דרך FTP או zip, אך אנו ממליצים להקים אינטגרציה רציפה מיד.

איך להקים CI/CD עם GitHub Actions?

GitHub Actions היא הבחירה האופטימלית לאוטומציה. הכנו workflow אוניברסלי שאנו מתאימים לכל טכנולוגיה:

---
# .github/workflows/azure-deploy.yml
name: Deploy to Azure
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader
      - name: Build frontend
        run: npm ci && npm run build
      - name: Deploy to Azure Web App
        uses: azure/webapps-deploy@v3
        with:
          app-name: myapp-prod
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}
          package: .

חשוב: שמרו את publish-profile בסודות GitHub — לעולם אל תכניסו סיסמאות למאגר. ה-workflow רץ אוטומטית בכל דחיפה לענף הראשי, ובתוך 2–3 דקות הגרסה החדשה חיה.

למה Deployment Slots הם חובה לייצור?

Deployment Slots הם סביבות מבודדות בתוך אותו App Service. אתם פורסים גרסה חדשה ל-staging, בודקים אותה, ואז מחליפים מיידית לייצור. ההחלפה אורכת שניות; המשתמשים לא שמים לב לשינוי. אם משהו משתבש, החזרה לאחור היא פעולה אחת.

# Создать staging slot
az webapp deployment slot create \
  --name myapp-prod \
  --resource-group myapp-rg \
  --slot staging

# Деплой в staging
az webapp deploy \
  --name myapp-prod \
  --resource-group myapp-rg \
  --slot staging \
  --src-path deployment.zip

# Swap staging → production (мгновенно, zero-downtime)
az webapp deployment slot swap \
  --name myapp-prod \
  --resource-group myapp-rg \
  --slot staging \
  --target-slot production

# Swap Back если что-то пошло не так
az webapp deployment slot swap \
  --name myapp-prod \
  --resource-group myapp-rg \
  --slot production \
  --target-slot staging

אנו משתמשים בטכניקה זו בכל פרויקטי הייצור. חנות מקוונת אחת לאחר יישום slots ביטלה השבתות ליליות — מטמון וחיבורי מסד נתונים אינם מתאפסים במהלך החלפה כשמוגדר כראוי.

איך לחבר דומיין מותאם אישית ו-SSL?

לאחר הפריסה, עליכם לקשר את הדומיין שלכם. Azure App Service תומך בתעודות SSL חינמיות מ-Let's Encrypt או בתעודות משלכם מ-Key Vault. התהליך:

1. בפורטל Azure, הוסיפו את הדומיין המותאם אישית תחת הסעיף 'Custom domains'.
2. קשרו תעודת SSL (חינמית או משלכם).
3. ציינו את קישור ה-TLS/SSL עבור הדומיין שלכם.

טיפ: השתמשו ב-Azure Key Vault לאחסון תעודות — זה מאובטח יותר מאחסון בקבצים.

קנה מידה אוטומטי: כשהאתר שלכם גדל

תוכנית ה-App Service יכולה להתאים את עצמה אוטומטית בהתבסס על מדדים. הגדרה דרך CLI:

az monitor autoscale create \
  --resource-group myapp-rg \
  --resource myapp-plan \
  --resource-type Microsoft.Web/serverfarms \
  --name autoscale-rule \
  --min-count 2 \
  --max-count 10 \
  --count 2
az monitor autoscale rule create \
  --autoscale-name autoscale-rule \
  --resource-group myapp-rg \
  --scale out 2 \
  --condition "Percentage CPU > 75 avg 5m"

עם קנה מידה אוטומטי נכון, פרויקט יכול להתמודד עם עלייה של פי 10 בתעבורה ללא התערבות ידנית. לדוגמה, הלקוח שלנו — שירות הזמנות מקוון — התמודד עם Black Friday עם גל תעבורה של פי 15 תוך שמירה על היענות.

השוואת שיטות פריסה

GitHub Actions מהירה פי 10 מהעלאת FTP ידנית ומבטלת לחלוטין טעויות אנוש. עם FTP, אתם מבזבזים 10 דקות בהעלאת קבצים; עם CI/CD, זה 2 שניות לכל commit.

טעויות נפוצות ופתרונות

• 502 Bad Gateway: לרוב נובעת מחוסר התאמה בגרסה בין סביבת הריצה של PHP/Node.js לסביבת Azure. בדקו את az group create --name myapp-rg --location westeurope az appservice plan create \ --name myapp-plan \ --resource-group myapp-rg \ --sku B2 \ --is-linux az webapp create \ --name myapp-prod \ --resource-group myapp-rg \ --plan myapp-plan \ --runtime "PHP|8.3" והשוו עם התצורה המקומית שלכם.
• משתני סביבה לא נקלטים: הגדירו אותם דרך # .github/workflows/azure-deploy.yml name: Deploy to Azure on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup PHP uses: shivammathur/setup-php@v2 with: { php-version: '8.3' } - name: Install dependencies run: composer install --no-dev --optimize-autoloader - name: Build frontend run: npm ci && npm run build - name: Deploy to Azure Web App uses: azure/webapps-deploy@v3 with: app-name: myapp-prod publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }} package: . , לא על ידי הכללת קובץ .env בארכיון.
• תעודת SSL לא עובדת: ודאו שקישרתם את התעודה בפורטל Azure לאחר הוספתה.

מה כלול בהגדרה סוהר

כשאתם מפקידים בידינו את הגדרת פריסת ה-Azure App Service שלכם, אנו:

• מנתחים את הפרויקט שלכם ובוחרים את התוכנית האופטימלית (עבדנו עם Azure למעלה מ-5 שנים והגדרנו פריסות ל-50+ פרויקטים)
• מקימים CI/CD דרך GitHub Actions או Azure DevOps
• מחברים Deployment Slots עם החלפה אוטומטית וללא השבתה
• קושרים דומיין מותאם אישית ותעודת SSL
• מגדירים קנה מידה אוטומטי וניטור
• מתעדים את כל התצורה

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

לוח זמנים ליישום

אל תדחו — בקשו ייעוץ, ואנו נהפוך את הפריסה שלכם לאמינה ואוטומטית.