puppetlabs-mysq (v3.0.0): временный пользователь

Question

у нас есть установка кукольный, которая в основном работает так:

1. Создать пользователя "puppetdeploy" доступ
2. Grant ко всем таблицам для пользователя "puppetdeploy"
3. Запускает скрипты, которые создает и обновляет базы данных из .sql файлов, используя «» puppetdeploy
4. Отозвать весь доступ к пользователю «puppetdeploy»

.pp файл выглядит примерно так:

mysql_user { 'puppetdeploy@localhost': 
    ensure => 'present', 
    password_hash => '*****',   
}-> 
mysql_grant { 'grant_all_for_puppetdeploy': 
    ensure  => 'present', 
    options => ['GRANT'], 
    privileges => ['ALL'], 
    table  => '*.*', 
    user  => 'puppetdeploy@localhost', 
} 
#... execute scripts to import bunch of .sql files using mysql user 'puppetdeploy' 
mysql_grant { 'revoke_all_for_puppetdeploy': 
    options => ['REVOKE'], 
    privileges => ['ALL'], 
    table  => '*.*', 
    user  => 'puppetdeploy@localhost', 
} 

В более поздних версиях MySQL-модуля это больше не работает, как имя для каждого гранта должны быть в формате "[пользователь]/[таблица], и Мне не разрешено иметь одно и то же имя для двух или более mysql_grants.

Есть ли способ обойти это ограничение в puppetlabs-mysql 3.0.0, или есть ли лучшие способы борьбы с временными пользователями mysql?

Answer 1

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

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

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

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

В качестве компромисса вы можете добавить custom fact, что позволит Puppet определить, что все GRANTs находятся в порядке в начале последующей транзакции и затем удаляют пользователя.

if $grants_are_deployed { 
    mysql_grant { 'revoke_all_for_puppetdeploy': ... } 
else { 
    mysql_user { 'puppetdeploy@localhost': } 
}