パペットで管理すべきでないものは何ですか？

私は一般に構成管理を通じて自分のやり方を学び、特にそれを実装するためにパペットを使用していますが、システムのどの側面がパペットで管理されるべきではないのでしょうか？

例として、通常、システムをpuppetの管理に貸す前に、ホスト名がすでに設定されていることを当然のことと考えています。少なくともpuppetmasterに到達するために使用されるネットワークでは、基本的なIP接続が機能している必要があります。puppetを使用してDNSゾーンファイルを自動的に作成するのは魅力的ですが、DNSリバースポインターは、Thingを起動する前に既に配置されている必要があります。証明書は面白くなります。

したがって、PuppetからIP構成を除外する必要がありますか？または、パペットを初めて起動する前に設定する必要がありますが、それでもパペットでIPアドレスを管理する必要がありますか？複数のIPを備えたシステム（WAN、LAN、SANなど）はどうですか？

何についてのIPMI？すべてではありませんが、ほとんどをipmitoolで設定すると、コンソールアクセス（物理、シリアルオーバーLAN、リモートKVMなど）を取得せずに済むため、Puppetで自動化できます。しかし、パペットエージェントを実行するたびにその状態を再確認することは私にとってはクールではありません。システムへの基本的なライトアウトアクセスは、他に何もする前に持っておきたいものです。

もう1つのストーリーは、更新プログラムのインストールに関するものです。私はこの特定のポイントには行きません。SFに関する多くの質問と、異なるシステム管理者の間の多くの異なる哲学が既にあります。私自身は、操り人形に物事を更新させないようにし（例のみensure => installed）、既に慣れているため手動で更新を行うことにしました。ミックス）。

これらは、今思い浮かんだほんの数例です。パペットから手の届かないところに残すべきシステムの側面はありますか？または、別の言い方をすれば、プロビジョニング時に設定する必要があるものと、システムで「静的に」設定されるものと、一元化された設定管理によって処理されるものとの境界はどこにありますか？

一般的なルール：構成管理を使用している場合、可能な構成のあらゆる側面を管理します。集中化すればするほど、環境を簡単にスケールアウトできます。

特定の例（質問から引用、すべて「これがあなたがそれを管理したい理由」の物語）：

IPネットワーク構成

確かに、マシンをラックに落とす前にアドレス/ゲートウェイ/ NSを構成しました。残りの設定を行うためにpuppetをどのように実行しなかったのですか？

しかし、今度は別のネームサーバーを環境に追加し、すべてのマシンを更新する必要があると言ってください-構成管理システムにそれを行わせたくありませんか？

または、会社が買収され、新しい親会社が番号付けシステムに合わせて192.168.0.0/24のアドレス指定を10.11.12.0/24に変更することを要求したとします。

または、突然大規模な政府契約を取得します-ただキャッチしなければならないのは、今すぐ IPv6をすぐに見直す必要があるか、取り引きが吹き飛ばされることです....

ネットワーク設定は管理したいものです...

IPMI設定

IPアドレスの場合と同様に、マシンをラックに設置する前にこれを設定するはずです-機能を備えたマシンでIPMI、リモートコンソールなどを有効にするのは、常識です。あまり変わらない...

...上記のIP構成で述べた仮想的な買収まで-それらの192.168-netアドレスを無効にすることを余儀なくされた理由は、それが新しい企業の大君主によるとIPMIランドであり、すべてのIPMIカードを更新する必要があるためです。今、彼らは誰かの予約されたIPスペースを踏みにじるつもりだからです。

ここでは少しストレッチがありますが、あなたが言ったように、すべてをで管理できますipmitool。Puppetにツールを実行させ、他のすべての作業を行っている間に構成を確認してみませんか？つまり、何も傷つけないので、IPMIも含めることができます...

更新情報

ソフトウェアの更新はより灰色の領域です-私の組織では、このためにパペットを評価し、それが「非常に不足している」ことがわかったためradmind、この目的で使用します。しかし、Puppetがradmindを呼び出せない理由はありません-実際、構成管理のためにPuppetに移行する場合/その場合、まさにそれが起こるのです！

ここで重要なことは、すべての更新を標準的な方法（組織全体の標準またはプラットフォーム内の標準）でインストールすることです-徹底的にテストしている限り、Puppetが更新プロセスを起動しない理由はありませんPuppetが混乱しないようにするためのすべて。
Puppetが単独で良い仕事をすることができないと判断した場合、Puppetがこのタスクにより適したツールを呼び出せない理由もありません...

車輪を再発明しないでください。

はい、50個のPuppet仮想ユーザーリソースを用意し、モジュールで必要に応じてそれらを実現することができます...可能であれば、LDAPを使用します。

苦い経験から話しています。まだldapはオプションではありませんが。

他の例は、単にDNSを使用するのではなく、hostsファイルをプッシュすることです。

• Puppetはオーケストレーションシステムではありません。特に：
  • PuppetはVMオーケストレーションにはあまり適していません。VMには独自のライフサイクルがあり、それを尊重する必要があるためです。
  • Puppetは、アプリケーションのリリース管理/複雑なアップグレードにはあまり適していません。スタンドアロンのパペットの実行はこのために悪用される可能性がありますが、少なくともPuppetが制御するのではなく、ラッパースクリプトまたは人間のロボットです。
• Puppetは優れたユーザー管理システムではありません（すべてのユーザーエントリ、削除されたユーザーを管理する必要があります。別のソリューションを見つけてください）
• Puppetは適切な構成データベースではありません（何らかの外部データベース、およびENC、Hiera、または類似の接着剤の使用を検討してください）

もちろん、これらすべてをPuppetで実行できます。時にはハンマーを置いて、レンチを探しに行く必要があります。

ただし、Puppetは、マシンの基本構成の維持、およびVMの実行とオーケストレーションのリリース、ユーザー管理などを可能にするツールのインストールに非常に優れています。

私はほとんどvoretaq7に同意していますが、いくつか注意点があります。

• システムがDHCPを使用しない限り、パペットでIPアドレスを設定することはめったにありません（ほとんどの大規模な「クラウド」プロバイダーがこれを行うと想定しています）。私はパペットでネットワーク構成を壊したが、ノードがパペットマスターに連絡する方法がないためにパペットでそれらを修正できなかった状況がありました。

• 更新管理はシステムツールの手にあると私は確信しており、パペットを栄光のcronとして使用して改善することはできません。

私の場合、最小限のシステム構成（Ubuntu）を読み込むブートストラップスクリプトがあります。Ruby、Rubygems、build-essential、gitなどです。私のPuppetマニフェストはバージョン管理下に置かれ、リポジトリを複製します。そこから、私のブートストラップスクリプトhostname --shortは有効な仮定を行い、を試みpuppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).ppます。

質問に答えるには：

• 私のスクリプトは基本的なネットワーク接続（DNS、IP）を想定しており、管理も変更もしません。
• 私のスクリプトは、マシンのIDが正しいと仮定し、変更しないでください。
• 私のスクリプトは、Ruby / Rubygems / Gitが存在することを前提としていますが、後で管理します。

ネットワーク設定にパペットを使用する必要はないと思います。通常は一度設定されたものです。また、IPやMAC、またはパペットによってもたらされる類似の何かに間違いがある場合、多少のがらくたを得ることができます。