# How to install gitlab Gitlabのローカルへのインストールにおいて、幾つかのOSについては複数の方法があるのでいかに示します. 一部見出しは各内容のドキュメントへのLinkになっています. ## 前提 Gitlab は Ruby on Rails製のアプリケーション(Webサーバー)であり, 一部がGoによって書き換えられている. その為、下記のものに依存している - Ruby 及び Rails - SQL (mysql/mariadb or postgresql) - Redis (cacheとして. 関連ツール導入等、設計によっては他のキャッシュにもなる) - NodeJS - Go - Nginx これらをどうインストールし、そのPCに合わせた設定をするか、というところで上記の「複数の方法」の差異が生まれ、またセットアップの簡単さや保守のコスト、更新への対応の簡単さ、等が変わる ## 一覧 https://about.gitlab.com/install/ 以下にそれぞれのメリット・デメリット等を簡単にまとめます. ## [From source](https://docs.gitlab.com/ee/install/installation.html) OSに対応したPackageが無い時&Dockerでのデメリットを避ける時, 機能のOnOffを全て管理したい時、細かい設定の変更をしたい時等は 直接ソースからBuildする. ### メリット・デメリット - 直接Buildするので環境に合わせた設定や最適化、機能の追加が可能 - 常に最新版が得られる, 特に nodeやRails周りは少し古いだけでセキュリティ的には実は完全にダメ、といったプラグインの更新が月1,2回ペースであるので, セキュリティを完全に重視するならこれ - (OSによってはパッケージの更新が早い`ローリングリリース`形式のものがあるのでそちらなら同等, そうではないものは安定版のみの更新になるので遅くなる) - 全てBuildするので、最初の導入に手間がかかる. 方法自体はドキュメントがあるので困らないが, 単純に依存するものをパッケージマネージャで入れる -> ある部分のbuild というのを数回繰り返すので時間はかかる ## package manager 対応したOSによってはpackage managerでインストール出来る. 公式と非公式があり, 非公式はドキュメントの更新が遅れている、といった事が起こる可能性がある(archはそうでした.) - [Ubuntu](https://about.gitlab.com/install/#ubuntu) - [Debian](https://about.gitlab.com/install/#debian) - [CentOS](https://about.gitlab.com/install/#centos-8) 他にもある程度のOSに対応している様なので, [一覧](#一覧)を確認して下さい. これとは別に(gitlabのarch版に関していえば古くなっていますが) Gitlabに関しての情報としては詳しいのでWikiを載せておきます. - [arch wiki](https://wiki.archlinux.jp/index.php/GitLab) ### メリット・デメリット - Package managerを使うので, 仕事量と最適化等のいいとこ取りがしやすい - OSの色が出やすく, 上記の公式対応のものは少ないコードで簡単に、一方arch等のものは割とソースを自分でBuildするのに近い(Makefileを用意してくれている, といったイメージ) - 定期的に更新が出るので簡単に更新出来る.(`sudo yum update` や `sudo apt update` 等で更新出来る) - 一方で(Gitlabに限らず)ローリングリリースではない Debian系やRedhat系 では更新の周期が一般的なOSの更新頻度並になる事が多い. - 設定の変更がややしにくい. OS固有の設定や推奨のフォルダ構成等があるので気をつけないとBestPracticeから外れやすい. - 結局SourceからBuildするのと同じ程度, OSや利用しているツールについて詳しくないと不具合対応や設定の変更・機能の追加が難しくなる. ## [Docker](https://docs.gitlab.com/ee/install/docker.html) https://docs.gitlab.com/omnibus/docker/ も合わせてどうぞ. Dockerのイメージがあります. Dockerそのものでの起動はOptionをたくさんつける事が多く, それぞれのオプション引数の扱い等面倒ですが, Docker-composeと合わせることで, 簡単に起動や細かいDocker特有の設定が出来ます. 今回はこの組み合わせを使用していました. ### メリット・デメリット - DockerとDocker-composeさえ導入できていれば, 環境変数と10行程度の `docker-compose.yml` を一枚用意するだけでセットアップから起動まで終わる. - 内部の設定の変更は難しい. 環境変数や引数で指定する事になるが, Dockerの中に隠蔽されているのでデフォルトから外れるとかなり複雑になる - 効率は他のインストール方法より良くない. Dockerの問題というよりはSQLやファイル等のデータが全てあるフォルダ内のファイルとして扱われるため. - 同様の原因でSQL等を外部に分けたりするのが難しいです. プロジェクトやソースコードの移行は問題ないですが, Userや細かい設定等の移行(sqlのデータ移行等も含む)といった「Gitlabで用意されていないExportやimport」は不可能に近いかかなり手間がかかるかとと思います. ### Docker-compose.yml 以下に簡単なDocker-compose用のファイルの例を示します. また、環境変数`GITLAB_HOME`として`/srv/gitlab`を設定してください. ```yaml version: '3.7' services: gitlab: image: gitlab/gitlab-ee ports: - "80:80" volumes: - '/srv/gitlab/config:/etc/gitlab' - '/srv/gitlab/logs:/var/log/gitlab' - '/srv/gitlab/data:/var/opt/gitlab' ``` ## backup https://www.creationline.com/lab/22705