CIツール導入ガイド 第5回 CI サーバーの構築(GitLabを利用し、CIサーバーを構築する手順)【PHP編】

By 2018-08-23 Development, DevOps

前記事は、第4回 さまざまなジョブ(2) その他の抑えておきたいツールの紹介を紹介した。CIツール導入ガイド 第5回は、GitLabを利用し、CIサーバーを構築する手順を紹介する。

GitLab は GitHub クローンとして有名だが、現在は CIツールとしての機能が実装されている。今回は GitLab をインストールし、実際に CIサーバーを構築してみよう。

インストール環境

gitLab はさまざまな環境にインストール可能だが、今回は CentOS7 を利用する事にした。まずはCentOS7 を minimal インストールしたサーバーを用意して欲しい。もちろん仮想マシンでも構わない。ただし、インストール時にかなりのメモリを消費するので、最低でも8GB 程度のメモリを利用可能な環境を用意して頂きたい。AWS を利用するなら、 t2.large 程度がお勧めだ。HDD容量は今回の検証だけなら20GBもあれば十分だ。

LitLab本体のインストール

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(トラックパス)」を提供している株式会社オープングルーヴが運営しています。

エンタープライズ向け Git / Subversion 導入や DevOps による開発の効率化を検討している法人様必見!

tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。

クラウド型バグ管理・バージョン管理ソフトの「tracpath(トラックパス)」を提供しているオープングルーヴが運営しています

You Might Also Like

No Comments

    コメントを残す

    このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください