Использование сред Puppet в Linux для безопасного обновления агента

Объективный

Создавайте и используйте среды puppet для тестирования новой конфигурации перед обновлением системы Live Production.

Версии операционной системы и программного обеспечения

Операционная система: Любой основной дистрибутив Linux, например, Ubuntu, Debian, CentOS
Программное обеспечение: кукла и кукловод

Требования

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

Конвенции

# – требует, чтобы данные команды Linux выполнялись с привилегиями root либо непосредственно от имени пользователя root, либо с помощью команды sudo
$ – данные команды Linux для выполнения от имени обычного непривилегированного пользователя

Знакомство

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

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

Как используются окружения Puppet?

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

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

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

Создание окружения Puppet

В этом руководстве мы создадим очень простой экземпляр Puppet с мастером Puppet и узлом агента Puppet. Главный сервер Puppet будет сконфигурирован таким образом, чтобы иметь две среды; тестирование и разработка.

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

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

Расположение конфигурации Puppet по умолчанию меняется в зависимости от используемого дистрибутива. В Ubuntu 18.04LTS, версии, которая будет использоваться в этом руководстве, расположение находится в /etc/puppet. Другие дистрибутивы (и официальная документация) могут разместить его в /etc/puppetlabs/. Однако, как только вы окажетесь в главном каталоге конфигурации Puppet, все подкаталоги будут одинаковыми для всех дистрибутивов.

Резолюция

Создание директорий окружения

Все окружения и их конфигурация находятся в каталоге /etc/puppet/code/. В Ubuntu 18.04 этот каталог пуст при установке, поэтому нам нужно сначала создать два каталога среды верхнего уровня с помощью следующих двух команд:

mkdir -p /etc/puppet/code/environments/testing
mkdir -p /etc/puppet/code/environments/development

Любой новый узел агента будет автоматически подключаться к среде разработки, если переменная окружения не установлена в альтернативное значение в разделе [agent] файла puppet.conf на узле агента.

Создание двух простых манифестов site.pp

Файл site.pp является основным манифестом, с которого агент Puppet начинает создание каталога желаемого состояния компьютера. Мы создадим два очень простых файла site.pp в двух средах, которые создают один и тот же файл на узле агента. Разница лишь в том, что они помещают в файл разный текст.

Первым файлом site.pp будет производственная среда по адресу:
/etc/puppet/code/environments/development/manifests/site.pp
Этот файл должен иметь следующее содержимое:

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Development Environment \n",
}

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

Этот манифест гарантирует, что файл присутствует в /tmp/example.txt и содержит текст "From The Development Environment" ("" добавляет новую строку в конце файла, что является хорошей практикой и останавливает отображение Puppet предупреждающего сообщения, когда его нет).

Второй манифест будет находиться в тестовой среде по адресу:
/etc/puppet/code/environments/testing/manifests/site.pp
Этот файл содержит:

file {'/tmp/example.txt':
 ensure  => present,
 mode    => "0644",
 content => "From The Testing Environment \n",
}

Это почти идентично файлу в среде разработки, с той лишь разницей, что текст в файле указывает на то, что он пришел из тестовой среды.

Оценка новой конфигурации марионетки из тестовой среды

По умолчанию узел агента будет синхронизироваться только со средой разработки. Сначала мы вручную дадим указание агенту Puppet синхронизироваться с главным сервером Puppet, а также создадим и применим site.pp, который мы создали в среде разработки.

Это делается с помощью следующей команды:

puppet agent --environment=production --test

Опция --test заставляет агента Puppet выполнять прогон каталога на переднем плане с подробным ведением журнала. Любые обновления или изменения будут применены к узлу.

Опция --environment=production предназначена для того, чтобы было понятно, что мы синхронизируемся из производственной среды. Обычно это настраивается в основной конфигурации агента Puppet и не обязательно включается в команду.

Когда вышеуказанная команда выполнена, мы получаем следующий вывод:

  Info: Using configured environment 'production'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Caching catalog for digital-2.net
  Info: Applying configuration version '1527680694'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/ensure: defined content as '{md5}59f9ce1d4aad5fd155db7ccc2478a93b'
  Notice: Applied catalog in 0.02 seconds

Этот вывод указывает на то, что файл /tmp/example.txt отсутствовал, поэтому агент Puppet создал его в соответствии с инструкциями в манифесте site.pp. При последующих запусках строк Notice: не будет, так как файл /tmp/example.txt существует с правильным содержимым.

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

Для того, чтобы протестировать и не зафиксировать новую конфигурацию, нам нужно выполнить следующую команду:

puppet agent --environment=testing --test --noop

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

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

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Info: Applying configuration version '1527683748'
  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content:
  --- /tmp/example.txt    2018-05-30 12:19:16.205774048 +0000
  +++ /tmp/puppet-file20180530-21610-8ipzur      2018-05-30 12:35:48.740982652 +0000
  @@ -1 +1 @@
  -From The Development Environment
  +From The Testing Environment

  Notice: /Stage[main]/Main/File[/tmp/example.txt]/content: current_value '{md5}59f9ce1d4aad5fd155db7ccc2478a93b', should be '{md5}abbb8f68df144a5673d
  62ae6c4a036ed' (noop)
  Notice: Class[Main]: Would have triggered 'refresh' from 1 event
  Notice: Stage[main]: Would have triggered 'refresh' from 1 event
  Notice: Applied catalog in 0.04 seconds

Наиболее интересными линиями здесь являются следующие:

  -From The Development Environment
  +From The Testing Environment

Они обозначают символом минуса ( - ) то, что изменяется, и символом плюс ( + ) то, на что изменяется. В данном примере это текст в файле.

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

Выявление ошибки

Новая конфигурация Puppet не всегда применяется без ошибок, и именно поэтому ее всегда следует тестировать перед применением к производственной системе. В этой ситуации мы принудительно допустим ошибку, допустив умышленную ошибку в файле тестирования site.pp. Мы попытаемся установить права доступа к файлу на 0944, что не является действительным разрешением и вызовет ошибку.

Теперь, когда мы запускаем:

  # puppet agent --environment=testing --test --noop

Мы увидим следующий вывод:

  Info: Using configured environment 'testing'
  Info: Retrieving pluginfacts
  Info: Retrieving plugin
  Info: Retrieving locales
  Info: Loading facts
  Error: Failed to apply catalog: Parameter mode failed on File[/tmp/example.txt]: The file mode specification is invalid: "0944" (file: /etc/puppetcode/environments/testing/manifests/site.pp, line: 1)

На следующем снимке экрана этот вывод показан в том виде, в котором он будет представлен в командной строке:

Марионетка укажет на любые ошибки, распечатав их красным цветом.

Цвета сразу же сообщают нам о том, что при попытке использовать новую конфигурацию Puppet из тестовой среды произошла бы ошибка. Однако, поскольку мы использовали опцию --noop, на рабочем сервере не было зафиксировано никаких ошибок.

Заключение

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