10分で出来る!オンプレ版GitLab導入クイックスタートガイド

はじめに

本記事では、Ubuntu 16.04 LTS に GitLab Enterprise Edition (以下、EE) を導入する手順を示します。Enterprise という名前ではありますが、基本機能のみの Core プランの利用はなんと 無料（Free）で使うことが出来ます。Core プランでもチーム開発に必要な機能のほとんどにアクセスできるので、まずはここからお試ししてみましょう。インストールパッケージが非常によく出来ているので、導入はとても簡単です。最短5行、10分程度で終わります。

GitLab には EE の他に CE (Community Edition) というバージョンがありますが、こちらは MIT License の下で開発されているオープンソースソフトウェアという位置づけであり、機能的には EE の Core プランで提供されるものと変わりません。
Core より上の有料プラン機能を使いたくなった際のアップグレード作業が簡単なので、特に縛りのない業務プロジェクトなら、EE を導入するべきでしょう。
GitLab CEはオープンソースソフトウェアだけをダウンロードしたい場合にお勧めします。そのため本記事ではEEのみを扱っています。CEとEEの違いについては、Gitlab社の情報を参照ください。

また、GitLab.com で提供されている SaaS 版もあります。プランの名前こそ違う¹　ものの、基本的に self-hosted 版と機能の違いはありません。今回は業務にそのまま使うことを見据え、自社サーバ内にオンプレで環境構築するケースを想定して self-hosted 版の例を紹介します。

さて、GitLab の導入には、公式にも利用を強く推奨されている GitLab Omnibus Package を使います。こちらは GitLab 本体だけでなく、その運用に必要な外部アプリケーションの導入とその設定・管理まで一括して行える強力なパッケージです。

検証は Ubuntu 16.04 LTS で行っていますが、Ubuntu 18.04 LTS や 20.04 LTS でも同様の手順でインストールできます。

Ubuntu 以外のディストリビューション、AWS や Azure といったクラウドプロバイダをお使いの方はGitLab社の公式のドキュメントを参照してください。

事前準備

GitLab 動作要件

ソース：https://docs.gitlab.com/ee/install/requirements.html
利用可能な Linux ディストリビューション
- Ubuntu
- Debian
- CentOS
- openSUSE
- Red Hat Enterprise Linux
- Scientific Linux
- Oracle Linux
2 core 以上の CPU + 8GB 以上の RAM
- ～100 ユーザまで。
  それ以上の規模になる場合の動作要件は以下を参照してください。
  https://docs.gitlab.com/ee/install/requirements.html#cpu

Red Hat Enterprise Linux、Scientific Linux、Oracle Linuxの3つのディストリビューションへは、CentOS のガイドにしたがって導入してください。

その他に必要なもの

GitLab にアクセスするためのドメイン名 (DNS登録済みのFQDN)
サーバのIPアドレス直打ちでもアクセスできますが、ドメイン名を用意しておくと SSL 証明書の取得までインストーラが自動でやってくれるので、準備しておくことを推奨します。

インストール

ソース：https://about.gitlab.com/install/?version=ce#ubuntu

依存パッケージのインストール

curl, openssh-server, ca-certificates
$ sudo apt-get update $ sudo apt-get install -y curl openssh-server ca-certificates
Postfix ( GitLab からの通知メール送信用. 別のシステムでも良い)
$ sudo apt-get install -y postfix
インストール途中にメールサーバの設定形式について訊かれるので、Internet Site を選択し、GitLab をホストするサーバの外部 DNS 名 (メールの宛先から見て IP アドレスの正引きができるもの) を設定してください。送られてくるメールの @ 以下になります。
通常は、用意した GitLab にアクセスするためのドメイン名と同じでよいでしょう。 SMTP を利用するので、25番ポートが開いているかも確認しましょう。
※別のメール送信システムを使う場合はスキップして、以下の手順に従ってください。
-> https://docs.gitlab.com/omnibus/settings/smtp.html

GitLab のインストール

GitLab リポジトリの取得
$ curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
GitLab のインストール
$ sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee
ここで "https://gitlab.example.com" を事前に用意した FQDN に書き換えてください。
また EXTERNAL_URL オプションを用いる際には、80番, 443番のポートが開いているか確認してください。その理由は次項の通りです。
SSL/TLS 証明書の設定について
GitLab のインスタンスへは, ブラウザを用いて HTTPS 通信でアクセスします。このため、SSL/TLS 証明書を取得して、サーバに設定する作業が必要です。
GitLab Omnibus Packeage の標準では、Let’s Encrypt² というフリー認証局サービスを利用して、SSL 証明書の取得が自動で行われます。
この時に認証局と通信をするため、80番, 443番のポートが開いている必要があるのです。なお、Let’s Encrypt によるSSL証明書は90日で期限が切れるため、定期的に再取得する必要があるのですが、Omnibus Package ではこの自動更新をインストーラが設定してくれます。
デフォルトの更新日付は毎月4日の午前0時です。変更したい場合は、以下の手順に従ってください。
-> https://docs.gitlab.com/omnibus/settings/ssl.html#automatic-lets-encrypt-renewal
また、ドメイン名の設定を行わない場合や、自前のセキュリティ証明書を用いる場合は EXTERNAL_URL のオプションをスキップして apt-get install した後、以下の手順に従って、手動で設定してください。
-> https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https

3. root でログインテスト

それでは、Webブラウザに設定した FQDN もしくはサーバの IP アドレスを入力して、GitLab にアクセスしてみましょう。
正しくインストールされていれば、以下のようなパスワードの設定画面にリダイレクトされるはずです。

ここで設定したものがユーザ名 root の初期パスワードとなります。
入力後、通常のログイン画面にリダイレクトされるので、root でログインしてみましょう。

無事ログインできれば、GitLab のインストール作業は終了です。環境にもよりますが、ここまでで大体10分程度だと思います。導入は非常に簡単ですね。

動作確認

ユーザの作成

続いて、実際に GitLab の機能が使えるか試していきます。まずは、作業を行うユーザを作成してみましょう。
管理メニューの Add people を選択し、フォームに Name, Username, Email を入力、Access level を Admin にしてユーザを作成します。

この時、メールサーバが正しく設定されていれば Email に入力したアドレスに招待メールが届くので、メール記載のリンクから作業ユーザでログインしなおします。
root と同じようにパスワードの再設定を求められますので設定します。

プロジェクトの作成

ログインできましたか？
それでは、Admin ユーザの管理画面から Create a project を選択し、プロジェクトを作成してみましょう。ここでは MyProj を作ってみました。

ここで、画面上部に SSH 経由でリモートリポジトリに変更を加えるなら SSH 鍵を登録するよう案内が出ているので、ついでに設定しておきます。もちろん、この設定は後からでも可能です。

Add SSH key ボタンを押して、Key エリアに端末の SSH 公開鍵をコピペ、Add key ボタンを押せば、登録完了です。

これで、SSH 経由でリモートリポジトリにアクセスできるようになりました。

Git リポジトリの動作確認

それでは、プロジェクトのリポジトリをローカルに clone してみましょう。
プロジェクトメニューから Clone を選び、Clone with SSH 側のテキストをコピーします。

その後、SSH 設定済みのターミナルからアクセスしてみます。

$ git clone git@XXXX:Rigel/myproj.git
Cloning into 'myproj'...
The authenticity of host 'XXXX' can't be established.
ECDSA key fingerprint is SHA256:XXXX.
Are you sure you want to continue connecting (yes/no)? yes 
Warning: Permanently added 'XXXX' (ECDSA) to the list of known hosts.
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

$ ls
myproj

無事 clone できてますね。

では、ローカルリポジトリに変更を加えて commit、さらに push してみます。

$ cd myproj/
$ touch README.md
$ ls
README.md

$ git add README.md
$ git commit -m "initial commit"
[master (root-commit) 3852530] initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@XXXX/myproj.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

ブラウザ上でブランチの状態を確認すると……

無事反映されてますね！
これで GitLab を使った開発の準備は整いました。

CI/CD のテスト: GitLab Pipeline でビルドの自動化を試してみる

とは言っても、これまでは git としての機能を確認したにすぎません。
本記事の最後に、GitLab ならではの強みである、CI/CD 機能も試してみましょう。今回は、GitLab Pipeline というジョブ実行機能を使って、コードのビルドを自動化してみます。

具体的には、これまで設定した GitLab とは別に gitlab-runner というジョブ実行器を立ち上げ、GitLab のリポジトリに push が行われた際に、予め設定したジョブを実行させるという構成です。

まずは gitlab-runner のインストールを行います。
なお、ディストリビューションによって行う必要のある操作が異なるので、Ubuntu 以外のディストリビューションの方は公式のドキュメントを参照してください。
-> https://docs.gitlab.com/runner/install/linux-repository.html

# for Ubuntu
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

$ sudo apt-get install gitlab-runner

続いて、gitlab-runner と GitLab のインスタンスを連携させます。
コマンドを打つ前に、Admin area -> Overview -> Runners と進み、Set up a shared Runner manually の欄にあるアクセストークンを控えておきましょう。

また、本記事では、ジョブの実行先として docker コンテナを選択しています。
docker がインストールされていない場合はインストールするか、別の exector でお試しください。
別の exector についてはこちらを参照してください。
-> https://docs.gitlab.com/runner/executors/README.html

$ sudo gitlab-runner register
Runtime platform                                    arch=amd64 os=linux pid=21651 revision=c5874a4b version=12.10.2
Running in system-mode.                            

## GitLab インスタンスの URL を入力                                        
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://XXXX/

## アクセストークンを入力
Please enter the gitlab-ci token for this runner:
YYYY 

## runner の説明を入力
Please enter the gitlab-ci description for this runner:
[ZZZZ]: myproj-runner  

## タグを登録 (※ジョブを実行する runnner を制御するのに使う id みたいなもの)
Please enter the gitlab-ci tags for this runner (comma separated):
myproj-tag

Registering runner... succeeded                     runner=2-3CuuzL

## executor を選択
Please enter the executor: docker, ssh, docker+machine, docker-ssh+machine, kubernetes, custom, docker-ssh, parallels, shell, virtualbox:
docker

## ジョブ側で docker image が指定されていない時の default を指定
Please enter the default Docker image (e.g. ruby:2.6):
ruby:2.6

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

これで GitLab と gitlab-runner の連携は終了です。

では、実際にジョブを定義していきましょう。
gitlab-runner では、リポジトリのルートにある .gitlab-ci.yml に定義を書いておくことになっています。詳しい .gitlab-ci.yml の書き方は公式ドキュメントを参照ください。

1から書いてもいいですが、テンプレートが用意されているので、本記事ではそちらを使うことにします。

リポジトリのルートで New File を選択して……

Select a template type で .gitlab-ci.yml を選択し……

Apply a template でテンプレートを選択します。
今回は C++ を選択してください。

.gitlab-ci.yml が作成出来たらローカルに pull して、以下の変更を加えます。

## before
  script:
    - ./runmytests.sh

## after
  script:
    - ./mybinary

続いて、同じくプロジェクトのルートに helloworld.cpp を作成します。

#include <iostream>
int main()
{
    std::cout << "Hello, World!n";
    return 0;
}

出来たら、この2点の変更を commit して push してください。
push 後、プロジェクトの CI/CD -> Pipelines を確認すると……？

おめでとうございます！
変更内容が自動でビルドされ、以下のテスト出力を得ることができました！
(ビルド時の出力結果は Stages から見られます)

1 Running with gitlab-runner 12.10.2 (c5874a4b)
2   on myproj-runner UwLVRMsq

3
Preparing the "docker" executor
00:03 
4 Using Docker executor with image gcc ...
5 Pulling docker image gcc ...
6 Using docker image sha256:7bba82d803294cfecf3eeda9e93f2758c9ea0cb15b2e967b229ae91192178a92 for gcc ...

8
Preparing environment
00:01 
9 Running on runner-uwlvrmsq-project-1-concurrent-0 via ZZZZ...

11
Getting source from Git repository
00:02 
12 Fetching changes with git depth set to 50...
13 Reinitialized existing Git repository in /builds/Rigel/myproj/.git/
14 Checking out e233f40f as master...
15 Removing mybinary
16 Skipping Git submodules setup

18
Restoring cache
00:01 

20
Downloading artifacts
00:01 
21 Downloading artifacts for build (24)...
22 Downloading artifacts from coordinator... ok        id=24 responseStatus=200 OK token=kX6Wz4hx

24
Running before_script and script
00:02 
25 $ ./mybinary
26 Hello, world!

28
Running after_script
00:01 

30
Saving cache
00:02 

32
Uploading artifacts for successful job
00:01 
34 Job succeeded

ビルド成果物は、Artifacts メニューから、GUI を介してダウンロード可能です。

以上で全ての作業は完了です。
お疲れ様でした！

まとめ

本記事では、GitLab Omnibus Package を利用して、Ubuntu に GitLab-EE を導入する方法と、gitlab-runner を導入してビルドの自動化をテストする方法を扱いました。

冒頭にも書いた通り、Omnibus Package が非常に良く作られており、導入までは本当にあっという間です。
ここまで高機能な開発環境を簡単に利用できるのは驚異的、『そろそろモダンな環境に移行しないとな……』とお考えの方は、是非サクッと試してみてください！

弊社ブログには GitLab 自体の使い方や、旧い SVM 環境から GitLab へリポジトリを移行する方法について解説する記事も用意していく予定です。ぜひブログの購読をお願いします。

脚注

GitLab EE self-hosted 版が Core/Starter/Premium/Ultimate に対して、SaaS 版が Free/Bronze/Silver/Goldです。値段とそれに応じた機能はほぼ同じです。
https://letsencrypt.org/

重複コード管理

修正もれ確認

はじめに

事前準備

GitLab 動作要件

その他に必要なもの

インストール

依存パッケージのインストール

GitLab のインストール

3. root でログインテスト

動作確認

ユーザの作成

プロジェクトの作成

Git リポジトリの動作確認

CI/CD のテスト: GitLab Pipeline でビルドの自動化を試してみる

まとめ

脚注

重複コード管理

修正もれ確認

10分で出来る!オンプレ版GitLab導入クイックスタートガイド

はじめに

事前準備

GitLab 動作要件

その他に必要なもの

インストール

依存パッケージのインストール

GitLab のインストール

3. root でログインテスト

動作確認

ユーザの作成

プロジェクトの作成

Git リポジトリの動作確認

CI/CD のテスト: GitLab Pipeline でビルドの自動化を試してみる

まとめ

脚注

関連記事