WordPress в Службе приложений

Azure Front Door
Azure Load Balancer
Виртуальная сеть Azure
Служба приложений Azure
База данных Azure для MySQL

В этой статье описывается архитектура для небольших и средних установок WordPress на Azure. Архитектура использует Служба приложений Azure для размещения WordPress и управляемые службы Azure для уровней баз данных, сетевой инфраструктуры и доставки контента. Сведения о более крупных или ресурсоемких установках см. в разделе варианты размещения WordPress на Azure.

Архитектура

Архитектурная диаграмма WordPress на службе приложений. Azure Front Door направляет трафик к веб-приложениям. База данных Azure для MySQL хранит динамическое содержимое.

Влево стрелка указывает из Интернета на Azure Front Door с Брандмауэр веб-приложений Azure. Пунктирная стрелка, помеченная как статический веб-контент, указывает от Хранилище BLOB-объектов Azure в разделе учетной записи хранения на Azure Front Door с Брандмауэр веб-приложений Azure. Стрелка указывает от Azure Front Door с Брандмауэр веб-приложений Azure к службе приложений Azure. Стрелка указывает из службы приложений на частную конечную точку. Стрелка указывает от этой строки на Хранилище BLOB-объектов. Стрелка указывает от частной конечной точки на гибкий сервер базы данных Azure для MySQL (основной). Стрелка указывает с первичного сервера на хранилище класса Premium. Пунктирная стрелка с надписью "локально избыточная синхронная репликация данных и журналов" ведет из хранилища уровня "Премиум" основного сервера в хранилище уровня "Премиум" резервного сервера. Стрелка указывает от гибкого резервного сервера База данных Azure для MySQL к его премиальному хранилищу. Вверху пунктирная стрелка помечена связанными точками из частной зоны DNS в виртуальную сеть.

Скачайте файл Visio для этой архитектуры.

Примечание.

Это решение можно расширить, реализуя советы и рекомендации, которые не относятся к любому методу размещения WordPress. Дополнительные сведения о развертывании установки WordPress см. в разделе WordPress на Azure.

Поток данных

Этот сценарий охватывает масштабируемую установку WordPress, которая выполняется в службе приложений.

Следующий поток данных соответствует предыдущей схеме:

Следующий поток данных соответствует предыдущей схеме:

  • Пользователи получают доступ к фронтенд веб-сайту через Azure Front Door с включённым Брандмауэр веб-приложений Azure.

  • Azure Front Door распределяет запросы по веб-приложениям службы Azure App Service, в которых работает WordPress. Если запрошенное содержимое не кэшировано, Azure Front Door извлекает его из веб-приложений.

  • Приложение WordPress подключается к База данных Azure для MySQL гибкому серверу через частную конечную точку и извлекает динамическое содержимое из базы данных.

  • База данных Azure для MySQL поддерживает высокий уровень доступности через резервный сервер.

  • Все статическое содержимое размещается в Хранилище BLOB-объектов Azure.

Компоненты

  • Служба приложений — это платформа как услуга (PaaS) для создания, развертывания и масштабирования веб-приложений. В этой архитектуре служба приложений размещает приложение WordPress.

  • База данных Azure для MySQL гибкий сервер — это управляемая служба реляционной базы данных на основе ядра СУБД MySQL с открытым исходным кодом. В этой архитектуре он хранит данные WordPress.

  • Защита от атак DDoS Azure — это служба безопасности сети, которая предоставляет расширенные функции защиты от атак типа "отказ в обслуживании" (DDoS). В этой архитектуре защита от атак DDoS помогает защитить общедоступный IP-адрес от атак DDoS.

  • Azure Front Door — это сеть доставки содержимого и глобальная подсистема балансировки нагрузки. В этой архитектуре Azure Front Door служит точкой входа приложения для веб-пользователей.

  • Azure Virtual Network — это сетевая служба, которая позволяет Azure ресурсам взаимодействовать друг с другом, Интернетом и локальными сетями, обеспечивая сегментацию и изоляцию. В этой архитектуре служба приложений и внутренние компоненты доступны только через частные подключения в виртуальной сети.

  • Хранилище BLOB-объектов — это служба хранилища объектов, оптимизированная для больших объемов неструктурированных данных. В этой архитектуре хранилище BLOB-объектов размещает все статическое содержимое для приложения WordPress.

  • Группы безопасности сети (NSG) используют правила безопасности, чтобы разрешить или запретить сетевой трафик по исходному или целевому IP-адресу, порту и протоколу. В этой архитектуре правила NSG ограничивают поток трафика между подсетями.

  • Шаблон WordPress в службе приложений — это шаблон управляемого решения для размещения WordPress в службе приложений. В этой архитектуре шаблон предоставляет предварительно настроенное развертывание WordPress, включающее службу приложений и другие службы Azure, описанные в этом разделе.

Альтернативные варианты

Используйте Azure Managed Redis для размещения кэша ключевых значений для подключаемых модулей оптимизации производительности WordPress. Кэш можно совместно использовать в веб-приложениях App Service.

Подробности сценария

Этот пример сценария применяется к небольшим установкам WordPress среднего размера.

Потенциальные варианты использования

  • События мультимедиа, вызывающие всплеск трафика
  • Блоги, использующие WordPress в качестве системы управления содержимым
  • Веб-сайты для бизнеса или электронной коммерции, использующие WordPress
  • Веб-сайты, созданные с помощью других систем управления содержимым

Рекомендации

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которые являются набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Для получения дополнительной информации см. Well-Architected Framework.

Надежность

Надежность помогает гарантировать, что ваше приложение может выполнять обязательства, которые вы выполняете для клиентов. Для получения дополнительной информации см. Контрольный список проверки конструкции на надежность.

При развертывании этого решения рассмотрите следующие рекомендации.

  • Настройте automated backups для База данных Azure для MySQL. Определите период хранения, соответствующий целям точки восстановления (RPOs). Периодически тестируйте процесс восстановления, чтобы проверить надежность резервного копирования.

  • Служба приложений обеспечивает встроенную балансировку нагрузки и проверки работоспособности. Эти функции помогают поддерживать доступность при сбое веб-приложения в App Service.

  • Azure Front Door может обслуживать кэшированные ответы, когда источник временно недоступен. Эта возможность ограничивает потерю доступности, но не заменяет полное решение для доступности.

  • Хранилище BLOB-объектов можно реплицировать в парный регион для избыточности данных в нескольких регионах. Дополнительные сведения см. в статье Репликация службы хранилища Azure.

  • Чтобы увеличить доступность База данных Azure для MySQL, включите высокий уровень доступности. Высокий уровень доступности в той же зоне доступности создает резервный сервер в той же зоне доступности, что и основной сервер. Для более надежной изоляции отказов используйте высокую доступность с зональным резервированием, которая размещает сервер резерва в другой зоне доступности. Используйте уровень вычислений "Общего назначения" или "Критически важный для бизнеса", чтобы обеспечить высокий уровень доступности. Дополнительные сведения см. в параметрах высокой доступности , которые соответствуют вашим потребностям.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и неправильного использования ценных данных и систем. Дополнительные сведения см. в контрольном списке проектных проверок по безопасности.

При развертывании этого решения рассмотрите следующие рекомендации.

  • Используйте Брандмауэр веб-приложений Azure в Azure Front Door для защиты трафика виртуальной сети, который передается на внешний уровень приложений. Дополнительные сведения см. в статье Брандмауэр веб-приложений Azure в Azure Front Door.

  • Используйте частные конечные точки для всех внутренних служб, включая База данных Azure для MySQL и Хранилище BLOB-объектов. Частные конечные точки сохраняют трафик в виртуальной сети и предотвращают доступ к общедоступному Интернету. Дополнительные сведения см. в разделе Приватный канал Azure.

  • Блокировать исходящий интернет-трафик из уровня базы данных.

  • Блокировать общедоступный доступ к частному хранилищу.

  • Обновляйте ядро WordPress, темы и плагины до последних версий, чтобы устранить известные уязвимости безопасности. Удалите подключаемые модули и темы, которые больше не нужны.

  • Ограничьте доступ к панели администрирования WordPress (/wp-admin), создав Брандмауэр веб-приложений Azure настраиваемые правила на Azure Front Door. RequestUri Используйте условие соответствия для сопоставления /wp-admin путей, в сочетании с условием IP-адреса, чтобы разрешить доступ только из известных диапазонов IP-адресов. Ограничения доступа к службе приложений применяются ко всему сайту, а не к отдельным путям URL, поэтому они не подходят для управления, специфичного для путей.

Дополнительные сведения о безопасности WordPress см. в статье "Общие советы по безопасности и производительности WordPress" и документация по безопасности Azure.

Оптимизация затрат

Оптимизация затрат фокусируется на способах сокращения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в контрольном списке проектной экспертизы для оптимизации затрат.

Ознакомьтесь со следующими рекомендациями по затратам при развертывании этого решения:

  • Ожидания трафика в ГБ в месяц: Объем трафика влияет на затраты больше всего. Количество экземпляров службы приложений, которые вам нужны, и стоимость исходящей передачи данных зависят от полученного трафика. Обслуживание содержимого с помощью Azure Front Door может снизить затраты на передачу исходящих данных.

  • Hosted data: Рассмотрим данные, размещенные в Хранилище BLOB-объектов. Цены на хранилище зависят от используемой емкости.

  • Процент записи: Рассмотрите, сколько новых данных вы записываете на веб-сайт и размещаете в хранилище. Определите, нужны ли новые данные. Для развертываний с несколькими регионами новые данные, записываемые на веб-сайт, сопоставляются с данными, реплицируемыми в разных регионах.

  • Статический и динамический контент: Отслеживайте производительность и емкость хранилища базы данных, чтобы определить, поддерживает ли сайт номер SKU с более низкой стоимостью. База данных хранит динамическое содержимое и Azure Front Door кэширует статическое содержимое.

  • Оптимизация службы приложений: Дополнительные сведения об оптимизации затрат службы приложений см. в разделе "Оптимизация затрат".

Операционная эффективность

Операционное совершенство охватывает процессы, которые обеспечивают развертывание приложения и его работу в производственной среде. Для получения дополнительной информации см. Контрольный список для оценки проектирования с точки зрения операционной эффективности.

При развертывании этого решения рассмотрите следующие рекомендации.

  • Включите Application Insights для мониторинга производительности приложений, доступности и шаблонов использования. Используйте данные мониторинга для выявления и устранения проблем, прежде чем они влияют на пользователей.

  • Используйте слоты развертывания в службе приложений для этапов обновления ядра WordPress. Разверните новую версию в промежуточном слоте и проверьте совместимость темы и подключаемого модуля перед переключением в рабочую среду. Выполните резервное копирование экземпляра База данных Azure для MySQL перед переключением, так как WordPress автоматически применяет миграции схем к общей базе данных, когда администратор входит в систему после обновления.

  • Автоматизация развертываний инфраструктуры с помощью Bicep или Terraform. Инфраструктура как код (IaC) помогает обеспечить согласованность между средами и надежно перестроить среды.

  • Настройте оповещения Azure Monitor для ключевых метрик, таких как использование ЦП службы приложений, количество подключений к базе данных и время отклика. Используйте оповещения для реагирования на операционные проблемы, прежде чем они влияют на пользователей.

Эффективность производительности

Эффективность производительности — это способность рабочей нагрузки эффективно масштабироваться в соответствии с требованиями пользователей. Для получения дополнительной информации см. контрольный список проверки конструкции для эффективности производительности.

При развертывании этого решения рассмотрите следующие рекомендации.

  • Включите функцию автомасштабирования в Службе приложений для автоматического масштабирования количества экземпляров. Вы можете задать триггер автомасштабирования для реагирования на запрос клиента или на основе расписания. Дополнительные сведения см. в статье "Начало работы с автомасштабированием" в Azure.

  • Используйте Azure Managed Redis для кэширования данных сеанса Hypertext Preprocessor (PHP) и часто запрашиваемых объектов WordPress. Выгрузите эти элементы из базы данных, чтобы уменьшить нагрузку запросов и улучшить время загрузки страницы.

  • Настройте правила кэширования Azure Front Door для обслуживания статических ресурсов из узлов сети на периферии. Кэширование на периферии, чтобы уменьшить задержку для пользователей, которые географически удалены от региона службы приложений.

  • Используйте последнюю поддерживаемую версию PHP в Службе приложений для улучшения производительности и безопасности. Убедитесь, что версия и подключаемые модули WordPress совместимы перед обновлением.

Соавторы

Microsoft поддерживает эту статью. Следующие авторы написали эту статью.

Основной автор:

Другие участники:

  • Адриан Калинеску | Старший архитектор облачных решений
  • Эндрю Карди | Старший инженер по программному обеспечению

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Документация по продукту:

Модули обучения Майкрософт: