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

23 сентября, 2017 12:28 пп 965 views | Комментариев нет

Linux, VPS | Amber | Комментировать запись

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

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

Требования

Умение работы с метаданными.
Базовые навыки работы со сценариями cloud-config, понимание их синтаксиса и поведения.

Читайте также:

Сценарий cloud-config для запуска ноды в Chef

Используя метаданные и сценарий cloud-config, вы можете легко привязать новый сервер к существующей инфраструктуре Chef.

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

Общий план

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

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

Сбор данных для сценария cloud-config

Для сценария cloud-config необходим следующий набор данных:

Значения validation name и validation key системы Chef.
URL-адрес, по которому доступен сервер Chef.

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

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

cat ~/chef-repo/.chef/knife.rb

Вся необходимая вам информация выделена в этом примере красным.

current_dir = File.dirname(__FILE__) log_level :info log_location STDOUT node_name "jellingwood" client_key "#{current_dir}/jellingwood.pem" validation_client_name "your-validator" validation_key "#{current_dir}/your-validator.pem" chef_server_url "https://your_server.com/organizations/your-organization" syntax_check_cache_path "#{ENV['HOME']}/.chef/syntaxcache" cookbook_path ["#{current_dir}/../cookbooks"]

Параметр validation name и URL сервера Chef можно просто скопировать.

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

Чтобы вывести содержимое файла your-validator, используйте эту команду:

cat ~/chef-repo/.chef/digitalocean-validator.pem

Примечание: Укажите свой путь к файлу.

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

-----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA3O60HT5pwEo6xUwcZ8WtExBUhoL3bTjlsvHVXg1JVmBUES+f V9jLu2N00uSZEDZneCIQyHLBXnqD/UNvWEPNvPzt1ecXzmw2BytB7lPDW4/F/8tJ vAVrKqC7B04VFGmcFY2zC8gf8BWmX8CNRDQooM7UO5OWe/H6GDGPPRIITerO3GrU . . . sWyRAoGBAKNc/ZUM8ljRV0UJxQ9nbdozXRZjtUaNgXMNiw+oP2HYYdHrlkKnGHYJ Js63rvjpq8pocjE8YI+2H0v4/4uWqW8GEBfrWbLMzGsYPnRyiHR5+hgjCUU50RB3 eFoNbURwLYcq2Z/IAQZpDpJWpofz3OVMpMXtei1cIflrAAd2wtWO -----END RSA PRIVATE KEY-----

Скопируйте все содержимое ключа (вместе со строками BEGIN и END).

Базовый сценарий cloud-config для Chef

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

#cloud-config chef:

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

В force_install укажите значение false. Если вдруг окажется, что клиент Chef уже установлен (такое бывает при развертывании из снапшота), инсталлятор не станет переустанавливать его. Теперь сценарий выглядит так:

#cloud-config chef: install_type: "omnibus" omnibus_url: "https://www.opscode.com/chef/install.sh" force_install: false

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

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

В validation_key используйте символ конвейера (|), чтобы вставить весь ключ.

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

Настройка среды Chef, run_list и атрибутов

Приведенных выше данных достаточно для подключения клиента к серверу Chef. Но у ноды нет никакой информации о настройке и оркестровке. Эту информацию также можно предоставить в сценарии cloud-config.

Чтобы определить среду новой ноды, используйте опцию environment. Если этой директивы нет, будет использоваться среда _default.

chef: environment: "staging"

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

chef: run_list: - "recipe[lamp]" - "role[backend-web]"

Указать исходные атрибуты новой ноды можно с помощью иерархии initial_attributes. Она определит атрибуты, которые повлияют на применение метода run_list:

chef: initial_attributes: lamp: apache: port: 80 mysql: username: webclient pass: $#fjeaiop34S

В результате сценарий cloud-config будет иметь такой вид:

#cloud-config chef: install_type: "omnibus" omnibus_url: "https://www.opscode.com/chef/install.sh" force_install: false node_name: "new_node" server_url: "https://your_server.com/organizations/your-organization" validation_name: "your-validator" validation_key: | -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA3O60HT5pwEo6xUwcZ8WtExBUhoL3bTjlsvHVXg1JVmBUES+f V9jLu2N00uSZEDZneCIQyHLBXnqD/UNvWEPNvPzt1ecXzmw2BytB7lPDW4/F/8tJ vAVrKqC7B04VFGmcFY2zC8gf8BWmX8CNRDQooM7UO5OWe/H6GDGPPRIITerO3GrU . . . sWyRAoGBAKNc/ZUM8ljRV0UJxQ9nbdozXRZjtUaNgXMNiw+oP2HYYdHrlkKnGHYJ Js63rvjpq8pocjE8YI+2H0v4/4uWqW8GEBfrWbLMzGsYPnRyiHR5+hgjCUU50RB3 eFoNbURwLYcq2Z/IAQZpDpJWpofz3OVMpMXtei1cIflrAAd2wtWO -----END RSA PRIVATE KEY----- environment: "staging" run_list: - "recipe[lamp]" - "role[backend-web]" initial_attributes: lamp: apache: port: 80 mysql: username: webclient pass: $#fjeaiop34S

Перенаправление вывода и настройка запуска клиента Chef

В разделе chef: есть все необходимые данные. Осталось только немного дополнить сценарий cloud-config.

Для начала нужно настроить перенаправление вывода каждой команды в лог CloudInit, по умолчанию /var/log/cloud-init-output.log.

output: {all: '| tee -a /var/log/cloud-init-output.log'}

Теперь нужно настроить клиент Chef для запуска после установки и настройки. На момент написания статьи omnibus не поддерживает автоматического запуска клиента.

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

Модуль runcmd может выполнять произвольные команды. Сюда можно поместить цикл.

runcmd: - while [ ! -e /usr/bin/chef-client ]; do sleep 5; done; chef-client

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

disable_ec2_metadata: true

Теперь у вас есть сценарий для запуска и оркестровки новой ноды в инфраструктуре Chef. Он выглядит так:

Сценарий можно откорректировать в соответствии с потребностями нод и инфраструктуры.

Сценарий cloud-config для запуска ноды в Puppet

Если инфраструктура поддерживается системой Puppet, вы можете использовать модуль puppet. Как и в предыдущем примере, для запуска и добавления ноды в инфраструктуру используется сценарий cloud-config.

Для работы вам понадобится мастер-сервер и инфраструктура Puppet.

Общий план

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

Но прежде агент должен зарегистрироваться на мастер-сервере Puppet. Он создает запрос на подпись сертификата и отправляет его мастеру.

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

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

Сбор данных с мастер-сервера Puppet

Прежде чем приступить к написанию сценария cloud-config, нужно собрать всю необходимую информацию для подключения к мастер-серверу.

Чтобы узнать FQDN мастера Puppet, введите:

hostname -f puppet.example.com

Примечание: FQDN будет отличаться. Не забудьте откорректировать сценарий.

Теперь убедитесь, что в конфигурационном файле Puppet есть опция dns_alt_names:

cat /etc/puppet/puppet.conf . . . dns_alt_names = puppet,puppet.example.com . . .

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

Далее нужно найти центр сертификации мастера Puppet. Он может быть в /var/lib/puppet/ssl/certs/ca.pem или /var/lib/puppet/ssl/ca/ca_crt.pem:

sudo cat /var/lib/puppet/ssl/certs/ca.pem -----BEGIN CERTIFICATE----- MIIFXjCCA0agAwIBAgIBATANBgkqhkiG9w0BAQsFADAcMRowGAYDVQQDDBFQdXBw ZXQgQ0E6IHB1cHBldDAeFw8xNTAyMTkxOTA0MzVaFw0yMDAyMTkxOTA0MzVaMBwx GjAYBgNVBAMMEVB1cHBldCBDQTogcHVwcGV0MIICIjANBgkqhkiG9w0BAQEFAAOC . . . arsjZT5/CtIhtP33Jl3mCp7U2F6bsk4/GDGRaAsFXjJHvBbL93NzgpkZ7elf0zUP rOcSGrDrUuzuJk8lEAtrZr/IfAgfKKXPqbyYF95V1qN3OMY+aTcrK20XTydKVWSe l5UfYGY3S9UJFrSn9aBsZzN+10HXPkaFKo7HxpztlYyJNI8UVSatcRF4aYYqt9KR UClnR+2WxK5v7ix0CVd4/KpYH/6YivvyTwxrhjF2AksZKg== -----END CERTIFICATE-----

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

Теперь можно приступать к написанию cloud-config.

Базовый сценарий cloud-config для Puppet

Сценарий cloud-config для нод Puppet довольно прост. Все параметры Puppet хранятся в разделе puppet:.

Любой сценарий cloud-config начинается со строки #cloud-config:

#cloud-config puppet:

Далее идут два раздела. Первый содержит ключ ЦС, ca_cert. Используйте символ конвейера, чтобы вставить ключ:

#cloud-config puppet: ca_cert: | -----BEGIN CERTIFICATE----- MIIFXjCCA0agAwIBAgIBATANBgkqhkiG9w0BAQsFADAcMRowGAYDVQQDDBFQdXBw ZXQgQ0E6IHB1cHBldDAeFw8xNTAyMTkxOTA0MzVaFw0yMDAyMTkxOTA0MzVaMBwx GjAYBgNVBAMMEVB1cHBldCBDQTogcHVwcGV0MIICIjANBgkqhkiG9w0BAQEFAAOC . . . arsjZT5/CtIhtP33Jl3mCp7U2F6bsk4/GDGRaAsFXjJHvBbL93NzgpkZ7elf0zUP rOcSGrDrUuzuJk8lEAtrZr/IfAgfKKXPqbyYF95V1qN3OMY+aTcrK20XTydKVWSe l5UfYGY3S9UJFrSn9aBsZzN+10HXPkaFKo7HxpztlYyJNI8UVSatcRF4aYYqt9KR UClnR+2WxK5v7ix0CVd4/KpYH/6YivvyTwxrhjF2AksZKg== -----END CERTIFICATE-----

Далее в разделе puppet: идет подраздел conf:. Он содержит пары ключ-значение, которые будут добавлены в файл puppet.conf. Их нужно писать в таком виде, в каком они будут добавлены в этот файл.

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

. . . [agent] server = puppet.example.com . . .

В синтаксисе cloud-config он записывается так:

Раздел conf: должен находиться на одном уровне с ca_cert. Так выглядит базовый сценарий для подключения ноды к мастеру Puppet. Дополнительные элементы из puppet.conf можно добавить в сценарий аналогичным образом: создать уровень для названия раздела, а затем определить пару ключ-значение.

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

. . . conf: agent: server: "puppet.example.com" output: {all: '| tee -a /var/log/cloud-init-output.log'} runcmd: - while [ ! -e /usr/bin/puppet ]; do sleep 5; done; puppet agent --enable; service puppet restart disable_ec2_metadata: true

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

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

Определение опции certname для ноды

Опция certname может переопределить значения среды. Доступны следующие переменные:

%i: идентификатор экземпляра сервера. Он будет извлечен из http://169.254.169.254/metadata/v1/id при создании сервера. Он совпадает с идентификатором виртуального сервера.
%f: FQDN сервера.

Общая настройка certname будет выглядеть так:

#cloud-config puppet: . . . conf: agent: server: "puppet.example.com" certname: "%i.%f"

Это сгенерирует certname по такому шаблону:

|- ID | | |-Fully Qualified Domain Name | | |-----||-------------------| 123456.testnode.example.com

Автоматизация подписи клиентских сертификатов

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

В файл puppet.conf на мастере Puppet нужно добавить опцию autosign в раздел [master]. Унее может быть несколько значений.

true: мастер Puppet будет подписывать все входящие запросы без каких-либо проверок. Это очень опасно, потому что любой хост может получить подписанный сертификат и войти в инфраструктуру.
<whitelist_filename>: эта опция позволяет создать белый список хостов. Мастер Puppet будет сверять запросы на подпись с этим списком. Эту опцию использовать не рекомендуется, так как имена сертификатов можно легко подделать.
<policy_executable>:эта опция указывает сценарий или исполняемый файл, с помощью которого можно определить, стоит ли подписывать сертификат. Puppet передаст запрос и certname как аргумент по стандартному вводу. Если мастер вернул состояние 0, сертификат был подписан. Если он вернул другое состояние, сертификат не подписан.

Опция автоматической подписи policy_executable является наиболее безопасным решением, которое использует переменную %i. Используйте %i.%f, чтобы добавить также и имя хоста.

#cloud-config puppet: conf: agent: server: "puppet.example.com" certname: "%i.%f" ca_cert: | . . .

Теперь сценарий cloud-config выглядит так:

#cloud-config puppet: conf: agent: server: "puppet.example.com" certname: "%i.%f" ca_cert: | -----BEGIN CERTIFICATE----- MIIFXjCCA0agAwIBAgIBATANBgkqhkiG9w0BAQsFADAcMRowGAYDVQQDDBFQdXBw ZXQgQ0E6IHB1cHBldDAeFw8xNTAyMTkxOTA0MzVaFw0yMDAyMTkxOTA0MzVaMBwx GjAYBgNVBAMMEVB1cHBldCBDQTogcHVwcGV0MIICIjANBgkqhkiG9w0BAQEFAAOC . . . arsjZT5/CtIhtP33Jl3mCp7U2F6bsk4/GDGRaAsFXjJHvBbL93NzgpkZ7elf0zUP rOcSGrDrUuzuJk8lEAtrZr/IfAgfKKXPqbyYF95V1qN3OMY+aTcrK20XTydKVWSe l5UfYGY3S9UJFrSn9aBsZzN+10HXPkaFKo7HxpztlYyJNI8UVSatcRF4aYYqt9KR UClnR+2WxK5v7ix0CVd4/KpYH/6YivvyTwxrhjF2AksZKg== -----END CERTIFICATE----- output: {all: '| tee -a /var/log/cloud-init-output.log'} runcmd: - while [ ! -e /usr/bin/puppet ]; do sleep 5; done; puppet agent --enable; service puppet restart disable_ec2_metadata: true

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

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

Для этого вам понадобится токен доступа вашего провайдера и библиотека Ruby. В данном примере используется клиент Ruby под названием Barge.

Установите gem Barge на мастер Puppet.

sudo gem install barge

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

#!/usr/bin/env ruby require 'barge' TOKEN = 'YOUR_API_TOKEN' droplet_ids = [] certname = ARGV[0] id_string = certname.slice(0...(certname.index('.'))) id_to_check = id_string.to_i client = Barge::Client.new(access_token: TOKEN) droplets = client.droplet.all droplets.droplets.each do |droplet| droplet_ids << droplet.id end Kernel.exit(droplet_ids.include?(id_to_check))

Можно поместить сценарий в /etc/puppet/validate.rb и сделать его исполняемым:

sudo chmod +x /etc/puppet/validate.rb

Затем добавьте в /etc/puppet/puppet.conf строку:

. . . [master] autosign = /etc/puppet/validate.rb . . .

Перезапустите сервис Apache.

sudo service apache2 restart

Теперь мастер Puppet будет автоматически подписывать сертификаты агентов.

Tags: Chef, cloud-config, Puppet

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.