パペットで管理すべきでないものは何ですか?
私は一般に構成管理を通じて自分のやり方を学び、特にそれを実装するためにパペットを使用していますが、システムのどの側面がパペットで管理されるべきではないのでしょうか? 例として、通常、システムをpuppetの管理に貸す前に、ホスト名がすでに設定されていることを当然のことと考えています。少なくともpuppetmasterに到達するために使用されるネットワークでは、基本的なIP接続が機能している必要があります。puppetを使用してDNSゾーンファイルを自動的に作成するのは魅力的ですが、DNSリバースポインターは、Thingを起動する前に既に配置されている必要があります。証明書は面白くなります。 したがって、PuppetからIP構成を除外する必要がありますか?または、パペットを初めて起動する前に設定する必要がありますが、それでもパペットでIPアドレスを管理する必要がありますか?複数のIPを備えたシステム(WAN、LAN、SANなど)はどうですか? 何についてのIPMI?すべてではありませんが、ほとんどをipmitoolで設定すると、コンソールアクセス(物理、シリアルオーバーLAN、リモートKVMなど)を取得せずに済むため、Puppetで自動化できます。しかし、パペットエージェントを実行するたびにその状態を再確認することは私にとってはクールではありません。システムへの基本的なライトアウトアクセスは、他に何もする前に持っておきたいものです。 もう1つのストーリーは、更新プログラムのインストールに関するものです。私はこの特定のポイントには行きません。SFに関する多くの質問と、異なるシステム管理者の間の多くの異なる哲学が既にあります。私自身は、操り人形に物事を更新させないようにし(例のみensure => installed)、既に慣れているため手動で更新を行うことにしました。ミックス)。 これらは、今思い浮かんだほんの数例です。パペットから手の届かないところに残すべきシステムの側面はありますか?または、別の言い方をすれば、プロビジョニング時に設定する必要があるものと、システムで「静的に」設定されるものと、一元化された設定管理によって処理されるものとの境界はどこにありますか?