Help us understand the problem. What is going on with this article?

GitlabのOmnibus版をインストールしてApacheで運用してみる(ついでにSSLと自動バックアップも)

More than 3 years have passed since last update.

調べるとこんな記事が結構あったけど、もう古くなったバージョンだったり、情報が散らばってたりするので、最新バージョンでやってみた場合のメモ。
もしかしたら不要な設定があるかもしれないけど、とりあえずこれで動作確認はOK。
以下に設定ファイル含めた全貌を記載。

インストール環境

  • サーバ
    • CentOS 6.5
    • メモリはとりあえずgitlab推奨の2GB

Gitlab Omnibusパッケージのインストール

GitlabのHPから対象のOSを選択するとインストール方法が出てくる。
Gitlab本体のインストールは上記の通りやっていけばすんなりと完了する(ほんとに2分で終わる)

今回はGitLab Community Edition 8.7.0の最新版をインストールした。

Omnibusパッケージだとpostgresもnginxもすべて必要なものをインストール、設定してくれるため非常に楽だが、すでにインストールしているpostgresやnginxを使う場合は自分で設定する必要があるためやや敷居が高くなる。

Apacheで運用する

GitlabはnginxをWebサーバとして動作するが、すでに使用しているサーバがあり、Apacheを使用して80番ポートでアクセスさせたい場合は、少し一手間を加える必要になるようである。

そこで、リバースプロキシを利用して、Apacheで受けたリクエストをnginxに転送することで実現させる。

gitlabの設定変更(SSLも対応)

今回リクエストの受け口となるURLをhttps://git.xxxxx.com とする

  • /etc/gitlab/gitlab.rb
external_url = 'https://git.xxxxx.com' # urlの設定。今回はhttps
・・・
nginx['listen_addresses'] = ["0.0.0.0", "[::]"]
nginx['listen_port'] = 4080 # nginxをポート4080で受けるように設定
・・・
nginx['ssl_certificate'] = "path_to_cert" # これいらないかも?
nginx['ssl_certificate_key'] = "path_to_key" # これも
・・・
# あとはsmptのところでメール送信のセットアップを行う

※ インストール当初、external_urlの部分に"="がついていなかったけど、どうやら記載しないと行けない模様

  • /var/opt/gitlab/nginx/conf/gitlab-http.conf
server {
  listen 0.0.0.0:4080;
  listen [::]:4080;
  server_name git.xxxxx.com; # ここを追記
  • /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml
  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    # host:
    host: 'git.xxxxx.com'
    port: 443
    https: true

    # Uncommment this line below if your ssh host is different from HTTP/HTTPS one
    # (you'd obviously need to replace ssh.host_example.com with your own host).
    # Otherwise, ssh host will be set to the `host:` value above
    ssh_host:  'git.xxxxx.com'
    url: https://git.xxxxx.com

最後にgitlab-ctl reconfigreで設定を読み込み、gitlab-ctl restartで再起動。

Apacheの設定

80番ポート側(HTTP)

HTTPSへリダイレクト

<VirtualHost *:80>
    ServerName git.xxxxx.com
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R]
</VirtualHost>

443番ポート側(HTTPS)

いろいろ省略してます

<VirtualHost *:443>
    ServerName git.xxxxx.com:443
    SSLEngine on
    SSLCertificateFile path_to_cert
    SSLCertificateKeyFile path_to_key
    SSLCertificateChainFile path_to_chain # 中間証明があれば
    SSLProxyEngine On
    ProxyRequests off
    ProxyPass / http://127.0.0.1:4080/
    ProxyPassReverse / http://127.0.0.1:4080/
    ProxyPass /assets http://127.0.0.1:4080/assets
    ProxyPassReverse /assets http://127.0.0.1:4080/assets
</VirtualHost>
/etc/init.d/httpd restart
# sslのpassを入力

これでhttps://git.xxxxx.com

自動バックアップの設定

gitlabのバックアップはコマンド1行で取得できる。

/opt/gitlab/bin/gitlab-rake gitlab:backup:create

これで、/var/opt/gitlab/backupsにtarでバックアップが作成される。
詳しくはここに記載されている通り。

バックアップの保存期間を設定する

再び、/etc/gitlab/gitlab.rbに設定する部分があるため下記の通り設定

gitlab_rails['backup_keep_time'] = 604800 # 7日間分保存する

cronで1日1回深夜2時にバックアップをする

0 2 * * * /opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1

リモートサーバにバックアップ

svnであればsvnsyncなど便利なものがあったけど、あまり思いつかないのでrsyncを使用してリモートサーバにtarファイルをディレクトリごとバックアップ。

rsync -avz --delete /var/opt/gitlab/backups/ [remoteのIP]::gitlab

gitlabのバックアップのタスクと一緒にスクリプトを組んでおけばバックアップしてからリモートに保存することが出来る。ただ、これだとバックアップが取れない日々が続いた場合に全部消えてしまうのでファイルごとにバックアップするほうがよさそう。

リモートサーバ側の設定
rsyncをインストールして、下記の通り設定。

  • /etc/rsyncd.conf
[gitlab] # ここは上記の[remoteのIP]::gitlabの"gitlab"と同じ命名にする
path = /path/to/backup
hosts allow = [バックアップ元サーバのIP]
hosts deny = *
list = true
uid = root
gid = root
read only = false

備考

https://git.xxxxx.com/gitlab のように、サブディレクトリで運用しようとしたけど、最新版の8.7.0ではバグがあるようで、レイアウト崩れが発生していた。
サブディレクトリ運用する場合はそれより低いバージョンであれば、問題なく設定が出来た。(設定がもう少し面倒くさい)

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした