前記事は、第4回 さまざまなジョブ(2) その他の抑えておきたいツールの紹介を紹介した。CIツール導入ガイド 第5回は、GitLabを利用し、CIサーバーを構築する手順を紹介する。
GitLab は GitHub クローンとして有名だが、現在は CIツールとしての機能が実装されている。今回は GitLab をインストールし、実際に CIサーバーを構築してみよう。
インストール環境
gitLab はさまざまな環境にインストール可能だが、今回は CentOS7 を利用する事にした。まずはCentOS7 を minimal インストールしたサーバーを用意して欲しい。もちろん仮想マシンでも構わない。ただし、インストール時にかなりのメモリを消費するので、最低でも8GB 程度のメモリを利用可能な環境を用意して頂きたい。AWS を利用するなら、 t2.large 程度がお勧めだ。HDD容量は今回の検証だけなら20GBもあれば十分だ。
GitLab本体のインストール
GitLab は標準の yum リポジトリには含まれていないが、以下の手順で簡単にインストール可能だ。<サイトのドメイン名>の部分には、このサーバーのドメイン名を指定して欲しい。IPアドレスでもオーケーだ。なお、インストールの終了と同時に HTTP アクセスが可能になるので注意して欲しい。通常、CIサーバーはイントラネット内に設置する事が多いだろう。しかしAWSのようなクラウドサービスを利用するなら、事前にファイヤーウォール等で特定 IPアドレスからのみ利用可能なように設定しておこう。
curl -LsS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash EXTERNAL_URL="http://<サイトのドメイン名>" sudo yum install -y gitlab-ce
インストールには少し時間が掛かる。AWS の t2.large で試した所、5分程度掛かった。インストールが終了すると、以下のような画面が表示される。
Running handlers:
Running handlers complete
Chef Client finished, 432/613 resources updated in 03 minutes 31 seconds
gitlab Reconfigured!
*. *.
*** ***
***** *****
.****** *******
******** ********
,,,,,,,,,***********,,,,,,,,,
,,,,,,,,,,,*********,,,,,,,,,,,
.,,,,,,,,,,,*******,,,,,,,,,,,,
,,,,,,,,,*****,,,,,,,,,.
,,,,,,,****,,,,,,
.,,,***,,,,
,*,.
_______ __ __ __
/ ____(_) /_/ / ____ _/ /_
/ / __/ / __/ / / __ `/ __ \
/ /_/ / / /_/ /___/ /_/ / /_/ /
\____/_/\__/_____/\__,_/_.___/
Thank you for installing GitLab!
GitLab should be available at http://???.???.???.???
For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
Verifying : gitlab-ce-11.1.4-ce.0.el7.x86_64 1/1
Installed:
gitlab-ce.x86_64 0:11.1.4-ce.0.el7
Complete!
http://???.???.???.???
と記載してある部分は、実際には GitLab のURLになる。このURLにブラウザからアクセスすると初期パスワードの設定画面になるので、適当なパスワードを設定しよう。
パスワードの設定が完了すると、ログイン画面に移動する。ユーザー名を root 、パスワードを今設定したパスワードでログインできる事を確認しよう。
ログインが成功すると以下のような画面に移動する。
Runner のインストール
Runner とは色々なジョブの実行を制御するツールだ。以下のようにインストールする。
curl -LsS https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash sudo yum install -y gitlab-ci-multi-runner
Docker のインストール
Docker とは仮想環境を作成、実行するためのプラットフォームだ。CI のさまざまなジョブを実行する時は、冪等性（べきとうせい）が要求される。冪等性とはある操作を何度行っても同じ結果になる事を示す概念だ。ジョブを実行する時の OS の状態が毎回異なると、冪等性が保たれない可能性がある。Docker では簡単に仮想環境を初期状態に戻す事ができるため、CIのジョブを実行する環境として便利だ。GitLab の実行環境として Docker が対応しているのでインストールしておこう。
インストールは以下の通りである。
sudo yum install -y docker
インストールが完了したら、GitLab が Docker を利用できるようにグループの設定を行う。
sudo groupadd docker sudo gpasswd -a gitlab-www docker
最後に自動起動の設定を行い、docker サービスを起動しよう。
sudo systemctl enable docker.service sudo systemctl start docker
実行環境の作成と起動
Docker をインストールしたので、次に Docker でコンテナを作成しよう。コンテナとは Docker上で動作するそれぞれの環境の事であり、ここで作成したコンテナが各種ジョブを実行する実行環境となる。最初にコンテナで利用するOSのイメージをインストールしておく必要があるので、以下の手順で CentOS7 のコンテナを利用可能にしよう。
sudo docker pull centos:centos7
次にコンテナを起動し、ログインしてみよう。以下のコマンドでコンテナの起動と、そのコンテナへのログインを同時に実行できる。
sudo docker run -it centos:centos7 /bin/bash
上記コマンドを実行し、プロンプトが変化したらログインに成功している。ここではコンテナを起動して root でログインしているのだが、 ESXi や Hyper-V 等の他の仮想環境を利用した事があると、起動までのあまりの速さに驚くかも知れない。これは Docker が Linux コンテナ技術を利用した仮想環境であるためだ。詳細は Docker の関連記事等を参照して頂きたい。
各ツールのインストール
コンテナにログインした状態で、利用するツールをインストールしよう。今回は第3回で利用した PHPMD, PHPCPD, PHPUnit をインストールする事にする。コンテナ内に居る事を確認し、以下の手順を実行しよう。
PHP本体のインストール
yum install -y php php-xml
composer のインストール
curl -LsS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin
各ツールのインストール
composer.phar global require phpmd/phpmd composer.phar global require sebastian/phpcpd composer.phar global require phpunit/phpunit
3つのツールがインストールされた事を確認するために、実行可能ファイルが保存されているディレクトリを見てみよう。以下のように4つのシンボリックリンクが存在していれば成功している。
# ls -l ~/.composer/vendor/bin/ total 0 lrwxrwxrwx. 1 root root 34 Aug 15 23:39 pdepend -> ../pdepend/pdepend/src/bin/pdepend lrwxrwxrwx. 1 root root 26 Aug 15 23:39 phpcpd -> ../sebastian/phpcpd/phpcpd lrwxrwxrwx. 1 root root 28 Aug 15 23:39 phpmd -> ../phpmd/phpmd/src/bin/phpmd lrwxrwxrwx. 1 root root 26 Aug 15 23:40 phpunit -> ../phpunit/phpunit/phpunit
実行環境の保存
これまでの手順でジョブの実行環境が整った。次に今作った実行環境を保存しておこう。Docker ではコンテナ内で行った作業は明示的に保存しない限り保存されない。まずは CTRL+P, CTRL+Q を順に押してコンテナを起動したまま抜けよう。exit コマンドを実行したり CTRL+D を押してログアウトすると、変更が保存されないままコンテナが終了してしまうので要注意だ。
ホストOS に戻ったら、
sudo docker ps
コマンドを実行する。これは現在実行中のコンテナの一覧を表示するコマンドだ。実行結果は以下のようになる。
$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 90d074f06d57 centos:centos7 "/bin/bash" 10 minutes ago Up 10 minutes serene_mestorf
一番左に表示されている「コンテナID」は、実行中のそれぞれのコンテナに紐づくIDだ。今はひとつのコンテナだけが立ち上がっているので上記のような感じで表示される。
コンテナID を確認したら、
sudo docker commit
コマンドを利用してコンテナ を保存する。
sudo docker commit <コンテナID> <名前>
コンテナID は
docker ps
コマンドで取得したコンテナIDを、名前にはこのコンテナの名前を指定する。今回は phptest という名前にしておこう。コンテナIDが 90d074f06d57 だとしたら、コマンドラインは以下の通りだ。
sudo docker commit 90d074f06d57 phptest
無事保存できたら今実行しているコンテナは終了して構わない。以下のコマンドで終了しよう。
sudo docker stop <コンテナID>
Runner の登録
ジョブを実行するコンテナが作成できたので、Runner を作成し、GitLab に登録しよう。まずWEB画面から上部メニューのスパナアイコンをクリックし、左サイドメニューから Runners をクリックしよう。URLは /admin/runners になる。
Setup a shared Runner manually
という項目にトークンが表示されるので、このトークンをメモしておこう。
次にコマンドラインに戻り
gitlab-ci-multi-runner
を実行する。実行中に色々と入力が要求されるが、以下のように進めていく。
$ sudo gitlab-ci-multi-runner register Running in system-mode. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://<サーバーのドメイン名>/ Please enter the gitlab-ci token for this runner:Please enter the gitlab-ci description for this runner: [(概要を入力するのだが、デフォルトではドメイン名が表示されている)]:<改行> Please enter the gitlab-ci tags for this runner (comma separated): <環境に付けるタグ名> Whether to run untagged builds [true/false]: [false]:<タグ無しのビルドを実行するかどうか> Whether to lock Runner to current project [true/false]: [false]:<改行> Registering runner... succeeded runner=nsWDyXM_ Please enter the executor: parallels, ssh, kubernetes, docker, docker-ssh, shell, virtualbox, docker+machine, docker-ssh+machine: <実行環境の種類> Please enter the default Docker image (e.g. ruby:2.1): <実行するDockerのイメージ> Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
<>内が入力する部分だ。<環境に付けるタグ名>と<実行するDockerのイメージ> には、
phptest
と入力して欲しい。<タグ無しのビルドを実行するかどうか>には
true
を、<実行環境の種類> には
docker
と入力する。
実際に入力したイメージは以下のような感じになる（’?’の部分はサイトごとに異なる）。
$ sudo gitlab-ci-multi-runner register Running in system-mode. Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/): http://???.???.???.???/ Please enter the gitlab-ci token for this runner: ???????????????????? Please enter the gitlab-ci description for this runner: [??????????????????????????????????????????????]: Please enter the gitlab-ci tags for this runner (comma separated): phptest Whether to run untagged builds [true/false]: [false]: true Whether to lock Runner to current project [true/false]: [false]: Registering runner... succeeded runner=gduponxa Please enter the executor: docker, docker-ssh, parallels, shell, virtualbox, docker-ssh+machine, ssh, docker+machine, kubernetes: docker Please enter the default Docker image (e.g. ruby:2.1): phptest Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
登録完了後に /admin/runners をリロードすると、以下のスクリーンショットのように作成した Runner が表示されている。
まとめ
ここまでで構築作業は完了だ。次回は検証用のプロジェクトを作成し、実際に動作させてみよう。（第6回 CIサーバーを使ってみよう 第5回で構築したGitLabで、実際にCIを行った様子の紹介）
社内サーバにリモートリポジトリを作るのも一つですが、「開発にまつわる面倒事」をこの際全部、tracpath（トラックパス）に任せてみませんか？
バージョン管理サービス・プロジェクト管理サービスの「tracpath（トラックパス）」では、
ユーザー５名、リポジトリ数３つまで、無料で利用可能です。
さっそく実務でも使って見ましょう。
自らも開発を行う会社が作ったからこそ、開発チームの「作る情熱」を支える、やるべきことに集中出来るサービスになっています。
エンタープライズ利用が前提のASPサービスなので、セキュリティも強固です。
