いつ、なぜapt-get updateを使うべきですか?

いつ、なぜapt-get updateを使うべきですか?

一般的な質問:

誰かがこのコマンドの機能apt-get updateと実際に使用する必要がある場合を説明できますか?


コメント

一つください詳細な回答。バージョンが非常に詳細でない限り、マンページのコピーだけではありません(以下のマンページに定義を追加しました)。

適切なアップデートを入手:ソースからパッケージインデックスファイルを再同期するために使用されます。利用可能なパッケージのインデックスは、/etc/apt/sources.list(5) で指定された場所から取得されます。アップグレードまたはdist-upgradeの前に常に更新を実行する必要があります。


サブ質問:

  • パッケージインデックスはどこに保存されますか?データベースに?ファイルに?
  • キャッシュを更新しないとapt-get installどうなりますか?リモートパッケージが存在しなくなり、リンクが壊れる可能性はありますか?
  • debリポジトリに関して合意されたポリシーはありますか?たとえば、リポジトリにはパッケージの最後のバージョンのみを含める必要がありますか、または逆に特定の展開で利用可能なすべてのバージョンを含める必要がありますか?

コンテキスト

研究中ですので、この質問をします。ドッカーフレームワーク。その特徴の一つはドッカーファイル、ファイル内の特定のコマンドを実行して、特定のオペレーティングシステムイメージを構築できます。この画像の1つの属性は、コンテキスト(ビルド時間など)に関係なく、常に同じでなければならないことです。

apt-get update別の時間にコマンドを実行すると結果が変わり、画像も変わるのかと心配です。

答え1

apt-get update利用可能なパッケージのリストをダウンロードしてください。

パッケージのリストは時間の経過とともに変更されることがあります。新しいパッケージが追加され、古いパッケージが削除されます。したがって、非常に古いキャッシュがあり、実行しようとすると、apt-get install存在しなくなったパッケージをダウンロードしようとすることがあります。
古いパッケージがリポジトリに残る期間は、リポジトリマネージャ(ディストリビューション)によって異なります。したがって、キャッシュが非常に古いdockerのようなものを使用している場合は、apt-get updateパッケージをインストールする前に常に実行する必要があります。

パッケージを削除して追加する理由は、主にバグ修正とセキュリティ更新によるものです。ただし、PPAなどのサードパーティ製のストレージを使用すると、すべてが起こります。

エンタープライズ環境でDockerなどのコンテナ化ツールを使用している場合は、毎回コンテナを再構築するのではなく、コンテナを一度ビルドしてから、コンテナをさまざまなリリース環境(開発、ステージング、プロダクション)に移動する必要があります。これにより、テストされていない他のコンテナを取得できなくなります。

キャッシュファイルの場所に関する質問に答えるには/var/lib/apt/lists

答え2

apt-get updateコマンドの機能と実際に使用する必要がある場合を誰か説明できますか?

apt-get updateディストリビューションのパッケージストアから更新されたインデックスをダウンロードして、利用可能なすべてのパッケージと正確なバージョンを一覧表示します。

UbuntuやDebianなどの一般的なディストリビューションは通常、パッケージ提供で保守的であり、以前のバージョンと互換性があるため、セキュリティ更新プログラムやバグ修正のために時間が経つにつれてバージョンはあまり変わりません。たとえば、mysqlは5.7.18からにアップグレードできますが、5.7.19アップグレードできません6.x

パッケージインデックスはどこに保存されますか?データベースに?ファイルに?

通常は1つ以上のファイルに保存されます/var/lib/apt。 Dockerの文脈では、これらのファイルは画像の内側にあります。 Dockerfileがビルドされると、新しくビルドされたイメージとして作成され、保持される新しいファイルシステムレイヤーに保存されます。

キャッシュを更新せずにapt-get installを実行するとどうなりますか?

存在しなくなったパッケージのバージョンをダウンロードしてみることができます。これは仮想マシンで一般的ですが、デプロイメントリポジトリがデフォルトイメージを構築した後に新しいパッケージを公開する場合は、コンテナ内でも発生する可能性があります。ディストリビューションの下流にあり、その数が多い可能性があるディストリビューションマネージャとDockerfileマネージャの間に調整がない可能性があります。 Debianリポジトリは1つだけですが、jessieそれに基づいている何千ものコンテナイメージとDockerfileがあります。

また、Ubuntuミラーなどの一部のアップストリームミラーダウンロードしたインデックスを削除画像を小さくして古いファイルを避けてください。したがって、基本イメージバージョンごとに最新のインデックスを提供するのではなく、基本イメージの上にビルドするときに更新されたインデックスをダウンロードする必要があると予想される。

リモートパッケージが存在しなくなり、リンクが壊れる可能性はありますか?

もちろん、インデックスに保存されたバージョンは非常に正確であるため5.7.19(単純化、より類似している5.7.19-0ubuntu1)。

debリポジトリに関して合意されたポリシーはありますか?たとえば、リポジトリにはパッケージの最後のバージョンのみを含める必要がありますか、または逆に特定の展開で利用可能なすべてのバージョンを含める必要がありますか?

アップデートがリリースされると、以前のマイナーバージョンがすばやく削除されるのが非常に一般的です。バイナリの重量は、数十メガバイトでサポートされているすべてのバージョンとアーキテクチャを掛けることができるため、これがサーバースペースを節約するためのものであると仮定します。したがって、通常、mysql-5.7.18後続で修正することは不可能ですapt-get installmysql-5.7.19リリースに公開されると、以前のバージョンは削除されます。

公平に言えば、Dockerのこの不確実性は、apt-get updateすべてのディストリビューションのパッケージ管理に付属する問題です。 EC2またはVagrant仮想マシンを繰り返し構築しようとすると、同じ問題が発生します。

一部のシステム管理者は、次のプログラムを使用します。適切に元のリポジトリをミラー化して特定のバージョンを固定することはできますが、更新をテストして固定されたアイテムを変更するために頻繁に実行される別のプロセスがないと、セキュリティ更新プログラムが欠落する可能性があります。

関連情報