Я пытаюсь создать макетную управляемую инфраструктуру (не предпринимательство) в AWS с экземплярами EC2. Используя модуль puppetlabs-aws, я могу создавать машины с помощью удобных средств. Далее следует сделать локальные настройки для каждого node, что самое важное - установить уникальное имя хоста. Как я могу это сделать?

Один из способов, которым я знаю, - предоставить script с помощью параметра user_data. Это было бы здорово, но чтобы быть полезным, мне нужно иметь возможность параметризовать этот script, чтобы избежать дублирования script один раз для каждого агента.

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

Update

Чтобы привести пример моей проблемы, рассмотрите этот фрагмент моего мануфактурного манифеста:

Это обеспечит запуск и запуск двух экземпляров. Обратите внимание, что user_data => template('configure.erb') ссылается на шаблон script, который выполняется в экземпляре после его создания. Здесь я мог бы задать имя хоста (или что бы я хотел), если бы я знал только, на какие данные основывать решение. Я могу добавить теги к описаниям экземпляров, но это невозможно прочитать из configure.erb script, насколько я знаю.

В любом случае, установка имени хоста - это только моя идея решить проблему с корнем. Могут быть другие более удобные методы. То, что я хочу, это просто способ иметь эти два экземпляра, представляющие разные типы node для марионеточного мастера.

Ответы

Ответ 1

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

Позвольте мне попытаться объяснить проблему, я думаю, вы пытаетесь обратиться к

То, что я пытаюсь ответить здесь

У вас есть существующий script, который устанавливает виртуальные хосты EC2 на AWS с использованием aws-марионеточного модуля. Этот модуль вызывает AWS API для фактического создания виртуальных хостов EC2. Но они содержат только конфигурацию, которая "встроена" в файл AMI, который используется в вызове API. Типичным AMI файлом может быть базовое изображение Centos. Дальнейшая конфигурация возможна на этом этапе через "пользовательские данные script". Но допустим, что это оболочка script, которую трудно проверить и поддерживать и поэтому не содержать сложную настройку

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

Эта вторая фаза контролируется новыми виртуальными хостами EC2, прикрепленными к марионеточному хозяину в их собственном праве. Так что я предполагаю, что вы делаете это:

этап 1, что делает хосты EC2
фаза 2, когда они сами настраиваются из марионеточного

Основной ответ с использованием ролей

Здесь некоторые идеи о том, как сделать этот сценарий с двухфазной конфигурацией хостов EC2,

При создании времени создайте персонализированный "роль". Сделайте файл в /etc/facter/facts.d/role.yaml как это

role: webserver

Это можно настроить, так как экземпляр создается путем добавления такой команды к данным пользователя script

echo 'role: webserver' > /etc/facter/facts.d/role.yaml

Пока эта "роль" настроена до запуска марионеток, она будет работать нормально.

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

Затем измените свой site.pp, чтобы сказать что-то вроде

include "$role"

И init.pp из модуля заработает и сделает все правильно, установит пакеты, настроит файлы и т.д.

Эта идея объясняется более подробно здесь https://puppetlabs.com/presentations/designing-puppet-rolesprofiles-pattern

Другой подход

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

---
:backends:
  - yaml
:hierarchy:
    - role/%{::role}
    - global
:yaml:
  :datadir: /etc/puppet/environments/production/hiera

Тогда у меня может быть файл /etc/puppet/environments/production/hiera/role/webserver.yaml, в котором говорится

classes:
  - webserver
  - yum_repos
  - logstash
  - java8

И конец сайта .pp говорит

hiera_include('classes')

Загружает все соответствующие определения классов из файлов modules_include

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

"Глобальная" часть конфигурации yaml предназначена для классов, загружаемых всем в вашей среде, например, admin user ssh keys

пример определенного типа

Вот пример того, как вы можете использовать определенный тип в качестве обертки вокруг ec2_instance, чтобы передать "myrole" в шаблон. Я не тестировал это, у меня нет установленного марионетка aws.

define my_instance( 
  $ensure = present,
  $region = 'us-west-2',
  $image_id = 'ami-f0091d91',
  $instance_type = 't2.micro',
  $key_name= 'mykey',
  $security_groups = ['provision-sg'],
  $myrole = 'webserver'
  )
{
ec2_instance { $title :
  ensure => $ensure,
  name => $title,
  region => $region,
  image_id => $image_id,
  instance_type => $instance_type,
  key_name => $key,
  security_groups => $security_groups,
  user_data => template('configure.erb'),
}
}

$instance_data={
  'backend' =>
  {
  ensure => present,
  name => 'backend',
  region => 'us-west-2',
  image_id => 'ami-f0091d91',
  instance_type => 't2.micro',
  key_name => 'mykey',
  security_groups => ['provision-sg'],
  myrole => 'voodooswamp'
},
  'webfront'=>
  {
  ensure => present,
  region => 'us-west-2',
  image_id => 'ami-f0091d91',
  instance_type => 't2.micro',
  key_name => 'mykey',
  security_groups => ['provision-sg'],
  myrole => 'humanfly'
  }
}


create_resources(my_instance, $instance_data)