Назад | Перейти на главную страницу

Подходит ли Puppet или Chef для управления самой базовой конфигурацией сервера в многопользовательской среде?

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

Подходит ли Puppet (или аналогичная) технология для внесения элементарных, но критических изменений массы? Например:

Меня беспокоит безопасность и инвазивность:

  1. Я не хочу, чтобы какой-либо сервер мог видеть какую-либо конфигурацию, которой он не должен
  2. Меня беспокоит, что мастер марионеток может быть уязвим для атаки со стороны взломанного сервера.
  3. Я не хочу, чтобы Puppet вносил какие-либо изменения, которых не должен, или отменял любые ручные изменения, сделанные на сервере.

Я должен предупредить об этом, сказав, что я никогда не использовал Puppet в продакшене, только немного поигрался в тестовой лаборатории, так что, возможно, я ошибаюсь в этом!

Да, конечно, это возможно. Однако решать, стоит ли вам это делать или нет, зависит от вас.

Относительно ваших запросов:

1) достаточно честно. Трафик основан на ssl, поэтому управление сертификатами важно. Также не доверяйте никаким «фактам», которые предоставляет клиент, касающимся его личности, поскольку они могут быть изменены клиентом. Вы хотите полагаться на SSL-сертификат клиента, чтобы обеспечить аутентификацию того, кто является сервером. Честно говоря, если вы правильно используете такие вещи, как hiera и избегаете огромных if-блоков на основе имени хоста в своем коде (что вам действительно следует), все будет в порядке.

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

3) Это действительно проблема тестирования и развертывания. Если у вас есть надежный марионеточный код, он не испортит ваши файлы. На то, чтобы разобраться в этом, требуется некоторое время, но на основы (например, вам нужно) не так много времени.

Попробуйте Ansible (ansible.cc). Может быть, это для тебя. На ваших клиентах не запущен агент. Он очень быстро растет.

Еще одна очень хорошая альтернатива - это Salt Stack.

Ansible и Salt просты для понимания, вы можете использовать их как инструмент командной строки, если хотите, например, распределенную оболочку.

Подходит ли Puppet (или аналогичная) технология для внесения элементарных, но критических изменений массы?

Да, это можно использовать таким образом. Я использую это для поддержки внешних клиентских систем.

Я не хочу, чтобы какой-либо сервер мог видеть какую-либо конфигурацию, которой он не должен

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

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

Я не хочу, чтобы Puppet вносил какие-либо изменения, которых не должен, или отменял любые ручные изменения, сделанные на сервере.

Есть несколько разных подходов к разрешению локальных изменений.

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

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

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

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

Другая возможность - использовать augeas для внесения изменений на уровне строки вместо изменения файлов целиком. Будьте очень консервативны в том, что вы меняете.

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

Я не хочу, чтобы Puppet вносил какие-либо изменения, которых не должен, или отменял любые ручные изменения, сделанные на сервере.

Для файлов конфигурации, созданных с использованием типа файла Puppets File, это можно сделать, установив:

replace => false,

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

Однако это противоречит философии Puppet как идемпотентного сценария развертывания.

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

Puppet лучше всего подходит для многих серверов с идентичной конфигурацией. Например. вы пишете всю конфигурацию совместно используемого веб-сервера, предоставленного вашей компанией, а затем создаете N экземпляров этого сервера. Впоследствии внести изменения во всех экземплярах сразу (например, вы обнаружите, что необходимо изменить AllowOverride для всех виртуальных хостов apache) будет очень просто. Вы также сможете хранить всю информацию о конфигурации в одном месте и контролировать ее версии. В идеальном случае вы сможете справиться с аппаратным отказом, выбросив сломанный хост, заменив его новым, установив то же имя хоста и подписав необходимый сертификат. Все остальное можно сделать с помощью Puppet.

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

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