Как поднять сервер

Как поднять свой VPN сервер: пошаговая инструкция с картинками

Если не знаете , как поднять свой VPN-сервер, тогда покупайте эту услугу у сторонних ресурсов или дочитайте статью д о конца, чтобы узнать , как можно создать VPN-сервер.

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

Однако если вы планируете использовать VPN-сервер многократно или даже постоянно, то зачем платить кому-то деньги, если поднять свой собственный VPN-сервер можно достаточно быстро, при этом он будет дешевле и безопаснее ?

Как поднять свой VPN-сервер

• арендовать удаленный компьютер, куда нужно будет установить специализированное программное обеспечение;

• подсоединиться к серверу по SSH при помощи специального ПО, а также настроить на сервере другое ПО, необходимое для создания VPN;

• установить специальное приложение на свое устройство и начать пользоваться своим VPN-сервером.

Создание VPN-сервера: арендуем удаленный компьютер

Свой собственный VPN-сервер поднимается на удаленном компьютере. Для этого нужно арендовать VPS-сервер. Как правило , стоят они не очень дорого, можно найти отличные сервер ы от 3 евро в месяц. Главное — это подобрать страну, где будут размещены мощности компании, предлагающей в аренду VPS-сервер.

Но и тут можно немного схитрить и воспользоваться бесплатным вариантом от Amazon AWS. Однако нужно учесть , для чего вам нужен собственный VPN-сервер, потому что бесплатные варианты, как правило, обладают более низкой производительностью, чем платные. Если вам нужно просто «юзать» интернет, то хватит бесплатного ; если постоянно смотреть виде о , скачивать файлы и т. д., то, возможно, лучше подобрать что-то из платных вариантов с более высокой скоростью работы и с большим объемом трафика.

Арендовав VPS-сервер , нужно будет на нем создать экземпляр виртуальной машины, на которой чуть позже настроите собственный VPN-сервер.

Как поднять свой VPN-сервер: настройки и подключение

• в поле «A d dress» нужно ввести IP-адрес вашего арендованного выделенного сервера;

• в поле « U sername» указать операционную систему вашей виртуальной машины, в большинстве случаев это Ubuntu;

• в поле «Keys» нужно будет добавить файл с расширением «.pem» который можно скачать из вашей виртуальной машины.

Как создать VPN-сервер: конфигурация

• РРТР — один из первых VPN-протоколов, очень шустрый, однако безопасность у него «хромает», поэтому для каких-либо серьезных дел лучше его не применять;

• L2TP/IPSec — намного безопаснее , чем первый, однако обладает не самой высокой скоростью работы;

• SSTP — это собственный протокол компании Microsoft, поэтому установить его на Линукс не получится;

• IKEv2 — один из самых быстрых и безопасных, однако есть проблема с поддержкой на различных устройствах;

• SoftEther — один из самых «свежих» протоколов с весьма неплохими характеристиками, однако у есть проблемы с поддержкой на различных устройствах;

• Open VPN — шустрый и безопасный, но очень непростой при его эксплуатации;

• WireGuard — один из самых быстрых, надежных, производительных и простых протоколов, он требует установки дополнительного ПО.

• «sudo apt install wireguard -y» — используется для установки протокола;

• «wg genkey | tee server_privatekey | wg pubkey > server_publickey» — используется для генерации пары ключей для сервера: приватный и открытый.

• «server_privatekey server_publickey phone_privatekey phone_publickey bob_privatekey bob_publickey» — и так перечислить все количество устройств, здесь у нас 2 устройства: «phone» и «bob».

• «sudo nano /etc/wireguard/wg1.conf»

• заменить строку «<PRIV_SER>» данными всех приватных ключей всех ваших устройств ( для этого вы и создавали текстовый файл ) ;

• заменить строку «<PUB_CLIENT>» данными всех публичных ключей всех ваших устройств.

• «sudo wg-quick up wg0»

• «sudo systemctl enable wg-quick@wg0.service»

Как подключиться к своему VPN-серверу

• «sudo nano phone.conf»

Заключение

Теперь вы знаете , как поднять свой VPN-сервер. Обычно создание VPN-сервера актуально, если вы планируете много работать через VPN. Потому что , если вам нужно разовое применение возможностей VPN, тогда имеет смысл воспользоваться уже готовыми сервисами с такой услугой, тем более они есть и бесплатные.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Как создать Linux сервер своими руками и что для этого нужно

Чтобы создать терминальный, файловый (FTP) или почтовый сервер на Linux, надо уметь работать в этой операционной системе. Иначе разобраться будет сложно. ОС не нужен мощный компьютер. Потому что она не расходует лишние ресурсы на графическое оформление. Дистрибутивы Линукса можно развернуть даже на старом ПК. Поэтому для создания различных серверов часто используют Linux или Ubuntu Server.

Об этом написано много различной литературы. Некоторые книги о Линуксе насчитывают тысячу страниц. Работать придётся через терминал и все команды вводить вручную. Но всё же вы сможете сделать небольшой Linux-сервер своими руками, который будет включать файловое хранилище, Web-сервисы и почтовый протокол.

Установка и настройка Ubuntu Server

Ubuntu Server создана на базе операционной системы Linux. Для её работы не нужен современный процессор, хорошая видеокарта или большой объём оперативной памяти. С Линукс можно развернуть сервер даже на старом ноутбуке. И в нём будут все нужные компоненты: почта, FTP, Web.

Скачать образ диска с Linux можно с сайта Ubuntu.ru. Выбирайте любую версию с Server (не Desktop!). Загрузка будет проходить через Torrent-клиент. Этот образ надо записать на болванку или флешку (с помощью LiveUSB). Также можно воспользоваться виртуальным приводом.

У Ubuntu упрощённый интерфейс. В нём нет никаких графических излишеств. Эта ОС прекрасно подходит, чтобы сделать Linux-сервер своими руками. С ней ресурсы компьютера будут использоваться для нужд домена. Ведь ей для работы нужно совсем немного.

Её установка проходит так:

• Выберите язык и регион, в котором проживаете.
• Придумайте имя администратора. Оно используется для управления сервером.
• Также задайте имя пользователя в поле «Username for your account». Под этим аккаунтом вы будете общаться с техподдержкой Ubuntu.

Указываем имя пользователя в Ubuntu

• Введите пароль. Подтвердите его.

Вводим пароль учетной записи

• Укажите домен, если он есть. На нём будут находиться все сервисы: файловый (FTP), почтовый, хостинг для сайтов и так далее.
• Подождите, пока установится система.
• После этого она предложит дополнительные компоненты.

Вот список того, что необходимо для сервера Linux и его полноценной работы:

• Open SSh. Используется для удалённого администрирования. Пригодится, если вы решите управлять сервисом с другого компьютера. Тогда на ПК с Линуксом можно будет отключить монитор и видеоадаптер.
• LAMP. Комплекс утилит Linux, который включает Apache (Web-сервер). MySQL (базы данных) и PHP (язык программирования для CMS). Эти компоненты нужны для создания управляющего интерфейса.

Далее указано то, что устанавливать необязательно. Выбор дистрибутивов опционален и зависит от того, что вы хотите в итоге получить.

• Samba file server. Позволяет настроить обмен файлами между компьютерами. Если вам нужен FTP-сервер, выберите этот пункт.
• Virtual Machine host. Устанавливайте, если собираетесь пользоваться возможностями виртуализации.
• Print server. Сетевые принтеры.
• DNS server. Система доменных имён. С ней можно распознать IP-адрес по имени компьютера и наоборот.
• Mail server. Почтовый сервер.
• PostgreSQL database. Объектно-реляционные базы данных.

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

Изначально вам надо будет проверить наличие обновлений. Введите команду «Sudo apt-get update» или «Sudo apt-get upgrade» без кавычек. После апдейта можно заняться настройкой всех компонентов серверов: FTP, почтового, Веб.

Для Ubuntu существует псевдографический интерфейс — Midnight Commander. Это аналог оболочки Norton Commander, которая разработана для системы MS DOS. С таким интерфейсом легче работать — всё нагляднее, чем в консоли.

Запуск терминала Linux

В современных Linux вместо консоли используется терминал. Чтобы в него зайти:

1. Откройте «Приложения».
2. Нажмите «Стандартные».
3. Там будет «Терминал».

Терминал в Linux

В него можно вводить команды так же, как в Ubuntu Server.

• Чтобы установить компоненты LAMP (если их ещё нет), надо последовательно ввести команды «sudo apt-get update», «sudo apt-get install tasksel» и «sudo tasksel install lamp-server». После каждой нажимайте Enter.
• Чтобы загрузить Open SSh, введите «sudo apt-get install openssh-server».
• Чтобы поставить Samba file server, напишите «sudo apt-get install samba».

При установке MySQL из пакета LAMP нужно будет задать пароль администратора, для SQL.

Локальный Web-сервер

Для создания Web у сервера должен быть свой выделенный IP. Тогда после установки LAMP по этому IP-адресу будет доступна тестовая страница Apache. Это и есть будущий Веб. В дальнейшем на него можно будет поставить FTP, базы данных, почтовый протокол. Для настройки Web-сервера:

• Установите phpMyAdmin. Для этого в терминале или в консоли введите друг за другом введите «sudo apt-get install phpmyadmin»

Команда «sudo apt-get install phpmyadmin»

• И потом «sudo service apache2 restart».
• Компонент загрузится. Apache будет перезагружен. Дальнейшие действия зависят от версии операционной системы.

Если у вас Ubuntu 13.1 и выше, используйте команды:

1. sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf-available/phpmyadmin.conf
2. sudo a2enconf phpmyadmin
3. sudo /etc/init.d/apache2 reload

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

В Ubuntu 16.04, нужны другие указания:

1. sudo apt-get install php-mbstring php-gettext
2. sudo phpenmod mcrypt
3. sudo phpenmod mbstring
4. sudo systemctl restart apache2

После их ввода и автоматического перезапуска службы по адресу http://[iP сервера]/phpmyadmin будет доступен веб-интерфейс.

• Конфигурация и данные о ней находятся в папке сервера Apache «etc/apache2/». Apache2.conf — конфигурационный файл для дистрибутива
• В директориях «mods-available»/«sites-available» и «mods-enabled»/«sites-enabled» находятся моды и сайты.
• В Ports.conf расписаны прослушиваемые порты.
• Если вы добавите после команды «sudo /etc/init.d/apache2» слово «Stop», Apache приостановит работу. Если «Start» — снова запустится. Если «Restart» — перезагрузится.
• Чтобы самостоятельно выбирать путь для сохранения сайтов, последовательно введите в терминал «sudo a2enmod rewrite» и «sudo a2enmod userdir».

Каждый раз после внесения каких-либо изменений надо перезапускать службу командой «Restart».

Почтовый сервер

Чтобы создать почтовый сервер на Линукс, у вас уже должен быть зарегистрирован домен. Также нужно иметь статический IP.

• Установите компонент Postfix. Для этого наберите в консоли «sudo apt-get postfix».
• Когда он загрузится, напишите команду «sudo /etc/initd/postfix start». Сервис начнёт работать.
• В Postfix уже прописаны параметры, которые нужны для полноценной работы с протоколом SMTP. Но всё же не помешает небольшая настройка.
• Откройте файл /etc/postfix/main.cf.
• Найдите в нём значение «mydomain =». После знака «=» напишите имя домена.
• Потом отыщите «myhostname =». И введите имя машины.
• Теперь почтовый сервер может отправлять письма другим компьютерам, которые находятся с ним в одной сети. Чтобы он мог посылать корреспонденцию и на другие домены в интернете, в файле «main.cf» найдите строчку «inet_interfaces =». Поставьте после неё слово «all».
• В переменной «mynetworks =» пропишите диапазон адресов всех компьютеров вашей подсети (например, 127.0.0.0/8).

Не рекомендуется открывать доступ к серверу извне. Такие «публичные» ресурсы очень часто используются для рассылки спама. Из-за этого ваш домен может оказаться в чёрном списке у других почтовых сервисов.

Если служба настроена верно, и выполнены все условия (постоянный IP-адрес, зарегистрированный домен), то Server сможет принимать и отправлять корреспонденцию. Если запись MX вашего домена ссылается на ваш хост.

Чтобы посмотреть логи ресурса, используйте команду «tail -f /var/log/mail/info». Чтобы получить от него сообщение, введите «mailq».

Файловый сервер

FTP-сервер Linux может понадобиться для обмена документами и загрузки файлов. Существует несколько версий таких ресурсов: vsFTPd, Samba, proFTPd.

Подробнее остановимся на vsFTPd. Его можно установить и запустить одной командой — «sudo apt-get install vsftpd». Дальнейшие настройки зависят от ваших предпочтений и от того, какой сервис вы хотите сделать. Для изменения параметров могут понадобиться права администратора.

Команда «sudo apt-get install vsftpd»

1. Сразу после загрузки программы система создаёт нового пользователя и добавляет в домашнюю директорию папку, которая предназначена для работы с серверным хранилищем. Также в каталоге «etc» появляется файл «ftpusers». Туда можно добавлять пользователей, которым запрещён доступ к файлам.
2. После установки лучше сменить директорию, в которой должны находиться файлы, в папку «var». Для этого от имени администратора напишите команду «usermod -d /var/ftp ftp && rmdir /home/ftp».
3. Создайте новую группу пользователей. Например, «userftp». Напечатайте в консоли «addgroup userftp».
4. Добавьте в неё новый аккаунт (для простоты назовём пользователя и группу одинаково). Используйте команду «useradd -a /var/ftp -g userftp userftp». Она заодно создаёт пользователя. Чтобы включить в группу уже существующий никнейм, вместо «useradd» напишите «usermod».
5. Надо придумать пароль новому пользователю. Введите в терминале «passwd userftp».
6. Напечатайте «chmod 555 /var/ftp && chown root:userftp /var/ftp», чтобы предоставить аккаунту доступ к корневой папке файлового сервера.
7. Теперь создайте публичную директорию. Последовательно введите «mkdir /var/ftp/pub» и «chown userftp:userftp /var/ftp/pub».

Изначально FTP запускается в автономном режиме. У неё есть скрипт, который играет роль демона. При такой функциональности доступно несколько команд. Они вводятся после строки «sudo service vsftpd».

Команда «sudo service vsftpd»

• Stop и Start. Отключение и включение.
• Restart и Reload. Перезапуск. Нужен для применения новых настроек. Разница между командами в том, что во второй перезагрузка происходит без полного отключения.
• Status. Информация о состоянии.

Дальнейшая настройка сервера заключается в переписывании файла конфигурации, который находится в etc/vsftpd.conf. У него простая и понятная структура. Разобраться в нём достаточно просто. Хотя для этого нужны определённые знания. Перед изменением этого файла имеет смысл сделать его резервную копию. Чтобы в случае выявления ошибок можно было всё восстановить. Введите команду «cp /etc/vsftpd.conf /etc/vsftpd_old.conf» и информация будет сохранена.

После этого можно приступать к редактированию.

• В параметре «listen=» напишите «YES». Тогда сервер будет работать в независимом режиме.
• «Local_enable» разрешает вход локальным пользователям.
• «Write_enable» даёт им доступ в домашние каталоги.
• «Anonymous_enable». Можно ограничить права анонимных пользователей, если поставить «NO». Также есть опция «no_anon_password» — анонимные входят без пароля. Её тоже можно запретить.

Если вы хотите делать публичный сервер, то после строки «listen» надо добавить несколько дополнительных параметров.

• «Max_clients». Количество одновременных соединений.
• «Idle_session_timeout» и «data_connection_timeout». Таймауты сессии.
• «Ftpd_banner». Приветственное сообщение для посетителей. Можно написать, к примеру, «Hello!».

Терминальный сервер

Терминальный сервер на Linux предназначен для предприятий и офисов, все компьютеры в которых объединены в одну сеть. Очень удобно, когда с любого ПК (если у него есть доступ) организации можно зайти на терминал. Это открывает большие возможности для удалённого администрирования.

Для такой задачи подходит LTSP — Linux Terminal Server Project. Программа есть в стандартном пакете Ubuntu. Чтобы её установить:

1. Введите команду «ltsp-server-standalone».
2. Потом напишите «apt-get update && apt-get install ltsp-server-standalone».
3. Подождите, пока всё загрузится и обновится.
4. Теперь надо поставить клиентскую систему. Напечатайте «ltsp-build-client».
5. Затем «ltsp-build-client -dist trusty -arch i386 -fat-client-desktop lubuntu-desktop».
6. Используйте команду «debootstrap», и дистрибутив автоматически развернётся в директорию «opt/ltsp/i386».

Linux Server может работать даже на слабых ПК. Поэтому его очень часто используют для создания серверов и удалённого администрирования. На этой операционной системе делают почтовые сервисы, FTP-хранилища, терминалы.

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

В данной статье я хочу рассказать об организации собственного приватного хостинга для размещения своих сайтов. В качестве основы будет выделенный сервер под гипервизор с разделением функционала на виртуальные машины.

Цели статьи

1. Рассказать о схеме построения приватного хостинга на базе выделенного сервера или серверов.
2. Подробно описать роль каждой виртуальной машины в составе хостинга.
3. Поделиться своим реальным опытом на тему настройки и сопровождения веб серверов.
4. Наполнить статью ссылками на свои материалы по заданной теме, чтобы можно было на практике повторить все описанное ниже.

Введение

Данная статья будет чисто теоретической с тематическими ссылками на мои статьи, если таковые будут присутствовать в контексте повествования. Я решил поделиться своим видением и опытом в построении приватного хостинга для размещения одного или нескольких сайтов в рамках одной команды или владельца. То есть система в описанном виде не будет предназначена для публичного доступа к сервисам. Только личное использование закрытого круга лиц.

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

• Frontend в виде проксирующего nginx.
• Backend сервер в связке с nginx + php-fpm либо Bitrixenv для сайтов на bitrix.
• Zabbix сервер для мониторинга.
• Elk Stack для хранения и анализа логов web сервера.

Это минимальное количество структурных единиц, которые я использую. В зависимости от задач и проектов, их может быть больше. Например, можно отдельно вынести функционал сервера баз данных. Если у вас используются сильно разные сайты, можно сделать несколько backend серверов, чтобы не разводить зоопарк на одном. К примеру, bitrix сайты я всегда разворачиваю отдельно.

Часто необходим свой почтовый сервер. Его тоже рекомендую разворачивать отдельно, причем желательно на другом ip адресе, чтобы иметь возможность эффективно противостоять ddos атакам. Если используется взаимодействие с удаленной инфраструктурой, можно настроить шлюз в отдельной виртуальной машине и использовать ее в качестве vpn сервера или клиента. В простейшем случае роль шлюза выполняет сам гипервизор.

Так же, в случае необходимости, я отдельно разворачиваю виртуальные машины с Youtrack, Teamcity, Onlyoffice, Gitlab. Можно компактно разместить все необходимое для работы небольшой команды разработчиков.

Изначально все настраивается на одном гипервизоре, но структура проекта позволяет без проблем его масштабировать на несколько серверов, либо выполнить переезд в облако. Несмотря на то, что сейчас активно развиваются кластеры (Kubernetes) и облачное размещение, предложенная мной схема полностью актуальна и востребована. Основные причины актуальности:

1. В Kubernetes имеет смысл размещать только те проекты, которые изначально построены на основе микросервисов. WordPress и Bitrix в k8s размещать неудобно.
2. Размещение на собственных серверах дает прогнозируемую производительность и максимальное выгодное соотношение производительности к стоимости. То есть это банально дешевле облаков раза в 2-3.

Итак, разберем теперь отдельно каждую виртуальную машину. В качестве базовых систем я использую Centos 8, но это не принципиально. Используйте ту систему, что вам больше нравится. Это может быть и Debian, и Ubuntu.

Гипервизор для своего хостинга

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

Если сервер без рейд контроллера, то используется софтовый рейд 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 сайтов:

У Битрикса тоже есть похожие ошибки, но я их не зафиксировал в статьях.

Я каждый сайт размещаю в отдельной директории, например /mnt/web/sites/site.ru. В этой директории уже свои поддиректории www, logs, php_sessions и т.д. Владелец каждого сайта — отдельный системный пользователь. От этого пользователя работает php-fpm пул, который обслуживает только этот сайт. Для каждого пользователя настроен sftp доступ к конкретному сайту. Каждый сайт имеет доступ только к своей базе mysql или postgresql.

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

Мониторинг сайтов и серверов

Для мониторинга виртуальных машин и сервисов нашего хостинга я всегда использую Zabbix. У меня накопилось огромное количество статей по нему практически на все случаи, с которыми я сталкиваюсь. В общем случае я настраиваю:

или железного контроллера. По последним, к сожалению, у меня нет статей, но в целом проблем с настройкой не возникает. У меня всегда гуглились подходящие решения. Если у сервера есть idrac, ilo, ipmi, можно с них брать нужные данные.
1. Если есть доступ к смарту дисков, то настраиваю мониторинг smart. Очень рекомендую это делать, чтобы в случае выхода из строя какого-то диска, у вас была полная информация о нем, чтобы передать ее в службу технической поддержки для замены. . Мне сразу приходит уведомление, если кто-то подключается к серверу по ssh. Если доступ есть не только у меня, то обязательно это настраиваю. Сильно упрощает жизнь и готовит к проблемам 🙂 Если доступ только у меня, то это небольшая защита и возможность быстро среагировать на несанкционированный доступ, хотя в реальности у меня ни разу такого не было. , в данном случае frontend и backend. Иногда мониторинг бэка не делаю. Реально не так уж часто он нужен, хотя кажется, что полезно получать все метрики. Но лично моя практика такова, что они мне на деле чаще всего не нужны. . Это одна из самых главных метрик, так как напрямую отвечает на вопрос, все ли у нас в порядке. Если сайт не работает или не доступен, то это наивысший приоритет проблемы. Так как мониторинг у нас локальный, он не дает полную картину происходящего, нужен еще один внешний. О нем подробнее расскажу далее. Локальный мониторинг сразу определяет, к примеру, если у нас упал backend и вместо страницы сайта видим 500-ю ошибку nginx. Или что-то еще. В общем, важная штука, рекомендую внимательно отнестись к мониторингу сайта. Рекомендую к нему обращаться напрямую через внутреннюю сеть гипервизора по локальному ip фронта. Для этого надо либо в host файл виртуалки с zabbix добавить все сайты по локальному ip, либо завести свой локальный dns сервер. Обычно я это делаю, если используется отдельная виртуальная машина под шлюз. и ssl сертификата. Штука не обязательная, настраивается по желанию. Если делегирование не так критично, так как регистраторы завалят напоминаниями на почту, то мониторинг ssl сертификатов рекомендую сделать. Их часто забывают продлить или возникают технические ошибки при работе с автопродлением Let’s Encrypt.
2. Я всегда настраиваю мониторинг бэкапов в том или ином виде. Он сильно зависит от конкретной ситуации, от данных, от места хранения бэкапов и т.д. Готовых решений нет, приходится импровизировать на месте. Но если не настрою мониторинг бэкапов, не могу спать спокойно. Бэкапы периодически разворачиваю вручную и проверяю. Это сильно ограничивает количество клиентов, с которыми могу сотрудничать, так как труд ручной. Но это меня много раз спасало. Так что не пренебрегаю.
3. Если есть почтовый сервер, настраиваю мониторинг postfix. За почтовым сервером рекомендую внимательно следить, особенно за очередью и количеством отправленных сообщений. Иногда учетки ящиков утекают в сеть и сервер начинает массово спамить. Если вовремя это не заметить и не остановить, можно залететь в спам листы и надолго там засесть. Это может парализовать работу того же интернет магазина, так как без почты он перестает нормально функционировать.

Основное по мониторингу перечислил. Частенько настраиваю что-то еще, в зависимости от потребностей конкретного заказчика. Если решение не типовое и нишевое, то статью не пишу по нему, хотя шаблоны себе сохраняю. Если есть какие-то критичные службы linux, можно мониторить еще и их.

Особенно удобно мониторить отклик сайта с локального сервера. Здесь нет сетевых задержек, которые возникают при работе внешнего мониторинга. Тут чистая производительность web сервера. Вкупе с внешним мониторингом получается полная и легко интерпретируемая картинка производительности веб сервера и скорости доступа к сайту. Только с двумя мониторингами — внешним и внутренним, можно адекватно оценивать и искать узкие места в работе сайта.

Хранение логов в ELK Stack

Я складываю все логи в elasticsearch. У меня есть статья про установку и настройку ELK Stack. Недавно я обновил инструкцию по установке, но скрины оставил старые. Очень хлопотно их заменять. Сам процесс установки отражен правильно, так как я регулярно пользуюсь своей статьей. У меня есть несколько примеров того, как можно анализировать логи различных сервисов.

В контексте данной статьи по настройке приватного хостинга нас будет интересовать сбор web логов и их анализ:

Статьи немного устарели в том плане, что в процессе эксплуатации мои дашборды изменились, но принцип тот же. Главное его понять, а дальше уже не будет проблем делать так, как удобно лично вам. Например, я не настраиваю 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. Если обновление прошло без ошибок — это удача. Обычно что-то ломается.

Заключение

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

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

Онлайн курс по Kubernetes

Онлайн-курс по Kubernetes – для разработчиков, администраторов, технических лидеров, которые хотят изучить современную платформу для микросервисов Kubernetes. Самый полный русскоязычный курс по очень востребованным и хорошо оплачиваемым навыкам. Курс не для новичков – нужно пройти вступительный тест.