GitLabセルフホスティングの話

弊社ではクライアントとのソースコード共有や、Wikiによるドキュメントの共有のためにGitLabをセルフホスティングしている。

GitHubがあるのにセルフホスティングするのは時代に逆行していると思われるが、動機やメリットもある。

そしてこのGitLabセルフホスティングは、いろいろ工夫をしながら実質的に月額500円程度のコストで実現している。

その辺の話をとりとめもなくしてみようと思う。GitLabの自社運用を検討している方の参考になれば嬉しい。

GitHubのデメリット - なぜGitLabセルフホスティングか？ ​

リポジトリ共有で課金される(?) ​

もしかしたら違うかもしれないが、GitHubでは社外のコラボレーターをリポジトリに招待すると、その分の料金も課金されると読んだ。

プロジェクトによっては10人以上のユーザーにリポジトリを共有することもあり、大変な金額になる。backlogという可能性もあったが弊社にはそれでも高額だ。これがGitLabをセルフホスティングした一番の理由だった。

非エンジニアにはハードルが高い ​

ソースコードの共有と同時にWikiによるドキュメントも共有することが多い。

GitHubは、エンジニアであればすでにアカウントを持っている可能性が高いが、共有する相手は必ずしもエンジニアではない。アカウントを開設してもらうハードルは非常に高い。

一方、GitLabであればアカウントをこちらで作成し、パスワードだけ設定してもらうような運用が可能だ。

日本語対応されていない ​

GitHubのGUIは基本的に英語のみだが、GitLabは大部分が日本語に対応している。

日本人のクライアントにとってはGitLabの方が親しみやすい。

システム構成の全体像 ​

とにかく安価に、それでいてできるだけ安定運用するため、次のような構成になっている。

どうやって稼働しているか ​

社内オンプレミス ​

これも時代の流れに逆行するが、社内の「自称」データセンターで稼働している。

退役したPCをサーバに仕立てて、通常のネット回線を用いているのでランニングコストは実質電気代だけである。

GitLabはかなりパワフルなRuby on Rails製のアプリケーションなので、快適に使うにはそこそこのパワーが要る。

AWSではもちろん高く付くし、VPSでもそれなりの料金になってしまう。この退役PCサーバの性能は、VPSなら月2〜3万円程度のプランに匹敵する。とても安上がりに稼働している。

Proxmox + Docker ​

もちろんベアメタルなLinuxサーバに直接インストールするような運用はしていない。

まずはPCサーバにProxmoxをインストールし、その上でコンテナとしてUbuntuを動かす。その上でDocker(Docker Compose)によりGitLabシステム群を稼働させている。

NASへの定期バックアップ ​

Proxmoxは本当に秀逸な仮想化プラットフォームで、バックアップ機能も標準で備えている。コンテナイメージを1日4回、NASにバックアップしている。

後述するが、Proxmoxであればディスクイメージのスナップショットも簡単に撮れるので、GitLabのアプリケーションアップグレード作業も安心して進められる。

GitLab自身のバックアップ機構 ​

なお、バックアップについてはGitLab自体も高精度なアプリケーションバックアップ機構を備えている。

OSイメージバックアップとアプリケーションバックアップ、両方あればさらに安心である。

実際、このバックアップ機能に助けられたことがある。稼働時間に応じてリソースがどんどん圧迫され、サービスが頻繁に停止してしまう問題に見舞われたことがあったのだ。最終的にGitLabをクリーンインストールし、アプリケーションバックアップからの復元作業をしたところ、事態が解決したのだ。

オールインワンのDockerイメージ ​

GitLabにはとても素晴らしいオールインワンのDockerイメージがある。

sameersbn/gitlab

GitLabは複雑なRuby on Railsアプリケーションで、セットアップの難易度が高い。昔になるが、挫折したこともある。

sameersbn/gitlabは非常によくできていて、雛形のdocker-compose.ymlにPostgresをはじめ必要なミドルウェアが記述済みとなっている。

あとは.envに環境変数によるオプションを指定するだけで、自分だけのGitLabを手にいれることができる。

SMTP - メール送信は外部サービス ​

メール送信機能は昨今、あまりに自社運用のハードルが高い。

弊社では全サービスを通してsendgridを利用しており、GitLabでもそれを使う設定にしている。

GitLabのアップグレード ​

上記のDockerイメージは現在まで安定してバージョンアップにも追従してくれており、大変ありがたい。

数ヶ月に一度、アップグレードを行うようにしている。Proxmox上でOSのイメージスナップショットを取り、アップグレードができたらスナップショットを統合する。

たまにアップグレードを忘れていて、バージョンを大きく跨いだアップグレードを行って失敗(GitLabが起動しない)することがある。

その場合もスナップショットをロールバックすれば元通りなので安心である。

ちなみにGitLabにはアップグレードのバージョンパスについて専用のガイドがある。アップグレードに失敗するとこのツールのお世話になる。

障害復旧 ​

社内にはProxmoxが稼働しているサーバが他にも数台ある。最悪、休眠中のPCにProxmoxをインストールすればよい。

なので、もしGitLabを稼働させているハードウェアに障害が発生しても、OSのイメージバックアップから数十分程度で復旧できる。

どうやって社外に公開しているか ​

こんな感じでアプリケーション自体は格安に、SREはゆるゆるながら少人数への提供なのでそこそここなしている。

ここからは社外のユーザーにどうアクセスを可能にしているかの話だ。

GitLabがサービス提供するポート ​

次のポートを外部に公開する必要がある。

• SSH (22) - Git用
• HTTP (80) - HTTPSにリダイレクト
• HTTPS (443) - Web GUI用

nginx + lego + Route53によるSSL対応 ​

sameersbn/gitlabが提供するサービスは素のHTTPなので、SSL化が必要だ。

まずSSL証明書だが、Let's EncryptのCLIクライアントのlegoを使っている。

legoはAWSのDNSサービスRoute53とAPI連携してドメインの所有権を証明し、SSL証明書を発行・更新してくれる。

その証明書を利用するnginxをリバースプロキシとして設置する。これは単純にDockerhubの公式nginxイメージを利用し、GitLabと同じdocker-compose.ymlに追記している。

出島サーバ - リバースプロキシVPS ​

先述の通り、GitLabとnginxは社内で稼働しており、これを外部にも公開するため、月500円程度の安いVPSを契約している。

そして社内のサーバからautosshでVPSに常時SSH接続し、ポート22、80、443をリバーストンネルで公開する。

このようなVPSの使い方を長崎にあった出島になぞらえて「出島サーバ」と個人的には呼んでいる。

ポート22のリバーストンネルは、出島サーバ自体のSSH接続と競合する。そのため出島サーバのSSHポートを他に変更してある。

セルフホスティングは必要か？ ​

冒頭でも書いたが、クラウドやSaaSがこれだけ充実している時代にセルフホスティングは時代に逆行していると思う。

「オープンソースだから自社運用すればほとんどタダ」と目論んでも障害発生時のコストや経済損失を考えると、毎月料金を払った方が結局はよい。

それでもセルフホスティングする意味は何か。

インフラのトレーニング ​

クラウドがどんどん便利になっている。

弊社でも簡単なサービスはFirebaseで提供するし、止められないサービスにはAWSを用いCDKで管理している。

これは一方で、伝統的なサーバ構築スキルを使う機会が減っていることを意味する。

クラウド時代だからといって「ネットワークやサーバのことはわかりません」では技術的に脆弱と言わざるを得ない。

トレーニングの一環として、普段使うサービスの一部をセルフホスティングしてみることに価値はある。

工夫が楽しい ​

何より、安価にできるだけ安定運用するにはどうするか、情報収集して試行錯誤するのは楽しい。