Волею судьбы у меня появились серверные ресурсы для создания собственной тестовой инфраструктуры. Хотя многие вещи можно протестировать, прибегая к помощи таких вещей как Docker, некоторые вещи лучше тестировать, а главное отлаживать, на живых виртуальных машинах с чистым Linux в той или иной форме. При создании тестовой инфраструктуры для Linux дистрибутивов я столкнулся с некоторыми подводными камнями о которых хочется упомянуть.

На данный момент основная цель тестовый инфраструктуры — это проверка работы моих ролей для Ansible в чистых операционных системах и их взаимодействия между собой. В существующих ролях, доступных в Ansible Galaxy меня не устраивает несколько вещей:

1. Часть ролей написана для определённых операционных систем и тестировалось только на них. Например, роли команды DebOps в основном тестируются на Debian, часто работают на Ubuntu, но обычно не работают на CentOS.
2. Роли команды ANXS тоже в основном нацелены на Debian/Ubuntu, иногда имеют поддержку CentOS, но при этом редко обновляются, либо требуют сильной взаимосвязи с другими ролями той же команды и не могут работать в индивидуальном виде.
3. Ну и последнее, но не менее важное для меня – свои роли я могу использовать для своих клиентов и в этом случае я могу быть уверен в том, что изменения в ролях с момента последнего применения не разрушат боевую систему клиента. Не все разработчики Ansible ролей думают об обратной совместимости. В тоже время, я спокойно могу повышать требования к версии самого Ansible, не заботясь о совместимости с теми версиями, которые не использую сам.

Для тестов я создавал виртуальные машины со следующими операционными системами:

• CentOS 6.8 — минимальная установка только с root пользователем.
• CentOS 7.3 – минимальная установка с не root пользователем.
• Debian 8 (Jessie) v8.7.1 – минимальная установка, с дополнительными компонентами в виде OpenSSH сервера и стандартными системными утилитами.
• Ubuntu 14.04 — минимальная установка, с дополнительными компонентами в виде OpenSSH сервера.
• Ubuntu 16.04 — минимальная установка, с дополнительными компонентами в виде OpenSSH сервера и стандартными системными утилитами.

Все операционные системы создавались в вариантах x32 и x64, для проверки корректной работы путей при работе с Ansible. Это не касается CentOS 7, который в x32 не разрабатывается (для серверов).

Итак, с чем я столкнулся и что хотелось бы запомнить.

CentOS (все версии).

В данной операционный системе при установке системы в конфигурации прописывается mac адрес сетевого адаптера. Таким образом, когда система клонируется из шаблона сетевой адаптер отсутствует.

Лечение заслуживает отдельного поста.

CentOS 6.8

В 64-битном исполнении отказался запускаться без swap раздела. Совсем. Связано это с VmWare ESXi или внутренними проблемами я не выяснял. Однако 32-битная версия запустилась без этого раздела без вопросов.

Ubuntu 16.04

Как я говорил выше, моя тестовая инфраструктура создана для тестирования ролей Ansible. Сам Ansible требует для работы пакет python, который отсутствует в минимальной установке Ubuntu 16.04.

Лечится следующим образом:

sudo apt-get update
sudo apt-get install python -y

Debian 8

В том варианте установки, который использовал я, в системе нет sudo. Совсем. Система использует su, что требует адаптации Ansible ролей.

Все указанные Linux системы

Во всех системах нет vm-ware-tools, что логично для пустых образов. Для своих тестов я создал два варианта шаблонов. В первом шаблоне vm-ware-tools нет как нет и другого софта, типа банального nano. Во втором варианте шаблонов установлен пакет open-vm-tools, который заменяет функционал родных утилит VmWare и есть в готовом виде во всех системах, кроме CentOS. В CentOS этот пакет есть в составе репозитория epel.

Подробные инструкции по установке пакета в отдельном посте.