Налаштування деплою сайту на Azure (App Service)

Налаштування деплою сайту на Azure (App Service)

Уявіть: ви push'ите код у main, за хвилину він уже на production без жодної секунди простою. Жодних ручних FTP-завантажень, жодних 502 помилок серед ночі. Саме так виглядає правильно налаштований деплой на Azure App Service. Ми бачили десятки проєктів, де дрібні помилки в конфігурації — невірний runtime, відсутність змінних оточення, кривий CI/CD — призводили до годин даунтайму. Розповідаємо, як цього уникнути.

Правильне налаштування Azure App Service включає кілька ключових компонентів: вибір відповідного плану, автоматизація збірки та деплою, організація оточень через Deployment Slots та налаштування автоскейлінгу. Нижче — конкретні кроки, які ми застосовуємо в кожному проєкті.

Створення App Service

App Service Plan — це основа. Для продакшену вибираємо рівень 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 запускається автоматично при кожному push у main, і через 2–3 хвилини нова версія вже на сервері.

Чому Deployment Slots — must have для production?

Deployment Slots — це ізольовані оточення всередині одного App Service. Ви деплоїте нову версію в staging, тестуєте, потім миттєво перемикаєте (swap) на production. Swap займає секунди, користувачі не помічають перемикання. Якщо щось пішло не так — відкат однією дією.

# Створити 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 

Ми використовуємо цю техніку у всіх продакшен-проєктах. Один інтернет-магазин після впровадження слотів перестав простоювати вночі — кешування та підключення до БД не скидаються при swap, якщо налаштовано правильно.

Як підключити кастомний домен та SSL?

Після деплою потрібно прив'язати свій домен. Azure App Service підтримує безкоштовні SSL-сертифікати від Let's Encrypt або власні з Key Vault. Процес:

1. У порталі Azure додайте custom domain у розділі Custom domains.
2. Прив'яжіть SSL-сертифікат (безкоштовний або свій).
3. Вкажіть прив'язку TLS/SSL для домену.

Порада: використовуйте Azure Key Vault для зберігання сертифікатів — це безпечніше, ніж зберігати їх у файлах.

Автоскейлінг: коли сайт зростає

App Service Plan вміє автоматично масштабуватися за метриками. Налаштування через 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 з runtime Azure. Перевірте az webapp config show та порівняйте з локальним середовищем.
• Змінні оточення не підхоплюються: задавайте їх через az webapp config appsettings set, а не через .env-файл в архіві.
• SSL-сертифікат не працює: обов'язково вкажіть прив'язку в порталі Azure після додавання сертифіката.

Що входить у налаштування під ключ

Відзначимо: коли ви довіряєте нам налаштування деплою на Azure App Service, ми:

• Аналізуємо ваш проєкт та підбираємо оптимальний план (ми працюємо з Azure понад 5 років, налаштували деплой для 50+ проєктів)
• Налаштовуємо CI/CD через GitHub Actions або Azure DevOps
• Підключаємо Deployment Slots з автоматичним swap та zero-downtime
• Прив'язуємо кастомний домен та SSL-сертифікат
• Налаштовуємо автоскейлінг та моніторинг
• Документуємо всю конфігурацію

Ми гарантуємо, що після налаштування ви зможете деплоїти однією кнопкою. Зв'яжіться з нами, щоб обговорити ваш проєкт — ми оцінимо його за 1 день та запропонуємо оптимальне рішення.

Строки реалізації

Не відкладайте — замовте консультацію, і ми зробимо ваш деплой надійним та автоматичним.