В настоящее время я делаю первые шаги с помощью ansible, так что это может быть базовый вопрос.
Я пытаюсь настроить сервер с помощью ansible, на котором размещается несколько веб-страниц, а также предоставляется ряд других служб. Для каждого из них я необязательно хочу иметь возможность
В настоящее время у меня также есть роли для настройки сервера имен, шифрования и брандмауэра. Как лучше всего общаться между ролями? Следует, например, роль веб-сервера знает точную команду, как создать сертификат для себя, или, возможно, есть способ абстрагировать это до вызова уведомления? Должна ли каждая роль службы иметь возможность записывать в мой файл конфигурации брандмауэра или это должно быть каким-то образом привилегией роли брандмауэра?
Может быть, я слишком склонен к программистскому мышлению, но мне нравятся такие вещи, как «разделение по интересам», и я хотел бы иметь возможность, например мой брандмауэр без необходимости менять все остальные роли.
По понятным причинам невозможно дать точный ответ на ваш вопрос, но позвольте мне хотя бы указать на некоторые моменты, некоторые из них будут очень легко понятны с точки зрения программиста:
Храните данные и логику разделенными. ansible предоставляет средства для выполнения этой простой задачи, но вам необходимо создать свои роли функциональным образом, то есть сделать свои роли настраиваемыми с помощью данных.
Напишите свои роли, чтобы они делали только одно, но делали это хорошо. Это улучшает возможность повторного использования ваших ролей и упрощает техническое обслуживание в будущем.
При определении данных, которые будут определять поведение ваших ролей, не переусердствуйте с сложными структурами данных. ansible имеет довольно много итераторов, которые вы можете использовать, и даже дает возможность писать свои собственные, но если вам понадобится что-то более сложное, чем with_subelements, пришло время переосмыслить свои структуры данных.
Используйте теги. Вы можете ограничивать действия, используя комбинацию групп и тегов.
Использовать registers, чтобы зафиксировать результат ваших действий и использовать их в последующих действиях для управления потоком с помощью when заявления. Однако не усложняйте условия слишком сильно.
set_facts и assert может помочь в сборе данных о состоянии целевой системы.
Идемпотентность. Держите свои действия идемпотентными, чтобы избавиться от необходимости строить слишком много логики поверх своих действий. Думайте в терминах целевого статуса (желаемого состояния), а не в терминах процедурного языка.