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

Выбор OS

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

  • Debian 10;
  • Ubuntu Server LTS;
  • CentOS;
  • RHEL;
  • Oracle Linux;
  • Rocky Linux;
  • AlmaLinux;

Со сравнением некоторых дистрибутивов можно ознакомиться в статье на 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 для авторизации на серверах и ходить по доменным учеткам. Но иметь локальую служебную учетку на случай “БИГ БАДА БУМ!” ты обязан.

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

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

ansible-galaxy install jtprogru.install_base_soft

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

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

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

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

Мониторинг

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

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

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

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

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

Итог

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

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

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

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

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