Настройка деплоя сайта на 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 день и предложим оптимальное решение.

Срок реализации

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