web-dev-qa-db-ja.com

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

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

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

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

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

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

ubuntudebianpuppetconfiguration-managementchef
28
daff

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

9
Perlchild

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

ensure => latest,

または

ensure=> "1.0.2",

最新/必要なバージョンを指定します。つまり.

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

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

無人アップグレードを実行すると、特にミッションクリティカルなパッケージ、カーネル、mysqlライブラリ、Apacheなどをアップグレードする場合は、少し怖くなります。特に、インストールスクリプトがサービスを再起動したい場合は特に注意してください。

22
Tom O'Connor

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

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

これをセットアップしたら（通常、必要なパッケージを上流のリポジトリからミラーリングして開始することができます）、Puppetの「ensure => latest」構文を使用して、すべてのマシンがリポジトリで最新であることを確認できます。

「ステージング」リポジトリを使用して、パッケージの更新バージョンを簡単に本番環境にロールアウトする前にテストできるようにするのが賢明です。これは、リポジトリテンプレートを使用してコードを複製することなく、Puppetで簡単に実行できます。

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

このアドバイスはすべて、Ruby gems、Python eggや、使用する可能性のある他のパッケージシステムに当てはまります。

私は少し書きました Puppetチュートリアル これは、Puppetをすばやく使い始めるのに役立つはずです。パッケージのバージョンを制御する最初のステップとしてPuppetを使用して、カスタムリポジトリ定義をマシンにデプロイできます。

18
John Arundel

Puppet/Chefはこの機能の候補となる可能性がありますが、システムに最新の状態everythingを維持するには、カスタムタイプまたはすべてのパッケージをリストする必要があります（libc6のような基本的なシステムライブラリを含む）ensure => latest。自動化されたパッケージ更新の特定のケースでは、cron-aptパッケージ。これも必要な処理を行います。

5
womble

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

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

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

5
Walter Heck

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

私はCfengine 3を使用して、いくつかのサーバーでこれを行います。自動更新するパッケージの明示的なリストを指定しているため、少し注意することなくallパッケージの更新を回避しています。これは非常に機能し、cfengine 3は非常に軽量です。

これが私のcfengine構成のpromiseスニペットです。

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

お役に立てれば。

4
Jonathan Clarke

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

2
SAnnukka

人形+ apt-daterを使用します。

2
ptman

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

1
Ken

セキュリティ更新

Ubuntu/Debian（またはRHELの場合はyum-cron）の堅牢な unattended-upgrades パッケージを設定するには、一般にAnsibleなどを使用するのが最も簡単だと思います/ CentOS）。 Puppet、Chef、その他のツールを使用できますが、ここではAnsibleについて説明します。

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

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

再起動がより複雑な場合、unattended upgradesからメールで通知され、/var/run/reboot-requiredも作成されるため、Ansible（または同様の）が適切なタイミングで再起動を管理できます（例：Webクラスターの再起動のローリング）またはDBサーバーがダウンタイムを回避するために、各サーバーが特定のTCPポートで続行する前に）使用可能になるのを待ちます。

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

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

一般的な更新

セキュリティ以外の更新は、通常の継続的な統合およびテストプロセスを実行して、問題が発生しないようにする必要があります。

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

0
RichVel