Gitlab CI/CDを使って開発・本番環境へのデプロイを自動or手動(Gitlabの画面から)で行えるようにする

Gitlab CI/CDを使って開発・本番環境へのデプロイを自動or手動(Gitlabの画面から)で行えるようにする

諸事情が有り、Gitlabにpushと同時に対象の環境へ自動的にデプロイをさせたり、手動でデプロイさせる際にGitlab上でボタンクリックで行わせたいということがあった。 で、Gitlab CI/CDを用いてブランチごとに各環境へのデプロイを行わせる事にした。Gitlab CI/CDでは実行する処理をそのままbashスクリプトで書けるので、デプロイの方法は一般的であろうgit clone(fetch)後にその内容をrsyncでssh越しに同期させる方式を取る。

今更説明せんでもいいかなと思うのだけど、Gitlab CI/CDを使ってデプロイをする際は以下の役割(機能)を持つノードが必要になってくる。

  • Gitlabサーバ … Gitlabを動作させているサーバ
  • Gitllab CI Runner … Gitlab CI/CDで、実際にビルドやテスト、デプロイを実行するノード(一応Gitlabサーバに同居させることができるけど、動作にメモリとか結構食うので非推奨らしい)。動作方法はDocker使ったりOSのシェルを使ったり選べる
  • デプロイターゲット … 実際にデプロイを行うターゲット

図にしてみると、以下のような感じ。 やってみるまでは難しく考えてたのだけど、単にgit pushと同時にキックしてほしいシェルスクリプト(コマンド)をymlに書いておいて、それをRunnerというノードがキックしてテストやらデプロイをしてくれると考えればいいようだ。

一応、今回は テスト環境に新しいサーバ構築するのめんどくさいので GItlabとGItlab CI Runnerは同居させて設定を進めていく。まぁ、お金なくてRunner稼働用のインスタンス用意できないパターンもあるだろうし、良いとしよう。 あと、Gitlab CI RunnerはDockerを使う方法がよく使われているようだけど、鍵認証でsshを利用する際などに楽をしたいのでOSのシェルをそのまま利用させることにする。ちなみに、OSはCentOS 7.4、Gitlabのバージョンは10.7を使用する。 基本的には公式手順の通りに進める。

1. Gitlab CI Runnerをインストールする

前もって記述したように、今回はGitlabとGitlab CIは同居させることにする。 対象のサーバで以下のコマンドを実行し、Gitlab CI Runnerをインストールする。

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
sudo yum install -y gitlab-runner

パッケージインストール後、自動的にgitlab-runnerが立ち上がるようになる。

2. GitlabにRunnerを登録する

Gitlab CI Runnerがインストールできたら、GitlabにRunnerとして登録する。 最初に、WebのGitlab管理画面から OverView > Runners にアクセスし、tokenの値を確認する。

tokenの値を確認したら、Gitlab CI Runnerをインストールしたノード(ここではGitlabノード)で、以下のようにコマンドを実行する。 実行中にgitlabのurl、tokenを聞かれるので入力し、それら以外は今回はデフォルトのままにする(後から修正可能)。

gitlab-runner register
# gitlab-runner register
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://test-gitlab.blacknon.local/
Please enter the gitlab-ci token for this runner:
XXXXXXXXXXXXXXXXXXXX
Please enter the gitlab-ci description for this runner:
[test-gitlab.blacknon.local]:
Please enter the gitlab-ci tags for this runner (comma separated):
shell
Whether to lock the Runner to current project [true/false]:
[true]:
Registering runner... succeeded                     runner=qgmgZPcn
Please enter the executor: docker, shell, docker+machine, docker-ssh, parallels, ssh, virtualbox, docker-ssh+machine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

この時、GitlabのSSL証明書が自己署名証明書だとコケるので、その場合は以下のコマンドを実行して対象の証明書を信用して処理をしてもらうようにする。

mkdir -p /etc/gitlab-runner/certs
openssl s_client -connect DOMAIN:443 -showcerts < /dev/null | openssl x509 -outform PEM > /etc/gitlab-runner/certs/DOMAIN.crt

実行後、再度Webの管理画面を確認したら登録したRunnerが確認できるはずだ。 登録後、ちゃんと対象のRunnerでリポジトリの処理をするよう許可するのを忘れないようにしよう。

3. テスト・デプロイの内容を「.gitlab-ci.yml」に記述する

RunnerがGitlabに登録できたら、対象のリポジトリにRunnerに処理させたい内容を記述する「.gitlab-ci.yml」を作成する。 今回は、テスト用のリポジトリということで以下のような内容で作成した。

variables:
  GIT_STRATEGY: none

stages:
  - deploy

test_develop_develop:
  type: deploy
  script:
    - pwd
    - rm -rf $PWD/$CI_PROJECT_NAME
    - git clone -b $CI_COMMIT_REF_NAME git@127.0.0.1:$CI_PROJECT_PATH.git
    - echo $CI_COMMIT_REF_NAME
    #- rsync -auz --delete --exclude=".git" --exclude=".gitlab-ci.yml" --exclude="README.md" ./$CI_PROJECT_NAME/* deploy@xxx.xxx.xxx.xxx:/path/to/dir/
  tags:
    - deploy
  only:
    - develop
  when: on_success

test_master_develop:
  type: deploy
  script:
    - pwd
    - rm -rf $PWD/$CI_PROJECT_NAME
    - git clone -b $CI_COMMIT_REF_NAME git@127.0.0.1:$CI_PROJECT_PATH.git
    - echo $CI_COMMIT_REF_NAME
    #- rsync -auz --delete --exclude=".git" --exclude=".gitlab-ci.yml" --exclude="README.md" ./$CI_PROJECT_NAME/* deploy@xxx.xxx.xxx.xxx:/path/to/dir/
  tags:
    - deploy
  only:
    - master
  when: on_success

テスト用なのでrsyncは実際にはキックしていないが、こんな感じで書いてやればデプロイができる。実際にリポジトリに登録する際には、こちらの公式ドキュメントを参考にして作成するといいだろう。 ちなみにclone時にデフォルトだとweb経由で取得するようなのだが、それだと自己証明書の時に面倒なので、今回はssh経由でgit cloneするように記述している。

手動でキックする場合は、whenの箇所をmanualにすることで、Webフロントから任意のpushのみを手動で処理させることができる。