Web сервер на CentOS 8
Итак, наш веб сервер centos будет состоять из трех основных компонентов — http сервера apache, интерпретатора языка программирования php и сервера баз данных mysql. Познакомимся немного с каждым из них:
- Apache — http сервер или просто веб сервер апач. Является кросплатформенным ПО, поддерживающим практически все популярные операционные системы, в том числе и Windows. Ценится прежде всего за свою надежность и гибкость конфигурации, которую можно существенно расширить благодаря подключаемым модулям, которых существует великое множество. Из недостатков отмечают большую требовательность к ресурсам, по сравнению с другими серверами. Держать такую же нагрузку, как, к примеру, nginx, apache не сможет при схожих параметрах железа.
- PHP — язык программирования общего назначения, который чаще всего применяется в веб разработке. На сегодняшний день это самый популярный язык в этой области применения. Поддерживается практически всеми хостинг-провайдерами.
- Mysql — система управления базами данных. Завоевала свою популярность в среде малых и средних приложений, которых очень много в вебе. Так что, как и php, на сегодняшний день является самой популярной бд, использующейся на веб сайтах. Поддерживается большинством хостингов. В CentOS вместо mysql устанавливается mariadb — ответвление mysql. Они полностью совместимы, возможен в любой момент переход с одной субд на другую и обратно. Я встречал информацию, что mariadb пошустрее работает mysql и люди потихоньку перебираются на нее. На практике мне не довелось это наблюдать, так как никогда не работал с нагруженными базами данных. А в обычных условиях разница не заметна.
Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:
| Процессор | 2 ядра |
| Память | 3 Gb |
| Диск | 30 Gb SSD |
Хочу сразу уточнить, что разбираю базовую дефолтную настройку. Для улучшения быстродействия, повышения надежности и удобства пользования нужно установить еще несколько инструментов, о чем я расскажу отдельно. В общем случае для организации веб сервера будет достаточно того, что есть в этой статье.
Конфигурации виртуальных хостов
Стандартный виртуальный хост находится в файле default в каталоге sites-available.
Чтобы ознакомиться с общим форматом виртуального хоста, откройте этот файл:
По умолчанию виртуальный хост обрабатывает запросы на порте 80.
Это не означает, что веб-сервер обязательно будет обрабатывать каждый запрос через этот порт. Apache может переопределять конфигурации.
Настройки виртуального хоста высшего уровня
Эти параметры устанавливаются в разделе Virtual Host и применяются ко всему виртуальному хосту.
Директива ServerName задаёт доменное имя или IP-адрес сервера. Это индивидуальный параметр каждого виртуального хоста, который может переопределить настройки по умолчанию, если он совпадает со значением ServerName.
Параметр ServerAlias позволяет добавить алиасы сайта – альтернативные имена и пути, ведущие к одному контенту. Так, например, часто устанавливается алиас домена с www.
DocumentRoot задаёт каталог, в котором веб-сервер хранит контент данного виртуального хоста. В Ubuntu для этого по умолчанию используется /var/www.
В конфигурации виртуального хоста есть специальный раздел для настройки обработки отдельных каталогов файловой системы. Эти настройки также можно переопределять.
Сначала виртуальный хост предлагает набор правил для каталога / (root-каталог). Этот раздел обеспечит базовую конфигурацию виртуального хоста, поскольку он относится ко всем файлам, которые обслуживаются в файловой системе.
По умолчанию Ubuntu не накладывает никаких ограничений на файловую систему. Apache рекомендует добавить несколько стандартных ограничений доступа, например:
Это заблокирует доступ ко всему контенту, если в последующих определениях каталогов не указано иное.
Далее идут настройки каталога document root, в которых параметр allow from all переопределяет параметры каталога /.
Параметр AllowOverride позволяет настроить переопределение конфигураций с помощью файлов .htaccess. Чтобы переопределить настройки, файл .htaccess должен находиться в каталоге с контентом. По умолчанию эта функция отключена.
Настройки Alias и ScriptAlias
Иногда перед разделом Directory идут параметры Alias и ScriptAlias.
Директива Alias позволяет добавлять к обслуживаемому контенту каталоги вне DocumentRoot.
ScriptAlias работает аналогичным образом, но содержит путь к каталогам с исполняемыми файлами.
К примеру, такая строка в виртуальном хосте для сайта example.com откроет доступ к контенту в каталоге /path/to/content/ при запросе example.com/content/.
Помните, что открывая доступ к дополнительным каталогам, нужно устанавливать ограниченные привилегии на них.
Включение сайтов и модулей в Apache
Создав файл виртуального хоста, вы можете включить его. Для этого нужно создать символическую ссылку на файл в каталоге sites-enabled:
Включив сайт, перезапустите Apache, чтобы веб-сервер перечитал конфигурации:
Чтобы отключить виртуальный хост, нужно удалить символьную ссылку из sites-enabled:
После этого нужно снова перезапустить веб-сервер:
Включить и отключить модуль Apache можно с помощью следующих команд (соответственно):
Они работают так же, как и ранее упомянутые команды a2ensite иa2dissite. После включения или отключения модуля нужно перезапускать веб-сервер.
Шаг 6 — Установка и настройка Nginx
На этом шаге мы выполним установку Nginx и настроим домены и как виртуальные хосты Nginx. Полное руководство по настройке виртуальных хостов в Nginx можно найти в документе .
Установите Nginx с помощью диспетчера пакетов:
Затем удалите соединение symlink по умолчанию виртуального хоста, поскольку мы больше не будем его использовать:
Позднее мы создадим собственный сайт по умолчанию ().
Теперь мы создадим виртуальные хосты для Nginx, используя ту же процедуру, что использовалась для Apache. Вначале необходимо создать корневые каталоги документов для обоих сайтов:
Мы будем хранить сайты Nginx в каталоге , где Nginx требуется хранить их по умолчанию. Вы можете поместить их в каталог с сайтами Apache, но разделение поможет привязать сайты к Nginx.
Как и в случае с виртуальными хостами Apache, после завершения настройки следует создать файлы и для тестирования:
Теперь создайте файл виртуального хоста для домена :
Nginx вызывает области серверных блоков файла конфигурации Создайте серверный блок для главного виртуального хоста, . Директива делает его виртуальным хостом по умолчанию для обработки запросов HTTP, не соответствующих никакому другому виртуальному хосту.
/etc/nginx/sites-available/example.com
Сохраните и закройте файл. Создайте файл виртуального хоста для второго домена Nginx, :
Добавьте в файл следующее:
/etc/nginx/sites-available/sample.org
Сохраните и закройте файл.
Затем активируйте оба сайта, создав символические ссылки на каталог :
Протестируйте конфигурацию Nginx и убедитесь в отсутствии проблем с конфигурацией:
При обнаружении ошибок перезагрузите Nginx:
Получите доступ к файлу виртуальных хостов Nginx через браузер по адресам http://example.com/info.php и http://sample.org/info.php. Снова изучите разделы PHP Variables.
должен иметь значение , указывая, что файлы обслуживались Nginx напрямую. должен указывать на каталог, ранее созданный на этом шаге для каждого из сайтов Nginx.
К настоящему моменту мы установили Nginx и создали два виртуальных хоста. Далее мы настроим Nginx на запросы прокси-сервера, предназначенные для доменов Apache.
Разные серверы для статического и динамического контента
Процессы Apache, которые управляют динамическим контентом, потребляют от 3 до 20 Мб памяти. Статический контент требуют всего лишь 1Мб памяти. Процесс, управляющий динамическим контентом, при следующем запросе может предоставлять статический контент.
Что приводит к расходам памяти и замедлению работы сервера. Поэтому рекомендуется разделить серверы на управляющие статическим контентом и динамическим контентом.
Например, можно использовать небольшой Apache в качестве frontend-сервера, предоставляющего статический контент. Запросы на динамический контент будут перенаправляться к другому серверу Apache со всеми необходимыми модулями.
Для подобного перенаправления запросов используются модули mod_proxy и mod_rewrite. Клиент не заметит разницы, и будет считать, что все запросы выполняются одним сервером.
Используя два сервера, можно ускорить работу Apache, выдавая статический контент быстрее и выделяя большее количество памяти для обработки динамического контента.
Настройка mod_security
Для корректной работы установка mod_security «из коробки» нуждается в дополнительной настройке. Стандартный конфигурационный файл настроен на DetectionOnly, то есть, фаервол только отслеживает логи, при этом ничего не блокируя. Чтобы изменить это поведение, отредактируйте файл modsecurity.conf:
Найдите в файле строку:
И измените ее так:
Примечание: при настройке mod_security на производственном сервере рекомендуется изменить эту директиву только после тестирования всех установленных правил.
Следующая директива, которую нужно отредактировать – это SecResponseBodyAccess. Она отвечает за буферизацию тела ответа; ее рекомендуется включать, только если требуется обнаружение и предохранение от утечки данных. Включенная директива (SecResponseBodyAccess On) не только будет использовать больше ресурсов сервера, но и увеличит размер лог-файла, следовательно, ее желательно отключить. Для этого найдите:
И измените значение:
Теперь нужно ограничить максимальный объем данных, который можно передать веб-приложению. За это отвечают 2 директивы:
Директива SecRequestBodyLimit задает максимальный размер данных POST. Если клиент отправляет больше данных, сервер выдаст ошибку . Если в веб-приложении нет механизма загрузки файлов, это значение можно существенно уменьшить. В конфигурационном файле задано следующее:
Что равно 12.5 мегабайтам.
Аналогично работает и директива SecRequestBodyNoFilesLimit. Разница только в том, что данная директива ограничивает размер данных POST за вычетом размера файлов.
Примечание: данное значение рекомендуется устанавливать по принципу ALARP (англ. «as low as reasonably practicable», то есть, исходя из оценки риска и задействованных ресурсов).
По умолчанию в конфигурационном файле задано:
Что равно 128KB.
В данном файле можно найти еще один параметр, влияющий на производительность сервера – это SecRequestBodyInMemoryLimit. Этот параметр задает размер данных тела ответа, который будет помещен в RAM; остальные данные отправятся на жесткий диск (как swap). Поскольку серверы, как правило, работают на SSD, это не проблема; однако, чтобы сэкономить RAM, значение можно уменьшить.
Это стандартное значение (128KB) в конфигурационном файле.
6 ответов
Решение
Стандартная установка Apache Debian будет иметь следующий фрагмент конфигурации:
Слушай 80
# Виртуальные хосты на основе имени SSL еще не поддерживаются, поэтому нет
# NameVirtualHost здесь
Слушай 443
Это говорит apache прослушивать порт 80 и прослушивать порт 443, если настроен mod_ssl. В вашем случае вы бы хотели:
Вам нужно убедиться, что вы запускаете перезапуск, а не операцию перезагрузки на apache, чтобы он обращал внимание на новые директивы Listen. Самое безопасное, что нужно сделать — это остановить Apache, убедиться, что он мертв и запустить его снова
Если эта конфигурация не работает, проверьте файлы журнала на наличие сообщений об ошибках. Вы можете использовать «netstat -lep —tcp», чтобы увидеть, прослушивает ли что-нибудь порт 8080. Наконец, если все остальное не работает, попробуйте запустить apache под strace, чтобы увидеть, пытается ли он подключиться к этому порту и не работает, но не регистрирует проблему.
63
2009-06-18 15:11
Эти ответы великолепны, но они исключают возможность того, что Оуэн уже сделал это («Я добавил «) может означать именно то, на что это похоже (то есть то, что предложил Дэвид).
Если вы уже сделали это и все еще находите, что он не работает, убедитесь, что вы правильно настроили свои директивы для каждого субдомена, который у вас может быть, в том числе и по умолчанию (если он был настроен вручную для прослушивания:80 сразу после имени).
У вас, вероятно, есть такая директива:
Вы должны изменить это на или же ,
7
2009-06-18 15:19
Шаг 1
httpd (apache) для прослушивания порта 80 и прослушивания порта 443, если настроен mod_ssl.
Шаг 2
Шаг 3
(Не все процессы могут быть идентифицированы, информация о не принадлежащих процессах не будет показана, вам нужно быть пользователем root, чтобы увидеть все это.)
5
2009-06-18 16:38
Предполагая запуск Linux как root, как вы можете видеть, слушает ли apache 8080 или нет. Это поможет вам определить, связана ли проблема с тем, что apache не слушает или существуют внешние факторы (например, брандмауэр, selinux и т. Д.), Которые приводят к истечению времени ожидания соединения.
2009-06-18 16:24
Вам может понадобиться настроить сайт на порт 8080, чтобы это работало. Прочитайте документацию по Apache Virtual Hosts. Каждый «сайт» может быть настроен на прием соединений через определенные порты (и IP-адреса и т. Д.). В вашем http.conf есть виртуальный хост, который настроен только для порта 80?
Также вы можете подтвердить, что сервер прослушивает 8080, используя и ищет запись в этом порту.
2009-06-18 14:38
Вы также можете проверить, включен ли SELinux. Конфигурация SELinux по умолчанию может не позволять запускать Apache на нестандартных портах. Вот сайт, который показывает вам, используете ли вы SELinux и как его отключить, если вы не хотите или не используете его возможности. http://www.crypt.gen.nz/selinux/disable_selinux.html
2009-06-18 15:24
Шаг 2. Установка модуля SSL для Apache
Прежде, чем устанавливать модуль, выполняем команду:
apachectl -M | grep ssl
Если видим строчку, на подобие:
ssl_module (shared)
Спускаемся к шагу 3 данной инструкции.
Иначе, устанавливаем httpd ssl_module.
а) Для CentOS:
yum install mod_ssl
б) Для Ubuntu/Debian:
a2enmod ssl
в) Для FreeBSD:
Открываем файл конфигурации apache:
ee /usr/local/etc/apache24/httpd.conf
* подразумевается, что используется apache 2.4.
Находим и снимаем комментарии со следующих строчек:
…
LoadModule ssl_module libexec/apache24/mod_ssl.so
…
Include etc/apache24/extra/httpd-ssl.conf
…
И ставим комментарии в следующих строках:
#<IfModule ssl_module>
#SSLRandomSeed startup builtin
#SSLRandomSeed connect builtin
#</IfModule>
Чтобы настройки применились, необходимо перезапустить веб-сервер одной из команд:
systemctl restart httpd
systemctl restart apache2
service apache2 restart
* первая, как правило, используется в системах на базе RPM, вторая — DEB, третья — BSD.
Шаг 5. Настройка редиректа
Чтобы все запросы по http автоматически перенаправлялись на https, необходимо настроить перенаправление (redirect). Есть несколько способов это сделать.
В конфигурационном файле
Открываем файл с настройкой виртуальных доменов (как в шаге 3) и дописываем следующее:
<VirtualHost *:80>
ServerName site.ru
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>
* в конкретном примере, мы перенаправили все запросы для сайта site.ru.
** обратите особое внимание, что если у Вас уже есть VirtualHost *:80 для настраиваемого сайта, необходимо его закомментировать или отредактировать
Установка модуля rewrite
Чтобы перенаправление работало в Apache, необходимо установить модуль rewrite.
а) в CentOS открываем конфигурационный файл и проверяем наличие строки:
vi /etc/httpd/conf.modules.d/00-base.conf
LoadModule rewrite_module modules/mod_rewrite.so
* если ее нет, добавляем; если она закомментирована, снимаем комментарий.
systemctl restart httpd
б) в Ubuntu:
a2enmod rewrite
systemctl restart apache2
Глобальные настройки Apache
Данный раздел рассматривает важные параметры глобальных настроек Apache.
Timeout
По умолчанию этот параметр имеет значение 300. Это значит, что на выполнение каждого запроса у сервера есть максимум 300 секунд. В большинстве случаев это значение очень большое, и его рекомендуют уменьшить до 30-60 секунд.
KeepAlive
Если этот параметр имеет значение On, сервер позволит клиенту запрашивать несколько объектов в рамках одного соединения. Если параметр имеет значение Off, то каждый новый запрос будет создавать индивидуальное соединение. Такое поведение может привести к перенагрузке сайта с большим трафиком.
MaxKeepAliveRequests
Этот параметр позволяет определить максимальное количество запросов для одного соединения. Это позволяет увеличить производительность Apache.
Значение 0 позволит веб-серверу обрабатывать неограниченное количество запросов в рамках одного соединения.
KeepAliveTimeout
Данный параметр устанавливает промежуток времени между запросами. Если в течение указанного времени клиент не создал следующий запрос. Веб-сервер прервёт соединение. Если в дальнейшем этот клиент отправит запрос, сервер создаст новое соединение.
Шаг 10 — Блокировка прямого доступа к Apache (опционально)
Поскольку Apache прослушивает порт на публичном IP-адресе, он доступен кому угодно. Его можно заблокировать с помощью следующей команды IPtables в наборе правил брандмауэра.
Обязательно используйте IP-адрес своего сервера вместо выделенного красным адреса в примере. Когда ваш брандмауэр заблокирует порт , убедитесь в недоступности Apache через этот порт. Для этого откройте браузер и попробуйте получить доступ к любому из доменных имен Apache через порт . Например: http://example.com:8080
Браузер должен вывести сообщение об ошибке Unable to connect (Не удается подключиться) или Webpage is not available (Страница недоступна). Если используется опция IPtables , сторонний наблюдатель не увидит разницы между портом и портом, где отсутствует какое-либо обслуживание.
Примечание. По умолчанию правила IPtables теряют силу после перезагрузки системы. Существует несколько способов сохранения правил IPtables, но проще всего использовать параметр в хранилище Ubuntu. Прочитайте эту статью, чтобы узнать больше о настройке IPTables.
Теперь настроим Nginx для обслуживания статических файлов для сайтов Apache.
Пример virtual host конфига через SSL c reverse proxy и Varnish
/путь-установки-апача/sites-available/ssl.conf
<IfModule mod_ssl.c>
<VirtualHost *:443>
DocumentRoot /var/www/wordpress.org
ServerName wordpress.org
ServerAlias www.wordpress.org
#перенаправляет https traffic в varnish на порт 80 и отправляет пользователю ответ от varnish
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:80/
ProxyPassReverse / http://127.0.0.1:80/
RequestHeader set X-Forwarded-Port "443"
RequestHeader set X-Forwarded-Proto "https"
#настройки ssl
SSLEngine On
SSLCertificateFile /etc/ssl/certificate.crt
SSLCertificateKeyFile /etc/ssl/private.key
SSLCACertificateFile /etc/ssl/ca_bundle.crt
#разрешает http версии сайта доступ к файлам доступным на https.
#такой же блок нужно будет вставить и в конфиг без SSL
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css|js)$">
Header add Access-Control-Allow-Origin "http://wordpress.org"
</FilesMatch>
</IfModule>
<Directory "/var/www/wordpress.org">
allow from all
Options +FollowSymLinks
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ -
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
</IfModule>
# END WordPress
</Directory>
</VirtualHost>
</IfModule>
Эта статья — перевод моей же статьи с личного блога https://windowspros.ru/apache-2-4-varnish-virtual-host-config-examples/
Резюме
Собственно всё. После этого надо не забыть закрыть контейнер виртуального хоста: .
Надо понимать, что это минимальный джентльменский набор настроек, но он позволяет поднять виртуальные хосты Apache 2 для настройки работы домена в связке Apache + NGiNX. Ну и доменное имя нужно конечно использовать своё, а не моё . Пути к папкам и файлам должны существовать. Иначе рискуете нарваться на ошибку рестарта Апача.
Конфиги виртуальных хастов обычно лежат в папке на сервере.
Для того, чтобы поднять виртуальный хост (запустить его в работу) нужно выполнить команду
Это активирует виртуальный хост, если в конфиге нет критических ошибок. То есть создаёт символьную ссылку в папке на этот файл конфига.
Не уверен, что это необходимо, но я ещё и перезапускаю Апач командой:
Если Apache рестартанул и не выдал никаких сообщений, сайт должен начать открываться в браузере по доменному имени (если у него конечно есть какие-то документы в домашней директории). =)
Особенность переадресации на синонимах
Предположим, есть домен domain1.tld и синоним domain2.tld. Если запросить в браузере адрес //domain2.tld/dir/ со знаком слэша в конце, то будет отображена индексная страница из директории dir основного домена, при этом содержимое адресной строки браузера останется без изменений. Но если запросить //domain2.tld/dir без слэша в конце, то произойдёт переадресация на //domain1.tld/dir/, и содержимое адресной строки изменится соответствующим образом.
Такова особенность работы модуля mod_dir, при которой если происходит запрос файла, являющегося директорией, но запрос не оканчивается знаком слэш, то mod_dir осуществляет внешнюю переадресацию на тот же адрес со знаком слэша в конце. В случае синонима при переадресации заменяется и имя домена.
Если такое поведение веб-сервера вас не устраивает, добавьте в файл следующие строки:
О создании переадресаций с другими условиями вы можете узнать из документации по web-серверу Apache.
Мы рассмотрели настройки веб-сервера на хостинге провайдера. Но для того, чтобы создать сайт, должна быть подготовлена специальная платформа. Для этого нужно установить локальный «домашний» веб-сервер, без необходимости подключения к интернету.Раньше веб-разработчикам приходилось на Windows-машине устанавливать сервер Apache с различными дополнениями к нему: PHP, Perl, MySQL и т.д. — в целях более удобной отладки сайтов. Но Дмитрий Котеров и группа программистов упростила жизнь многим веб-разработчикам, создав проект «Денвер».
Я уже давно использую Denwer (Джентельменский набор веб-разработчика). Он меня полностью устраивает, потому что этот набор прост в установке и не прихотлив в использовании.
Стандартный пакет Денвера включает в себя следующий пакет:
- Инсталлятор (поддерживается также инсталляция на flash-накопитель).
- Apache, SSL, SSI, mod_rewrite, mod_php.
- PHP5 с поддержкой GD, MySQL, sqLite.
- MySQL5 с поддержкой транзакций.
- Система управления виртуальными хостами, основанная на шаблонах. Чтобы создать новый хост, вам нужно лишь добавить директорию в каталог /home, править конфигурационные файлы не требуется. По умолчанию уже поддерживаются схемы именования директорий многих популярных хостеров; новые можно без труда добавить.
- Система управления запуском и завершением всех компонентов Денвера.
- phpMyAdmin — система управления MySQL через Web-интерфейс.
- Эмулятор sendmail и SMTP-сервера (отладочная «заглушка» на localhost:25, складывающая приходящие письма в /tmp в формате .eml); поддерживается работа совместно с PHP, Perl, Parser и т.д.
Правда, существуют альтернативы Денверу, которые, естественно, содержат необходимый набор для создания и тестирования динамический сайтов на своей машине.
