Управление конфигурацией для «одного сервера, несколько администраторов»

Мы создали сервер, на котором работает инфраструктура для небольшой ассоциации. До сих пор мы пытались управлять конфигурацией с помощью Ansible, но это не было большим успехом. Возможно, мы делаем это неправильно.

В принципе, идея заключается в том, что этот сервер большую часть времени останется один, и люди будут добавлять или изменять что-то один раз в голубой луне. Это делает крайне важным, чтобы все, что настроено и работает на сервере, было хорошо задокументировано и понятно, поскольку люди, которые не управляют системой, часто теряют обзор (не говоря уже о запоминании деталей). Кроме того, со временем состав группы людей, которые будут администрировать этот сервер, изменится (когда люди уходят и присоединяются к «комитету»).

Мы начинали с чистой установки, добавляя роли в ansible всякий раз, когда мы хотели что-то настроить (nginx, phpfpm, postfix, firewall, sftp, munin, ..). Возможно, из-за нашей неопытности, мы, конечно, никогда не сможем напечатать набор ответных задач точно так, как нам нужно, чтобы это было за один раз, также потому, что конфигурация - это процесс проб и ошибок. Это означает, что на практике мы обычно сначала настраиваем любую службу, которую хотим запускать на сервере , а затем переводим в доступные задачи. Вы можете видеть, куда это идет. Люди забывают затем протестировать задачу или боятся сделать это, рискуя что-то сломать, или еще хуже: мы забываем или пренебрегаем добавлением вещей к ansible.

Сегодня у нас очень мало уверенности в том, что конфигурация ANSIBLE действительно отражает то, что настроено на сервере.

В настоящее время я вижу три основные проблемы:

• Трудно (читай: у нас нет хорошего способа) протестировать задания, не рискуя сломаться.
• Это добавляет дополнительную работу, чтобы сначала выяснить желаемую конфигурацию, а затем выяснить, как преобразовать это в ответные задачи.
• (В идеале) мы не используем его достаточно часто, чтобы создать привычку и рутину.

Важным моментом здесь является то, что для всего, что мы в конечном итоге делаем, новичкам должно быть легко выучить веревки без тонны практики.

Есть ли жизнеспособная альтернатива, которая по-прежнему предоставляет некоторые гарантии и проверки (сравнимые с объединением файлов Ansible с некоторыми master), которые «не позволяют настроить вещи и записать то, что вы сделали»?

РЕДАКТИРОВАТЬ: Мы рассмотрели совершение /etcмерзавца. Есть ли разумный способ защитить секреты (закрытые ключи и т. Д.) Таким образом, но все же есть хранилище конфигурации, доступное за пределами сервера?

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

Это не только поможет в тестировании новых изменений, но и послужит испытательным стендом для новых сотрудников (или сотрудников старшего возраста, которые давно не пользовались системой) для ознакомления с вашими настройками.

Что касается хранения / etc / в git: нет, не делайте этого. Этот каталог - лишь малая часть того, что меняется в ansible, и наличие там git только побудит людей делать локальные изменения.

Держите ваши сборники игр в Git. Подумайте об ограничении разрешений, чтобы только вы могли применить анальные изменения к работающему серверу. Другие могут отправлять запросы извлечения со своими изменениями, которые вы можете просмотреть и в случае необходимости объединить с мастером.

Возможно, из-за нашей неопытности, мы, конечно, никогда не сможем напечатать набор ответных задач точно так, как нам нужно, чтобы это было за один раз, также потому, что конфигурация - это процесс проб и ошибок. Это означает, что на практике мы обычно сначала настраиваем любую службу, которую хотим запускать на сервере, а затем переводим в доступные задачи.

Хотя есть и другие проблемы (например, отсутствие тестовой среды), вы можете добиться значительных улучшений, не делая этого .

Одна из основных целей разработки Ansible - быть идемпотентом , а это значит, что многократное использование вашей книги игр не должно ничего менять (если вы не изменили игры). Таким образом, когда я настраиваю новую часть программного обеспечения, мои шаги:

1. Внесите изменения в Ansible задач.
2. Запустите playbook.
3. Проверьте систему и, если она не верна, вернитесь к шагу 1.
4. Передайте мои изменения.

Если вы не думаете, что в первый раз напишите в Ansible правильную вещь , все равно пишите ее и повторяйте до тех пор, пока она не станет правильной, как и любой другой код. Это значительно снижает вероятность того, что вы забудете Ansiblize внести некоторые изменения, которые вы сделали, поскольку каждое внесенное вами изменение уже было в Ansible в какой-то момент в процессе разработки.

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

Для начала у вас может быть слишком много поваров, без четкого владения, если это так, ожидайте трагедию общего достояния. Каждый бизнес-приоритет каждый раз побеждает проблемы системной инженерии, если только она не ослаблена, а то, что осталось, отражается непосредственно на ответственном инженере.

Набор инструментов CM не может быть спроектирован администраторами, это то, что я только что понял. Они могут повторно использовать существующую работу или ВОЗМОЖНО распространяться на прочной основе, но даже тогда это потребует обременительного применения практики. То, что может сделать инженер, это просто НЕ то, что может сделать администратор. Многие понятия в Ansible почти такие же, как в кодовой базе. Можете ли вы научить администратора Python и ожидать компетентных результатов? Нет, наверняка нет, я бы ожидал хакерскую работу, поэтому вам нужно сделать задачу достаточно структурированной, чтобы хакерская работа была сносной.

Таким образом, вам нужно настроить вещи для успеха, разработать решения для точек ненужного администрирования. Торгуйте сложными системами низкого уровня для вещей, которые администратор мог бы на самом деле сделать успешно. Набор инструментов CM НЕ спасет вас от архитектурных или дизайнерских несоответствий.

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

1. Переместите любую работу, связанную с бизнес-процессами, в выделенную рабочую палубу.

2. Разделив задачи на боксы, вы можете иметь два или более боксов в одном прямо сейчас.

3. Переопределяйте свой CM более структурированным образом и следуйте лучшим практическим методам, учебникам, представляющим объекты, а не функции или роли. Каждая система должна быть описана в одной игре.