CentOS 8 вышел: разворачиваем тестовый стенд и разбираемся с AppStream на практике

Дождались. CentOS 8.0 вышел официально - и в тот же день мы подняли тестовый стенд, чтобы посмотреть как всё это работает в реальности, а не в release notes. В июле писали про анонс и аудит парка - теперь время пощупать живой дистрибутив.

Главный вопрос был не про DNF (там всё прозрачно - yum как симлинк, команды работают) и не про SELinux enforcing по умолчанию (это мы ожидали, у нас и так enforcing на всех новых серверах). Главный вопрос - как на практике ведёт себя AppStream с реальными сценариями установки PHP и Node.js, которые мы используем в managed-проектах.

Первые полчаса

Установка через ISO прошла без замечаний. Anaconda стала чуть приятнее, хотя это субъективно. После ребута - чистая система, DNF работает, SELinux в enforcing. /usr/bin/python - нет нигде, что и ожидалось. python3 - есть, 3.6.8.

Первое, что бросается в глаза: dnf repolist показывает два репозитория - baseos и appstream. Это и есть базовое разделение, о котором читали в документации RHEL 8. BaseOS - системная база, AppStream - приложения и рантаймы в виде модулей.

Попробовали сразу dnf install php. Ответ неожиданный: пакет есть, ставится - php 7.2 из AppStream без каких-либо телодвижений. Хорошо. Но это дефолтный поток, а нам в некоторых проектах нужен 7.3 или конкретная сборка.

Где ломается привычная логика

Вот тут начинается самое интересное - нет, не так. Вот тут выясняется, что модульность - это не просто версионирование пакетов, это смена контракта между системой и администратором.

Смена потока не работает "в лоб". Если PHP уже стоит из потока по умолчанию, и вы хотите переключиться на другой поток, dnf module enable php:7.3 выдаёт ошибку: нельзя сменить активный поток, пока установлены пакеты из текущего. Нужно сначала dnf module reset php, потом dnf remove всего что связано с PHP, потом включить новый поток, потом ставить заново. Это не одна команда. Это процедура.

Конфликты между модулями реальные. Мы попробовали поставить PHP 7.3 и одновременно MySQL 8.0 через AppStream. Конфликта нет, они в разных модулях. Но когда добавили модуль perl, выяснилось, что некоторые Perl-модули тянут зависимости из Python 2.7-пакетов, которые конфликтуют с нашим Python 3.6-профилем. Не критично, но осознать это через сообщения об ошибке DNF - не самое простое упражнение.

Node.js и версии. dnf module list nodejs показывает потоки: 10 и 12. Дефолт - 10. Включаем 12 командой dnf module enable nodejs:12, ставим nodejs - получаем Node.js 12.x. Это работает нормально, логично. Но если потом в CI-скрипте написан просто dnf install nodejs без предварительного enable нужного потока - получишь 10-й, и не сразу поймёшь почему.

Что это значит для Ansible-ролей

Мы сразу прогнали несколько ролей из нашего набора - тех, что ставят PHP и Node.js на CentOS 7. На восьмёрке все они либо упали, либо поставили не то.

Проблема системная: роли использовали yum/dnf модуль Ansible с прямым указанием пакетов. На CentOS 7 это работает - пакет ищется в EPEL или vendor-репо. На CentOS 8 пакет либо не найден (если не включён нужный AppStream-модуль), либо найден, но версии не та что ожидается.

В Ansible 2.8 появился модуль dnf с поддержкой AppStream-модулей - можно передавать enablemodule и state: enabled. Это рабочий путь, но плейбуки нужно переписывать. Простой yum: name=php больше не достаточен, нужно явно описывать желаемый поток.

Пример задачи в плейбуке для PHP 7.3 на CentOS 8 получается примерно такой:

- name: enable php 7.3 stream
  dnf:
    name: "@php:7.3"
    state: present

- name: install php packages
  dnf:
    name:
      - php
      - php-fpm
      - php-mysqlnd
    state: present

Синтаксис @module:stream - это нотация DNF для работы с AppStream. Работает, но надо знать.

SELinux и первые шероховатости

SELinux enforcing - это не новость, мы его не выключаем. Но на тестовом стенде сразу напоролись на то, что nginx из AppStream при запуске с нестандартным DocumentRoot пишет в лог Permission denied без очевидного объяснения. audit2allow в помощь - там всё стандартно, нужно semanage fcontext или chcon. Сюрприза нет, просто напоминание: если переезжать с CentOS 7, где кто-то в своё время выключил SELinux и не включил обратно - это будет первая боль при переезде.

Где мы с этим сейчас

Тестовый стенд работает. Понимание AppStream есть, хотя и потребовало нескольких часов возни. Вывод пока такой: для новых инсталляций восьмёрка нормальна, если изначально строить роли с учётом модульности. Для миграции существующих серверов - нужен отдельный план, потому что механика установки пакетов изменилась принципиально, не косметически.

Продакшн-инсталляции пока не трогаем - смотрим как дистрибутив поживёт первые недели, читаем что приходит от других команд. У CentOS 8 репутации нарабатывать надо с нуля, и торопиться здесь незачем.