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