- Как с нуля настроить свой хостинг для сайтов на Linux CentOS 7
- Содержание
- Как выбрать сервер для хостинга
- Железо
- Платформа
- Выбор операционной системы
- Установка веб-сервера + все необходимое
- Настройка хостинга
- Общий пользователь
- Запуск виртуальных доменов от определенного пользователя
- Настройка Apache
- Создание пользователя
- Создание площадки
- Веб сервер на CentOS 8 с php7, node.js и redis
- Предисловие
- Создание виртуальной машины
- Память
- Процессор
- Собственно установка
- Выбор источника
- Разбивка диска
- Постустановка
- Теперь сконфигурируем оставшийся диск
Как с нуля настроить свой хостинг для сайтов на Linux CentOS 7
Обращаю особое внимание, что в данной инструкции идет речь о создании виртуального хостинга — веб-сервера для размещения сайтов изолированных друг от друга.
В качестве примера используются команды на Linux CentOS. Однако, справедливости ради, нужно заметить, что данными методами без проблем удастся настроить любой Linux и (с небольшими правками) FreeBSD.
- Частный хостинг для небольшого количества клиентов.
- Размещение сайтов компании.
- Тестовый сервер для веб-мастера.
- Установка корпоративных порталов.
- Домашний сервер для компьютерных игр.
Не рекомендую использовать данный хостинг для оказания профессиональных услуг большому количеству клиентов, в связи с отсутствием панели управления. В противном случае, необходимо сделать выбор в сторону специализированной платформы, например, CPanel или самостоятельно разрабатывать систему управления, биллинга, поддержки и так далее.
Содержание
Как выбрать сервер для хостинга
Железо
Основной потребляемый ресурс виртуального хостинга — объем жесткого диска. Небольшие сайты-визитки могут иметь размер менее 100 Мб. Но Интернет-магазины или фото- видео-порталы требуют больших ресурсов. В зависимости от целей, необходимо выделить от 50 Гб до 4 Тб. Больше или меньше для наших целей нецелесообразно.
Мощный процессор нужен только для порталов, которые запускают большое количество скриптов. Для большинства хостингов можно остановить выбор на недорогом процессоре.
Оперативной памяти также требуется небольшое количество — веб-сервер для 50 — 100 простых сайтов прекрасно себя будет чувствовать на 8 Гб.
Платформа
Прекрасно подойдут следующие варианты — обычный домашний компьютер, выделенный физический сервер, виртуальная машина, арендованный сервер.
Выбор операционной системы
Для большинства хостинг-серверов, UNIX-системы являются лучшим выбором, так как:
- Преимущественно, они бесплатные.
- Работают стабильно.
- Основное программное обеспечение для веб-серверов, в первую очередь, разрабатывается для UNIX.
Напомню, что в данной инструкции применяется Linux CentOS 7.
Установка веб-сервера + все необходимое
Процесс настройки веб-сервера подробно описан в статье NGINX + Apache (httpd) + MariaDB (MySQL) + PHP + PHP-FPM (fastCGI) + FTP + PHPMyAdmin + Memcached + xCache + Postfix на CentOS 7. По данной инструкции можно настроить сервер для персонального использования или использования в компании. Но на хостинге будут находиться разные сайты, которые нужно изолировать друг от друга. Также необходимы квоты.
Настройка хостинга
На предыдущем шаге представлена ссылка на статью, по которой мы сконфигурировали полноценный веб-сервер. Но для хостинга необходимо внести некоторые дополнительные настройки.
Общий пользователь
Так как к одним и тем же каталогам необходимы права доступа для nginx и apache, создаем общую группу и добавим в нее учетные записи, от которых работают данные веб-сервисы.
Добавим группу virtwww:
Задаем созданную группу как дополнительную для apache и nginx:
usermod apache -G virtwww
usermod nginx -G virtwww
Запуск виртуальных доменов от определенного пользователя
Чтобы каждый виртуальный домен apache мог работать от отдельного пользователя, устанавливаем модуль httpd-itk:
yum install httpd-itk
После открываем следующий файл:
и снимаем комментарий для LoadModule — получится:
LoadModule mpm_itk_module modules/mod_mpm_itk.so
Настройка Apache
Добавим разрешения на каталоги, в которых будут храниться файлы сайтов:
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
AllowOverride All
Options Indexes ExecCGI FollowSymLinks
Require all granted
* по предложенной статье права были выданы на каталоги /var/www/*/www, для хостинга мы будем использовать немного другую вложенность.
Создание пользователя
Для каждого клиента необходимо создавать отдельного пользователя Linux, к которому будут привязаны виртуальные домены и базы данных. Это позволит изолировать ресурсы одного пользователя от другого и осуществить квотирование.
1. Создаем пользователя и группу Linux:
groupadd u10001 -g 10001
useradd u10001 -u 10001 -g virtwww -G u10001 -d /var/www/u10001 -m -k /dev/null
* где u10001 — имя пользователя/группы; 10001 — идентификатор пользователя в системе; virtwww — основная группа, которой будет принадлежать пользователь; опция -m создаст каталог пользователя; -k /dev/null — не использовать скелет для наполнения профиля файлами.
2. Создаем базу данных и пользователя mysql:
mysql -uroot -p -e «CREATE DATABASE b10001 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;» -e «GRANT ALL PRIVILEGES ON b10001.* TO m10001@localhost IDENTIFIED BY ‘mysqlpass’;»
* где b10001 — название базы; m10001 — пользователя базы данных; mysqlpass — пароль доступа к mysql.
3. Создаем FTP-пользователя. Процесс зависит от того, где мы решили хранить пользователей.
Если храним в файле:
ftpasswd —passwd —file=/etc/proftpd.d/ftpd.passwd —name=f10001 —uid=10001 —gid=10001 —home=/var/www/u10001 —shell=/sbin/nologin
Если в базе данных:
mysql -uroot -p -e «INSERT INTO proftpd.users (username, password, uid, gid, homedir) values (‘f10001’, encrypt(‘ftpass’), 10001, 10001, ‘/var/www/u10001’);»
* f10001 — имя FTP-пользователя; ftpass — пароль пользователя.
4. Задаем права на каталоги:
chmod 4710 /var/www/u10001
chmod 4470 /home/mysql/b10001
chown u10001:virtwww /var/www/u10001
chown u10001:mysql /home/mysql/b10001
* где /home/mysql — путь, по которому хранятся базы.
Создание площадки
Для каждого клиента можно создать одну или несколько площадок, каждая из которых будет использоваться под определенный сайт.
1. Создаем каталоги:
mkdir -p /var/www/u10001/site1.ru/
mkdir -p /var/www/u10001/site1.ru/log/
* подразумевается, что мы создаем площадку для сайта site1.ru.
2. Задаем права на каталоги:
chown -R u10001:virtwww /var/www/u10001/site1.ru
chown -R root:u10026 /var/www/u10001/site1.ru/log
chmod -R 04770 /var/www/u10001/site1.ru
chmod 0710 /var/www/u10001/site1.ru/cgi
chmod -R 0750 /var/www/u10001/site1.ru/log
3. Создаем виртуальный домен в Apache:
Define root_domain site1.ru
Define root_path /var/www/u10001/site1.ru
ErrorLog $
TransferLog $
php_admin_value upload_tmp_dir $
php_admin_value doc_root $
php_admin_value user_dir www
php_admin_value open_basedir /var/www/u10001:/usr/local/share/smarty:/usr/local/share/pear
php_admin_value session.save_path «0;0660;$
php_flag display_errors off
AssignUserID u10001 virtwww
* где site1.ru — сайт, для которого мы создаем площадку; /var/www/u10001/site1.ru — путь, где будут расположены файлы сайта; AssignUserID определяет, под какими учетными данными будет работать виртуальный домен.
4. Создаем виртуальный домен в nginx:
server <
listen 80;
server_name site1.ru www.site1.ru;
set $root_path /var/www/u10001/site1.ru/www;
gzip on;
gzip_disable «msie6»;
gzip_min_length 1000;
gzip_vary on;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;
access_log /home/www/u10001/site1.ru/log/nginx/access_log;
error_log /home/www/u10001/site1.ru/log/nginx/error_log;
location / <
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>
* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|tar|wav|bmp|rtf|js)$ <
root $root_path;
expires modified +1w;
>
error_page 500 502 503 504 /50x.html;
location = /50x.html <
root /usr/local/www/nginx-dist;
>
>
Проверяем правильность настроек nginx и httpd:
Источник
Веб сервер на CentOS 8 с php7, node.js и redis
Предисловие
Вот уже 2 дня как вышла новая версия операционной системы CentOS, а именно, CentOS 8. И пока что в Интернете довольно мало статей на тему того, как в ней что-то делается, поэтому я решил восполнить этот пробел. При чем расскажу я не только о том, как поставить эту пару программ, но и о том, как я вообще вижу установку Линукс в виртуальную среду в современном мире для типовых задач, включая разбиение дисков и прочее.
Но в начале я хочу кратенько рассказать о том, почему стоит переходить на эту версию со всех предыдущих, а тому есть аж две причины:
- php7! В прошлой версии CentOS ставился «православный» php5.4…
Ладно, если чуть серьезнее, то очень много пакетов перепрыгнули через несколько версий скопом. Мы (поклонники redhat-ообразных ОС) наконец-то вошли если не в будущее, то хотя бы в настоящее. И сторонники Ubuntu больше не будут над нами смеяться и тыкать в нас пальцами, ну… хотя бы некоторое время ;).
Создание виртуальной машины
Гипервизоры бывают разные и у меня нет цели затачивать читателя под конкретный, расскажу об общих принципах.
Память
Первое… Для установки системы CentOS начиная с 7 точно, а по-моему и в 6 тоже так было («но это не точно»), необходимо минимум 2 ГБ оперативной памяти. Поэтому советую для начала столько и выдать.
Но если что, после установки объем памяти можно и уменьшить. На 1 ГБ голая система работает вполне нормально, я проверял.
Для нормальной установки следует создать виртуальный диск объемом 20-30 ГБ. Для системы этого хватит. И второй диск для данных. Его можно добавить как на этапе создания виртуальной машины, так и после. Я обычно добавляю потом.
Процессор
На одном ядре голая система не тормозит. А поскольку ресурсы свободно масштабируются, давать больше на этапе установки я смысла не вижу (разве что вы идеально знаете требования и лень лишний раз лезть в конфигуратор)
Остальное обычно можно оставить по-умолчанию.
Собственно установка
Итак… Запускаем установщик… Лично я давно ставлю подобные сервисы только в виде виртуальных машин, поэтому всякие там записи дистрибутива на флешку описывать не буду — просто монтирую ISO в качестве CD-диска в любимом гипервизоре, загрузка и погнали.
Базовая установка проходит довольно типично, остановлюсь только на нескольких моментах.
Выбор источника
С момента выхода восьмой версии зеркало от Яндекса лежит уже который день. Ну, то есть оно периодически поднимается, а потом опять начинает показывать ошибку. Уверен, что дело в чрезмерной нагрузке на сервис. Поэтому для указания источника лично мне пришлось вместо того, чтобы ввести привычный адрес, идти сюда, выбирать там зеркало которое мне нравится и вручную вводить адрес в окне установщика. Тут важно помнить, что указывать надо путь к той папке, где лежит каталог repodata. Например, mirror.corbina.net/pub/Linux/centos/8/BaseOS/x86_64/os.
Разбивка диска
Этот вопрос скорее религиозный на мой взгляд. У каждого админа есть своя позиция на этот счёт. Но я всё-таки поделюсь своей точкой зрения на вопрос.
Да, в принципе, можно всё место выделить под корень и работать будет, чаще всего даже вполне неплохо. Зачем же тогда городить огород с разными разделами? — Основных причины тому на мой взгляд 2: квоты и переносимость.
Например, если что-то пошло не так и на основном разделе с данными возникли ошибки, хочется иметь возможность всё равно загрузить систему и провести реанимационные мероприятия. Поэтому лично я выделяю отдельный раздел под /boot. Там лежит ядро и загрузчик. Обычно хватает мегабайт 500, но в редких случаях может потребоваться больше, а учитывая, что мы уже привыкли измерять место терабайтами, я выделяю под этот раздел 2ГБ. И тут важно то, что его нельзя делать lvm.
Дальше идёт корень системы. Для нормальной установки мне ни разу не требовалось больше 4 ГБ именно на систему, но во время плановых мероприятий я часто использую каталог /tmp для распаковки дистрибутивов, а выделять его под отдельный раздел смысла не вижу — в современных системах он чистится автоматически, поэтому не заполняется. Так что под корень я выделяю 8ГБ.
Swap… По большому счету практической пользы от него мало. Если у вас на сервере стал использоваться свап, сегодня в реальном мире это означает лишь то, что серверу надо добавить больше оперативной памяти. Иначе проблемы с быстродействием гарантированы (либо у какой-то программы «течёт» память). Поэтому этот раздел нужен только для диагностики. Поэтому 2 ГБ это отличная цифра. Да, вне зависимости от того, сколько на сервере памяти. Да, я читал все те статьи, где написано про отношение объема памяти к объему свопа… ИМХО, они устарели. За 10 лет практики мне это ни разу не пригодилось. 15 лет назад я их применял, да.
Выделять ли /home в отдельный раздел ИМХО каждый может решать сам. Если кто-то этим каталогом на сервере будет пользоваться активно, лучше выделить. Если никто — незачем.
Далее, /var. Его на мой взгляд выделять надо обязательно. Для начала можно ограничиться цифрой в 4 ГБ, а там как пойдёт. И да, под «как пойдет» я имею ввиду, что
- Во-первых, всегда можно примонтировать другой диск в подкаталог /var (что я дальше покажу на примере)
- Во-вторых, у нас же lvm — всегда можно добавить. А добавлять обычно приходится тогда, когда слишком много логов начинает туда сыпаться. Но мне заранее предсказать эту цифру никогда не удавалось, поэтому начинаю я с 2 ГБ, а потом смотрю.
Не распределенное место останется свободным в группе томов, его потом всегда можно использовать.
Все разделы, кроме /boot имеет смысл сделать в LVM. Да, включая swap. Да, swap по всем советам должен быть в начале диска, а в случае с LVM его местоположение определить нельзя в принципе. Но как я уже писал выше, ваша система не должна использовать swap вообще. А потому не имеет никакого значения, где он находится. Ну не в 95 году мы живём, вот честно!
Далее, в LVM есть несколько базовых сущностей, с которыми надо уметь жить:
- физический том
- группа томов
- логический том
Физические тома объединяются в группы, при этом каждый физический том может быть только в одной группе, а группа может находиться сразу на нескольких физических томах.
А логические тома находятся каждый в одной группе.
Но… У нас, блин, опять же 21 век на дворе. И сервера виртуальные. Не имеет смысла к ним применять те же механизмы, которые применялись к физическим. И вот для виртуальных важно иметь данные отдельно от системы! Это очень важно в частности для возможности быстрого переключения данных к другой виртуалке (например при переходе на новую ОС) и вообще всяких полезных плюшек (раздельных бэкапов разделами средствами гипервизора например). Поэтому одна volume group используется для системы и обязательно другая используется для данных! Это логическое разделение сильно помогает в жизни!
Если вы при создании виртуальной машины создали только один виртуальный жесткий диск, на этом конфигурация и заканчивается. А если два, то просто не размечайте пока второй.
Постустановка
Так, наконец-то загрузилась свежеустановленная система. Первое, что надо проверить — интернетик.
Ответ есть? — Отлично, жмём Ctrl-C.
Если нет — идите настраивать сеть, без этого жизни нет, но моя статья не об этом.
Теперь если мы еще не под рутом, заходим под рута, ибо набирать такое количество команд с sudo лично мне влом (и да простят меня админы-параноики):
Теперь первым делом набираем
И если вы читаете эту статью в 2019 году, скорее всего ничего не произойдет, но попробовать стоило.
Теперь сконфигурируем оставшийся диск
Допустим, раздел с системой у нас был xvda, тогда диск с данными будет xvdb. ОК.
Большинство советов будут начинаться со слов «Запустите fdisk и создайте раздел. »
Так вот, это неверно!
Я блин еще раз повторю, потому как это важно! В данном случае для работы с LVM, занимающим один целый пусть и виртуальный диск создавать на нем разделы вредно! В этой фразе важно каждое слово. Если мы работаем без LVM — надо. Если у нас на диске скажем система и данные — надо. Если нам почему-то надо оставить половину диска пустой — тоже надо. Но обычно все эти допущения сугубо теоретические. Потому что если мы решим добавить места к имеющемуся разделу, то проще всего это будет делать именно при такой конфигурации. И удобство в администрировании настолько перевешивает много всякого, что мы целенаправленно идём к этой конфигурации.
А удобство заключается в том, что если вы захотите расширить раздел с данными, вы просто добавите места в виртуальный раздел, после чего расширите группу с помощью vgextend и всё! В редких случаях может потребоваться что-то еще, но как минимум не придёться расширять в начале логический том, что уже приятно. А то для расширения этого самого тома рекомендуют в начале удалить имеющийся, а потом создать новый поверх… Что и выглядит не очень приятно и нельзя сделать на живую, а расширение по указанному мною сценарию можно проводить «на лету» даже не размонтируя раздел.
Итого, создаём физический том, потом группу томов, его включающую и потом раздел для нашего сервера:
Тут можно вместо большой буквы «L» (и размера в ГБ) указать маленькую и тогда вместо абсолютного размера указать относительный, например, чтобы использовать половину свободного на данный момент в группе томов места, надо указать «-l +50%FREE»
А последняя команда форматирует раздел в файловой системе ext4 (которая пока что по моей практике показывает наибольшую стабильность в случае если всё сломалось, поэтому я предпочитаю её).
Теперь монтируем раздел в нужное место. Для этого добавляем правильную строку в /etc/fstab:
Если выскочила ошибка — бьем тревогу! Потому что это означает, что у нас ошибка в /etc/fstab. И что при следующей перезагрузке у нас будут очень большие проблемы. Система может и вообще не загрузиться, что для облачных сервисов часто весьма печально. А потому надо либо срочно исправлять последнюю дописанную строку, либо удалять её вовсе! Именно поэтому мы не стали прописывать команду монтирования вручную — тогда мы не получили бы такой прекрасной возможности провести проверку конфига вотпрямщаз.
Теперь собственно ставим всё, что хотели и открываем порты под веб:
По желанию можно еще и БД сюда поставить, но лично я стараюсь держать её отдельно от веб-сервера. Хотя держать её рядом быстрее, да. Скорость виртуальных сетевых адаптеров обычно в районе гигабита, а при работе на той же машине обращения происходят почти мгновенно. Но зато менее безопасно. Тут кому что важнее.
Теперь добавляем параметр в конфигурационный файл (создаём новый, современная идеология CentOS’а такая)
Перезагружаем сервер.
В комментариях меня заругали за совет выключать SeLinux, поэтому я исправлюсь и напишу про то, что после этого надо не забыть настроить SeLinux.
Собственно, профит! 🙂
Источник