みなさんこんにちは! この記事では、Windowsサーバーの構成用にPuppetを構成する印象を共有したいと思います。
一般に、タスクは次のとおりでした。リモートサーバーを更新するためのパッチの自動配信およびインストールのプロセスを整理することです。 よく知られている構成マネージャーから選択しましたが、その主な要件はWindowsの高度なサポートです。 Puppetは、高いエントリーしきい値、プルアプローチ、Rubyの知識の必要性のために拒否することを決めたとすぐに言わなければなりません。 しかし、私は本当に何が起こったかを共有したいと思います。
はじめに
Puppetにはマスターエージェント通信モデル(アーキテクチャ)があり、ウィザードのオペレーティングシステムをWindowsにすることはできません。 Windowsエージェントを管理するには、ターゲットマシンに.msiインストーラーであるソフトウェアがインストールされている必要があります。
Puppetはホスト名で動作し、ウィザードとエージェント間の対話はHTTPSプロトコルを介して実行されます。これは、Apache Webサーバー(ウィザード用)などの依存関係があることを意味し、証明書とその設定との対話を避けることも不可能です。
テストインフラストラクチャ
- Puppet WizardをインストールするためのUbuntu 16.04 LTS仮想マシン。
- 実際には管理する必要があるWindowsターゲットマシン。
設置
インストールは、アーキテクチャコンポーネントの数に応じて、2つの部分で構成されます。
マスター
ウィザードのインストールについては、 ここで説明します 。 インストール中に起動しなかった唯一のことは、SSL証明書の再生成後にApacheの起動が停止したことです。
イベントログにアクセスすると、問題が明らかになります-構成ファイル/etc/apache2/sites-enabled/puppetmaster.confと同じ名前の証明書は存在しません。 入って、名前を修正します(私の場合は、ただのパペット)、それだけです。 ところで、ここでマスターの証明書を見ることができます-/ var / lib / puppet / ssl / certs
エージェント
Windowsエージェントをインストールするとき、何かがうまくいかない可能性があります。 最も重要なルールは、Puppetウィザードのバージョンは常にPuppetエージェントのバージョンと同等(またはそれ以上)でなければならないということです。
インストールプロセスの最初の段階で、インストーラーに含まれるものを確認できます。
これらのコンポーネントの多くについて詳しくは、 ドキュメントを参照してください 。 次に、ウィザードのアドレスを指定すると完了です。
すべてが成功したかどうかをどのように確認できますか? イベントビューアーに移動し、ソースがPuppetであるメッセージを確認します。 ウィザードとエージェントの互換性のないバージョンの前述の問題の例を以下に示します。
すべてがうまくいった場合、最後のステップはウィザードでエージェント証明書に署名することです。
puppet cert list --all cert sign <agent-hostname>
パペットマニフェストの例
# # , # , # class action::windows { file { 'c:\\Temp\\foo.txt': ensure => present, content => 'This is some text in my file' } } # , Windows class action::default { notify{ "Operating system $::operatingsystem not supported": } } # osfamily # case $::osfamily { 'windows': { include action::windows } default: { include action::default } }
ウィザードにマニフェストを適用するには: puppet apply <manifest-name>
。
エージェント: puppet agent --test
。
おわりに
前に書いたように、Puppetは主に管理へのプルアプローチを使用しているため、タスクに選択されませんでしたが、私の意見では、システムの安定性と年齢は多くの状況でより重要です。 さらに、プッシュアプローチにはmcollectiveがあります 。