1

基本的に次のように動作するパペットのセットアップがあります。

  1. ユーザー「puppetdeploy」を作成します
  2. ユーザー「puppetdeploy」にすべてのテーブルへのアクセスを許可します
  3. 「puppetdeploy」を使用して、.sql ファイルからデータベースを作成および更新するスクリプトを実行します
  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-module の以降のバージョンでは、これは機能しなくなりました。各許可の名前は「[user]/[table]」の形式にする必要があり、2 つ以上の mysql_grants に同じ名前を付けることは許可されていません。

puppetlabs-mysql 3.0.0 でこの制限を回避する方法はありますか、または一時的な mysql ユーザーを処理するより良い方法はありますか?

4

1 に答える 1

0

問題は、そのようなワークフローが Puppet のパラダイムに適合しないことです。Puppet マニフェストはスクリプトではありません。これは、Puppet に適用させたい状態の説明です。もちろん、多くの場合、遷移を正しく行うにはシリアル化された構成手順が必要ですが、Puppet が同期しなければならない 1 つの明確な状態がすべてに必要であり、この状態を維持する必要があります。

同じ Puppet トランザクション中に複数の異なる状態を取るために 1 つ以上のリソースを必要とするすべてのワークフローは問題を引き起こし、通常は何らかのハックによって解決されます。

mysql_grant特定のシナリオでは、マニフェストの抜粋で概説されているすべてのステップを実行する、Puppet がデプロイして実行するスクリプトを優先して、タイプを放棄するのが最善の場合があります。これは非常に Puppet らしいことではありませんが、Puppet に同じリソースを 1 つの状態から別の状態にジャグリングさせようとしないため、はるかにクリーンです。

さらに良いのは、Puppet が実際の管理者アカウントの権限を使用できるようにすることです。

妥協案として、Puppet がフォローアップ トランザクションの開始時にすべての GRANT が適切であると判断できるようにするカスタム ファクトを追加し、その後ユーザーを削除することができます。

if $grants_are_deployed {
    mysql_grant { 'revoke_all_for_puppetdeploy': ... }
else {
    mysql_user { 'puppetdeploy@localhost': }
}
于 2014-11-13T12:47:35.973 に答える