GitLabDay 15

GitLab Auto DevOps を試してみた (その二)

More than 1 year has passed since last update.


GitLab Auto DevOps を試してみた (その二)

これは GitLab Advent Calendar 2017 の 15 日目の記事です。

その一では、GitLab Auto DevOps の Auto DevOps: quick start guide をなぞってみました。

今日はそれを一つ一つ見ていこうと思います。


Auto Build

Auto BuildDockerfile を検出して自動で Docker Image のビルドから GitLab Container Registry へのアップデートまで自動でやってくれるそうです。

$ # Auto DevOps variables and functions # collapsed multi-line command

$ setup_docker
$ build
Building Dockerfile-based application...
Sending build context to Docker daemon 144.4kB

Step 1/6 : FROM ruby:2.4.1-alpine
2.4.1-alpine: Pulling from library/ruby
90f4dba627d6: Pulling fs layer

...

Pushing to GitLab Container Registry...
The push refers to repository [registry.gitlab.com/masakura/minimal-ruby-app/master]
7b433b3bc1d5: Preparing
e7d3ac95d998: Preparing

...

Job succeeded


Auto Test

Auto Testherokuish とやらを利用して実行されています。

あまり Ruby や Heroku に詳しくないのですが、rake test を実行しているのだけは分かりました!

$ setup_test_db

$ cp -R . /tmp/app
$ /bin/herokuish buildpack test
-----> Ruby app detected
-----> Setting up Test for Ruby
-----> Using Ruby version: ruby-2.4.1
-----> Installing dependencies using bundler 1.15.2
Running: bundle install --without development --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment

...

-----> Running test: bin/rake test
/app/vendor/ruby-2.4.1/bin/ruby -w -I"lib:." -I"/app/vendor/bundle/ruby/2.4.0/gems/rake-12.0.0/lib" "/app/vendor/bundle/ruby/2.4.0/gems/rake-12.0.0/lib/rake/rake_test_loader.rb" "test/app_spec.rb"
Run options: --seed 44318
# Running:
.
Finished in 0.001106s, 904.4740 runs/s, 904.4740 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
Job succeeded


Auto Code Quality

Auto Code QualityCode Climate を利用したコード検査です。

$ # Auto DevOps variables and functions # collapsed multi-line command

$ setup_docker
$ codeclimate
Unable to find image 'codeclimate/codeclimate:0.69.0' locally
0.69.0: Pulling from codeclimate/codeclimate

...

Generating .codeclimate.yml...
Config file .codeclimate.yml successfully generated.
Edit and then try running 'validate-config' to check configuration.
Generating default configuration for engines...
Config file .rubocop.yml successfully generated.
WARNING: A new version (v0.70.5) is available. Upgrade instructions are available at: https://github.com/codeclimate/codeclimate#packages
Uploading artifacts...
codeclimate.json: found 1 matching files
Uploading artifacts to coordinator... ok id=44392657 responseStatus=201 Created token=o9ZJXsdP
Job succeeded

コード検査の結果はジョブの成果物に登録されます。TODO が残ってるよ! と教えてくれました。

[

{
"categories": [
"Bug Risk"
],
"check_name": "TODO",
"description": "TODO found",
"location": {
"lines": {
"begin": 8,
"end": 8
},
"path": "server.rb"
},
"type": "issue",
"fingerprint": "d307efde33ac46498148e96379df0fc5",
"severity": "minor",
"engine_name": "fixme"
}
]

Code Quality は Merge Request と組み合わせると面白いんですが、それはまた後程!


Auto Review Apps

Auto Review Apps はすごいです!

Review Apps は Merge Request (Pull Request の GitLab 版) のアプリをプレビューする機能です。Merge Request 毎に、Kubernetes クラスターにビルドされたアプリが設置され、専用の URL でアクセスできるようになります。

ちょっとやってみます。

server.rbこんにちわ に書き換えて、ブランチ名を hello にし、Start a new merge request... にチェックを入れて Commit changes で Merge Request を作成します。

image.png

こんな感じで Merge Request のパイプラインが始まります。

image.png

パイプラインが終わると Merge Request に URL が表示されます。

image.png

クリックすると、こんにちわ! となります。

image.png

キマシター!

こんな感じで、Review Apps では、ソースコードだけでなくアプリの方もレビューができるわけです。

Code Quality もやってみましょう。検査エラーを出すために、server.rbTODO を埋め込みます。

image.png

パイプラインが終了すると、こんな感じでコード検査の問題になる個所が表示されます。

image.png

リンクをクリックすると、該当行へジャンプします。

image.png

なお、Merge Reuqest の Code Quality は Merge Request で変更されたもしくは新しく追加された部分のみが対象となります。もとからある #TODO HTML... には反応しません。


Auto Deploy

Auto Deploymaster にマージされたものをそのまま production として公開します。

先ほど こんにちわ と修正した Merge Request をマージすると、デプロイも含めたパイプラインが開始されます。

image.png

GitLab Project の CI/CD -> Environment -> production と選択します。新しいアプリがデプロイされたことが分かります。

image.png

View deployment をクリックすると、反映されていることが分かります。

image.png

余談ですが、Rollback ボタンをクリックすると、以前の Hello, world! のアプリにすぐに戻せます。便利ですねぇ。


Auto Monitoring

Auto Monitoring はデプロイされたアプリをモニタリングできます。

新しいアプリをデプロイした直後、バグで負荷が急上昇するなど、トラブルがつきものです。GitLab でデプロイし、そのまま GitLab で不具合の兆候を調べられるので便利ですね。

この時点では私はまだうまくモニタリングできていません。

image.png

Prometheus をセットアップすればいいだけだとは思いますが、そこまでは Auto DevOps: quick start guide の方法ではやってくれないようです。

そのあたりはまた次回!


まとめ

Auto DevOps そのものはまだベータで、本番プロジェクトでは使わない方がいいそうです。実際に、DevOps のフローはプロダクトや組織でかなり変わるので、個人的には Auto DevOps が役に立つかどうかまでは分かりません。

Auto DevOps で提供される機能は、すべてマニュアルで設定すれば使うことができます。マニュアルで設定していった方がいいとは思いますが、Auto DevOps を一度は試して、そこをベースに自分らに合わせて調整していく方法がよさそうです。Auto DevOps は GitLab が考える DevOps の具象化したものとして考えています。