[PHP, Системное администрирование] Apache & Nginx. Связаны одной цепью (2 часть)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
На прошлой неделе в первой части этой статьи мы описали, как построена связка Apache и Nginx в Timeweb. Мы очень благодарны читателям за вопросы и активное обсуждение! Сегодня рассказываем, как реализована доступность нескольких версий PHP на одном сервере и почему мы гарантируем безопасность данных нашим клиентам.
Виртуальный хостинг (Shared-хостинг) предполагает, что на одном сервере размещено множество аккаунтов клиентов. На аккаунте одного клиента, как правило, находится несколько сайтов. Сайты работают как на готовых CMS (например, Bitrix), так и на кастомных. Таким образом, технические требования у всех систем разные, поэтому в рамках одного сервера необходимо управлять несколькими версиями PHP.
В качестве основного веб-сервера мы используем Nginx: он принимает все подключения извне и отдает статический контент. Остальные запросы мы проксируем дальше, на веб-сервер Apache. Здесь и начинается магия: для каждой версии PHP запущен отдельный экземпляр Apache, который слушает определенный порт. Этот порт прописывается в виртуальном хосте клиентского сайта.
О работе Shared-схемы можно прочитать более подробно в первой части статьи.
Shared-схема
Важно отметить, что мы ставим пакеты PHP под разные версии, потому что обычно во всех дистрибутивах лежит только одна версия PHP.
Safety first!
Одна из главных задач виртуального хостинга — обеспечить безопасность данных клиента. Различные аккаунты, находясь на одном сервере, самостоятельны и независимы. Как это работает?
Файлы сайтов хранятся в домашних каталогах самих пользователей, а в виртуальном хосте веб-серверов указываются нужные пути. При этом важно, чтобы веб-серверы, Nginx и Аpache, получили доступ к конечным файлам определенного клиента, так как веб-сервер запускается только от одного пользователя.
Для Nginx используется патч безопасности, разработанный командой Timeweb: этот патч меняет пользователя на того, который указан в конфигурационном файле веб-сервера.
У других хостинг-провайдеров эта проблема может быть решена, например, через манипуляции с расширенными правами файловой системы (ACL).
Для работы Apache используется модуль мультипроцессинга mpm-itk. Он позволяет запускать каждый VirtualHost с собственным идентификатором пользователя и ID группы.
Таким образом, благодаря операциям, описанным выше, мы получаем безопасную изолированную среду для каждого клиента. При этом мы также решаем задачи масштабирования для Shared-хостинга.
Как реализована связка Apache и Nginx, можно прочитать в первой части нашей статьи. Кроме того, там же описана альтернативная конфигурация через Dedicated-схему.
Если у вас остались вопросы к нашим экспертам, пишите в комментариях. Постараемся на всё ответить или описать решение задачи более подробно в следующих статьях.
===========
Источник:
habr.com
===========
Похожие новости:
- [Kubernetes, Серверное администрирование, Системное администрирование] Практические истории из наших SRE-будней. Часть 2
- [PHP] Hire PHP Developers: Cost & Procedure
- [Информационная безопасность, Системное администрирование, Сетевые технологии, Сетевое оборудование] 2. NGFW для малого бизнеса. Распаковка и настройка
- [PHP] Получение видео из Tik Tok без водяного знака
- [DevOps, Серверное администрирование, Системное администрирование] Использование переменных Grafana для большей интерактивности дашбордов (перевод)
- [PHP, ООП, Совершенный код] Вы уверены, что пишете объектно-ориентированный код? (перевод)
- [DevOps, Kubernetes, Серверное администрирование, Системное администрирование] Запускаем Keycloak в HA режиме на Kubernetes (перевод)
- [Amazon Web Services, Angular, Облачные сервисы, Хостинг, Яндекс API] Как разместить статический сайт с помощью Yandex.Cloud Object Storage
- [IT-компании, Системное администрирование, Софт] Microsoft возобновляет выпуск необязательных обновлений для Windows 10 and Windows Server
- [IT-компании, Системное администрирование, Софт] Microsoft признала, что в Windows 10 версии 2004 системный статус сетевого соединения может глючить. Это можно исправить
Теги для поиска: #_php, #_sistemnoe_administrirovanie (Системное администрирование), #_vebserver (веб-сервер), #_php, #_hosting (хостинг), #_blog_kompanii_timeweb (
Блог компании Timeweb
), #_php, #_sistemnoe_administrirovanie (
Системное администрирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:36
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
На прошлой неделе в первой части этой статьи мы описали, как построена связка Apache и Nginx в Timeweb. Мы очень благодарны читателям за вопросы и активное обсуждение! Сегодня рассказываем, как реализована доступность нескольких версий PHP на одном сервере и почему мы гарантируем безопасность данных нашим клиентам. Виртуальный хостинг (Shared-хостинг) предполагает, что на одном сервере размещено множество аккаунтов клиентов. На аккаунте одного клиента, как правило, находится несколько сайтов. Сайты работают как на готовых CMS (например, Bitrix), так и на кастомных. Таким образом, технические требования у всех систем разные, поэтому в рамках одного сервера необходимо управлять несколькими версиями PHP. В качестве основного веб-сервера мы используем Nginx: он принимает все подключения извне и отдает статический контент. Остальные запросы мы проксируем дальше, на веб-сервер Apache. Здесь и начинается магия: для каждой версии PHP запущен отдельный экземпляр Apache, который слушает определенный порт. Этот порт прописывается в виртуальном хосте клиентского сайта. О работе Shared-схемы можно прочитать более подробно в первой части статьи. Shared-схема Важно отметить, что мы ставим пакеты PHP под разные версии, потому что обычно во всех дистрибутивах лежит только одна версия PHP. Safety first! Одна из главных задач виртуального хостинга — обеспечить безопасность данных клиента. Различные аккаунты, находясь на одном сервере, самостоятельны и независимы. Как это работает? Файлы сайтов хранятся в домашних каталогах самих пользователей, а в виртуальном хосте веб-серверов указываются нужные пути. При этом важно, чтобы веб-серверы, Nginx и Аpache, получили доступ к конечным файлам определенного клиента, так как веб-сервер запускается только от одного пользователя. Для Nginx используется патч безопасности, разработанный командой Timeweb: этот патч меняет пользователя на того, который указан в конфигурационном файле веб-сервера. У других хостинг-провайдеров эта проблема может быть решена, например, через манипуляции с расширенными правами файловой системы (ACL). Для работы Apache используется модуль мультипроцессинга mpm-itk. Он позволяет запускать каждый VirtualHost с собственным идентификатором пользователя и ID группы. Таким образом, благодаря операциям, описанным выше, мы получаем безопасную изолированную среду для каждого клиента. При этом мы также решаем задачи масштабирования для Shared-хостинга. Как реализована связка Apache и Nginx, можно прочитать в первой части нашей статьи. Кроме того, там же описана альтернативная конфигурация через Dedicated-схему. Если у вас остались вопросы к нашим экспертам, пишите в комментариях. Постараемся на всё ответить или описать решение задачи более подробно в следующих статьях. =========== Источник: habr.com =========== Похожие новости:
Блог компании Timeweb ), #_php, #_sistemnoe_administrirovanie ( Системное администрирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 22:36
Часовой пояс: UTC + 5