Установка vds. Настройка сервера с нуля на примере VPS от Hetzner’а
Твитнуть
Предыстория
Лучший способ развиваться - делиться накопленным опытом.
Раньше для запуска сайтов мне было достаточно shared-хостинга. Это разумная экономия, если посещаемость сайтов небольшая. Так продолжалось до 2014 года, когда в руки попал довольно посещаемый ресурс, запущенный на VPS и при этом сильно тормозящий. Шутка ли - страницы могли генерироваться по 10 секунд! На домашней Убунте я не раз ставил стек программ LAMP командой sudo apt-get install lamp-server^ , раскидывая сайты по разным папкам и составляя несложные конфиги, поэтому первым делом перенёс сайт на своё «железо». На домашнем ПК он заработал довольно шустро, поэтому решил, что на сервере нужно просто переустановить софт с нуля. Глубокой ночью, когда посетителей было мало, поставил Ubuntu 12.04.4 (тогда была самой актуальной версией), Apache+PHP+MySQL+phpmyadmin+proftpd и запустил сайт. Увы - генерация страниц как длилась по 5-10 секунд, так и продолжила отнимать драгоценное время.
Стал копать дальше и убедился, что дело было в самописных компонентах CMS (это была Joomla, кстати). Переписывать тормозящий программный код CMS, с которым я не знаком, не лучшее решение, когда работу нужно выполнить в сжатые сроки. Поэтому прикрутил компонентам кэширование и аллилуйя - тормоза исчезли! Страницы стали загружаться за 0,7-0,9 секунд, это более чем пятикратный прирост производительности.
Я дам прямой ответ на вопрос: как же сделать так, чтобы запущенный на дешёвом, медленном сервере сайт работал быстро.
Выбор VPS
Если у вас нет виртуального сервера, почитайте о том, В статье я рассказал о минимальных системных требованиях к виртуальному серверу и как выбрать подходящий.
Выбор ОС для сервера (Ubuntu Server 16.04)
Обычно хостинг даёт возможность выбрать операционную систему для вашего сервера. Большинство предлагаемых - различные дистрибутивы Linux: Debian, Ubuntu, Arch Linux, CentOS, OpenSUSE, Fedora, Gentoo и другие.
На персональном компьютере можете ставить что угодно, но на серверах важна стабильность. На мой взгляд, Ubuntu 16.04 - разумный компромисс между новыми версиями софта и стабильностью. Инструкции для Debian подходят и для Убунты, а значит - начинающим пользователям будет раздолье в плане повышения навыков и поиска ответа на вопросы. Потом при желании можно переключиться на CentOS или вообще FreeBSD, но для начала, чтобы избежать головной боли при настройке, лучше Убунты ничего не придумали.
Моё субъективное мнение о популярных дистрибутивах:
- CentOS (любая версия): новичкам будет тяжело, ибо инструкций не очень много. В репозиториях доступны довольно свежие версии софта.
- Debian (любая версия): оперативной памяти занимает немного, что помогает быстрее работать сайту с высокой посещаемостью за счёт выделения памяти кэшу и PHP с MySQL (после тонкой настройки, конечно), но в репозитории доступны старые, проверенные версии PHP, из-за чего скорость работы сайтов будет не так высока, как могла бы быть. Инструкций много, начинающие пользователи разберутся, но настройка требует времени.
- Ubuntu Server 16.04: серверная версия популярного дистрибутива Linux. Версия 16.04 будет поддерживаться до апреля 2021 г. - это значит, что после настройки вы четыре года сможете просто обновлять софт. Обновления важны, потому что в новых версиях исправляются найденные уязвимости и устраняются ошибки. Версии программ в репозитории Ubuntu 16.04 относительно свежие. Например, на момент написания статьи доступна PHP 7.0, дающая 30% прирост производительности по сравнению с PHP 5.6, идущей по умолчанию в Debian 8.
- Ubuntu Server 16.10, 17.04, 17.10: версия 16.10 уже вышла, но обновления безопасности прекратят приходить в июле 2017 года, придётся обновлять всю систему целиком до 17.04. На момент написания статьи 17.04 готовится к выходу, а 17.10 пока только в планах, их тоже ставить нет смысла: это не LTS-релизы, а значит, они тоже быстро превратятся в тыкву.
У любителей настраивать всё ручками можно знатно пригореть от того, что я предлагаю Ubuntu Server 16.04 в качестве основы для веб-сервера, ведь есть CentOS/FreeBSD/Что-то_ещё_OS. Выбор в мире свободного софта - всегда конфликт и холивары. Моя позиция такова: Ubuntu - хороший старт, начните с неё, а дальше у каждого свой путь.
Как подключиться к VPS
Вам нужно понимать, что такое консоль и какие команды бывают. Дело в том, что каждый хостинг стремится сделать собственную сборку ВПС-ки. Например, устанавливает Apache, MySQL, правит конфиги. Поэтому нужно уметь смотреть логи и понимать, что происходит.
Итак, ОС выбрали, сервер заказали, в админке хостинга появился IP-адрес сервера, имя пользователя и пароль для доступа по SSH. Как подключиться к ВПСке?
Управление сервером осуществляется через терминал (консоль) путём ввода команд. Обычно к консоли подключаются по протоколу SSH с помощью соответствующих программ. Я рекомендую использовать Putty как самую распространённую: ссылка на самую новую версию. Версия с MSI-инсталлятором (первая ссылка в списке) - наиболее полный комплект. Или можете использовать форк (модификацию) Putty под названием KiTTY, где добавлено много полезного по сравнению с оригинальной программой.
После установки панели управления VestaCP сервером можно управлять и через браузер, обращаясь к консоли только для обновления программ.
Инструкция подходит к Ubuntu 16.04 и 16.10. Пожалуйста, не спрашивайте меня об установке софта на CentOS и другие дистрибутивы - это тема отдельной статьи.
Вход на сервер через Putty
Для входа нужна только первая вкладка в стартовом окне Putty:
1 - сюда введите IP-адрес вашего сервера;
2 - порт, по умолчанию 22;
3 - введите любое название;
4 - сохранение настроек под именем из третьего пункта;
5 - в дальнейшем просто запустите двойным щелчком по пункту в этом списке. Для редактирования настроек именно этого пункта есть кнопки Load и Save .
После нажатия Open (или двойного щелчка по сохранённому пункту в списке), если правильно ввели адрес и порт, появится предупреждение:
Это значит, что Putty пока не знает цифровой отпечаток этого сервера и предлагает его запомнить. Смело жмите «Да». В будущем, если вдруг кто-то подменит ваш сервер поддельным, окно появится снова. Это удобно.
Появится консоль с предложением войти:
Нужно сначала ввести выданный хостером логин, нажать Enter, пароль и снова Enter:
Тут важный момент: если вам выдан пароль к пользователю root , нужно создать другого с меньшими правами. Под пользователем root можно нечаянно удалить любые системные файлы, а нам нужно, чтобы VPS прожил как можно дольше.
Чтобы добавить нового пользователя, введите команду:
adduser имяпользователя
Затем добавьте его в группу sudo, чтобы можно было тоже выполнять рутовые операции, но только с указанием команды sudo:
usermod -a -G sudo имяпользователя
После этого можно выйти из рута командой logout и зайти под новым пользователем. Его и используйте в дальнейшем.
Есть ещё один способ авторизации на сервере: по цифровому ключу. Генерируется файл-ключ, благодаря которому сервер узнает, что вы - это вы. Цифровой ключ просто нереально подобрать, поэтому доступ к серверу по протоколу SSH будет предельно надёжен. По умолчанию включать доступ по цифровому ключу любят зарубежные хостеры, у наших встречал пока только у одного. Если у вас простая связка логин/пароль, не переживайте и просто имейте в виду, что есть более защищённый способ, который можно включить в будущем. Как настроить, в Интернете инструкций полно, я не буду останавливаться на этом.
Обновление программ
Нужно запомнить команду обновления, которую вводить придётся часто:
sudo apt update && sudo apt upgrade
Точнее, это две команды, объединённые в одну, чтобы лишний раз не жать Enter:
- apt update обновляет список программ, подгружая из их репозитория Ubuntu 16.04;
- apt upgrade запускает обновление программ сервера, если есть устаревшие;
- sudo означает, что программу apt нужно запустить от имени суперпользователя root.
Обычно софт обновляется самостоятельно. Вмешательство требуется только при несовпадении конфигурационных файлов, идущих в комплекте, с содержимым имеющихся на сервере. При этом даётся выбор: заменить, сравнить построчно или оставить имеющиеся файлы. На практике можно оставить конфигурацию без изменений.
Немного теории: как работает веб-сервер
Веб-сервер - это программа, которая разберёт запрос браузера посетителя и отдаст ему нужные файлы. Для работы полноценного сайта на WordPress одного веб-сервера мало - он может отдавать только статичные (заранее подготовленные) файлы, ещё нужны интерпретатор PHP и сервер баз данных. Любой сайт на WordPress - это набор скриптов на языке программирования PHP, которые запрашивают информацию у сервера баз данных, чтобы сформировать страницы с записями, комментариями пользователя, админкой и прочими полезными интерактивными штуками.
Общий принцип работы таков:
1. Браузер пользователя узнаёт у DNS-сервера провайдера IP-адрес сервера, на котором находится сайт.
2. Затем браузер обращается по IP-адресу к серверу, указывая заодно, какой именно сайт ему нужен.
3. Веб-сервер разбирает запрос, определяя - что отдать посетителю. Два варианта событий:
а) Если это просто фотография, документ или другой статичный файл, то веб-сервер загружает с диска этот файл и отдаёт посетителю.
б) Если запрос подразумевает обработку через php-скрипт, он выполняется, формируя html-код странички и этот готовый код передаётся веб-серверу, который, в свою очередь, передаёт его браузеру посетителя.
Вы можете подумать: «Зачем читать эту азбуку? Раз я купил VPS, то всё знаю!». Вам придётся немного потерпеть, потому что есть нюансы, про которые многие забывают. Даже профессионалы своего дела, судя по вопросам на таком серьёзном сайте, как toster.ru, иногда получают граблями по лбу.
Выбор веб-сервера: Apache против Nginx
По умолчанию на VPS не будет веб-сервера, интерпретатора PHP и сервера баз данных. Их нужно ставить самим.Рассмотрим два самых популярных веб-сервера - Apache и Nginx.
- Apache - самый популярный выбор. Совместим со всеми CMS, в том числе WordPress. К сожалению, скорость работы оставляет желать лучшего. Работающий на Apache сайт при наплыве посетителей начнёт открываться медленно или вовсе выдаст ошибку 500, 502 или другую из серии 5**, если у сервера не хватит ресурсов. Плюс только один: совместимость. На нём работают любые сайты, любые CMS, любой софт, написанный на PHP.
- Nginx - второй по популярности веб-сервер. Используется многими посещаемыми сайтами. Например, Яндексом, Mail.ru и Вконтакте. Сильная сторона nginx - он очень быстро отдаёт посетителю статичные файлы (.htm, .jpg, .png и другие). Благодаря этому и некоторым другим особенностям на аналогичном по производительности сервере Nginx выдерживает большее количество одновременных посетителей, а также позволяет загружать странички быстрее. Никакой магии, конечно, нет - если посетителей много и ресурсов сервера не хватает, 5**-е ошибки посыпятся тоже, но при бо льших нагрузках. О том, почему Nginx быстрее, есть
Всё познаётся в сравнении. Если бы не существование Nginx, можно было бы смело поставить Apache и при повышении посещаемости сайта просто переезжать на более быстрый сервер. Но я рассказываю о том, как сделать так, чтобы сайт работал быстро , так что пошлём Apache куда-нибудь подальше.
Я предлагаю использовать Nginx, потому что:
- Nginx быстро отдаёт статичные файлы. Я подчеркиваю - действительно быстро . Если у вас сайт с большим количеством фотографий, переход на Nginx будет заметен невооружённым глазом: изображения на страницах будут появляться быстро, словно вы подключились к более шустрому Интернету.
- Nginx может кэшировать результат работы PHP-скриптов и отдавать браузеру так же быстро, как статичные файлы. Это те самые грабли, на которые наступают некоторые админы, я в их числе. Nginx может работать в любой мыслимой конфигурации и если вдруг вам захотелось ускорить работу сайта, велик соблазн включить все виды кэширования. Но при длинной цепочке кэширования производительность, наборот, может упасть! Более того, посетителям нужен не замерший во времени сайт - комментарии, форумы, новостные ленты должны обновляться. Обновлять кэш постранично в WordPress довольно накладно. А если сбрасывать всё при каждом новом комментарии или записи в блоге, производительность сайта будет низкой, потому что часть ресурсов будет уходить на постоянное пересоздание кэша. Поэтому дальше я предложу гарантированный способ кэширования, однозначно ускоряющий сайт, всё остальное будете допиливать сами, если появится желание.
- Nginx отказоустойчив. Так как это ещё и прокси-сервер, то при грамотной настройке, если вдруг «отвалится» PHP-интерпретатор, сайт продолжит работу, отдавая посетителям кэшированные страницы.
- Nginx контролируем в настройке. Всё сосредоточено в нескольких.conf файлах и вся логика параметров базируется на запросе посетителя. Nginx разбирает запрошенный URL «по кирпичикам» и решает: отдать ли фотографию, перенаправить ли запрос PHP-интерпретатору, взять искомое из кэша или запретить доступ. В итоге ресурсов для отдачи контента отдаётся столько, сколько нужно. Apache работает иначе. Как именно, рассказано в статье, ссылку на которую я привёл в начале главы.
На мой взгляд, использовать Apache можно только в том случае, если разработчиками сайта явно заявлена совместимость только с этим веб-сервером. Но даже в этом случае можно сделать из Nginx прокси, позволив ему отдавать статические и кэшированные файлы, перенаправляя запросы на формирование динамических страниц к Apache. Так как WordPress прекрасно дружит с Nginx, подобную химеру рассматривать не буду. Только Nginx и PHP-FPM, чтобы исключить любые промежуточные этапы, способные снизить скорость работы и усложнить настройку.
Выбор PHP: версии 5.6, 7.0, 7.1 и 7.2
Сразу скажу: вам нужен PHP минимум седьмой версии. По сравнению с 5.6 прирост скорости может быть двухкратным. Те страницы, что открывались медленно, станут открываться быстрее, а быстрые вообще будут генерироваться практически мгновенно.
На момент написания статьи в Ubuntu 16.04 по умолчанию устанавливается PHP 7.0, хотя уже вышла 7.2. Между 7.0, 7.1 и 7.2 разница в производительности минимальна (от 1 до 10% в разных задачах). Приобретя опыт в настройке PHP, вы сможете установить самую свежую, но на первых порах лучше оставить ту, которая будет в стандартных репозиториях ОС.
Выбор сервера баз данных: MySQL, MariaDB, PostgreSQL и другие
Помимо веб-сервера и интерпретатора PHP, должен быть запущен сервер баз данных. WordPress отлично работает с MySQL и MariaDB, а вот с PostreSQL и другими SQL-как-бы-совместимыми базами данных всё печально. Если у сайта нет десятков тысяч активно комментирующих посетителей, обычный MySQL Server не будет «бутылочным горлышком» - операции чтения из базы данных отлично кэшируются.
Пока лучше остаться на MySQL Server. В перспективе можно перенести базу на MariaDB и таким образом ускорить работу нагруженного сайта, инструкций на эту тему в Интернете полно.
Нужен ли DNS-сервер
Часто забывают, что виртуальный сервер может работать DNS-сервером, если установлен соответствующий софт и в записях домена указан IP-адрес сервера в качестве DNS-ки.
Моё мнение: это серьёзная угроза безопасности, потому что в случае взлома VPS, если будут изменены DNS-записи, исправление последствий может занять целые сутки, даже если вы мгновенно исправите взлом. То есть DNS-сервера во всём мире могут сутки открывать вместо вашего сайта поддельный, из-за чего вы потеряете посетителей и, что важнее, их доверие.
В течении 5-20 минут установятся веб-сервер Nginx, PHP-FPM в качестве интерпретатора PHP, Exim для отправки сообщений на электронную почту, MySQL Server для работы баз данных, Vsftpd для доступа по протоколу FTP, файрвол Iptables и средство автоматического бана Fail2Ban. Версии у программ будут те, которые находятся в репозитории Ubuntu.
В конце установки появится информация о том, по какому адресу доступна Vesta Control Panel, а также пароль нового пользователя admin, совпадающий с тем, что указали ранее в команде установки:
После установки Весты вам нужно выйти из сеанса вашего пользователя командой logout и перезайти под свежесозданным admin
. И в будущем сидите только под ним, потому что:
а) все папки и файлы, которые потребуется создать в папке /home/admin/, будут принадлежать пользователю admin, вручную выполнять команду chown не потребуется,
б) меньше риск удалить системные файлы.
После установки VestaCP доустановите модули PHP, необходимые для работы WordPress:
sudo apt install php-curl php-gd php-mbstring php-mcrypt php-xml php-xmlrpc
Ещё один момент: софт после установки далеко не всегда запускается автоматически. Перезапустите сервер командой restart, чтобы MySQL Server, Nginx и прочие стартовали. Можно запустить и вручную, но перезапуск VPS - самый простой способ.
Работа в Vesta Control Panel
Так как для статьи я использую локальный виртуальный сервер, мой адрес для доступа к панели будет https://192.168.110.11:8083. У вас, конечно, другой. При заходе браузер предупредит, что https-соединение не защищено - не обращайте внимания. Затем будет запрос логина/пароля (тот самый admin и ваш пароль), после ввода откроется панель управления:
Для удобства можете нажать справа вверху надпись «admin» и в настройках профиля переключиться на русский язык.
В будущем вам лучше изучить основы Linux, чтобы понять, как сделать сервер «непробиваемым». А пока, чтобы хоть как-то обезопасить сервер, зайдите на вкладку «Фаервол» и заблокируйте порты служб FTP, DNS, POP3, IMAP, DB:
Когда потребуется загрузить файлы по протоколу FTP (адрес сервера - его IP, порт 21, пользователь admin, пароль тот же), можно временно разблокировать строку FTP. Постоянно держать открытыми порты со службами, которыми не пользуетесь, нельзя.
Краткое перечисление страниц панели управления Vesta:
- Пакеты. Здесь настраиваются шаблоны с ограничениями, назначаемые учётным записям (их может быть несколько). Честно говоря, смысла в них мало, потому что Веста не доросла до панели управления полноценного хостинга.
- IP. Настройка сетевых карт сервера. Лучше не трогать.
- Графики. Раздел, где должны рисоваться красивые графики использования памяти, пропускной способности сетевых интерфейсов, нагрузки на базу данных. На практике ни разу не замечал, чтобы они показывали что-то, имеющее отношение к действительности. Возможно, это я один такой везучий.
- Статистика. Просто полезная статистика, в пояснениях не нуждается.
- Журнал. Операции, проводимые в панели управления, можно отследить тут.
- Обновления. Можно узнать версии основных компонентов Весты.
- Фаервол. Удобная настройка фай рвола iptables. Разработчики - грамотеи.
- Сервер. Здесь можно остановить или перезапустить важные службы, а также настроить. Честно говоря, не советую настраивать службы через Весту, потому что иногда при сохранении она превращает файлы конфигурации буквально в кашу. Не знаю, с чем это связано, наблюдал на нескольких серверах. Вкладку лучше использовать только для перезапуска служб.
- USER. Добавление новых пользователей и управление существующих.
- WEB. Настройка сайтов. Самая важная вкладка, из-за которой Веста и нужна. О ней будет попозже.
- DNS. Настройка записей домена, если VPS выступает в роли DNS-сервера.
- MAIL. Настройка почтового сервера. В той конфигурации, что я вам рекомендую, страница бесполезна.
- DB. Вторая по важности после WEB вкладка, позволяет быстро создать новую базу данных.
- CRON. Крайне полезная вкладка, позволяющая настроить выполнение команд на сервере через заданные промежутки времени.
- BACKUP. Здесь можно создать и загрузить бекапы.
До идеала Весте далеко, но пользоваться можно. Чтобы не наступили на те же грабли, что и я, перечислю недостатки VestaCP:
1) Через Весту нельзя редактировать расширенные настройки. Возможность есть, но работает плохо. Например, на вкладке Сервер можно открыть настройки служб, где в удобных текстовых полях записаны какие-то значения. Если их изменить, не факт, что они сохранятся. А если нажать Дополнительные опции и попытаться отредактировать появившийся файл конфигурации вручную, служба может перестать запускаться, потому что строчки окажутся не там, где должны быть. Например, повторно добавиться в конец файла. А еще может открыться файл конфигурации от другой версии, по каким-то причинам оставшийся на сервере. Лучше самому делать тонкую настройку, редактируя файлы конфигурации через mcedit (как именно, покажу дальше).
2) Разработчики VestaCP имеют своё собственное видение того, какой софт должен ставиться вместе с панелью. Они написали отдельные скрипты для нескольких дистрибутивов Linux, подгружающиеся с их сайта во время установки. По их логике, если в Ubuntu 16.04 по команде apt install php ставится PHP версии 5.6, то так тому и быть. И не важно, что потом вместо 5.6 появится 7.0, а в репозиторий добавится ещё и php7.1, устанавливаемый командой apt install php7.1 - судя по комментариям на официальном форуме, такой ситуации не может быть в принципе.
Ещё веселее с поддержкой Ubuntu 16.10 - из-за ошибки в скрипте установки половина софта просто-напросто не устанавливается. На момент написания этой инструкции упоминание ошибки висит на официальном форуме Весты месяц, одна-единственная строчка с ошибкой до сих пор не исправлена. Чтобы не быть голословным, покажу часть скрипта установки софта для Убунты по адресу http://vestacp.com/pub/vst-install-ubuntu.sh:
Если следовать логике скрипта установки, то все дистрибутивы Убунты делятся на Ubuntu 16.04 и остальные. Вот только Ubuntu 16.10 - не остальные. В её репозиториях нет ни apache2.2-common, ни php5-fpm и другого устаревшего софта. Без редактирования скриптов установки работающий с VestaCP веб-сервер на Ubuntu 16.10 не получить.
3) Удобный инструмент управления базами данных phpMyAdmin, который ставит скрипт установки Весты, может просто не работать.
4) Способов «выстрелить в ногу» в Весте выше крыши. Например, ни в коем случае нельзя удалять шаблон default на странице Пакеты , в противном случае вы познаете боль и страдания.
5) Почему-то в скриптах установки панели нет корректной проверки на существование имеющегося софта. Поэтому, если на сервере изначально был установлен какой-то софт, например Apache, а вы ставите Весту без включения этого софта (только Nginx), возможны сбои. Например, просто ничего не заработает. Я не знаю, что тут посоветовать, кроме как удалить весь перечисленный в команде установки панели софт (nginx, phpfpm, apache, vsftpd, proftpd, exim, dovecot и так далее) и только потом ставить панель.
Несмотря на недостатки, среди бесплатных панелей управления лучше Vesta Control Panel ничего нет. Разве что , но у неё нет веб-интерфейса, нужно вводить команды с клавиатуры. Альтернативы Webmin, Froxlor, ajenti недостаточно автоматизируют управление сервером и сложнее в настройке, а у платного ISP Manager тоже хватает проблем.
Установка дополнительного софта
1. Memcached. Благодаря этой софтине можно разместить кэш в оперативной памяти сервера, что ускорит отдачу кэшированных страниц.
Устанавливается командой
sudo apt install memcached php-memcache
После этого рекомендую перезапустить сервер.
2. Littleutils. Нужен для работы плагина CW Optimizer, который сжимает фотографии, загружаемые на сайт. Оптимизация изображений - один из и привлечения посетителей (никто не любит медленную загрузку страниц). Лучше начать оптимизировать фотографии уже сегодня.
Сохраните настройки кнопкой OK, затем выйдите из MC кнопкой F10 и запустите коммандер снова, на этот раз командой sudo mc и повторите настройку.
Эта неочевидная опция сильно упростит жизнь во время редактирования файлов конфигурации. Она позволит временно скрывать с экрана текстовый редактор коммандера mcedit, переключаясь на консоль. Например, когда будете редактировать конфигурацию Nginx, вы сможете отредактировать файл, сохранить его кнопкой F2, затем скрыть редактор сочетанием клавиш Ctrl+O и ввести команду в консоли:
Если будет такой результат:
То с файлом всё отлично и можно перезагружать сервер, окончательно применяя новые настройки:
sudo service nginx restart
Если же появится сообщение о проблемах, можно нажать Ctrl+O и сразу поправить нужную строчку, не тратя время на переоткрытие файла.
Во многих инструкциях советуют редактировать файлы с помощью текстовых редакторов vi или nano . Консоль - не всегда удобно, зачем усложнять себе жизнь ещё больше? На мой взгляд, проще и быстрее в MC зайти в нужную папку, выбрать файл и нажать F4, чтобы открыть редактор, который можно скрыть в любой момент.
Как установить WordPress
1. Прежде чем приступить к установке сайта на Вордпресс, создайте отдельную базу данных на вкладке DB, нажав зеленую кнопку «+ «:
Без базы данных сайты на WP не работают. Им нужно где-то хранить настройки и тексты записей. И лучше для каждого сайта создавать отдельную базу данных. Тогда в случае взлома одного сайта до других добраться будет сложнее.
2. На вкладке WEB добавьте сайт кнопкой «+ «:
Пройдусь по порядку по всем пунктам при добавлении нового домена/сайта:
Домен: адрес сайта. Если домен пока не купили, укажите тот, который планируете купить. В файле hosts компьютера (и сервера тоже в папке /etc/hosts) можно связать домен и IP-адрес сервера, чтобы вы уже могли пользоваться сайтом по выбранному адресу.
IP адрес: адрес вашего сервера. Сетевых карт может быть несколько, поэтому нужно убедиться, что выбран адрес, соответствующий выданному провайдеру.
Поддержка DNS: так как VPS не работает как DNS-сервер, нужно снять галку.
Поддержка почты: тоже снять галку, потому что на сервере будет только Exim для отправки писем, VPS в качестве почтового сервера не подходит по той же причине, что и поддержка DNS.
Следующие пункты появятся при нажатии «Дополнительные опции»:
Алисы: дополнительные адреса, с которых перенаправлять на основной домен.
Поддержка SSL: поддержка шифрования. Современные сайты должны поддерживать защищённый протокол https , здесь сомнений быть не может. После включения опции нужно отметить и «Поддержка Lets Encrypt «, чтобы использовать бесплатные сертификаты Let’s Encrypt. После сохранения настроек нужно повторно поставить галку на «Поддержка Lets Encrypt», потому что с первого раза сертификат может не сгенерироваться.
Учтите два момента:
- Нельзя получить сертификат на домен или поддомен, если в A-записях домена указан IP другого сервера. Это сделано для того, чтобы никто, кроме владельца домена, не смог получить SSL-сертификат. Поэтому до покупки домена и настройки DNS вы сертификат не получите. То есть, чтобы сайт заработал по протоколу https, ваш сайт должен открываться по протоколу http. Только потом можно настроить редирект с http на https.
- Генерация ключей Let’s Encrypt через Весту работает через раз. Придётся смотреть логи и разбираться, в чём проблема (они в папке /usr/local/vesta/log) или воспользоваться сторонними утилитами.
Статистика сайта: включение встроенной системы статистики. В большинстве случаев лучше не включать, чтобы не нагружать сервер.
Дополнительный ftp: создание аккаунта ftp специально для работы с папкой, где будет находиться сайт. Даёт ощущение ложной безопасности - мол, дадите только пароль от этого сайта и до других файлов никто не доберётся. На самом деле это не так, VestaCP не подходит организации хостинга с полностью изолированными друг от друга сайтами и пользователями.
3. Когда создадите сайт на вкладке WEB, не торопитесь уходить. Вам нужно снова зайти в настройки сайта (кнопка «Редактировать» при наведении мыши на пункт меню. Появятся новые настройки - выбор шаблонов Web и Backend:
Шаблон Web в VestaCP отвечает за набор настроек Nginx, специфичных для каждой из популярных CMS. Шаблон Backend отвечает за настройку связи между веб-сервером и PHP-интерпретатором.
Выберите Шаблон Web - wordpress , а Шаблон Backend - socket (связь через сокеты работает быстрее связи через порты). Если галка с «Поддержка Lets Encrypt» оказалась снята, поставьте снова. Нажмите Сохранить и снова откройте настройки сайта и поставьте Шаблон Web - wordpress2 и снова сохраните настройки.Почему не выбрать сразу шаблон wordpress2? Ну, я говорил, что VestaCP - глючная штука, это одна из проблем - правильный файл конфигурации для WordPress не генерируется корректно с первого раза.
Обновление от 4.04.2017: Сначала сгенерируйте Let’s Encrypt ключи, потом выбирайте шаблон Web wordpress2, Backend - socket. Или, если SSL не нужно, выбирайте шаблоны wordpress2, socket и сохраняйте настройки.
Если посты отдают 404 ошибку при включенных в админке WP постоянных «красивых» ссылках, используйте шаблон Nginx из поста
4. Запустите Putty, зайдите под пользователем admin.
Выполните команды по очереди:
cd /home/admin/tmp/
wget https://ru.wordpress.org/latest-ru_RU.zip
unzip latest-ru_RU.zip -d /home/admin/web/имя_вашего_домена/public_html/
mv /home/admin/web/имя_вашего_домена/public_html/wordpress/* /home/admin/web/имя_вашего_домена/public_html/
rm latest-ru_RU.zip
rm -r /home/admin/web/имя_вашего_домена/public_html/wordpress
sudo service nginx restart
5.
Сайт уже должен заработать. Зайдите через браузер по адресу https
://адрес_сайта, откроется страница установки:
Если зайти по обычному протоколу http, придётся в панели управления WordPress заходить в Настройки - Общие и менять значения в полях Адрес WordPress (URL) и Адрес сайта (URL) с обычного http на https, чтобы CMS поняла, что приоритет у защищённого протокола.
По порядку заполните все поля:
- Имя базы данных - имя той базы данных, что создали в первом шаге.
- Имя пользователя - имя пользователя к базе данных из первого шага.
- Пароль - думаю, понятно, что это пароль к базе.
- Сервер базы данных - так как база данных на том же сервере, оставляйте «localhost».
- Префикс таблиц - введите что-нибудь случайное.
6. На следующем этапе нужно указать название сайта, имя пользователя-администратора сайта и ваш e-mail:
Пожалуйста, не указывайте в качестве имени пользователя такие банальные логины, как admin или домен сайта. Не надо облегчать жизнь вредоносным ботам-сканерам, которые будут пытаться подобрать пароль к вашей админке.
7. Откроется панель управления сайта:
В принципе, уже сейчас сайт полностью работоспособен. Но я рекомендую установить плагины, которые ускорят работу сайта и повысят безопасность.
Установка и настройка необходимых плагинов WordPress
Все плагины ставятся сразу из админки. Достаточно пройти в раздел Плагины - Добавить новый и ввести имя плагина в поле поиска.
CW Image Optimizer. Плагин, оптимизирующий каждую фотографию, загружаемую на сайт. В настройке не нуждается. Достаточно было установки Littleutils из прошлого шага. Хочу подчеркнуть - все альтернативы этого плагина платные. Есть разве что EWWW Image Optimizer, но он плохо оптимизирует.
DCO Russian Fixes - плагин для транслитерации имён файлов и ссылок и корректировки формата дат. После установки и активации в настройке не нуждается.
SSL Insecure Content Fixer (Фильтр небезопасного содержимого SSL) - делает все ссылки на сайте ведущими на https-версию вместо http. Работа защищенного соединения HTTPS влияет на ранжирование в поиске Гугла, нужно по-максимуму использовать эту возможность. Рекомендую после установки плагина зайти в раздел Настройки - Небезопасный контент SSL и переключить плагин на режим Виджеты , чтобы все ссылки страницы вели на защищённые версии.
iThemes Security - плагин для повышения уровня безопасности. После установки и активации в верхней части панели управления появится кнопка «Получите бесплатно API ключ» - нажмите и получите его. Настройки iThemes Security смотрите ниже в отдельной главе.
Autoptimize - для объединения всех.css и.js файлов темы и плагинов в один, чтобы сократить количество запросов к серверу. Пока протокол HTTP/2 не шибко актуален, для ускорения загрузки страниц можно экономить запросы. Я перепробовал все подобные плагины, Autoptimize - самый корректный, он совместим с большинством тем WordPress. После установки и активации плагина зайдите в его настройки и включите все три вида оптимизации: HTML, CSS и JS.
W3 Total Cache - самый лучший в мире плагин кэширования. С Nginx отлично дружит, после установки и настройки сайт будет летать. Выделил настройку в отдельную главу. Ничего сложного, нужно просто пробежаться по пунктам.
Настройка iThemes Security
После установки плагина и получения бесплатного API ключа зайдите в пункт Security в меню панели и пройдитесь по разделам настроек. Я перечислю только те, которые лучше изменить, всё остальное можете не трогать.
Основные настройки:
- Тип журнала событий - Только в файле , чтобы база данных не росла в размере.
- Скрыть меню безопасности в админ панели - поставьте галку, чтобы убрать не шибко нужный пункт.
Заблокированные пользователи:
- Включить черный список от сайта HackRepair.com - поставьте галку.
Local Brute Force Protection:
- Автоматически запретить пользователя «admin» - поставьте галку, чтобы каждый бот и умник, пытающийся зайти в вашу панель управления под самым банальным во Вселенной логином, получал автоматический бан.
SSL:
- Нажмите Enable в этом блоке настроек. Потом зайдите в его настройки и отметьте SSL для консоли управления , чтобы панель управления работала только по HTTPS.
Тонкая подстройка системы:
- Нажмите Enable, чтобы включить блок настроек. Затем в настройках поставьте галку на опциях Защита системных файлов, Отключить просмотр каталогов, Отключить PHP в папке Uploads, Disable PHP in Plugins, Disable PHP in Themes. Последние три опции могут поломать работу некачественно написанных шаблонов оформления и плагинов, так что поможет выявить подобные поделия.
Подстройка WordPress:
- Поставьте галки на Remove the Windows Live Writer header, Remove the RSD (Really Simple Discovery) header, Уменьшить спам в комментариях, Отключить сообщение об ошибке при неудачной попытке входа, Отключает архив автора для пользователя, у которого нет записей.
- Если не пользуетесь программой WordPress на Android, поставьте опцию XML-RPC в режим Отключить XML-RPC.
- REST API - в Restricted Access.
Настройка W3 Total Cache
Плагинов кэширования сайтов на WordPress бесчисленное множество, как и вообще способов ускорить сайт, сохраняя промежуточные результаты работы скриптов. Всего я насчитал пять этапов/видов кэширования, каждый из которых может ускорить сайт:
I.
Кэширование PHP с помощью технологии OPCache.
Компиляция скриптов в более быстрый код, ускоряет их выполнение минимум в 2 раза. Выбор веб-сервера на работу OPCache не влияет, это настройка интерпретатора PHP. Как включить, расскажу в отдельной главе ниже.
II. Кэширование средствами CMS.
Благодаря плагинам кэширования WordPress типа W3 Total Cache или WP Super Cache результат работы скриптов в виде страничек сайта отдаётся не только веб-серверу, но и сохраняется в виде статичных html-файлов. Самый предсказуемый, управляемый вид кэширования. При первом посещении страничка откроется медленно (как обычно), при последующих - очень быстро,
как и все статичные файлы, если используется Nginx.
При использовании Apache страницы тоже станут открываться шустрей, но по сравнению с Nginx прирост мал.
III.
Кэширование с помощью Varnish
или любого другого кэширующего прокси. Nginx и Apache можно настроить так, чтобы вместо обращения к интерпретатору страница подгружалась из промежуточного кэша, если она там есть. Если мне кто-нибудь объяснит, зачем нужен этот велосипед, буду весьма признателен. Ни одного плюса в подобной прослойке не вижу, потому что см. далее:
IV.
Кэширование средствами Nginx.
Сам веб-сервер тоже может сохранять готовые страницы и отдавать посетителям. Благодаря такой работе сайт будет открываться очень, очень быстро. Особенно если папку с кэшем расположить в оперативной памяти сервера.
К сожалению, в отличии от кэширования с помощью WordPress, Nginx будет отдавать посетителям старые странички до тех пор, пока файлы кэша не будут удалены. Раньше можно было управлять очисткой с помощью плагина WordPress Nginx Helper, но в последних бесплатных
версиях веб-сервера разработчики удалили модуль fastcgi_cache_purge. Настроить кэширование в Nginx для корректной работы всё же можно, но это тема отдельной статьи. В большинстве случаев такое кэширование не нужно, достаточно кэширования средствами CMS.
V.
Браузерное кэширование.
Можно и нужно настроить веб-сервер так, чтобы браузер кэшировал статичные файлы (фотографии, .css и.js файлы) минимум на неделю, чтобы лишний раз не загружать с сервера одно и то же. Включается легко в том же W3 Total Cache, польза неоспорима.
При использовании Apache II
и III
виды кэширования не смогут быть эффективными, потому что обработкой запросов будет заниматься медленный веб-сервер.
Итак, как же ускорить с помощью W3 Total Cache? Установите этот плагин, зайдите в его настройки на страницу General Settings:
Раздел Page Cache:
- Галку на Enable , настройку Page Cache Method на Memcached.
Раздел Database Cache:
- Галку на Enable , настройку Database Cache Method на Memcached.
Раздел Object Cache:
- Галку на Enable , настройку Object Cache Method на Memcached.
Раздел Miscellaneous:
- Снимите галку с Enable Google Page Speed dashboard widget , этот инструмент может ввести в заблуждение.
- Снимите галку с Anonymously track usage to improve product quality , незачем отсылать информацию о своём сайте.
Страница настроек Page Cache:
- Поставьте галки в разделе General на опциях Cache feeds: site, categories, tags, comments, Cache SSL (https) requests.
- В разделе Advanced
, если будете использовать популярный плагин Yoast SEO,
измените содержимое поля Never cache the following pages:
на
wp-.*\.php
index\.php
(+)?sitemap(_index)?(-)?(*)?\.(xml(\.gz)?|xsl)$
Страница настроек Browser Cache (настройка кэширования в браузере):
- Поставьте галки в разделе General на опциях Set expires header, Set cache control header, Set entity tag (ETag), Don’t set cookies for static files, Apply HTTP Strict Transport Security policy.
- Поставьте галки в разделах CSS & JS, HTML & XML, Media & Other Files на опциях Set expires header, Set cache control header, Set entity tag (eTag), Disable cookies for static files.
Страница Extensions:
- Выключите модули Fragment Cache и New Relic.
Подобных настроек достаточно, чтобы сайт стал открываться быстро. Не забудьте посмотреть следующую главу, чтобы подключить часть настроек Nginx, которые создали плагины iThemes Security и W3 Total Cache.
Настройка Nginx
Осталось совсем чуть-чуть: нужно сделать так, чтобы Nginx подключал настройки, сделанные плагинами iThemes Security и W3 Total Cache. Для редактирования файлов конфигурации Nginx нужны права суперпользователя, поэтому запустите Midnight Commander командой
sudo mc
и зайдите в папку /home/admin/conf/web:
Увидите два файла:
- nginx.conf - настройка сайтов, доступных по протоколу http.
- snginx.conf - сайты по протоколу https.
В nginx.conf настройки сайтов будут всегда. В snginx.conf только в том случае, если включали SSL при создании сайта в панели управления VestaCP. В принципе, вы можете редактировать эти файлы, но после этого при попытке добавить новый сайт через Весту конфигурационные файлы превратятся в кашу. Придётся сбросить все правки командой v-rebuild-web-domains admin yes .
Поэтому нужно создать отдельный файл с настройками, который подхватится nginx, и не будет мешать работе панели управления. Для этого в Midnight Commander в папке /home/admin/conf/web нажмите Shift+F4 . Если до этого никогда не редактировали файлы через MC, появится выбор редактора. Выберите mcedit .
Вставьте туда вот такой код:
include /home/admin/web/имя_вашего_домена
/public_html/*.conf;
Благодаря этой строчки будет подхватываться файл nginx.conf, который создается плагином W3 Total Cache и другими совместимыми с Nginx.
Если пользуетесь плагином SEO-оптимизации Yoast SEO, добавьте ещё это:
#Yoast SEO Sitemaps location ~ ([^/]*)sitemap(.*).x(m|s)l$ { rewrite ^/sitemap.xml$ /sitemap_index.xml permanent; rewrite ^/(+)?-?sitemap.xsl$ /index.php?xsl=$1 last; rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last; rewrite ^/([^/]+?)-sitemap(+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last; }
Нажмите F2 для сохранения файла, появится окно выбора имени файла. Введите nginx.имя_вашего_домена.conf_custom.
Потом Ctrl+O
для скрытия MC и наберите в консоли для проверки конфига:
sudo service nginx configtest
Если всё ОК, перезапустите сервер для применения конфига:
sudo service nginx restart
Теперь ваш сайт защищён и кэширование работает нормально.
Настройка PHP-FPM
В Интернете полно инструкций о том, что можно редактировать в файле /etc/php/7.0/fpm/php.ini. Я лишь приведу парочку, которые в любом случае стоит изменить.
Для повышения безопасности:
Session.use_strict_mode = 1
Для включения OPCache, о котором я писал выше:
Opcache.enable=1 opcache.memory_consumption=128 opcache.max_accelerated_files=7963 opcache.max_wasted_percentage=10
Обратите внимание - нужно убрать «;» перед строками. Ещё можете указать параметр opcache.validate_timestamps=0 , если готовы перезагружать сервер после каждого обновления темы, плагинов и самого WordPress. Параметр отключает проверку изменения файлов PHP, придётся очищать вручную кэш OPCache.
После применения настроек перезагрузите Nginx и PHP-FPM командой:
sudo service nginx restart && sudo service php-fpm restart
Что дальше?
Файлы конфигурации, где сосредоточены все настройки, влияющие на производительность сервера:
- Настройки веб-сервера Nginx хранятся в файле /etc/nginx/nginx.conf
- Настройки PHP хранятся в файлах папки /etc/php/7.0/fpm/
- Настройки сервера MySQL в /etc/mysql/my.cnf
Для того, чтобы копаться в конфигах, нужны знания и возможность измерить результаты. Поэтому советую не переживать и оставить настройки по умолчанию. Они подходят для большинства серверов и сайтов. Когда вы по-настоящему поймёте, как работают веб-сервера, вот тогда стоит приступать к экспериментам.
А пока приведённых мною настроек хватит, чтобы ваш сайт выдержал несколько тысяч посетителей в минуту, в зависимости от производительности сервера.
P.S. Ко мне поступило несколько предложений написать инструкцию по установке VestaCP для CentOS. Разница между Убунтой и любым другим дистрибутивом Linux невелика. Вы вполне можете поставить Весту и на Debian, и CentOS, если знаете команды пакетного менеджера. Поэтому отдельной статьи не будет.
P.P.S. Я не оказываю помощь в настройке этой панели управления. Судя по проблемам, возникшим примерно за год использования, данная панель довольно глючная. С ней постоянно возникают какие-то неурядицы, которые новички решить не могут. Я не автор этого продукта, ресурсов и времени быть техподдержкой VestaCP у меня нет.
Настройка VPS с нуля - это набор стандартных действий, которые сможет проделать и новичок. С помощью нашей статьи.
Первое, с чего стоит начать - выбор операционной системы для вашего новенького виртуального сервера. Рассмотрим наиболее популярные UNIX-подобные системы.
Какая операционная система лучше подойдет для VPS?
1. Debian и CentOS
Обе эти операционные системы способны хорошо работать на скромных выделенных ресурсах. Исходя из этого факта, данные системы стоит выбирать, если вы заказываете с достаточно скромными ресурсами, например, выбрали тарифный план с 512 Мб ОЗУ или ниже.
Стоит отметить, что если вы хотите работать с такой панелью управления, как ISP Manager, то в вашем случае больше подойдет CentOS, т.к. он хорошо совместим с этой панелью.
2. Fedora и Ubuntu
3. FreeBSD
Эта система необходима для некоторых специфических нужд, но чаще всего ее прекрасно может заменить любая из вышеназванных операционных систем. К ресурсам данная система также довольно требовательна. Сложности ожидают вас и при ее установке, т.к. этот процесс разработчиками практически не автоматизирован и занимает довольно много времени.
Настройка VPS
Теперь поговорим непосредственно о настройке VPS. В качестве примера рассмотрим настройку VPS на CentOS.
Первое, что нам нужно будет сделать - установить SSH-соединение с новеньким VPS. Делается это довольно просто, а поможет нам программа PuTTY. Скачав и запустив ее, перед собой вы увидите такое окно:
В полне под названием Host name введите DNS-имя или IP-адрес вашей VPS. Укажите порт, который будет использоваться для доступа (эту информацию можно получить у вашего хостера). Далее, в меню слева найдите пункт Translation и перейдите в него.
В выпадающем списке Remote character set выберите кодировку UTF-8. После этого нажмите кнопку Open и соединение будет установлено.
Предполгается, что CentOS уже установлен на сервере, и мы можем приступить к непосредственной работе с системой. Многие хостеры самостоятельно устанавливают требуемую операционную систему бесплатно, поэтому мы опустим вопрос установки.
Для начала систему необходимо обновить, для этого в консольном окне достаточно ввести всего одну команду:
# yum update
Вполне возможно, что хостер установил самую актуальную версию системы, поэтому в некоторых случаях обновление может не потребоваться, но проверить будет не лишним.
Следующий этап, ожидающий нас - это настройка iptables (брандмауэра). Для этого нам понадобится специальная утилита setup. Чаще всего она есть в системе, однако если ее не окажется, установить ее не сложно:
#yum install setuptool system-config-securitylevel-tui authconfig system-config-network-tui ntsysv
После того, как установка setup завершится, можно переходить к ее запуску:
# setup
В появившемся окне вы сможете либо вовсе отключить брандмауэр, либо открыть только необходимые порты. Рекомендуется открыть порты и выбрать соединения, с которыми нам предстоит работать (чаще всего это Web, SSH, FTP).
При желании или какой-то особой необходимости можно отключить iptables, однако это не рекомендовано:
# service iptables stop && chkconfig iptables off
Закончив, мы перейдем к установке и настройкe веб-сервера Apache и SSL. Для начала введите в консоль следующую команду:
# yum -y install httpd mod_ssl
После того, как закончите, необходимо перейти к редактированию конфигурационного файла Apache. Чтобы это сделать нужно в любом текстовом редакторе открыть файл /etc/httpd/conf/httpd.conf. Нам необходимо внести IP или имя сервера в ServerName. По завершении этого действия, необходимо настроить Apache на автоматический запуск:
# chkconfig httpd on
После всего этого Apache можно запустить:
# service httpd start
Если вы хотите проверить работоспособность веб-сервера, то существует простой и достаточно показательный тест - достаточно создать небольшую веб-страницу:
# echo " Hello, world! " > /var/www/html/index.html
После выполнения команды найдите другой компьютер или любое устройство, с активным подключением к сети Интернет и с помощью его браузера перейдите по адресу вида:
http://IP-адрес_вашего_VPS
Вы должны увидеть страницу с надписью “Hello, world!”. Ее появление свидетельствует об успешной установке и настройке.
# yum -y install php php-common php-gd php-mysql php-xml php-mbstring
После успешной установки PHP необходима перезагрузка Apache:
# service httpd restart
Чтобы проверить работу PHP, можно написать небольшой скрипт, который будет показывать информацию об установленной верии PHP:
# echo "" > /var/www/html/info.php
Чтобы увидеть его в действии, также с другой машины перейдите по адресу вида:
http://IP-адрес_вашего_VPS/info.php
Если PHP работает, то на открывшейся странице отобразится информация и можно приступить к следующим шагам.
Следующая наша задача - установка MySQL. С некоторого времени MariaDB официально является реализацией MySQL в CentOS. Для этого введите:
yum -y install mariadb mariadb-server
Закончив это, нам нужно будет назначить MySQL на автозагрузку:
# systemctl enable mariadb.service
Теперь самое время для запуска этой СУБД:
# systemctl start mariadb.service
Также обязательной мерой является установка root-пароля и настройка некоторых других опций :
# mysql_secure_installation
Закончив работу с MySQL перейдем к более глубокой настройке Apache. Убедившись в нормальной работе основных служб мы можем перейти к созданию директорий для наших сайтов.
Их структура будет такова:
/home/ — в этой директории будут содержаться сайты
/home/site.ru/ — здесь будет находиться каждый из отдельных сайтов
/home/site.ru/www/ — в этой директории разместятся файлы каждого конкретного сайта
/home/site.ru/logs/ — это место для лог-файлов
/home/site.ru/tmp/ — в эту директорию отправятся временные файлы
В директории /etc/httpd/conf.d/ для удобства мы будем содержать конфигурационные файлы каждого из сайтов, находящихся на нашем VPS.
В качестве примера приведем содержание конфигурационного файла для сайта site.ru (его имя должно быть site.conf):
Если на вашем VPS под управлением CentOS будет несколько сайтов, то такой файл нужно будет создать для всех них.
После того, как закончите, снова перезагрузите Apache:
# service httpd restart
Если что-то не сработает, то отчет об ошибках можно будет найти в /var/log/httpd/.
Завершающим этапом базовой настройки VPS на CentOS станет настройка и установка PHPMyAdmin.
В это статье мы будем рассматривать ручной способ инсталляции. Для того, чтобы это сделать нам нужен wget - специальный менеджер загрузок, устанавливается он довольно просто:
# yum -y install wget
Далее нужно перейти на домашнюю страницу проекта PHPMyAdmin http://www.phpmyadmin.net/home_page/downloads.php и найти ссылку на самую свежую версию PHPMyAdmin с поддержкой нескольких языков в формате tar.gz. Э ту ссылку необходимо просто скопировать.
Затем введите команду:
# cd /var/www/html/
После этого нужно загрузить PHP My Admin:
# wget https://files.phpmyadmin.net/phpMyAdmin/4.8.1/phpMyAdmin-4.8.1-all-languages.zip
В указанной директории должен быть загруженный архив phpMyAdmin, его нужно распаковать:
# tar xzf phpMyAdmin-4.8.1-all-languages.zip
Будет создана директория phpMyAdmin-4.8.1-all-languages, которую надо переименовать в phpmyadmin:
# mv phpmyadmin
Приводим файл /etc/httpd/conf.d/phpMyAdmin.conf к виду:
Order allow,deny
Allow from all
Внимание! Данные настройки позволят всем видеть ресурс phpMyAdmin. Рекомендуем установить дополнительную авторизацию на раздел либо использовать другие способы органичения доступа.
Загруженный архив можно удалить, т.к. он больше нам не понадобится:
# rm phpMyAdmin-4.8.1-all-languages .tar.gz
На этом процесс установки PHPMyAdmin закончен. Его работу можно проверить, перейдя по адресу вида:
https://IP-адрес_вашего_VPS/phpmyadmin/
Вместе с окончанием установки PHPMyAdmin окончена и базовая настройка VPS-сервера, управляемого CentOS.
В этой статье мы поэтапно расскажем о том, как создать виртуальный сервер (VPS/VDS) в панели управления сайт и о том, как подключиться к созданному серверу.
Компания Serverspace предоставляет услуги Облачных серверов в аренду — ознакомьтесь с нашими тарифами на VPS на Windows и Linux .
Итак, начнем.
Создание виртуального сервера
1. в панели управления сайт, перейдите в раздел «Серверы» и нажмите кнопку «Создать сервер».
2. Затем выберите шаблон виртуального сервера - операционную систему (ОС), которая будет установлена на сервер. Для установки доступны следующие ОС:
- Windows Server 2008 R2 (RU/ENG);
- Windows Server 2012 R2 (RU/ENG);
- Windows Server 2016 R2 (RU/ENG);
- FreeBSD 10, 11;
- Debian 8.11, 9.5;
- Ubuntu 16.4, 18.4;
- CentOS 6.10, 7.5;
- PfSense 2.4;
- VyOS 11.8.
Стоимость лицензии Windows Server при выборе соответствующей ОС уже включена в абонентскую плату, независимо от того, имеется у вас домен в виртуальной инфраструктуре или нет.
Если же вы планируете установить на VPS/VDS другую ОС, просто создайте ее ISO-образ и отправьте его нашей техподдержке.
Параметры готовых конфигураций:
При этом в дальнейшем вы сможете менять конфигурацию прямо в панели управления.
После выбора ОС необходимо выбрать центр обработки данных (ЦОД) , в котором будет размещаться ваш виртуальный сервер. Наши ЦОД-ы расположены в Беларуси (beCloud), России (DataSpace) и в Нидерландах (AM2), и для каждой страны доступна своя конфигурация:
4. За дополнительную плату вы можете подключить автоматическое создание резервных копий (бэкапов) виртуального сервера, которые создаются раз в сутки. Для этого необходимо выбрать период хранения бэкапов - 7, 14, 21 или 28 дней.
5. Если на этапе подбора операционной системы вы выбрали ОС Windows Server и ее необходимо включить в существующий домен Microsoft Active Directory, просто поставьте галочку в чекбоксе «выполнить системную подготовку Windows». При этом время создания сервера увеличится на 15-20 минут, так как в процессе создания будет запущена специальная утилита sysprep.
Если же в качестве операционной системы выбрана FreeBSD, Debian, Ubuntu или CentOS, необходимо дополнительно указать способ подключения - через пару логин/пароль или по SSH. Логин и пароль генерируются автоматически и появляются на экране после создания сервера. SSH-ключ можно сгенерировать при помощи программы ssh-keygen или прикрепить уже сгенерированный ключ.
6. Затем необходимо указать количество серверов и присвоить им имена. За один раз можно создать до 5 серверов.
При создании сервера сетевому интерфейсу будет автоматически присвоен один бесплатный IPv4-адрес. В дальнейшем вы сможете подключить дополнительные IPv4- и IPv6-адреса за отдельную плату.
Подключение к виртуальному серверу
После создания виртуального сервера к нему можно подключиться через веб-консоль. Для подключения потребуется логин и пароль администратора, указанные во вкладке «Состояние».
Кнопка перехода в веб-консоль расположена в правом верхнем углу. Если вам неудобно пользоваться веб-консолью, вы можете подключаться к серверу любым другим удобным способом.
Подключение к операционным системам происходит по разным протоколам: для FreeBSD, Debian, Ubuntu и CentOS используется протокол SSH, а для подключения к серверам Windows - протокол RDP.
В интернете сегодня можно не только развлекаться, но и учиться, работать и зарабатывать. Количество сайтов растет ежесекундно, услуги хостинга также становятся привлекательными и множатся как грибы после дождя. Бывает, что хостер оправдывает все ожидания, но иногда приходится и переезжать. Можно нанять фрилансера, но лучше научиться делать это самому. Сегодня тебя ждет небольшая инструкция именно на этот случай.
Постановка задачи
Ситуация самая жизненная. Интернет-магазин, размещенный на шаред-хостинге, после запуска начал получать клиентов, но появились пожелания к функциональности, и разработчики активно занялись доработкой сайта. Выяснилось, что, когда в этом участвует несколько человек, постоянно копировать файлы через FTP для теста, да и еще на рабочий сайт, очень проблемно. Терялся контроль, кто когда что сделал, нужно было беспокоиться о сохранении оригинальных файлов, чтобы было легко откатиться. Владельцу приходилось или согласовывать правки, или копировать все самому. Разработчик не мог сразу посмотреть результат и ждал. Процесс сильно тормозился. В итоге пришли к тому, что нужно использовать возможности Git и создать новый сайт-зеркало, где можно было бы все обкатывать. При такой схеме разработчик мог сразу тестировать код, а в случае одобрения код переносили в master и выкладывали уже на рабочий сайт. Также можно легко отслеживать коммиты.
Вторая проблема: хостинг постоянно падал. Причину в итоге нашли: Entry processes limit - параметр, который определяет количество CGI/PHP-процессов, входящих внутрь виртуального контейнера, и о котором не сильно любят говорить маркетологи хостера. На графиках его тоже не видно, только маленькая графа в таблице. В итоге при небольших нагрузках CPU и RAM (не более 20%) сервер вообще не работал даже при минимальном количестве посетителей. В итоге было принято решение переезжать.
Первоначальные настройки сервера
OC в VDS устанавливается автоматически. Достаточно выбрать версию и вариант с веб-панелью или без и чуть подождать, пока не придет письмо с данными для входа. На хостингах предлагаются и разные веб-панели. Когда этот материал создавался, Vesta не поддерживала Ubuntu 16.04 и необходимости в ней не было, поэтому выбрали чистую систему. Все дальнейшие действия ведутся от имени root. Первым делом проверяем локаль, часовой пояс и время. Вообще, веб-приложения обычно не обращают внимания на некоторые системные настройки, но иногда попадается именно тот случай, поэтому лучше сразу сделать все правильно.
# locale
Если в ответ получаем отличное от ru_RU.UTF - перенастраиваем.
# locale-gen ru_RU ru_RU.UTF-8 ru_RU ru_RU.UTF-8 # localedef -c -i ru_RU -f UTF-8 ru_RU.UTF-8 # dpkg-reconfigure locales # update-locale LANG=ru_RU.UTF-8
Проверяем время:
Если часовой пояс не соответствует - переконфигурируем.
# dpkg-reconfigure tzdata
Обновляем сервер:
# apt update && apt upgrade
Теперь можем ставить сервисы.
Ставим веб-сервер
Несмотря на их разнообразие, выбор установки обычно сводится к трем вариантам: Apache, nginx или nginx как реверс Apache. Apache очень гибок в настройках и использует модули для обработки динамических запросов, поэтому хорошо справляется с динамикой. Nginx хорош в отдаче статики и потребляет меньше ресурсов, но для обработки динамики использует сторонний модуль, что снижает скорость и чуть усложняет настройки. В зависимости от конкретного приложения каждый из них может иметь свои плюсы и минусы и показывать разную скорость. Поэтому окончательный выбор веб-сервера всегда приходится подтверждать практикой, подбирая оптимальный вариант. Проблема nginx - то, что в некоторых специфических движках следует вручную возиться с редиректами, когда на Apache все будет работать буквально из коробки, достаточно просто включить mod_rewrite.
Нагрузочное тестирование можно произвести при помощи ab (Apache Benchmark, входит в apache2-utils) или siege. Причем лучше проверить с localhost и удаленного узла, чтобы видеть, как работает сеть.
# ab -c 10 -n 6000 http://example.org/
Хотя ab - это скорее для себя, чтобы оценить эффективность установок. Человека со стороны обычно интересует только то, что показывает Google PageSpeed , поэтому ориентироваться следует и на него.
В последнем случае сайт на старом хостинге давал 60, после переноса на VDS (с такими же параметрами) он в Apache в установке по умолчанию показывал 72, nginx с голым конфигом - 62, после добавления сжатия - 78. На этом и остановились, выбрали nginx. В репозитории несколько пакетов, для большинства ситуаций достаточно базового core, содержащего все основные модули, для PHP нам понадобится FPM.
# apt nginx install nginx php7.0-fpm
Файл в общем стандартный, но для скорости добавим кеширование и сжатие. Точные параметры в каждом случае необходимо подбирать опытным путем, но для небольших и средних проектов таких установок обычно бывает достаточно. В nginx.conf добавляем или, если повезло, снимаем комментарии в секции http:
# nano /etc/nginx/nginx.conf http { .... open_file_cache max=200000 inactive=60s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; server_tokens off; server_names_hash_bucket_size 64; reset_timedout_connection on; client_body_timeout 10; gzip on; gzip_disable "msie6"; gzip_static on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js; }
Создаем настройки для домена:
# nano /etc/nginx/sites-available/example.org server { listen 80; server_name example.org default; root /var/www/example.org; access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; rewrite_log on; # Полезная настройка для отладки index index.php; try_files $uri $uri/ /index.php?$query_string; location ~ \.php$ { include /etc/nginx/fastcgi_params; # fastcgi_pass 127.0.0.1:9000; fastcgi_pass unix:/run/php/php7.0-fpm.sock; } # Кешируем картинки и txt/XML/JS/CSS. Можно убрать ненужное или что-то добавить location ~* ^.+\.(jpg|jpeg|gif|png|js|css|txt|xml)$ { access_log off; expires 30d; } # Блокируем доступ к каталогу.git (о нем дальше), по аналогии добавляем свои правила location ~ /\.git { deny all; } }
Это общий пример для стандартного движка. Некоторые движки вроде OpenCart или WebAsyst требуют специфических настроек, и даже не всегда работает то, что предлагается в Сети.
Проверяем, работает ли сжатие. Это можно сделать, просмотрев заголовок Content-Encoding в Firebug (он должен показывать gzip), или при помощи специального сервиса .
Включаем сайт:
# ln -s /etc/nginx/sites-available/example.org /etc/nginx/sites-enabled/example.org
Перезапускаем nginx:
# service nginx restart
Но работать еще не будет. Нужно настроить PHP. Для FPM все установки находятся в /etc/php/7.0/fpm. Проверяем, что в pool.d/www.conf учетная запись совпадает с используемой nginx и включен сокет.
# nano /etc/php/7.0/fpm/pool.d/www.conf user = www-data group = www-data listen = /run/php/php7.0-fpm.sock
Кроме этого, можно обратить внимание на параметры, определяющие количество процессов, которые будут обслуживать PHP-запросы.
Pm = dynamic pm.max_children = 15 pm.start_servers = 6 pm.min_spare_servers = 2 pm.max_spare_servers = 6
На чуть загруженных серверах может не хватать количества процессов. В логах об этом сразу скажут.
# cat /var/log/php7.0-fpm.log WARNING: server reached pm.max_children setting (5), consider raising it
Еще важный файл php.ini. Параметров там много, и можно рассказывать долго. Но изначально следует включить сжатие, установить максимальный размер файла на аплоад, подключить mail(), сессии и очень желательно включить акселератор OPcache.
# nano /etc/php/7.0/fpm/php.ini zlib.output_compression = On upload_max_filesize = 2M sendmail_path = sendmail -t -i session.save_path = "/var/lib/php/sessions" opcache.enable=1 opcache.memory_consumption=128 pcache.max_accelerated_files=2000
Обязательно проверяем права доступа на /var/lib/php/sessions, чтобы туда мог писать nginx, иначе сессии не будут образовываться. Перезапускаем.
# service php7.0-fpm restart
Теперь перенос сайта. Если переносим с другого хостинга, то там создаем бэкап. Если есть хостинговая веб-панель, то можно использовать ее возможности. Или вручную:
# tar -zcvf backup.tar.gz /var/www
И на новом месте распаковываем:
# tar -zxvf backup.tar.gz /var/www
Но для сайта нам нужна СУБД.
Ставим MySQL
C MySQL все очень просто. Вводим
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!