MENU

gitlabを既存ミドルウェアを使ってセットアップする(サブディレクトリ運用)

エンジニアブログ

2017-06-01

andyです。

現在弊社ではソース管理にgit、レビューシステムにgerritを自前サーバにインストールして利用しています。
ただし以下のような不満点(主にgerritに対して)があり、別のツールを模索しているところです。

・gitのみだとそもそもレビューしたり何かのアクションに対して通知等がしづらい(hookだけでは限界がある)
・UIが若干イケてない
・コミットの単位が大きくなりがち
・大規模にリベースするとサーバのリソースが不足する
・Change-Idという謎のコミットメッセージが必要
・今の開発フローにブランチの管理を合わせにくい

gerritのUIは本サイトを見ていただければなんとなく想像つくかと思います。。(頑張ればカスタマイズできるのでしょうが・・)

コミット単位が大きくなる、という点は、gerritは1コミット1レビューという紐付け方をしているため(正確にはChange-Idとレビューの紐付け)、レビューの指摘があった場合 git commit –amend を利用してコミットを修正していく、という開発スタイルになります。
つまりレビューが完了するまで1つのコミット内で修正を重ねていくことになるため、コミットのゴールが小さくなるように意識しない限り巨大なコミットができあがってしまいがち、ということになります。
これは開発者にとってもレビュアーにとってもストレスフルで、開発用ブランチやリリース用ブランチへのマージが遅くなったり、レビューが通らないとなかなかマージされず時間がかかってしまい、開発リズムが作りづらい状況を生んでしまっています。

大規模にリベースする、というのは比較的長期のプロジェクト(弊社では1ヶ月以上の開発案件は長めです)の場合、コミット数が30, 40をオーバーするケースも珍しくありません。
その間に運用/改善案件等でリリースブランチにコミットが入りますから、あるタイミングで長期開発ブランチはリベースが必要になります。
これを行うと、gerritをインストールしているサーバのリソースが強烈に消費されてしまい、場合によってはプロセスが暴走したりoom-killerに切られてしまう、といったことが発生してしまいます。
(gerritが動作するサーバはCPU4コア、メモリ6GBのインスタンスです。jenkinsと共存させているためリソース取り合い状態ですが)

これはgerritに限った話ではなくビルドサーバには共通して求められるものかもしれません。

Change-Idはgerrit特有の仕様で、上記の「コミットとレビューを結びつける」仕組みです。
gerritが提供するcommit-hookでこのChange-Idが自動的に振られるのですが、場合によってうまく振られなかったり、cherry pickする場合にはそのChange-Idも含んでコピー&ペーストしなければならない、などの微妙な制約がちょっとしたストレスになります。

開発フローと合わない、という点は長くなるので今回は割愛します(いずれ書く機会があれば・・)。

さて、相変わらず前置きが長いですが、本題に入ります。
これら課題をある程度解決することを期待して、まずはgitlabを使ってみよう、ということになりました。
gitlabは何も考えなければ必要なミドルウェアをオールインワンでセットアップしてくれて、すぐに使い出すことができます。
※セットアップに弊社でも利用しているchefを使っているのですが、世界に配布するchefがメンテナンスできていることに驚きです。。(これについても1記事書けそうです)
が、運用を考えるとwebサーバ、キャッシュサーバ、DBサーバは分けておきたいな、既存で使っているものがあればそれを使いたいな、と考え、まずは既存のミドルウェアを使う設定で動かしてみます。

gitlabのオールインワンから切り離したものは以下のミドルウェアです。
(幸いにも?弊社が採用しているミドルウェアが存在したもの)

・smtpサーバ
・キャッシュサーバ(Redis)
・DBサーバ(PostgreSQL)
・webサーバ(nginx)

そしてそれぞれの設定は以下のようになります。
(gitlabのインストールは済んでいる前提です)
※執筆時バージョンは9.2.1

■gitlabのコンフィグレーション(/etc/gitlab/gitlab.rb)
まずはサブディレクトリやタイムゾーン、ディスク指定など


external_url 'http://example.waja.co.jp/gitlab'
gitlab_rails['time_zone'] = 'Asia/Tokyo'
git_data_dirs({
  "default" => { "path" => "/var/opt/gitlab/git-data", 'gitaly_address' => 'unix:/var/opt/gitlab/gitaly/gitaly.socket' },
  "alternative" => { "path" => "/var/data/gitlab" }
})

smtpサーバ指定(自前かつローカルLAN内なのでセキュリティ系の設定は外します)


gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "my.smtp.server"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_authentication'] = false
gitlab_rails['smtp_enable_starttls_auto'] = false

Redis設定(既存のRedisがセットアップ済み)


redis['enable'] = false
gitlab_rails['redis_host'] = "my.redis.server"
gitlab_rails['redis_port'] = 6379
gitlab_rails['redis_database'] = 3

PostgreSQL設定(既存のPostgreSQLがセットアップ済み)
※なお、既存PostgreSQLがoidをデフォルトで付与するようになっていたため、gitlabセットアップ時に一時的にOFFにしました。
※これをONにしたままだとMySQLのデータ移行(gitlabの元データ?はMySQLの模様)時にoidというカラム名がバッティングしてスキーマ登録時にエラー終了してしまいます。


DBサーバ側に事前にユーザを作ります
CREATE USER gitlab WITH ENCRYPTED PASSWORD 'xxxxxxxx' SUPERUSER CREATEDB NOCREATEROLE;
(superuserで作らないとextensionが作れないなど、途中でエラーになってしまいます)

postgresql['enable'] = false
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_encoding'] = "utf8"
gitlab_rails['db_database'] = "gitlab"
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "xxxxxxxx"
gitlab_rails['db_host'] = "my.postgresql.server"
gitlab_rails['db_port'] = 5432

nginx設定


nginx['enable'] = false
web_server['external_users'] = ['nginx']

ここまででも多少の試行錯誤が入っているのですが(DBサーバのoidやSUPERUSERなど微妙なハマりポイントです。。)、既存のミドルウェアで以下のような設定を追加しています。

■nginx(/etc/nginx/conf.d/xxxx.conf


    location /gerrit {
        proxy_set_header   X-Real-IP           $remote_addr;
        proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host    $host;
        proxy_set_header   X_FORWARDED_PROTO   $scheme;

        proxy_read_timeout 90;
        proxy_pass        http://127.0.0.1:8081;
        proxy_redirect     http://127.0.0.1:8081 http://$host;
    }

※実はgitlabが動作させるいくつかのプロセスがオープンするポート番号が既存のアプリケーションと被ったりしているのでそれぞれ変更したりしています。
以下の設定はgitlabのexternal_urlがちゃんと効いていれば?不要なのかもしれませんが、何故かうまくいかなかったので追加した設定です。
(これもまたハマりポイント・・)


    location /assets {
        rewrite ^(.*)$ /gitlab$1 permanent;
    }

何故かassets(メールの添付画像など)がサブディレクトリからの相対パスにならなかった、という・・・

というわけで、ここまでやってようやく利用準備が整いました。
これからいろいろと検証して、各課題が解決できるのか、等を検証していきたいと思います。

IntelliJ KEYMAP #1(Mac)

2017-05-29

BLOG/エンジニアブログ

アプリ更新時のブラウザリロードは自動で!

2017-04-30

BLOG/エンジニアブログ

常時SSL化その後

2017-02-24

BLOG/エンジニアブログ