Создание и настройка сервера Minecraft

• Tutorial

Minecraft сегодня принадлежит к числу самых популярных сетевых игр. За неполных три года (первый официальный релиз состоялся осенью 2011 года) у него появились миллионы поклонников по всему миру. Разработчики игры сознательно ориентируются на лучшие образцы двадцатилетней давности, когда многие игры были по сегодняшним меркам примитивными с точки зрения графики и несовершенными с точки зрения юзабилити, но при этом — по-настоящему захватывали. Как и все игры-песочницы, Minecraft предоставляет пользователю огромные возможности для творчества — в этом, собственно, и заключается главный секрет его популярности. Организацией серверов для игры в многопользовательском режиме занимаются сами игроки и их сообщества. Сегодня в Интернете функционируют десятки тысяч игровых серверов (см., например, список здесь). Немало поклонников этой игры есть и среди наших клиентов, и они арендуют в наших дата-центрах оборудование под игровые проекты. В этой статье мы расскажем о том, на какие технические моменты нужно обратить внимание при выборе сервера для Minecraft.

Выбираем платформу

В состав игры Minecraft входят следующие архитектурные элементы:

1. сервер — программа, с помощью которой игроки взаимодействуют друг с другом по сети;
2. клиент — программа для подключения к серверу, устанавливаемая на компьютере игрока;
3. плагины — дополнения к серверу, добавляющие новые функции или расширяющие старые;
4. моды — дополнения к игровому миру (новые блоки, предметы, возможности).

Для Minecraft существует много серверных платформ. Самыми распространенными и популярными являются Vanilla и Bukkit. Vanilla это официальная платформа от разрабочиков игры. Распространяется как в графическом, так и в консольном варианте. Новая версия Vanilla всегда выходит одновременно с новой версией Minecraft. Недостатком Vanilla является чрезмерное потребление памяти (примерно 50 МБ на одного игрока). Еще один существенный недостаток — отсутствие плагинов.Bukkit был создан группой энтузиастов, предпринявших попытку усовершенствовать официальный сервер Minecraft. Попытка оказалась вполне удачной: по функциональности Bukkit намного шире, чем Vanilla — в первую очередь благодаря поддержке разнообразных модов и плагинов. При этом он потребляет меньше памяти на каждого игрока — примерно 5–10 МБ. Минусы Bukkit заключаются в том, что при запуске он забирает слишком много оперативной памяти. Кроме того, чем дольше сервер работает, тем больше ему требуется памяти (даже если игроков мало). Выбирая в качестве сервера Bukkit, следует учитывать, что его новые версии, как правило, содержат ошибки; стабильная версия обычно появляется примерно через 2-3 недели после выхода официальной версии Minecraft. Кроме того, в последнее время набирают популярность и другие платформы (например, Spout, MCPC и MCPC+), но они отличаются ограниченной совместимостью с Vanilla и Bukkit и крайне ограниченной поддержкой модов (например, для Spout вообще можно только писать моды c нуля). Если их и использовать — то только для экспериментов. Для организации игрового сервера мы рекомендуем использовать платформу Bukkit, так как она отличается наибольшей гибкостью; кроме того, под нее существует множество разнообразных модов и плагинов. Стабильная работа сервера Minecraft во многом зависит от грамотного выбора аппаратной платформы. Рассмотрим этот вопрос более подробно.

Аппаратные требования

И сервер, и клиент Mineсraft очень требовательны к системным ресурсам. При выборе аппаратной платформы следует учитывать, что многоядерный процессор больших преимуществ не даст: ядро сервера Minecraft может использовать лишь один поток вычисления. Второе ядро, впрочем, будет нелишним: некоторые плагины выполняются в отдельных потоках, да и Java тоже потребляет немало ресурсов… Поэтому для Minecraft-сервера лучше выбирать процессор, у которого выше производительность одного ядра. Более мощный двухядерный процессор будет более предпочтительным, чем многоядерный, но менее мощный. На специализированных форумах рекомендуется использоваться процессоры с тактовой частотой не ниже 3ГГц. Для нормального функционирования сервера Minecraft требуется большое количество оперативной памяти. Bukkit занимает примерно 1ГБ оперативной памяти; кроме того, под каждого игрока, как уже было сказано выше, отводится от 5 до 10 МБ. Плагины и моды тоже потребляют довольно много памяти. Для сервера на 30 — 50 игроков, таким образом, потребуется не менее 4 ГБ оперативной памяти. В Minecraft очень многое (например, загрузка тех же плагинов) зависит от скорости работы файловой системы. Поэтому предпочтительно выбирать сервер с SSD-диском. Шпиндельные диски вряд ли подойдут по причине низкой скорости случайного чтения. Огромное значение имеет и скорость интернет-подключения. Для игры 40-50 человек вполне хватит канала 10 Мб/c. Однако тем, кто планирует более масштабный minecraft-проект, включающий сайт, форум и динамическую карту, крайне желательно иметь канал с большей пропускной способностью. Какую конкретную конфигурацию лучше всего выбрать? Из предлагаемых нами конфигураций рекомендуем обратить внимание на следующие:

• Intel Core 2 Duo E8400 3ГГц, 6ГБ RAM, 2×500ГБ SATA, 3000 руб/мес.;
• Intel Core 2 Quad Q8300 2.5ГГц, 6ГБ RAM, 2×500ГБ SATA, 3500 руб/мес. — данную конфигурацию мы используем для нашего тестового сервера MineCraft, на которым вы прямо сейчас можете поиграть (как это сделать — написано ниже);
• Intel Core i3-2120 3.3ГГц, 8ГБ RAM, 2×500ГБ SATA, 3500 руб/мес.

Эти конфигурации вполне подойдут для создания серверa Minecraft на 30-40 игроков. Некоторым минусом является отсутствие SSD-дисков, но мы даем другое немаловажное преимущество: гарантированный канал 100 Мб/с без каких-либо ограничений и соотношений. При заказе всех перечисленных выше конфигураций установочный платеж не взимается. Есть у нас и более производительные, но при этом, естественно, более дорогие серверы (при заказе этих конфигураций установочный платеж также не взимается):

• 2х Intel Xeon 5130, 2ГГц, 8ГБ RAM, 4×160ГБ SATA, 5000 руб/мес;
• 2х IntelXeon 5504, 2ГГц, 12ГБ RAM, 3×1ТБ SATA, 9000 руб/мес.

Рекомендуем также обратить внимание на новую бюджетную модель с SSD-диском на базе процессора Intel Atom C2758: Intel Atom C2758 2.4ГГц, 16 ГБ RAM, 2×240ГБ SSD, 4000 руб/мес., установочный платеж — 3000 руб.

Установка и запуск сервера Bukkit в OC Ubuntu

Прежде чем устанавливать сервер, создадим нового пользователя и добавим его в группу sudo:

 $ sudo useradd -m -s /bin/bash <имя пользователя> $ sudo adduser <имя пользователя> sudo 

Далее зададим пароль, под которым созданный пользователь будет подключаться к серверу:

 $ sudo passwd <имя пользователя>

Переподключимся к серверу под новой учетной записью и приступим к установке. Minecraft написан на Java, поэтому на сервере обязательно нужно установить Java Runtime Environment. Обновим список доступных пакетов:

 $ sudo apt-get update 

Затем выполним следующую команду:

 $ sudo apt-get install default-jdk 

Для установки и запуска Bukkit желательно также установить терминальный мультиплексор — например, screen (можно использовать и другие терминальные мультиплексоры — см. наш обзор):

 $ sudo apt-get install screen 

Screen понадобится, если мы будем подключаться к игровому серверу по ssh. С его помощью можно будет запускать сервер Minecraft в отдельном окне терминала, и даже после закрытия клиента ssh сервер будет работать. Создадим директорию, в которой будут храниться файлы сервера:

 $ mkdir bukkit $ cd bukkit 

После этого зайдем на страницу загрузок официального сайта Bukkit. В правой верхней части страницы можно увидеть ссылку на последнюю рекомендованную к использованию cборку сервера (recommended build). Советуем скачивать именно ее:

 $ wget <ссылка на рекомендованную версию>

Теперь запустим screen:

 $ sudo screen 

и выполним следующую команду:

 $ java -Xmx1024M -jar craftbukkit.jar -o false 

Поясним, что означают используемые параметры:

• Xmx1024M — максимальное количество оперативной памяти на сервер;
• jar craftbukkit.jar — ключ до сервера;
• o false — разрешает доступ к серверу с пиратских клиентов.

Сервер будет запущен. Остановить сервер можно, набрав в консоли команду stop.

Настройка и конфигурирование сервера

Настройки сервера хранятся в конфигурационном файле server.properties. Он содержит следующие параметры:

• generator-settings — задает шаблон генерации суперплоского мира;
• allow-nether — определяет возможность перехода в Нижний мир. По умолчанию для этого параметра установлено значение true. Если установлено значение false, то все игроки из Нижнего мира будут перемещены в обычный;
• level-name — имя папки с файлами карты, которая будет использоваться во время игры. Папка размещается в той же директории, где находятся файлы сервера. Если такой директории нет, сервер автоматически создает новый мир и помещает его в директорию с таким же именем;
• enable-query — при установленном значении true активирует протокол GameSpy4 для прослушивания сервера;
• allow-flight — разрешает полеты по миру Minecraft. По умолчанию имеет значение false (полеты запрещены);
• server-port — указывает порт, который будет использоваться сервервом игры. Стандартный порт для Minecraft — 25565. Значение этого параметра изменять не рекомендуется;
• level-type — определяет тип мира (DEFAUT/FLAT/LARGEBIOMES);
• enable-rcon — открывает удаленный доступ к консоли сервера. По умолчанию он отключен (false);
• level-seed — входные данные для генератора уровней. Чтобы иметь возможность создавать случайные миры, это поле нужно оставить пустым;
• force-gamemode — уставливает для игроков, подключающихся к серверу, стандартный режим игры;
• server-ip — указывает IP-адрес, который будет использоваться игроками для подключения к серверу;
• max-build-height — указывает максимальную высоту постройки на сервере. Его значение должно представлять собой число, кратное 16 (64, 96, 256 и т.п.);
• spawn-npcs — разрешает (если установлено значение true) или запрещает (если установлено значение false) появление NPС в деревнях;
• white-list — включает и отключает использование белого списка игроков на сервере. Если установлено значение true, то администратор сможет формировать белый список, добавляя в него ники игроков вручную. Если же установлено значение false, то на сервер может заходить любой пользователь, знающий его IP-адрес и порт;
• spawn-animals — разрешает автоматическое появление дружелюбных мобов, если установлено значение true);
• snooper-enabled — разрешает серверу отправлять статистику и данные разработчикам;
• hardcore — включает на сервере режим Хардкор;
• texture-pac — файл текстур, который будет использоваться при подключении игрока к серверу. В качестве значения этого параметра указывается имя zip-архива с текстурами, который хранится в той же директории, что и сервер;
• online-mode — включает проверку премиум-аккаунтов пользователей, подключающихся к серверу. Если для этого параметра установлено значение true, но на сервер смогут заходить только владельцы премиум-аккаунтов. Если проверка аккаунтов отключена (установлено значение false), то на сервер могут заходить любые пользователи (в том числе, например, и игроки, подделавшие ник), что создает дополнительные риски безопасности. При отключенной проверке можно играть в Minecraft по локальной сети, без доступа к Интернету;
• pvp — разрешает или запрещает игрокам воевать друг с другом. Если этот параметр имеет значение true, то игроки могут уничтожать друг друга. Если установлено значение false, то игроки не могут наносить друг другу прямой урон;
• difficulty — задает уровень сложности игры. Может принимать значения от 0 (самый легкий) до 3 (самый сложный);
• gamemode — указывает, какой игровой режим будет установлен для заходящих на сервер игроков. Может принимать следующие значения: 0 — Survival, 1-Creative, 2-Adventure;
• player-idle-timeout — время бездействия (в минутах), по истечении которого игроки автоматически отключаются от сервера;
• max-players — максимальное допустимое количество игроков на сервере (от 0 до 999);
• spawn-monsters — разрешает (если установлено значение true) порождение враждебных мобов;
• generate-structures — включает (true)/отключает (false) генерацию структур (сокровищницы, крепости, деревни);
• view-distance — регулирует радиус обновляемых чанков для отсылки игроку; может принимать значения от 3 до 15.

Логи сервера minecraft записываются в файл server.log. Он хранится в той же папке, что и файлы сервера. Лог постоянно увеличивается в размере, забирая все больше и больше дискового пространства. Упорядочить работу механизма логирования можно с помошью так называемой ротации логов. Для ротации используется специальная утилита — logrotate. Она ограничивает число записей в логе определенным пределом. Можно настроить ротацию логов так, что все записи будут удаляться, как только файл лога достигнет определенного размера. Можно также установить срок, по истечении которого все старые записи будут признаны неактуальными и удалены. Основные настройки ротации находятся в файле /etc/logrotate.conf; кроме того, для каждого приложения можно создавать индивидуальные настройки. Файлы с индивидуальными настройками хранятся в директории /etc/logrotate.d. Создадим текстовый файл /etc/logrotate.d/craftbukkit и впишем в него следующие параметры:

 /home/craftbukkit/server.log {   rotate 2   weekly   compress   missingok   notifempty } 

Рассмотрим их значения более подробно:

• параметр rotate указывает число ротаций до удаления файла;
• weekly указывает, что ротация будет производиться еженедельно (можно установить и другие параметры: monthly — ежемесячно и daily — ежедневно);
• compress указывает, что архивные логи нужно сжимать (обратная опция — nocompress);
• missingok указывает, что при отсутствии файла лога нужно продолжать работу и не выводить сообщения об ошибке;
• notifempty указывает не сдвигать файл лога, если он пуст.

Более подробно о настройках ротации логов можно прочитать здесь.

Советы по оптимизации

Сразу же оговоримся, что в этом разделе будут приведены советы, касающиеся только оптимизации игрового сервера. Вопросы тонкой настройки и оптимизации сервера, на котором установлен Mineсraft, представляют собой отдельную тему, выходящую за рамки этой статьи; заинтересованные читатели без труда смогут найти нужную информацию в Интернете. Одной из самых распространенных проблем, возникающих при игре в Minecraft, являются так называемые лаги — ситуации, когда программа вовремя не реагирует на пользовательский ввод. Они могут быть обусловены проблемами как на стороне клиента, так и на стороне сервера. Ниже мы дадим рекомендации, которые помогут снизить вероятность возникновения проблем на серверной стороне.

Регулярно контролируйте расход памяти сервером и плагинами

Потребление памяти можно отслеживать при помощи специализированных административных плагинов — например, LagMeter.

Следите за обновлениями плагинов

Как правило, разработчики новых плагинов с каждой новой версией стремятся снизить нагрузку.

Старайтесь не пользоваться множеством плагинов со сходной функциональностью

Большие плагины (например, Essentials, AdminCMD, CommandBook) очень часто включают в себя функциональность многих мелких плагинов. Например, тот же Essential содержит функции плагинов iConomy, uHome, OpenInv, VanishNoPacket, Kit. Мелкие плагины, функциональность которых полностью покрывается функциональностью одного большого, в большинстве случаев можно удалить, чтобы не перегружать сервер.

Ограничивайте карту и прогружайте ее самостоятельно

Если не ограничивать карту, то нагрузка на сервер существенно увеличится. Ограничить карту можно при помощи плагина WorldBorder. Для этого нужно запустить этот плагин и выполнить команду /wb 200, а затем прорисовать карту при помощи команды /wb fill. Прорисовка, конечно, займет немало времени, но лучше это сделать один раз, закрыв сервер на технические работы. Если карту будет прорисовывать каждый игрок — сервер будет работать медленно.

Замените тяжеловесные плагины на более быстрые и менее ресурсоемкие

Далеко не все плагины для Minecraft можно назвать удачными: часто они содержат много лишних и ненужных функций, а иногда еще и потребляют много памяти. Неудачные плагины лучше заменять на альтернативные (их существует довольно много). Например, плагин LWC можно заменить на Wgfix+MachineGuard, а плагин DynMap — на Minecraft Overviewer.

Всегда очищайте дроп или установите плагин для автоматического удаления дропа

Дропом в играх называются предметы, выпадающие при смерти моба или разрушении некоторых блоков. Хранение и обработка дропов занимают очень много системных ресурсов. Чтобы сервер работал быстрее, дроп желательно удалять. Это лучше делать при помощи специальных плагинов — например, NoLagg или McClean.

Не используйте античиты

На игровых серверах часто устанавливаются так называемые античиты — программы, которые блокируют попытки воздействовать на игру нечестными способами. Существуют античиты и для Minecraft. Любой античит — это всегда дополнительная нагрузка на сервер. Предпочтительнее устанавливать защиты для лаунчера (которые, впрочем, абсолютной гарантии безопасности не дают и легко ломаются — но этой уже тема для отдельного разговора) и для клиента.

Вместо заключения

Любые инструкции и рекомендации оказываются гораздо более эффективными, если они подкреплены конкретными примерами. Основываясь на приведенных выше инструкциях по установке, мы создали свой сервер MineCrаft и поместили на карту кое-что интересное. Вот что у нас получилось:

• Сервер Bukkit — стабильная рекомендованная версия 1.6.4;
• Плагин Statistics — чтобы собирать статистику об игроках;
• Плагин WorldBorder — чтобы прорисовать и ограничить карту;
• Плагин WorldGuard (+WorldEdit как зависимость) — чтобы защитить некоторые области.

Приглашаем всех желающих поиграть на нем: чтобы подключиться, добавьте новый сервер и укажите адрес mncrft.slc.tl. Будем рады, если в комментариях вы поделитесь собственным опытом установки, настройки и оптимизации серверов MineCraft и расскажете, какие моды и плагины вам интересны и почему.Классная новость: С 1 августа установочный платеж на выделенные серверы фиксированной конфигурации снижен на 50%. Теперь разовый установочный платеж составляет всего 3000 руб. Читателей, которые не могут оставлять комментарии здесь, приглашаем к нам в блог.

Если сервер без рейд контроллера, то используется софтовый рейд mdadm. Установка и настройка proxmox на софтовом рейде у меня подробно описана. У Selectel удобно выполнены базовые шаблоны для установки. Если я заказываю сервер, то сразу выбираю в качестве системы Debian на raid1. Установщик автоматически накатывает систему на mdadm. Остается только установить гипервизор. Самому разбивать диски и собирать mdadm не придется.

В простейшем случае в качестве шлюза используется хостовая система гипервизора. Iptables и Nat настраиваются на ней. Если у вас будут использоваться несколько выделенных серверов и их придется объединять по vpn через интернет, то я настраиваю шлюз в виде отдельной виртуальной машины. Можно и на самом гипервизоре, но я не люблю смешивать функционал. К тому же, когда у вас шлюз в отдельной виртуальной машине, его проще забэкапить и развернуть в другом месте. То есть в целом переезд проекта будет проще и быстрее.

Если у вас только один внешний IP адрес, то на гипервизоре используются 2 сетевых интерфейса:

1. Реальная сетевая карта с настроенным внешним IP адресом.
2. Виртуальный бридж, обычно vmbr0 для сети виртуальных машин, а так же для их связи с самим гипервизором.

Если используются несколько IP адресов, которые нужно будет назначать разным виртуальным машинам, то сетевых интерфейса будет 3:

1. Реальная сетевая карта без настроек IP адреса.
2. Бридж vmbr1, в который будет включен сетевой интерфейс, в который приходит линк с внешними ip адресами. На этом бридже будет настроен реальный IP адрес самого гипервизора, если нет отдельного шлюза. Этот же бридж будет подключен к тем виртуальным машинам, где нужен внешний ip адрес.
3. Бридж vmbr0 для виртуальной сети виртуальных машин.

Подробно с примерами вопрос сетевых настроек гипервизора я рассматриваю в статье про настройку proxmox, ссылку на которую дал в начале.

С гипервизором разобрались, переходим к следующему элементу web хостинга — frontend серверу.

Frontend сервер nginx

В качестве frontend сервера выступает Nginx, работающий в режиме proxy_pass. В контексте данного раздела я рекомендую 2 статьи на тему настройки Nginx — настройка проксирования и базовая настройка nginx.

В данном случае не обязательно использовать именно Nginx. В некоторых ситуациях более актуальным будет взять HAProxy. Но в общем случае подойдет Nginx. На frontend сервер будут поступать все внешние http запросы. На него будут проброшены порты 80 и 443. Расскажу, для чего использовать отдельный frontend сервер. Ведь можно обойтись и без него.

1. Удобство эксплуатации и обновления. К примеру, я хочу попробовать какую-то новую настройку — изменение ядра, модуля nginx и т.д. Я делаю копию frontend, настраиваю на нем все, что нужно и переключаю на него трафик. Если все в порядке, то оставляю в работе, либо переношу настройки на основной сервер. Если возникают какие-то проблемы, я просто переключаю проброс порта на старый сервер и все сразу начинает работать как прежде. В общем случае, frontend сервер очень маленький (20-30 гб под систему и логи).
2. На frontend удобно работать с внешними запросами — контролировать, обрабатывать, блокировать, предотвращая доступ к бэкенду с данными. Например, можно настроить ipset и блокировать отдельные страны. Можно выстроить простейшую защиту от ddos. Можно настроить отдельный модуль ModSecurity для Nginx. Когда у вас frontend отдельно, вам проще настраивать и обновлять компоненты, не боясь нарушить работу сайтов.
3. Frontend сервер аккумулирует все логи с внешних запросов и передает в ELK. Далее я покажу, как их удобно в автоматическом режиме сразу все передавать на хранение, а потом удобно анализировать.
4. В общем случае с отдельным frontend сервером безопаснее. Все внешние запросы приходят к нему. Многие зловреды (как и легальные компоненты и плагины) не понимают, как работать на бэкенде, который стоит за frontend. Это как плюс так и минус в некоторых случаях, так как усложняется эксплуатация. Особенно хлопотно с битриксом, так как у него много сервисов и проверок, которые напрямую стучатся по внешнему ip домена и не понимают, что делать, когда попадают на фронтенд. Но это все решаемо.

На frontend настраиваются бесплатные сертификаты от Let’s Encrypt. Так как весь трафик от фронта до бэка крутится в рамках одного гипервизора, смысла передавать его в шифрованном виде нет. Так что на backend он идет по http.

С frontend я отправляю в ELK логи запросов только к php скриптам. Именно они представляют для меня полезную информацию, так как позволяют оценить скорость работы сайта. Информация от отдачи статики лично мне не нужна. В общем случае, я ее не собираю, а включаю отдельно по мере необходимости. Это позволяет не раздувать лог файлы. Чем меньше их объем, тем удобнее и быстрее с ними работать.

Backend сервер nginx, apache, php

Про бэкенд сервер рассказывать особо нечего. Он настраивается в зависимости от потребностей проекта. В общем случае для php сайтов это будет либо настройка nginx + php-fpm, либо apache + php. Как я уже говорил, бэкендов может быть несколько. Если вы web студия или какое-то агенство, которое само хостит сайты клиентов, то у вас может быть как классический web сервер php, так и bitrixenv для размещения битрикс сайтов. А они сейчас очень популярны. Почти все интернет магазины, с которыми я работал, были на битриксе. Плюс коробки с bitrix24 иногда покупают. Если сотрудничаете с малым или среднем бизнесом, без битрикса скорее всего не обойтись. Я его хоть и не люблю, но работать приходится.

В общем случае на backend я не настраиваю ssl, но бывают исключения или различные ошибки. Вот примеры таких ошибок в работе типовых php сайтов:

Статьи немного устарели в том плане, что в процессе эксплуатации мои дашборды изменились, но принцип тот же. Главное его понять, а дальше уже не будет проблем делать так, как удобно лично вам. Например, я не настраиваю GEO карты. В реальности они мне не нужны. Так, для красоты только. Ниже пример моего актуального дашборда для этого сайта.

По дашборду я сразу получаю актуальную информацию о состоянии сайта — информация о средней скорости ответа на php запросы и карта распределения ответов по шкале. Почти все запросы укладываются в интервалы до 300 мс, что считаю хорошим результатом. Напоминаю, что это информация только о php запросах. На сайте настроено кэширование, так что большинство страниц уходят к посетителю значительно быстрее напрямую через nginx, минуя обработчик php.

Тут же можно сделать выборку по медленным запросам, по запросам с определенных ip адресов, посмотреть запросы с различными кодами ошибок и т. д. В общем, без такого дашборда я ощущаю себя слепым. Я не понимаю, как понять, что с сайтом все в порядке, или наоборот узнать, какие у него проблемы, если у тебя нет под рукой подобной информации. Сайт может начать сыпать пятисотыми ошибками, а тебе надо как-то вручную грепать access log и пытаться понять, проблема единичная или масштабная. А тут все под рукой.

Я так привык в ELK, что на сервера почти не хожу. Все логи собираю в нем (обязательно системные) и там же просматриваю. Плюс к этому мониторинг и управление через ansible, но об этом позже. Ходить на сервера по ssh практически нет необходимости.

Такой подход очень хорошо масштабируется, поэтому я его и использую, хотя на моих масштабах это и не так актуально, но тем не менее, хочется все делать правильно с заделом на будущее. У меня был проект, который начался с одного сервера и нескольких докер контейнеров, а закончился примерно сотней виртуалок. Я очень пожалел, что с самого начала не начал автоматизировать процессы. Просто не был готов к этому. Не было опыта и понимания. Все росло постепенно и каждый раз вручную сделать было быстрее. Но в какой-то момент я стал просто зашиваться. Повезло, что проект в итоге усох, но не по моей вине 🙂

На фронте у меня логи всех сайтов складываются в одну директорию /var/log/nginx и оттуда единым шаблоном уходят в filebeat, а с него в logstash и далее в elasticsearch в один общий индекс, который бьется по дням. Раньше я каждый сайт отправлял в отдельный индекс, но со временем понял, что это не удобно. Так приходится для каждого индекса создавать свои визуализации и дашборды. Когда сайтов много это хлопотно, хотя и можно автоматизировать, но большого смысла нет на моих масштабах.

Сейчас я собираю все в один индекс, делаю единый dashboard и в нем уже с помощью фильтров просматриваю данные по разным сайтам. Я вывел в лог nginx информацию об имени виртуального домена. Это удобно и быстро настраивается. Для каждого нового сайта не надо вообще ничего делать. Filebeat автоматом забирает его логи. С помощью фильтра в Kibana просматривается информация в логах.

Почтовый сервер и шлюз

На настройке почтового сервера и шлюза для нужд хостинга подробно останавливаться не хочется. Статья и так очень большая получается. К тому же тут особых нюансов нет. Нужен обычный шлюз и обычный почтовый сервер. Можно взять готовую сборку, к примеру, iredmail или zimbra. Я иногда использую первый. Но чаще всего настраиваю все сам на базе postfix + dovecot + postfixadmin + roundcube. Так же рекомендую свою статью-рассуждение на тему, какой почтовый сервер выбрать.

В качестве шлюза так же можно взять либо готовую сборку, к примеру, на базе pfsense, clearos или чего-то подобного, либо настроить все самому. Я обычно настраиваю сам, так как не люблю зоопарк из систем. Мне нравится единообразие. Так удобнее управлять инфраструктурой, поэтому все собираю сам. Вот пример настройки шлюза на centos 7. Статья давно написана, на полностью актуальна. Ничего принципиально не поменялось.

При необходимости на шлюзе настраивается либо openvpn сервер, либо vpn клиент, если сервер уже есть. Если используется отдельный шлюз, я в него прокидываю реальный ip адрес, убираю его с самого гипервизора и делаю шлюзом по-умолчанию для гипервизора саму виртуалку со шлюзом. Главное не забыть ее поставить в автозагрузку, иначе после ребута гипервизора потеряете к нему доступ.

Если используются несколько дедиков в проекте, не объединенных в локальную сеть в рамках ЦОД, я их объединяю с помощью openvpn через интернет.

Backup сайтов

Для бэкапа я предпочитаю арендовать виртуальные машины в ruvds. К ним можно подключить большие диски — от 500 Гб и больше.

Подробно о том, как правильно делать бэкапы, я рассуждал отдельно. Конкретная реализация зависит от типа и частоты бэкапов, а так же глубины хранения. В общем случае достаточно будет обычных дампов баз данных и копии файлов сайта, скопированных с помощью rsync.

Если собираетесь делать бэкапы виртуальных машин, то настраивайте nfs сервер, подключайте его по vpn к гипервизору и настраивайте как отдельное хранилище для бэкапов. Штатным средством proxmox делайте регулярные бэкапы. В качестве nfs сервера отлично подходят виртуалки ruvds, так как там полноценная операционная система.

На этой же виртуалке ruvds я настраиваю простенький внешний мониторинг Zabbix для удаленным наблюдением за сайтами и физическими серверами по внешним ip адресам.

Так же я настраиваю дублирование бэкапов на s3 подобные хранилища с помощью rclone. Например, в selectel. Похожие хранилища есть у mail.ru и yandex.cloud. Облачные сервисы mail.ru я в настоящее время тестирую. Возможно будут статьи по этому поводу.

Я обычно делаю 3 контейнера в s3 с именами day, week, month и настраиваю правила хранения в них:

• day — 14 дней
• week — 31 день
• month — бессрочно

Следить за ротацией не надо, хранилище само удаляет старые архивы. У меня пока открыт вопрос по мониторингу бэкапов в s3 и их автоматическому разворачиванию для проверки. Пока не прорабатывал этот вопрос.

Управление хостингом

Самый главный вопрос при создании своего хостинга — как им управлять. Именно этот вопрос решают все готовые панели, но при этом добавляют массу новых проблем. В общем случае я не рекомендую использовать панели управления хостингом. Сам их терпеть не могу, так как намучался с ними. Там вечно какие-то проблемы, если тебе надо хоть немного кастомизировать настройки. А уж как они умирают при обновлении. Сколько я этих проблем повидал.

Сейчас просто не работаю с панелями вообще. Если кто-то предлагает взять на поддержку сервер с панелью управления хостингом (ispmanager, plex, vestacp), сразу отказываюсь. Я не могу гарантировать стабильную работу сайтов на них.

Раньше я писал bash скрипты для быстрого добавления сайта или настройки системы. Когда сайтов не много, создавал их руками. Сейчас я все стараюсь делать с помощью ansible. В паблик пока не готов выдать свои наработки. Их оформить отдельный труд. Нужно для начала хотя бы обзорную статью про ansible написать. Черновик уже год как написан, но не хватает времени оформить в полноценную статью.

Перечислю основные моменты, которые нужно автоматизировать:

• При добавлении виртуальной машины базовые настройки системы, подключение к мониторингу.
• При создании сайта — создание конфига nginx на фронте и бэке, запрос на сертификат, создание директорий и системного пользователя для сайта, создание php-fpm пула, настройка ротации логов, создание базы данных и пользователя, доступ пользователя по sftp.
• Поправить скрипт создания бэкапов. Создаю их bash скриптом. Есть мысли тоже через ansible делать, но пока не прорабатывал тему.
• Добавление мониторинга сайта в Zabbix. Пока не реализовал. Надо делать через api заббикса. Руки не дошли. С автоматизацией веб проверок в заббиксе пока все плохо.

Это основное. Может что-то забыл. Первое время все делал топорно единой yaml лапшой файла плейбука. Последнее время все переделываю с использованием шаблонов, ролей, задач, хендлеров, инвентаря и т.д. Стараюсь использовать ansible правильно.

В чем большое преимущество подобной автоматизации, помимо того, что можно быстро создать сущности на большом количестве объектов, когда у тебя этих объектов мало? В том, что настроив и проверив один раз какую-то процедуру, ее можно смело запускать без боязни где-то ошибиться. Она всегда отработает так, как ее настроили.

Например, при настройке firewall я всегда опасаюсь применять изменения в правилах. Вдруг где-то ошибся и что-то пойдет не так. Отрубится какой-то сервис или еще хуже — потеряю доступ к серверу. А когда у тебя есть шаблон и готовый плейбук по добавлению правил или заливки готового набора правил из шаблона, тебе достаточно проверить только переменные, чтобы в них не было ошибок. Далее прогнать на всякий случай плейбук в режиме check, а потом применить, если все в порядке.

В такой последовательности меньше шансов получить ошибку. Это облегчает управление даже тогда, когда автоматизация не дает существенной прибавки к производительности из-за малого масштаба информационной системы. Зачастую, настройка и отладка плейбуков занимает больше времени, чем ручная работа. Но это дает задел на будущий рост и опыт. Даже если роста не будет в этом проекте, наработки пригодятся в другом.

Плейбуки храню в git. Приучил себя вообще все хранить в git. Первое время было не привычно и казалось, что не удобно. Но в итоге привык и оценил удобство репозиториев.

Базовые рекомендации по настройке своего хостинга

Потихоньку заканчиваю статью по настройке своего хостинга. Все основное я уже описал. Перечислю отдельно некоторые важные моменты.

1. Закрывайте с помощью firewall все не публичные доступы — ssh, панель управления proxmox, phpmyadmin и т.д. Я долгое время не делал этого, так как боялся не получить доступ в экстренной ситуации, когда я не смогу зайти через доверенный ip адрес. На практике это не было никогда проблемой. Обычно разрешаю к подключению свой статический ip адрес и 2 vpn сервера тоже со статичными внешними адресами.
2. Настраивайте мониторинг всех критичных вещей — состояние рейда, актуальность бэкапов, подключения по ssh к  серверам и т.д. Не делайте много уведомлений — только реально важные вещи. Если будет спам от мониторинга, толку от него становится мало. Делайте повторяющиеся уведомления для некритичных событий, которые часто откладываешь и забываешь исправить.
3. Если занимаетесь работами по ускорению работы сайтов, можно в отдельной виртуальной машине настроить локальную версию сервиса webpagetest для объективной оценки скорости сайта без внешних сетевых задержек.
4. Когда обновляете систему на виртуальной машине, сделайте ее snapshot. После установки, если все в порядке, не забудьте его удалить. Это простое правило может очень сильно выручить в случае нештатной ситуации. Кстати, обновления я всегда делаю вручную, не через ansible или какие-то еще средства автоматизации. Если нет полного дублирования функционала с автоматическим переключением на работающий сервис, предпочитаю вручную контролировать установку обновлений. К сожалению, не такая уж и редкость, когда обновление что-то ломает. Пример — elk stack или bitrixenv. Если обновление прошло без ошибок — это удача. Обычно что-то ломается.

Заключение

На этом у меня все. Постарался собрать и описать самый что ни на есть реальный опыт по настройке веб серверов в составе своего приватного хостинга. Буду рад советам, комментариям и замечаниям по существу.

Если у вас есть желание получить себе подобный сервер или набор серверов, пишите примерное тех задание на почту. Адрес есть в разделе Контакты.

Практикум по Kali Linux

Курс для тех, кто интересуется проведением тестов на проникновение и хочет практически попробовать себя в ситуациях, близких к реальным. Курс рассчитан на тех, у кого еще нет опыта в информационной безопасности. Обучение длится 3 месяца по 4 часа в неделю. Что даст вам этот курс:

• Искать и эксплуатировать уязвимости или изъяны конфигурации в корпоративных сетях, web сайтах , серверах. Упор на пентест ОС Windows и на безопасность корпоративного сегмента.
• Изучение таких инструментов, как metasploit, sqlmap, wireshark, burp suite и многие другие.
• Освоение инструментария Kali Linux на практике — с ним должен быть знаком любой специалист по ИБ.

Проверьте себя на вступительном тесте и смотрите подробнее программу по .

Помогла статья? Есть возможность отблагодарить автора

Используемые источники:

• https://vetriks.ru/nastroika-servera.html
• https://habr.com/post/231935/
• https://serveradmin.ru/nastrojka-servera-dlya-hostinga/