Chef / Puppetを定期的に実行することの長所/短所は何ですか？
私はいつも彼らが定期的にPuppetを実行していた場所で働いていました。そのため、変更の配布は簡単でその場で行われました。新しいチームでは、Chefエージェントを定期的に実行すると眉をひそめます。彼らはそれをbootstrap OSに使用し、それを強制終了するだけです。定期的に実行せずにChefのような構成管理ツールを使用する理由がわかりません。基本的なシェルスクリプトを介して実行-xyzソフトウェアをインストールし、構成ファイルをコピーして、サービスを再起動します。
彼らは、コードがべき等であるかどうかわからないため、本番環境で定期的に実行するのは危険すぎると言います。
私の質問は次のとおりです。
- ブートストラップのためだけにオーケストレーションツールを使用している人は何人いますか？路地でブガッティを20mphで運転するようなものではありませんか？
- スケールアップするときに、これを定期的に実行する際に問題が発生しますか？どのように処理しますか？ （私が知っている1つの方法は、エージェントをソロモードで実行し、Puppet/Chefサーバーを圧倒するのではなく、複数の同時ダウンロードを処理できるリポジトリ/アーティファクトからクックブックをダウンロードさせることです）。
- チームにコードをべき等に修正し、定期的にエージェントを実行するように促すにはどうすればよいですか？または、Chefからbashのような単純なものに移動して、コードの保守/書き込みのオーバーヘッドを削減します。
- 私たちがツールを本来の使用方法で使用していないと言っているのは正しいですか？
- 私はここで何かを見逃している/見落としていますか？
ブートストラップのためのオーケストレーション
プロセスのこの部分に実際に焦点を当てているTerraformのようなツールがあります。また、頻繁に再実行する必要のないアドホックタスクにもansibleを使用します。
ただし、一般的には、少なくとも1時間ごとに構成管理を実行することをお勧めします。アクセスの許可または削除は、これらのメカニズムを介して行われることが多く、更新を遅らせると、コンプライアンスまたはユーザビリティの問題が発生する可能性があります。ある大きなショップでは、パペットを2つに分割して、アクセス制御の更新を処理する「シャドウパペット」を壊さずにアプリ固有のものを一時停止し、「切断できなかった」ようにしました。
定期的に実行することによる問題
あなたが悪いレシピを書くならば、あなたは非常に速くすべての生産を破壊することができます。役割がQAにリリースされ、ステージングに進む前に検証され、製品に進む前に再検証されるプロセスがあります。 Chefにはテストメカニズムが組み込まれています。同様の手法を他の手法でも使用できます。
定期的に実行することを奨励する方法
私は最初にカーペットの下でブラシをかけられている問題に焦点を合わせます。レシピを頻繁に実行しないと、OSやアプリの変更が原因でレシピが機能しなくなったときに気付かないでしょう。
次に、必要に応じてどこでも非常に迅速に変更を加えることができることを述べておきます。 chefの実行間隔は、変更が環境全体に伝播するのを待つことができる最大時間である必要があります。
あなたは正しいですか？
主に。それが彼らにとって十分に機能する場合、彼らは何も変更する必要がないと思うかもしれません。価値を示し、人々にそれを現実のものにするために、デモを考え出す必要があるかもしれません。または、組織が成熟して、教えていることを処理できるようになるまで待つ必要があるかもしれません。
何が足りないの？
考慮していないと思われる主なことは、パフォーマンスへの影響の可能性です。アプリがバックグラウンドで実行されているものに非常に敏感である場合、chefの実行中にスループットが低下したりレイテンシが高くなったりすることがあります。このような場合は、レシピを調整するか、オフピーク時にのみ実行する必要があります。
私が見たもう一つのことは、メモリの枯渇です。シェフが機能しなくなるまで、アプリは徐々にメモリをかみ砕きます。うまくいけば、あなたはメモリレベルを監視し、シェフがこの種のものを捕まえるために働いているかどうかを監視しています。
パフォーマンスとメモリを超えて、信頼できる本番システムを構築する方法について多くのことを説明しているRelease Itのような本を読むことをお勧めします。