Linuxパッケージのパッケージとイメージ

以下に、GitLabがなぜ依存関係をバンドルしたパッケージとDockerイメージを提供するのかについての基本的な情報があります。

これらの方法は物理マシンや仮想マシンのインストール、シンプルなDockerインストールに最適です。

目標

これらのパッケージにはいくつかのCoreゴールがあります：

GitLabのコアはRuby on Railsプロジェクトです。しかし、アプリケーション全体としてのGitLabはより複雑で、複数のコンポーネントがあります。これらのコンポーネントが存在しなかったり、設定が間違っていたりすると、GitLabは動作しなかったり、予測できない動作をしたりします。

GitLabアーキテクチャの概要では、これらのコンポーネントのいくつかと、それらがどのように相互作用するかを示しています。これらのコンポーネントはそれぞれ設定し、最新の状態に保つ必要があります。

また、ほとんどのコンポーネントは外部との依存関係があります。例えば、Railsアプリケーションは多くのRuby gemsに依存しています。これらの依存関係の中には、正しく機能するためにオペレーティングシステム上に存在する必要がある独自の外部依存関係もあります。

さらに、GitLabのリリースサイクルは毎月あり、最新の状態に保つためには頻繁なメンテナンスが必要です。

上に挙げたことはすべて、GitLabインストールをメンテナーするユーザーにとって課題となります。

GitLabのようなアプリケーションにとって、外部依存は通常以下のような課題をもたらします：

依存関係があなたのオペレーション・システムに存在しても、他のサポートされているOSに存在するとは限らないことに留意してください。

依存関係がバンドルされたパッケージの利点をいくつか挙げます：

バンドルされた依存関係を持つパッケージの欠点をいくつか挙げます：

その答えを簡単に言うと、「メンテナンスの手間が減るから」です。バージョンに互換性がない場合、既存の機能を壊してしまう可能性のある複数のパッケージを扱う代わりに、1つだけ扱えばいいのです。

複数のパッケージを扱うには、複数の場所で正しい設定が必要です。設定を同期させ続けることは、エラーの原因になります。

現在の依存関係をすべてメンテナーするスキルセットがあり、将来導入されるかもしれない依存関係に対処する十分な時間があるのであれば、上に挙げた理由は Linux パッケージのパッケージを使わない理由にはならないかもしれません。

このルートに進む前に、心に留めておくべきことが2つあります：

多くのユーザーによってテストされていないライブラリのバージョンを使用する場合、多くの可能性が存在するため、問題が発生した場合にサポートを受けることが難しくなる可能性があります。
Linuxパッケージのパッケージでは、コンポーネントを独立して実行する必要がある場合、不要なサービスをシャットオフすることもできます。例えば、Linuxパッケージのインストールで、バンドルされていないPostgreSQLデータベースを使用することができます。

Linuxパッケージのような非標準的なソリューションは、アプリケーションに多くの可動部がある場合に適しているかもしれないことを覚えておいてください。

GitLab DockerイメージはLinuxパッケージをベースにしています。

このイメージから生成されたコンテナには複数のプロセスが含まれていることから、この種のコンテナは「ファットコンテナ」とも呼ばれます。

このようなイメージに賛成する理由も反対する理由もありますが、上で述べたことと同じようなものです：

この方法は、コンテナやスケジューラを使い始めたばかりの組織で、より複雑なインストールを行う準備が整っていない場合に有効です。この方法は導入に最適で、小規模な組織には効果的です。