Мой личный чек-лист для Linux сервера

2021-08-26 20:14 · обн. 2026-05-15 20:00 · 7 мин чтения · jtprogru

Привет, %username%! Небольшая заметка (в первую очередь для меня) о том, что требуется сделать при разворачивании нового Linux-сервера.

🔄 Обновлено 2026-05-15: подтянул список дистрибутивов под текущую реальность (CentOS Linux EOL с июня 2024), добавил блок про современный стек мониторинга и перекрёстные ссылки на свежие посты про SLO и SRE.

Выбор OS#

Начать стоит с выбора OS, т.к. это довольно важный момент. Если в компании уже имеется какое-то количество серверов на Linux, то стоит выбирать тот дистрибутив, который преобладает. Если среди дистрибутивов творится бардак и зоопарк, то стоит определиться с тем, на какой дистрибутив переводить все остальные и разворачивать новые. На выбор в 2026 году имеет смысл рассматривать:

Debian 12 (Bookworm) или Debian 13 (Trixie) — стабильный, предсказуемый, минимум сюрпризов;
Ubuntu Server LTS — 24.04 на горизонте до 2029, 22.04 ещё в активной поддержке;
Rocky Linux или AlmaLinux — наследники CentOS Linux, бинарная совместимость с RHEL;
RHEL — если у тебя есть подписка и желание/требование платить за поддержку;
Oracle Linux — если уже сидишь в экосистеме Oracle.

Что НЕ стоит ставить на новый сервер:

CentOS Linux — мёртв с июня 2024 (CentOS 7 — последний релиз), наследники выше;
CentOS Stream — это rolling-релиз и upstream для RHEL, для прода обычно не подходит;
Ubuntu non-LTS — короткий цикл поддержки, проблем больше, чем пользы.

Со сравнением некоторых дистрибутивов можно ознакомиться в статье на Habr: Есть ли жизнь после CentOS? .

Шаблонизирование#

Чтобы проще было выбирать (если еще не определился) просто разверни виртуалку с каждым дистрибутивом на своей системе виртуализации (VMware или Proxmox). Поиграйся с каждым дистрибутивом и оцени какой именно тебе больше подходит. Как только ты определился с выбором, сделай преднастройку минимальную и сконвертируй в Template готовую виртуалку.

Важно: Не стоит сразу ставить весь необходимый софт (агенты мониторинга, базовые тулзы) – тебе в дальнейшем надо будет как-то это обновлять сразу после разворачивания виртуалки из шаблона.

Создай служебного пользователя automator под которым в дальнейшем будешь ходить на сервер с помощью того же Ansible. Если есть какой-то стандарт со стороны ИБ, то можешь перенастроить порт SSH =)

Короче на этом этапе не стоит сильно увлекаться – кажущееся упрощение принесет только дополнительные страдания.

Авторизация#

Этот пункт относится уже к свежеразвернутому серверу. Запомни: никто не должен иметь прямого доступа от пользователя root – запрети вход по SSH с учеткой root. Так же запрети вход на сервера по паролю. С помощью автоматизации на ansible и пользователя automator создаешь отдельных пользователей для всех своих коллег (из числа тех, кто должен иметь доступ на сервер).

Я лично для себя держу отдельную роль Ansible для случаев, когда “надо кому-то помочь” – jtprogru.profile .

Ставится она вот так просто (как и любая другая роль из Ansible Galaxy):

ansible-galaxy install jtprogru.profile

Данная роль создает мою учетку, устанавливает пароль, добавляет ключи и кидает некоторые конфиги в профиль. Сделай себе что-то подобное и будет тебе счатье! А если ты работаешь в команде, то можно всем стандартизировать профили. Короче включай фантазию и пользуйся мозгами.

Есть еще и альтернативная роль. В ней ничего грандиозного нету. Позволяет указать список логинов и ключей. Так же доступна в Ansible Galaxy: jtprogru.admins_access .

В дальнейшем тебе никто не мешает прикрутить ту же FreeIPA, LDAP, Keycloak для авторизации на серверах и ходить по доменным учеткам. Но иметь локальую служебную учетку на случай “БИГ БАДА БУМ!” ты обязан.

По ключам отдельно: RSA-2048 уже не комильфо. Дефолт сегодня — ed25519 (или sk-ed25519 если у тебя есть FIDO2-ключ типа YubiKey). Подробнее — в посте Авторизация по ключу при подключении по SSH .

Необходимый софт#

Список необходимых тулзовин, которые надо ставить на сервер обычно у каждого админа свой, но я попытался собрать что-то усредненно-обобщенное. Список этого софта я так же для упрощения своей жизни собрал в виде Ansible-роли, которая так же доступна для всех – jtprogru.install_base_soft . Ставим роль:

ansible-galaxy install jtprogru.install_base_soft

Роль позволяет расширить список софта каким-то специфичным и даже переопределить основной список – все в твоих руках.

Параметры ядра#

К настройкам ядра в Linux стоит относится аккуратно и читать документацию. С некоторыми из параметров ядра можно ознакомиться в одной из моих прошлых статей: Настройка Linux для HL и защиты от DDoS . На случай работы с параметрами ядра у меня – не поверишь! – тоже есть ролька небольшая в Ansible Galaxy – jtprogru.sysctl . Данную роль стоит запускать с осторожностью и трижды подумать подбирая и меняя параметры.

Так же стоит учитывать, что в зависимости от дистрибутива, его версии и версии используемого ядра наименования некоторых параметров ядра могут отличаться. Короче как обычно – БУДЬ ВНИМАТЕЛЬНЕЕ!

На современных ядрах (6.x в Debian 12/13, Ubuntu 24.04, Rocky/Alma 9) часть старых рецептов уже устарела или сменила дефолты — например, BBR-congestion control давно стабилен и его можно включать без оглядки, а net.core.somaxconn по умолчанию подняли. Не копипасть параметры из статей десятилетней давности без проверки man sysctl и текущих дефолтов в твоём ядре.

Мониторинг#

В качестве систем мониторинга используй ту систему, которую хорошо знаешь. Ну это мой тебе субъективный совет. В остальном я лично вижу два стандарта: Prometheus и Zabbix .

Если у тебя нет еще работающей системы мониторинга или ты пока не особо понимаешь “зачем оно тебе надо”, то сходи вот в эту статью и почитай: Мониторинг: что/куда/зачем? .

Я лично делю эти системы для себя по следующему принципу:

Zabbix – мониторинг инфраструктуры, состояние сервера, хранение исторических данных за большой промежуток времени;
Prometheus – мониторинг Docker/Kubernetes;

Я знаю что в Zabbix появляется возможность мониторить и Docker, и Kubernetes, но не могу полноценно рекомендовать т.к. не использовал. Просто установленный на хосте Docker daemon отлично мониторится с помощью Zabbix Agent 2, думаю и для Kubernetes уже появилось какое-то решение.

За пять лет, что прошло с момента написания этого поста, стек ощутимо разросся. Кроме Zabbix и Prometheus сейчас имеет смысл смотреть в сторону:

VictoriaMetrics — Prometheus-совместимый сторадж, который в проде заметно экономнее по ресурсам и быстрее на больших объёмах;
Loki + Tempo + Pyroscope — стек Grafana Labs для логов, трейсов и continuous profiling;
OpenTelemetry — vendor-agnostic стандарт сбора метрик/логов/трейсов. Универсальный SDK и коллектор, который можно подружить почти с любым бэкендом;
Grafana Alloy — единый коллектор, заменяет зоопарк из Prometheus node_exporter, Promtail, OTel-collector.

Подробнее про модели мониторинга и инструменты — в моём посте Мониторинг: что/куда/зачем? . А ещё имеет смысл смотреть не только на «зелёные дашборды», но и на SLO как чертёж архитектуры — это уже про то, ради чего весь мониторинг нужен.

Итог#

По итогу мы получаем Linux-сервер с локальной служебной учетной записью для работы автоматизации (или в случае аварийного доступа). Который будет очень быстро разворачиваться и не будет требовать дополнительных телодвижений.

В целом для первоначального старта этого всего достаточно, а дополнительное и полезное можно глянуть в этих статьях:

Что показывает atop? – отличная утилита, которая может быть очень полезна на самых первых этапах (когда мониторинга как такового нету совсем);
Авторизация по ключу при подключении по SSH – как настроить авторизацию по ключу (не редко среди разрабов и начинающих админов этого не популярная инфа);
Ansible – основы управления конфигурацией – немного об основах Ansible, который мне очень нравится своей тем, что он довольно простой для старта и с ним легко начать практиковать IaC;
Настройка systemd-resolved – настройка встроенного резолвера (SystemD уже здесь – смирись и прекрати срать башовыми скриптами в /etc/init.d/);
Настраиваем systemd-timesyncd – настройка встроенного демона синхронизации времени;
Установка Zabbix на Ubuntu – небольшая заметка о том, как установить Zabbix;
Установка Grafana на Ubuntu – стандартная визуализация от Zabbix мне не заходит, а вот Grafana прям доставляет удовольствие;
SLO как чертёж архитектуры – зачем вообще всё это считать и как от мониторинга прийти к понятным целям надёжности;
Эволюция SRE 2020-2025 – что поменялось в индустрии за последние пять лет.

Что-то прям дофига набралось ссылочек на собственные статьи =\

Ну если чего-то не хвататет – ссылки для связи внизу. На этом всё!

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

О способах отблагодарить автора можно почитать на странице “Донаты ”.