ソフトウェアエンジニアの技術ブログ：Software engineer tech blog

Docker HubやGoogle container Registryと同様に、GitLabにもGitLab Container Registryが備わっている。

$ docker login registry.gitlab.com
$ docker build -t registry.gitlab.com/hoge/myproject .
$ docker push registry.gitlab.com/hoge/myproject

コンテナイメージの名前を変数化

job01:
  stages:
    - build
    - test
    - deploy

  variables:
    CONTAINER_NAME: ${CI_PROJECT_NAME}_${APP_NAME}
    CONTAINER_IMAGE: ${CI_REGISTRY}/${CI_PROJECT_NAMESPACE}/${CI_PROJECT_NAME}/${APP_NAME}

  packaged_web_app:
    stage: packaged
    before_script:
      - docker login -u gitlab-ci-token -p ${CI_BUILD_TOKEN} ${CI_REGISTRY}
    script:
      - cd ./${APP_NAME}
      - docker build . -t ${CONTAINER_IMAGE}
    only:
      - branches
    except:
      - master
    tags:
      - shell
      - gitlab-runner01

  deploy_web_demo:
    stage: deploy
    variables:
      SERVICE_DOMAIN: gitlab-service.example.com
    before_script:
      - docker rm -f ${CONTAINER_NAME} || true
    script:
      - docker run --name ${CONTAINER_NAME} -p 80:8080 -d ${CONTAINER_IMAGE}
      - sleep 3
      - curl http://${SERVICE_DOMAIN}/${APP_NAME}
    only:
      - master
    when: manual
    environment:
      name: production
      url: http://${SERVICE_DOMAIN}/${APP_NAME}/
    tags:
      - shell
      - gitlab-runner01  

なるほど、大まかにイメージはできてきた

デプロイを自動化してリリースの安定化が求められる
Pipelineにてjobを組み合わせ、デプロイをコードによって自動化する機能
Review Appsでアーティファクトの確認

### ステージの定義
.gitlab-ci.yml

job01:
  stages:
    - build
    - test
    - deploy

  Build_Job01:
    stage: build
    script:
      - "sudo docker run centos:latest echo Build01"

  Test_Job1:
    stage: test
    script:
      - "sudo docker run centos:latest echo Test01"

  Test_Job2:
    stage: test
    script:
      - "sudo docker run centos:latest echo Test02"

  Deploy_Job1:
    stage: deploy
    script:
      - "sudo docker run centos:latest echo Deploy01"

stageのリストに記載した順番に実行される
whenパラメータ: on_success, on_failure, always, manual

### whenパラメータの例

job01:
  stages:
    - build
    - cleanup_build

  Build_Job01:
    stage: build
    script:
      - "docker run centos:latest echo BuildProcess"

  Cleanup_Build_Job01:
    stage: cleanup_build
    script:
      - "docker rm -f $(sudo docker ps -qa --filter 'status=exited')"
    when: on_failure

### dependenciesパラメータの例

job01:
  stages:
    - build
    - test
    - deploy

  variables:
    APP_NAME: 'web_demo'
    CONTAINER_NAME: ${CI_PROJECT_NAME}_${APP_NAME}

  Build_app01:
    stage: build
    script:
      - cd ./app01
      - gradle war
    artifacts:
      paths:
        - app01/build/libs/*.war

  Build_app02:
    stage: build
    script:
      - cd ./app02
      - gradle war
    artifacts:
      paths:
        - app02/build/libs/*.war

  test_app01:
    stage: test
    script:
      - cd ./app01
      - gradle test
    dependencies:
      - build_app01

  test_app02:
    stage: test
    script:
      - cd ./app02
      - gradle test
    dependencies:
      - build_app02

  deploy:
    stage: deploy
    script:
      - cp app*/build/libs/*.war /usr/local/tomcat/webapps
      - systemctl start tomcat.service

  build_web_demo:
    stage: build
    image: gradle:4.4.1-jdk8
    script:
      - cd ./${APP_NAME}
      - gradle war
      - gradle test
    artifacts:
      paths:
        - ${APP_NAME}/build/libs/*war
      expire_in: 10 min
    tags:
      - docker
      - gitlab-runner01

  test_web_demo:
    stage: test
    variables:
      TEST_CONTENT: GitLab
    script:
      - docker run --name ${CONTAINER_NAME} -d ${APP_NAME}
      - sleep 5
      - export CONTAINER_ADDRESS='docker inspect -f "{{ .NetworkSettings.IPAddress}}" ${CONTAINER_NAME}'
      - wget --post-data="name=${TEST_CONTENT}" http://${CONTAINER_ADDRESS}:8080/${APP_NAME}/hello
      - grep ${TEST_CONTENT} ./hello
    after_script:
      - rm -v ./hello
      - docker rm -f ${CONTAINER_NAME} || true
    tags:
      - shell
      - gitlab-runner01

  deploy_web_demo:
    stage: deploy
    variables:
      SERVICE_DOMAIN: gitlab-service.example.com
    before_script:
      - docker rm -f ${CONTAINER_NAME} || true
    script:
      - docker run --name ${CONTAINER_NAME} -p 80:8080 -d ${APP_NAME}
      - sleep 3
      - curl http://${SERVICE_DOMAIN}/${APP_NAME}/
    tags:
      - shell
      - production-gitlab-runner01

Dockerfile

FROM tomcat:latest
COPY build/libs/*.war /usr/local/tomcat/webapps
CMD ["catalina.sh", "run"]

うーむ、build, test, deployを書いていくのはわかった。

GitLab CI/CDにおけるジョブは「.gitlab-ci.yml」に定義する

.gitlab-ci.yml

job01:
  script:
    - uname -r
    - ps
    - hostname

Job02:
  script:
    - ./build.sh
    - ./test.sh

– Scriptパラメータ利用例

job01:
  script:
    - uname -a
    - ./scripts/build.sh
    - bundle exec rspec spec/requests/

– only, expectパラメータ

job01:
  only:
    - /^script-.*$/
  except:
    - tags

only, exceptで使用できるオプション
branches, tags, pushes, schedules, web

– variablesパラメータ

job01:
  variables:
    PROXY_PATH: 'http://proxy.example.com'
    FLAGS: '-0'
  script:
    - 'https_proxy=$PROXY_PATH curl $FLAGS https://gitlab.com/gitlab-org/gitlab-ce/repository/archive.tar.gz'

– tagパラメータ
プロジェクト内で実行可能なRunnerのリストから特定のRunnerを選択する際に使用
指定したタグを利用し、それにマッチしたRunnerだけにジョブを渡す

job01:
  tags:
    - shell
    - gitlab-runner01

– artifactsパラメータ
ジョブの実行結果をアーティファクトとして保存する際の定義を行う
name, untracked, when, expire_in

job01:
  artifacts:
    name: "${CI_JOB_NAME}_${CI_COMMIT_REF_NAME}"
    untracked: true
    expire_in: 10 min
    paths:
      - ./artifacts

### pythonを実行するサンプル

job01:
  script:
    - python ./scripts/hello.py
  only:
    - master
  tags:
    - shell
    - gitlab-runner01

.gitlab-ci.ymlでbuildとテストを自動化するところまではわかった。
.gitlab-ci.ymlでDockerのbuildをどうやるかが問題か…

継続的CIにはJenkins, Travis CI, Circle CIなどがよく利用される
GitLab CI/CDのジョブ機能を使うことによって、ビルドツールやテストツールと連携したインテグレーションの自動化が可能となる

### GitLab CI/CD Jobs
– マルチプラットフォーム: Go, Linux, Windows, FreeBSD, Dockerなどどのプラットフォーム上でもジョブが実行可
– Merge Requestとの連携: Merge Request後のビルド実行確認ができる
– 並列分散実行: 複数のGitLab runnerプロセスにより並列にビルド実行が可能
– オートスケール: ジョブのオートスケールを実現
– アーティファクトの管理: ブラウザ上から利用可能
L Dockerのレジストリ機能とも簡単に連携できる

### GitLab Runner
GitLab CI/CD上から指示されたスクリプトを実行したり、一時的にDockerコンテナを生成してジョブを実行するプロセス
※コンテナをRunnerする場合は2通りある
1. DockerホストにRunnerをインストールしてコンテナをジョブとして起動
2. DockerコンテナをRunnerとして、コンテナ内でジョブを実行

### Executorの種類
– Shell Executor: Runnerが導入されているサーバ上でビルドやテストを実行できるシンプルなExcecutor
– Docker Executor: Docker APIを通してDocker Engineと接続することによって、コンテナから各ビルド作業を実行
– Virtual Box Executor: VirtualBoxのVMを利用したビルド環境を提供 sshとbashを経由
– SSH Executor: SSH接続可能な特定サーバに対してコマンドをSSH経由で送りつける
– Kubernetes Executor: Kubernetes API経由でクラスタ上のPodを作成してビルドを実施。.gitlab-ci.yml内で定義されたServiceパラメータごとに新たにコンテナが生成されビルド、テストを実施

### Runnerの種類
Shared Runners(共有のRunnerで処理)とSpecific Runners(特定のプロジェクトのジョブのみ実行)の2種類がある
Go言語で作成されており、1つのプロセスで複数のExecutorを登録できる