Ansibleと比較したPuppetの制限は何ですか？

PuppetとAnsibleの違い、特にAnsibleと比較してどのようなPuppetの制限があるのか​​を理解したいと思います。

Puppetでできないことはありますが、Ansibleではできますか？言い換えれば、なぜ一部の人々がPuppetからAnsibleに移行するのでしょうか？

もちろん、Puppet、Ansible、Chefにはそれぞれ長所と短所があり、ここにもお気に入りのツールを追加します。だから、私は意見から離れて、事実としてAnsibleで素晴らしいことを共有しようとします。

Ansibleを他のものよりも優れたものにする主な機能は、ターゲットノードで実行されているカスタム/追加エージェントに依存する必要がなく、代わりにssh接続のみに基づいていることです。はい、まだsshサーバー、Python、およびノー​​ド上のPythonライブラリが必要です。選択したディストリビューション（または幸運なことに、いくつかのWindowsノードがあります）が同梱されていない場合は、少しなりますブートストラップに苦痛。しかし、それはありそうにないことであり、あなたのディストリビューションについてもう一度考えさせるかもしれません。

これにより、監視が簡単になり、追加のリソースを消費したり、システムがデーモンを常にルートとして実行するように強制したりせず、一般的にUNIX哲学の内部で気分が良くなります。Chefにはchef-solo、Puppetをマスターレスで実行できますが、クローンとフックを介してそれぞれ「反対方向」に動作します。Ansibleでは、ソースリポジトリのマージにより、ジェンキンス、gitマスター、またはたとえばRundeckのような他のツールであっても、私たち全員が慣れている方法で展開をトリガーできます。

いいえ、PuppetからAnsible（またはその逆）に移行する人々は、どちらのツールでも達成できることと達成できないこととは何の関係もありません。Puppet / Chef / Ansible-それは主に好みの問題です。

たとえば、AnsibleはPythonに基づいており、Python開発者は通常、それ（DSLを学習する必要はありません）、またはRuby（Chefの場合）に慣れています。Python開発者がAnsibleを拡張するのも簡単です。

しかし、本質的には、あなたが達成できることに関して、それらはすべて非常に似ています。一部の分野には相対的な長所があり、他の分野には短所がありますが、通常、それらの選択はチームのスタイル/文化/好みによって行われます。

Puppet 4.0までは、設計上の選択であったPuppetでアクションを具体的に注文するのが困難であったため、複数のサーバーまたはサービスにまたがるアプリケーションを調整する簡単な方法はありませんでした。Ansibleは、特に複数のサーバーにまたがるステップのオーケストレーションと順序付けが優れていました。これは、ステップの順序が間違っていると、最終的に一貫性が得られるまでそれらのステップを繰り返すことで回復不能なエラーが発生する可能性があるアプリケーションで特に重要でした。

それはもはや問題ではないので、区別は主に好みに基づいています。