人形で管理すべきでないものは何ですか？
私は一般的に構成管理を通じて自分の方法を学び、 puppet を使用してそれを具体的に実装しています、そして、もしあれば、システムのどの側面をすべきか疑問に思っていますない人形で管理されますか？
例として、通常、システムをパペットの管理に貸す前にホスト名がすでに設定されていることを当たり前としています。少なくとも操り人形マスターに到達するために使用されるネットワーク上で、基本的なIP接続が機能している必要があります。 puppetを使用してDNSゾーンファイルを自動的に作成するのは魅力的ですが、DNSリバースポインターは、起動する前に既に配置されている必要があります。そうでないと、証明書がおかしくなるでしょう。
それでは、人形からIP構成を除外する必要がありますか？または、puppetを初めて起動する前に設定しますが、それでもpuppetでIPアドレスを管理しますか？複数のIPを持つシステム（WAN、LAN、SANなど）についてはどうですか？
[〜＃〜] ipmi [〜＃〜] はどうですか？すべてではないにしても、そのほとんどを ipmitool で構成することで、コンソールアクセス（物理、LAN上のシリアル、リモートKVMなど）から解放され、パペットで自動化できます。しかし、パペットエージェントを実行するたびにその状態を再確認することは、私にはクールに聞こえません。システムへの基本的なライトアウトアクセスは、他に何をする前に持っておきたいものです。
別の全体的な話は、アップデートのインストールについてです。私はこの特定のポイントに行くつもりはありません。SFについてはすでに多くの質問があり、さまざまなシステム管理者の間にはさまざまな哲学があります。私自身、人形に物事を更新させないことに決めました（例：ensure => installed）そして、これまでと同じように手動で更新を行います。このタスクの自動化は、人形に自信があるとき（たとえば、ミックスに MCollective を追加することにより）後日になります。
これらは私が今思いついたほんの数例です。人形の手の届かないところに残すべきシステムの側面はありますか？または、別の言い方をすると、プロビジョニング時にセットアップする必要があるものとシステムで「静的に」構成する必要があるものと、集中管理された構成管理によって処理されるものとの間の境界はどこにあるのでしょうか。
一般的なルール：構成管理を使用している場合は、構成のあらゆる側面を管理できます。集中化すればするほど、環境のスケールアウトが容易になります。
特定の例（質問から引用、すべて「これがあなたがそれを管理したい理由です」という説明）：
IPネットワーク構成
確かに、それをラックに落とす前に、マシンのアドレス/ゲートウェイ/ NSを構成しました。つまり、設定の残りの部分を実行するためにパペットをどのように実行しないのですか？
しかし、今度は環境に別のネームサーバーを追加し、すべてのマシンを更新する必要があるとしましょう-構成管理システムにそれを実行させたくないですか？
または、あなたの会社が買収され、192.168.0.0/24から10.11.12.0/24に変更する新しい親会社の要求に合わせて、彼らのナンバリングシステムに。
または、突然大規模な政府契約を締結しました-唯一の問題は、IPv6を有効にする必要があることですRIGHT FREAKIN 'NOWまたは取引が吹き飛ばされた...
ネットワーク構成は管理したいもののようです...
IPMI設定
IPアドレスの場合と同じように、マシンをラックに配置する前にこれを設定していると思います-機能を持つすべてのマシンでIPMIやリモートコンソールなどを有効にすることは常識であり、これらの構成ではあまり変わらない...
...上記のIP構成で述べた架空の買収まで-これらの192.168ネットアドレスを空にすることを余儀なくされた理由は、それが新しい企業の支配者によるとIPMIランドであり、すべてのIPMIカードを更新する必要があるためです誰かが予約したIPスペースを踏みにじるからです。
わかりました、ここでは少し伸びていますが、あなたが言ったように、すべてはipmitoolで管理できます。それで、Puppetがツールを実行して、他のすべてのことを実行している間に構成を確認しないでください。つまり、何も害を及ぼさないので、IPMIを含めることもできます...
アップデート
ソフトウェアの更新はより灰色の領域です-私の組織では、これについてパペットを評価し、それが「まったくない」と判断したため、radmindをこの目的で使用します。 Puppetがradmindを呼び出せない理由はありません-実際のところ、構成管理のためにPuppetに移行する場合と移行するのは、まさにそのようなことです。
ここで重要なことは、すべての更新を標準的な方法（組織全体の標準、またはプラットフォーム内の標準のいずれか）でインストールすることです-十分にテストした限り、Puppetが更新プロセスを起動してはならない理由はありません。 Puppetが何も台無しにしないようにするためのすべて。
Puppetだけでは適切に機能しないと判断した場合、Puppetがこのタスクにより適したツールを呼び出せない理由もありません...
車輪を再発明しないでください。
はい、50の仮想ユーザーリソースを用意して、必要に応じてモジュールで実現することができますが、可能であればLDAPを使用してください。
私は苦い経験から話します。ここではまだldapはオプションではありませんが。
別の例は、DNSだけを使用するのではなく、hostsファイルをプッシュすることです。
- Puppetはオーケストレーションシステムではありません。特に：
- VMには尊重されるべき独自のライフサイクルがあるため、PuppetはVMオーケストレーションにはあまり適していません。
- Puppetは、アプリケーションリリース管理/複雑なアップグレードにはあまり適していません。スタンドアロンのパペット実行がこれに悪用される可能性がありますが、少なくともパペットが制御しているのではなく、ラッパースクリプトまたは人間のロボットで問題ありません。
- Puppetは優れたユーザー管理システムではありません（削除するには、削除されたユーザーであっても、everyユーザーエントリを管理する必要があります。別の解決策を見つけてください）
- Puppetは適切な構成データベースではありません（ある種の外部データベースと、ENC、Hiera、または同様の接着剤の使用を検討してください）
もちろん、Puppetを使用してこれらすべてのことを実行できます。時々、ハンマーを置いて、レンチを探しに行く必要があります。
ただし、Puppetはマシンの基本構成の維持、およびVMおよびリリースオーケストレーション、ユーザー管理などを可能にするツールをインストールすることで非常に優れています。
私はほとんどvoretaq7に同意しますが、いくつかの警告があります。
システムがDHCPを使用しない限り、パペットでIPアドレッシングを構成することはめったにありません（ほとんどの大規模な「クラウド」プロバイダーがこれを行うと想定しています）。私はパペットでネットワーク構成を壊した状況がありましたが、ノードがパペットマスターに連絡する方法がなかったためパペットでそれらを修正できませんでした。
更新管理はシステムツールの手に委ねられていると私は確信しています。人形を名誉あるcronとして使用して改善することはできません。
私の場合、最小限のシステム構成（Ubuntu）をロードするbootstrapスクリプト：Ruby、Rubygems、build-essential、gitなど）があります。私のPuppetマニフェストはバージョン管理下にあり、私は単にリポジトリのクローンを作成します。そこから、my bootstrapスクリプトは_hostname --short_が有効であると想定し、puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).ppを試行します。
あなたの質問に答えるには：
- 私のスクリプトは基本的なネットワーク接続（DNS、IP）を想定しており、それを管理または変更しません。
- 私のスクリプトは、マシンのIDが正しいと想定し、それを変更しません。
- 私のスクリプトは、Ruby/Rubygems/Gitが存在することを前提としていますが、do後で管理します。
ネットワーク設定に人形を使う必要がないと思います。通常は一度設定したものです。また、IPやMAC、または人形によってもたらされる類似のものに間違いがある場合は、がらくたが発生する可能性があります。