複数のマシンでaptを効率的に管理するにはどうすればよいですか?


11

puppetを使用して約30のUbuntuサーバーを管理しています。パッケージを最新の状態に保つためのアプローチとして、cron-aptとapticronへの多くの参照を見てきましたが、プロセスを一元管理する方法を見つけることができませんでした。cront-apt / apticronでは、各ホストにログインしaptitude updateて実行し、更新を実行する必要があります。コアパッケージが更新されるたびに、30台すべてのマシンからのレビュー通知は言うまでもありません。

より良い方法が必要です。助言がありますか?

回答:


3

風景はあなたに興味があるかもしれません。これは大規模なUbuntuの展開を管理するための「公式」管理ツールであり、Canonicalはおそらくその使用にお金を払うことに非常に熱心です。

再編集:

まず、免責事項。DebianやUbuntuでミラーリングを使用したことがないので、ソフトウェアに精通していません。

第二に、apt-mirrorは「重すぎる」ソリューションになると思われます。元のアイデアは、更新プログラムを展開するために別のテストマシン(またはテスト環境、おそらく仮想マシン)を用意するというものでした。更新のパフォーマンスに満足したら、パッケージを「デプロイ」ミラーにプル/プットします(公式ソースからのローカルミラーと、デプロイしたいアップデートのみのセカンダリミラーがあります)。リモートマシンは事前に設定された時間に更新を実行し、「展開」ミラーから各マシンにプルします。cronジョブは次のもので構成されます。

apt-get update && apt-get upgrade --quiet --assume-yes

残念ながら、私が詳細を読み始めたので、あなたが求めてapt-mirrorいるパッケージだけでなく、あらゆる種類のものを引き出すようです。そのため、概念にはメリットがありますが、このアイデアを放棄します。


風景が面白そうです。もっと詳しく調べなければなりません。ローカルaptミラーを実行すると(現在実行中)、保留中の更新を承認/レビューするのにどのように役立つかはわかりません。それを明確にできますか?
Insyte

14

同僚がapt-daterを発見し、簡単に調べました。apt-daterは「ターミナルベースのリモートパッケージアップデートマネージャー」です。

cursesベースのインターフェースを使用して、すべてのホストまたはホストのグループなどの更新を管理します。発生する可能性のあるエラーなどを含む、完全なaptセッションのロギングをサポートします。

管理対象マシンのsshおよびsudoに依存します。

参照http://www.ibh.de/apt-dater/を

自分で使っていないので、私はそれを支持することはできませんが、あなたが探しているものに近いように聞こえます。


これは非常に有望に見えます。Insyte、私は自分自身でこの答えをお勧めします。これまでに説明したすべての手順を実行できますが、そのための時間を本当に投資したいのでしょうか。@ジェフ、素敵な提案のために+1。
エイブリーペイン

4

すでにPuppetを使用しているため、これを行う最も簡単な方法(および変更管理/追跡の目的に最適)は、Puppetマニフェストにインストールするパッケージの目的のバージョンを指定することです。セキュリティアナウンスメントリストに注目し、使用するものが届くと、Puppetを更新して「このパッケージのこの新しいバージョンをインストールしてください」と言うだけです。マニフェストでリビジョン管理を使用していると仮定すると、「ポリシー」がいつ変更されたかがわかり、Puppetからのレポートは変更が実際に行われた正確な時間を示します(したがって、それを後のログイベントと簡単に関連付けることができます)。


これはほとんど私たちがやっていることです。すべてのサーバーがすべてのパッケージをインストールするため、puppetパッケージタイプは使用しません。代わりに、パッケージ名とバージョンを使用してサーバーにファイルを書き込み、スクリプトを使用してそれらを実行し、インストールされているかどうかを確認してからインストールを試みます。2番目の部分は、apticronメールを含むメールフォルダーを読み取り、マニフェストファイルの更新と書き換えが必要なすべてのパッケージを取得するスクリプトです。この方法がどの程度うまく機能するかはまだ完全にはわかりません。
デビッドパシュリー

2
Puppetパッケージタイプがすべてのマシンにすべてのパッケージをインストールするのはなぜですか?各パッケージのスタンザを関連するクラスまたは定義されたタイプに入れて、適切なマシンにのみインストールされるようにします。バージョンリストを1つのファイルに一元化する場合は、仮想リソースの大きなリストを作成し、必要に応じてそれらを実現します。
ワンブル


1

特にテスト環境をすでにお持ちの場合、以前にそれについて本当に考えていなかったとしても、私の最初のアイデアはaveryが示唆したものに似たものになるでしょう。

基本的に、自分のローカルリポジトリから自動的にアップグレードするように運用マシンを設定し、テスト環境を実行するものの最新バージョンにアップグレードした後にのみ、このリポジトリを更新します。

Apticronはうまくスケーリングできません。非常に小さな環境で実行されるように設計されていますが、いくつかの良い点があります。

  • リストを送信するだけでなく、アップグレードするパッケージの変更ログも送信します。
  • 変更ログを取得するには、パッケージをダウンロードするため、アップグレードする際にパッケージがダウンロードされるのを待つ必要はありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.