Настройка VDS Подробное руководство по развертыванию своего сервера
Настройка VDS. Подробное руководство по развертыванию своего сервера.
Данное руководство предназначено для развертывания и настройки VDS сервера на примере Ubuntu 20.04 с установкой веб-сервера nginx, php 7 и сервера базы данных MySQL.
Автор материала
Артем Зернов. Веб-разработчик, создатель проекта Лектория, эксперт MODX Revolution, директор веб-студии OpenColour. Youtube-канал OpenModx.
Для чего?
Вы уже получили навыки в создании web приложений и хотите разместить созданный сайт в интернете, но как это сделать? Все просто! Есть хостинг провайдеры, которые, как раз и предоставляют услуги, по размещению сайтов в сети. Заходя на страничку к провайдеру, вы видите, что можно взять в аренду виртуальный хостинг или VDS.
В чем разница? Давайте рассмотрим эти продукты и избавимся от боязни их использовать. Начнем по порядку от общего к частному.
Хостинг — это услуга по предоставлению ресурсов для размещения информации на сервере, постоянно имеющем доступ к интернету. Следовательно виртуальный хостинг — вид хостинга, при котором множество веб-сайтов расположено на одном веб-сервере. Это самый экономичный вид хостинга, подходящий для небольших проектов. Исходя из определения разные тарифы на виртуальные хостинг могут отличаться по следующим основным параметрам:
- размер дискового пространства;
- количество месячного трафика;
- количество сайтов, которые можно разместить в рамках хостинга как одной услуги;
- количество баз данных и количество места под базы данных;
- количество почтовых ящиков и FTP-аккаунтов;
- ресурсы CPU;
- количество оперативной памяти.
Примеры тарифов (хостинг timeweb)
Используя виртуальный хостинг, соответственно Вы попадаете в определенные ограничения по использованию ресурсов, при превышении которых выставляются предупреждения об ограничении работы и предлагается повысить тариф или начать работу по оптимизации сайта. Но как компенсация этого, в Вашем распоряжении есть административная панель, с помощью которой вы можете реализовать все функции по управлению сайтами.
Альтернативой виртуального хостинга является использование VDS\VPS (Virtual Dedicated\Private Server) — это, виртуальный выделенный или приватный сервер, который предоставляется хостинг провайдером в аренду заказчику.Чтобы не вводить в заблуждение, сразу отмечу, что разницы между аббревиатурами VPS и VDS нет никакой. Дело в том, что два этих понятия появились практически одновременно и параллельно развивались.
Что же такое VDS? Говоря простым языком, поставщик услуг на своем оборудовании, с помощью средств виртуализации разворачивает несколько виртуальных (программных) серверов. С точки зрения функциональности такой сервер ничем не отличается от физического, на него также устанавливаются операционная система и программное обеспечение, он также расположен в сети и управляется, как и остальные ПК, средствами удаленного администрирования. При этом данный сервер находится на удаленной площадке провайдера, которая защищена от сбоев и оптимизирована под работу 24/7/365. В свою очередь хостинг провайдер берет на себя все обязательства по обслуживанию и сопровождению оборудования и системы виртуализации. Но соответственно цену на эту услугу несколько выше чем на виртуальный хостинг.
Примеры тарифов VDS
К достоинствам этой услуги можно отнести, что Вы больше не будете ограничены количеством месячного трафика, размещаемых сайтов, базами данных и прочим. В Ваших силах теперь установить на свой VDS все необходимое программное обеспечение без каких-либо запретов и ограничений.
Но и минусы тоже есть. Настройка и администрирование теперь является Вашей заботой.
Что бы исправить возникшую несправедливость и обучить настройке и азам администрирования VDS и создано это руководство.
Исходные данные
Определим, что у нас есть некоторый сайт, работающий на php+MySQL под управлением некой CMS (в нашем случае это будет MODX Revolution, но на процесс настройки VDS это не влияет), а это значит, что помимо развертывания CMS необходимо установить и настроить основные модули php, nginx, mysql. Для этого определим следующую последовательность наших действий:
Регистрация на хостинге и конфигурация VDS
В руководстве будем пользоваться услугами компании timeweb. Переходим на вкладку VPS / VDS, из предлагаемых тарифов выбираем тот, который нам подходит по характеристикам и нажимаем кнопку заказать. После этого попадаем в окно регистрации и выбора параметров виртуального сервера.
В текстовые поля вводим свою фамилию, имя и отчество, и адрес электронной почты. В выпадающем списке меняем операционную систему на Ubuntu 20.04
Источник
Сам себе админ. Учимся настраивать VDS и переносить сайты
В интернете сегодня можно не только развлекаться, но и учиться, работать и зарабатывать. Количество сайтов растет ежесекундно, услуги хостинга также становятся привлекательными и множатся как грибы после дождя. Бывает, что хостер оправдывает все ожидания, но иногда приходится и переезжать. Можно нанять фрилансера, но лучше научиться делать это самому. Сегодня тебя ждет небольшая инструкция именно на этот случай.
Постановка задачи
Ситуация самая жизненная. Интернет-магазин, размещенный на шаред-хостинге, после запуска начал получать клиентов, но появились пожелания к функциональности, и разработчики активно занялись доработкой сайта. Выяснилось, что, когда в этом участвует несколько человек, постоянно копировать файлы через FTP для теста, да и еще на рабочий сайт, очень проблемно. Терялся контроль, кто когда что сделал, нужно было беспокоиться о сохранении оригинальных файлов, чтобы было легко откатиться. Владельцу приходилось или согласовывать правки, или копировать все самому. Разработчик не мог сразу посмотреть результат и ждал. Процесс сильно тормозился. В итоге пришли к тому, что нужно использовать возможности Git и создать новый сайт-зеркало, где можно было бы все обкатывать. При такой схеме разработчик мог сразу тестировать код, а в случае одобрения код переносили в master и выкладывали уже на рабочий сайт. Также можно легко отслеживать коммиты.
Вторая проблема: хостинг постоянно падал. Причину в итоге нашли: Entry processes limit — параметр, который определяет количество CGI/PHP-процессов, входящих внутрь виртуального контейнера, и о котором не сильно любят говорить маркетологи хостера. На графиках его тоже не видно, только маленькая графа в таблице. В итоге при небольших нагрузках CPU и RAM (не более 20%) сервер вообще не работал даже при минимальном количестве посетителей. В итоге было принято решение переезжать.
Первоначальные настройки сервера
OC в VDS устанавливается автоматически. Достаточно выбрать версию и вариант с веб-панелью или без и чуть подождать, пока не придет письмо с данными для входа. На хостингах предлагаются и разные веб-панели. Когда этот материал создавался, Vesta не поддерживала Ubuntu 16.04 и необходимости в ней не было, поэтому выбрали чистую систему. Все дальнейшие действия ведутся от имени root. Первым делом проверяем локаль, часовой пояс и время. Вообще, веб-приложения обычно не обращают внимания на некоторые системные настройки, но иногда попадается именно тот случай, поэтому лучше сразу сделать все правильно.
Если в ответ получаем отличное от ru_RU.UTF — перенастраиваем.
Если часовой пояс не соответствует — переконфигурируем.
Теперь можем ставить сервисы.
Настраиваем часовой пояс
Xakep #212. Секреты даркнета
Ставим веб-сервер
Несмотря на их разнообразие, выбор установки обычно сводится к трем вариантам: Apache, nginx или nginx как реверс Apache. Apache очень гибок в настройках и использует модули для обработки динамических запросов, поэтому хорошо справляется с динамикой. Nginx хорош в отдаче статики и потребляет меньше ресурсов, но для обработки динамики использует сторонний модуль, что снижает скорость и чуть усложняет настройки. В зависимости от конкретного приложения каждый из них может иметь свои плюсы и минусы и показывать разную скорость. Поэтому окончательный выбор веб-сервера всегда приходится подтверждать практикой, подбирая оптимальный вариант. Проблема nginx — то, что в некоторых специфических движках следует вручную возиться с редиректами, когда на Apache все будет работать буквально из коробки, достаточно просто включить mod_rewrite.
Нагрузочное тестирование можно произвести при помощи ab (Apache Benchmark, входит в apache2-utils) или siege. Причем лучше проверить с localhost и удаленного узла, чтобы видеть, как работает сеть.
Хотя ab — это скорее для себя, чтобы оценить эффективность установок. Человека со стороны обычно интересует только то, что показывает Google PageSpeed, поэтому ориентироваться следует и на него.
В последнем случае сайт на старом хостинге давал 60, после переноса на VDS (с такими же параметрами) он в Apache в установке по умолчанию показывал 72, nginx с голым конфигом — 62, после добавления сжатия — 78. На этом и остановились, выбрали nginx. В репозитории несколько пакетов, для большинства ситуаций достаточно базового core, содержащего все основные модули, для PHP нам понадобится FPM.
Файл в общем стандартный, но для скорости добавим кеширование и сжатие. Точные параметры в каждом случае необходимо подбирать опытным путем, но для небольших и средних проектов таких установок обычно бывает достаточно. В nginx.conf добавляем или, если повезло, снимаем комментарии в секции http:
Создаем настройки для домена:
Это общий пример для стандартного движка. Некоторые движки вроде OpenCart или WebAsyst требуют специфических настроек, и даже не всегда работает то, что предлагается в Сети.
Проверяем, работает ли сжатие. Это можно сделать, просмотрев заголовок Content-Encoding в Firebug (он должен показывать gzip), или при помощи специального сервиса.
Но работать еще не будет. Нужно настроить PHP. Для FPM все установки находятся в /etc/php/7.0/fpm. Проверяем, что в pool.d/www.conf учетная запись совпадает с используемой nginx и включен сокет.
Кроме этого, можно обратить внимание на параметры, определяющие количество процессов, которые будут обслуживать PHP-запросы.
На чуть загруженных серверах может не хватать количества процессов. В логах об этом сразу скажут.
Еще важный файл php.ini. Параметров там много, и можно рассказывать долго. Но изначально следует включить сжатие, установить максимальный размер файла на аплоад, подключить mail(), сессии и очень желательно включить акселератор OPcache.
Обязательно проверяем права доступа на /var/lib/php/sessions, чтобы туда мог писать nginx, иначе сессии не будут образовываться. Перезапускаем.
Теперь перенос сайта. Если переносим с другого хостинга, то там создаем бэкап. Если есть хостинговая веб-панель, то можно использовать ее возможности. Или вручную:
И на новом месте распаковываем:
Но для сайта нам нужна СУБД.
Проверяем сжатие отдаваемых веб-сервером данных
Ставим MySQL
C MySQL все очень просто. Вводим
На запрос указываем пароль root, и уже можно работать. Если не требуется доступ к нему извне, то следует разрешить использовать только локалхост или сокет.
После изменений перезапускаем:
Остальные параметры обычно настроены оптимально для большинства ненагруженных узлов. В процессе работы следует смотреть за журналами и значениями текущих переменных.
Вероятно, что-то придется подкрутить. Для быстрой оптимизации лучше воспользоваться советами, выдаваемыми скриптом MySQLTuner, который есть в репозитории.
Скрипт MySQLTuner позволяет оптимизировать MySQL
Переносим базу
Архивируем на старом хосте базу данных через phpMyAdmin или вручную:
Если нужны все базы, то используем ключ -A. Копируем на новый сервер. Создаем базу workbase, импортируем старые данные и создаем учетную запись baseadmin для работы с этой базой:
Заодно добавим учетку с меньшими правами для бэкапа.
Настраиваем подключение к БД в параметрах движка, и можно работать.
Почтовый сервер
Хотя некоторые приложения могут напрямую подключаться к внешнему SMTP (что очень даже хорошо: в случае взлома провайдер не забанит аккаунт из-за рассылки спама), но в большинстве приложений для отправки почты используют функцию mail() , а поэтому нам потребуется локальный SMTP-сервер. Здесь опять два варианта: настроить полноценный сервер или установить прокси, который будет подменять SMTP, переправляя запросы на внешний сервер (потребуется почтовый ящик). В качестве последнего отлично подходит ssmtp, который есть в репозитории. Хотя установить «большой» сервер в минимальной конфигурации — дело пяти минут.
В процессе выбираем «Интернет-сайт» и указываем домен.
И почта должна уже работать. Единственный момент — если почтовый ящик домена привязан к Gmail, то, когда в него идет письмо с этого же домена, технология DMARC Gmail может его отбросить как спам. Хотя если отправитель будет другой, то все будет работать. В этом случае следует убедиться, что SMTP-сервер не отправляет hostname, которое дал серверу хостер. Строку mydestination следует изменить на
Настройки Postfix во время установки
Мониторинг и бэкап
Две важные вещи — мониторинг и бэкап. После установки сайт может падать из-за неоптимальных настроек. Поэтому лучше сразу установить хотя бы простое решение, позволяющее перезапускать сервисы. В репозиториях есть отличные утилиты healt-check или monit, проверяющие не только сервисы, но и общее состояние системы. Настроек там много, и на первых порах или на легких сайтах можно обойтись простеньким скриптом. Для nginx он будет выглядеть примерно так:
По аналогии можно добавить контроль MySQL, PHP-FPM и SMTP-сервера.
Решений для бэкапа в репозитории больше чем достаточно, в зависимости от ситуации и наличия ресурсов можно подобрать себе любой по вкусу. В самом простом случае можно использовать самописный скрипт, который будет собирать папки /etc, веб-серверы и SQL-базы и отправлять их на FTP. Файлы будем хранить неделю. Чтобы файлы удалялись автоматически, в имени будем использовать остаток от деления, тогда новый файл с таким же именем будет перезатираться. В нашем примере будем делить на 7.
Прогоняем первый раз оба файла вручную, чтобы убедиться в их работоспособности. И добавляем задачи в /etc/crontab. Мониторить будем каждые десять минут, резервную копию будем создавать ежедневно в 20:00.
На данный момент мы имеем полностью настроенный веб-сервер.
Подключаемся к Bitbucket
Вся изюминка переноса состояла в использовании при разработке веб-сайта Git. Выглядело интересно, осталось только это все реализовать. Здесь можно пойти несколькими путями. Самый, наверное, простой — инициализировать локальный репозиторий и позволить разработчику при коммите выкладывать файлы прямо на сервер. Минус здесь — мы фактически даем ему доступ на сервер. Поэтому лучше перестраховаться, и самым правильным вариантом будет использовать посредника с возможностью автоматического pull файлов после коммита. Так мы получаем еще один источник бэкапа. В качестве промежуточного сервиса был выбран сервис «ведро битов» Bitbucket, предлагающий всякие вкусности вроде бесплатных «private»-репозиториев и удобного интерфейса. Хотя, в принципе, это может быть любой другой подобный сервис — GitHub или Google Cloud Source Repositories.
Механизм взаимодействия будет простым. Создаем репозиторий (можно в отдельной теме), инициализируем Git прямо в корне сайта (как вариант, можно переносить с другого каталога, но это не так интересно), добавляем удаленный репозиторий Bitbucket и подключаем сервер к аккаунту Bitbucket. Чтобы коммит на Bitbucket сразу попадал на веб-сайт, будем использовать механизм хуков. Сам Git предоставляет такую возможность, а в Bitbucket есть даже два варианта.
Для пула можно использовать протокол HTTPS или Git — ставить эту схему в уже рабочий сайт или разворачивать с нуля. В случае HTTPS меньше настроек, просто после инициализации подключаем удаленный репозиторий и в последующем тянем из него изменения.
Но если придется экстренно вносить правки в файлы вручную, то возможен конфликт при будущих pull. Если же используем SSH, то настроек чуть больше, но зато, поправив файл, можем сразу сделать commit, избежав возможных проблем.
Для подключения через Git/SSH нужно на Bitbucket загрузить публичный ключ. Генерируем:
В качестве имени вводим bitbucket, чтобы не путаться. На запрос пароля жмем ввод. Меняем сразу права, иначе будет ругаться.
Проверяем, работает ли ssh-agent:
Смотрим, чтобы в
/.ssh/config была информация для идентификации хоста Bitbucket:
Добавляем публичный ключ bitbucket.pub на Bitbucket в настройках учетной записи «Безопасность -> SSH-ключи». После этого должны заходить ssh -Tvv git@bitbucket.org без пароля. Теперь у нас два варианта: пустой или рабочий сайт. Если сайт пустой, а репозиторий содержит данные, то просто делаем
Это вариант самый беспроблемный, так как сайт фактически ставим с нуля и не будет конфликтов между локальными файлами и теми, что уже есть в репозитории. В других случаях следует инициализировать репозиторий и добавить удаленный.
После чего тянуть изменения git pull origin master. Главная проблема в том, что Git не хочет инициализировать репозиторий в каталоге, в котором уже есть файлы. Выкрутиться можно несколькими способами. Самый простой — проделать это все в отдельном каталоге, а затем скопировать в рабочий и проверить работу git pull. Но файлы в Git и локальные не должны различаться, иначе придется использовать git checkout, который набросает лишние строки в файле, в результате можем получить нерабочий сайт. Причем нет необходимости переносить весь сайт, достаточно перенести только каталог .git.
Не забываем про права доступа. Так как имя начинается с точки, то шаблон * не сработает, нужно указать явно.
Для большего контроля следует в .gitignore внести все файлы, которых не должны касаться изменения. Например, для WP это могут быть основные файлы и каталоги.
Проверяем работу с Bitbucket вручную
Теперь разработчик может выкладывать код в Bitbucket, а мы забирать на сайт. Осталось только автоматизировать процесс. В Git это позволяет система хуков — фактически скриптов, выполняющихся в зависимости от наступления определенного события. Реализованы хуки и в Bitbucket. Причем доступно сразу два варианта: веб-хук (Webhooks) и службы. В логах они выглядят так:
Настраиваются они через API или веб-интерфейс (меню «Настройки»). На проект можно создать несколько хуков. Для настройки веб-хука нужно указать URL и событие (всего 21 событие). В Webhooks на указанный в установках URL отправляется POST-запрос с данными в JSON-формате (в интерфейсе есть возможность просмотра View requests), при необходимости можно их отобрать и обработать запрос в зависимости от параметров.
В «Службах» можно выбрать несколько вариантов, включая и POST-запрос, Twitter и обращение к различным сервисам.
Добавляем Webhooks в настройках Bitbucket
Нам для нашей схемы достаточно, чтобы Bitbucket при пуше (repo:push) просто «дернул» URL в веб-хуке, а мы по этому событию вытянем коммит из репозитория. Создаем простой скрипт:
В целях безопасности можно его назвать как-нибудь случайно типа 12ghrt78.php и ограничить доступ к скрипту из сетей Bitbucket: 131.103.20.160/27, 165.254.145.0/26, 104.192.143.0/24. Хотя иногда приходится его вызывать из браузера. Указываем файл в настройках веб-хука на событие Repository push. Теперь при пуше разработчиком веб-сервер вытянет коммит из Bitbucket. В зависимости от настройки хостинга может не хватить прав доступа. В этом случае ничего не остается, как разрешить выполнять команду через sudo:
Набираем команду visudo и в /etc/sudoers записываем:
Теперь должно работать.
Вывод
В статье описана самая простая ситуация, которая встречается в 80% случаев. В идеале затем каждый пункт требует дополнительного внимания, после тестового прогона следует заняться оптимизацией и попробовать выжать из сервера максимум.
Источник
Инструкция по настройке VDS: базовая конфигурация и работа с LEMP
Управление виртуальным сервером осуществляется с помощью командной строки. Для этих целей удобнее всего использовать бесплатную программу PuTTy. Она не требует установки: скачав и запустив утилиту, вы можете тут же подключиться к VDS по протоколу SSH, введя IP-адрес (номер порта по умолчанию — 22) и нажав на кнопку “Open”. После этого на экране появится окно консоли с приглашением к авторизации “login as:”. Введите root, нажмите “Enter”, далее укажите полученный при заказе услуги пароль и вновь подтвердите действие клавишей ввода. Теперь можно начинать работу.
Сама процедура настройки VDS представляет собой ввод в консоль текстовых команд, с помощью которых можно осуществлять практически любые операции над сервером. Ниже рассмотрена последовательность базовых действий, которые необходимо осуществить сразу после запуска виртуальной машины, а также пошаговая установка связки программного обеспечения, необходимого для размещения веб-сайтов. Примеры адаптированы для двух наиболее распространенных семейств Линукс: Debian (к ней относится, например популярный Ubuntu) и Centos (в него входит сам Centos, Fedora и ряд других).
Первоначальная настройка VDS
Обновление программного обеспечения
Начинать настройку VDS необходимо с глобального обновления. Запустить апдейт в Debian-подобных операционных системах можно следующим образом:
для Centos команда иная:
В процессе обновления вас спросят о том, хотите ли вы установить новые пакеты. Отвечайте утвердительно, используя клавишу Y, и подтвердите свой выбор, нажав “Enter”.
Добавление нового пользователя
Работать с сервером под учетной записью root настоятельно не рекомендуется — лучше всего создать нового пользователя и передать ему необходимые права. В Debian-подобных системах это делается командой:
где username следует заменить на желаемое имя пользователя. После ее выполнения вас попросят задать пароль, а затем предложат заполнить дополнительные поля (делать это необязательно — их можно оставить пустыми).
При работе с Centos также используется команда:
Однако пароль задается отдельно:
Передача привилегий root
После создания нового пользователя ему необходимо передать права суперадминистратора, в противном случае вы не сможете полноценно настроить VDS. Делается это через добавление вновь созданной учетной записи в соответствующую группу. Для Debian-подобных:
Управление SSH
В целях безопасности необходимо проделать ряд манипуляций с конфигурационным файлом sshd_config, который, как легко догадаться, отвечает за настройку удаленного подключения к серверу по SSH. В разных дистрибутивах Линукс для редактирования используются различные утилиты, соответственно, и команды для них будут несколько различаться. В Debian-подобных применяется nano:
Для сохранения внесенных изменений необходимо нажать комбинацию клавиш Ctrl+X, затем Y и “Enter”. Centos имеет в своем составе редактор vi:
Сохранение информации осуществляется командой :x, после чего необходимо нажать “Enter”.
В sshd_config следует запретить вход с помощью учетной записи root, заменив
а также поменять порт SSH, используемый по умолчанию, заменив
Номер порта лучше выбирать из диапазона 49152-65535 — это позволит избежать возможных конфликтов с различными службами и сервисами Линукс. После описанных манипуляций необходимо перезапустить SSH. В Debian это делается так:
Теперь необходимо переподключиться к серверу через назначенный порт под новой учетной записью, после чего настройку VDS можно продолжать.
Установка и настройка LEMP
Большинство современных CMS написаны на языке программирования PHP. Это означает, что для размещения практически любого сайта, независимо от типа и функционала, нам понадобится LEMP. Данная аббревиатура обозначает связку современного и очень быстрого веб-сервера Nginx, интерпретатора php-fpm и системы управления базами данных MySQL. Процедура установки достаточно проста и не займет много времени.
Установка Nginx
Начнем с установки Nginx. В Debian-подобных дистрибутивах это делается одной строчкой:
после чего сервер будет автоматически запущен.
В Centos сперва необходимо добавить репозиторий EPEL:
и только после этого производить установку:
Финальный этап — запуск Nginx:
Установка MySQL
В Debian-подобных операционных системах сервис баз данных устанавливается командой:
В процессе вас попросят задать пароль администратора MySQL.
В Centos-подобных дистрибутивах вместо MySQL используется форк MariaDB, обладающий теми же функциональными возможностями. После его установки:
сервер баз данных необходимо запустить, а также добавить в список автозагрузки:
Настройка MySQL
Первичная настройка сервера баз данных осуществляется с помощью специального скрипта, идущего в комплекте с основным ПО:
После запуска вас попросят ввести пароль администратора MySQL, который мы задали на предыдущем этапе, а затем зададут ряд вопросов, отвечать на которые необходимо кнопками Y (да) и N (нет), подтверждая выбор клавишей “Enter”:
- Хотите ли вы сменить пароль? (Change the root password?) — Нет (N)
- Удалить анонимных пользователей? (Remove anonymous users?) — Да (Y)
- Запретить удаленную авторизацию с правами суперпользователя? (Disallow root login remotely?) — Да (Y)
- Удалить тестовую базу данных? (Remove test database and access to it?) — Да (Y)
- Перезагрузить таблицу привилегий? (Reload privilege tables now?) — Да (Y)
Добавление новой базы данных
Управление базами данных осуществляется через консоль MySQL. Чтобы в нее войти, необходимо ввести команду:
после чего авторизоваться, используя пароль администратора.
Для размещения динамического сайта необходимо создать базу данных, с которой будет работать движок. Обычно для каждого проекта создается отдельная БД и отдельный пользователь, который может ей управлять. Давайте создадим базу данных sitedb, пользователя site_user, а затем передадим последнему права на управление sitedb (вы можете заменить предложенные имена на любые другие).
Делается это следующим образом:
Создаем базу данных:
Создаем пользователя (вместо password укажите уникальный пароль)
Передаем права управления sitedb пользователю site_user:
Обновляем данные о привилегиях:
По завершении всех операций выйдите из консоли MySQL:
Установка PHP
Важный этап настройки VDS — установка и конфигурирование интерпретатора PHP. Команды для разных дистрибутивов Линукс отличаются. Инсталляция в Debian осуществляется так:
В Centos — немного иначе:
Конфигурация PHP
Первый шаг — редактирование файла php.ini. В Debian и Ubuntu он располагается здесь:
В Centos-подобных дистрибутивах — непосредственно в каталоге etc:
В обеих системах сперва необходимо раскомментировать и поменять значение в следующей строчке:
Таким образом, мы закрыли важную уязвимость, с помощью которой злоумышленники могли бы получить несанкционированный доступ к сайту. На этом настройка интерпретатора на Debian завершена, осталось перезапустить PHP-процессор:
В Centos же необходимо отредактировать и файл www.conf:
Здесь требуется найти строчку
Далее запускаем интерпретатор, а также вручную добавляем его в автозагрузку:
Создание директории
Теперь необходимо создать каталог, в котором будут располагаться файлы вашего ресурса. В любой операционной системе Линукс это делается следующей командой:
В данном примере sitename.ru необходимо заменить на доменное имя сайта. Что касается файлов CMS, их следует загрузить в папку public_html. По завершении загрузки необходимо передать права управления веб-серверу. Здесь есть различия в именах, используемых для обозначения Nginx. Для Debian-подобных дистрибутивов команда будет выглядеть так:
Добавление нового хоста Nginx
Последний этап настройки VDS для размещения сайта — добавление виртуального хоста Nginx. Нам достаточно отредактировать файл default. В семействе Debian это делается так:
Открыв файл, удалите из него всю информацию, заменив на код, представленный ниже (вместо sitename.ru подставьте актуальное имя сайта), и сохраните результат:
Осталось перезапустить Nginx. Команда для дистрибутивов Debian:
Теперь виртуальный сервер полностью готов к эксплуатации, и можно начинать работу непосредственно с веб-ресурсом. Дальнейшие шаги зависят от выбранной CMS.
Источник
Настройка виртуального сервера (VPS/VDS) с нуля
В этой статье мы поэтапно расскажем о том, как создать виртуальный сервер (VPS/VDS) в панели управления Serverspace и о том, как подключиться к созданному серверу.
Как создать виртуальный сервер?
1. Авторизуйтесь в панели управления Serverspace, перейдите в раздел «Серверы» и нажмите кнопку «Создать сервер».
2. Затем выберите шаблон виртуального сервера из списка — операционную систему (ОС), которая будет установлена.
Стоимость лицензии Windows Server при выборе соответствующей ОС уже включена в абонентскую плату, независимо от того, имеется у вас домен в виртуальной инфраструктуре или нет.
Если же вы планируете установить на VPS/VDS другую ОС, просто создайте ее ISO-образ и отправьте его нашей техподдержке.
3. Далее необходимо выбрать технические параметры виртуального сервера. Вы можете создать собственную конфигурацию, либо выбрать готовую:
Примеры готовых конфигураций:
Стандарт | Стандарт+ | Профи | |
---|---|---|---|
Количество ядер | 1 | 4 | 10 |
Оперативная память | 512 МБ | 11 ГБ | 26 ГБ |
Объем хранилища | 10 ГБ | 250 ГБ | 1000 ГБ |
Ширина интернет-канала (Мбит/сек) | 10 | 10 | 100 |
При этом в дальнейшем вы сможете менять конфигурацию прямо в панели управления.
После выбора ОС необходимо выбрать центр обработки данных (ЦОД), в котором будет размещаться ваш виртуальный сервер. Наши ЦОД-ы расположены в Беларуси (beCloud), США (NNJ3) и в Нидерландах (AM2), и для каждой страны доступна своя конфигурация.
4. За дополнительную плату вы можете подключить автоматическое создание резервных копий (бэкапов) виртуального сервера, которые создаются раз в сутки. Для этого необходимо выбрать период хранения бэкапов — 7, 14, 21 или 28 дней.
5. Если на этапе подбора операционной системы вы выбрали ОС Windows Server и ее необходимо включить в существующий домен Microsoft Active Directory, просто поставьте галочку в чекбоксе «выполнить системную подготовку Windows». При этом время создания сервера увеличится на 15-20 минут, так как в процессе создания будет запущена специальная утилита sysprep.
Если же в качестве операционной системы выбрана FreeBSD, Debian, Ubuntu или CentOS, необходимо дополнительно указать способ подключения — через пару логин/пароль или по SSH. Логин и пароль генерируются автоматически и появляются на экране после создания сервера. SSH-ключ можно сгенерировать при помощи утилиты или прикрепить уже сгенерированный ключ.
6. Затем необходимо указать количество серверов и присвоить им имена. За один раз можно создать до 5 серверов.
При создании сервера сетевому интерфейсу будет автоматически присвоен один бесплатный IPv4-адрес. В дальнейшем вы сможете подключить дополнительные IPv4- и IPv6-адреса за отдельную плату.
Подключение к виртуальному серверу
После создания виртуального сервера к нему можно подключиться через веб-консоль. Для подключения потребуется логин и пароль администратора, указанные во вкладке «Состояние».
Кнопка перехода в веб-консоль расположена в правом верхнем углу. Если вам неудобно пользоваться веб-консолью, вы можете подключаться к серверу любым другим удобным способом.
Подключение к операционным системам происходит по разным протоколам: для FreeBSD, Debian, Ubuntu и CentOS используется протокол SSH, а для подключения к серверам Windows — протокол RDP.
Источник