Почему я перевёл все серверы с CentOS на Debian 12

Если вы до сих пор держите серверы на CentOS 7 или 8 — поздравляю, вы живёте в прошлом. CentOS 7 умер в июне 2024, CentOS 8 убили ещё раньше — в конце 2021-го, когда Red Hat переориентировал его на CentOS Stream. А Stream — это уже не стабильный дистрибутив, это rolling-превью RHEL. Использовать это в продакшне — сомнительное удовольствие.

У меня под управлением около 40 серверов: веб, базы данных, мониторинг, CI/CD, хранилища. Всё исторически крутилось на CentOS 7. Работало нормально, не трогай — не сломается. Но время вышло.

Варианты на замену я рассматривал три: Debian 12 (Bookworm), Ubuntu 22.04 LTS и Rocky Linux 9. Забегая вперёд — выбрал Debian. Сейчас объясню почему.

Rocky — очевидный преемник CentOS для тех, кто хочет остаться в экосистеме RHEL. Binary-совместимость, те же пакеты, привычный dnf. Соблазн велик, особенно если у вас куча проверенных RPM-скриптов.

Но мне не нравится зависимость от Red Hat. Один раз уже наступили на эти грабли с CentOS. Rocky держится на энтузиазме сообщества, и хотя у проекта есть коммерческая поддержка от CIQ, я не уверен, что через 5 лет ситуация не повторится.

Ubuntu — вполне себе взрослый серверный дистрибутив. LTS-версии поддерживаются 5 лет, Canonical не собирается никуда пропадать. Но у Ubuntu есть раздражающие особенности: snap-пакеты в неожиданных местах, netplan вместо нормальных конфигов сети, и вообще чувствуется, что Canonical любит экспериментировать.

Debian — это скучно. Скучно в хорошем смысле. Никаких сюрпризов, предсказуемый цикл релизов, огромный репозиторий пакетов. Bookworm вышел в 2023 году и будет поддерживаться до 2028-го с LTS до 2033-го. Никакой корпоративной повестки.

Репозиторий backports позволяет получать свежие версии отдельных пакетов без перехода на testing. Это удобно, когда нужен, например, свежий PostgreSQL или Nginx.

Прямой апгрейд с CentOS на Debian невозможен — разные форматы пакетов, разная структура системы. Только чистая установка.

Мой подход:

# 1. Снимаем список всего установленного на старом сервере
rpm -qa --queryformat '%{NAME}
' | sort > installed_packages.txt

# 2. Экспортируем конфиги (всё, что в /etc)
tar czf etc_backup.tar.gz /etc/

# 3. Делаем дамп баз, если есть
mysqldump --all-databases > all_databases.sql

# 4. Устанавливаем чистый Debian 12, потом восстанавливаем данные

Самые частые грабли при миграции:

• Сетевые интерфейсы называются иначе. На CentOS был eth0, на Debian будет ens3 или enp2s0. Правьте /etc/network/interfaces.
• Firewall: на CentOS firewalld, на Debian по умолчанию вообще нет фаервола — ставьте ufw или настраивайте iptables/nftables напрямую.
• SELinux vs AppArmor: CentOS использует SELinux, Debian — AppArmor. Это разные системы мандатного контроля доступа. Если у вас были кастомные SELinux-политики — придётся переписывать.

Базовые операции несложно перемапить в голове:

# Обновить систему
# CentOS: dnf update -y
apt update && apt upgrade -y

# Установить пакет
# CentOS: dnf install nginx
apt install nginx

# Найти пакет
# CentOS: dnf search package
apt search package

# Информация о пакете
# CentOS: dnf info package
apt show package

Один момент, который удивляет переходящих с RPM: в Debian пакеты нередко разделены на основной и -dev. Например, libssl-dev отдельно от libssl. Если что-то не компилируется — скорее всего, нужен -dev вариант.

AppArmor проще SELinux в управлении. Профили лежат в /etc/apparmor.d/, проверить статус:

aa-status

Если приложение ведёт себя странно — смотрите /var/log/kern.log на предмет apparmor="DENIED". Временно перевести профиль в complain-mode:

aa-complain /etc/apparmor.d/usr.sbin.nginx

40 серверов мигрировал за два месяца, по выходным. Один сервер завис на этапе восстановления базы — оказалось, несовместимая версия MySQL. Остальные прошли без критических проблем.

Debian оправдал ожидания: стабильный, предсказуемый, хорошо документированный. Никакой корпоративной зависимости. Если вы ещё на CentOS — начинайте планировать миграцию прямо сейчас.