構成管理ツール（Puppet、Chef）は、インストールされたパッケージを最新の状態に保つことができますか？

これはおそらく、構成管理ツールを既に実行しているユーザーにとっては簡単な質問です。PuppetやChefなどの構成管理ツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？

主にDebianとUbuntuに基づいた多数のサーバーを実行するとします。構成管理ツールを使用すると、セキュリティの更新やバグ修正が行われたときにリポジトリからインストールされたパッケージを簡単に更新できますか？

現在、システムにセキュリティ更新プログラムを自動的にインストールさせるために「無人アップグレード」を実行していますが、それでもサーバーに接続してaptitude update && aptitude safe-upgrade頻繁に実行する必要があります。当然、これは退屈で退屈でエラーが発生しやすくなります。

PuppetやChefなどのツールは、インストール済みパッケージを最新の状態に保つための適切なアプローチですか？これらのツールを使用aptitudeして、15台のサーバーで手動または同等のツールを実行しないようにしていますか？これらの質問に対する答えは「もちろんです！」です。

しかし、この特定のユースケースに関する詳細情報はどこで入手できますか？PuppetやChefを詳しく調べる時間はまだありません。サンプルのクックブックまたはクラスでは、sshなどの特定のパッケージをインストールするというささいな例しか示していません。公式のドキュメント以外に、推奨するリソースはありますか（もちろん、もしあれば、どのツールが自分に適しているかがわかったらドキュメントを勉強します）。

Puppet（シェフもそうだと思います）は、apt-get / yumソフトウェアリポジトリと連携しています。どのパッケージが利用可能かを把握するという重い作業を行うensure => latestため、Ubuntu / CentOS / Debianなどで機能します。適切なファイルを正しくセットアップしている限り（/etc/apt/sources.listなど）。

あなたは人形でそれをすることができます、あなたはどちらかをします：

ensure => latest,

または

ensure=> "1.0.2",

最新/必須バージョンを指定します。すなわち

package { apache2: ensure => "2.0.12-2" }
package { apache2: ensure => latest }

これは、少なくとも、すべてのシステムで同じバージョンを指定できること、およびサーバーが（潜在的に危険な）自動的に自分自身をアップグレードするのを防ぐことを意味します。私はこの方法を多くのサイトの実稼働で使用しましたが、非常にうまく機能します。

特にミッションクリティカルなパッケージ、カーネル、mysqlライブラリ、apacheなどをアップグレードしている場合は、無人アップグレードを実行するのが少し怖いです。特に、インストールスクリプトでサービスを再起動する必要がある場合は！

これはおそらく間違った質問だと思います。確かに、PuppetやChefなどの構成管理ツールを使用してインフラストラクチャを維持することは、すべてを手動で行うことから大きく飛躍します。パッケージのバージョンを最新の状態に保ち、同期を保つという問題は、これらのツールが直接解決する問題ではありません。これを適切に自動化するには、パッケージリポジトリ自体を管理下に置く必要があります。

私がこれを行う方法は、特定のサイトに関心のあるパッケージを含む専用のYumリポジトリ（Redhat / Fedora / CentOS用、Debian / Ubuntu用のAPTリポジトリ）を維持することです。これらは通常、アプリケーション自体（Ruby、PHP、Apache、Nginx、ライブラリなど）とセキュリティが重要なパッケージの依存関係になります。

この設定が完了したら（通常、アップストリームリポジトリから必要なパッケージをミラーリングするだけで開始できます）、Puppetの "ensure => latest"構文を使用して、すべてのマシンがリポジトリで最新になるようにします。

'ステージング'リポジトリを使用して、パッケージの更新されたバージョンをテストしてから実稼働環境にロールアウトすることをお勧めします。これは、リポジトリテンプレートを使用することで、コードの重複なしにPuppetで簡単に実行できます。

パッケージのバージョン管理を自動化すると、さまざまなOSディストリビューション、バージョン、およびマシンアーキテクチャの複数のリポジトリとパッケージを維持するのに非常に時間がかかり、あらゆる種類のあいまいな問題と非互換性が生じる可能性があるため、すべての運用システムを同期することを強くお勧めします。

このアドバイスはすべて、Ruby gem、Python egg、および使用可能な他のパッケージシステムに等しく適用されます。

Puppetをすばやく起動して実行するのに役立つ小さなPuppetチュートリアルを作成しました。パッケージバージョンを制御するための最初のステップとしてPuppetを使用して、マシンにカスタムリポジトリ定義をデプロイできます。

Puppet / Chefはこの機能の有力な候補ですが、システム上のすべてを最新の状態に保つには、カスタムタイプか、すべてのパッケージ（libc6などの基礎となるシステムライブラリを含む）をリソースとしてリストする必要がありますensure => latest。自動化されたパッケージ更新の特定のケースでは、cron-aptパッケージを調べたい場合があります。

この質問は古いものですが、当時存在していた回答が利用できなかったため、最新の方法で回答したいと思いました。

人形やシェフを使用している場合は、mcollectiveを調べてください。サーバーのグループにコマンドを送信できるpuppetlabsの人々による非常に素晴らしいツールです。http://docs.puppetlabs.com/mcollective/

また、任意の数のサーバーでapt更新を行うために使用できるaptプラグインもあります。http： //projects.puppetlabs.com/projects/mcollective-plugins/wiki/AgentApt

これはあなたの元の質問には少し遅れていると思いますが、ここでは「絶対に遅れない」という精神に基づいています。

Cfengine 3を使用して、複数のサーバーでこれを実行します。自動更新用のパッケージの明示的なリストを指定するため、少し注意することなくすべてのパッケージを更新することは避けます。それは素晴らしく機能し、cfengine 3は非常に軽量です。

cfengine構成からのプロミススニペットを以下に示します。

    packages:
            "apache2"
                    package_method => "apt",
                    package_policy => "update";

お役に立てれば。

私はジョナサンに同意します。Cfengine 3のアプローチは、低レベルで再コーディングすることなくパッケージ管理のすべての側面を制御できるため、優れています。

puppet + apt-daterを使用します。

Ubuntu / Debianシステムを管理および監視するように設計されたCanonicals Landscapeなどのパッケージ管理ツールも使用できます。複数のシステムを管理し、それらを同時に更新し、いくつかの基本的な監視機能を提供します。

セキュリティアップデート

一般的に、Usbun / Debian（またはRHEL / CentOS）向けの堅牢な無人アップグレードパッケージをセットアップするには、Ansibleなどを使用するのが最も簡単だと思いますyum-cron。Puppet、Chef、または他のツールを使用できますが、ここではAnsibleについて説明します。

• unattended-upgrades 必要に応じて、セキュリティ以外の更新を同時に行うことができます。これは、Ansibleを介して毎日コマンドを実行するよりもはるかに簡単です。

• unattended-upgrades毎日自動更新を処理し、通常はセキュリティの更新のみに制限されます（安定性を高めるため）。更新後にサーバーの再起動が必要な場合、このツールは特定の時間に自動再起動できます。

再起動がより複雑な場合unattended upgradesは、メールで送信できます。また/var/run/reboot-required、Ansible（または同様の）が適切なタイミングで再起動を管理できるように（たとえば、WebサーバーまたはDBサーバーのクラスターのローリング再起動によりダウンタイムを回避し、続行する前に特定のTCPポートで使用可能になるサーバー）。

Ubuntu / Debianシステム用のjnv.unattended-upgradesのようなAnsibleロール、またはRHEL / CentOSもカバーする（そしてSSH構成を強化する）シンプルだが効果的なgeerlingguy.securityを使用できます。

迅速なセキュリティ更新がそれほど重要でない場合は、重要度の低いサーバーで最初にテストプロセスを実行し、unattended-upgradeテストで問題がないことが示されたらコマンドを実行できます-ただし、サーバー指向のセキュリティ修正が問題を引き起こすことは非常にまれです経験。

一般的な更新

セキュリティ以外の更新は、物事が壊れないようにするために、通常の継続的な統合とテストのプロセスを経る必要があります。

aptitude safe-upgrade過去にサーバーで深刻な問題が発生するのを見てきましたので、これを自動的に実行しないのが最善ですが、セキュリティの更新は一般に非常に安全です。