Да, это нативная сборка под Linux, причем с фейковым Vulkan API и без железа - используется программный рендер на встроенной видеокарте.
История с исходниками достойна экранизации:
Code here is decompiled with IDA Pro and manually cleaned up, uninlined and rewritten to use templates. It is not a matching decompilation, and there is no workflow to merge the functions here with functions from the binary. The .exe contains class names as part of RTTI (see objtree.txt) but there has been no source leak. There has however been a debug info leak for Tomb Raider (2013). It's a different game, but uses a similar engine.
Можно грузить уровни, модели и персонажей, к сожалению сама игра пока не работает. Но редакция внимательно следит за развитием событий.
VPS куплен, SSH-сессия открыта. У многих здесь возникает пауза: непонятно, с чего начать и под какую задачу настраивать VPS-сервер. Разберём пять практических сценариев того, как использовать VPS: хостинг сайтов, запуск ботов, размещение API, мониторинг и автоматизация. У каждого – конкретный стек, ориентиры по ресурсам и нюансы, которые лучше знать до начала настройки, а не в процессе. Реальные требования зависят от сложности проекта, нагрузки, выбранного стека и числа одновременно работающих сервисов.
Что даёт VPS и почему его берут
VPS-сервер отличается от shared-хостинга тремя вещами. Первое – у вас есть заявленные параметры тарифа: CPU, RAM, диск и сетевой канал. На качество работы всё ещё может влиять общая инфраструктура хоста, но изоляция здесь выше, чем на shared-хостинге. Второе – root-доступ: можно установить любой софт, выбрать версию PHP, настроить nginx под конкретную задачу. Третье – VPS-сервер работает круглосуточно без вашего участия, независимо от состояния вашего компьютера или интернета. На shared-хостинге чужая нагрузка может повлиять на соседние сайты, если провайдер плохо ограничивает ресурсы аккаунтов.
От облачных функций (AWS Lambda, Yandex Cloud Functions) VPS отличается предсказуемостью: нет cold-start задержек, нет тарификации за каждый вызов функции, нет ограничений по времени выполнения. Для задач с постоянными процессами: баз данных, ботов, мониторинга – VPS часто проще и предсказуемее, чем serverless-архитектура с оплатой за вызов. При низкой или нерегулярной нагрузке serverless может оказаться дешевле.
Базовая подготовка: что сделать сразу после покупки
Настройка VPS начинается не сразу с рабочего проекта, а с базовой конфигурации. Базовая настройка снижает риск классических проблем: открытого SSH, устаревших пакетов, лишних портов и нехватки памяти при пиковых нагрузках. Пропуск таких шагов может увеличить риск потерять сервер из-за брутфорса или случайной команды от root.
• SSH-ключи. Сгенерируйте пару через ssh-keygen, передайте публичный ключ через ssh-copy-id, отключите аутентификацию по паролю в sshd_config.
• Пользователь без root. Создайте аккаунт с правами sudo. Работа от root в продакшене – плохая практика. Одна ошибка может стоить всей системы.
• Firewall. Откройте в UFW SSH-порт, 80 и 443, если они нужны вашему сценарию. Если используется стандартный SSH-порт, это 22. Fail2ban добавит защиту от брутфорса на SSH.
• Swap. Если RAM меньше 2 ГБ, добавьте swap-файл на 1–2 ГБ. Он снижает риск OOM при пиковой нагрузке, но при активном использовании может ухудшить производительность.
• Обновления. Запустите sudo apt update && apt upgrade сразу после входа на сервер, до начала любой работы.
Сценарий 1. Хостинг сайтов и веб-проектов
Хостинг на VPS оправдан, когда shared-хостинг перестал справляться: нет нужной версии PHP или Python, не хватает памяти, несколько доменов требуют разных настроек или нестандартного ПО. На VPS больше свободы в настройке: можно выбрать версии ПО, настроить веб-сервер, подключить нужные модули и управлять несколькими проектами независимо. Именно поэтому многие переезжают сюда с первого же конфликта с техподдержкой shared-хостинга.
Стек: Nginx как веб-сервер и reverse proxy, PHP-FPM для WordPress или других CMS, MySQL или PostgreSQL как база данных. Для статических сайтов (Hugo, Astro, Next.js SSG) Nginx работает без интерпретатора, нагрузка минимальная. SSL – Let’s Encrypt через Certbot, бесплатно и с автообновлением. Один Nginx обслуживает несколько доменов через server blocks.
Порты СУБД (3306, 5432) наружу не открывайте: приложение обращается к базе внутри сервера. Для сайта с умеренным трафиком часто хватает 1 vCPU и 1–2 ГБ RAM; для тяжёлых CMS с кешированием, большим числом плагинов или высокой посещаемостью лучше закладывать 2 vCPU и 2–4 ГБ. Добавьте Redis для кеша сессий: это может снизить нагрузку на базу данных и улучшить отклик WordPress при росте трафика.
Сценарий 2. Запуск Telegram- и Discord-ботов
Боту часто нужно работать круглосуточно и хранить состояние: настройки пользователей, историю диалогов, очереди задач. Локальная машина для этого не подходит, а облачные функции удобны в основном для коротких команд без постоянного процесса. VPS решает обе задачи: бот постоянно запущен, а база данных может работать рядом на том же сервере.
Стек для Telegram: Python + aiogram, управление процессом через systemd, хранение состояния в SQLite или PostgreSQL. SQLite подходит для небольших ботов с умеренной нагрузкой, но при высокой конкуренции запросов или запуске нескольких экземпляров приложения лучше сразу выбирать PostgreSQL. Для Discord – Node.js + discord.js, для управления процессом удобен PM2. Redis подойдёт для быстрого хранения временных данных и очередей.
Для большинства продакшен-сценариев с Telegram-ботами удобен webhook-режим: сервер сам получает обновления, не опрашивая API Telegram. Для webhook нужен домен с HTTPS. Polling тоже остаётся корректным вариантом для небольших проектов: он проще в запуске и не требует домена с HTTPS. Простой бот без базы данных умещается на 1 vCPU и 1 ГБ RAM. Бот со сложными очередями, вызовами внешних API и ML-моделями потребует минимум 2 ГБ RAM. Через systemd настраивается автозапуск: после перезагрузки сервера бот поднимется сам.
Сценарий 3. Размещение API и бэкендов
VPS-сервер даёт API постоянный адрес, свою базу данных и полный контроль над окружением, без vendor lock-in и без ограничений по времени выполнения запросов. Это важно для бэкендов с длительными операциями: обработкой файлов, парсингом, генерацией отчётов.
Стек: FastAPI (Python) или Express.js (Node.js) для REST, Docker для изоляции сервисов, Nginx или Traefik как reverse proxy. Приложение слушает на localhost, наружу открыты только 80 и 443. GraphQL – Strawberry (Python) или Apollo Server (Node.js). Для автодеплоя – GitHub Actions: пуш в main запускает пересборку и перезапуск контейнера.
Порты базы данных держите внутри Docker-сети, не открывайте наружу: бэкенд обращается к базе по имени сервиса внутри сети. Для API с базой данных начинайте с 2 vCPU и 2–4 ГБ RAM. При росте нагрузки Docker и reverse proxy позволяют масштабировать сервисы без переписывания архитектуры. Traefik автоматически получает и обновляет SSL-сертификаты через Let’s Encrypt при настроенном ACME, поэтому отдельная настройка Certbot не нужна.
Сценарий 4. Мониторинг и сбор метрик
Сервер мониторинга должен работать независимо от мониторируемой инфраструктуры. Если основной сервер упал, система мониторинга должна увидеть это первой и отправить алерт, а не упасть вместе с ним. Отдельный небольшой VPS для мониторинга решает эту задачу.
Uptime Kuma – удобный инструмент с веб-интерфейсом: отслеживает HTTP-статусы, время ответа, порты TCP, отправляет алерты в Telegram, Slack и другие каналы. Разворачивается через Docker за несколько минут и обычно помещается в небольшой VPS. Для лёгкого мониторинга часто достаточно 512 МБ RAM, но потребление зависит от числа проверок и их типа.
Prometheus + Grafana – полный стек для сбора метрик, построения дашбордов и настройки алертов. Prometheus собирает данные с exporters, Grafana строит графики. Оба сервиса вместе могут потреблять примерно 600–1000 МБ RAM в покое, но фактическое потребление зависит от retention, числа targets и объёма метрик. Под этот сценарий обычно стоит закладывать не меньше 2 ГБ RAM. Node Exporter собирает системные метрики хоста – CPU, RAM, диск, сеть; добавьте его на каждый наблюдаемый сервер. Алерты в Telegram настраиваются через Alertmanager за несколько минут.
Сценарий 5. Автоматизация и рабочие процессы
Сервер не выключается. Это главное преимущество VPS для автоматизации: cron-задачи запускаются по расписанию в любое время суток, скрипты работают столько, сколько нужно, без ограничений по времени выполнения и без зависимости от того, включён ли ваш компьютер.
n8n – self-hosted инструмент для визуальной автоматизации, аналог Zapier на вашем сервере. Разворачивается через Docker, а потребление памяти может начинаться примерно от 500 МБ RAM и расти с числом workflow, интеграций и выбранной БД. Данные о задачах хранятся в БД, поэтому volume для персистентности обязателен. Настроенный VPS с n8n заменяет подписку на облачные сервисы автоматизации и не передаёт данные третьим сторонам.
Для простых задач достаточно cron: бэкап файлов, отправка отчётов, очистка временных директорий, синхронизация данных между сервисами.
Как выбрать свой сценарий и не перегрузить сервер
Примерные ориентиры по ресурсам под основные задачи:
• Сайт или бот без тяжёлых фоновых задач: 1 vCPU, 1–2 ГБ RAM
Несколько сценариев на одном VPS совместить возможно, но требования зависят от сложности проекта, выбранного стека, объёма трафика и числа одновременно работающих сервисов. Для простого сайта, небольшого бота и лёгкого мониторинга 2 ГБ RAM могут быть достаточны, если нет тяжёлых фоновых задач. Docker упрощает совмещение: каждый сервис в своём контейнере, порты не конфликтуют, ресурсы лимитируются. Постоянная загрузка CPU или RAM выше 80% может стать сигналом для апгрейда. Начните с минимального тарифа и расширяйте по мере роста – большинство провайдеров позволяют сделать это без пересоздания сервера.
Чек-лист: что настроить на VPS под любой сценарий
1. SSH-ключи настроены, аутентификация по паролю отключена
2. Создан sudo-пользователь, работа от root прекращена
3. Система обновлена: sudo apt update && apt upgrade
4. UFW включён: открыты только нужные входящие порты, например SSH-порт, 80 и 443 для веб-сценариев
5. Swap настроен при RAM < 2 ГБ
6. Автоматические снапшоты или бэкапы настроены
7. Домен привязан, HTTPS работает через Let’s Encrypt
8. Базовый мониторинг: uptime и диск под контролем
VPS это не готовый продукт, а платформа для разных задач: сайта, бота, API, мониторинга или автоматизации. Начните с одного сценария, не пытайтесь запускать всё сразу. Сначала закройте базовую настройку из чек-листа: SSH-ключи, firewall, обновления, бэкапы и мониторинг. После этого разверните минимальную рабочую версию сервиса и расширяйте конфигурацию по мере роста нагрузки.
Облачный инстанс создан, SSH-доступ работает, и первое, что хочется сделать, это запустить приложение. Но новый сервер в этот момент уязвим: root-доступ может быть разрешён, часть пакетов требовать обновления, firewall ещё не настроен, мониторинга нет. Автоматические сканеры находят новые IP-адреса за минуты и начинают перебор паролей ещё до того, как вы откроете второй терминал.
Настройка облачных серверов перед нагрузкой – это четыре конкретных блока: сеть, пользователи и доступ, firewall, мониторинг. Каждый занимает от десяти минут до получаса. Пропустить любой – значит получить дыру в безопасности и эксплуатации.
Разберём все четыре блока по порядку на примере Ubuntu 22.04 LTS. Все команды воспроизводимы и проверены. Порядок шагов важен: каждый следующий опирается на предыдущий. Не запускайте приложение до настройки firewall: незащищённый VPS с открытым SSH быстро попадает под автоматический перебор паролей.
С чего начинается настройка облачного сервера?
Терминал Ubuntu 22.04 с обновлением пакетов, проверкой синхронизации времени, запущенных служб и свободного места на диске.
Прежде чем двигаться дальше, нужно привести систему в актуальное состояние. Образы облачных провайдеров зачастую собираются заранее и поставляются с пакетами недельной или месячной давности. Первое же обновление нередко закрывает десятки CVE, включая критические в OpenSSH и ядре. Выполните:
apt update && apt upgrade -y
Если обновление затронуло ядро – перезагрузите сервер. После перезагрузки убедитесь, что соединение восстановилось, и продолжайте.
Следующий шаг – проверить синхронизацию времени. Расхождение системных часов ломает TLS-рукопожатие, сбивает JWT-токены и делает логи бесполезными при сравнении событий с разных хостов. На Ubuntu 22.04 за это отвечает systemd-timesyncd. Проверьте его статус:
timedatectl status
В строке NTP service должно стоять active. Если нет – включите вручную:
systemctl enable --now systemd-timesyncd
Также сразу посмотрите, что уже запущено на сервере, и сколько свободно дискового пространства. На минимальном образе Ubuntu 22.04 запущено около 25–30 системных сервисов. Если их заметно больше, образ уже преднастроен провайдером:
Если корневой раздел занят более чем на 80%, разберитесь с этим до любых дальнейших шагов: нехватка места ломает обновления пакетов, ротацию логов и запись временных файлов.
Настройка сети на облачном сервере
Терминал Ubuntu 22.04 с проверкой сети, настройкой статического IP через Netplan и изменением имени облачного сервера.
Начните с просмотра текущего состояния сетевых интерфейсов. Две команды дают полную картину: какие интерфейсы подняты, какие IP назначены и куда идёт маршрут по умолчанию.
ip a
ip route show
В выводе ip a найдите интерфейс с публичным IP-адресом – обычно это ens3, ens4 или eth0, в зависимости от провайдера. Запомните его имя: оно понадобится в конфигурации netplan.
На Ubuntu 22.04 сетевые настройки управляются через netplan: конфигурационные файлы лежат в /etc/netplan/. Если провайдер использует cloud-init для автоматической конфигурации сети, в /etc/netplan/ уже может быть файл 50-cloud-init.yaml. Его можно редактировать, но изменения могут быть перезаписаны cloud-init при следующей перезагрузке или пересоздании конфигурации. Безопаснее создать отдельный файл с более высоким приоритетом, например 99-custom.yaml: числа в именах файлов определяют порядок применения, большее число применяется последним и переопределяет предыдущее.
Пример конфигурации со статическим IP (замените значения на реальные):
Терминал Ubuntu 22.04 с применением Netplan и проверкой IP-адреса, маршрута, DNS и внешнего соединения.
Директива addresses задаёт статический IP с маской. routes описывает маршрут по умолчанию – шлюз, через который идёт весь трафик. nameservers – DNS-серверы; при необходимости укажите серверы провайдера или вашего корпоративного резолвера.
Перед применением проверьте конфигурацию через netplan try: он применит настройки и автоматически откатит их через 120 секунд, если вы не подтвердите. Это страховка от потери соединения. Если всё в порядке – зафиксируйте:
netplan apply
Последний штрих – задать осмысленное имя хоста. Понятное имя упрощает навигацию в логах и мониторинге, особенно когда серверов несколько:
hostnamectl set-hostname web-prod-01
echo "127.0.1.1 web-prod-01" >> /etc/hosts
Диагностика сетевых проблем
Терминал Ubuntu 22.04 с успешной проверкой подключения, DNS-серверов и открытого SSH-порта.
Если после применения netplan что-то пошло не так, три команды помогут локализовать проблему:
Если ping проходит, а dig не разрешает имена – проблема в DNS. На Ubuntu 22.04 DNS управляется через systemd-resolved. Его состояние:
resolvectl status
Если dig не установлен, установите пакет:
apt install bind9-dnsutils -y
В выводе resolvectl смотрите секцию DNS Servers для каждого интерфейса. Если серверы не отображаются или стоит 127.0.0.53, убедитесь, что в файле netplan прописан раздел nameservers, и заново примените конфигурацию.
Команда ss -tulpn полезна не только при диагностике сети: её стоит запускать после каждого шага настройки, чтобы убедиться – ничего лишнего не появилось на открытых портах.
Управление пользователями и доступом (users)
Постоянно работать от root – плохая практика. Опечатка в пути к файлу под root может уничтожить данные без возможности отмены. Любая уязвимость в запущенном от root приложении даёт атакующему полный контроль над системой. При командной работе аудит затруднён: в логах нет разграничения между разными администраторами.
Создайте пользователя для повседневной работы. В Ubuntu удобнее использовать adduser: команда создаёт домашнюю директорию, настраивает оболочку и интерактивно запрашивает пароль.
adduser <name>
usermod -aG sudo <name>
Команда usermod -aG sudo <name> добавляет пользователя в группу sudo. На Ubuntu эта группа по умолчанию имеет право выполнять любые команды через sudo без изменения файла /etc/sudoers. Проверьте, что всё работает не закрывая текущую сессию root:
su - <name>
sudo whoami # должно вывести: root
Для входа по SSH без пароля сгенерируйте ключ на локальной машине и скопируйте публичную часть на сервер. Тип ed25519 предпочтительнее rsa:
# На локальной машине
ssh-keygen -t ed25519 -C "user@pc_name"
ssh-copy-id <name>@<IP_сервера>
Два терминала: создание пользователя deploy и проверка sudo на Ubuntu-сервере, генерация и копирование SSH-ключа с локального компьютера.
Два терминала: создание пользователя deploy и проверка sudo на Ubuntu-сервере, генерация и копирование SSH-ключа с локального компьютера.
Если нужно добавить публичный ключ вручную – создайте структуру директорий самостоятельно. Разрешения важны: 700 на директорию, 600 на файл:
После настройки ключа войдите в новый сеанс под пользователем через SSH. Убедитесь, что аутентификация по ключу работает, и только после этого переходите к следующему шагу.
Безопасные настройки SSH
Настройка SSH на сервере сводится к нескольким директивам в /etc/ssh/sshd_config. Ключевой принцип: ограничить поверхность атаки. Откройте файл:
nano /etc/ssh/sshd_config
Перед отключением парольного входа не закрывайте текущую root-сессию и убедитесь, что вход по SSH-ключу работает в новом терминале. Если в конфиге или ключах есть ошибка, SSH-доступ можно потерять, и восстанавливать его придётся через консоль провайдера, VNC/KVM или rescue mode.
Внесите следующие изменения:
# Запретить прямой вход под root
PermitRootLogin no
# Только ключи; пароли не принимать
PasswordAuthentication no
PubkeyAuthentication yes
# Разрешить вход только указанному пользователю
AllowUsers deploy
# Сократить время и попытки аутентификации
MaxAuthTries 3
LoginGraceTime 30
PermitRootLogin no закрывает наиболее атакуемый вектор: большинство автоматических сканеров перебирают именно root. PasswordAuthentication no убирает парольный вход полностью после этого единственным способом войти остаются SSH-ключи. AllowUsers deploy добавляет дополнительный слой: даже если на сервере появятся другие пользователи, по SSH они войти не смогут.
Директива AllowUsers особенно полезна при командной работе: она задаёт явный белый список тех, кто может войти по SSH. Новый пользователь, не включённый в список, не получит доступ даже с корректным ключом.
Перед перезапуском проверьте синтаксис конфига, ошибка в директиве заблокирует вас при работающем соединении:
sshd -t # пустой вывод означает: конфиг корректен
systemctl restart ssh
Откройте новый терминал и убедитесь, что вход по ключу работает, прежде чем закрывать текущую сессию. Это самая частая ошибка при настройке SSH: отключают парольный вход до того, как проверяют, что ключ принимается.
Дополнительно: смена стандартного порта 22 на нестандартный снижает количество автоматических сканирований и шум в логах. Если решите сменить, сначала откройте новый порт в UFW, затем измените Port в конфиге и перезапустите sshd, не наоборот.
Настройка firewall: UFW и iptables
UFW – стандартный инструмент управления firewall на Ubuntu. Он даёт простой интерфейс для настройки правил, а конкретный backend зависит от версии Ubuntu и конфигурации системы: это может быть iptables-совместимый слой или nftables. На новом сервере UFW установлен, но часто не активирован.
Настройка облачных серверов без активного firewall оставляет все порты открытыми. Порядок имеет значение: сначала разрешить SSH, потом включать UFW, иначе заблокируете собственное соединение:
ufw default deny incoming # всё входящее – запрещено по умолчанию
Если SSH настроен на нестандартный порт, замените 22 на него. Правило ufw status verbose покажет активные разрешения и политику по умолчанию – полезно сверить сразу после включения.
Для отладки сначала используйте вывод UFW:
ufw status verbose
Если нужно посмотреть низкоуровневые правила, используйте инструмент, который соответствует backend системы:
iptables -L -n --line-numbers
или:
nft list ruleset
На Ubuntu 22.04 UFW может работать через iptables-совместимый backend или nftables. Поэтому не стоит ориентироваться только на одну цепочку INPUT: фактическое расположение правил зависит от backend и конфигурации системы.
Для автоматической блокировки IP-адресов после нескольких неудачных попыток входа установите fail2ban:
apt install fail2ban -y
systemctl enable --now fail2ban
Создайте файл пользовательских настроек /etc/fail2ban/jail.local. Редактировать jail.conf напрямую не стоит – он перезаписывается при обновлении пакета:
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
[sshd]
enabled = true
При таких настройках IP блокируется на час после пяти неудачных попыток входа за десять минут. Перезапустите сервис и проверьте статус jail:
systemctl restart fail2ban
fail2ban-client status sshd
В выводе Currently banned покажет количество активных блокировок. Разбанить конкретный IP можно командой fail2ban-client set sshd unbanip <IP>. Кроме SSH, fail2ban поддерживает джейлы для nginx, apache2 и postfix. Они конфигурируются аналогично, добавлением отдельных секций в jail.local.
Мониторинг облачного сервера
Мониторинг сервера Linux без агентов начинается со встроенных инструментов. Для быстрой диагностики их вполне хватает:
Для постоянного мониторинга с метриками и алертами нужен агент. Выбор зависит от контекста: если в инфраструктуре уже есть Prometheus, оптимален node_exporter – он экспортирует более 800 метрик ОС с минимальным потреблением ресурсов (около 20–50 MB RAM):
apt install prometheus-node-exporter -y
systemctl enable --now prometheus-node-exporter
Агент слушает на порту 9100 и отдаёт метрики в формате Prometheus по адресу http://<IP>:9100/metrics. Добавьте этот адрес как scrape target в конфигурацию Prometheus, и метрики появятся в Grafana. Не открывайте порт 9100 наружу: ограничьте доступ через security group, UFW или приватную сеть Prometheus.
Если Prometheus ещё нет – Netdata даёт готовый интерактивный дашборд из коробки, без дополнительной инфраструктуры:
apt install netdata -y
systemctl enable --now netdata
Netdata слушает на порту 19999. Настройте SSH-туннель для разового просмотра или nginx с basic auth для постоянного доступа. Netdata потребляет от 100 MB RAM, на VPS с 1 GB это существенная разница по сравнению с node_exporter.
Алерты настраиваются поверх метрик. Для node_exporter используйте Prometheus Alertmanager: правила на PromQL, уведомления в Slack, email или PagerDuty. Для Netdata встроена собственная система уведомлений – настройте её в /etc/netdata/health_alarm_notify.conf. На практике для старта хватает трёх порогов: CPU load выше числа vCPU, диск выше 85%, список упавших сервисов непуст.
Что мониторить в первую очередь
На только что настроенном сервере важны шесть базовых показателей:
CPU load average – если значение устойчиво превышает количество vCPU в течение 5–10 минут, сервер перегружен. htop или uptime показывают три скользящих средних: за 1, 5 и 15 минут.
Память – при использовании свыше 85% система начинает активно использовать swap, что резко увеличивает latency. Для веб-серверов и баз данных это ощутимо. Контролируется через free -h.
Диск – заполненность свыше 80% блокирует запись логов, временных файлов и данных приложений. Дополнительно следите за iostat (из пакета sysstat) – высокий await при умеренной нагрузке указывает на проблемы с хранилищем.
Failed services – systemctl --failed выводит список упавших юнитов. Перед выводом в продакшен этот список должен быть пустым.
Auth log – journalctl -u ssh --since "1 hour ago" покажет активность после настройки fail2ban. Строки Failed password могут продолжать появляться до бана или с других IP-адресов. Важнее проверить, что fail2ban видит попытки входа и добавляет нарушителей в jail; строки Accepted publickey должны соответствовать вашим успешным входам.
Открытые порты – ss -tulpn один раз после каждого изменения конфигурации. Всё, что слушает наружу, должно быть в явном белом списке UFW.
Чек-лист финальной проверки
Пройдитесь по списку перед открытием сервера под рабочий трафик:
• Непривилегированный пользователь создан, добавлен в sudo
• Перед отключением парольного входа проверен вход по SSH-ключу в новом терминале
• PasswordAuthentication no и PermitRootLogin no прописаны в sshd_config
• UFW включён: ufw status verbose показывает только нужные порты
• fail2ban запущен: fail2ban-client status sshd показывает активный jail
• Пакеты обновлены: apt upgrade -y выполнен, при обновлении ядра – перезагрузка
• NTP активен: timedatectl показывает NTP service: active
• Мониторинг-агент запущен и метрики доступны
• Бэкапы настроены через панель провайдера или отдельный инструмент
• systemctl --failed возвращает пустой список
• Имя хоста и /etc/hosts настроены корректно
Четыре блока: сеть, пользователи, firewall, мониторинг – это минимальная конфигурация, без которой облачный сервер не готов к продакшену. Пропуск любого из этих шагов рано или поздно даёт о себе знать: либо взломом, либо аварией без видимой причины, либо часами поиска проблемы в логах.
Сохраните этот гайд и пройдитесь по нему при следующем деплое нового инстанса. В блоге Aeza регулярно выходят материалы по администрированию и безопасности серверов – подпишитесь, чтобы не пропускать NETTOWN5 обновления.
Дано: ASUS X50N, ноут которому уже почти 19 лет и нужно поставить на него систему, которая будет хорошо работать на нем в условиях современного веба. Выбор пал на Debian Linux с графической оболочкой LXQt. Данная среда рабочего стола является наиболее легковесной, по сравнению с другими наиболее распространенными. В итоге все прошло гладко, все основные устройства были определены в процессе установки Debian.
Изначально на нем стояла Windows XP. Стоял 160 Гб HDD, по тем временам (а это на секундочку 2007 год) это был достаточно большой объем. Вообще этот ноут использовался больше для мультимедиа задач - отредактировать фото, посмотреть фильм, записать на DVD слайд-шоу. Стоит отметить, что тут только SATA 2 на материнке, поэтому мы будем ограничены в плане пропускной способности накопителя.
О скоростях разных версий SATA:
SATA I: до 150 МБ/с
SATA II: до 300 МБ/с
SATA III: до 600 МБ/с
Как видим, достаточно мало по современным меркам. Если говорить о сети. Встроенная проводная сетевая карта поддерживает максимум 100 Мбит/сек. Беспроводное подключение - 54 Мбит/с.
В общем то, ноутбук в процессе эксплуатации за все годы ни разу не апгрейдили, за исключением установки SSD S55 от Silicon Power.
Тем не менее для базового интернет-серфинга его еще можно юзать, плюс ряд старых игр можно запускать без особых проблем.
Мой путь в мир линукса, как это все начиналось, как было и чем закончилось.
Это вторая статья из серии «моего пути», первая — про BSD и остальные сложные юниксы находится тут. В реальности погружение в индустрию происходило параллельно и я не выделял отдельные этапы работы только с линуксом или только с BSD.
Более того — в одной из следующих статей расскажу и про Windows, которую тоже знаю давно и глубоко.
Начало
Шел тяжелый 1998й год, тот самый кризисный, когда вместо рублей на ценниках красовался ныне забытый У.Е. а по улицам катались братки на черных мерседесах.
На самом деле, я уже не особо помню, какой точно дистрибьютив был первым — RedHat это был или Mandrake или даже Slackware, поскольку доставалось оно тогда охапками, ставилось «на посмотреть», быстро убивалось и откатывалось обратно на венды.
Но был один, с которым я зашел сильно дальше чем просто установка, с которого по-сути началось полноценное использование Linux.
Mandrake, Mandriva, Mageia
Мое более-менее осознанное использование линукса началось с Mandrake Linux. На что были веские причины:
несмотря на проблемы с оборудованием — мышка и та работала не всегда, Мандрейк был самым «пользовательским» дистрибутивом и только на нем одном можно было сразу получить хоть какое-то рабочее окружение, без сложной правки конфигов.
У него же был первый графический инсталлятор, который сам умел определять разрешение экрана и частоту развертки.
Плюс пакеты, много пакетов.
Судя по награде за 2000й год, у меня было что-то еще более древнее.
Сейчас это трудно объяснить, но выкачать даже 600Мб (размер одного CD-диска), необходимых для установки — по модему было ох как непросто.
Сутками скачивалось.
Поэтому имея 4 CD-диска, забитых софтом, можно было вполне комфортно жить. Вот так примерно выглядело окружение тех лет:
Тот самый KDE3, золотая классика и веха в развитии всего OpenSource.
Обратите внимание на XMMS — знаменитый линуксовый клон Winamp, на котором следущие 10 лет автор слушал музыку:
Да, это именно Netscape Navigator - предок Мозиллы и Firefox. До создания Хрома еще десять лет.
Доступ в интернет тогда был через телефонную линию и модем, время пентиумов, целеронов и хренового китайского железа (Acorp кто-то еще помнит?) Звук, видео и модем, раскладка клавиатуры и локализация — все это настраивалось, но с таким боем и по кривым мануалам, что словами эти ощущения не передать:
Видео — с ручной настройкой разрешения и частоты кадров, «плоских» мониторов еще не было;
Локализация — с кракозяблями и KOI8-R кодировкой, UTF-8 повсеместно появится через примерно пять лет.
Короче было весело.
CD-диски с Mandrake образца 2003го года, третий курс ВУЗа.
Wine тогда еще не придумали а развитие OpenOffice не позволяло нормально работать с документами MS Word — поэтому с самого начала (и поныне) у меня был dual boot:
венды, линуксы и BSD на разных разделах и разных дисках.
Количество компьютеров также постоянно росло, появлялись первые сервера и сетевое оборудование — благо работа «сисодмином-разработчиком» позволяла постоянно таскать домой самые разные железки.
Думаю мало кто из смертных может похвастаться опытом настройки домашней локалки на маршрутизаторе уровня ядра, пусть и недолгим — мне его дали на время, для обновления прошивки и настройки.
Настройка OSPRF, RIP и VLANов — в 2004м году, ручками, в дикой сибирской провинции.
Так что я работал с IOS задолго до появления этих ваших айфонов ;)
Но про сети и сисадминство расскажу как-нибудь в другой раз, благо там тоже было немало приключений.
Чудесные студенческие годы.
Едем дальше.
2007й год, который «блейзер-челки-эмо-готы» — вот это все. Еще это последний «жирный» год, потому что в следующем 2008 опять грянет мировой кризис. В тот год Мандрейк обанкротился, развалился и стал Мандривой, полная история для ценителей вот тут.
Но тем не менее, открытое продолжение Мандрейка - «Mandriva One» вновь стал очень большим шагом вперед, показав всему миру как надо делать нормальные дистрибьютивы.
Графический пошаговый инсталлятор, LiveCD, адекватная локализация - все что нужно для счастья линуксоида в ламповом 2007м .
Заодно настало время дурацких спецэффектов — появился Сompiz (Beryl и Emerald в те далекие времена):
Cейчас уже выглядит совсем аляповато, но в те годы это выглядело очень круто.
Образ Мандривы я уже выкачивал сам, но устанавливал пока еще с DVD диска. До первых «bootable usb stick» пройдет еще пару лет, а пока это все такой же «bootable iso» в лотке привода.
Вот так выглядело мое рабочее окружение в те годы:
Самый старый скриншот из сохранившихся. 2007й год.
Скриншот этот на самом деле очень интересный:
идет сборка из Portage от генты, но.. в Мандриве! Окружение — сильно переделанный jwm, а редактор — сильно переделанный Metpad. Котик (слева) — анимированный, мой, исходник потерялся в годах.
Обратите внимание, что в качестве браузера тут Firefox, поскольку Google выпустит первую версию Chrome только через год.
Много чего произошло с тех пор:
бесконечные работы во всех возможных жопах ИТ-отрасли, переезд в Германию, затем в Москву, в Сингапур, обратно в Москву и затем в Питер.
Но основным линуксом все также оставалась Мандрива.
2016й год, пью пиво посреди Сингапура.
Хотя временами я конечно перебирал со стилем:
Весна 2016го. Вроде и было не так давно, но насколько же мир успел измениться.
С тех пор и поныне, Mageia - продолжение Мандривы активно используется и является одной из ключевых рабочих систем.
Ныне это выглядит вот так:
ROSA , OpenMandriva и русский линукс
Как-то так получилось что чисто отечественные дистрибьютивы я толком не использовал — ни Альт ни ASP. И вся жесть вроде Black Cat Linux тоже обошла меня стороной :)
Росу я также полностью пропустил, вместе со всем их движем на тему совместной разработки с OpenMandriva. Видимо сказался хороший уровень владения английским, благодаря чему русская локализация мне никогда не была нужна.
Все остальное
Я перепробовал по большому счету все известные и популярные дистибьютивы. Какие-то использовал разово, какие-то использую по работе до сих пор а некоторых уже нет на свете (более не развиваются).
Хоть как-то описать весь мой опыт нереально, поэтому пройдусь по верхам.
Debian & Ubuntu
Получилось так, что с Дебианом я познакомился позже чем с Убунтой, причем путем «поиска первоисточника» в интернете. Шел 2005й год, Убунту к тому времени уже стала легендарной в мире опенсорса — из-за легкости в освоении для простых пользователей.
И действительно, ее удалось без особых проблем поставить на HP Compaq NX9020 — мой первый ноутбук:
Через него потом прошло все доступное и возможное, включая Sun Solaris x86, Slackware и все найденные BSD.
А вот уже «тюнингованный» Дебиан, внезапно на Panasonic CF-28:
2011й год, Москва.
C оформлением я опять сильно перебрал, поскольку тут еще больше кастомизированный JWM, уже без отсылок к оригиналу.
Много чего на C и Tcl писалось на этой машине:
2012й, Москва, парк Горького.
RedHat, CentOS и Scientific Linux
Серьезное использование началось с 2006 года, после переезда в Москву. Использовал именно для работы, когда было нужно иметь дело с закрытым корпоративным софтом от IBM и Oracle:
Все оно сильно зависело от устаревших системных библиотек, поэтому нормально работало только под такими специфическими дистрибьютивами.
Собственно ситуация с тех пор не сильно поменялась — завести «большую» вебсферу (не Liberty) под какой-нибудь убунтой такая же проблема как и 20 лет назад.
Scientific Linux — в своем роде уникальная штука, дистрибьютив созданный ИТ-департаментом CERN, у которого апстримом является и так стабильный CentOS. Получился эдакий дистиллят стабильности, в мире бесконечных обновлений и патчей обычных линуксов.
К сожалению не так давно разработка этого дистрибутива была прекращена.
Arch, Manjaro
Это уже новодел, с которым я впервые познакомился читая знаменитую Arch Linux Wiki.
В какой-то момент там собрали вообще всю актуальную информацию о тонкой настройке графики в линуксе: Xorg, Xinerama, Compiz, Wayland, о виртуализации: KVM, docker, ansible — короче обо всем, что делалось долго, сложно и требовало включать голову .
Логичным шагом стало изучение и самого арча. Впрочем он бысто надоел своей нестабильностью и я переключился на куда более стабильный Manjaro, который и cейчас используется на одном из ноутбуков для веб-разработки.
Всю жизнь таким занимаюсь.
Работа
Думаю у вас после прочтения встал очевидный вопрос:
чем же таким автор занимался по работе и кто платил за все эти компьютерные радости?
За все эти дистрибьютивы, изучение всяких BSD, сетей и установки линуксов на десктоп и ноутбуки — ведь это все несколько далеко от должностных обязанностей, кого бы то ни было.
На самом деле, чаще всего получалось, что ввиду широких компетенций, я совмещал обычно сразу несколько должностей: от планирования до разработки и внедрения.
Если делать разбивку на современные должности:
СTO, архитектор, тимлид, ведущий разработчик, аналитик, QA, DBA, DevOps, администратор и сетевой инженер.
Это было очень характерно для ИТ-индустрии в те годы, так что врядли удивлю кого-то из ветеранов.
Здравствуйте мои маленькие и взрослые любители линкуска.
Думаю, что каждый кто пользовался консолью, рано или поздно хотел ее кастомизировать, сделать функциональнее или красивее, и многих это приводило к проектам типа oh-my-zsh.
Вот и меня это приводило к нему и всегда вызывало попаболь.
На картинке все красиво, а когда начинаешь разбираться то понимаешь, что поймал какой то гемор.
Талмуды документации, не оень понятно с чего начинать, и самое что меня бесило это ручная правка конфига.
Все это приводило к тому что или ползовался какой то сборкой либо удалял его к чертям.
В общем мне все это надоело и я решил сделать свой фреймворк с блэкджеком понятным управлением и приятным интерфейсом которым хочется пользоваться.
И так, что мы имеем:
Все управление осуществляется через CLI, автозавершение команд через ТАБ.
Система плагинов - все так же включается и выключается командами через консоль, можно посмотреть список плагинов и описание к каждому из них. Возможность установки из других репозиториев.
Нескучные обои темы
Ииии о боже мой! Да разве можно было вообще о таком мечтать!
Переносимые профили!
Создал свой профиль, с темой набором плагинов, так же командой создается контейнер которым можно делиться или переносить между девайсами.
Все работает быстро и без тормозов.
Есть встроенный доктор который проверит конфигурацию на ошибки
DreamZSH Stats который показывает время загрузки и прочую инфу о текущей конфигурации.
Бэкапы
И прочие радости жизни. Я постарался учесть как можно больше деталей для удобство пользования. Порог вхождения стримится к нулю, можно даже мануал не читать.
В общем если вам интересно, ставьте, пользуйтесь, буду рад обратной связи.
Перевести проект в продакшен – это не поднять dev-стенд. Подходящий сервер должен выдерживать пиковую нагрузку, восстанавливаться после сбоев и не создавать сюрпризов ночью. Не каждый VPS подходит для этого: провайдеры по-разному гарантируют ресурсы, стабильность и время реакции поддержки.
Критерии production-ready VPS
VPS для продакшена должен давать предсказуемые ресурсы, а не мягкие лимиты с оверселлингом. Ключевые параметры: полноценная аппаратная виртуализация, изоляция ресурсов, стабильное хранилище, стабильная сетевая пропускная способность и поддержка IPv6. SLA не ниже 99,9% с описанными компенсациями – это важный ориентир для продакшена.
Безопасность и резервирование
Настройка сервера для продакшена начинается до деплоя: firewall настроен, SSH переведён на ключи. Типичные ошибки: открытые порты на всех интерфейсах, отсутствие изоляции между сервисами и ненастроенные snapshot’ы. Для любого продакшен-сервера регулярные бэкапы – обязательное условие. Без проверенного восстановления они не надёжны.
Мониторинг и автоматизация
Без метрик и алертинга продакшен-среда остаётся неконтролируемой. Подключите Prometheus или Zabbix, настройте пороговые алерты по CPU, RAM, дискам и времени ответа. Для крупных проектов и командной разработки полезно хранить конфигурацию инфраструктуры в Ansible или Terraform. Это упрощает деплой, поддержку среды и восстановление после сбоев, но не является обязательным условием для каждого продакшен-проекта.
Чек-лист: production-готовность VPS
• SLA ≥99,9% с описанными компенсациями
• Стабильное хранилище с понятными ограничениями по производительности
• Аппаратная виртуализация и изоляция ресурсов
• SSH-аутентификация по ключам, firewall настроен
• Автоматические бэкапы с тестом восстановления
• Мониторинг и алертинг (Prometheus или Zabbix)
Проверьте, закрывает ли ваш VPS-провайдер требования продакшен-нагрузки. Если по важным для проекта пунктам есть пробелы, лучше устранить их до деплоя, а не во время первого инцидента.
