Omnibus ベースのパッケージとイメージ

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

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

目標

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

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

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

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

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

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

GitLabのようなアプリケーションでは、外部依存は通常次のような課題をもたらします：

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

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

バンドルされた依存関係を持つパッケージの欠点もあります：

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

複数のパッケージは複数の場所で正しいコンフィギュレーションを必要とします。コンフィギュレーションの同期を維持することはエラーになりがちです。

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

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

大多数のユーザーによってテストされていないライブラリのバージョンを使用する場合、多くの可能性が存在するため、あなたが遭遇した問題のサポートを受けることはより難しいかもしれません。
Omnibus パッケージでは、コンポーネントを単独で実行する必要がある場合に、必要ないサービスを停止することもできます。例えば、バンドルされていないPostgreSQLデータベースをOmnibus パッケージで使用することができます。

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

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

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

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

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