Управление конфигурацией для «одного сервера с несколькими администраторами»
Мы установили сервер, на котором работает инфраструктура небольшой ассоциации. Уже, мы пытались управлять конфигурацией с помощью Ansible, но безуспешно. Возможно, мы делаем это неправильно.
В принципе, идея состоит в том, что этот сервер будет большую часть времени оставаться в покое, и люди будут добавлять или изменять вещи один раз в синюю луну. Это делает крайне важным, чтобы все, что настроено и запущено на сервере, было хорошо документировано и понятно, поскольку люди, которые не администрируют систему часто, неизбежно теряют обзор (не говоря уже о деталях). Кроме того, со временем состав группы людей, которые будут администрировать этот сервер, изменится (по мере того, как люди уходят и присоединяются к «комитету»).
Мы начали с чистой установки, добавляя роли в анзибле всякий раз, когда мы хотели что-то настроить (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Возможно, из-за нашей неопытности мы Конечно, мы никогда не сможем напечатать набор доступных задач в точности так, как нам нужно, за один раз, в том числе потому, что настройка - это своего рода процесс проб и ошибок. Это означает, что на практике мы обычно сначала настраиваем любую службу, которую хотим запустить на сервере , а затем переводим ее в доступные задачи. Вы можете видеть, к чему это идет. Люди забывают затем протестировать задачу или боятся сделать это, рискуя сломать что-то, или, что еще хуже: мы забываем или пренебрегаем добавлением вещей в анзибл.
Сегодня у нас очень мало уверенности в том, что конфигурация анзибля действительно отражает что настроено на сервере.
В настоящее время я вижу три основные проблемы:
- Трудно (читай: у нас нет хорошего способа) тестировать доступные задачи, не рискуя сломать их.
- Это добавляет дополнительную работу, чтобы сначала выяснить желаемую конфигурацию, а затем выяснить, как преобразовать это в доступные задачи.
- (В идеале) мы не используем его достаточно часто, чтобы создать привычку и рутину.
] Важное соображение здесь заключается в том, что независимо от того, чем мы в конечном итоге займемся, должно быть легко новичкам освоить канаты без тонны практики.
Есть ли жизнеспособная альтернатива, которая все еще дает некоторые гарантии и проверки (сравнимые с объединением файлов Ansible с каким-то мастером ), что «настроить вещи и записать, что вы сделали» не обеспечивают?
РЕДАКТИРОВАТЬ: Мы рассматривали возможность фиксации / и т. д. мерзать. Есть ли разумный способ защитить секреты (закрытые ключи и т. Д.) Таким образом, но все еще есть хранилище конфигурации, доступное за пределами сервера?
Просто запустите тестовую / промежуточную виртуальную машину, которую вы можете использовать для проверки ваших изменений. Ваш текущий метод внесения изменений сначала вручную безнадежно сломан и обречен на провал. Вы и ваша команда должны взять на себя обязательство использовать CM должным образом, и отчасти это связано с наличием тестовой системы. Достаточно даже просто локальной бродячей виртуальной машины.
Это не только поможет при тестировании новых изменений, но также послужит испытательной площадкой для новых сотрудников (или более старых сотрудников, которые не использовали систему некоторое время), чтобы ознакомиться с вашей настройкой ansible.
Относительно сохранения / etc / в git: нет, не делайте этого. Этот каталог - лишь малая часть того, что изменяется в ansible, и наличие там git только побудит людей вносить локальные изменения.
Храните ваши ansible playbooks в git. Рассмотрите возможность ограничения разрешений, чтобы только вы могли применять доступные изменения к действующему серверу. Другие могут отправлять запросы на вытягивание со своими изменениями, которые вы можете просмотреть и при необходимости объединить в мастер.
Возможно, из-за нашей неопытности мы, конечно, никогда не сможем напечатать набор доступных задач в точности так, как нам нужно, за один раз, также потому, что конфигурация - это немного метод проб и ошибок. Это означает, что на практике мы обычно сначала настраиваем любую службу, которую хотим запустить на сервере, а затем переводим в доступные задачи.
Хотя есть и другие проблемы (например, отсутствие среды тестирования), вы можете значительно улучшить ситуацию, не выполняя это .
Одна из основных целей разработки Ansible - быть идемпотентным , что означает, что многократный запуск вашей playbook ничего не изменит (если вы не изменили пьесы). Таким образом, когда я настраиваю новое программное обеспечение, я делаю следующие шаги:
- Внесите изменения в задачи Ansible.
- Запустите playbook.
- Изучите систему и, если она не верна, вернитесь к шагу 1.
- Зафиксируйте мои изменения.
Если вы не думаете, что напишете что-то правильное с первого раза в Ansible, все равно напишите и повторяйте, пока он не станет правильным, как и любой другой код. Это значительно снижает вероятность того, что вы забудете внести в Ansible некоторые изменения, которые вы внесли, поскольку каждое внесенное вами изменение уже было в Ansible в какой-то момент в процессе разработки.
Ansible имеет время нарастания, прежде чем вы превысите свой предыдущий уровень производительности, но как только вы это сделаете, состояние вашей системы легко проверить. Кажется, что ваши практики не соответствуют вашим конечным целям. Вы можете работать продуктивно с помощью набора инструментов CM, сохраняя при этом твердые инженерные практики, но для его правильной структуры требуется время. По сути, вы торгуете эффективностью и простотой реализации для стабильности и масштабируемости предприятия. Точно так же, как опытный профессиональный программист не пишет уродливых хаков, последствия всегда перевешивают выгоды.
Для начала, у вас может быть слишком много поваров без четкого владения, если так, ожидайте трагедию общества.Каждый бизнес-приоритет всегда будет преобладать над проблемами системной инженерии, если только он не будет широко решен и то, что останется, отражается непосредственно на ответственном инженере.
Набор инструментов CM не может быть спроектирован администраторами, это то, что я только что приходить к пониманию. Они могут повторно использовать существующую работу или, ВОЗМОЖНО, расширить на прочной основе, но даже тогда это потребует обременительного применения практики. То, что может сделать инженер, - это просто НЕ то, что может делать администратор. Многие концепции в Ansible почти такие же, как и в кодовой базе, можете ли вы научить административный питон и ожидать компетентных результатов? Нет, конечно, нет, я бы ожидал хакерской работы, поэтому вам нужно сделать задачу достаточно структурированной, чтобы хакерская работа была сносной.
Итак, вам нужно настроить все на успех, разработать решения для точек ненужное администрирование. Обменяйте низкоуровневую сложность систем на вещи, которые администратор действительно может успешно делать. Набор инструментов CM НЕ спасет вас от несоответствий в архитектуре или дизайне.
Таким образом, порядок может быть изменен, очевидно, потому что реализация зависит от того, какой путь наименее разрушителен для вашего текущего состояния.
Переместите любую системную работу, связанную с бизнес-процессами, в специальная Rundeck.
Разделите задачи на блоке, прямо сейчас у вас может быть два или более блока.
Переопределите свой CM более структурированным образом и следуйте лучшим практикам, представляющим объекты, а не функции или роли. Каждую систему следует описать в одной пьесе.