【GitLab 公式 を訳してみた】GitLab稼働必須条件

法律: IT 解説記事 GitLab CI GitLab フノス(訳者) マニュアル

 GitLab DocumentationInstallation>GitLab稼働必須条件

  オペレーティング システム

  対応Unixディストリビューション


 これらのOSたちは、GitLabの公式サイトにインストール方法が記されています。


 

  非対応Unixディストリビューション
 


 以上のOSが、GitLabが対応していないディストリビューションです。
 これらのオペレーティングシステムについては、GitLabをソースコードからビルドしなくてはなりません。

 

  非Unix系オペレーティングシステム(Windows 等)

  GitLabはUnix系OSを対象に設計されたことから、Windowsでは全く動作しません。我々に知識がないことなどから、Windows版のリリースにはまだまだかかりそうです。
 GitLabのインストールには、Unix系OSを導入した仮想マシンをお使いください。

 

  Ruby のバージョン

  GitLabではRuby (MRI) 2.3以上が必要です。2.3未満 (2.1, 2.2) のRubyのサポートは、GitLab 8.13で打ち切られました。
 

  RubyはMRI(Matz' Ruby Implementation)安定版をお使いください。
 GitLab開発者の中には、JRubyRubiniusを好んで使用する者もおりますので、GitLabを利用する際には予め、複数個のGemsライブラリをそろえておくとよいでしょう。

 

  ハードウェア要件

  ストレージ

  これは皆さんがGitLabに収容したいレポジトリのサイズ次第ですが、なるべく余裕を持ってかなり多めに用意してください。
 機能を拡張するときや、同じレポジトリがもう1つ必要になったときなどに、フリースペースが十分でないと困ることになります。

  こういうときに、ハードウェアに追加のドライブがマウントできると便利ですね。機材の問題さえクリアすれば、論理ボリュームマネージャを使ってドライブを追加することができます。

  遠隔ハードドライブについては、network file system (NFS) プロトコルに対応しているものなら、マウント可能です。
 attached storage (NAS) デバイス、 storage area network (SAN)、Amazon Web Services (AWS)、Elastic Block Store (EBS)上のボリュームなどが、これに当てはまります。このボリュームはファイルサーバに設置されます。

  十分なRAMメモリーと、CPUを搭載しているのならば、ストレージの速度がレスポンスに関わってきます。
 GitLabの応答速度を向上させたいのなら、高速ドライブ(7200 RPM 以上)か、solid state drive (SSD)を使用することをお勧めします。
 また、後述にもある通り、安定的なシステムの運営には、相当量のスワップが必要です。そのことも考慮したうえで、適切なストレージを選択してください。

 

  CPU



  メモリ

  GitLabをインストールするには、「RAM + swap」の総量メモリ4GBを最低限確保してください。
 しかし、これは「マシン搭載メモリ=4GB」という意味ではありません。
 オペレーティングシステムとその他アプリケーションのメモリ使用量を除いたうえで、4GBをGitLab専用に充てられるくらいの容量が望まれます。

 メモリ不足は、GitLabの設定変更時に予期せぬエラーをもたらす他、コマンドを出した際にも500エラーを表示される原因になります。
 


  たとえ、サーバーに十分なRAMがあったとしても、最低2GBのスワップを用意しましょう。スワップを多めにとっておくことで、メモリを変更したときにもエラーが起こりづらくなります。
 カーネルのswappinessは最低値を「10」に設定しておくことをお勧めします。これで、システムメモリはRAMをメインで使用して、必要な時にスワップを使用するような動作に設定できます。

 注:Sidekiqのworkersの25番目では、処理の概要(tophtop など)の中から個別のプロセスが表示されます。ですが、RAMのアロケーションについてはマルチスレッドアプリケーションとして表示されます。
 詳しくは後述の『Unicorn Workers』の章で紹介します。

 

  データベース

  データベース用のサーバーの容量は、GitLabの規模(ユーザー、プロジェクトなどの数)によって異なりますが、最低でも5-10 GBのストレージ量が必要でしょう。
 

  GitLabでは次のデータベースに対応しています。


 MySQL/MariaDBを使っていて不利な点をお伝えします。
 

  1. MySQLのサブグループ対応機能が、GitLab 9.3で廃止。詳しくはissue #30472をご覧ください。
  2. GitLab Geo に対応していない
  3. Zero downtime migrationsが動くのは、データベースの負荷分散からして、PostgreSQLだけ。
  4. GitLabオプティマイザによって、ダッシュボードのロードにはPostgreSQL LATERAL JOINが使われている。
  5. GitLabオプティマイザによって、ダッシュボードのロードにはPostgreSQL LATERAL JOINが使われている。
  6. GitLabはPostgreSQLに最適に設計された。クエリプランナーの違いから、MySQLは反応が遅くなる。たとえば、PostgreSQLでは動作していたはずのサブクエリが、MySQLでは処理されない場合がある。
  7. 両者の違いは、今後さらに開いていくと思われる。


 現在GitLabでMySQL/MariaDBを使用している方を対象に、PostgreSQLへの移行を薦めております。
 
 

  PostgreSQL 必要条件

  GitLab 10.0は、PostgreSQL 9.6以降に対応しています。それ未満のバージョンはご利用いただけません。システム開発とテストの段階でPostgreSQL 9.6を使用していたことから、これが最も相性の良いデータベースとなっています。

  PostgreSQLを利用するには、GitLabデータベースを読み込む際に「pg_trgm」エクステンションを使用しなくてはなりません。このエクステンションは(スーパーユーザーでPostgreSQLを使用している状態で)、次のクエリをデータベースごとに与えることで、有効化できます。

=====================
CREATE EXTENSION pg_trgm;
=====================

  一部システムでは、このエクステンションの使用に何らかのパッケージを追加する(postgresql-contrib など)必要があります。

 

  Unicorn Workers

  unicorn workersの量を増加させることで、アプリケーションの応答時間を短縮したり、同時に複数のリクエストに応えられる状態を作り出せる場合があります。

  たとえば、マシンのCPUコアを1つだけ増やす操作(CPU cores + 1 = unicorn workers)などは代表的です。
 これで、コアが2つしかないマシンに対して、擬似的に3つのコアを作成させることができます。

  2GB以上のRAMが搭載されているマシンでは、unicorn workersを最低3個用意することをおすすめします。
  メモリが1GBなら、スワップを有効化させるために、Unicorn workersが2つ必要です。

  オムニバス版をお使いで、 Unicorn workersの個数を調整したい方は、Unicorn settings in the Omnibus GitLab documentationを参考にしてください。

 

  Redis と Sidekiq

  Redisは、全てのユーザーセッションとバックグラウンド タスクキューを保存します。保存する事項が膨大になりづらいため、GitLabで対応しているデータベースとしては、ストレージ要求が最も少なめです。各ユーザーごとに25kBくらいかかります。

 Sidekiqは、バックグラウンドで発生する処理を、マルチスレッドで切り盛りするプログラムです。基本的に、Railsの容量が200MB以上になったときに作動しますが、メモリの空き状況やメモリーリークなどによって、開始が遅れることがあります。
 1万人のアクティブユーザーが存在する、大規模なアクティブサーバーでは、Sicekiq処理に1GB以上のメモリを要する場合があります。

 

  Prometheus と 付属 exporters について

  Omnibus GitLab 9.0から、Prometheus と 付属 exportersがデフォルトで有効にされています。これでGitLabのシステム調査がある程度容易に実行できます。

 デフォルトの設定では、この機能のために約200MBが消費されるようになっています。

  この機能は任意で停止させることが可能です。詳しくはPrometheus documentationをご確認ください。

 

  GitLab Runner

  我々開発者側としては、扱いの簡単さから、GitLab ランナーは GitLabがインストールされているのと同じマシンに導入することをお勧めしたいところです。
 CI環境で使わなくてはならないアプリケーションなどがGitLabに入っていることもあり得ます。そうなると同じマシンに導入した方が設定が簡単です。
 しかし、GitLab ランナーもまた、メモリを大きく消費します。

  メモリの消費量からして、GitLab ランナーと GitLab Railsアプリケーションを同一のマシンに置いておくことは得策でない場合があります。

  ランナーとGitLabはそれぞれ別のマシンにインストールすることは、リソース面では現実的ではあります。しかし、お互いに密接に関係して動いているシステムなだけに、セキュリティ面での心配が伴います。とくに、GitLab ランナーでシェルエクゼキュータを使用する予定なら、なおさらです。

  CI機能をフルに使っていこうとお考えの方は、セキュリティリスクがあることも踏まえたうえで、GitLab ランナーを別のマシンに導入してください。

 

  ウェブブラウザへの対応

  GitLab は、メジャーリリースのFirefox、Chrome/Chromium、Safari、Microsoft ブラウザ(Microsoft Edge と Internet Explorer 11のみ)に対応しています。

  それぞれのブラウザに新しいバージョンが発表され次第、GitLabのサポートは新バージョンに移行していきます。その代わり以前のブラウザへの対応は打ち切られていきます。ご注意ください。

 Edit this page2018-03-23 21:52:04 / Hnoss
原文サイトを表示
[ 原文 ] https://docs.gitlab.com/ee/install/requirements.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。