Как автоматически добавлять новые капли в вашу систему управления конфигурацией

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

В этом руководстве мы будем использовать сценарийcloud-config для замены шага начальной загрузки вручную, позволяя новому узлу автоматически подключаться к серверу Chef, проверять себя, получать учетные данные клиента и выполнять начальный запуск клиента Chef. Сервер сделает это автоматически при первой загрузке без какой-либо помощи со стороны администратора.

Чтобы наш сценарийcloud-config успешно загрузился, ему потребуется доступ к учетным данным, обычно доступным для командыknife. В частности, нам нужны следующие фрагменты информации:

Вся эта информация доступна в правильном формате в файле конфигурацииknife на рабочей станции, используемой для управления инфраструктурой Chef. Внутри репозитория Chef должен быть скрытый каталог с именем.chef, содержащий этот файл.

Предполагая, что ваше репозиторий Chef расположен в вашем домашнем каталоге на рабочей станции и называетсяchef-repo, вы можете вывести содержимое файла, набрав:

Куски необходимой информации выделены ниже:

Имя проверки и URL-адрес сервера Chef можно получить непосредственно из файла как есть. Скопируйте эти значения, чтобы использовать их в файлеcloud-config.

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

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

Вы увидите закрытый ключ RSA:

Скопируйте ключ проверки целиком, чтобы сразу же использовать его в сценарииcloud-config.

Если у вас есть данные выше, вы можете создать сценарий. Конфигурация Chef может быть выполнена с помощью специального модуляcloud-config под названиемchef. cloud-config должен содержать действительный YAML и должен иметь#cloud-config в качестве первой строки скрипта.

Начиная с, ваш скрипт будет выглядеть так:

В документацииcloud-config утверждается, что клиент Chef можно установить либо из драгоценного камня Ruby, либо из пакета, либо с помощью традиционного метода установки «омнибус». Однако на практике методы gem и package обычно терпят неудачу, поэтому мы будем использовать метод «omnibus». Хотя обычно в этом нет необходимости, мы также явно перечислим расположение установщика omnibus.

Мы установимforce_install на «ложь». Таким образом, если по какой-либо причине клиент Chef уже установлен в образе (например, если вы развертываете из снимка), клиент не будет переустановлен. Пока что наш скрипт выглядит так:

Затем у нас есть возможность выбрать имя для нового сервера в инфраструктуре Chef с помощью директивыnode_name. Если вы не установите это, Chef будет использовать имя хоста сервера, так что это необязательно. Тем не менее, это должно быть уникальным в вашей среде шеф-повара.

После этого мы можем добавить всю информацию о подключении, которую мы взяли с нашей рабочей станции Chef. Мы установим опциюserver_url на расположение сервера Chef точно так же, как это было в файлеknife.rb. То же самое и с опциейvalidation_name.

В качестве ключа проверки мы будем использовать вертикальный символ YAML (|), чтобы ввести весь ключ проверки, который мы нашли на рабочей станции:

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

Хотя приведенные выше сведения предоставляют достаточно информации для подключения клиента к серверу Chef, мы не предоставили узлу никакой информации о том, как на самом деле настроить себя. Мы также можем предоставить эту информацию в скриптеcloud-config.

Чтобы указать среду, в которой должен быть размещен новый узел, используйте параметрenvironment. Если он не установлен, будет установлена ​​среда_default, которая является общим значением по умолчанию для узлов Chef, которым не была предоставлена ​​другая среда.

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

Вы можете указать начальные атрибуты нового узла, используя иерархиюinitial_attributes. Это установит начальные атрибуты, которые повлияют на применениеrun_list:

При подключении к предыдущему сценариюcloud-config это может выглядеть примерно так:

Приведенный выше сценарий содержит всю информацию, необходимую в разделеchef:. Однако есть еще несколько вещей, которые мы должны сделать, используя другие модулиcloud-config.

Во-первых, мы должны указать, что мы хотим перенаправить вывод каждой команды и подкоманды в выходной журнал процесса CloudInit. По умолчанию он находится в/var/log/cloud-init-output.log. Мы можем сделать это с помощью модуляoutput следующим образом:

Еще одна вещь, которую мы хотим сделать, - настроить клиент Chef так, чтобы он действительно работал после его установки и настройки. На момент написания этой статьи метод установки omnibus не делал этого автоматически.

Мы можем заставить это поведение, дождавшись, пока исполняемый файлchef-client не будет установлен на сервере, прежде чем вызывать команду. Используя простой циклbash, мы будем проверять наличие этого файла каждые пять секунд. Когда он будет найден, мы запустимchef-client, чтобы реализовать указанную нами начальную конфигурацию.

Модульruncmd можно использовать для выполнения произвольных команд. Это идеальное место для нашего циклаbash:

Кроме того, при желании вы можете добавить еще одну директивуcloud-config для нулевого маршрута конечной точки метаданных после первой загрузки. Это полезно, потому что мы помещаем закрытый ключ в наши пользовательские данные. Без нулевой маршрутизации конечной точки метаданных это было бы доступно любому пользователю на сервере. Реализуйте это, добавив:

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

Приведенный выше скрипт можно настроить по мере необходимости для каждого нового сервера в вашей инфраструктуре.

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

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

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

Первое, что нам нужно сделать перед созданием нашего файлаcloud-config, - это собрать данные с нашего главного сервера Puppet, которые нам нужно будет подключить. Нам нужно всего несколько кусочков информации.

Во-первых, вам нужно получить полное доменное имя (FQDN) главного сервера Puppet. Вы можете сделать это, набрав:

В большинстве случаев он должен возвращать что-то вроде этого:

Вы также можете проверить свой главный файл конфигурации Puppet, чтобы узнать, установлен ли параметрdns_alt_names:

Если SSL-сертификаты вашего Puppet master были созданы после установки этих параметров, они также могут быть использованы.

Другим предметом, который нам нужно собрать, является сертификат центра сертификации Хозяина Марионеток. Его можно найти либо в/var/lib/puppet/ssl/certs/ca.pem, либо в/var/lib/puppet/ssl/ca/ca_crt.pem:

Результаты будут выглядеть примерно так:

Скопируйте сертификат полностью. Мы будем включать это в наш файлcloud-config, чтобы наши новые серверы могли проверить, что они подключаются к правильному мастеру Puppet.

Получив эти данные, вы можете приступить к созданию файлаcloud-config, чтобы новый сервер мог подключиться к существующей инфраструктуре Puppet.

Конфигурацияcloud-config для новых узлов Puppet довольно проста. Вся конфигурация, специфичная для Puppet, находится в разделе файлаpuppet:. Как и в любом файлеcloud-config, самая первая строка должна содержать#cloud-config сама по себе:

Под этим есть только два подраздела. Первый - это клавишаca_cert. При этом будет использоваться символ канала для запуска текстового блока YAML, чтобы сертификат CA мог быть задан полностью как блок с отступом:

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

Второй раздел под зонтикомpuppet: - это разделconf:. Используется для указания пар ключ-значение, которые будут добавлены в общий файлpuppet.conf. Пары "ключ-значение" должны быть размещены под заголовками разделов, как в файлеpuppet.conf.

Например, по крайней мере, новый сервер должен знать адрес главного сервера Puppet. В файлеpuppet.conf это находится в разделе[agent], например:

Чтобы указать это в синтаксисеcloud-config, вы должны добавить это к тому, что у нас есть:

Обратите внимание, что разделconf: соответствует разделуca_cert, а не дочернему элементу. Это необходимый минимум для подключения к Хозяину Марионеток. Любые дополнительные элементы конфигурации, найденные вpuppet.conf, могут быть добавлены аналогичным образом, сначала создав уровень для имени раздела, а затем определив пару ключ-значение.

После этого мы должны перенаправить весь будущий вывод в файлcloud-init-output.log и добавить строкуruncmd, сопоставимую с той, которую мы добавили для конфигурации Chef. Это будет ждать, пока агент Puppet не будет установлен, а затем включить и перезапустить его. Мы также можем обнулить конечную точку метаданных после первого запуска, как мы делали в разделе Chef. Эти строки директивыcloud-config должны быть размещены вне любых других разделов модуля:

С помощью этой информации новый сервер может подключиться к главному серверу Puppet, а затем сгенерировать запрос подписи сертификата клиента для передачи главному серверу. По умолчанию клиентские сертификаты должны быть подписаны вручную на мастере Puppet. Как только это будет сделано, в следующий интервал обновления агента Puppet (по умолчанию каждые 30 минут) узел будет извлекать свою конфигурацию из мастера Puppet. Чуть позже мы продемонстрируем, как реализовать относительно безопасный механизм автоподписи, чтобы избежать этой задержки.

Одно из значений, которое может быть помещено в файлpuppet.conf нового сервера, является уникальным случаем. В файлеcloud-config параметрcertname может заменять значения из среды, если заданы определенные переменные. Следующие переменные распознаются:

Имея это в виду, обычная настройкаcertname будет выглядеть так:

Это дастcertname с шаблоном, подобным этому:

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

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

В файлеpuppet.conf на главном сервере Puppet вы можете установить параметрautosign в разделе[master] файла. Это может принимать несколько разных значений:

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

Чтобы продемонстрировать автоматическую подпись на основе политик, вы можете добавить переменнуюcertname к вашемуcloud-config, которая включает переменную идентификатора экземпляра%i. Мы будем использовать%i.%f, чтобы он также включал выбранное имя хоста:

Ваш полныйcloud-config теперь может выглядеть примерно так:

На главном сервере Puppet нам нужно будет настроить скрипт проверки. Поскольку Ruby уже установлен для Puppet, мы можем создать простой скрипт на Ruby.

Поскольку мы используем формат%i.%f дляcertname, мы можем проверить, соответствует ли первая частьcertname (часть перед первой точкой) действительному идентификатору капли для нашей учетной записи. . Это просто простая проверка, которая на практике не делает намного больше, чем файл белого списка. Тем не менее, вы можете адаптировать эту идею, чтобы быть гораздо более сложной, если хотите.

Для этого нам потребуется персональный токен доступа из раздела «Приложения и API» панели управления DigitalOcean. Вам также нужно будет установить одну из библиотек DigitalOcean Ruby. Ниже мы покажем вам несколько упрощенных скриптов, которые используют клиенты DigitalOcean RubyBarge иDropletKit.

Если вы хотите использовать клиент Barge, установите гем на своем Puppet master, набрав:

Следующий сценарий можно использовать для проверки, соответствует ли первая частьcertname в запросе подписи сертификата действительному идентификатору капли:

Если вы вместо этого хотите использовать DropletKit, официальный клиент DigitalOcean Ruby, вы можете установить гем, набрав:

Обратите внимание, что гем DropletKit действителен только для Ruby 2.0 и выше, поэтому это может быть невозможно при использовании версии Ruby, поставляемой с Puppet.

Скрипт для DropletKit можно адаптировать так:

Вы можете поместить скрипт, соответствующий установленному вами гему, в файл с именем/etc/puppet/validate.rb и пометить его как исполняемый, набрав:

Затем вы можете добавить следующее в свой файлpuppet.conf (расположенный в/etc/puppet/puppet.conf, если вы используете Puppet с открытым исходным кодом):

Перезапустите службу Apache для реализации новой политики подписывания:

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