Reiniciando o mysql utilizando o módulo puppetlabs / mysql?

Question

Eu tenho duas pastas - uma é 'public_modules' e a outra é 'private_modules'. Quando eu inicio uma nova máquina do Vagrant, a pasta 'public_modules' é preenchida com módulos, como descrito no meu Puppetfile (por uma questão de brevidade, estes são todos os módulos na puppetforge). 'private_modules' contém quaisquer modificações e configurações que eu preciso mudar para os módulos públicos. Ao usar o bibliotecário-fantoche, não preciso fazer o check-in desses módulos públicos nem confiar em submódulos git. Considere o seguinte arquivo de manifesto:

class drupaldb {
class { '::mysql::server':
    root_password => 'platform',
    override_options => { 'mysqld' => { 'max_connections' => '1024', 'bind-address' => '0.0.0.0' } }
}

mysql::db { 'drupaldb':
    user     => 'root',
    password => 'platform',
    host     => '%',
    grant    => ['SELECT', 'UPDATE', 'DELETE'],
}

service { 'mysql':
    ensure => running,
    enable => true,
    subscribe => File['/etc/mysql/my.cnf']
}
}

Provisionamento O Vagrant falhará porque o serviço mysql já foi definido no módulo público aqui:

class mysql::server::service {

if $mysql::server::real_service_enabled {
    $service_ensure = 'running'
} else {
    $service_ensure = 'stopped'
}

if $mysql::server::real_service_manage {
    file { $mysql::params::log_error:
      owner => 'mysql',
      group => 'mysql',
}
service { 'mysqld':
  ensure   => $service_ensure,
  name     => $mysql::server::service_name,
  enable   => $mysql::server::real_service_enabled,
  provider => $mysql::server::service_provider,
}
}

}

Então, o que eu fui incapaz de resolver é como instruir o mysql a reiniciar no final do meu módulo? Eu recorri a reiniciar o mysql através de um comando shell embutido no final do meu Vagrantfile, mas isso é certamente um hack.

Aqui está o módulo puppetlabs

    

Answer 1

Eu tive o mesmo problema e resolvi adicionando um parâmetro 'restart' à minha inicialização do mysql :: server.

class { '::mysql::server':
  override_options => $override_options,
  restart => true,
}

Isto diz ao módulo mysql para reiniciar o mysql sempre que algo mudar.

    

Answer 2

O que não entendo é por que você deseja reiniciá-lo? O módulo puppetlabs-mysql irá gerenciar todas as reinicializações necessárias após todas as alterações de configuração.

De qualquer forma, sua declaração de serviço não reiniciaria o MySQL, a menos que o arquivo my.cnf fosse alterado. Como todas as mudanças são feitas através do módulo puppetlabs-mysql, ele irá reiniciar o serviço, então não vejo o ponto em sua declaração.

Mas, sem entrar em razões por que você deseja fazer isso, sugiro que adicione o seguinte recurso no final do seu módulo:

notify { 'restart_mysql':
  notify  => Service['mysqld'],
  require => [ Class['::mysql::server'], ::Mysql::Db['drupaldb'] ],
}

Ou você pode fazer isso manualmente com exec:

exec { 'restart_mysql':
  cmd     => 'service mysqld restart',
  require => [ Class['::mysql::server'], ::Mysql::Db['drupaldb'] ],
}

    

Answer 3

Como o módulo agrupa o recurso service em uma classe conveniente, a maneira canônica de abordar isso é enviar um evento para essa classe.

File['/etc/mysql/my.cnf'] ~> Class['mysql::server::service']

É um pouco estranho, porque o recurso file também não está no escopo local. Normalmente ficaria assim

file { '/etc/mysql/my.cnf':
    ...
    notify => Class['mysql::server::service']
}