読者です 読者をやめる 読者になる 読者になる
pixiv insideは移転しました! ≫ http://inside.pixiv.blog/

GitLabの運用方法をドーンと公開!!

ピクシブ株式会社 Advent Calendar 2016の時間です。今回はピクシブ株式会社でエンジニアをしている @catatsuy が担当します。今回は意外と書いてなかったのでGitLabを社内でどう運用しているかの話を書こうと思います。

GitLabとGitHub

ピクシブ社内では以下の2つの方法でソースコードを管理しています。

  • 自社でホストしているGitLab
  • GitHub Organization

それぞれ以下の特徴があります。

  • GitLabのメリット
    • 自社でホストしているため、アメリカにサーバーがあるGitHubよりもgit cloneでリポジトリをダウンロードする場合などは速い
    • オープンソースのプロジェクトのため、社内のサーバーにインストールするだけで使える
      • ソースコードを読めば内部でやっていることが分かる
    • ユーザー数やリポジトリ数などで料金がかからないため、気軽に使える
  • GitLabのデメリット
    • バージョンアップは自分たちでやる必要がある
      • 停止する必要がある
  • GitHub Organizationのメリット
    • GitHubと全く同じ使い方ができる
    • 外部サービスの連携が充実している
    • 外部の会社とのやり取りに使うこともできる
  • GitHub Organizationのデメリット
    • ユーザー数やリポジトリ数などで料金がかかる
    • 日本からだと回線が遅いので、容量の大きいリポジトリだと扱いにくい

ピクシブ株式会社では社内でpixiv.gitと呼ばれている最も大きなリポジトリでGitLabを使用しています。今回は弊社でのGitLabの使い方や運用方法について紹介します。

GitLab上のユーザー権限について

GitLab上のユーザー権限は複数存在します。

Permissions - GitLab Documentation

現在社内では社員全員Developer権限にしています。そうするとリポジトリの作成権限などもなくなるので、Owner権限をもつアカウントを用意して必要なときだけそのアカウントを使用しています。

またGitLabにはprotected branches機能があります。この機能を使うことでmasterブランチなど特定のブランチに対してforce pushを禁止することが出来ます。現在ではGitHubでも使える機能ですが、GitLabには以前から存在した機能の一つです。

pixiv.gitでは基本的に作った本人がmasterブランチにmergeして、本人が本番にデプロイするルールで運用しています。しかしprotected branches機能を使うとDeveloper権限のユーザーでは通常のpushすらできませんでした。そのため以前はDeveloper権限のユーザーでもpushできるようにGitLab側にパッチを当てていました。現在ではDeveloper権限のユーザーにもpushする権限を与えることができるので、現在ではパッチを当てていません。

会社によってはGitLabにパッチを当てて運用していると聞きます。GitLabはオープンソースで開発されていて、主観ですがソースコードも読みやすいと思います。なのでパッチを当てることが容易なところもGitLabの魅力です。以前は上記のパッチを当てていましたが、現在ではGitLabにパッチを当てずに運用しています。

GitLabの認証

pixivの開発サーバーはLDAPでユーザーを管理しています。なのでpixivの開発に関わる人は全員LDAPのアカウントを所有しています。そこでGitLabの認証もLDAPを使用しています。LDAP経由で初めてログインを行った際にユーザーが作成されるので、その後にOwner権限を持っているユーザーでGroupにDeveloper権限で所属させることでアカウントを作成しています。LDAPでの設定は以下のURLを参照してください。

LDAP - GitLab Documentation

加えて、GitLabではRubyで広く使われている omniauth/omniauth で使える認証を使用できます。

社内でGoogle Appsを使用している場合はそのGoogle Appsのアカウントを使用して認証することなども可能です。各社で最適な認証方法で提供できることもGitLabの魅力です。

詳細は以下のドキュメントを参照してください。

OmniAuth - GitLab Documentation

外からも使いたい

社内のGitLabは社内のネットワークからのみ参照できるようにしていました。しかしこれだと社外からアクセスする場合にVPNを使う必要があります。VPNを使うのは手間ですし、ネットワーク機器上の制約もあります。そこでGitLabをもっと社外から気軽に見られるようにしたいという需要が社内からありました。そういった場合に社内ではgateを使ってGoogle認証で提供していました。それについては以前に私が記事を書きました。

inside.pixiv.net

inside.pixiv.net

ただしgateは最近ほとんどメンテナンスされていません。またgateは単純なプロクシサーバーとして機能するわけではないため、GitLabのような様々なオープンソースのツールに対応するのは難しい部分があります。そこで最近では bitly/oauth2_proxy を使って、下の記事の方法で前段にGoogle認証を挟むことで外部からでも手軽にセキュアにアクセスできるようにしています。

lamanotrama.hateblo.jp

GitLabで前段にGoogle認証を挟む場合はいくつか注意すべき点がありました。それを紹介します。

GitLabの前段にGoogle認証を挟む

pixivの開発は専用の開発サーバー上で行われています。そのサーバーは自社データセンター内に存在するため、GitLab上のリポジトリへのアクセスはデータセンター内のサーバーで使えるプライベートなホスト名を使ってsshでアクセスしています。

しかしGitLabでは外部から見れるドメインと、ssh経由でリポジトリを持ってくる際のドメインは同じであることが前提になっているため、指定できるhost名は1つだけです。またGitLab上のソースコードは機密情報でもあるため、HTTPS通信にしたいです。そうなると当然外部から解決できるドメイン名で提供する必要があります。

つまり以下のような設定にしたいです。

  • ブラウザからは外部から解決できるドメイン名でHTTPS通信で見れる
  • git cloneはsshからのみ行う
    • sshのURLのドメインはデータセンター内のプライベートなホスト名

GitLabの設定はgitlab.ymlにYAMLで記述します。HTTPSで提供する場合はgitlab:以下でhttps: trueと記述します。gitlab:以下のhost:にブラウザ上で見れるドメイン名を記述します。

これではリポジトリのsshのURLでhostに指定したもので表示されてしまいます。そこでgitlab.ymlgitlab_shell:の下に ssh_path_prefix: "git@private.domain:" という設定を行います。そうすることでリポジトリのURLだけを変えることが出来ます。

GitLabではリポジトリのURLとしてデフォルトではhttpとsshの両方を提供していますが、Google認証を通した時点でhttp経由ではgit cloneができなくなります。GitLab上の設定でEnabled Git access protocolsというものがあるため、ここをsshのみにすることでGitLab上ではsshのURLしか表示されなくなります。

実は設定のssh_path_prefixはGitLabにパッチを当てるつもりでソースコードを読んでいたときに見つけました。ドキュメントにも載って無さそうだったので隠しオプションかもしれません。使用する際はソースコードを読んで使えるか確認した方がよいでしょう。

バージョンアップについて

GitLabの開発は非常に活発なため、定期的にバージョンアップをしたいです。基本的にはドキュメント通りに行えば問題ありませんが、実際に社内で行っているバージョンアップ方法を紹介します。

GitLabでは全てのバージョン間のバージョンアップ方法のドキュメントが用意されています。現在使用しているバージョンから使いたいバージョン間のドキュメントは必ず全て目を通しましょう。

gitlabhq/doc/update at master · gitlabhq/gitlabhq · GitHub

ドキュメントはほとんどが毎回コピペされているだけですが、バージョンによってはコピペではない文章が書かれていることがあります。その文章を手元にコピーするなどして忘れないようにしましょう。バージョンにもよると思いますが、基本的には複数のバージョンアップを同時にやっても問題ありません。ただし先程紹介したコピペではない文章に注意する必要があります。

バージョンアップのドキュメントでは必ず最初にバックアップを行っています。GitLabのバックアップではMySQLで使用している場合はmysqldumpと、gitリポジトリのバックアップをしています。停止時間はできる限り小さくしたいところですが、MySQLのデータが増えるとmysqldumpだけでもかなりの時間を使います。

バージョンアップの作業では基本的にgitリポジトリをいじることはないため、実はmysqlを停止してからdata_dir以下をバックアップするだけで十分なことがほとんどです。ただし今後のアップデートで変わる可能性があるのでバックアップをどの程度行う必要があるかは各自で確認してください。

またGitLabのリポジトリ上に.ruby-versionがあります。Rubyのコンパイルにはそれなりに時間がかかるので、次に使いたいGitLabのバージョンで使うRubyは予めインストールしておきましょう。rbenvであれば複数のバージョンをインストールする事が可能です。新しいバージョンのRubyをインストールする際は、そのRubyのバージョンでbundlerのインストールをすることを忘れないようにしましょう。

まとめ

紹介したように、GitLabは認証について柔軟な設定ができます。またGitHubが障害になっても業務が行えたり、自社でホストしているためリポジトリのダウンロードが高速に行えるメリットがあります。ソースコードが読みやすいOSSなので、必要に応じてパッチを当てる事も比較的容易です。バージョンアップで気を付けるべき点などもありますが、皆さんの会社でも社内のリポジトリ管理にGitLabを使ってみてはいかがでしょうか。

次回は弊社が誇るおもしろアルバイターのhakatashiがおもしろエントリーを公開してくれます。hakatashi の検索結果 - pixiv inside で是非予習してからご覧ください!